Oracle® Fusion Middleware

Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド

11gリリース1 (11.1.1.9.0)

B55900-11(原本部品番号:E12037-13)

2015年4月

このドキュメントでは、インストールを行うユーザーを対象に、Oracle WebCenter Portalコンポーネントをエンタープライズ・デプロイメントにインストールおよび構成する方法を説明します。Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのベスト・プラクティスの詳細な計画を示しています。

Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド, 11gリリース1 (11.1.1.9.0)

B55900-11

Copyright © 2009, 2015, Oracle and/or its affiliates.All rights reserved.

原本著者: Bonnie Vaughan (ライター)、Janga Aliminati (設計者)、Richard Delval (協力エンジニア)

原本協力著者: Rosie Harvey、Roy Sandjaja

原本協力者: Fermin Castro Alonso、Pradeep Bhat

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルと著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 エンタープライズ・デプロイメントの概要

- 1.1 エンタープライズ・デプロイメント・ガイドについて

- 1.2 エンタープライズ・デプロイメントの用語

- 1.3 Oracle推奨事項のメリット

- 1.3.1 組込みセキュリティ

- 1.3.2 高可用性

2 エンタープライズ・デプロイメント参照用トポロジの紹介

- 2.1 エンタープライズ・デプロイメント参照用トポロジの概要

- 2.1.1 このガイドに記載されている参照用トポロジ

- 2.1.2 Oracle Identity Managementの統合について

- 2.1.3 Web層ノードについて

- 2.1.3.1 ロード・バランサの要件

- 2.1.4 アプリケーション層について

- 2.1.5 データ層について

- 2.1.6 通信のユニキャスト要件について

- 2.2 Linuxにおけるエンタープライズ・デプロイメントのハードウェア要件

- 2.3 資格証明およびポリシー・ストアとしてのデータベースまたはLDAPの使用について

- 2.4 クロックの同期

- 2.5 インストールするソフトウェア・コンポーネント

- 2.6 参照用トポロジのインストールおよび構成のロード・マップ

- 2.6.1 Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスのフロー・チャート

- 2.6.2 Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスの手順

- 2.6.3 エンタープライズ・デプロイメントへのインクリメンタルなモジュラ・アプローチの理解

3 エンタープライズ・デプロイメント用のネットワークの準備

- 3.1 エンタープライズ・デプロイメント用のネットワークの準備の概要

- 3.2 トポロジで使用する仮想サーバー名

- 3.2.1 wcp.example.com

- 3.2.2 admin.example.com

- 3.2.3 wcpinternal.example.com

- 3.3 ロード・バランサの構成

- 3.3.1 ロード・バランサの要件

- 3.3.2 ロード・バランサの構成手順

- 3.3.2.1 ロード・バランサの構成

- 3.4 IPおよび仮想IPの構成

- 3.5 エンタープライズ・デプロイメント用の仮想IPアドレスの有効化

- 3.6 ファイアウォールおよびポートの構成

4 エンタープライズ・デプロイメント用のファイル・システムの準備

- 4.1 エンタープライズ・デプロイメント用のファイル・システムの準備の概要

- 4.2 ディレクトリ用語とディレクトリ環境変数

- 4.3 異なるディレクトリの推奨場所

- 4.3.1 バイナリ(Oracleホーム)ディレクトリに対する共有記憶域に関する推奨事項

- 4.3.1.1 バイナリ(Oracleホーム)ディレクトリについて

- 4.3.1.2 複数のドメインでの単一のOracleホームの共有について

- 4.3.1.3 冗長バイナリ(Oracleホーム)ディレクトリの使用について

- 4.3.2 ドメイン構成ファイルに対する共有記憶域に関する推奨事項

- 4.3.2.1 Oracle WebLogic Serverの管理サーバーと管理対象サーバーのドメイン構成ファイルについて

- 4.3.2.2 管理サーバーと管理対象サーバーのドメイン構成ファイルの共有記憶域要件

- 4.3.3 JMSファイル・ストアおよびトランザクション・ログに対する共有記憶域に関する推奨事項

- 4.3.4 ディレクトリの推奨場所

- 4.3.5 ディレクトリ構造と構成

- 4.4共有記憶域の構成

5 エンタープライズ・デプロイメント用のデータベースの準備

- 5.1 エンタープライズ・デプロイメント用のデータベースの準備の概要

- 5.2 データベース要件について

- 5.2.1 データベース・ホストの要件

- 5.2.2 サポートされているデータベース・バージョン

- 5.2.3 初期化パラメータについて

- 5.3 データベース・サービスの作成

- 5.3.1 10gおよび11gリリース1 (11.1)データベース用のデータベース・サービスの作成

- 5.3.2 11gリリース2 (11.2)データベース用のデータベース・サービスの作成

- 5.4 Oracle RACデータベースへのOracle Fusionメタデータ・リポジトリのロード

- 5.5 トランザクション・リカバリ権限用SOAスキーマの構成

- 5.6 データベースのバックアップ

6 エンタープライズ・デプロイメント用のソフトウェアのインストール

- 6.1 ソフトウェアのインストール・プロセスの概要

- 6.2 Oracle HTTP Serverのインストール

- 6.2.1 Oracle HTTP Serverのインストールの前提条件

- 6.2.2 Oracle HTTP ServerのWEBHOST1およびWEBHOST2へのインストール

- 6.2.3 Oracle Fusion Middlewareインストールのバックアップ

- 6.3 Oracle Fusion Middlewareのインストール

- 6.3.1 Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成

- 6.3.2 Oracle Fusion Middlewareコンポーネントのインストール

- 6.3.2.1 Oracle SOA Suiteのインストール

- 6.3.2.2 Oracle WebCenter Portalのインストール

- 6.3.2.3 Oracle WebCenter Contentのインストール

- 6.3.3 Fusion Middlewareインストールのバックアップ

7 エンタープライズ・デプロイメント用のWeb層の構成

- 7.1 Web層構成の概要

- 7.2 Web層構成の前提条件

- 7.3 構成ウィザードによるOracle HTTP Serverの構成

- 7.4 Oracle HTTP Serverの構成の検証

- 7.5 HTTPリクエストをルーティングするためのロード・バランサの構成

- 7.6 仮想ホストの定義

- 7.6.1 httpd.confファイルでのIPアドレスとポートの定義

- 7.6.2 <VirtualHost>ディレクティブを定義する.confファイルの作成

- 7.6.3 構成の検証

8 エンタープライズ・デプロイメント用のドメインの作成

- 8.1 ドメイン作成の概要

- 8.2 SOAHOST1でのVIP1の有効化

- 8.3 SOAHOST1での構成ウィザードによるドメインの作成

- 8.4 構成後タスクおよび検証タスク

- 8.4.1 SOAHOST1での管理サーバー用boot.propertiesの作成

- 8.4.2 SOAHOST1でのノード・マネージャの起動

- 8.4.3 SOAHOST1での管理サーバーの起動

- 8.4.4 GridLinkデータ・ソースの構成の検証

- 8.4.5 管理サーバー構成の検証

- 8.4.6 管理サーバーと同じノードでの管理対象サーバー用独立ドメイン・ディレクトリの作成

- 8.4.7 WSM-PM_ClusterへのJava Required Files(JRF)テンプレートの適用

- 8.4.8 ホスト名検証の無効化

- 8.4.9 WLS_WSM1管理対象サーバーの起動と検証

- 8.5 SOAHOST2へのドメイン構成の伝播

- 8.5.1 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

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

- 8.5.3 WLS_WSM2管理対象サーバーに対するホスト名検証の無効化

- 8.5.4 SOAHOST2でのノード・マネージャの起動

- 8.5.5 WLS_WSM2管理対象サーバーの起動と検証

- 8.6 Oracle WSMについてのJavaオブジェクト・キャッシュの構成

- 8.7 WebLogic ServerドメインのOracle HTTP Serverの構成

- 8.7.1 管理サーバーとWLS_WSMn管理対象サーバーについてのOracle HTTP Serverの構成

- 8.7.2 WebLogicプラグイン有効化フラグの有効化

- 8.7.3 WebLogic ServerへのOracle HTTP Serverの登録

- 8.7.4 管理コンソールのフロントエンドURLの設定およびリダイレクション・プリファレンスの設定

- 8.7.5 Oracle HTTP Serverを介したアクセスの検証

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

- 8.8 WebLogic Serverドメイン構成のバックアップ

9 SOAコンポーネントを使用するためのドメインの拡張

- 9.1 SOAコンポーネントを使用するためのドメインの拡張の概要

- 9.2 Oracle SOAコンポーネント用のドメインの拡張の準備

- 9.2.1 SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化

- 9.3 構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張

- 9.4 コンポジットをデプロイするためのOracle Coherenceの構成

- 9.4.1 ユニキャスト通信を使用したデプロイメントの通信の有効化

- 9.4.2 Oracle Coherenceで使用するホスト名の指定

- 9.5 構成後タスクおよび検証タスク

- 9.5.1 WLS_SOAn管理対象サーバーに対するホスト名検証の無効化

- 9.5.2 SOAHOST1でのノード・マネージャの再起動

- 9.5.3 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

- 9.5.4 WLS_SOA1管理対象サーバーの起動と検証

- 9.5.5 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

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

- 9.5.7 WLS_SOA2管理対象サーバーの起動と検証

- 9.5.8 Oracle SOA SuiteのGridLinkデータ・ソースの検証

- 9.6 拡張したドメインでのOracle HTTP Serverの構成

- 9.6.1 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

- 9.6.2 Oracle HTTP Serverを介したアクセスの検証

- 9.6.3 フロントエンドHTTPホストおよびポートの設定

- 9.6.3.1 フロントエンドHTTPホストおよびポートの設定

- 9.6.3.2 コールバックURLについて

- 9.7 トランザクション・リカバリ用デフォルト永続ストアの構成

- 9.8 Oracleアダプタの構成

- 9.8.1 OracleファイルとFTPアダプタの高可用性化

- 9.8.1.1 データベースのmutex lock操作の使用

- 9.8.2 Oracle JMSアダプタの高可用性化

- 9.8.3 Oracle Databaseアダプタのスケーリング

- 9.9 SOA構成のバックアップ

10 WebCenter Portalコンポーネントを使用するためのドメインの拡張

- 10.1 WebCenter Portalコンポーネントを使用するためのドメインの拡張の概要

- 10.2 WebCenter Portalコンポーネントを使用するための構成ウィザードを使用したドメインの拡張

- 10.3 構成後のタスク

- 10.3.1 WebCenter Portal管理対象サーバーに対するホスト名検証の無効化

- 10.3.2 SOAHOST1でのノード・マネージャの起動

- 10.3.3 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

- 10.4 SOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播

- 10.4.1 unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播

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

- 10.4.3 WCPHOST1およびWCPHOST2でのノード・マネージャの起動

- 10.4.4 WCPHOST1でのWC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの起動

- 10.4.5 WebCenter PortalのためのGridLinkデータ・ソース構成およびONS構成の検証

- 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管理対象サーバーの検証

- 10.5 Spaces_Cluster用のJavaオブジェクト・キャッシュの構成

- 10.6 マルチキャストからユニキャストへのディスカッションの変換

- 10.7 ディスカッション・サーバーでのクラスタリングの構成

- 10.8 Analyticsの構成

- 10.9 アクティビティ・グラフの構成

- 10.10 REST APIの構成

- 10.11 拡張したドメインでのOracle HTTP Serverの構成

- 10.11.1 WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成

- 10.11.1.1 Microsoftクライアントの構成

- 10.11.2 Oracle HTTP Serverを介したアクセスの検証

- 10.12 WebCenter Portalの構成のバックアップ

11 エンタープライズ・デプロイメント用のノード・マネージャの設定

- 11.1 ノード・マネージャの概要

- 11.2 ノード・マネージャのログの場所の変更

- 11.3 ノード・マネージャのホスト名検証証明書の有効化

- 11.3.1 utils.CertGenユーティリティを使用した自己署名証明書の生成

- 11.3.2 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

- 11.3.3 keytoolユーティリティを使用した信頼キーストアの作成

- 11.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

- 11.3.5 共通または共有記憶域インストールの使用

- 11.4 ノード・マネージャの起動

- 11.5 カスタム・キーストアを使用するためのWebLogic Serverの構成

12 エンタープライズ・デプロイメントにおけるWebCenter Portalの外部ツールおよびサービスの構成

- 12.1 WebCenter Portal、ディスカッションおよびポートレット・プロデューサ・アプリケーション用デフォルトWebサービス・ポリシーの構成

- 12.2 ディスカッション・サーバーの接続の構成

- 12.2.1 Fusion Middleware Controlを使用したディスカッション・サーバーの接続の作成

- 12.2.2 WLSTを使用したディスカッション・サーバーの接続の作成

- 12.3 インスタント・メッセージおよびプレゼンス(IMP)サーバー接続の構成

- 12.4 ワークリストおよびワークフロー用のBPELサーバー接続の構成

- 12.4.1 開始する前に

- 12.4.2 Fusion Middleware Controlを使用したワークリストおよびワークフローの構成

- 12.4.3 WLSTを使用したワークリストおよびワークフローの構成

- 12.5 ポートレット・プロデューサの登録

- 12.5.1 Fusion Middleware Controlを使用したすぐに使用できるポートレット・プロデューサの登録

- 12.5.2 WLSTを使用したすぐに使用できるポートレット・プロデューサの登録

- 12.6 ページレット・プロデューサの登録

- 12.7 検索サービスの構成

- 12.8 通知用のメール・サーバーの構成

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

- 13.1 Oracle WebCenter Contentを追加するためのドメイン拡張の概要

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

- 13.3 unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播

- 13.4 WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成

- 13.5 WCPHOST1およびWCPHOST2でのノード・マネージャの起動

- 13.6 管理サーバーの再起動

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

- 13.8 WebCenter ContentのためのGridLinkデータ・ソース構成およびONS構成の検証

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

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

- 13.11 WLS_WCC2管理対象サーバーの起動および構成

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

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

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

- 13.15 Oracle HTTP Serverを介したアクセスの検証

- 13.16 インストールのバックアップ

- 13.17 WebCenter Portal用のOracle WebCenter Contentの構成

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

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

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

- 13.18 WebCenter PortalアプリケーションへのOracle WebCenter Contentの登録

- 13.19 Inbound Refineryのインストールと構成

- 13.19.1 Inbound Refineryを追加するためのドメインの拡張

- 13.19.2 unpackユーティリティを使用したWCPHOST1およびWCPHOST2へのドメイン構成の伝播

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

- 13.19.4 管理サーバーの再起動

- 13.19.5 Inbound Refinery管理対象サーバーの起動

- 13.19.6 Inbound Refineryの構成

- 13.19.6.1 Inbound Refineryの設定の構成

- 13.19.6.2 ドキュメント変換の構成

- 13.19.6.3 Inbound RefineryインスタンスのOracle WebCenter Contentへの構成

14 エンタープライズ・デプロイメント用のサーバー移行の構成

- 14.1 エンタープライズ・デプロイメント用のサーバー移行の概要

- 14.2 サーバー移行リース表のユーザーおよび表領域の設定

- 14.3 管理コンソールによるリース用のGridlinkデータ・ソースの作成

- 14.4 ノード・マネージャのプロパティ・ファイルの編集

- 14.5 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

- 14.6 サーバー移行ターゲットの構成

- 14.7 サーバー移行のテスト

15 エンタープライズ・デプロイメントとOracle Identity Managementの統合

- 15.1 Oracle Identity Managementとの統合の概要

- 15.2 資格証明ストアの構成

- 15.2.1 LDAPオーセンティケータの作成

- 15.2.2 WebLogic管理者のLDAPへの移行

- 15.2.2.1 LDAPディレクトリでの管理ユーザーおよびグループのプロビジョニング

- 15.2.2.2 管理ロールの管理グループへの割当て

- 15.2.2.3 接続での新しい管理ユーザーの指定

- 15.2.2.4 boot.propertiesファイルの更新およびシステムの再起動

- 15.2.3 ドメイン資格証明ストアの再関連付け

- 15.3 ポリシー・ストアの構成

- 15.3.1 サーバー・ディレクトリでのノードの設定

- 15.3.2 ドメイン・ポリシー・ストアの再関連付け

- 15.4 ドメイン・ポリシーおよび資格証明ストアの再関連付け

- 15.5 Oracle Access Manager 10gの統合

- 15.5.1 Oracle Access Manager 10gの統合の概要

- 15.5.2 Oracle Access Manager 10gの前提条件

- 15.5.3 OAM構成ツールの使用

- 15.5.3.1 OAM構成ツールの実行の前提条件

- 15.5.3.2 OAM構成ツールの実行

- 15.5.3.3 RESTポリシーの更新

- 15.5.3.4 Oracle SESおよびポートレット用の除外ポリシーの作成

- 15.5.3.5 ポリシー・ドメインおよびアクセス・ゲートを正常に作成したことの確認

- 15.5.3.6 ホスト識別子の更新

- 15.5.3.7 WebGateプロファイルの更新

- 15.5.3.8 アクセス・サーバーの追加

- 15.5.3.9 委任フォーム認証の構成

- 15.5.4 WebGateのインストールと構成

- 15.5.5 WebgateのIP検証の構成

- 15.5.6 WebLogicオーセンティケータの設定

- 15.5.6.1 構成ファイルのバックアップ

- 15.5.6.2 OAM IDアサータの設定

- 15.5.6.3 プロバイダの順序の設定

- 15.5.7 OAM 10gでの仮想ホストの構成

- 15.6 Oracle Access Manager 11gの統合

- 15.6.1 Oracle Access Manager 11gの統合の概要

- 15.6.2 Oracle Access Manager 11gの前提条件

- 15.6.3 WebGateの設定

- 15.6.3.1 GCCライブラリのインストール

- 15.6.3.2 WebGateのインストール

- 15.6.3.3 インストール後の手順

- 15.6.4 WebGateエージェントの登録

- 15.6.4.1 RREGツール

- 15.6.4.2 OAM11gRequestファイルの更新

- 15.6.4.3 oamregツールの実行

- 15.6.4.4 WEBHOSTへのアクセス・ファイルのコピー

- 15.6.4.5 RESTポリシーの更新

- 15.6.5 WebLogicオーセンティケータの設定

- 15.6.5.1 構成ファイルのバックアップ

- 15.6.5.2 OAM IDアサータの設定

- 15.6.5.3 プロバイダの順序の設定

- 15.6.6 OAM 11gでの仮想ホストの構成

- 15.7 SSO用のWebCenter Portalアプリケーションの構成

- 15.7.1 WebCenter Portal用のシステム・プロパティの構成

- 15.7.2 WebCenter Portalの管理者ロールの構成

- 15.7.2.1 WLSTを使用したWebCenter Portal管理者ロールの付与

- 15.7.2.2 Fusion Middleware Controlを使用したWebCenter Portal管理者ロールの付与

- 15.7.3 ディスカッション・サーバーでSSOプロバイダとしてOAMを使用するための設定

- 15.7.3.1 ディスカッション・サーバーでの管理者権限の付与

- 15.7.3.2 ディスカッション・サーバー用のシステム・プロパティの構成

- 15.7.3.3 ディスカッション・サーバー接続に対する新しい管理ユーザーの指定

- 15.8 WebCenter PortalおよびBPEL認証の構成

- 15.8.1 オーセンティケータの検証

- 15.8.2 soa-infraのBPMWorkflowAdminアプリケーション・ロールのロール・メンバーの設定

- 15.8.3 SOAコールバックURLの構成

- 15.9 アイデンティティ管理構成のバックアップ

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

- 16.1 トポロジの管理および監視の概要

- 16.2 SOAインフラストラクチャ・データベースでのスペースの管理

- 16.3 UMSドライバの構成

- 16.4 トポロジのスケール・アップ(管理対象サーバーを既存ノードに追加)

- 16.4.1 Oracle SOA (WSMを含む)のスケール・アップ

- 16.4.2 Oracle WebCenter Portalのスケール・アップ

- 16.4.3 Oracle WebCenter Contentのスケール・アップ

- 16.5 トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)

- 16.5.1 Oracle SOA (WSMを含む)のスケール・アウト

- 16.5.2 Oracle WebCenter Portalのスケール・アウト

- 16.5.3 Oracle WebCenter Contentのスケール・アウト

- 16.6 WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行

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

- 16.7.1 別ノードへの管理サーバーのフェイルオーバー

- 16.7.2 Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証

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

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

- 16.9 Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング

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

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

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

- 16.9.4 ドメインの伝播後WC_Spaces Serverが起動しない

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

- 16.9.6 データベースのフェイルオーバー後にポートレットが使用できなくなる

- 16.9.7 構成済のJOCポートがすでに使用中

- 16.9.8 JMS構成の復元

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

- 16.9.10 RESTポリシーの構成後に2次認証を無効にする

- 16.9.11 サーバー移行時にSudoエラーが発生する

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

- 16.9.13 最大サイズ超過エラー・メッセージ

A Oracle RACでのマルチ・データ・ソースの使用

- A.1 マルチ・データ・ソースおよびOracle RACについて

- A.2 EDGトポロジ用のマルチ・データ・ソースの構成の標準的な手順

B アプリケーションおよびリソースのサーバーへのターゲット設定

- B.1 WebCenter Portal管理対象サーバー

- B.2 WebCenter Portalポートレット管理対象サーバー

- B.3 WebCenter Portalコラボレーション管理対象サーバー

- B.4 WebCenter Portalユーティリティ管理対象サーバー

- B.5 Oracle SOA Suite管理対象サーバー

- B.6 Oracle WSMポリシー・マネージャ管理対象サーバー

- B.7 WebCenter Content管理対象サーバー

- B.8 Inbound Refinery管理対象サーバー

- B.9 管理サーバー

索引

はじめに

「はじめに」では、『Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド』の対象読者、内容および表記規則について説明します。

対象読者

このガイドは、Oracle Fusion Middlewareエンタープライズ・デプロイメントのインストールや構成を担当するシステム管理者を対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

Oracle Fusion Middlewareドキュメント・ライブラリにある次のマニュアルに、エンタープライズ・デプロイメント・アーキテクチャをインストールおよび構成する手順に関する追加情報があります。

- 管理者ガイド

- Oracle Virtual Directory管理者ガイド

- Oracle Internet Directory管理者ガイド

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するグラフィカル・ユーザー・インタフェース要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、パラグラフ内のコマンド、URL、例に記載されているコード、画面に表示されるテキスト、または入力するテキストを示します。

1 エンタープライズ・デプロイメントの概要

この章では、Oracle WebCenter Portalエンタープライズ・デプロイメントの概要を示します。

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

- エンタープライズ・デプロイメント・ガイドについて

- エンタープライズ・デプロイメントの用語

- Oracle推奨事項の利点

1.1 エンタープライズ・デプロイメント・ガイドについて

このエンタープライズ・デプロイメント・ガイドは、Oracle WebCenter Portalエンタープライズ・デプロイメントの実証済高可用性テクノロジ、セキュリティ・テクノロジおよび推奨事項に基づいたベスト・プラクティスの青写真です。これらの青写真に示すベスト・プラクティスは、技術スタック全体において多くのOracle製品を対象にしています。それらの製品には、Oracle Database、Oracle Fusion MiddlewareおよびEnterprise Manager Fusion Middleware Controlがあります。

Oracle Fusion Middlewareのエンタープライズ・デプロイメントの特長は、次のとおりです。

- 様々なビジネス上のサービス・レベル合意(SLA)を考慮し、高可用性に対するベスト・プラクティスを可能なかぎり広範囲に適用できるようにします。

- データベース・グリッド・サーバーと低コストのストレージを使用したストレージ・グリッドを活用し、回復力に優れ低コストのインフラストラクチャを提供します。

- 様々な構成に対する広範なパフォーマンス影響調査の結果を利用し、最適な高可用性アーキテクチャを構成して、実行およびビジネス・ニーズに合せたスケール変更を可能にします。

- 停止状態からのリカバリ時間と自然災害時に許容可能なデータ損失量を制御できます。

- ハードウェアやオペレーティング・システムに依存しない、Oracleのベスト・プラクティスと推奨アーキテクチャを使用します。

高可用性の実現の詳細は、Oracle Technology NetworkのOracle Database高可用性に関するページ(http://www.oracle.com/technetwork/database/features/availability/maa-best-practices-155366.html)を参照してください。

注意:
Oracle WebCenter Portalのエンタープライズ・デプロイメント・ガイドは、Linux環境におけるエンタープライズ・デプロイメントを中心に説明しています。しかしながら、UNIX環境やWindows環境を使用したエンタープライズ・デプロイメントの実装も可能です。

1.2 エンタープライズ・デプロイメントの用語

この項では、以前のリリースのコンポーネントで使用されていた用語と、それに対応する11gリリース1 (11.1.1.9.0)の用語について説明します。

- Oracleホーム: Oracleホームには、特定の製品をホストするために必要な、インストール済のファイルが含まれています。たとえば、WebCenter Portal Oracleホームには、Oracle WebCenter Portalのバイナリおよびライブラリ・ファイルを含むディレクトリが含まれています。Oracleホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。各Oracleホームは、複数のOracleインスタンスやOracle WebLogic Serverドメインと関連付けることができます。

- Oracle共通ホーム: この環境変数と関連ディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files (JRF)に必要なバイナリおよびライブラリ・ファイルが含まれるOracleホームを指しています。

- WebLogic Serverホーム: WebLogic Serverホームには、WebLogic Serverをホストするために必要な、インストール済のファイルが含まれています。WebLogic Serverホームのディレクトリは、Oracleホームのディレクトリのピアで、ミドルウェア・ホームのディレクトリ構造の内部にあります。

- ミドルウェア・ホーム: ミドルウェア・ホームは、Oracle WebLogic Serverホームと、オプションとして1つまたは複数のOracleホームで構成されます。ミドルウェア・ホームは、ローカル・ファイル・システムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。

- Oracleインスタンス: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどの、1つ以上のアクティブなミドルウェア・システム・コンポーネントが含まれます。インストール時かその後でインスタンスの作成と構成を行うときに、インスタンスにどのコンポーネントを含めるかを決定しますOracleインスタンスには、更新可能なファイルがあります。それらのファイルの例には、構成ファイル、ログ・ファイル、一時ファイルなどがあります。

- フェイルオーバー: 高可用性システムのメンバーに不測の障害が発生した場合(計画外停止)、サービスの提供をコンシューマに対して続行するため、システムではフェイルオーバー操作が行われます。システムがアクティブ/パッシブ型システムの場合、パッシブ・メンバーはフェイルオーバー操作においてアクティブになります。そしてコンシューマは、障害が発生したメンバーではなく、アクティブになったメンバーにダイレクトされます。フェイルオーバー操作は、手動でも実行できます。また、障害を検出した場合にクラスタのリソースを障害ノードからスタンバイ・ノードに移動するように、ハードウェア・クラスタ・サービスを設定することで、フェイルオーバー操作を自動化することもできます。システムがアクティブ/アクティブ型システムの場合、ロード・バランサのエンティティによりフェイルオーバーが実行されます。このエンティティによって、リクエストがアクティブ・メンバーで処理されます。アクティブ・メンバーに障害が発生すると、ロード・バランサにより障害が検出され、障害メンバーへのリクエストが、正常に動作しているアクティブ・メンバーに自動的にリダイレクトされます。アクティブ/アクティブ型システムとアクティブ/パッシブ型システムの詳細は、『高可用性ガイド』を参照してください。

- フェイルバック: システムのフェイルオーバー操作が正常に終了した後、最初に障害を起こしたメンバーは修復され、スタンバイ・メンバーとしてシステムに再導入されます。必要に応じて、フェイルバック処理を開始して、このメンバーをアクティブにし、別のメンバーを非アクティブにすることができます。この処理によりシステムは、障害発生前の構成に戻ります。

- ハードウェア・クラスタ: ハードウェア・クラスタは、これらのサービスのクライアントにネットワーク・サービス(例: IPアドレス)や、アプリケーション・サービス(例: データベース、Webサーバー)の単一ビューを提供するコンピュータの集まりです。ハードウェア・クラスタの各ノードは、それぞれ固有のプロセスを実行するスタンドアロン・サーバーです。これらのプロセスは互いに通信して、単一のシステムであるかのように動作して、アプリケーション、システム・リソースおよびデータを連携してユーザーに提供できます。
特別なハードウェア(クラスタ・インターコネクト、共有記憶域)とソフトウェア(ヘルス・モニター、リソース・モニター)を使用することで、ハードウェア・クラスタにより高可用性とスケーラビリティが実現されます。クラスタ・インターコネクトは、ハートビート情報でノード障害を検出するハードウェア・クラスタで使用されるプライベート・リンクです。ハードウェア・クラスタでは特別なハードウェアとソフトウェアが必要なので、一般的にSun、HP、IBM、Dellなどのハードウェア・ベンダーによりハードウェア・クラスタは提供されています。ハードウェア・クラスタで構成可能なノードの数はベンダーによって異なりますが、Oracle Fusion Middlewareの高可用性を実現するのに必要なノードの数は2つのみです。このため、ハードウェア・クラスタを使用する高可用性ソリューションでは、2つのノードによるハードウェア・クラスタがこのドキュメントで前提にされています。

- クラスタ・エージェント: ハードウェア・クラスタのノード・メンバー上で実行されるソフトウェアで、他のノードとの可用性やパフォーマンスの操作の調整をします。クラスタウェアによりリソースのグループ化と監視を行い、サービスを移行できます。クラスタ・エージェントではサービスのフェイルオーバーを自動化できます。

- クラスタウェア: クラスタ・メンバーの処理を、1つのシステムとして管理するソフトウェアです。これにより、クラスタ・メンバー間のハートビート・メカニズムを使用して、監視対象のリソースとサービスのセットを定義したり、これらのリソースとサービスをクラスタ内の別のメンバーにできるだけ効率的かつ透過的な方法で移動することができます。

- 共有記憶域: エンタープライズ・デプロイメント・ドメイン内のすべてのマシンがアクセスできる記憶域のサブシステムです。共有ディスクには特に次のものが配置されています。

- ミドルウェア・ホームのソフトウェア

- AdminServerドメイン・ホーム

- JMS

- Tlogs(該当する場合)

Oracle WebCenter ContentまたはInbound Refinery管理対象サーバーを除いて、管理対象サーバー・ホームも共有ディスクに配置できます。共有記憶域は、Network Attached Storage (NAS)またはStorage Area Network (SAN)にすることができます。また、複数のノードが同時にアクセスして読込みと書込みができる他のストレージ・システムにすることもできます。

- 1次ノード: Oracle Fusion Middlewareインスタンスをいつでもアクティブに実行しているノードであり、バックアップ/2次ノードを持つように構成されているノードです1次ノードに障害が発生すると、Oracle Fusion Middlewareインスタンスは2次ノードにフェイルオーバーされます。このフェイルオーバーは、管理サーバー用のクラスタウェアを使用して、手動または自動で実行できます。サーバー移行機能に基づいたシナリオでは、WebLogic Whole Server移行機能が自動化フェイルオーバーに使用されています。

- 2次ノード: Oracle Fusion Middlewareインスタンスのバックアップ・ノードであるノード。1次ノードが使用できなくなると、アクティブなインスタンスでフェイルオーバーが実行されます。この項で、1次ノードに関する定義を参照してください。

- ネットワーク・ホスト名: ネットワーク・ホスト名は、/etc/hostsファイルまたはDNS名前解決を通じてIPアドレスに割り当てられる名前です。この名前は、参照先マシンに接続する際にネットワークで参照可能です。ネットワーク・ホスト名と物理ホスト名が同一である場合があります。ただし、各マシンには物理ホスト名は1つのみ付与されますが、ネットワーク・ホスト名は複数付与される場合があります。そのため、マシンのネットワーク・ホスト名はその物理ホスト名であるとはかぎりません。

- 物理ホスト名: このガイドでは、物理ホスト名とネットワーク・ホスト名を区別しています。このガイドでは、現在のマシンの内部名を指す場合に物理ホスト名が使用されます。UNIXでは、hostnameコマンドにより返される名前です。
Oracle Fusion Middlewareで使用される物理ホスト名は、ローカル・ホストを示します。インストール中に、インストーラでは物理ホスト名が現在のマシンから自動的に取得され、ディスク上のOracle Fusion Middleware構成メタデータに格納されます。

- 物理IP: 物理IPは、ネットワーク上のマシンのIPを示します。ほとんどの場合、マシンの物理ホスト名と関連付けられます(物理ホスト名に関する定義を参照)。仮想IPと対照的に、マシンがネットワークに接続されると、必ず同じマシンと関連付けられます。

- スイッチオーバー: 通常の操作中に、システムのアクティブなメンバーのメンテナンスやアップグレードが必要になることがあります。スイッチオーバー処理を開始して、メンテナンスやアップグレード(計画停止中に実施)が必要なメンバーが処理していたワークロードを、代替メンバーが引き継ぐことができます。スイッチオーバー処理により、システムのコンシューマに対してサービスが続行できるようになります。

- スイッチバック: スイッチオーバー操作の実行時、メンテナンスまたはアップグレードのためにシステムのメンバーは非アクティブ化されます。メンテナンスやアップグレードが完了すると、システムでスイッチバック処理を実行して、アップグレードしたメンバーをアクティブ化し、スイッチオーバー前の構成にシステムを戻すことがきます。

- 仮想ホスト名: 仮想ホスト名はネットワーク・アドレスを指定可能なホスト名で、ロード・バランサまたはハードウェア・クラスタを通じて、1つ以上の物理マシンにマップされます。ロード・バランサの場合、このマニュアルでは仮想サーバー名の名前は仮想ホスト名と同じ意味で使用されます。複数のサーバーのセットを代表する仮想ホスト名をロード・バランサに付与でき、クライアントは仮想ホスト名を使用して、間接的にマシンと通信します。ハードウェア・クラスタの仮想ホスト名は、クラスタの仮想IPに割り当てられるネットワーク・ホスト名です。クラスタにある特定ノードにクラスタの仮想IPが永続的に付与されないため、仮想ホスト名も特定ノードに永続的に付与されません。

注意:
このドキュメントで仮想ホスト名という用語を使用する場合は、常にそれが仮想IPアドレスに関連付けられることを前提とします。IPアドレスが必要とされたり使用される場合、明示的に言及します。

- 仮想IP: クラスタ仮想IP、ロード・バランサ仮想IPとも言います。一般的に、仮想IPはハードウェア・クラスタやロード・バランサに割り当てることができます。クラスタにおいて単一のシステム・ビューをネットワークのクライアントに対して実現するために、クラスタのメンバーであるサーバーのグループに対して仮想IPはエントリ・ポイントのIPアドレスとして機能します。仮想IPはハードウェア・クラスタやサーバーのロード・バランサに割り当てることができます。
ハードウェア・クラスタではクラスタの仮想IPが使用され、外部の世界に対してクラスタ(スタンドアロンのマシンにも設定可能)へのエントリ・ポイントを実現します。ハードウェア・クラスタのソフトウェアにより、クラスタにある2台の物理ノード間においてこのIPアドレスの変更が管理されますが、クライアントはこのIPアドレスに接続します。その際、このIPアドレスが現在アクティブである物理ノードを判別する必要はありません。2台のノードによる標準的ハードウェア・クラスタ構成では、各マシンには固有の物理IPアドレスと物理ホスト名が付与されながら、数個のクラスタIPアドレスを付与することもできます。これらのクラスタIPアドレスは、2台のノードにおいて切り替わります。クラスタIPアドレスを現在所有しているノードは、そのアドレスでアクティブになります。

また、ロード・バランサでも、複数のサーバーのセットのエントリ・ポイントとして仮想IPが使用されます。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーには割り当てられませんが、サーバーとクライアントとの間においてプロキシとして動作するロード・バランサに割り当てられます。

1.3 Oracle推奨事項のメリット

このガイドで説明するOracle Fusion Middleware構成では、すべての起動でセキュリティが確保され、ハードウェア・リソースが最大化され、様々なアプリケーションを使用したエンタープライズ・コンピューティングのために信頼性が高く標準に準拠したシステムを提供するために設計されています。

- 第1.3.1項「組込みセキュリティ」

- 第1.3.2項「高可用性」

Oracle Fusion Middleware構成のセキュリティと高可用性のメリットは、ファイアウォール・ゾーンの分離とソフトウェア・コンポーネントのレプリケーションを通じて実現されます。

1.3.1 組込みセキュリティ

エンタープライズ・デプロイメント・アーキテクチャのセキュリティを確保するためには、ソフトウェア・コンポーネントのすべての機能グループを各グループ固有のDMZで分離し、すべてのトラフィックをプロトコルとポートによって制限します。次の特長により、必要なレベルのすべてのセキュリティが確保され、高レベルの標準の準拠が実現します。

- ポート80で受信した外部通信はすべてポート443にリダイレクトするように、外部のロード・バランサを構成します。

- 外部のクライアントからの通信はロード・バランシング・ルーターを超えたレベルでは発生しません。

- ロード・バランシング・ルーターからデータ層への直接的な通信は許可されません。

- コンポーネントは、Web層、アプリケーション層およびデータ層の異なる保護ゾーンで分離されます。

- いずれの時点においても、2つのファイアウォール間での直接的な通信は禁止されています。

- 1つのファイアウォール・ゾーンで通信が始まった場合、それは次のファイアウォール・ゾーンで終わる必要があります。

- Oracle Internet Directoryはデータ層内で独立しています。

- Oracle Identity Managementコンポーネントは別のサブネットにあります。

- 複数の保護ゾーンにおいて複数のコンポーネント間の通信はすべて、ファイアウォールのルールに従いポートとプロトコルによって制限されます。

1.3.2 高可用性

各コンポーネントまたはソフトウェア・コンポーネントの機能グループが別のコンピュータにレプリケートされており、コンポーネント・レベルでの高可用性を実現するように構成されます。このため、エンタープライズ・デプロイメント・アーキテクチャでは高い可用性が実現されます。

2 エンタープライズ・デプロイメント参照用トポロジの紹介

この章では、Oracle WebCenter Portalのエンタープライズ・トポロジの概要を示します。

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

- エンタープライズ・デプロイメント参照用トポロジの概要

- Linuxにおけるエンタープライズ・デプロイメントのハードウェア要件

- 資格証明およびポリシー・ストアとしてのデータベースまたはLDAPの使用について

- クロックの同期

- インストールするソフトウェア・コンポーネント

- 参照用トポロジのインストールおよび構成のロード・マップ

2.1 エンタープライズ・デプロイメント参照用トポロジの概要

この項では、WebCenter Portalのエンタープライズ・トポロジについて説明します。この項を使用してエンタープライズ・デプロイメント・トポロジを計画してください。

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

- 第2.1.1項「このガイドに記載されている参照用トポロジ」

- 第2.1.2項「Oracle Identity Managementの統合について」

- 第2.1.3項「Web層ノードについて」

- 第2.1.4項「アプリケーション層について」

- 第2.1.5項「データ層について」

- 第2.1.6項「通信のユニキャスト要件について」

2.1.1 このガイドに記載されている参照用トポロジ

このマニュアルでは、図2-1に示す、Oracle WebCenter PortalでOracle Access Managerを使用する参照用エンタープライズ・トポロジの構成手順を示します。

注意:
エンタープライズ・デプロイメントの実際のトポロジでは、このガイドで説明するトポロジの一部変更が必要な場合もあります。

図2-1 Oracle Access Managerを使用したMyWCPExampleトポロジ

2.1.2 Oracle Identity Managementの統合について

Oracle Identity Managementシステムとの統合は、エンタープライズ・デプロイメント・アーキテクチャの重要な側面です。この統合により、シングル・サインオン、Oracle Platform Security Servicesとの統合、一元化されたアイデンティティおよび資格証明ストア、WebLogic Serverドメインにおける認証などの機能が実現されます。Oracle Identity Management (IDM)エンタープライズ・デプロイメントはこのエンタープライズ・デプロイメントとは別であり、それ自体で別のドメイン内に存在します。エンタープライズ・デプロイメント・コンテキストのOracle Identity Managementの詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

Oracle Identity Managementエンタープライズ・デプロイメントへの主要インタフェースは、LDAPサーバーへのLDAPトラフィック、OAMアクセス・サーバーへのOAP (Oracle Access Protocol)および認証リクエストのHTTPリダイレクトです。

2.1.3 Web層ノードについて

Web層のノードはDMZパブリック・ゾーンにあります。この層では、2つのノード(WEBHOST1とWEBHOST2)が、WebGateおよび*_vh.confファイルとともに構成されているOracle HTTP Serverを実行します。

Oracle HTTP ServerからWebLogic Serverへのリクエストのプロキシを許可する*_vh.confファイルを通じて、Oracle HTTP Serverはアプリケーション層で実行されているWebLogic Serverにリクエストを転送します。

Oracle HTTP ServerにあるWebGate (Oracle Access Managerコンポーネント)はOracle Access Protocol (OAP)を使用して、Oracle Oracle Identity Management DMZ内のOAMHOST2で実行されているOracle Access Managerと通信します。WebGateとOracle Access Managerは、ユーザー認証などの操作を実行するために使用されます。Oracle HTTP Server内のWebGateモジュールは、Oracle Access Protocol (OAP)を使用してOracle Access Managerと通信し、ユーザー・グループへの問合せなどの操作を実行します。

Web層には外部リクエストを処理するロード・バランサ・ルーターも含まれています。外部リクエストは、ロード・バランサで構成されている仮想ホスト名に送信されます。ロード・バランサは、このリクエストをOracle HTTP Serverに転送します。

Web層を保護しているファイアウォールでは、HTTPポート、つまりHTTPS用のポート443とHTTP用のポート80のみが開いています。

2.1.3.1 ロード・バランサの要件

このエンタープライズ・トポロジは外部のロード・バランサを使用します。この外部ロード・バランサには、次の機能が必要です。

- 仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。

- ポート変換構成が可能である必要があります。これによって、仮想ホスト名とポートにおける入力リクエストが、バックエンド・サーバーにある別のポートにリダイレクトされます。

- プールにあるサーバーのポートを監視してサービスの可用性を判定する機能。

- 仮想サーバーとポートの構成: 仮想サーバー名とポートを外部ロード・バランサ上で構成できる機能。仮想サーバー名とポートは次の要件を満たす必要があります。

- ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、Web層のOracle HTTP Serverの場合、ロード・バランサでは、HTTPとHTTPSのトラフィックに対して仮想サーバーとポートで構成されている必要があります。

- 仮想サーバー名は、IPアドレスに関連付けられていて、DNSの一部であることが必要です。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。

- ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。

- フォルト・トレラント・モード: ロード・バランサをフォルト・トレラント・モードに構成することを強くお薦めします。

- トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようにロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。これは、クライアント・マシンのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断するより望ましい方法です。

- スティッキーなルーティング機能: コンポーネントに対してスティッキーな接続を維持できる機能です。この例には、Cookieベースの永続性やIPベースの永続性などが含まれています。

- ロード・バランサはSSLリクエストをロード・バランサで終了して、同等の非SSLプロトコル(たとえば、HTTPSからHTTP)を使用してトラフィックを実際のバックエンド・サーバーに転送できる必要があります。この機能は一般にSSLの高速化と呼ばれ、このエンタープライズ・デプロイメントで必要になります。

注意:
ロード・バランサは、外部向けのURLを介した、すべてのクライアント・リクエストのエントリ・ポイントです。同じように構成されている内部URLは、クライアントが一般的に使用することを意図したものではなく、内部での使用用です。WebCenter Portalエンタープライズ・デプロイメント・トポロジでは、内部/外部設定はサポートしていません。

ロード・バランサの構成方法の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

2.1.4 アプリケーション層について

アプリケーション層のノードはDMZセキュア・ゾーンにあります。

この層では、SOAHOST1とSOAHOST2の2つのノードが、Oracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlを実行しますが、構成はアクティブ/パッシブです。管理サーバーは、手動でフェイルオーバーすることも(第8.7.6項「管理サーバーの手動フェイルオーバーの検証」を参照)、Oracle WebLogic Server管理コンソールをCFC/CRSで構成して、自動で別のハードウェア・クラスタにフェイルオーバーすることもできます(このアーキテクチャでは記載されていません)。

Oracle WebCenter Portalコンポーネントは、アクティブ/アクティブ構成で、WCPHOST1とWCPHOST2上で実行されます。一般的に管理対象サーバーは、WC_Spaces (すぐに使用可能なWebCenter Portalアプリケーション)、WC_Portlet (ポートレットとページレット・プロデューサ)、WC_Collaboration (ディスカッション)、WC_Utilities (分析、アクティビティ・グラフ、パーソナライズ)と呼ばれます。カスタムの管理対象サーバーを作成して、JDeveloperを使用して構築されたWebCenter Portal Frameworkアプリケーションを実行することもできます。

WCPHOST1とWCPHOST2では、Oracle WebCenterコンテンツ・サーバーも実行され、アクティブ/アクティブ構成で構成されています。

このトポロジでSOAコンポーネントも実行している場合、SOAHOST1とSOAHOST2は、SOAコンポーネントを実行する管理対象サーバーWLS_SOAおよびWLS_WSMとともに構成されているWebLogic Serverを実行します。これらのコンポーネントはアクティブ/アクティブ構成です。

Oracle Web Services Manager (Oracle WSM)は、エンタープライズ・デプロイメント・トポロジにおけるWebサービスの管理と保護を目的としたポリシー・フレームワークを提供します。また、WSMのポリシー・マネージャでは、さらに2台のWebLogic Serverでアクティブ/アクティブ構成で実行されます。

アプリケーション層を保護しているファイアウォールでは、HTTPポート、OAPポートおよびプロキシ・ポートが開きます。OAPポートは、Web層のOracle HTTP Serverで実行されているWebGateモジュールがOracle Access Managerと通信するためのものです。外部のHTTPアクセスが必要なアプリケーションでは、Oracle HTTP Serverがプロキシとして使用されます。Oracle HTTP Server上のプロキシが有効にされて、このアクセスが許可される必要があります。

2.1.5 データ層について

データ層のノードは、最もセキュアなネットワーク・ゾーン(イントラネット)に配置されます。

この層では、Oracle RACデータベースがCUSTDBHOST1とCUSTDBHOST2のノードで実行されます。このデータベースには、WebCenter Portal、WebCenter Content、SOA Suiteコンポーネントに必要なスキーマが含まれています。アプリケーション層で実行される、WebCenter Portal、WebCenter Content、およびSOAコンポーネントがこのデータベースにアクセスします。

データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(一般的には1521)が開かれている必要があります。また、IDMエンタープライズ・デプロイメントでLDAP記憶域にアクセスするトラフィックに対して、LDAPポート(一般的には389および636)が開いている必要があります。

2.1.6 通信のユニキャスト要件について

MyWCPExampleトポロジ内のノードでは、ユニキャストを使用し通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。

ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。

クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。

ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。

ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。

- WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。

- 個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプのオーバーライドはできません。

- メッセージ・モードを変更するには(ユニキャストからマルチキャストへ、またはマルチキャストからユニキャストへ)、クラスタ全体を停止してから再起動する必要があります。

- マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。

- クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。

- JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。

2.2 Linuxにおけるエンタープライズ・デプロイメントのハードウェア要件

エンタープライズ・デプロイメントをインストールして構成する前に、Oracle Technology Network (OTN)でOracle Fusion Middlewareのシステム要件と仕様に関するドキュメントに目を通して、インストールする製品の最小インストール要件を環境が満たしていることを確認します。

さらに、表2-1では、このガイドで説明されているエンタープライズ・デプロイメントの標準的なハードウェア要件でLinuxオペレーティング・システムに関するものを示しています。

適切なキャパシティ・プランニングを実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。これは、使用される各WebCenter PortalアプリケーションまたはカスタムSOAシステムによって異なります。

表2-1 標準ハードウェア要件

サーバー

ディスク

メモリー

TMPディレクトリ

スワップ

データベース

nXm

n: ディスクの台数(台数は4台以上で、1台のディスクはストライプ)

m: ディスクの容量(30GB以上)

6 - 8GB

デフォルト

デフォルト

WEBHOSTn

10GB

4GB

デフォルト

デフォルト

SOAHOSTn

10GB脚注 1

10GB

デフォルト

デフォルト

WCPHOSTn

10GB

10GB

デフォルト

デフォルト

脚注 1 共有記憶域のミドルウェア・ホーム構成の場合、2つのインストールでは、スロット数と関係なく合計20GBになるようにすると十分です。第4.4項「共有記憶域の構成」を参照してください。

2.3 資格証明およびポリシー・ストアとしてのデータベースまたはLDAPの使用について

Oracle Fusion Middlewareでは、WebLogic Serverドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、Oracle Database、XMLファイル(デフォルト)、または様々なタイプのLDAPプロバイダに基づいてストアを使用できます。ドメインでデータベースまたはLDAPを使用する場合は、すべてのポリシー・データと資格証明データが、一元化されたストアで保持および管理されます。ただし、XMLポリシー・ストアを使用すると、管理対象サーバー上で行われる変更は、管理サーバーに伝播されません(両方のサーバーが同じドメイン・ホームを使用していない場合)。

データベースまたはLDAPベースのストアでは、資格証明およびポリシー・ストアは、システムおよびアプリケーション固有のポリシー、資格証明およびキーのリポジトリであるセキュリティ・ストアの一部です。 この集中化により、ポリシー、資格証明、およびキーに関するデータの管理と保守が容易になります。

注意:
デフォルトのファイル・ベースのポリシーおよび資格証明ストアは、開発のみに使用され、単一ノードのWebCenter Portal構成でのみ使用する必要があります。エンタープライズ・デプロイメントの場合、ポリシー・ストアおよび資格証明ストアをデータベース・ベースのセキュリティ・ストアまたは外部のLDAPベースのストアに再度関連付ける必要があります。この再関連付を、ドメインの作成直後(拡張の前)に実行すると、ポリシーが上書きされず、Oracle Enterprise Manager Fusion Middleware Controlにドメインのアプリケーション・ストライプが表示されます。
本番環境にはデータベース・ベースのセキュリティ・ストアをお薦めします。詳細は、『Oracle Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」を参照してください。

Oracle Fusion Middleware WebCenter Portalエンタープライズ・デプロイメント・トポロジでは、第4.2項「ディレクトリ用語とディレクトリ環境変数」に記載されているように、管理サーバーと管理対象サーバーは別のドメイン・ホームを使用します。前述の「注意」に示されているように、ポリシー・ストアの再関連付けが必要です。

注意:
ドメイン・ホームは、サーバーが実行される物理ディレクトリ(/aserverまたは/mserver)です。管理サーバーのドメイン・ディレクトリの構成ファイルへの変更は外に伝播されます。ただし、管理対象サーバーのドメイン・ディレクトリへの変更は上書きされます。

LDAPを資格証明およびポリシー・ストアとしてWebCenter Portalエンタープライズ・デプロイメント・トポロジに構成するには、第15.2項「資格証明ストアの構成」および第15.3項「ポリシー・ストアの構成」の手順を実行します。

2.4 クロックの同期

ジョブ、アダプタおよびOracle B2Bを正常に機能させるため、クラスタに参加するすべてのサーバーのクロックを同期させ、クロックの時間差を1秒以内に収める必要があります。これを実現するには、ネットワーク・タイム・サーバーを1つ使用して、各サーバーがそのネットワーク・タイム・サーバーを参照するようにします。

ネットワーク・タイム・サーバーを参照させる手順は、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムのドキュメントを参照してください。

2.5 インストールするソフトウェア・コンポーネント

表2-2に、このガイドの手順を開始する前に入手しておく必要のあるOracleソフトウェアを示します。

Oracle Fusion Middlewareソフトウェアのダウンロードの詳細は、Oracle Technology Network (OTN)のOracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルを参照してください。

『Oracle WebCenter Portalインストレーション・ガイド』も参照してください。

表2-2 コンポーネントおよびインストール・ソース

コンポーネント

配布メディア

Oracle Database 10gまたは11g

AL32UTF8文字セットを使用するOracle Database 10gディストリビューション(データベース10.2.0.4以降のSEまたはEEバージョン)

AL32UTF8文字セットを使用するOracle Database Server 11gディストリビューション(データベース11.1.0.7以降のSEまたはEEバージョン)

- WebCenter Portalエンタープライズ・デプロイメントでは、Oracle RACデータベースへの接続にGridLinkデータ・ソースを使用することをお薦めします。GridLinkでSCAN機能を使用するには、Oracle Database Server 11gR2 (Enterprise Edition, バージョン11.2以降)のOracle RACデータベース・バージョンを使用する必要があります。

Repository Creation Utility (RCU)

Oracle Fusion Middleware Repository Creation Utility 11g (11.1.1.9)ディストリビューション

Oracle WebLogic Server (WLS)

Oracle WebLogic Server (10.3.6)ディストリビューション

Oracle HTTP Server (OHS)

Oracle Fusion Middleware WebTier and Utilities 11g (11.1.1.7)ディストリビューション

Oracle SOA Suite

Oracle SOA Suite 11g (11.1.1.7)ディストリビューション

Oracle WebCenter Portal

Oracle WebCenter Portal 11g (11.1.1.9)のディストリビューション

Oracle WebCenter Content

Oracle WebCenter Content 11g (11.1.1.9)ディストリビューション

Oracle Access Manager (OAM) WebGate

WebGate 10g (10.1.4.3) for OAM 10gまたはWebGate 11g (11.1.1.7) for OAM 11g。

Oracle Virtual Directory (OVD)

Oracle Identity and Access Management 11g (11.1.2.0)ディストリビューション

Oracle Internet Directory (OID)

Oracle Identity and Access Management 11g (11.1.2.0)ディストリビューション

2.6 参照用トポロジのインストールおよび構成のロード・マップ

Oracle WebCenter Portalエンタープライズ・デプロイメントを開始する前に、図2-2のフロー・チャートを参照してください。このフロー・チャートは、このガイドで説明するエンタープライズ・デプロイメントを完成させるための大まかなプロセスを示しています。表2-3はこのフロー・チャート内の手順を説明するものであり、ここから各手順の項または章にジャンプできます。

この項の内容は次のとおりです。

- 第2.6.1項「Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスのフロー・チャート」

- 第2.6.2項「Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスの手順」

- 第2.6.3項「エンタープライズ・デプロイメントへのインクリメンタルなモジュラ・アプローチの理解」

2.6.1 Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスのフロー・チャート

図2-2に、Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスのフロー・チャートを示します。このチャートを確認し、既存の環境に基づいた実行手順を理解してください。

図2-2 Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスのフロー・チャート

2.6.2 Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスの手順

表2-3では、図2-2に示す、Oracle WebCenter Portalのエンタープライズ・デプロイメント・プロセスのフロー・チャートの各手順を示します。この表では、処理における各ステップの詳細について、その参照先も示します。

表2-3 Oracle WebCenter Portalエンタープライズ・デプロイメント・プロセスの手順

手順

説明

詳細

エンタープライズ・デプロイメント用のネットワークの準備

エンタープライズ・デプロイメント用のネットワークを準備するには、仮想サーバー名、IP、仮想IPSなどの概念を理解し、仮想ホスト名を定義してロード・バランサを構成する必要があります。

第3章「エンタープライズ・デプロイメント用のネットワークの準備」

エンタープライズ・デプロイメント用のファイル・システムの準備

エンタープライズ・デプロイメント用のファイル・システムを準備するには、ディレクトリおよびディレクトリ環境変数の用語を理解し、共有記憶域を構成する必要があります。

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」

エンタープライズ・デプロイメント用のデータベースの準備

エンタープライズ・デプロイメント用のデータベースを準備するには、データベース要件の確認、データベース・サービスの作成、Oracle RACデータベースへのメタデータ・リポジトリのロード、トランザクション・リカバリ権限用のSOA、WCPおよびWCCスキーマの構成ならびにデータベースのバックアップを実行します。

第5章「エンタープライズ・デプロイメント用のデータベースの準備」

エンタープライズ・デプロイメント用のソフトウェアのインストール

Oracle HTTP Server、Oracle WebLogic ServerおよびOracle Fusion Middlewareをインストールし、Oracle Fusion Middlewareコンポーネントにパッチ・セットを適用します。

第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」

エンタープライズ・デプロイメント用のWeb層の構成

ロード・バランサを使用してOracle HTTPサーバーを構成し、仮想ホスト名を構成します。

第7章「エンタープライズ・デプロイメント用のWeb層の構成」

エンタープライズ・デプロイメント用のドメインの作成

構成ウィザードを起動してドメインを作成します。

第8章「エンタープライズ・デプロイメント用のドメインの作成」

SOAのためのドメインの拡張

Oracle SOAコンポーネントを構成するために構成ウィザードを実行して既存のWebLogic Serverドメインを拡張します。

第9章「SOAコンポーネントを使用するためのドメインの拡張」

WebCenter Portalコンポーネントを使用するためのドメインの拡張

構成ウィザードを実行して既存のWebLogic Serverドメインを拡張し、Oracle WebCenter Portalを構成します。

第10章「WebCenter Portalコンポーネントを使用するためのドメインの拡張」

ノード・マネージャの設定

ホスト名検証を有効化し、ノード・マネージャを起動して、カスタム・キーストアを使用するようにWebLogic Serverを構成し、ノード・マネージャを設定します。

第11章「エンタープライズ・デプロイメント用のノード・マネージャの設定」

WebCenter Portalの外部サービスの構成

ディスカッション、メール、検索などのWebCenter Portalアプリケーションの外部サービスを設定および構成します。

第12章「エンタープライズ・デプロイメントにおけるWebCenter Portalの外部ツールおよびサービスの構成」

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

構成ウィザードを実行して既存のWebLogic Serverドメインを拡張し、コンテンツ・サーバーとInbound Refineryを構成します。

第13章「Oracle WebCenter Contentを追加するためのドメインの拡張」

サーバー移行の構成

WLS_SOA1およびWLS_SOA2管理対象サーバーのサーバー移行を構成します。WLS_SOA1管理対象サーバーは障害時にSOAHOST2で再起動するように構成されます。WLS_SOA2管理対象サーバーは障害時にSOAHOST1で再起動するように構成されます。

第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」

Oracle Identity Managementとの統合

Oracle SOAエンタープライズ・デプロイメントとOracle Identity Management 10gまたは11gを統合できます。

第15章「エンタープライズ・デプロイメントとOracle Identity Managementの統合」

2.6.3 エンタープライズ・デプロイメントへのインクリメンタルなモジュラ・アプローチの理解

このドキュメントではインクリメンタルなモジュラ・アプローチでエンタープライズ・デプロイメントの設定方法を説明しています。

記憶域、データベース、ネットワーキングおよびWeb層インフラストラクチャの設定手順は、その他のOracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドで説明している手順とほぼ同じです。これらのトポロジ要素は、この後の手順で構成するOracle WebLogic Serverドメインの基盤となるもので、このドメインがエンタープライズ・デプロイメントの土台となります。

ドメインの作成手順はガイドによって異なります。しかし、どのエンタープライズ・デプロイメント・ガイドでも、Oracle WebLogic Serverドメインの作成方法と拡張方法を次のようなモジュラの手順で説明しています。

1. Oracle Fusion Middlewareソフトウェアをディスクにインストールし、必要なバイナリ・ディレクトリを作成します。

2. Oracle Fusion Middleware構成ウィザードを実行してドメインを作成し、管理コンポーネントのみを構成します。
管理コンポーネントには、管理サーバー、Oracle WebLogic Server管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Web Services Managerが含まれます。

3. 構成ウィザードを再度実行し、使用する主なOracle Fusion Middleware製品を追加するためドメインを拡張します。

4. オプションで、構成ウィザードを再度実行して、その他のサポート・コンポーネントおよび製品を追加するためにドメイン拡張します。

このインクリメンタルなアプローチに従うことで、構成ウィザードの各ステップ後に環境を確認できます。また、セットアップ・プロセス中のトラブルシューティングが容易になります。

さらに、このモジュラ・アプローチでは代替トポロジの検討が可能になります。これは特に、管理コンポーネントの構成後、このガイドに記述されているコンポーネントをすべてドメインに含める必要がないことが判明したような場合です。この場合は、ドメイン拡張に関する章を個々に選択して参照し、組織で必要とされるコンポーネントを構成します。

3 エンタープライズ・デプロイメント用のネットワークの準備

この章では、WebCenter Portalエンタープライズ・デプロイメント・トポロジで必要なネットワーク環境の事前構成について説明します。この章を使用して、仮想サーバー名、ロード・バランサ、IPと仮想IP、ファイアウォールおよびポートの構成を計画してください。

この章の内容は次のとおりです。

- エンタープライズ・デプロイメント用のネットワークの準備の概要

- トポロジで使用する仮想サーバー名

- ロード・バランサの構成

- IPおよび仮想IPの構成

- エンタープライズ・デプロイメント用の仮想IPアドレスの有効化

- ファイアウォールおよびポートの構成

3.1 エンタープライズ・デプロイメント用のネットワークの準備の概要

様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらの仮想サーバーは、サービスを実行するために適切な実際のホストおよびポートに対して構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

3.2 トポロジで使用する仮想サーバー名

WebCenter Portalエンタープライズ・トポロジでは、次の仮想サーバー名を使用します。

- wcp.example.com

- admin.example.com

- wcpinternal.example.com

仮想サーバー名がIPアドレスと関連付けられており、DNSの一部になっていることを確認してください。Oracle Fusion Middlewareを実行するノードは、これらの仮想サーバー名を解決できるようになっている必要があります。

注意:
エンタープライズ・デプロイメントにMicrosoft Officeの統合またはMicrosoft SharePointサーバーへのアクセスが必要な場合は、仮想ホストの追加が必要です。詳細は、『Oracle WebCenter Portalの管理』の「Microsoft Office統合の管理」の章を参照してください。

第3.3項「ロード・バランサの構成」の手順に従って、ロード・バランサで仮想サーバー名を定義します。

注意:
クライアントがアクセスする唯一の仮想サーバーの名前は外部向けのwcp.example.comのURLです。その他のすべてのURLは、内部使用用です。第2.1.3.1項「ロード・バランサの要件」も参照してください。

3.2.1 wcp.example.com

wcp.example.comは、ランタイムOracle SOA SuiteおよびOracle WebCenter Portalコンポーネント(soa-infra、ワークフロー、WebCenter Portalアプリケーションなど)へのすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバーの名前です。SSLへのトラフィックが構成されます。クライアントはwcp.example.com:443のアドレスを使用してこのサービスにアクセスします。

この仮想サーバーは、ロード・バランサで定義されます。

3.2.2 admin.example.com

admin.example.comは、WebLogic管理サーバー・コンソールやOracle Enterprise Managerなどの管理サービスに転送されるすべての内部HTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。

クライアントからの入力トラフィックは、SSL対応ではありません。クライアントはadmin.example.com:80のアドレスを使用してこのサービスにアクセスし、リクエストはWEBHOST1とWEBHOST2のポート7777に転送されます。

この仮想サーバーは、ロード・バランサで定義されます。

3.2.3 wcpinternal.example.com

wcpinternal.example.comは、Oracle WebCenter Portalサービスの内部起動に使用される仮想サーバー名です。このURLはインターネットに公開されずに、イントラネットからのみアクセスできます。

クライアントからの入力トラフィックは、SSL対応ではありません。クライアントはwcpinternal.example.com:80のアドレスを使用してこのサービスにアクセスし、リクエストはWEBHOST1とWEBHOST2のポート7777に転送されます。

この仮想サーバーは、ロード・バランサで定義されます。

3.3 ロード・バランサの構成

ロード・バランサ上には、各種のネットワーク・トラフィックおよび監視用に、いくつかの仮想サーバーおよびそれらに関連付けられたポートを構成する必要があります。これらは、実際のホストおよびポートに対して適切に構成し、サービスが継続されるようにする必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

推奨トポロジ内には、2つのロード・バランサ・デバイスがあります。一方のロード・バランサは外部HTTPトラフィック用に設定し、もう一方のロード・バランサは内部LDAPトラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なDMZ間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。

このエンタープライズ・トポロジは外部のロード・バランサを使用します。第3.2項「トポロジで使用する仮想サーバー名」で説明する仮想サーバー名を定義して、ロード・バランサを構成します。

ロード・バランサの詳細は、第2.1.3項「Web層ノードについて」を参照してください。

3.3.1 ロード・バランサの要件

このエンタープライズ・デプロイメント・トポロジでは外部のロード・バランサを使用します。この外部ロード・バランサは次の機能を備えている必要があります。

- 仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。これにより、ロード・バランサは、プール内のサーバーに対するリクエストをロード・バランシングできます。

- ポート変換の構成。

- ポート(HTTPおよびHTTPS)の監視。

- 仮想サーバーとポートの構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。さらに、仮想サーバー名とポートは次の要件を満たしている必要があります。

- ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、Oracle WebLogic Serverクラスタの場合は、1つの仮想サーバーとHTTPおよびHTTPSの両トラフィック用のポートを指定してロード・バランサを構成する必要があります。

- 仮想サーバー名は、IPアドレスに関連付けられていて、DNSの一部であることが必要です。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。

- ノード障害を検出し、障害が発生したノードへのトラフィックのルーティングを即座に停止する機能。

- リソースの監視、ポートの監視およびプロセスの障害の検出: ロード・バランサは、通知などの方法を使用してサービスやノードの障害を検出し、障害が発生したノードへのOracle Net以外のトラフィックの送信を停止できる必要があります。ご使用の外部ロード・バランサに障害の自動検出機能がある場合、これを使用する必要があります。

- フォルト・トレラント・モード: ロード・バランサをフォルト・トレラント・モードに構成することを強くお薦めします。

- その他: トラフィックの転送先となるバックエンド・サービスが使用できない場合、コール元のクライアントに即座に戻るようにロード・バランサの仮想サーバーを構成することを強くお薦めします。これは、クライアント・マシンのTCP/IP設定に基づいてタイムアウト後にクライアント側で接続を切断するより望ましい方法です。

- SSLアクセラレーション: この機能は必須です。

- TCP接続の接続タイムアウトに大きい値を使用したディレクトリ層に対するロード・バランサでの1つ以上の仮想サーバーの構成。この値は、Oracle Access Managerとディレクトリ層の間でトラフィックがない場合に、その予想される最大時間より大きい必要があります。

- クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。

Oracle Technology Networkでは、検証されたロード・バランサの一覧とその構成をhttp://www.oracle.com/technetwork/middleware/ias/tested-lbr-fw-sslaccel-100648.htmlで提供しています。

3.3.2 ロード・バランサの構成手順

ロード・バランサの構成手順は、ロード・バランサのタイプにより異なります。実際の手順については、ベンダーが提供するマニュアルを参照してください。一般的な構成フローを次に示します。

1. サーバーのプールを作成します。このプールには、ロード・バランサの定義に含まれるサーバーのリストおよびポートが含まれます。

たとえば、Webホスト間のロード・バランシングでは、ポート7777上でホストWEBHOST1とWEBHOST2にリクエストを転送するサーバーのプールを作成します。

2. 特定のホストとサービスが利用可能かどうかを判別するルールを作成し、手順1で作成したサーバーのプールに割り当てます。

3. ロード・バランサ上に仮想サーバーを作成します。
これは、アプリケーションにより使用されるリクエストを受信するアドレスとポートです。たとえば、Web層リクエストをロード・バランシングするには、wcp.example.com:443の仮想ホストを作成します。

注意:
第3.2項「トポロジで使用する仮想サーバー名」も参照してください。

4. ロード・バランサでサポートされている場合は、仮想サーバーが内部から、外部から、またはその両方から利用できるのかどうかを指定します。内部アドレスはネットワーク内からのみ解決可能であることを確認します。

5. 適用可能な場合は、仮想サーバーに対するSSL終端を構成します。

6. 手順1で作成したサーバーのプールを仮想サーバーに割り当てます。

7. 表3-4に従って、タイムアウト設定を調整します。これには、サービスが停止しているかどうかを検出する時間も含まれます。

8. Oracle HTTP Serverノードを監視してノードの障害を検出するように構成します。

- 「/」のURLコンテキストに定期的にpingを実行するように監視を設定します。

ヒント:
Oracle HTTP Serverのドキュメント・ルートにindex.htmが存在せずにOracle WebLogic Serverで「/」の404エラーが返される場合は、かわりにGET /\n\nを使用してください。

- ping実行間隔については、システムに負荷を与えないように値を指定します。とりあえず5秒で試してみることができます。

- タイムアウト時間については、使用するOracle WebCenter Portalシステムで予測できる最長レスポンス時間に相当する値を指定します(つまり、HTTPサーバーへのリクエストに必要な最長所要時間より大きな値を指定します)。

9. (オプション)Oracle WebCenter Contentを使用している場合は、ロード・バランサのWebCenter Contentソケット(ポート4444)を構成する必要があります。詳細は、第13.4項「WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成」を参照してください。

3.3.2.1 ロード・バランサの構成

WebCenter Portalエンタープライズ・デプロイメントでは、表3-1に示すようにロード・バランサを構成します。

表3-1 ロード・バランサの構成

仮想ホスト

サーバー・プール

プロトコル

SSL終端

外部

必要なその他の構成/コメント

admin.example.com:80

WEBHOST1.example.com:7777

WEBHOST2.example.com:7777

HTTP

いいえ

いいえ

- 内部管理アドレスを仮想サーバーのアドレスとして使用します(たとえば、admin.example.com)。

- HTTPをプロトコルとして指定します。

- アドレスとポートの変換を有効にします。

- サービスやノードが停止した場合に接続のリセットを有効にします。

- ステップ1で作成したプールを仮想サーバーに割り当てます。

- 必要に応じて、この仮想サーバーの/consoleと/emのみへのアクセスを許可するルールを作成します。

wcp.example.com:443

WEBHOST1.example.com:7777 WEBHOST2.example.com:7777

HTTP

いいえ

はい

- システムのフロントエンド・アドレスを仮想サーバーのアドレスとして使用します(たとえば、wcp.example.com)。フロントエンド・アドレスは、システムで使用され外部に公開されているホスト名であり、インターネットに公開されます。

- ポート80とポート443を使用します。ポート80(非SSLプロトコル)に着信するリクエストはすべて、ポート443 (SSLプロトコル)にリダイレクトされる必要があります。

- HTTPをプロトコルとして指定します。

- アドレスとポートの変換を有効にします。

- サービスやノードが停止した場合に接続のリセットを有効にします。

- ステップ1で作成したプールを仮想サーバーに割り当てます。

- この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

wcpinternal.example.com:80

WEBHOST1.example.com:7777 WEBHOST2.example.com:7777

HTTP

いいえ

いいえ

- 内部管理アドレスを仮想サーバーのアドレスとして使用します(たとえば、wcpinternal.example.com)。このアドレスは一般的に外部化されません。

- HTTPをプロトコルとして指定します。

- アドレスとポートの変換を有効にします。

- サービスやノードが停止した場合に接続のリセットを有効にします。

- ステップ1で作成したプールを仮想サーバーに割り当てます。

- 必要に応じて、この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

3.4 IPおよび仮想IPの構成

図3-1に示すように、異なる仮想IPと物理IPでリスニングするように、管理サーバーと管理対象サーバーを構成してください。図に示すように、各VIPとIPは、使用するWebLogic Serverに割り当てられます。VIP1に障害が発生すると、手動で管理サーバーがSOAHOST2で再起動します。Oracle WebLogic Serverの移行機能により、VIP2とVIP3がそれぞれ、SOAHOST1からSOAHOST2にフェイルオーバーし、SOAHOST2からSOAHOST1にフェイルオーバーします。WebLogic Serverの移行機能の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

物理IP(仮想IPでない)が各ノードに固定的に割り当てられます。

IP1はSOAHOST1の物理IPで、WLS_WSM1 Webサービス・ポリシー・マネージャのサーバーで使用されます。

IP2はSOAHOST2の物理IPで、WLS_WSM2 WebServicesポリシー・マネージャのサーバーで使用されます。

IP3はWCPHOST1の物理IPであり、すべてのWebCenter Portalサーバー(WC_Spaces1、WC_Portlets1、WC_Collaboration1、WC_Utilities1およびClusterInst1)で使用されます。

IP4はWCPHOST2の物理IPであり、すべてのWebCenter Portalサーバー(WC_Spaces2、WC_Portlets2、WC_Collaboration2、WC_Utilities2およびClusterInst2)によって使用されます。

図3-1 管理サーバーと管理対象サーバーにマップされるVIPとIP

表3-2には、様々な仮想ホストの説明が記載されています。

表3-2 仮想ホスト

仮想IP

VIPのマップ先

説明

VIP1

ADMINVHN

ADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名であり、管理サーバーの手動フェイルオーバーによりフェイルオーバーします。これは、管理サーバーのプロセスが実行されているノード(デフォルトはSOAHOST1)で有効にされます。

VIP2

SOAHOST1VHN1

SOAHOST1VHN1は、WLS_SOA1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA1プロセスが実行されているノード(デフォルトはSOAHOST1)で有効化されます。

VIP3

SOAHOST2VHN1

SOAHOST2VHN1は、WLS_SOA2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA2プロセスが実行されているノード(デフォルトはSOAHOST2)で有効化されます。

3.5 エンタープライズ・デプロイメント用の仮想IPアドレスの有効化

この手順は、他のOracle Fusion Middlewareコンポーネントを後でインストールするかしないかに関係なく、WebLogic Server管理サーバーのフェイルオーバーを行うために必要です。

管理サーバーを仮想IPアドレスに関連付けます。これにより、プライマリ・ホストで障害が発生した場合に別のホスト上で管理サーバーを起動することが可能になります。

表3-3に示すように仮想ホストが有効になっていることを確認します。

表3-3 仮想ホスト

VIP

有効化されるホスト

ADMINVHN.example.com

SOAHOST1

SOAHOST1VHN1.example.com

SOAHOST1

SOAHOST2VHN1.example.com

SOAHOST2

注意:
これは、浮動IPアドレスに関連付けられているDNS名です。これは、ロード・バランサ上で構成される仮想ホストのDNS名ではありません。

UNIXの場合

1. rootとしてifconfigコマンドを実行します。

/sbin/ifconfig interface:index IPAddress netmask netmask
/sbin/arping -q -U -c 3 -I interface IPAddress

ここでinterfaceはeth0またはeth1であり、indexは0、1または2です。

例:

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

2. 次の例のように、ネットワークで仮想IPの新しい場所を登録できるようにします。

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

3. 別のノードからこのアドレスをpingして、このアドレスが使用可能であることを検証します。次の例を示します。

/bin/ping 100.200.140.206

この例で、ethXはイーサネット・インタフェース(eth0またはeth1)、Yはインデックス(0、1、2)です。

Windowsの場合

1. 次のコマンドを実行します。

netsh interface ip add address interface IP_Address netmask

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。

次の例では、IPアドレスはインタフェースLocal Area Connection上で有効になります。

netsh interface ip add address "Local Area connection" 100.200.140.206 255.255.255.0

3.6 ファイアウォールおよびポートの構成

多くのOracle Fusion Middlewareコンポーネントおよびサービスはポートを使用します。管理者は、これらのサービスが使用するポート番号を把握し、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにする必要があります。

ほとんどのポート番号はインストール中に割り当てられます。

表3-4に、トポロジのファイアウォールで開く必要のあるポートを含むWebCenter Portalトポロジで使用されるポートの一覧を示します。

ファイアウォール表記法:

- FW0は外側のファイアウォールを示します。

- FW1は、Web層とアプリケーション層との間におけるファイアウォールを示します。

- FW2は、アプリケーション層とデータ層との間におけるファイアウォールを示します。

注意:
ファイアウォール・ポートはTCP/IPポートの定義によって異なります。

表3-4 使用されるポート

タイプ

ファイアウォール

ポートとポート範囲

プロトコル/アプリケーション

インバウンド/アウトバウンド

その他の考慮事項とタイムアウトのガイドライン

ブラウザによるリクエスト

FW0

80

HTTP/ロード・バランサ

インバウンド

タイムアウトは、WebCenter Portalによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

ブラウザによるリクエスト

FW0

443

HTTPS/ロード・バランサ

インバウンド

タイムアウトは、WebCenter Portalによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

ブラウザによるリクエスト

FW1

80

HTTPS/ロード・バランサ

アウトバウンド(イントラネット・クライアントの場合)

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

ブラウザによるリクエスト

FW1

443

HTTPS/ロード・バランサ

アウトバウンド(イントラネット・クライアントの場合)

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

コールバックおよびアウトバウンド起動

FW1

80

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

コールバックおよびアウトバウンド起動

FW1

443

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、SOAによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

Oracle HTTP Serverへのロード・バランサ

該当なし

7777

HTTP

該当なし

第3.3項「ロード・バランサの構成」を参照してください。

管理サーバーによるOHS登録

FW1

7001

HTTP/t3

インバウンド

タイムアウトを短い時間(5から10秒)に設定します。

管理サーバーによるOHS管理

FW1

OPMNポート(6701)とOHS管理ポート(7779)

それぞれTCPとHTTP

アウトバウンド

タイムアウトを短い時間(5から10秒)に設定します。

WSM-PMのアクセス

FW1

7010

範囲: 7010から7999

HTTP/WLS_WSM-PMn

インバウンド

タイムアウトを60秒に設定します。

複数のWSMクラスタ・メンバー間における通信

該当なし

7010

TCP/IPユニキャスト

該当なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

Spaces_Clusterメンバー間の通信

該当なし

9000

TCP/IPユニキャスト

該当なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

Portlet_Clusterメンバー間の通信

該当なし

9001

TCP/IPユニキャスト

該当なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

Collab_Clusterメンバー間の通信

該当なし

9002

TCP/IPユニキャスト

該当なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

Utilities_Clusterメンバー間の通信

該当なし

9003

TCP/IPユニキャスト

該当なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

WebCenter Contentアクセス

FW1

16200

HTTP / WLS_WCCn

インバウンド

ブラウザ・ベースでアクセスします。セッション・タイムアウトを構成します。

WCC_Clusterメンバー間の通信

該当なし

16200

TCP/IPユニキャスト

該当なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

WebLogic Serverクラスタ内におけるセッション・レプリケーション

該当なし

該当なし

該当なし

該当なし

該当なし

管理コンソールのアクセス

FW1

7001

HTTP/管理サーバーとEnterprise Manager

t3

両方

管理コンソールへのアクセスのタイプ(アプリケーション層のクライアントからOracle WebLogic Server管理コンソールを使用する予定があるか、またはアプリケーション層の外部のクライアントから使用する予定があるか)に基づいてこのタイムアウト時間をチューニングする必要があります。

ノード・マネージャ

該当なし

5556

TCP/IP

該当なし

該当なし

実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールおよびポートに関する項を参照してください。

アクセス・サーバーのアクセス

FW1

6021 (OAM 10g)

5575 (OAM 11g)

OAP

インバウンド

実際の値は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のファイアウォールおよびポートに関する項を参照してください。

アイデンティティ・サーバーのアクセス

FW1

6022

OAP

インバウンド

データベースのアクセス

FW2

1521

SQL*Net

両方

タイムアウトは、WebCenter Portalによって使用されるプロセス・モデルのタイプとすべてのデータベース・コンテンツによって異なります。

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

Gridlink用に必要。各データベース・サーバー上でONSサーバーが実行されます。

Oracle Internet Directoryのアクセス

FW2

389

LDAP

インバウンド

ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。

Oracle Internet Directoryのアクセス

FW2

636

LDAP SSL

インバウンド

ロード・バランサに基づいてディレクトリ・サーバーのパラメータをチューニングする必要があります。それ以外の方法ではチューニングしないでください。

WebCenterコンテンツ・サーバーへのWebCenter Portalのアクセス

FW2

4444

TCP/IPソケット

該当なし

永続的に接続されます。タイムアウトは構成可能です。

Inbound RefineryへのWebCenter Portalのアクセス

FW2

5555

TCP/IPソケット

該当なし

該当なし

OWSM用JOC

該当なし

9991

TCP/IP

該当なし

該当なし

デプロイメントの一貫性

該当なし

8088

範囲: 8000から8090

該当なし

該当なし

4 エンタープライズ・デプロイメント用のファイル・システムの準備

この章では、Oracle WebCenter Portalエンタープライズ・デプロイメント用のファイル・システムの準備方法について説明します。推奨されるディレクトリ構造とその場所に関する情報を示し、共有記憶域の構成手順も説明します。

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

- エンタープライズ・デプロイメント用のファイル・システムの準備の概要

- ディレクトリおよびディレクトリ環境変数の用語

- 異なるディレクトリの推奨場所

- 共有記憶域の構成

4.1 エンタープライズ・デプロイメント用のファイル・システムの準備の概要

ファイル・システムの設定では、構成と管理が容易でわかりやすいエンタープライズ・デプロイメントを作成できるようにすることが重要です。この章の情報に従ってファイル・システムを設定することをお薦めします。この章で定義されている用語は、このガイド内のダイアグラムおよび手順で使用されます。

この章を参照情報として使用すると、インストールおよび構成手順で使用されているディレクトリ変数について理解できます。その他のディレクトリ・レイアウトも可能であり、サポートされていますが、このマニュアルで採用するモデルは、可用性を最大化するために選択されており、コンポーネントの最良の独立性と構成の対称性の両方を実現し、バックアップおよび災害からのリカバリを容易にします。ドキュメントの残りの部分では、このディレクトリ構造およびディレクトリ用語を使用します。

4.2 ディレクトリとディレクトリ環境変数の用語

この項では、Oracle WebCenter Portalエンタープライズ・デプロイメントを構成するためにこのガイドで使用されるディレクトリ環境変数について説明します。このガイドでは、インストールして構成するディレクトリを次のディレクトリ変数を使用して説明しています。

- ORACLE_BASE: この環境変数と関連ディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指しています。

- MW_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが常駐している場所を指します。

- WL_HOME: この環境変数と関連ディレクトリ・パスには、WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。

- ORACLE_HOME: この環境変数と関連ディレクトリ・パスは、Oracle SOA SuiteまたはOracle WebCenter Portalがインストールされている場所を指します。

- ORACLE_COMMON_HOME: この環境変数と関連ディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files (JRF)に必要なバイナリ・ファイルとライブラリ・ファイルを含むOracleホームを参照しています。

- DOMAIN Directory: このディレクトリ・パスは、Oracle WebLogic Serverドメイン情報(構成アーティファクト)が格納されている場所を指しています。後述のように同じノード内にある場合でも、個々のOracle WebLogicサーバーで異なるドメイン・ディレクトリを使用できます。

- ORACLE_INSTANCE: Oracleインスタンスには、1つ以上のシステム・コンポーネントがあります。コンポーネントの例には、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどがあります。Oracleインスタンスのディレクトリには、更新可能なファイルがあります。それらのファイルの例には、構成ファイル、ログ・ファイル、一時ファイルなどがあります。

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

- ASERVER_HOME: ドメイン構成のプライマリの場所です。典型的な例は、/u01/oracle/config/domains/domain_nameです。

- MSERVER_HOME: 管理対象サーバーの起動と停止に使用されるドメイン構成のコピーです。典型的な例は、/u02/private/oracle/config/domains/domain_nameです。

- WEBGATE_ORACLE_HOME: WebGateがインストールされている場所です。

ヒント:
この項で説明している場所には、ショートカットとして環境変数を使用し、ディレクトリに簡単に移動できます。たとえば、Linuxでは$ORACLE_BASEという環境変数を使用し、/u01/app/oracle(つまり、推奨されるORACLE_BASEの場所)を参照できます。Windowsでは、%ORACLE_BASE%とWindowsに固有のコマンドを使用できます。

4.3 異なるディレクトリの推奨場所

次の各項では、エンタープライズ・デプロイメント・トポロジに対して共有記憶域を使用する場合の基本的な推奨事項を紹介します。

- バイナリ(Oracleホーム)ディレクトリに対する共有記憶域に関する推奨事項

- ドメイン構成ファイルに対する共有記憶域に関する推奨事項

- JMSファイル・ストアおよびトランザクション・ログに対する共有記憶域に関する推奨事項

- ディレクトリの推奨場所

- ディレクトリ構造と構成

4.3.1 バイナリ(Oracleホーム)ディレクトリに対する共有記憶域に関する推奨事項

次の各項では、Oracle Fusion MiddlewareのOracleホーム・ディレクトリに対して共有記憶域を使用する場合のガイドラインについて説明します。

- バイナリ(Oracleホーム)ディレクトリについて

- 複数のドメインでの単一のOracleホームの共有について

- 冗長バイナリ(Oracleホーム)ディレクトリの使用について

4.3.1.1 バイナリ(Oracleホーム)ディレクトリについて

Oracle Fusion Middleware製品をインストールする際には、製品のバイナリをOracleホームにインストールします。Oracleホーム・ディレクトリにインストールされたバイナリ・ファイルは読取り専用であり、Oracleホームにパッチが適用されるか新しいバージョンにアップグレードされるまで変更されることはありません。

標準的な本番環境では、Oracleホーム・ファイルは、Oracle Fusion Middleware構成ウィザードを使用して作成するドメイン構成ファイルとは別の場所に保存します。

Oracle Fusion Middlewareのインストールに対するMiddlewareホームには、Oracle WebLogic Serverのバイナリ、Oracle Fusion Middlewareのインフラストラクチャ・ファイルおよびOracle Fusion Middleware製品固有のディレクトリが含まれます。

Oracle Fusion MiddlewareのOracleホームの構造および内容の詳細は、概念を参照してください。

4.3.1.2 複数のドメインでの単一のOracleホームの共有について

Oracle Fusion Middlewareでは、単一のOracleホームから複数のOracle WebLogic Serverドメインを構成できます。このため、Oracleホームを共有ボリューム上の1つの場所にインストールし、複数のホスト・インストールでOracleホームを再利用することが可能です。

注意:
共有記憶域に配置できないOracle WebCenter ContentおよびOracle WebCenter Content: Inbound Refineryの管理対象サーバーを除き、管理対象サーバーのドメイン・ディレクトリは、ローカルまたは共有記憶域に配置できます。これらの管理対象サーバーは、ノード固有のファイル(intradoc.cfgなど)を使用します。

Oracleホームが異なるホスト上の複数のサーバーにより共有されている場合、留意するべきいくつかのベスト・プラクティスがあります。具体的には、各ホスト上のOracleインベントリ(oraInventory)が、整合性を保ち、パッチを適用するために更新されていることを確認します。

ホストに対するoraInventoryを更新し、Oracleホームを共有記憶域にアタッチするには、次のコマンドを使用します。

ORACLE_HOME/oui/bin/attachHome.sh

oraInventoryの詳細は、『Oracle Universal InstallerおよびOpatchユーザーズ・ガイド for Microsoft Windows and UNIX Systems』のOracle Universal Installerインベントリに関する項を参照してください。

4.3.1.3 冗長バイナリ(Oracleホーム)ディレクトリの使用について

可用性が最大になるように、共有記憶域ではバイナリの冗長インストールを使用することをお薦めします。

このモデルでは、Oracle Fusion Middlewareソフトウェアに対する同一のOracleホームを2つの異なる共有ボリューム上にインストールします。1つのOracleホームを1つのサーバーのセットにマウントし、もう一方のOracleホームを残りのサーバーにマウントします。各Oracleホームは同じマウント・ポイントを持つため、サーバーがどのOracleホームを使用しているかにかかわらず、Oracleホームのパスは常に同じになります。

いずれかのOracleホームが破損するか利用できなくなっても、サーバーの半数しか影響を受けません。さらに保護を強化するために、これらのボリュームのディスク・ミラーを行うことをお薦めします。

共有記憶域上の別々のボリュームを使用できない場合は、同じボリューム内の異なるディレクトリを使用して別々のボリュームをシミュレートし、ホスト側でこれらのボリュームを同じマウント位置にマウントすることをお薦めします。これによって複数ボリュームが提供するような保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護は可能になります。

4.3.2 ドメイン構成ファイルに対する共有記憶域に関する推奨事項

次の各項では、Oracle Fusion Middleware製品をエンタープライズ・デプロイメントで構成する場合に作成するOracle WebLogic Serverのドメイン構成ファイルに対して共有記憶域を使用する場合のガイドラインについて説明します。

- Oracle WebLogic Serverの管理サーバーと管理対象サーバーのドメイン構成ファイルについて

- 管理サーバーと管理対象サーバーのドメイン構成ファイルの共有記憶域要件

4.3.2.1 Oracle WebLogic Serverの管理サーバーと管理対象サーバーのドメイン構成ファイルについて

Oracle Fusion Middleware製品の構成時には、Oracle WebLogic Serverドメインを作成または拡張します。各Oracle WebLogic Serverドメインは、1つの管理サーバーおよび1つ以上の管理対象サーバーで構成されます。

Oracle WebLogic Serverドメインの詳細は、Oracle WebLogic Serverのドメイン構成の理解に関する項を参照してください。

エンタープライズ・デプロイメントでは、ドメインの管理対象サーバーがアクティブ/アクティブ型の高可用性のために構成される場合があることを理解しておく必要があります。ただし、管理サーバーはこのように構成できません。管理サーバーはシングルトン・サービスです。つまり、一度に1つのホストでのみアクティブにすることができます。

4.3.2.2 管理サーバーと管理対象サーバーのドメイン構成ファイルの共有記憶域要件

ドメイン構成ファイルのコピーを2つ作成することをお薦めします。

- 1つは管理サーバーの構成ファイル用のコピーです。
このディレクトリは共有記憶域上にインストールし、管理サーバーを実行しているホストに排他的にマウントします。

ホストで障害が発生した場合に、このディレクトリを別のホストにマウントし、そのホストで管理サーバーを起動できます。

- もう一方のコピーは管理対象サーバーの構成ファイル用です。
管理対象サーバーのドメイン・ディレクトリは、ローカルの記憶域にも共有記憶域にも配置できます。

管理対象サーバーがドメイン・ディレクトリを共有すると、スケール・アウト手順が容易になります。ただし、管理対象サーバーの構成ファイルを共有すると、パフォーマンスに影響する可能性もあります。

したがって、ストレージ・システムの要件があれば、使用するデプロイメントではその要件に応じて決定する必要があります。ストレージ・システムによっては、複数のマシンが同じ共有ボリュームをマウントするための構成オプションが提供されているものもあります。

このエンタープライズ・デプロイメント・トポロジで用意されている構成手順では、管理対象サーバーごとに各ノードのローカル・ドメイン・ディレクトリが使用されると想定しています。

4.3.3 JMSファイル・ストアおよびトランザクション・ログに対する共有記憶域に関する推奨事項

サーバーの障害や移行の場合にリカバリで複数のホストを利用可能にするには、JMSファイル・ストアとJTAトランザクション・ログは共有記憶域に配置する必要があります。

ファイル・ストア内のJMSおよびJTA情報の使用方法の詳細は、Oracle WebLogic Serverサーバー環境の構成のWebLogic永続ストアの使用方法に関する項を参照してください。

4.3.4 ディレクトリの推奨場所

この項では、推奨されるディレクトリについて説明します。共有記憶域の場所が直接指定されている場合は必ず、そのディレクトリでは共有記憶域が必要とされることを意味します。ローカル・ディスクが使用されたり共有記憶域がオプションの場合、マウント指定では「共有記憶域を使用している場合」の語句で修飾されます。共有記憶域の場所は例であり、指定されたマウント・ポイントが使用されているかぎり変更できます。ただし、共有記憶域デバイスでは整合性と単純化のためこの構造をお薦めします。

ORACLE_BASE:

推奨ディレクトリ: /u01/app/oracle

管理サーバー・ドメイン・ディレクトリのドメイン・ディレクトリ:

ORACLE_BASE/admin/domain_name/aserver/domain_name (最後のdomain_nameディレクトリは、構成ウィザードにより追加されます。)

- マシンのマウント・ポイント: ORACLE_BASE/admin/domain_name/aserver

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/aserver

- マウント元: このディレクトリをマウントする必要があるのは、管理サーバーが稼働しているノードのみです。管理サーバーが別のノードに再配置(フェイルオーバー)されたら、そのノードが同じマウント・ポイントで同じ共有記憶域をマウントします。トポロジ内の残りのノードがこの場所をマウントする必要はありません。

管理対象サーバー・ドメイン・ディレクトリのドメイン・ディレクトリ:

ORACLE_BASE/admin/domain_name/mserver/domain_name

- 共有ディスクを使用している場合、このマシンのマウント・ポイントは、ORACLE_BASE/admin /domain_name/Noden/mserver/にマウントされたORACLE_BASE/admin/domain_name/mserverになります(各ノードでは管理対象サーバー用に異なるドメイン・ディレクトリが使用されます)。

注意:
この手順は実際、共有記憶域によって異なります。前述の例はNASに特有でありますが、他の記憶域タイプでは別のタイプのマッピングによりこの冗長性が実現される場合があります。

JMSファイルベース・ストアとTlogs用の場所(SOAのみ):

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

- マウント・ポイント: ORACLE_BASE/admin/domain_name/soa_cluster_name/

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/soa_cluster_name/

- マウント元: Oracle SOA Suiteが稼働するすべてのノードでは、別のノードへのサーバー移行が発生したときにトランザクション・ログおよびJMSストアを使用できるように、この共有記憶域の場所をマウントする必要があります。

管理サーバーのアプリケーション・ディレクトリの場所

ORACLE_BASE/admin/domain_name/aserver/applications

- マウント・ポイント: ORACLE_BASE/admin/domain_name/aserver/

- 共有記憶域の場所: ORACLE_BASE/admin/domain_name/aserver

- マウント元: このディレクトリをマウントする必要があるのは、管理サーバーが稼働しているノードのみです。管理サーバーが別のノードに再配置(フェイルオーバー)されたら、そのノードが同じマウント・ポイントで同じ共有記憶域をマウントします。トポロジ内の残りのノードがこの場所をマウントする必要はありません。

管理対象サーバーのアプリケーション・ディレクトリの場所

ORACLE_BASE/admin/domain_name/mserver/applications

注意:
このディレクトリは、WebCenter Portalエンタープライズ・デプロイメントではローカルになります。

MW_HOME (アプリケーション層)

推奨ディレクトリ: ORACLE_BASE/product/fmw

- マウント・ポイント: ORACLE_BASE/product/fmw

- 共有記憶域の場所: ORACLE_BASE/product/fmw (VOL1とVOL2)

注意:
共有記憶域に利用できるボリュームが1つしかない場合に、誤ってファイルを削除しないように、あるいはパッチを適用できるように、別のディレクトリを使用して冗長に構成することができます。2つのMW_HOMEを使用できます。その場所は、少なくとも1つはORACLE_BASE/product/fmw1、もう一方はORACLE_BASE/product/fmw2とします。これらのMW_HOMEは、すべてのノードで同じマウント・ポイントにマウントされます。

- マウント元: 少なくとも半分のノードで一方のインストールを使用し、もう半分で他方のインストールを使用できるように、ノードではVOL1とVOL2を互換的にマウントします。
WebCenter Portalエンタープライズ・デプロイメント・トポロジでは、SOAHOST1とWCPHOST1は、VOL1をマウントし、SOAHOST2とWCPHOST2はVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域において、考えられる2つのディレクトリを互換的にマウントします。たとえば、SOAHOST1ではORACLE_BASE/product/fmw1、SOAHOST2ではORACLE_BASE/product/fmw2を、それぞれ共有記憶域の場所として使用します。

ORACLE_HOME (Web層):

推奨ディレクトリ: ORACLE_BASE/product/fmw/web

- マウント・ポイント: ORACLE_BASE/product/fmw

- 共有記憶域の場所: ORACLE_BASE/product/fmw (VOL1とVOL2)

注意:
Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用する場合は、層を横断する記憶域デバイスへのアクセスには、適切なセキュリティ制限をかけることを検討してください。
このエンタープライズ・デプロイメント・ガイドでは、Oracle Web Tierがローカル・ディスクにインストールされると想定しています。Oracle Web Tierのバイナリ(およびORACLE_INSTANCE)を共有ディスクにインストールすることもできます。その場合は、共有ディスクがアプリケーション層に使用されるものとは別になっている必要があります。

- マウント元: 共有記憶域のインストールでは、少なくとも半分のノードで一方のインストールを使用し、もう半分で他方のインストールを使用できるように、ノードではVOL1とVOL2を互換的にマウントします。
WebCenter Portalエンタープライズ・デプロイメント・トポロジでは、WEBHOST1は、VOL1をマウントし、WEBHOST2はVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域において、考えられる2つのディレクトリを互換的にマウントします。たとえば、WEBHOST1ではORACLE_BASE/product/fmw1、WEBHOST2ではORACLE_BASE/product/fmw2をそれぞれ共有記憶域の場所として使用します。

WL_HOME:

推奨ディレクトリ: MW_HOME/wlserver_10.3

ORACLE_HOME:

推奨ディレクトリ

- MW_HOME/wc (WebCenter PortalのOracleホーム)

- MW_HOME/soa (SOA SuiteのOracleホーム)

- MW_HOME/wcc (Oracle WebCenter ContentのOracleホーム)

ORACLE_COMMON_HOME:

推奨ディレクトリ: MW_HOME/oracle_common

ORACLE_INSTANCE (OHSインスタンス):

推奨ディレクトリ: ORACLE_BASE/admin/instance_name

- 共有ディスクを使用する場合、マシンのマウント・ポイントは次のとおりです。

ORACLE_BASE/admin/instance_name

マウント先:

ORACLE_BASE/admin/instance_name (VOL1)

注意:
(VOL1)はオプションです。(VOL2)も使用できます。

4.3.5 ディレクトリ構造と構成

この項では、推奨されるディレクトリ構造および共有記憶域の理解に役立つダイアグラムを示します。

図4-1は、このディレクトリ構造を示した図です。

図4-1 ディレクトリ構造

図4-1のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-1は、図において様々な色で識別されている要素の意味に関する説明が記載されています。

表4-1 ディレクトリ構造の要素

要素

説明

管理サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体は共有記憶域上に配置されます。

管理対象サーバー・ドメインのディレクトリは、ローカル・ディスクまたは共有ディレクトリに配置できます。また、管理対象サーバー・ドメインのディレクトリを複数のノード上で共有する場合、ノード間で同じ共有ディスクの場所をマウントする必要があります。Web層のinstance_nameディレクトリは、ローカル・ディスクまたは共有ディスクに配置できます。

固定名です。

インストール依存名です。

図4-2は、WebCenter Portal用に複数のボリュームを持つ共有記憶域の構成例を示しています。この例では、SOAHOST1とSOAHOST2を示しています。さらに、WCPHOST1とWCPHOST2上の管理対象サーバーのディレクトリが、VOL1とVOL2に示されています。

図4-2 共有記憶域の構成例

表4-2は、ドメインのディレクトリ構造をまとめたものです。この表の各項目は、次のとおりです。

- WLS_WCPは、WC_Spaces、WC_Portlet、WC_Utilities、WC_CollaborationのすべてのWebCenter Portal管理対象サーバーです。

- WLS_WCCは、WebCenter Content管理対象サーバーです。

- WLS_IBRは、Inbound Refinery管理対象サーバーです。

表4-2 共有記憶域の内容

サーバー

データのタイプ

共有記憶域のボリューム

ディレクトリ

ファイル

WLS_SOA1

Txログ

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々です。

WLS_SOA2

Txログ

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々です。

WLS_SOA1

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々です。たとえば、SOAJMSStore1やUMSJMSStore1などです。

WLS_SOA2

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々です。たとえば、SOAJMSStore2やUMSJMSStore2などです。

WLS_SOA1

WLSインストール

VOL1

MW_HOME

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA2

WLSインストール

VOL2

MW_HOME

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP1

WLSインストール

VOL1

MW_HOME

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP2

WLSインストール

VOL2

MW_HOME

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA1

SOAインストール

VOL1

MW_HOME/soa

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA2

SOAインストール

VOL2

MW_HOME/soa

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP1

WebCenter Portalインストール

VOL1

MW_HOME/wc

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP2

WebCenter Portalインストール

VOL2

MW_HOME/wc

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCC1

WebCenter Contentインストール

VOL1

MW_HOME/wcc

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCC2

WebCenter Contentインストール

VOL2

MW_HOME/wcc

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA1

ドメイン構成

VOL1

ORACLE_BASE/admin/domain_name/aserver/domain_name

管理サーバーを実行している1つのサーバーのみで使用されます。

WLS_SOA1

ドメイン構成

VOL1

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA2

ドメイン構成

VOL2

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP1

ドメイン構成

VOL1

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP2

ドメイン構成

VOL2

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCC1

Webファイルおよびボールト・ファイル

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/vault

個別ボリューム上のvaultファイルのディレクトリで、ロックが無効になっています。

WLS_WCC1

Webファイルおよびボールト・ファイル

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/weblayout

個別ボリューム上のweblayoutファイルのディレクトリで、ロックが無効になっています。

WLS_WCC2

Webファイルおよびボールト・ファイル

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/vault

個別ボリューム上のvaultファイルのディレクトリで、ロックが無効になっています。

WLS_WCC2

Webファイルおよびボールト・ファイル

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/weblayout

個別ボリューム上のweblayoutファイルのディレクトリで、ロックが無効になっています。

WLS_IBR1

Inbound Refineryファイル

VOL3

ORACLE_BASE/admin/domain_name/ibr_servers_name/ibr1

個別ボリューム上のInbound Refineryファイルのディレクトリで、ロックが無効になっています。

WLS_IBR2

Inbound Refineryファイル

VOL3

ORACLE_BASE/admin/domain_name/ibr_servers_name/ibr2

個別ボリューム上のInbound Refineryファイルのディレクトリで、ロックが無効になっています。

注意:
VOL3は、NFSのロック無効化ボリュームとしてマウントされます。詳細は、第4.4項「共有記憶域の構成」を参照してください。

4.4 共有記憶域の構成

SOAHOST1、SOAHOST2、WCPHOST1、WCPHOST2が2つの別々のボリュームのバイナリ・インストール用に同じ場所を参照できるように、次のコマンドを使用して、共有記憶域の場所を作成しマウントします。

注意:
共有記憶域のファイル・システムの作成に使用されるユーザーIDは、これらのファイルに対する読取り、書込みおよび実行権限を持ちます。オペレーティング・システム・グループにおける他のユーザーは、ファイルの読取りや実行は可能ですが、書込み権限はありません。インストールと構成の権限に関する詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストールと構成の権限とユーザーの理解に関する項を参照してください。

コマンドでnasfilerは共有記憶域ファイラです。

SOAHOST1とWCPHOST1から:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw ORACLE_BASE/product/fmw -t nfs

SOAHOST2とWCPHOST2から:

mount nasfiler:/vol/vol2/ORACLE_BASE/product/fmw ORACLE_BASE/product/fmw -t nfs

注意:

利用できるボリュームが1つのみの場合、共有記憶域で別々のディレクトリを2つ使用して、それらをSOAサーバーの同じディレクトリにマウントすることで、バイナリの冗長性を実現できます。

SOAHOST1から:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw1 ORACLE_BASE/product/fmw -t nfs

SOAHOST2から:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw2 ORACLE_BASE/product/fmw -t nfs

次のコマンドは、異なるノード間においてSOAトランザクション・ログを共有する方法を示します。

mount nasfiler:/vol/vol1/ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs -t nfs

mount nasfiler:/vol/vol1/ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs -t nfs

WCPHOST1とWCPHOST2から:

次のコマンドは、異なるノード間においてWebCenter ContentファイルおよびInbound Refineryファイルを共有する方法を示します。

mount nasfiler:/vol/vol3/ORACLE_BASE/admin/domain_name/wcc_cluster_name
ORACLE_BASE/admin/domain_name/wcc_cluster_name -t nfs -o rw,bg,hard,vers=3,nolock,noac

mount nasfiler:/vol/vol3/ORACLE_BASE/admin/domain_name/ibr_servers_name/
ORACLE_BASE/admin/domain_name/ibr_servers_name -t nfs -o rw,bg,hard,vers=3,nolock,noac

WCPHOST2でも同様に実行します。

注意:

- WebCenter Contenは独自のロックを管理し、デフォルトのロック機能がWebCenter Contentのロック管理を妨げることがあるため、ここではnolockオプションをお薦めします。

- noacオプションは、異なるマシンから同じファイルに頻繁にアクセスされるファイル・システムにもお薦めします。

共有ストレージの構成の検証

構成した共有記憶域にテスト・ファイルを作成し、新しくマウントしたディレクトリでファイルの読取りおよび書込みができることを確認します。

例:

$ cd newly mounted directory
$ touch testfile

所有者と権限が正しいことを確認します。

$ ls -l testfile

ファイルを削除します。

$ rm testfile

注意:
共有記憶域にはNASやSANなどのデバイスを使用できます。次は、NASデバイスの記憶域をSOAHOST1から作成する例を示しています。オプションは、具体的な記憶域デバイスに応じて異なる場合があります。

mount nasfiler:/vol/vol1/fmw11shared ORACLE_BASE/wls -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768, wsize=32768

使用する環境に適切なオプションについては、ストレージ・ベンダーとマシン管理者と相談してください。

5 エンタープライズ・デプロイメント用のデータベースの準備

この章では、Oracle WebCenter Portalエンタープライズ・デプロイメント用にデータベースを準備する手順について説明します。この手順には、データベースの初期設定、メタデータ・リポジトリのロードおよびデータベースのバックアップが含まれます。

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

- エンタープライズ・デプロイメント用のデータベースの準備の概要

- データベース要件について

- データベース・サービスの作成

- Oracle RACデータベースへのOracle Fusionメタデータ・リポジトリのロード

- トランザクション・リカバリ権限のSOAスキーマの構成

- データベースのバックアップ

5.1 エンタープライズ・デプロイメント用のデータベースの準備の概要

データベースには、WebCenter Portalエンタープライズ・トポロジ用に、WebCenter PortalコンポーネントやOWSMなどの様々なOracle Fusion Middlewareコンポーネントによって使用される、スキーマのコレクションであるOracle Fusion Middleware Repositoryが用意されています。このデータベースはアイデンティティ管理データベースとは別になっています。これは、Oracle Internet DirectoryやDIPなどのコンポーネントによってアイデンティティ管理のエンタープライズ・デプロイメントで使用されます。

Oracle Fusion Middlewareコンポーネントを構成するには、まずOracle Fusion Middlewareリポジトリをインストールする必要があります。Oracle Fusion Middlewareメタデータ・リポジトリは、リポジトリ作成ユーティリティ(RCU)を使用して既存のデータベースにインストールします。RCUはRCUのDVDにあるか、表2-2に記載された場所にあります。エンタープライズ・トポロジでは、Real Application Clusters (Oracle RAC)データベースを強くお薦めします。

後でWebCenter Portalコンポーネントを構成する際には、構成ウィザードによってメタデータ・リポジトリを含むデータベースに接続するための情報の入力が求められます。

5.2 データベース要件について

メタデータ・リポジトリをデータベースにロードする前に、次の各項で説明されている要件をデータベースが満たしていることを確認してください。

- 第5.2.1項「データベース・ホストの要件」

- 第5.2.2項「サポートされているデータベース・バージョン」

- 第5.2.3項「初期化パラメータについて」

5.2.1 データベース・ホストの要件

データ層内のCUSTDBHOST1およびCUSTDBHOST2には、次の要件があります。

- Oracle Clusterware
Linux用11g リリース1 (11.1)については、Oracle Clusterwareのインストレーション・ガイドを参照してください。

- Oracle Real Application Cluster
Linux用11g リリース1 (11.1)については、『Oracle Real Application Clustersインストレーション・ガイド for Linux and UNIX』を参照してください。Linux用10g リリース2 (10.2)については、Oracle Database Oracle ClusterwareとOracle Real Application Clustersのインストレーション・ガイドを参照してください。

- 自動ストレージ管理(オプション)
ASMでは、ノードが全体としてインストールされます。データベースのOracleホームとは別のOracleホームにインストールすることをお薦めします。このオプションはrunInstallerにあります。「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択し、個別のASMホームを作成します。

5.2.2 サポートされているデータベース・バージョン

Oracle WebCenter Portalでは、サポートされているデータベースおよびスキーマが存在している必要があります。使用するデータベースが認証されていること、または認証済のすべてのデータベースを確認するには、Oracle Fusion Middlewareのサポートされるシステム構成ページにあるOracle Fusion Middleware 11gリリース1 (11.1.1.x)の製品エリアを参照してください。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

データベースのリリースをチェックするには、次のようにPRODUCT_COMPONENT_VERSIONビューに問い合せます。

SQL> SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE PRODUCT LIKE 'Oracle%';

注意:

- Oracle WebCenter Portalでは、メタデータ(10gまたは11g)の格納に使用するデータベースでAL32UTF8文字セットがサポートされている必要があります。データベースの文字セットの選択に関する情報は、データベースのドキュメントを確認してください。

- WebCenter Portalエンタープライズ・デプロイメントでは、Oracle RACデータベースへの接続にGridLinkデータ・ソースを使用することをお薦めします。GridLinkでSCAN機能を使用するには、Oracle Database Server 11gR2 (Enterprise Edition, バージョン11.2以降)のOracle RACデータベース・バージョンを使用する必要があります。

5.2.3 初期化パラメータについて

必要な最小値に次の初期化パラメータが設定されていることを確認してください。これは、リポジトリ作成ユーティリティによってチェックされます。

表5-1 必要な初期化パラメータ

構成

パラメータ

必要な値

パラメータ・クラス

SOA

PROCESSES

300以上

静的

WebCenter Portal

PROCESSES

300以上

静的

SOAおよびWebCenter Portal

PROCESSES

600以上

静的

SOA、WebCenter Portal、およびWebCenter Content

PROCESSES

700以上

静的

SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。

SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。

SQL> SHOW PARAMETER processes

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

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE;

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

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

5.3 データベース・サービスの作成

複数の製品スイートで同じデータベースを共有している場合でも、製品スイートごとに別のデータベース・サービスを構成することをお薦めします。また、デフォルトのデータベース・サービスとは別のデータベース・サービスを使用することもお薦めします。

サービスを使用したOracle Databaseへの接続の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のOracle RACとネットワークの接続性に関する項を参照してください。データベース・サービスを作成および管理する完全な手順は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』の動的データベース・サービスによるワークロード管理に関する項を参照してください。

実行時接続ロード・バランシングでは、ロード・バランシングが有効になっている各サービスのサービス・レベルの目標を使用してOracle RACロード・バランシング・アドバイザを構成する必要があります。Oracle RACロード・バランシング・アドバイザには、SERVICE_TIMEまたはTHROUGHPUTを構成できます。接続のロード・バランシングの目標は「短い」に設定します。10gと11gリリース1データベースについては、この変更にDBMS_SERVICEパッケージを使用します。11gリリース2には、かわりにsrvctlコマンド・ユーティリティを使用します。

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

- 第5.3.1項「10gおよび11gリリース1 (11.1)データベース用のデータベース・サービスの作成」

- 第5.3.2項「11gリリース2 (11.2)データベース用のデータベース・サービスの作成」

5.3.1 10gおよび11gリリース1 (11.1)データベース用のデータベース・サービスの作成

10gおよび11gリリース1データベース・サービスを作成および変更するには、DBMS_SERVICEパッケージを使用します。

1. SQL*Plusにログオンし、サービスを作成します。

sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'wcpedg.example.com',
NETWORK_NAME => 'wcpedg.example.com'
);

注意:
Oracle RACデータベースのサービス名と、それに続けてドメイン名を小文字で入力します。例:
wcpedg.example.com

注意:
示したEXECUTE DBMS_SERVICEコマンドは1行に入力します。
DBMS_SERVICEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプのリファレンスを参照してください。

2. 次のsrvctlコマンドを使用して、データベースにサービスを追加し、それをインスタンスに割り当てます。

srvctl add service -d wcdb -s wcpedg.example.com -r wcdb1,wcdb2

3. サービスを開始します。

srvctl start service -d wcdb -s wcpedg.example.com

注意:
SRVCTLによるデータベース・サービスの作成および管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のSRVCTLを使用したサービスの管理に関する項を参照してください。

4. 適切なサービス目標に合わせサービスを変更します。

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'wcpedg.example.com',goal => DBMS_SERVICE.GOAL_THROUGHPUT, clb_goal =>DBMS_SERVICE.CLB_GOAL_SHORT);

または、

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'wcpedg.example.com', goal => DBMS_SERVICE.GOAL_SERVICE_TIME, clb_goal =>DBMS_SERVICE.CLB_GOAL_SHORT);

5.3.2 11gリリース2 (11.2)データベース用のデータベース・サービスの作成

11gリリース2 (11.2)データベース・サービスを作成および変更するには、srvctlユーティリティを使用します。

1. sqlplusにログオンし、サービスを作成します。

sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'wcpedg.example.com',
NETWORK_NAME => 'wcpedg.example.com'
);

注意:
Oracle RACデータベースのサービス名と、それに続けてドメイン名を小文字で入力します。例:
wcpedg.example.com

注意:
示したEXECUTE DBMS_SERVICEコマンドは1行に入力します。
DBMS_SERVICEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプのリファレンスを参照してください。

2. サービスをデータベースに追加し、srvctlを使用してインスタンスに割り当てます。

srvctl add service -d wcdb -s wcpedg.example.com -r wcdb1,wcdb2

注意:
SRVCTLによるデータベース・サービスの作成および管理の完全な手順は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のSRVCTLを使用したサービスの管理に関する項を参照してください。

3. サービスを開始します。

srvctl start service -d wcdb -s wcpedg.example.com

4. 適切なサービス目標に合わせサービスを変更します。

srvctl modify service -d wcdb -s wcpedg.example.com -B SERVICE_TIME -j SHORT

または、

srvctl modify service -d wcdb -s wcpedg.example.com -B THROUGHPUT  -j SHORT

5.4 Oracle RACデータベースへのOracle Fusionメタデータ・リポジトリのロード

リポジトリ作成ユーティリティ(RCU)はRCUディストリビューションから入手できます。データベースのシードに使用されたRCUのパッチ・セット・レベルは、Oracle WebCenter Portalインストールのと一致している必要があります。つまり、このエンタープライズ・デプロイメントでOracle WebCenter Portal 11gR1 (11.1.1.9)をインストールする場合は、RCU 11gR1 (11.1.1.9)を使用する必要があります。

データベースにOracle Fusion Middlewareリポジトリをロードする手順は次のとおりです。

1. Repository Creation Utility (RCU)のディストリビューションを開きます。

2. RCUホーム・ディレクトリのbinディレクトリからRCUを起動します。
cd RCU_Home/bin

./rcu

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。

5. 「データベース接続の詳細」画面で、データベースの情報を正しく入力します。

- データベース・タイプ: 「Oracle Database」を選択します。

- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名またはノード名のいずれかをホスト名(CUSTDBHOST1-VIP)として指定します。

- ポート: データベースのポート番号(1521)を入力します。

- サービス名: データベースのサービス名を入力します: wcpedg.example.com

- ユーザー名: SYS

- パスワード: SYSユーザーのパスワードを入力します。

- ロール: SYSDBA

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

6. 「リポジトリ作成ユーティリティ - 前提条件チェック」ダイアログ・ボックスで、すべてのグローバル前提条件のチェック・ボックスが緑色であり、検証されることを確認します。その場合、「OK」をクリックします。
使用中のデータベースでUTF-8文字セットを使用していない場合には警告メッセージが表示され、多言語サポート対応のデータベースを使用した場合にデータ損失の可能性がある旨を通知します。今後、多言語サポートを使用しない場合は、「無視」をクリックすることもできます。それ以外の場合は、「停止」をクリックします。

7. 「コンポーネントの選択」画面で、次の手順を実行します。

1. 「接頭辞の新規作成」を選択して、データベース・スキーマに使用する接頭辞を入力します。たとえば、wcpedgです。接頭辞は、データベースで複数のリポジトリの論理グループを作成するために使用されます。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

2. 後で使用するため、スキーマ名をメモします。

3. 次を選択します。

- AS共通スキーマ
- Metadata Services

- Oracle Platform Security Services

- WebCenter Content:
- Oracle WebCenter Content Server - 完了

- SOAおよびBPMインフラストラクチャ:
- SOAインフラストラクチャ

- Business Activity Monitoring

- ユーザー・メッセージング・サービス

- WebCenter Portal(すべてのスキーマを選択):
- スペースとサービス脚注 1

- ポートレット・プロデューサ

- アクティビティ・グラフおよびAnalytics

- ディスカッション

注意:
これによってMetadata Servicesも自動的に選択されます。

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

8. 「スキーマ・パスワード」画面で、「補助スキーマにメイン・スキーマのパスワードを使用」を選択します。次の画面で、すべてのコンポーネントのスキーマ・パスワードを入力します。

ヒント:

- スキーマ名を書き留めておきます。この情報は後続の手順で必要になります。

- スキーマのパスワードがデータベース要件を満たしていることを確認します。スキーマの作成時に単純すぎるパスワードがデータベースにより拒否された場合、RCUではパスワードの再試行ができません。最初からやり直し、RCUを再実行する必要があります。

- パスワードの有効期限は、かなり大きなメンテナンスになる場合があります。データベース・セキュリティおよびポリシーの制限は、RCUにより作成されるユーザーに適用されます。デフォルトのデータベース・セキュリティ・ポリシーおよび有効期限からスキーマ・ユーザーを除外するか、定期的にパスワードをリセットするためにプロアクティブ・メンテナンス・スケジュール(およびポータルの停止)を計画することができます。

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

9. 「カスタム変数」画面で、分析およびアクティビティ・グラフにパーティション化を使用するかどうかを選択します。
エンタープライズ・デプロイメントでは、パーティション化の使用はオプションです。「次へ」をクリックして、デフォルトの「N」を受け入れます。または、ご使用の環境でパーティション化を使用するためにパーティション化によるAnalyticsのインストールを「Y」に設定して、「次へ」をクリックします。

注意:
分析データのパーティション化の詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle WebCenter Portal分析データのパーティション化に関する項を参照してください。
表をパーティション化することを選択した場合、Oracle WebCenter Portalは、データベースのネイティブ・パーティショニングを使用して、パーティションを自動的に作成します。

データをパーティション化すると、パーティション・マネージャが作成した古いパーティションを削除することによりデータをパージできるため、データのパージが簡単になります。パーティション化された環境でデータをパージするには、単に不要となった月ベースのパーティションを削除することをお薦めします。

10. 「表領域のマップ」画面で、「次へ」をクリックしてデフォルトの表領域およびサイズを受け入れます。

注意:
必要に応じて、「表領域の管理」ボタンをクリックして、カスタムの名前付け、サイズ設定またはオプションに適合するように新しい表領域の構成を変更します。「表領域の管理」画面の使用の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』のOracle WebCenter Contentアプリケーションのスキーマの作成に関する項を参照してください。

確認のダイアログが表示され、選択したスキーマに存在しない表領域が作成されるという内容のメッセージが表示されます。「OK」をクリックして、このメッセージを確認します。

11. 「サマリー」画面で「作成」をクリックします。

12. 「完了サマリー」画面で「閉じる」をクリックします。

13. 追加した新しいユーザーでデータベースに接続し、必要なスキーマが作成されていることを確認します。

ORACLE_HOME/bin/sqlplus

たとえば、SYSDBAユーザーとしてログインし、パスワードを入力します。スキーマ・バージョンのレジストリを検索することで、簡単な確認を実行できます。

-bash-3.00$ $ORACLE_HOME/bin/sqlplus SYS/password as SYSDBA
SQL> SELECT version, status FROM schema_version_registry where owner = 'WCPEDG_WEBCENTER';

VERSION STATUS
-----------------------------------------
11.1.1.9.0 VALID

注意:
すべてのスキーマの値が11.1.1.9.0であるとはかぎりません。前回のスキーマの拡張に応じて、11.1.1.2.0、11.1.1.5.0、11.1.1.7.0または11.1.1.8.0である場合があります。

Oracle WSMポリシーとOWSM MDSスキーマについて

Oracle WSMがWebCenter Portalエンタープライズ・デプロイメントの一部として存在する場合、Oracle WSMポリシーの保存にアイデンティティ管理データベースを使用することをお薦めします。OWSM MDSスキーマに、他のSOAやWebCenter Portalスキーマに使用される情報ではなく、IMデータベース接続情報を使用します。データベースで必要なスキーマを作成するには、IMデータベース情報を使用して前述の手順を繰り返します(RCUを再度実行します)。ただし、手順7の「コンポーネントの選択」画面では「AS共通スキーマ: Metadata Services」のみを選択します。Oracle WSMポリシーの格納にアイデンティティ管理データベースを使用する方法の詳細は、第15項「エンタープライズ・デプロイメントとOracle Identity Managementの統合」を参照してください。

5.5 トランザクション・リカバリ権限のSOAスキーマの構成

WebLogic Serverコンテナのクラッシュ後、進行中のトランザクションをリカバリする際に、Oracle WebLogic Serverトランザクション・マネージャでトランザクション状態の情報を問い合せて該当するコマンド(commitやrollbackなど)を発行するには、適切なデータベース権限が必要です。

これらの権限は、RCU操作で決定されるsoainfraスキーマの所有者に付与する必要があります。

トランザクション・リカバリ権限用のSOAスキーマを構成するには:

1. sysdba権限が付与されたユーザーとしてsqlplusにログオンします。例:

sqlplus "/ as sysdba"

2. 次のコマンドを入力します。

SQL> Grant select on sys.dba_pending_transactions to wcpedg_soainfra;

Grant succeeded.

SQL> Grant force any transaction to wcpedg_soainfra;

Grant succeeded.

SQL>

5.6 データベースのバックアップ

データベースにメタデータ・リポジトリをロードした後は、まずバックアップを実行し、その後でエンタープライズ・デプロイメント用ソフトウェアをインストールする必要があります。

データベースのバックアップは、今後の手順で問題が発生した場合に迅速なリカバリを行うために明示的に行います。この目的のためにデータベースのバックアップ戦略を使用することも、オペレーティング・システムのツールやRMANを使用して単純にバックアップすることもできます。特にデータベースがOracle ASMを使用して作成された場合は、データベースにOracle Recovery Managerを使用することをお薦めします。可能な場合、オペレーティング・システムのツール(tarなど)を使用してコールド・バックアップも実行できます。

脚注の凡例

脚注 1: 前のリリースでは、すぐに使用できるアプリケーションWebCenter Portalはスペースと呼ばれていました。RCUの一部の画面では、前の名前で呼ばれています。

6 エンタープライズ・デプロイメント用のソフトウェアのインストール

この章では、Oracle WebCenter Portalのエンタープライズ・デプロイメントの参照用トポロジに必要なソフトウェアをインストールする手順を説明します。Oracle HTTP Serverをインストールした後に、Oracle Fusion Middlewareをインストールします。

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

- ソフトウェアのインストール・プロセスの概要

- Oracle HTTP Serverのインストール

- Oracle Fusion Middlewareのインストール

6.1 ソフトウェアのインストール・プロセスの概要

エンタープライズ・デプロイメントのソフトウェアのインストールは、2つの部分に分割できます。最初の部分では必要なWeb層のインストールについて説明し、2番目の部分では必要なFusion Middleware (FMW)コンポーネントについて説明します。以降の章では、Oracle WebCenter Portalの参照用トポロジを作成するために必要な構成手順を説明します。

ソフトウェアの入手

ソフトウェアを入手する場所の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のOracle Fusion Middlewareソフトウェアの入手に関する項を参照してください。

いずれかのダウンロード場所を選択して、Oracle WebCenter Portalをダウンロードします。ZIPアーカイブ・ファイルがシステムに保存されます。

アーカイブ・ファイルをダウンロードした後、インストールを実行するマシン上の任意のディレクトリにアーカイブ・ファイルを解凍します。

インストールするソフトウェア

表6-1に、各ホストにインストールする必要があるソフトウェアまたは各ホストからアクセス可能なソフトウェアを示します。

表6-1 各ホストにインストールする必要があるソフトウェアまたは各ホストからアクセス可能なソフトウェア

ホスト

Oracle
HTTP
Server

Oracle WebLogic Server

Oracle
SOA
Suite

Oracle WebCenter Portal

Oracle WebCenter Content

WEBHOST1

X

WEBHOST2

X

SOAHOST1

X

X

X

X

SOAHOST2

X

X

X

X

WCPHOST1

X

X

X

X

WCPHOST2

X

X

X

X

6.2 Oracle HTTP Serverのインストール

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

- 第6.2.1項「Oracle HTTP Serverのインストールの前提条件」

- 第6.2.2項「Oracle HTTP ServerのWEBHOST1およびWEBHOST2へのインストール」

- 第6.2.3項「Oracle Fusion Middlewareインストールのバックアップ」

6.2.1 Oracle HTTP Serverのインストールの前提条件

Oracle HTTP Server (OHS)をインストールする前に、ご使用のマシンが次の要件を満たしていることを確認します。

- 『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』で指定されているように、システム、パッチ、カーネルおよびその他の要件が満たされていることを確認します。

- Oracle HTTP Serverはデフォルトではポート7777にインストールされるので、ノード上のどのサービスでもポート7777を使用していないことを確認する必要があります。このポートが使用中かどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。

netstat -an | grep 7777

ポート7777が使用されている場合は解放する必要があります。

- Linuxプラットフォームで、/etc/oraInst.locファイルが存在する場合はその内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、およびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locが存在しない場合は、この手順を省略してもかまいません。

- インストールを開始する前に、次の環境変数が設定されていないことを確認します。

- LD_ASSUME_KERNEL

- ORACLE_INSTANCE

6.2.2 Oracle HTTP ServerのWEBHOST1およびWEBHOST2へのインストール

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

Oracle HTTP ServerをWEBHOST1およびWEBHOST2にインストールするには:

1. Oracle HTTP Serverのインストーラを次のインストール・メディアから起動します。
./runInstaller

2. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. ORACLE_BASE/oraInventoryを入力します(これは推奨の場所です)。

2. インストールを実行するユーザーのOSグループを入力します。

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

画面上の指示に従い、root権限で/createCentralInventory.shを実行します。

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

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

5. 「インストール・タイプの選択」画面でインストール - 構成なしを選択し、「次へ」をクリックします。

6. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

7. 「インストール場所の指定」画面で、次を指定します。

- Fusion Middlewareホームの場所(インストール場所): ORACLE_BASE/product/fmw

- Oracleホームの場所のディレクトリ: web

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

8. 「セキュリティ・アップデートの指定」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択し、受信する場合は、電子メール・アドレスを入力します。

9. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。問題がなければ、「インストール」をクリックします。
UNIXシステムでoracleRoot.shスクリプトの実行を求められたら、必ずrootユーザーとして実行します。

Oracle HTTP Serverソフトウェアがインストールされます。

10. 「インストール完了」画面で「終了」をクリックして終了します。

11. Oracle HTTP Serverのインストール後、ORACLE_HOMEディレクトリに次のディレクトリが表示されることを確認し、インストールが成功したことを確認します。

- oracle_common

- web

6.2.3 Oracle Fusion Middlewareインストールのバックアップ

この時点でFusion Middlewareホームをバックアップする必要があります(この時点ですべてのサーバーが停止していることを確認します)。

WEBHOST1> tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw HOME/oraInventory

6.3 Oracle Fusion Middlewareのインストール

この項では、Oracle WebCenter Portalのエンタープライズ・デプロイメントの参照用トポロジに必要なOracle Fusion Middlewareソフトウェアをインストールする方法を説明します。インストールするソフトウェア・コンポーネントは、Oracle WebLogic Serverホーム(WL_HOME)およびOracleホーム(ORACLE_HOME)です。第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

注意:
セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

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

- 第6.3.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」

- 第6.3.2項「Oracle Fusion Middlewareコンポーネントのインストール」

- 第6.3.3項「Fusion Middlewareインストールのバックアップ」

6.3.1 Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成

SOAHOST1およびSOAHOST2にOracle WebLogic Serverをインストールします。

Oracle WebLogic ServerはWCPHOST1およびWCPHOST2にインストールする必要はありません。インストールは共有記憶域で実行されるため、MW_HOMEは、WCPHOST1とWCPHOST2のOracle WebCenter Portalによってアクセスおよび使用が可能です。

注意:
WebLogic Serverを、64ビットJDKを使用して64ビット・プラットフォームにインストールする場合は、この項の手順ではなく、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の64ビットJDKを使用した64ビット・プラットフォームへのWebLogic Serverのインストールに関する項の手順に従ってください。

Oracle WebLogic Serverをインストールするには:

1. Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。

$ ./wls1036_linux32.bin

2. 「ようこそ」画面で、「次へ」をクリックします。

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、次の手順を実行します。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します

注意:
詳細は、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」を参照してください。

ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。このディレクトリは/u01/app/oracleとすることをお薦めします。詳細は、第4.3項「各種ディレクトリの推奨場所」を参照してください。

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

4. 「セキュリティ更新のための登録」画面で、セキュリティ更新の通知を受け取る連絡先の情報を入力して、「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「カスタム」を選択し、「次へ」をクリックします。

6. 「製品とコンポーネントの選択」画面で「次へ」をクリックします。

7. 「JDKの選択」画面で、「Oracle JRockit 1.6.0_<version> SDK」のみを選択して「次へ」をクリックします。

8. 「製品インストール・ディレクトリの選択」画面で、ORACLE_BASE/product/fmw/wlserver_10.3とORACLE_BASE/product/fmw/coherence_3.7を受け入れ、「次へ」をクリックします。

9. 「インストールのサマリー」画面で「次へ」をクリックします。
Oracle WebLogic Serverソフトウェアがインストールされます。

10. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

6.3.2 Oracle Fusion Middlewareコンポーネントのインストール

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

- 第6.3.2.1項「Oracle SOA Suiteのインストール」

- 第6.3.2.2項「Oracle WebCenter Portalのインストール」

- 第6.3.2.3項「Oracle WebCenter Contentのインストール」

6.3.2.1 Oracle SOA Suiteのインストール

Oracle SOA SuiteをSOAHOST1およびSOAHOST2にインストールする手順は次のとおりです

注意:
インストールは共有記憶域で実行されるため、MW_HOMEは、WCPHOST1とWCPHOST2のOracle WebCenter Portalによってアクセスおよび使用が可能です。

1. Linuxプラットフォームで、/etc/oraInst.locファイルが存在する場合はその内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、およびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locが存在しない場合は、この手順を省略してもかまいません。

2. Oracle SOA Suiteのインストーラをインストール・メディアから起動します。

./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します(例: ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version)。詳細は、第6.3.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」を参照してください。

3. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

2. インストールを実行しているユーザーの「オペレーティング・システム・グループ」名を入力します。

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

画面上の指示に従い、root権限で/createCentralInventory.shを実行します。「OK」をクリックします。

注意:
「インベントリ・ディレクトリの指定」画面は、UNIXオペレーティング・システムで、Oracle Universal Installerによる初めてのインストール時のみ表示されます。インストーラは、インベントリ・ディレクトリを使用して、マシンにインストールしたすべてのOracle製品を追跡します。

4. 「ようこそ」画面で、「次へ」をクリックします。

5. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

6. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「OK」をクリックします。

7. 「インストール場所の指定」画面で、Oracle SOA Suiteのインストール場所を指定します。すでにインストールされているOracleミドルウェア・ホームをドロップダウン・リストから選択します。Oracleホーム・ディレクトリには、SOA Suiteのディレクトリ名(soa)を入力します。

図6-1 インストーラ・ウィザードの「インストール場所の指定」画面

完了したら、「次へ」をクリックします。

8. Application Server画面で、WebLogic Serverを選択し、「次へ」をクリックします。

9. 「インストールのサマリー」画面で「インストール」をクリックします。
Oracle Fusion Middleware SOA Suiteソフトウェアがインストールされます。

10. 「インストール完了」画面で「終了」をクリックします。

11. Oracle WebLogic SeverおよびOracle SOA Suiteの両方のインストールが完了したら、MW_HOMEディレクトリに次のファイルとディレクトリが表示されることを確認し、インストールを確認します。

- coherence_version

- jrockit-jdk_version **

- modules

- oracle_common

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- soa

- wlserver_10.3

注意:

- ** 64ビットJDKを使用する64ビット・プラットフォームでインストールする場合は、jrockit-jdk_versionディレクトリは表示されません。(Oracle WebLogic Serverの.jarインストーラにはJDKが組み込まれていませんが、.binインストーラにはJDKが含まれます)。『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の64ビットJDKを使用した64ビット・プラットフォームでのWebLogic Serverのインストールに関する項も参照してください。

- このガイドで説明する例ではJRockitを使用します。特に記載がないかぎり、動作保証された任意のバージョンのJavaを使用できます。

6.3.2.2 Oracle WebCenter Portalのインストール

Oracle WebCenter PortalをSOAHOSTおよびSOAHOST2にインストールする手順は次のとおりです。

注意:
インストールは共有記憶域で実行されるため、MW_HOMEは、WCPHOST1とWCPHOST2のOracle WebCenter Portalによってアクセスおよび使用が可能です。

1. Oracle WebCenter Portalのインストーラを起動します。

./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します(例: ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version)。詳細は、第6.3.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」を参照してください。

2. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. HOME/oraInventoryと入力します。ここでHOMEは、インストールを実行しているユーザーのホーム・ディレクトリです(推奨の場所)。

2. インストールを実行しているユーザーの「オペレーティング・システム・グループ」名を入力します。

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

注意:
「インベントリ・ディレクトリの指定」画面は、UNIXオペレーティング・システムで、Oracle Universal Installerによる初めてのインストール時のみ表示されます。インストーラは、インベントリ・ディレクトリを使用して、マシンにインストールしたすべてのOracle製品を追跡します。

3. 「ようこそ」画面で、「次へ」をクリックします。

4. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

5. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「OK」をクリックします。

6. 「インストール場所の指定」画面で、Oracle WebCenter Portalのインストール場所を指定します。すでにインストールされているOracleミドルウェア・ホームをドロップダウン・リストから選択します。Oracleホーム・ディレクトリには、WebCenter Portalのディレクトリ名(wc)を入力します。
「次へ」をクリックします。

7. Application Server画面で、WebLogic Serverを選択し、「次へ」をクリックします。

8. 「インストールのサマリー」画面で「インストール」をクリックします。
Oracle WebCenter Portalソフトウェアがインストールされました。

9. 「インストール完了」画面で「終了」をクリックします。

10. Oracle WebLogic Sever、Oracle SOA SuiteおよびOracle WebCenter Portalのインストールが完了したら、MW_HOMEディレクトリに次のディレクトリとファイルが表示されることを確認し、インストールを確認します。

- coherence_version

- jrockit-jdk_version **

- modules

- oracle_common

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- soa

- wc

- wlserver_10.3

注意:

- ** 64ビットJDKを使用する64ビット・プラットフォームでインストールする場合は、jrockit-jdkversionディレクトリは表示されません。(Oracle WebLogic Serverの.jarインストーラにはJDKが組み込まれていませんが、.binインストーラにはJDKが含まれます)。『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の64ビットJDKを使用した64ビット・プラットフォームでのWebLogic Serverのインストールに関する項も参照してください。

- このガイドで説明する例ではJRockitを使用します。特に記載がないかぎり、動作保証された任意のバージョンのJavaを使用できます。

6.3.2.3 Oracle WebCenter Contentのインストール

Oracle WebCenter ContentをSOAHOSTおよびSOAHOST2にインストールする手順は次のとおりです。

注意:
インストールは共有記憶域で実行されるため、MW_HOMEは、WCPHOST1とWCPHOST2のOracle WebCenter Portalによってアクセスおよび使用が可能です。

1. Oracle WebCenter Contentのインストーラを起動します。

./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します(例: ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version)。詳細は、第6.3.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」を参照してください。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

4. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

5. 「インストール場所の指定」画面で、Oracle WebCenter Contentをインストールする場所を指定します。すでにインストールされているOracleミドルウェア・ホームをドロップダウン・リストから選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(wcc)を入力します。
完了したら、「次へ」をクリックします。

6. 「アプリケーション・サーバー」画面で、「WebLogic Server」が選択されていること(デフォルト)を確認してから「次へ」をクリックします。

7. 「インストールのサマリー」画面で「インストール」をクリックします。
Oracle WebCenter Contentソフトウェアがインストールされます。

8. 「インストール完了」画面で「終了」をクリックします。

9. Oracle WebLogic Server、Oracle Fusion Middleware for SOA、Oracle WebCenter PortalおよびOracle WebCenter Contentのインストールが完了したら、MW_HOMEディレクトリに次のディレクトリとファイルが表示されることを確認し、インストールを確認します。

- coherence_version

- jrockit-jdk_version

- modules

- oracle_common

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- soa

- wc

- wlserver_10.3

- wcc

注意:

- ** 64ビットJDKを使用する64ビット・プラットフォームでインストールする場合は、jrockit-jdkversionディレクトリは表示されません。(Oracle WebLogic Serverの.jarインストーラにはJDKが組み込まれていませんが、.binインストーラにはJDKが含まれます)。『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の64ビットJDKを使用した64ビット・プラットフォームでのWebLogic Serverのインストールに関する項も参照してください。

- このガイドで説明する例ではJRockitを使用します。特に記載がないかぎり、動作保証された任意のバージョンのJavaを使用できます。

6.3.3 Fusion Middlewareインストールのバックアップ

この時点でSOAHOST1からFusion Middlewareホームをバックアップする必要があります(まず、サーバーが停止していることを確認します)。

tar -cpzf BACKUP_LOCATION/edg6.3.3_fmwhome.tgz MW_HOME
tar -cpzf BACKUP_LOCATION/edg6.3.3_oraInv.tgz ORACLE_BASE/oraInventory

これによって、Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントの両方のインストール・ファイルのバックアップが作成されます。

7 エンタープライズ・デプロイメント用のWeb層の構成

この章では、Oracle Fusion Middleware WebCenter Portalの実装をサポートするOracle Web層の構成方法を説明します。

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

- Web層構成の概要

- Web層構成の前提条件

- 構成ウィザードによるOracle HTTP Serverの構成

- Oracle HTTP Serverの構成の検証

- HTTPリクエストをルーティングするためのロード・バランサの構成

- 仮想ホストの定義

7.1 Web層構成の概要

Oracle Web層ソフトウェアを構成する前に、第6.2項「Oracle HTTP Serverのインストール」の説明に従って、このソフトウェアをWEBHOST1とWEBHOST2にインストールする必要があります。また、第7.3項「構成ウィザードによるOracle HTTP Serverの構成」の説明に従って、インスタンス・ホーム、インスタンス名およびOracle HTTP Serverコンポーネント名を定義します。

次に、インストールを検証し、すべてのHTTPリクエストをWEBHOST1およびWEBHOST2にルーティングするようにロード・バランサを構成できます。

最後に、両方のOHSサーバー上で.confファイルで<VirtualHost>ディレクティブを定義することにより、仮想ホストを構成できます。第3.3項「ロード・バランサの構成」でのロード・バランサの構成時に、次の仮想ホスト名を作成しています。

- wcp.example.com

- admin.example.com

- wcpinternal.example.com

7.2 Web層構成の前提条件

構成を開始する前に、第6.2項「Oracle HTTP Serverのインストール」のとおり、Oracle Web層ソフトウェアをWEBHOST1およびWEBHOST2にインストールする必要があります。

7.3 構成ウィザードによるOracle HTTP Serverの構成

Oracle Web層の構成手順は、WEBHOST1とWEBHOST2で同じです。

Oracle Web層を構成する手順は次のとおりです。

1. Oracle Fusion Middleware構成ウィザードの場所にディレクトリを変更します。

WEBHOST1> cd ORACLE_BASE/product/fmw/web/bin

2. 構成ウィザードを起動します。

WEBHOST1> ./config.sh

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「コンポーネントの構成」画面で「Oracle HTTP Server」を選択し、「選択されたコンポーネントとWebLogicドメインの関連付け」を選択解除します。「Oracle Web Cache」は選択されていないことを確認します。
「次へ」をクリックします。

5. 「コンポーネントの詳細の指定」画面で、次の値を指定します。

- インスタンス・ホームの場所: ORACLE_BASE/admin/webn

- ASインスタンス名: webn

- OHSコンポーネント名: ohsn

(ここでnは、インストール上の連番を示します。たとえば、WEBHOST1には1、WEBHOST2には2などです。)

注意:
WEBHOST1とWEBHOST2で、異なるOracle HTTP Serverインスタンス名を指定する必要があります。

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

6. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、ファイル名を選択してから「表示/編集」をクリックします。
高可用性の実装では、様々なコンポーネントで使用されるポートのすべてを複数のホスト間で同期すると、エンタープライズ・デプロイメントがより簡単になります(必須ではありません)。

注意:
1つのファイルにポートを指定して「自動でポートを構成」をバイパスすることは必須ではありませんが、より簡単になります。

ファイルは次のようになります。

[OHS]
#Listen port for OHS component
OHS Port = 7777

[OPMN]
#Process Manager Local port no
OPMN Local Port = 1880

サンプルのstaticports.iniファイルは、インストール・ディスク1のstage/Responseディレクトリにあります。

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

7. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。

8. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。問題がなければ、「構成」をクリックします。

9. 複数のConfiguration Assistantが連続して起動されるため、時間がかかることがあります。終了したら、「次へ」をクリックすると、「インストール完了」画面が表示されます。

10. 「インストール完了」画面で「終了」をクリックして終了します。

7.4 Oracle HTTP Serverの構成の検証

インストールが完了したら、両方のOracle HTTP Serverのホーム・ページに、次のURLからアクセスできることを確認します。

http://webhost1.example.com:7777/
http://webhost2.example.com:7777/

7.5 HTTPリクエストをルーティングするためのロード・バランサの構成

Oracle HTTP Server (WEBHOST1、WEBHOST2)を実行するホストへすべてのHTTPリクエストをルーティングするようロード・バランサを構成できます。Oracle HTTP ServerがフロントエンドのOracle WebLogic Serverである場合は、ロード・バランサでスティッキー・セッション(Cookieの挿入)を有効にする必要はありません。このドキュメントで説明するトポロジには該当しませんが、ロード・バランサからOracle WebLogic Serverに直接移動する場合にはスティッキー・セッションが必要です。

使用するロード・バランサによって、構成手順は異なります。具体的な手順は、ロード・バランサのドキュメントを参照してください。第3.3項「ロード・バランサの構成」も参照してください。

7.6 仮想ホストの定義

このガイドの参照トポロジでは、Oracle HTTPサーバーに対する仮想ホスト・セットを定義する必要があります。各仮想ホストについては、後にWebLogicサーバー・ドメイン内の適切な管理サーバーまたは管理対象サーバーに要求をルーティングするための特定のURLセットを定義する必要があります。

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

- 第7.6.1項「httpd.confファイルでのIPアドレスとポートの定義」

- 第7.6.2項「<VirtualHost>ディレクティブを定義する.confファイルの作成」

- 第7.6.3項「構成の検証」

7.6.1 httpd.confファイルでのIPアドレスとポートの定義

名前ベースの仮想サーバーを定義します。定義する個々の仮想ホストに対して使用するIPアドレスとポートを定義する必要があるという意味です。一度、httpd.confファイルにIPアドレスとポートを定義すれば、実際の仮想ホスト名(および各々の特定URL)を仮想ホスト専用の.confファイルに定義できます。

IPアドレスおよびポートを定義するには、httpd.confファイルに次のエントリを追加します。

NameVirtualHost *:7777

httpd.confファイルは次のディレクトリにあります。

ORACLE_BASE/admin/instance_name/config/OHS/component_name

7.6.2 <VirtualHost>ディレクティブを定義する.confファイルの作成

個々の仮想ホストをホスト自身の.confファイルで定義します。こうすることで、定義する個々の仮想ホストのURLの管理が容易になります。

httpd.confには、moduleconfサブディレクトリのすべての*.confファイルをインクルードするINCLUDE文があります。この文により、各コンポーネントに対して個別に仮想ホスト・ファイルを作成することが可能になり、仮想ホスト定義の更新、維持およびスケールアウトが容易になります。

<VirtualHost>のディレクティブを定義するために、次のファイルを新規作成します。

- wcp_vh.conf

- admin_vh.conf

- wcpinternal_vh.conf

次のディレクトリに新規ファイルを作成します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

例:

ORACLE_BASE/admin/web1/config/OHS/ohs1/moduleconf

個々の仮想ホストをホスト自身の.confファイルに定義する手順は次のとおりです。

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

<VirtualHost *:7777>
ServerName https://wcp.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

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

<VirtualHost *:7777>
ServerName wcpinternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

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

<VirtualHost *:7777>
ServerName admin.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end_url=/console" [R]
</VirtualHost>

4. Oracle HTTPサーバーを両方とも再起動します。

cd ORACLE_BASE/admin/instance_name/bin
opmnctl stopall
opmnctl startall

7.6.3 構成の検証

ロード・バランサから次のURLにアクセスして、ロード・バランサとOracle HTTP Serverが正しく構成されていることを確認します。

- https://wcp.example.com/index.html

- http://admin.example.com/index.html

- http://wcpinternal.example.com/index.html

注意:
これらのURLには、ロード・バランサを通してのみアクセスできます。Webサーバー・ホスト(WEBHOST1またはWEBHOST2)からアクセスしようとすると、これらのURLはエラーになります。これらのURLは、ロード・バランサおよび定義済の仮想ホストのURLを使用したサーバーへのアクセスにのみ有効です。

これらのURLにアクセスできない場合は、第3.3項「ロード・バランサの構成」の手順を正しく実行していることを確認してください。

8 エンタープライズ・デプロイメント用のドメインの作成

この章では、構成ウィザード、Oracle WebLogic Server管理コンソール、Oracle Enterprise ManagerおよびOracle WSM Policy Managerを使用してドメインを作成する方法を説明します。ドメインを拡張してWebCenter Portalコンポーネントを追加できます。

注意:
セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

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

- ドメイン作成の概要

- SOAHOST1でのVIP1の有効化

- SOAHOST1での構成ウィザードによるドメインの作成

- 構成後タスクおよび検証タスク

- SOAHOST2へのドメイン構成の伝播

- Oracle WSMのJavaオブジェクト・キャッシュの構成

- WebLogic ServerドメインのOracle HTTP Serverの構成

- WebLogic Serverドメイン構成のバックアップ

8.1 ドメイン作成の概要

表8-1に、構成後タスクを含む、WebLogic Serverドメインの作成手順を示します。

表8-1 WebLogic Serverドメインの作成手順

手順

説明

詳細

SOAHOST1でのVIP1の有効化

SOAHOST1ホスト名に対しVIP1を有効にします。

第8.2項「SOAHOST1でのVIP1の有効化」

WebLogic Serverドメインの作成

構成ウィザードを実行してWebLogic Serverドメインを作成します。

第8.3項「SOAHOST1での構成ウィザードによるドメインの作成」

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

構成後タスクおよび検証タスクの手順に従います。

第8.4項「構成後タスクおよび検証タスク」

SOAHOST2へのドメイン構成の伝播

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

第8.5項「SOAHOST2へのドメイン構成の伝播」

WebLogic ServerドメインでのOracle HTTP Serverの構成

WebLogic ServerドメインのOracle HTTP Serverを構成し、構成を検証します。

第8.7項「WebLogic ServerドメインのOracle HTTP Serverの構成」

ドメインのバックアップ

新しく構成したWebLogic Serverドメインをバックアップします。

第8.8項「WebLogic Serverドメイン構成のバックアップ」

このドメインを作成し構成したら、ドメインを拡張し、次の章で説明するとおり、Oracle WebCenter Portalコンポーネント、Oracle SOA Suite、Oracle WebCenter Contentなどを含めることができます。

8.2 SOAHOST1でのVIP1の有効化

SOAがインストールされているかどうかにかかわらず、この手順は管理サーバーのフェイルオーバーを可能にするために必要です。

管理サーバーは仮想ホスト名(ADMINVHN)に関連付けます。仮想ホスト名は、DNSサーバーとカスタムの/etc/hostエントリのいずれかによって、適切な仮想IP (VIP1)にマップする必要があります。WebCenter Portalトポロジ内の必要なノードにある名前解決システム(DNSサーバー、/etc/hosts)に応じてADMINVHNが使用可能であることを確認します。この仮想ホスト名(ADMINVHN1)に関連付けられた仮想IP (VIP1)は、SOAHOST1で有効になっている必要があります。

仮想IPの有効化方法の詳細は、第3.5項「エンタープライズ・デプロイメント用の仮想IPアドレスの有効化」を参照してください。

表8-2に示すように仮想ホストが有効になっていることを確認します。

表8-2 仮想ホスト

VIP

有効化されるホスト

ADMINVHN.example.com

SOAHOST1

SOAHOST1VHN1.example.com

SOAHOST1

SOAHOST2VHN1.example.com

SOAHOST2

注意:
これは、浮動IPアドレスに関連付けられているDNS名です。これは、ロード・バランサ上で構成される仮想ホストのDNS名ではありません。

8.3 SOAHOST1での構成ウィザードを使用したドメインの作成

ORACLE_COMMON_HOMEディレクトリから構成ウィザードを実行し、管理サーバーとOracle Web Services Managerを含むドメインを作成できます。その後、ドメインを拡張してWebCenter Portal、SOAおよびWebCenter Contentコンポーネントを含めることができます。

ドメインを作成する手順:

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておく必要があります。

2. SOAHOST1で、ディレクトリを次の構成ウィザードの場所に変更します。

cd ORACLE_COMMON_HOME/common/bin

3. Oracle Fusion Middleware構成ウィザードを開始します。

./config.sh

4. 「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面が表示されます(図8-1)。

図8-1「ドメイン・ソースの選択」画面

5. 「ドメイン・ソースの選択」画面で、次の手順を実行します。

- 「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

- 次の製品を選択します。

- WebLogic Serverの基本ドメイン - 10.3.6.0 [wlserver_10.3](これは自動的に選択されます)

- Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

- Oracle WSM Policy Manager 11.1.1.0 [oracle_common]

- Oracle JRF - 11.1.1.0 [oracle_common](これは自動的に選択されます)

いくつかのターゲットを間違って選択解除した場合は、この画面で次の項目が選択されていることを確認します。

- Oracle Enterprise Manager

- Oracle WSM Policy Manager

- Oracle JRF

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

注意:
複数のOracleホームがインストールされている場合(たとえば、WebCenter PortalホームとSOAホーム)、どちらのホームについても、使用可能な製品が表示されます。この手順では、Oracle共通ホーム(oracle_common)の製品のみを選択します。これは、たとえば、Oracle JRF - 11.1.1.0 [oracle_common]のように、製品名の末尾に角かっこで囲んで示されます。

6. 「ドメイン名と場所の指定」画面で、ドメイン名(wcpedg_domainなど)を入力します。
ドメインの場所が第3章「エンタープライズ・デプロイメント用のネットワークの準備」で推奨しているディレクトリおよび共有記憶域のマウント・ポイントと一致することを確認します。

ドメインの場所として、次を入力します。

ORACLE_BASE/admin/domain_name/aserver

アプリケーションの場所として、次を入力します(このディレクトリは共有記憶域内のものである必要があります)。

ORACLE_BASE/admin/domain_name/aserver/applications

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

8. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者が使用するユーザー名とパスワードを入力します。
「次へ」をクリックします。

9. 「サーバーの起動モードおよびJDKの構成」画面で、次の手順を実行します。

- 「WebLogicドメインの起動モード」には、「本番モード」を選択します。

- 「JDKの選択」では、「JROCKIT SDK1.6.0_<version>」を選択します。

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

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

10. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. OWSM MDSスキーマを選択します。

2. RACの構成には、(付録A「Oracle RACでのマルチ・データ・ソースの使用」で説明した)「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます。
ここの手順では、「GridLinkへ変換」を選択します。

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

11. 「GridLink RACコンポーネント・スキーマの構成」画面(図8-2)が表示されます。

図8-2 GridLink RACコンポーネント・スキーマの構成

この画面で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 10以上を選択します。

- サービス名: Oracle RACデータベースのサービス名と、続けてドメイン名を小文字で入力します。たとえば、wcpedg.example.comです。

- ユーザー名: 対応するコンポーネントのデータベースのスキーマ所有者の完全な名前(接頭辞を含む)を入力します。

- パスワード: データベース・スキーマ所有者のパスワードを入力します。

- 「FANの有効化」を選択します。

- 「SSLの有効化」のチェックが選択解除されていることを確認します(または、ONS通知の暗号化にSSLが選択されている場合、適切なウォレットとウォレット・パスワードを入力します)。

- サービス・リスナー: 使用しているOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。このプロトコルは、TCPである必要があります。
Oracle RACノードの追加または削除時にSCANアドレスを含むGridLinkデータ・ソースを更新する必要がないよう、サービス・リスナー(とOSNホスト)の指定にはSCANアドレスを使用することをお薦めします。SCANアドレスを判断するには、TCPプロトコルを使用し、データベースのremote_listenerパラメータを問い合せます。

SQL>show parameter remote_listener;

NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      custdbhost.example.com:1521

注意:
データベース・バージョンがSCANをサポートしない場合は次を実行します。

- Oracle Database 11gリリース1 (11.1)の場合、各データベースのインスタンス・リスナーの仮想IPとポートを次のように入力します。
custdbhost1-vip.example.com (Port 1521)

および

custdbhost2-vip.example.com (Port 1521)

- Oracle Database 10gの場合、マルチ・データ・ソースを使用し、Oracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- 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サービスのホスト名とポートを入力します。例:
custdbhost1.example.com (Port 6200)

および

custdbhost2.example.com (Port 6200)

12. 「JDBCコンポーネント・スキーマのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

13. 「オプションの構成を選択」画面で、次の項目を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

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

14. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: ADMINVHN

- リスニング・ポート: 7001

- SSLリスニング・ポート: 該当なし

- SSL有効: 選択解除

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

15. 「管理対象サーバーの構成」画面で、「追加」をクリックして次の管理対象サーバーを追加します。

表8-3 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_WSM1

SOAHOST1

7010

該当なし

いいえ

WLS_WSM2

SOAHOST2

7010

該当なし

いいえ

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

16. 「クラスタの構成」画面で、「追加」をクリックして次のクラスタを追加します。

表8-4 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

WSM-PM_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

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

17. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- WSM-PM_Cluster:

- WLS_WSM1

- WLS_WSM2

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

18. 「マシンの構成」画面で、次の手順を実行します。

- 「UNIXマシン」タブをクリックし、「追加」をクリックして次のマシンを追加します。

表8-5 マシン

名前脚注1

ノード・マネージャのリスニング・アドレス脚注2

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

localhost

脚注1 任意の一意の文字列

脚注2 解決可能なホスト名

他のフィールドはすべてデフォルト値のままにします。

注意:
localhostはすべてのアクティブなマシンの相対内部アドレスであるため、ADMINHOSTのノード・マネージャ・リスニング・アドレスはlocalhostを指す必要があります。管理サーバーはlocalhost属性と1つ目のノードを組み合せて使用し、フェイルオーバー後は2つ目のノードも使用するため、管理サーバーのフェイルオーバー時には管理サーバーと関連付けられているノード・マネージャのインスタンスは変更されます。

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

19. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- SOAHOST1: WLS_WSM1

- SOAHOST2: WLS_WSM2

- ADMINHOST: AdminServer

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

20. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、wsm-pmアプリケーションがWSM-PM_Clusterのみにターゲット設定されていることを確認します。その他のすべてのデプロイメントが「AdminServer」にターゲット設定されていることを確認します。「次へ」をクリックします。

21. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のように選択します。

- 左側で「WSM-PM_Cluster」を選択します。右側で「JDBCシステム・リソース」を選択します。これにより、すべてのwsmデータソース(mds-owsm)を自動的に選択できます。

- 左側で「管理サーバー」を選択します。右側で「JDBCシステム・リソース」を選択します。これにより、すべてのwsmデータソース(mds-owsm)を自動的に選択できます。

すべてのJDBCシステム・リソースが管理サーバーとWSM-PM_Clusterの両方にターゲット設定されている必要があります。

- 残りすべてのサービスが「管理サーバー」にターゲット設定されていることを確認します。

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

22. 「構成のサマリー」画面で「作成」をクリックします。

23. 「ドメインの作成」画面で「完了」をクリックします。

8.4 構成後タスクおよび検証タスク

構成ウィザードでドメインを構成した後は、次の手順に従って構成後タスクと検証タスクを実行します。

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

- 第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」

- 第8.4.2項「SOAHOST1でのノード・マネージャの起動」

- 第8.4.3項「SOAHOST1での管理サーバーの起動」

- 第8.4.4項「GridLinkデータ・ソースの構成の検証」

- 第8.4.5項「管理サーバー構成の検証」

- 第8.4.6項「管理サーバーと同じノードでの管理対象サーバー用独立ドメイン・ディレクトリの作成」

- 第8.4.7項「WSM-PM_ClusterへのJava Required Files(JRF)テンプレートの適用」

- 第8.4.8項「ホスト名検証の無効化」

- 第8.4.9項「WLS_WSM1管理対象サーバーの起動と検証」

8.4.1 SOAHOST1での管理サーバー用boot.propertiesの作成

SOAHOST1上で管理サーバーのboot.propertiesファイルを作成します。ノード・マネージャを使用して管理サーバーを起動するには、この手順を必ず実行する必要があります。

管理サーバーのboot.propertiesファイルを作成する手順は次のとおりです。

1. 次のディレクトリ構造を作成します。

mkdir -p ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security

2. テキスト・エディタで、次の行を記述したboot.propertiesというファイルを、前の手順で作成した最後のディレクトリに作成します。

username=Admin_Username
password=Password

注意:
管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で起動します。
セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を短くする必要があります。ファイルを編集した後、できるだけ速やかにサーバーを起動し、エントリを暗号化してください。

3. ファイルを保存してエディタを閉じます。

8.4.2 SOAHOST1でのノード・マネージャの起動

SOAHOST1でノード・マネージャを起動するには、StartScriptEnabledプロパティをtrueに設定し、startNodeManager.shを使用してノード・マネージャを起動します。

SOAHOST1でノード・マネージャを起動する手順は次のとおりです。

1. 次のディレクトリにあるsetNMProps.shスクリプトを実行します。

ORACLE_COMMON_HOME/common/bin

StartScriptEnabledプロパティをtrueに設定してから、ノード・マネージャを起動します。

cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

注意:
クラスのロードの失敗やその他の問題を回避するには、StartScriptEnabledプロパティを使用します。詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のSOAサーバーの再起動に失敗したためにポリシー移行が未完になることに関する項を参照してください。

2. ノード・マネージャを起動します。

nohup $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh \
> $MW_HOME/wlserver_10.3/common/nodemanager/nodemanager.out 2>&1 &

注意:
管理サーバーを管理するノード・マネージャ・インスタンスの起動時には、-DDomainRegistrationEnabled=trueを設定することが重要です。これは、管理サーバー・ドメイン・ホームがノード・マネージャのdomainsファイルになく、ドメインの動的な登録を使用する必要があるためです。ここで示している例を除き、このパラメータを使用することはお薦めしません。
このマシンに管理サーバーがなく、このマシンが管理サーバーのフェイルオーバー・ノードでない場合は、次のようにノード・マネージャを起動する必要があります。

./startNodeManager.sh

8.4.3 SOAHOST1での管理サーバーの起動

管理サーバーは、ノード・マネージャを使用して起動および停止します。ただし、初めてノード・マネージャで管理サーバーを起動するときに、構成ウィザードによりノード・マネージャにデフォルトで設定されているユーザー名とパスワードを変更する必要があります。そのため、管理サーバーの初回の起動時に起動スクリプトを使用します。

最初の起動操作には手順1から4が必要ですが、2回目以降の起動には手順4のみが必要です。

ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。

1. SOAHOST1上のドメイン・ディレクトリの起動スクリプトを使用して、管理サーバーを起動します。

cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin
./startWebLogic.sh

2. 管理コンソールを使用してノード・マネージャの資格証明を更新します。

1. ブラウザで、次のURLにアクセスします。
http://ADMINVHN:7001/console

2. 管理者としてログインします。

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

4. domain_name→「セキュリティ」→「一般」をクリックして、一番下にある「詳細」オプションを開きます。

5. ノード・マネージャの新しいユーザー名を入力するか、既存のユーザー名を書き留めておいてノード・マネージャのパスワードを更新します。

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

3. 管理サーバーのプロセスが起動したシェルで[Ctrl]キーを押しながら[C]キーを押すか、プロセスを確認してkillコマンドを使用し、管理サーバーを停止します。

4. WLSTを起動して、nmconnectと前の手順で設定した資格証明により、ノード・マネージャに接続し、nmstartを使用して管理サーバーを起動します。手順2eで入力した、ノード・マネージャのユーザー名とパスワードを入力します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルを起動したら、次のように指定します。

wls:/offline>nmConnect('NodeManager_Username','NodeManager_Password',
'SOAHOST1','5556','domain_name','/ORACLE_BASE/admin/domain_name/aserver/domain_name')

wls:/nm/domain_name nmStart('AdminServer')

注意:
このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/nodemanager

8.4.4 GridLinkデータ・ソースの構成の検証

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

GridLinkデータ・ソースの構成を検証する手順は次のとおりです。

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

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 新しいデータ・ソースの1つをクリックします。

4. 「監視」タブをクリックし、いずれかのサーバーを選択します。

5. 「統計」タブをクリックし、いずれかのサーバーを選択します。

6. 「ONS」→「テスト」タブをクリックします。

7. サーバーを選択し、「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

データ・ソースを使用するすべてのWebLogic Serverで、ONSテストを実行します。

8.4.5 管理サーバー構成の検証

ドメインに作成した管理サーバーが正しく構成されているかどうかを確認するため、Oracle WebLogic Server管理コンソールにログインして管理対象サーバーとクラスタが表示されることを確認し、Oracle Enterprise Managerにログインします。

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. ブラウザで、次のURLにアクセスします。

http://ADMINVHN:7001/console

2. 管理者としてログインします。

3. WLS_WSM1およびWLS_WSM2管理対象サーバーが表示されていることを確認します。

4. WSM-PM_Clusterが表示されていることを確認します。

5. 次のURLのOracle Enterprise Managerにアクセスできることを確認します。

http://ADMINVHN:7001/em

6. 第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してEnterprise Managerコンソールにログインします。

8.4.6 管理サーバーと同じノードでの管理対象サーバー用独立ドメイン・ディレクトリの作成

packコマンドおよびunpackコマンドを使用して、管理サーバーが使用するドメイン・ディレクトリを、SOAHOST1で管理対象サーバーが使用するドメイン・ディレクトリから分離します(ディレクトリを分離するこの処理は、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されています)。

unpackスクリプトを実行する前に、第4.3項「各種ディレクトリの推奨場所」に示すとおりORACLE_BASE/admin/domain_name/mserverディレクトリが存在することを確認してください。

独立ドメイン・ディレクトリを作成する手順は次のとおりです。

1. 次のように、packコマンドをSOAHOST1上で実行してテンプレート・パックを作成します。

SOAHOST1> 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

注意:
前回のpack/unpack処理からの指定されたテンプレート・パックjarファイルが存在する場合は、別の名前(wcdomaintemplate2.jarなど)を選択します。

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

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-template=wcdomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications -overwrite_domain=true

注意:
unpackコマンドを実行する前に、/ORACLE_BASE/admin/domain_nameディレクトリに対する書込み権限が必要です。たとえば、次のディレクトリに対してです。

/ORACLE_BASE/admin/wcpedg_domain/

8.4.7 WSM-PM_ClusterへのJava Required Files(JRF)テンプレートの適用

構成ウィザードを使用してドメインが作成された後、WebLogic Serverのインストールに含まれていない多数のリソースをWSM-PM_Clusterにターゲット設定する必要があります。

これらのリソースをターゲット設定するには:

1. 第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 左側のナビゲーション・ツリーで、「Farm_domain_name」→「WebLogicドメイン」→domain_nameを開き、「WSM-PM_Cluster」を選択します。

3. 右側で「JRFテンプレートの適用」をクリックします。

4. 画面に確認メッセージが表示されるのを待ちます。
このメッセージは、JRFテンプレートがWSM-PM_Clusterクラスタに正常に適用されたことを確認するものです。

8.4.8 ホスト名検証の無効化

この手順は、管理サーバーで様々なノードを認証するための適切な証明書をまだ設定していない場合に必要です(第11章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、様々なWebLogicサーバーを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証を行う際に、管理サーバーと各管理対象サーバーに対するホスト名の検証を無効にし、第11章「エンタープライズ・デプロイメント用のノード・マネージャの設定」の説明に従ってエンタープライズ・デプロイメント・トポロジの構成を完了した後に再びホスト名の検証を有効にします。

サーバーに対するホスト名の検証は、サーバーが起動して稼働するとただちに、管理サーバーから順に無効にできます。

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

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

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

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

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

5. 「サーバーのサマリー」ページで、「サーバー」表の「名前」列からサーバーの名前を選択します。「AdminServer(admin)」を選択します。

6. このサーバーの「設定」ページで、「SSL」タブをクリックします。

7. 「詳細」をクリックします。

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

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

10. WLS_WSM1およびWLS_WSM2サーバーに対して手順5から9を繰り返します。

11. 変更を保存してアクティブ化します。

12. これらの変更を有効にするには、管理サーバーを再起動する必要があります。

1. 「サーバーのサマリー」画面で、「制御」タブを選択します。

2. 表で「AdminServer(admin)」を選択して、「停止」をクリックします。

3. 管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して再度起動します。

8.4.9 WLS_WSM1管理対象サーバーの起動と検証

管理対象サーバーを構成後に起動し、正しく実行されているかどうかを確認します。Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーを起動しそのステータスを確認できます。

WLS_WSM1管理対象サーバーの起動と検証の手順:

1. 次の手順に従い、管理コンソールを使用して WLS_WSM1管理対象サーバーを起動します。

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

2. 「サーバー」を選択します。「サーバーのサマリー」ページが表示されます。

3. 「制御」タブをクリックします。

4. 「WLS_WSM1」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。
「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

3. 次のURLを使用して、Oracle WSM Policy Managerにアクセスします。

http://SOAHOST1:7010/wsm-pm

第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを入力します。

4. 「ポリシー・マネージャの検証」をクリックします。
構成が正しい場合は、データ・ストアで使用できるポリシーとアサーション・テンプレートのリストが表示されます。ポリシーやアサーション・テンプレートがまったく表示されない場合は、構成が正しくありません。

8.5 SOAHOST2へのドメイン構成の伝播

SOAHOST1の構成が完了したら、unpackユーティリティを使用してSOAHOST2に構成を伝播し、伝播した構成を検証します。

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

- 第8.5.1項「unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」

- 第8.5.2項「uploadおよびstageディレクトリの絶対パスへの変更」

- 第8.5.3項「WLS_WSM2管理対象サーバーに対するホスト名検証の無効化」

- 第8.5.4項「SOAHOST2でのノード・マネージャの起動」

- 第8.5.5項「WLS_WSM2管理対象サーバーの起動と検証」

8.5.1 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

unpackユーティリティを使用してドメイン構成を伝播します。unpackスクリプトを実行する前に、第4.3項「各種ディレクトリの推奨場所」の説明のとおり次のディレクトリが存在することを確認してください。

ORACLE_BASE/admin/domain_name/mserver

ドメイン構成を伝播する手順は次のとおりです。

1. 次のコマンドをSOAHOST1上で実行して、前の手順で作成したテンプレート・ファイルをコピーします。

cd ORACLE_COMMON_HOME/common/bin

scp wcdomaintemplate.jar oracle@SOAHOST2:/ORACLE_COMMON_HOME/common/bin

2. SOAHOST2のWL_HOME/common/binディレクトリではなく、ORACLE_COMMON_HOME/common/binディレクトリからunpackコマンドを実行し、伝播するテンプレートを解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-template=wcdomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications -overwrite_domain=true

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

ドメインを作成し、テンプレートをmserverディレクトリに解凍した後、uploadとstageディレクトリを更新します。これらのディレクトリは、デフォルトでは次の場所にあります。

./servers/server_name/upload

および

/u01/app/oracle/admin/wcpedg_domain/aserver/wcpedg_domain/servers/server_name/stage

これらのデフォルトのディレクトリ・パスは、リモート・デプロイメントでは問題を引き起こし、ステージ・モードを使用したデプロイメントでは混乱の原因となります。

これらの問題を防ぐには、uploadディレクトリを次のように更新します。

ORACLE_BASE/admin/wcpedg_domain/mserver/wcpedg_domain/servers/server_name/upload

また、stageディレクトリを次のように更新します。

ORACLE_BASE/admin/wcpedg_domain/mserver/wcpedg_domain/servers/server_name/stage

すべての管理対象サーバーで、これらのディレクトリ・パスを更新します。

これらのディレクトリを更新する手順は次のとおりです。

1. 管理コンソールにアクセスします。

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

3. 「サーバー」をクリックしてからサーバー名をクリックします。

4. 「構成」の「デプロイメント」タブで、UploadおよびStageディレクトリを変更します。

5. これらの変更を有効にするためにWLS_WSM1管理対象サーバーを再起動します(停止した後、再び起動する)。

8.5.3 WLS_WSM2管理対象サーバーに対するホスト名検証の無効化

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_SOA1およびWLS_SOA2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第11章「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

8.5.4 SOAHOST2でのノード・マネージャの起動

ドメイン構成を伝播しホスト名検証を無効にしたら、StartNodeManager.shスクリプトを使用してノード・マネージャを起動します。

SOAHOST2でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

注意:
クラスのロード失敗などの問題を回避するために、StartScriptEnabledプロパティを使用する必要があります。

2. ノード・マネージャを起動します。

cd WL_HOME/server/bin
./startNodeManager.sh

8.5.5 WLS_WSM2管理対象サーバーの起動と検証

管理コンソールを使用して、WLS_WSM2管理対象サーバーを起動して検証します。

WLS_WSM2管理対象サーバーを起動し、正しく構成されていることを確認する手順:

1. 管理コンソールを使用してWLS_WSM2管理対象サーバーを起動します。

2. 管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

3. 次のURLにアクセスします。

http://SOAHOST2:7010/wsm-pm

4. 「ポリシー・マネージャの検証」をクリックします。

8.6 Oracle WSMについてのJavaオブジェクト・キャッシュの構成

Oracle WSM Policy Managerを実行しているすべてのサーバーで、Javaオブジェクト・キャッシュ(JOC)を構成します。この手順はオプションですが、ローカル・キャッシュを保持することでキャッシュを検索する必要がなくなるため、Oracle WSMのパフォーマンスが向上します。

次のディレクトリにあるconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成できます。

MW_HOME/oracle_common/bin/

これはWLSTオンライン・モードで実行するPythonスクリプトであるため、管理サーバーが稼働している必要があります。

Oracle製品のJOCポートを構成する場合は、9988から9998の範囲のポートを使用することをお薦めします。

Oracle WSMのJavaオブジェクト・キャッシュを構成する手順は次のとおりです。

1. コマンド行のOracle WebLogic Scripting Tool (WLST)を使用して管理サーバーに接続します。例:

MW_HOME/wc/common/bin/wlst.sh
$ connect()

入力を求められたら、サーバーのURLおよびWebLogic管理者のユーザー名とパスワードを入力します。

2. WLSTを使用して管理サーバーに接続後、execfileコマンドを使用してスクリプトを開始します。たとえば、次のようにします。

wls:/mydomain/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")

3. 指定されたクラスタのすべての管理対象サーバーに対してJOCを構成します。
スクリプトでクラスタ名を指定するかどうかを尋ねられたら「y」と入力し、さらにクラスタ名と検出ポートの入力を求められたらそれらも指定します。これにより、指定したクラスタのすべての管理対象サーバーが検出され、JOCが構成されます。検出ポートはクラスタのJOC構成全体で共通です。例:

Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : WSM-PM_Cluster
Enter Discover Port : 9991

configure-joc.pyをHA環境で使用するための手順は、次のとおりです。

execfile("MW_HOME/oracle_common/bin/configure-joc.py")
.
Enter Hostnames (eg host1,host2) : SOAHOST1,SOAHOST2
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : WSM-PM_Cluster
.
Enter Discover Port : 9991
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n

4. WLSTコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成した後で、構成を有効にするために、影響を受ける管理対象サーバーをすべて再起動します。

このスクリプトは、次のオプションのJOC構成の実行にも使用できます。

- 指定されたすべての管理対象サーバーに対してJOCを構成します。
スクリプトにより、クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたら「y」と入力し、そしてプロンプトが表示されたらクラスタ名と検出ポートも指定します。例:

Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WLS_WSM1:9998, WLS_WSM1:9998) : WLS_WSM1:9991,WLS_WSM2:9991

- 特定の管理対象サーバーの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) : WLS_WSM1,WLS_WSM3

- すべての管理対象サーバーに対して分散モードを無効にします。
スクリプトにより、指定されたクラスタのすべての管理対象サーバーに対して分散を無効化できます。分散モードに関するプロンプトが表示されたら'false'を指定します。デフォルトでは、分散モードは'true'に設定されています。

CacheWatcherユーティリティを使用してJOCの構成を確認します。詳細は、『Oracle Fusion Middleware高可用性ガイド』の分散Javaオブジェクト・キャッシュの構成に関する項を参照してください。

8.7 WebLogic ServerドメインのOracle HTTP Serverの構成

この項では、WebLogic ServerドメインにおけるOracle HTTP Serverの構成タスクおよびその構成の検証タスクについて説明します。

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

- 第8.7.1項「管理サーバーとWLS_WSMn管理対象サーバーについてのOracle HTTP Serverの構成」

- 第8.7.2項「WebLogicプラグイン有効化フラグの有効化」

- 第8.7.3項「WebLogic ServerへのOracle HTTP Serverの登録」

- 第8.7.4項「管理コンソールのフロントエンドURLの設定およびリダイレクション・プリファレンスの設定」

- 第8.7.5項「Oracle HTTP Serverを介したアクセスの検証」

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

8.7.1 管理サーバーとWLS_WSMn管理対象サーバーについてのOracle HTTP Serverの構成

管理サーバーおよびWSM-PM_Cluster (WLS_WSMn管理対象サーバーを含む)へのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタのノード・リストに設定する必要があります。

管理サーバーとWLS_WSMn管理対象サーバーのOracle HTTP Serverを構成する手順:

1. WEBHOST1とWEBHOST2上で、次のディレクトリにあるadmin_vh.confおよびwcpinternal_vh.confファイルにディレクティブを追加します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

第7.6項「仮想ホストの定義」の指示に従って、admin_vh.confおよびwcpinternal_vh.confファイルを作成しておく必要があります。

1. 例8-1に太字で示したディレクティブを、admin_vh.confファイルに追加します。
admin_vh.confファイルは、例8-1のように表示されます。

例8-1 admin_vh.confファイル

# Admin URLs are only accessible through the admin virtual host

<VirtualHost *:7777>
ServerName admin.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>

注意:
このドキュメントに示された7777、admin.example.com:80、you@your.addressなどの値は、単なる例です。これらのかわりに、実際の環境に基づいた値を入力してください。

2. 例8-1に太字で示したディレクティブを、wcpinternal_vh.confファイルに追加します。WebLogicClusterパラメータを、クラスタ内のノードのリストに設定します。
wcpinternal_vh.confファイルは、例8-1のように表示されます。

例8-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>

</VirtualHost>

2. 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サーバー・プラグインの使い方』を参照してください。

8.7.2 WebLogicプラグイン有効化フラグの有効化

セキュリティのため、またロード・バランサがSSLリクエストを終了するため(Oracle HTTP ServerはリクエストをWebLogic Serverに非SSLとしてルーティングします)、ロード・バランサにSSLを構成した場合、そのドメインに対しWebLogicプラグイン有効化フラグをオンにする必要があります。

WebLogicプラグイン有効化フラグを有効にする手順は次のとおりです。

1. 管理コンソールにログオンします。

2. 左側のナビゲーション・ツリーでドメイン名をクリックします。

3. 「Webアプリケーション」タブをクリックします。

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

5. 「WebLogicプラグインの有効化」チェック・ボックスを選択します。

6. 変更を保存してアクティブ化します。

8.7.3 WebLogic ServerへのOracle HTTP Serverの登録

Oracle WebLogic Serverドメインが作成されたら、Oracle Web層をドメインに接続できます。これには、Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Web層を管理および監視できるというメリットがあります。

Oracle Web層をWebLogic Serverドメインに関連付けるには、WEBHOST1で次のコマンドを実行します。

WEBHOST1> cd ORACLE_BASE/admin/instance_name/bin

WEBHOST1> ./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic

このコマンドは、OHS2に対してWEBHOST2からも実行する必要があります。

登録したOracle HTTP ServerはFusion Middleware Controlで管理可能なターゲットとして表示されます。これを確認するには、Fusion Middleware Controlにログインします。ナビゲーション・ツリーにある「WebTier」項目に、該当のOracle HTTP Serverが登録されていることが示されます。

8.7.4 管理コンソールのフロントエンドURLの設定およびリダイレクション・プリファレンスの設定

ロード・バランサを使用してOracle WebLogic Server管理コンソールにアクセスする場合、管理サーバーのフロントエンドURLを変更し、ユーザーのブラウザが適切なロード・バランサ・アドレスにリダイレクトされるようにする必要があります。

Oracle WebLogic Server管理コンソール・アプリケーションでは、コンソールを使用して、ポート、チャネル、セキュリティに対する変更を追跡します。コンソールを使用して行われた変更をアクティブ化するとき、コンソールは現在のリスニング・アドレス、ポートおよびプロトコルを検証します。このリスニング・アドレス、ポートおよびプロトコルがまだ有効の場合、コンソールはHTTPリクエストをリダイレクトし、ホストとポートの情報を管理サーバーのリスニング・アドレスとポートに置き換えます。

管理サーバーのフロントエンドURLを変更する手順は次のとおりです。

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

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

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

4. 「サーバー」をクリックして、「サーバーのサマリー」ページを開きます。

5. 表の「名前」列で「管理サーバー」を選択します。「AdminServer(admin)」の「設定」ページが表示されます。

6. 「プロトコル」タブをクリックします。

7. 「HTTP」タブをクリックします。

8. 「フロントエンド・ホスト」を「admin.example.com」に設定し、「フロントエンドHTTPポート」を「80」に設定します(管理URLにHTTPSを使用する場合は、適宜変更します)。

9. 変更を保存してアクティブ化します。

10. 変更がアクティブ化されたときにコンソールで構成ページがリロードされないように、Oracle WebLogic Server管理コンソールで構成変更の追跡を無効にします。

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

2. バナー内の「プリファレンス」リンクをクリックします。

3. 「共有プリファレンス」タブをクリックします。

4. 「構成変更の追跡」チェック・ボックスの選択を解除します。

注意:
フロントエンド・ホストやポートの設定を変更した後、構成の変更をアクティブ化できない場合は、第16.9.2項「管理コンソールで変更をアクティブ化した後にユーザーがログイン画面にリダイレクトされる」を参照してください。

8.7.5 Oracle HTTP Serverを介したアクセスの検証

Oracle HTTP Serverを介したアクセスを検証する手順は次のとおりです。

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

次のロード・バランサURLを検証し、Oracle HTTP ServerからWSM-PM_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

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

- http://admin.example.com/console

- http://admin.example.com/em

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

第8.7.3項「WebLogic ServerへのOracle HTTP Serverの登録」の説明に従ってOracle HTTP Serverを登録すると、そのOracle HTTP Serverは管理可能なターゲットとしてOracle Enterprise Manager Consoleに表示されます。これを確認するには、Enterprise Manager Consoleにログインします。ナビゲーション・ツリーにある「WebTier」項目に、該当のOracle HTTP Serverが登録されていることが示されます。

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

ドメインを構成したら、第16.7項「管理サーバーの手動フェイルオーバーの検証」の手順に従ってフェイルオーバーをテストします。

8.8 WebLogic Serverドメイン構成のバックアップ

バックアップを実行してドメイン構成を保存します。最初にサーバーが停止していることを確認します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/admin/domain_name

ドメイン構成をバックアップするには、SOAHOST1で次のコマンドを実行します。

tar -cpzf BACKUP_LOCATION/edg8.8_fmwhome.tgz MW_HOME

次のコマンドを使用して、Web層のインスタンス・ホームをバックアップします。

tar -cpzf BACKUP_LOCATION/edg8.8_OHS_web_instances.tgz ORACLE_INSTANCE

9 SOAコンポーネントを使用するためのドメインの拡張

この章では、構成ウィザードを使用して、SOAコンポーネントを扱うことができるようにドメインを拡張する方法を説明します。ドメインは第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成しました。

注意:

- SOAHOST1とSOAHOST2でSOAコンポーネントを実行する場合にのみ、この章の手順に従ってください。WebCenter PortalトポロジでSOAコンポーネントを実行しない場合は、この章は省略できます。

- セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

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

- SOAコンポーネントを使用するためのドメインの拡張の概要

- Oracle SOAコンポーネント用のドメインの拡張の準備

- 構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張

- コンポジットをデプロイするためのOracle Coherenceの構成

- 構成後タスクおよび検証タスク

- 拡張したドメインでのOracle HTTP Serverの構成

- Configuring a Default Persistence Store for Transaction Recovery

- Oracleアダプタの構成

- SOA構成のバックアップ

9.1 SOAコンポーネントを使用するためのドメインの拡張の概要

Oracle WebLogic Serverドメインを拡張して、Oracle SOAコンポーネントを追加します。表9-1に、Oracle SOAの構成手順と、Oracle SOAコンポーネントを使用するためのドメインの拡張に必要なタスクを示します。

表9-1 SOAコンポーネントを使用するためのドメインの拡張の手順

手順

説明

詳細

SOAコンポーネントを使用するためのドメインの拡張の準備

各ホスト名のVIPマッピングを有効化します。

第9.2.1項「SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化」

SOAコンポーネントを使用するためのドメインの拡張

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogic Serverドメインを拡張します。

第9.3項「構成ウィザードを使用したSOAコンポーネントのためのドメインの拡張」

コンポジットをデプロイするためのOracle Coherenceの構成

コンポジットのデプロイにユニキャスト通信を使用するためOracle Coherenceを構成します。

第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」

構成後タスクおよび検証タスク

構成後タスクおよび検証タスクの手順に従います。

第9.5項「構成後タスクおよび検証タスク」

SOAHOST1へのドメイン構成の伝播

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

第9.5.3項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」

拡張したドメインでのOracle HTTP Serverの構成

管理対象サーバーとともにOracle HTTP Serverを構成し、アクセスの検証、フロントエンドHTTPのホストおよびポートの設定およびSOA_ClusterのWLSクラスタ・アドレスを設定します。

第9.6項「拡張したドメインでのOracle HTTP Serverの構成」

デフォルト永続ストアの構成

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

第9.7項「トランザクション・リカバリ用デフォルト永続ストアの構成」

Oracleアダプタの構成

OracleファイルおよびFTPアダプタの高可用性およびOracle JMSアダプタの高可用性を有効化し、Oracle Databaseアダプタをスケーリングします。

第9.8項「Oracleアダプタの構成」

SOA構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第9.9項「SOA構成のバックアップ」

9.2 Oracle SOAコンポーネント用のドメインの拡張の準備

構成ウィザードを実行し、ドメインを拡張する前に、2つのSOAマシン上で各ホスト名のVIPマッピングを有効化します。

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

- 第9.2.1項「SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化」

9.2.1 SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化

Oracle WebCenter Portalドメインでは、Oracle SOA Suite管理対象サーバー用リスニング・アドレスに仮想ホスト名を使用します。2つのSOAマシンでそれぞれのホスト名の仮想IPマッピングを有効にして(SOAHOST1上のVIP2およびSOAHOST2上のVIP3)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーまたは/etc/hosts/解決のいずれかで)正しく解決する必要があります(まだこの作業を行っていない場合)。

仮想IPを有効にするには(まだこの作業を行っていない場合)、第3.5項「エンタープライズ・デプロイメント用の仮想IPアドレスの有効化」に記載されている手順を実行します。これらの仮想IPおよびVHNは、Oracle SOA Suiteサーバーからのサーバーの移行を有効にするために必要です。高可用性を実現するために、後からSOAシステムに対するサーバーの移行を構成できます。サーバーの移行の構成の詳細は、第14章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。

9.3 構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張

構成ウィザードを使用して、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを、SOAコンポーネントを使用できるように拡張します。

この項では、SOAデプロイメントが、WebCenter Portalデプロイメントと同じデータベース・サービス(wcpedg.example.com)を使用することを前提としています。ただし、デプロイメントではSOA専用の別のデータベース・サービス(soaedg.example.comなど)の使用を選択することもできます。

注意:
第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインをバックアップしていない場合は、SOAコンポーネントを使用するためにドメインを拡張する前に、現在のドメインをバックアップします。ドメインの拡張時にエラーが発生した場合は、このバックアップを使用してリカバリできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の「環境のバックアップ」を参照してください。

構成ウィザードを使用してドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内のすべての管理対象サーバーを停止します。

3. 構成ウィザードの場所にディレクトリを変更します。これはOracle共通ホーム・ディレクトリ内です(ドメインの拡張は、管理サーバーが存在するSOAHOST1から実行することに注意してください)。

cd ORACLE_COMMON_HOME/common/bin

4. export CONFIG_JVM_ARGS="-Djava.security.egd=file:/dev/./urandom"

5. 構成ウィザードを開始します。

./config.sh

6. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

7. 「WebLogicドメイン・ディレクトリ」画面で、次のWebLogic Serverドメイン・ディレクトリを選択します。

ORACLE_BASE/admin/domain_name/aserver/domain_name

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

8. 「拡張ソースの選択」画面で、次の手順を実行します。

1. 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

2. 次の製品を選択します。

- Oracle SOA Suite 11.1.1.0

次の製品はすでに選択されてグレー表示されています。これらは、第8.3項「SOAHOST1での構成ウィザードによるドメインの作成」の手順でドメインを作成したときに選択されたものです。

- WebLogic Serverの基本ドメイン

- Oracle Enterprise Manager

- Oracle WSM Policy Manager

- Oracle JRF

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

9. このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。

10. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. 「SOAインフラストラクチャ」→「ユーザー・メッセージング・サービス」→SOA MDSスキーマを選択します。

2. コンポーネント・スキーマのRAC構成については、「GridLinkへ変換」を選択します。
RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます。後者のオプションについては、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

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

図9-1 GridLink RACコンポーネント・スキーマの構成

11. 「GridLink RACコンポーネント・スキーマの構成」画面で(図9-1)、次の手順を実行します。

1. 表で「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」および「SOA MDSスキーマ」を選択します。

2. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 10以上を選択します。

- サービス名: データベースのサービス名と、続けてドメイン名を小文字で入力します。たとえば、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をサポートしない場合は次を実行します。

- Oracle Database 11gリリース1 (11.1)の場合、各データベースのインスタンス・リスナーの仮想IPとポートを次のように入力します。
custdbhost1-vip.example.com (Port 1521)

および

custdbhost2-vip.example.com (Port 1521)

- Oracle Database 10gの場合、マルチ・データ・ソースを使用し、Oracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: データベースからの通知のとおり、Oracle RACデータベースのSCANアドレスとONSリモート・ポートを入力します。

[orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:
Oracle Database 11gリリース1 (11.1)の場合、データベースのONSサービスのホスト名とポートを入力します。例:
custdbhost1.example.com (Port 6200)

および

custdbhost2.example.com (Port 6200)

3. 「SOAインフラストラクチャ」のみを選択し、このデータベース・スキーマのユーザー名とパスワードを入力します。

- ユーザー名: 対応するコンポーネントのデータベースのスキーマ所有者の完全な名前(接頭辞を含む)を入力します。接頭辞は第5.4項「Oracle RACデータベースへのOracle Fusionメタデータ・リポジトリのロード」で作成したものと一致する必要があります。

- パスワード: データベース・スキーマ所有者のパスワードを入力します。

4. 「ユーザー・メッセージング・サービス」、「SOA MDSスキーマ」には、手順cを繰り返します。

5. すべてのSOAスキーマの値が正しい場合、(「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」および「SOA MDSスキーマ」)、「次へ」をクリックします。

12. 「JDBCデータ・ソースのテスト」画面で、すべての接続が正常であることを確認します。
接続のテストは自動的に行われます。「ステータス」列に結果が表示されます。正常でない接続がある場合は、「前へ」をクリックして前の画面に戻り、入力を訂正します。

すべての接続に成功したら「次へ」をクリックします。

13. 「オプションの構成を選択」画面で、次の項目を選択します。

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

- JMSファイル・ストア

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

14. 「JMS分散宛先タイプの選択」画面で、すべてのJMSシステム・リソースがUDDとして構成されていることを確認します。これがデフォルトです。

注意:
「オーバーライドの警告」ダイアログ・ボックスで、「OK」をクリックします。

15. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
soa_server1というサーバーが自動的に作成されます。

1. 自動的に作成されたサーバーを選択し、「名前の変更」をクリックして、名前を「WLS_SOA1」に変更します。

2. 「追加」をクリックし他の新規サーバーを追加して、サーバー名として「WLS_SOA2」と入力します。

3. WLS_SOA1およびWLS_SOA2サーバーに、表9-2内の属性を指定します。この画面に表示されている他のサーバーは変更せず、そのままにしておきます。

表9-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_SOA1

SOAHOST1VHN1

8001

該当なし

いいえ

WLS_SOA2

SOAHOST2VHN1

8001

該当なし

いいえ

WLS_WSM1

SOAHOST1

7010

該当なし

いいえ

WLS_WSM2

SOAHOST2

7010

該当なし

いいえ

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

16. 「クラスタの構成」画面で、次のクラスタを追加します。

表9-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

SOA_Cluster

ユニキャスト

該当なし

該当なし

SOAHOST1VHN1:8001,SOAHOST2VHN1:8001

WSM-PM_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

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

注意:
直接バインディングを介してリクエスト/レスポンスが非同期でやり取りされるようにするため、SOAコンポジットでは、JNDIプロバイダURLを提供して、呼び出されたサービスが、コールバックするBeanを検索できるようにする必要があります。
soa-infraの構成プロパティは指定されていないがWebLogic Serverクラスタ・アドレスが指定されている場合は、JNDIプロバイダURLのクラスタ・アドレスが使用されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名を指定することも、サーバーip:portのカンマ区切りリストを指定することもできます。また、ユーザーが明示的に設定していれば、soa-infraの構成プロパティJndiProviderURL/SecureJndiProviderURLを同じ目的に使用することもできます。

17. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- SOA_Cluster:

- WLS_SOA1

- WLS_SOA2

- WSM-PM_Cluster:

- WLS_WSM1

- WLS_WSM2

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

18. 「マシンの構成」画面で、デフォルトで表示されるLocalMachineを削除し、「Unixマシン」タブをクリックします。
表9-4に示すエントリが表示されます。

表9-4 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

localhost

その他すべてのフィールドはデフォルト値のままにします。

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

19. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- ADMINHOST:

- AdminServer

- SOAHOST1:

- WLS_SOA1

- WLS_WSM1

- SOAHOST2:

- WLS_SOA2

- WLS_WSM2

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

20. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定します。(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです。)

- oracle.sdp.*およびoracle.soa.*ライブラリは、SOA_Clusterにのみターゲット設定します。

- oracle.rules.*ライブラリは、管理サーバーおよびSOA_Clusterにのみターゲット設定します。

- wsm-pmアプリケーションは、WSM-PM_Clusterにターゲット設定します。
(Oracle Web Services ManagerをSOA_Clusterにデプロイする予定である場合は、wsm-pmアプリケーションをSOA_Clusterにもターゲット設定します。)

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

21. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- mds-owsmをWSM-PM_ClusterとAdminServerの両方のターゲットとします。
(手順17でOracle Web Services ManagerをSOA_Clusterにデプロイした場合は、mds-owsmもSOA_Clusterにターゲット設定します。)

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

22. 「JMSファイル・ストアの構成」画面で、第4.3項「各種ディレクトリの推奨場所」での推奨に従って各JMSストアに指定した共有ディレクトリの場所を入力します。例:

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

パスORACLE_BASE/admin/domain_name/soa_cluster_name/jms/で始まるように各行を更新します。

同期書込みフィールドは空のままにします。

Name: Directory:

------------------------------------------------------------------------------

UMSJMSFileStore_auto_1 /u01/app/oracle/admin/wcdomain/soa_cluster/jms/UMSJMSFileStore_auto_1

UMSJMSFileStore_auto_2 /u01/app/oracle/admin/wcdomain/soa_cluster/jms/UMSJMSFileStore_auto_2

PS6SOAJMSFileStore_auto1 /u01/app/oracle/admin/wcdomain/soa_cluster/jms/PS6SOAJMSFileStore_auto1

PS6SOAJMSFileStore_auto2 /u01/app/oracle/admin/wcdomain/soa_cluster/jms/PS6SOAJMSFileStore_auto2

BPMJMSFileStore_auto_1 /u01/app/oracle/admin/wcdomain/soa_cluster/jms/BPMJMSFileStore_auto_1

BPMJMSFileStore_auto_2 /u01/app/oracle/admin/wcdomain/soa_cluster/jms/BPMJMSFileStore_auto_2

SOAJMSFileStore_auto_1 /u01/app/oracle/admin/wcdomain/soa_cluster/jms/SOAJMSFileStore_auto_1

SOAJMSFileStore_auto_2 /u01/app/oracle/admin/wcdomain/soa_cluster/jms/SOAJMSFileStore_auto_2

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

23. 「構成のサマリー」画面で「拡張」をクリックします。

注意:
ドメイン構成ポートがホスト・ポートと競合していることを警告するダイアログが表示されますが、「OK」をクリックして閉じてください。この警告は、すでにインストールされているWSM-PMが原因で表示されます。

24. 「ドメインの拡張」画面で、「完了」をクリックします。

25. 管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で再起動します。

9.4 コンポジットをデプロイするためのOracle Coherenceの構成

コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。

ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

注意:
デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムを実行するネットワーク環境に応じて、デプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。

9.4.1 ユニキャスト通信を使用したデプロイメントの通信の有効化

tangosol.coherence.wkanシステム・プロパティを使用してノードを指定します(nは1から9の番号)。Well Knownアドレスとして最大9ノードまで指定できますが、クラスタには10以上のノードを作成できます。番号は、1から開始します。この番号付けは、連続的で間隙を含まないようにする必要があります。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHN1とSOAHOST2VHN1)。Oracle WebLogic Server管理コンソールでこのプロパティを設定するには、「サーバーの起動」タブの「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図9-2)。

ヒント:
SOAコンポジットのデプロイ時に高可用性を確保するには、適切な数のノードを指定して、どの時点でもそのうちのいずれかが必ず稼働しているようにします。

注意:
SOAHOST1VHN1は、SOAHOST1でWLS_SOA1がリッスンする仮想IPにマップされる仮想ホスト名です。SOAHOST2VHN1は、SOAHOST2でWLS_SOA2がリッスンする仮想IPにマップされる仮想ホスト名です。

図9-2 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定

9.4.2 Oracle Coherenceで使用するホスト名の指定

管理コンソールを使用して、Oracle Coherenceで使用するホスト名を指定します。

Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。

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

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

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列にハイパーリンクで表示されているサーバーの名前(WLS_SOA1またはWLS_SOA2)をクリックします。選択したサーバーの「設定」ページが表示されます。

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

6. 「サーバーの起動」タブをクリックします(図9-2を参照)。

7. WLS_SOA1とWLS_SOA2について、「引数」フィールドに次の値を入力します。

注意:
異なる-Dパラメータの間には、空白の行を入れないでください。テキストは、前述の場所からコピーして管理コンソールの引数テキスト・フィールドに貼り付けないでください。貼り付けると、Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。

注意:
デプロイメントに使用されるCoherenceクラスタは、デフォルトでポート8088を使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。例:
WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』の「Coherenceクラスタの使用」を参照してください。

WLS_SOA1については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1

WLS_SOA2については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1

8. 「保存」→「変更のアクティブ化」をクリックします。

注意:
これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります。(これらの変数はサーバーの出力ログに記録されます。)Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。

注意:
このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。

9.5 構成後タスクおよび検証タスク

構成ウィザードでドメインを拡張し、Oracle Coherenceを構成したら、次の手順に従って、構成後タスクと検証を行います。

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

- 第9.5.1項「WLS_SOAn管理対象サーバーに対するホスト名検証の無効化」

- 第9.5.2項「SOAHOST1でのノード・マネージャの再起動」

- 第9.5.3項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」

- 第9.5.4項「WLS_SOA1管理対象サーバーの起動と検証」

- 第9.5.5項「unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」

- 第9.5.6項「uploadおよびstageディレクトリの絶対パスへの変更」

- 第9.5.7項「WLS_SOA2管理対象サーバーの起動と検証」

- 第9.5.8項「Oracle SOA SuiteのGridLinkデータ・ソースの検証」

9.5.1 WLS_SOAn管理対象サーバーに対するホスト名検証の無効化

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。異なるWebLogic Serverを管理する場合のエラーを防止するには、WLS_SOAn管理対象サーバーのホスト名検証を無効化する必要があります。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第11.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

9.5.2 SOAHOST1でのノード・マネージャの再起動

startNodeManager.shスクリプトを使用してノード・マネージャを再起動します。

SOAHOST1でノード・マネージャを再起動する手順は次のとおりです。

1. ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。

- シェルのフォアグラウンドで実行されている場合は、[Ctrl]を押しながら[C]を押します。

- シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、killコマンドを使用して停止します。例:

ps -ef | grep NodeManager
orcl      9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh

kill -9 9139

2. ノード・マネージャを起動します。

./startNodeManager.sh

9.5.3 管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播

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

起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリをバックアップします。

tar -cpzf BACKUP_LOCATION/edg9.5.3-doman_name.tgz ORACLE_BASE/admin/domain_name

2. 次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=soadomaintemplateExtSOA.jar -template_name=soadomaintemplateExtSOA

注意:
前回のpack/unpack処理からの指定されたテンプレート・パックjarファイルが存在する場合は、別の名前(soadomaintemplateExtSOA2.jarなど)を選択します。

3. 次のようにunpackコマンドをSOAHOST1上で実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-overwrite_domain=true -template=soadomaintemplateExtSOA.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

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

注意:
WLS_WSMサーバーが実行されている場合、ポートの競合を示すメッセージが表示されることがあります。この警告を無視して続行できます。

9.5.4 WLS_SOA1管理対象サーバーの起動および検証

管理コンソールを使用してWLS_SOA1管理対象サーバーを起動し、検証します。

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

1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。

1. 次のURLの管理コンソールにアクセスします。

http://ADMINVHN:7001/console

ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。

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

3. 「サーバー」をクリックします。
「サーバーのサマリー」画面が表示されます。

4. 「制御」タブをクリックします。

5. 「WLS_WSM1」および「WLS_WSM2」を選択し、「起動」をクリックします。

6. この2つのサーバーのステータスが「実行中」として報告されることを確認します。いずれかのサーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

7. 「WLS_SOA1」を選択して、「起動」をクリックします。

2. WLS_SOA1サーバーのステータスが「実行中」として報告されることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

3. 次のURLにアクセスして、WLS_SOA1のステータスを確認します。

http://SOAHOST1VHN1:8001/soa-infra/

次のURLにアクセスして、ワークリスト・アプリケーションのステータスを確認します。

http://SOAHOST1VHN1:8001/integration/worklistapp/

次のURLにアクセスして、コンポーザ・アプリケーションのステータスを確認します。

http://SOAHOST1VHN1:8001/soa/composer/

アクセスが許可されていることを確認する前に、少なくとも1つの管理対象サーバー(WLS_WSM1またはWLS_WSM2)が稼働していることを確認します。

9.5.5 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

unpackユーティリティを使用して、構成したドメインをSOAHOST2に伝播します。

ドメイン構成を伝播する手順は次のとおりです。

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

cd ORACLE_COMMON_HOME/common/bin

scp soadomaintemplateExtSOA.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin

2. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh
-domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/
-template=soadomaintemplateExtSOA.jar -overwrite_domain=true
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

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

注意:
このエンタープライズ・デプロイメント・トポロジで提供されている構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されると想定しています。

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

uploadおよびstageディレクトリを更新します。詳細な手順は、第8.5.2項「uploadおよびstageディレクトリの絶対パスへの変更」を参照してください。

これらの変更を有効にするには、管理コンソールでWLS_SOA1管理対象サーバーを再起動します(停止した後、再び起動する)。

9.5.7 WLS_SOA2管理対象サーバーの起動と検証

管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。soa-infraおよびworklistappのURLにアクセスして検証します。

WLS_SOA2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順:

1. 管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

3. 次のURLでsoa-infraにアクセスします。

http://SOAHOST2VHN1:8001/soa-infra

4. 次のURLにアクセスして、worklistappアプリケーションのステータスを確認します。

http://SOAHOST2VHN1:8001/integration/worklistapp/

アクセスが許可されていることを確認する前に、少なくとも1つの管理対象サーバー(WLS_WSM1またはWLS_WSM2)が稼働していることを確認します。

注意:
WLS_SOA2サーバーが稼働していても、一部のアプリケーションが失敗した状態になることがあります。そのため、前述のURLを検証し、個別のアプリケーションに関するエラーがないか、サーバーの出力ファイルで確認することをお薦めします。

5. 次のURLにアクセスして、composerアプリケーションのステータスを確認します。

http://SOAHOST2VHN1:8001/soa/composer/

9.5.8 Oracle SOA SuiteのGridLinkデータ・ソースの検証

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

- fgEDNDataSource

- ENLocalTxDataSource

- mds-soa

- ORASDPMDataSource

- SOADataSource

- SOALocalTxDataSource

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

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

2. 「ドメイン構造」ツリーの「サービス」を展開し、「データ・ソース」を選択します。

3. データ・ソースをテストします。

1. データ・ソース名(EDNDataSourceなど)をクリックします。

2. 「監視」タブをクリックします。

3. 「テスト」タブをクリックします。

4. すべてのサーバー・デプロイメントの状態が「実行中」であることを確認します。

- WLS_SOA1

- WLS_SOA2

5. WLS_SOA1サーバー行を選択します。

6. 「データソースのテスト」をクリックします。

7. テストが成功したことを確認します。

8. WLS_SOA2サーバー行を選択します。

9. 「データ・ソースのテスト」をクリックします(図9-3)。

10. テストが成功したことを確認します。
構成が正しい場合、テストは成功します。

図9-3 GridLinkデータ・ソースのテスト

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

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

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 「統計」タブをクリックします。

4. デプロイ済インスタンスの一覧から「WLS_SOA1」をクリックします。

5. 「ONS」タブをクリックし、「テスト」タブをクリックします。

6. 「WLS_SOA1」を選択し、「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

7. テストが成功したことを確認します。

8. WebLogic Serverナビゲーションの同じデータ・ソースをクリックします。

9. 「監視」タブをクリックします。

10. デプロイ済インスタンスの一覧から「WLS_SOA2」をクリックします。

11. 「ONS」タブをクリックし、「テスト」タブをクリックします(図9-4)。

図9-4 ONSの設定のテスト

12. 「WLS_SOA2」を選択し、「ONSのテスト」をクリックします。
構成が正しい場合、ONSのテストは成功します。ONSのテストが失敗する場合、Oracle RACデータベース・ノードでONSサービスが実行されていることを確認します。

9.6 拡張したドメインでのOracle HTTP Serverの構成

ドメイン構成をSOAHOST2に伝播した後、拡張したドメインでOracle HTTP Serverを構成します。

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

- 第9.6.1項「WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成」

- 第9.6.2項「Oracle HTTP Serverを介したアクセスの検証」

- 第9.6.3項「フロントエンドHTTPホストおよびポートの設定」

9.6.1 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

WLS_SOAn管理対象サーバーを含むSOA_ClusterへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタのノード・リストに設定する必要があります。

Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。

1. WEBHOST1とWEBHOST2上で、例9-1で太字で示したディレクティブを、次のディレクトリにあるwcp_vh.confファイルに追加します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

第7.6項「仮想ホストの定義」の指示に従って、wcp_vh.confファイルを作成している必要があります。

wcp_vh.confファイルは例9-1のように表示されます。

例9-1 wcp_vh.confファイル

<VirtualHost *:7777>
ServerName https://wcp.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

Debug ERR
DebugConfigInfo ON
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/${COMPONENT_TYPE}/${COMPONENT_NAME}/wcp_vh_wls.log"

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

</VirtualHost>

2. 同様に、例9-2に太字で示したディレクティブを、同じ場所にあるwcpinternal_vh.confファイルに追加します。
wcpinternal_vh.confファイルは、例9-2のように表示されます。

例9-2 wcpinternal_vh.confファイル

<VirtualHost *:7777>
ServerName wcpinternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

Debug ERR
DebugConfigInfo ON
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/${COMPONENT_TYPE}/${COMPONENT_NAME}/wcpinternal_vh_wls.log"

# 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>

</VirtualHost>

3. 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サーバー・プラグインの使用』を参照してください。

9.6.2 Oracle HTTP Serverを介したアクセスの検証

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

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

- https://wcp.example.com/soa-infra

- http://wcpinternal.example.com/integration/worklistapp

- https://wcp.example.com/sdpmessaging/userprefs-ui

- https://wcp.example.com/soa/composer

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

9.6.3 フロントエンドHTTPホストおよびポートの設定

この項では、フロントエンドHTTPのホストとポートを管理コンソールを使用して設定する手順を示します。コールバックURLがどのように決定されるかについても説明します。

9.6.3.1 フロントエンドHTTPホストおよびポートの設定

Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定する手順は次のとおりです。

1. WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。

2. 左ペインの「ドメイン構造」ウィンドウで「環境」を選択し、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

3. SOA_Clusterクラスタを選択します。

4. 「HTTP」を選択します。

5. 次の値を設定します。

- フロントエンド・ホスト: wcp.example.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80

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

7. 変更を有効にするために、管理コンソールの「チェンジ・センター」セクションの「変更のアクティブ化」をクリックします。

8. サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。

注意:
ロード・バランサでHTTPSが有効になっており、SSLがロード・バランサで終了する場合(SOAサーバーはHTTPSではなくHTTPリクエストのみを受信します)、ここに示しているように、Webサービスのエンドポイント・プロトコルはhttpに設定されます。ロード・バランサはHTTPをHTTPSにリダイレクトするため、Oracle Enterprise Manger Fusion Middleware ControlでWebサービスの機能をテストすると、次の例外が発生します。

(javax.xml.soap.SOAPException: oracle.j2ee.ws.saaj.ContentTypeException)

この例外を解決するには、URLエンドポイントを更新します。

Enterprise Managerの「テスト」ページで、エンドポイントURLの編集を確認します。

「エンドポイントURL」ページで、次の操作を実行します。

- httpをhttpsに変更します。

- 初期設定のポート番号(80など)をSSLポート(443など)に変更します。

9.6.3.2 コールバックURLについて

この項では、SOAシステムでコールバックURLがどのように決定されるかについて説明します。

- SOAへのリクエストが外部または内部のサービスから発行された場合、SOAはクライアントで指定されたコールバックURLを使用します。

- 外部または内部の非同期サービスへのリクエストがSOAから送られると、コールバックURLは次のように、優先度の高い順に決定されます。

1. 特定の参照用のバインド・プロパティとして指定されたcallbackServerURLを使用します(このプロパティは、コンポジットのモデリング時または実行時にMBeansを使用して設定できます)。これにより、サービス呼び出しごとに異なるコールバックURLを割り当てることができます。つまり、外部サービスからのコールバックURLには、内部サービスへのコールバックURLとは異なる値を設定できます。エンタープライズ・デプロイメント・アーキテクチャでの一般的なコールバックURLは、外部サービスについてはwcp.example.com (443/https)、内部サービスについてはwcpinternal.example.com (7777/http)です。このプロパティは、システムMBeanブラウザに対応するバインドmbeanを通じ、実行時にシステムMBeanブラウザを使用して設定します。特定のURLを追加するには、そのProperties属性にcallbackServerURLプロパティを追加してから保存操作を実行します。

2. soa-infra-config.xmlで指定したコールバックURLを使用します。この場合、指定できるアドレスは1つのみです。外部サービスと内部サービスの両方を組み合せて呼び出し可能な場合は、エンタープライズ・デプロイメント・アーキテクチャでこのアドレスをwcp.example.com (443/https)に設定する必要があります。内部サービスのみを呼び出す場合は、このアドレスをwcpinternal.example.com (7777/http)に設定します。

3. SOA_ClusterのWLSで指定するフロントエンド・ホストとして、このコールバックURLを使用します。この場合も指定できるアドレスは1つのみなので、soa-infra-config.xmlの場合と同じ処理をお薦めします。

4. WLS MBean APIで指定されたローカル・ホスト名を使用します。これは、エンタープライズ・デプロイメントのような高可用性環境ではお薦めしません。

9.7 トランザクション・リカバリ用デフォルト永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。

注意:
デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

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

2. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列で、サーバーWLS_SOA1の名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。

5. 「構成」タブをクリックしてから「サービス」タブをクリックします(トップレベルの「サービス」タブではありません)。

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

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

7. WLS_SOA2サーバーについて、手順3、4、5、6を繰り返します。

8. 「保存」→「変更のアクティブ化」をクリックします。

9. WLS_SOA1およびWLS_SOA2管理対象サーバーを再起動します。

10. WLS_SOA1とWLS_SOA2が再起動した後、次のディレクトリに次のファイルが作成されていることを確認します。

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

- _WLS_WLS_SOA1000000.DAT

- _WLS_WLS_SOA2000000.DAT

注意:
トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

9.8 Oracleアダプタの構成

Oracleファイル、FTPおよびデータベース・アダプタを、拡張したSOAドメイン用に構成します。

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

- 第9.8.1項「OracleファイルとFTPアダプタの高可用性化」

- 第9.8.2項「Oracle JMSアダプタの高可用性化」

- 第9.8.3項「Oracle Databaseアダプタのスケーリング」

9.8.1 OracleファイルとFTPアダプタの高可用性化

OracleファイルおよびFTPアダプタを使用すると、ローカル・ファイル・システムやリモート・ファイル・システムのファイルをFTP(ファイル転送プロトコル)を使用してBPELプロセスまたはOracle Mediatorで読取りまたは書込みできるようになります。これらのアダプタは、Oracle BPEL Process ManagerおよびOracle Mediatorサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能を、インバウンドおよびアウトバウンドの両方の操作でサポートしています。Oracleファイル・アダプタとFTPアダプタがアウトバウンド操作に対する高可用性を備えるようにするには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作での高可用性に関する項で説明されているデータベースのmutexロック操作を使用します。データベースのmutex lock操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。

注意:
前述の操作は、これらのアダプタがアプリケーションで必要になる場合にのみ実行する必要があります。

注意:
ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。

9.8.1.1 データベースのmutex lock操作の使用

データベース表をコーディネータとして使用して、アウトバウンドのOracleファイルやFTPアダプタのサービスに高可用性を実現します。

注意:
FTPアダプタの手順および構成オプションは、フィルタ・アダプタのオプションと完全に同じです。FTP HAの構成に使用する接続ファクトリは、FTPアダプタ・デプロイメントのアウトバウンド接続プールの下に表示されるeis/Ftp/HAFtpAdapterです。

注意:
データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトを増やします。

アウトバウンドのOracleファイルやFTPアダプタの高可用性を実現するには、Oracle WebLogic Server管理コンソールで、eis/HAFileAdapterに対応するconnection-instanceのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。

1. soa_cluster共有ボリューム上にdpというフォルダを作成します。

2. Oracle WebLogic Serverコンソールにログインします。コンソールにアクセスするには、次のURLにナビゲートします。

http://servername:portnumber/console

3. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

4. 右ペインの「デプロイメントのサマリー」で「FileAdapter」をクリックします。

5. 「構成」タブをクリックします。

6. 「アウトバウンド接続プール」タブをクリックして「javax.resource.cci.ConnectionFactory」を開き、構成済の接続ファクトリを表示します。

7. 「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。

8. 図9-5に示すように、接続ファクトリのプロパティが表示されます。

図9-5 Oracle WebLogic Serverコンソール - 「javax.resource.cci.Connectionfactoryの設定」ページ

「ロックして編集」をクリックします。これにより、プロパティ値の列が編集可能になります(「プロパティ値」列で任意の行をクリックしてその値を変更できます)。

OracleファイルとFTPアダプタの接続ファクトリの新しいパラメータは次のとおりです。

controlDir: 制御ファイルを格納するディレクトリ構造に設定します。1つのクラスタの中で複数のWebLogic Serverインスタンスを実行する場合は、この値を共有場所に設定する必要があります。この共有記憶域のディレクトリは次のような構造にします。

ORACLE_BASE/admin/domain_name/cluster_name/fadapter

inboundDataSource: jdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。以前に作成されたスキーマは次のディレクトリにあります。

ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql

事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。別のスキーマを選択する場合は、それに応じてinboundDataSourceプロパティを設定する必要があります。

outboundDataSource: jdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。以前に作成されたスキーマは次のディレクトリにあります。

ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql

事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。その場合は、outboundDataSourceプロパティを設定する必要があります。

outboundDataSourceLocal: jdbc/SOALocalTxDataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。

outboundLockTypeForWrite: Oracle Databaseを使用している場合は、この値をoracleに設定します。デフォルトでは、OracleファイルとFTPアダプタはインメモリーmutexを使用してアウトバウンドの書込み操作をロックします。書込み操作を同期化するには、次の値のいずれかを選択する必要があります。

memory: OracleファイルとFTPアダプタはインメモリーmutexを使用してファイル・システムへのアクセスを同期化します。

oracle: アダプタは、Oracle Databaseシーケンスを使用します。

db: アダプタは事前作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用している場合にのみ使用します。

user-defined: アダプタはユーザー定義のmutexを使用します。ユーザー定義のmutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutexを実装し、新しいバインド・プロパティoracle.tip.adapter.file.mutexを構成して、その値にアウトバウンド参照のmutexの完全修飾クラス名を指定します。

9. これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。

10. デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/cluster_name/dp/Plan.xml

11. 「保存」をクリックしてデプロイメント・プラン・ファイルを送信します。

12. 「保存」をクリックしてJMSアダプタの設定を保存します。

13. 「変更のアクティブ化」をクリックします。

14. 一度新しいデプロイメント・プランを保存してアクティブ化すると、FileAdapterデプロイメントをアクティブ化します(まだ開始されていないデプロイメントのステータスは「準備完了」です)。FileAdapterデプロイメント・プランをアクティブ化する手順は次のとおりです。
管理コンソールの「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

右ペインの「デプロイメントのサマリー」でFileAdapterを選択し、「起動」→「すべてのリクエストを処理」を選択します。

15. (オプション)次の例のように、(バインディング・コンポーネントのjcaファイル内で)接続ファクトリが使用されるようにBPELプロセスまたはMediatorシナリオを構成します。

<adapter-config name="FlatStructureOut" adapter="File Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/HAFileAdapter" adapterRef=""/>
<endpoint-interaction portType="Write_ptt" operation="Write">
<interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec">
<property../>
<property../>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

注意:

- location属性は、接続ファクトリのeis/HAFileAdapterに設定されています。

- 前述の手順は、ファイル・アダプタを高可用性用に構成するためのものです。FTPアダプタを高可用性用に構成するには、コントロール・ディレクトリを更新するための同じ手順を実行します。この変更には、eis/Ftp/HAFtpAdapter接続ファクトリ・インスタンスを使用します。

9.8.2 Oracle JMSアダプタの高可用性化

Oracle JMSアダプタがクラスタ内の複数のサーバーと通信する場合、アダプタの通信ファクトリのプロパティFactoryPropertiesに使用可能なサーバーがリストされている必要があります。サーバーがリストされない場合、ランダムな1サーバーとの接続が確立されます。そのサーバーが停止しても、追加のメッセージは処理されません。

アダプタのJCA接続ファクトリを確認する手順は次のとおりです。

1. 次の構造を使用して、共有ストレージにOracle SOA Suiteクラスタのためのデプロイメント・プラン・ディレクトリを作成します。

ORACLE_BASE/admin/domain_name/cluster_name/dp

2. 次のURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

http://servername:portnumber/console

3. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

4. 右ペインの「デプロイメントのサマリー」でJMSAdapterをクリックします。

5. 「構成」タブをクリックします。

6. 「アウトバウンド接続プール」タブをクリックしてoracle.tip.adapter.jms.IJmsConnectionFactoryを開き、構成済の接続ファクトリを表示します。

7. 使用中の特定のインスタンス(例: eis/wls/Queue)をクリックします。接続ファクトリの「アウトバウンド接続のプロパティ」が開きます。

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

9. FactoryPropertiesフィールドで(「プロパティ」値の該当するセルをクリックして)、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url=t3://soahostvhn1:8001,soahost2vhn1:8001;java.naming.security.principal=weblogic;
java.naming.security.credentials=myPassword1

10. これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。

11. デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/cluster_name/dp/Plan.xml

12. 「保存」をクリックしてデプロイメント・プラン・ファイルを送信します。

13. 「保存」をクリックしてJMSアダプタの設定を保存します。

14. 「変更のアクティブ化」をクリックします。

コンソールでデプロイメントを更新します。

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

2. 「JMSAdapter」チェック・ボックスを選択します。

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

4. 「更新」をクリックします。

5. 「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します(このオプションには、デプロイメント・プランを指定する必要があります)。」を選択し、共有記憶域の場所に保存されたデプロイメント・プランを選択します。クラスタ内のすべてのサーバーがこのプランにアクセスできる必要があります。

6. 「終了」をクリックします。

7. 変更をアクティブ化します。

9.8.3 Oracle Databaseアダプタのスケーリング

ロックのスキップ機能の導入により、これまでの最善の方法であった、各ポーリング・ノードでLogicalDeletePollingStrategyまたはDeletePollingStrategyと一意のMarkReservedValueを使用し、MaxTransactionSizeを設定する方法は使用できなくなりました。以前にこのアプローチを使用していた場合は、db.jcaファイルからMarkReservedValueパラメータを削除するか、ウィザードの「論理削除」ページでこのパラメータを選択解除するだけで、ロックが自動的にスキップされるようになります。

予約された値に対してロックのスキップを使用することには、次のような利点があります。

- ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。

- (更新/予約の次にコミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。

- 一意のMarkReservedValueを指定する必要がありません。以前は、そのようにするためには、R${weblogic.Name-2}-${IP-2}-${instance}のように、複雑な変数を構成することが必要でした。

論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。

以前は、複数のOracle BPEL Process ManagerノードまたはOracle Mediatorノードにデプロイする複数のOracle Databaseアダプタ・プロセス・インスタンスにおける最善の手法は、基本的に、ポーリング・ノードごとに一意のMarkReservedValueを設定し、さらにMaxTransactionSizeを設定して、LogicalDeletePollingStrategyまたはDeletePollingStrategyを使用することでした。

ただし、ロックのスキップが導入されたことによって、このアプローチは現在使用されなくなりました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)選択解除するだけで、ロックが自動的にスキップされるようになります。

詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティおよびポーリング戦略に関する項を参照してください。

9.9 SOA構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の「環境のバックアップ」を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の「環境のリカバリ」を参照してください。

ドメイン構成をバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl startall

2. データベースのバックアップを取ります。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/admin/domain_name

1. ドメイン内のすべての管理対象サーバーを停止します。

2. 管理サーバーを停止します。

3. SOAHOST1で次のコマンドを実行して、管理サーバーをバックアップします。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

4. 管理サーバーを起動します。

5. すべての管理対象サーバーを起動します。

10 WebCenter Portalコンポーネントを使用するためのドメインの拡張

この章では、WebCenter Portalコンポーネントを含めるために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを構成ウィザードを使用して拡張する方法を説明します。

注意:
セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

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

- WebCenter Portalコンポーネントを使用するためのドメインの拡張の概要

- WebCenter Portalコンポーネントを使用するための構成ウィザードを使用したドメインの拡張

- 構成後のタスク

- SOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播

- Spaces_Cluster用のJavaオブジェクト・キャッシュの構成

- マルチキャストからユニキャストへのディスカッションの変換

- ディスカッション・サーバーでのクラスタリングの構成

- Analyticsの構成

- アクティビティ・グラフの構成

- REST APIの構成

- 拡張したドメインでのOracle HTTP Serverの構成

- WebCenter Portalの構成のバックアップ

10.1 WebCenter Portalコンポーネントを使用するためのドメインの拡張の概要

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項「構成後のタスク」

ドメイン構成の管理対象サーバーのドメイン・ディレクトリへの伝播

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

第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項「ディスカッション・サーバーでのクラスタリングの構成」

第10.8項「Analyticsの構成」

第10.9項「アクティビティ・グラフの構成」

第10.10項「REST APIの構成」

拡張したドメインでの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の構成のバックアップ」

10.2 WebCenter Portalコンポーネントを使用するための構成ウィザードを使用したドメインの拡張

WebCenter Portalコンポーネントを含めるために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを、構成ウィザードを使用して拡張できます。

注意:
ドメインを拡張する前に、現在のドメインをバックアップする必要があります。ドメインの拡張時にエラーが発生した場合は、このバックアップを使用してリカバリできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の「環境のバックアップ」を参照してください。

構成ウィザードを使用してドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内の管理サーバーおよびすべての管理対象サーバーを停止します。

3. 構成ウィザードの場所にディレクトリを変更します。これは共通のOracleホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するSOAHOST1から実行することに注意してください)。

cd ORACLE_COMMON_HOME/common/bin

4. 構成ウィザードを開始します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. 「WebLogicドメイン・ディレクトリ」画面で、WebLogic Serverドメイン・ディレクトリを選択します。

ORACLE_BASE/admin/domain_name/aserver/domain_name

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

7. 「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。

- 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

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

8. このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。

9. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. 画面に次のコンポーネント・スキーマが表示されることを確認します。表10-2に示すスキーマ所有者名は、RCUでスキーマを作成する際に接頭辞としてwcpedgが使用されていると想定しています。

表10-2 コンポーネント・スキーマの値

コンポーネント・スキーマ

スキーマ所有者

WebCenterDSスキーマ

wcpedg_webcenter

ActivitiesDSスキーマ

wcpedg_activities

DiscussionDSスキーマ

wcpedg_discussions

PersonalizationDSスキーマ

wcpedg_webcenter

PortletDSスキーマ

wcpedg_portlet

Portlet-ServicesProducerDSスキーマ

wcpedg_portlet

WC-ServicesProducerDS

wcpedg_webcenter

WebCenterMDSスキーマ

wcpedg_mds

PersonalizationMDSスキーマ

wcpedg_mds

mds-PageletProducerDSスキーマ

wcpedg_mds

mds-ServicesProducerDSスキーマ

wcpedg_mds

2. 表10-2のコンポーネント・スキーマの横のすべてのチェック・ボックスを選択します。

3. RACの構成には、(付録A「Oracle RACでのマルチ・データ・ソースの使用」で説明した)「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます。
ここの手順では、「GridLinkへ変換」を選択します。

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

10. 「GridLink RACコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. 表10-2に示された11個のすべてのデータ・ソース・スキーマを選択します。

2. 「ユーザー名」を除くすべてのフィールドに値を入力して、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をサポートしない場合は次を実行します。

- Oracle Database 11gリリース1 (11.1)の場合、各データベースのインスタンス・リスナーの仮想IPとポートを次のように入力します。
custdbhost1-vip.example.com (Port 1521)

および

custdbhost2-vip.example.com (Port 1521)

- Oracle Database 10gの場合、マルチ・データ・ソースを使用し、Oracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- 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サービスのホスト名とポートを入力します。例:
custdbhost1.example.com (Port 6200)

および

custdbhost2.example.com (Port 6200)

3. たとえば、次のActivitiesDSスキーマを選択し、適切な詳細を指定します。
表10-2のすべてのWebCenter Portalスキーマに、GridLink情報が入力されていることを確認します。

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

11. ユーザー名: 11個のデータ・ソースを1つずつ選択し、データベース・スキーマ所有者の完全なユーザー名(接頭辞を含む)を入力します。表10-2に示されたユーザー名では、RCUでスキーマを作成する際の接頭辞はwcpedgでした。

12. 「JDBCデータ・ソースのテスト」画面で、テストするスキーマを選択し(または「すべて選択」をクリックし)、「接続のテスト」をクリックします。
「接続結果ログ」に結果が表示されます。スキーマを含むデータベースに正常に接続できたことを確認します。できなかった場合は、「前」をクリックし、前の画面に戻り、入力を修正し、テストを再試行します。

すべての接続に成功したら「次へ」をクリックします。

13. 「オプションの構成を選択」画面で、次の項目を選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

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

15. 「管理対象サーバーの構成」画面で、表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

該当なし

いいえ

注意:

- 管理対象サーバーの名前をここで変更できますが、このページにある元の管理対象サーバーのいずれをも削除しないようにしてください。

- クラスタ・モードがユニキャストの場合、リスニング・アドレスの指定は必須です。

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

16. 「クラスタの構成」画面で、4つ新しいクラスタ(表10-4)を追加します。

表10-4 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

Spaces_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

Portlet_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

Collab_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

Utilities_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

注意:
WSM-PM_ClusterおよびSOA_Clusterは、リストにすでに表示されている必要があります。

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

17. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- Spaces_Cluster:

- WC_Spaces1

- WC_Spaces2

- Portlet_Cluster:

- WC_Portlet1

- WC_Portlet2

- Collab_Cluster:

- WC_Collaboration1

- WC_Collaboration2

- Utilities_Cluster:

- WC_Utilities1

- WC_Utilities2

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

18. 「マシンの構成」画面で「Unixマシン」タブをクリックし、表10-5に示されている5つのエントリがあることを確認します。

表10-5 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST1は、第8.3項「SOAHOST1での構成ウィザードによるドメインの作成」で構成ウィザードを実行したときにすでに構成されています。

SOAHOST2

SOAHOST2

SOAHOST2は、第8.3項「SOAHOST1での構成ウィザードによるドメインの作成」で構成ウィザードを実行したときにすでに構成されています。

ADMINHOST

localhost

WCPHOST1

WCPHOST1

WCPHOST2

WCPHOST2

その他すべてのフィールドはデフォルト値のままにします。

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

19. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- 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

注意:
構成ウィザードにデフォルトで表示される元のサーバーの名前を変更することはできますが、絶対に削除はしないでください。

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

20. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- wsm-pmアプリケーションは、WSM-PM_Clusterにターゲット設定する必要があります。

- SOA_ClusterにWebサービス・マネージャをデプロイする場合は、wsm-pmアプリケーションもSOA_Clusterにターゲット設定されていることを確認します。

- WebCenter Portalに固有のすべてのクラスタから、wsm-pmアプリケーションのターゲット設定を削除します。

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

21. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次の設定をします。

- mds-owsmは、WSM-PM_ClusterおよびAdminServerにターゲット設定する必要があります。
(オプションで、他のクラスタ/サーバーが存在する場合は、それらにmds-owsmをターゲット設定することもできます。)

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

22. 「構成のサマリ」画面で、「拡張」をクリックします。

23. 「ドメインの拡張」画面で、「完了」をクリックします。
この構成を有効にするには、管理サーバーを起動する必要があります。

24. 管理サーバーを、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で起動します。

10.3 構成後のタスク

構成ウィザードでドメインを拡張した後は、次の手順に従って構成後タスクを実行します。

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

- 第10.3.1項「WebCenter Portal管理対象サーバーに対するホスト名検証の無効化」

- 第10.3.2項「SOAHOST1でのノード・マネージャの起動」

- 第10.3.3項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更の伝播」

10.3.1 WebCenter Portal管理対象サーバーに対するホスト名検証の無効化

このガイドで説明するエンタープライズ・デプロイメントでは、WebCenter Portalを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。異なるWebLogic Serverを管理する場合のエラーを防止するには、WebCenter Portal管理対象サーバー(WC_Spacesn、WC_Portletn、WC_Collaborationn、WC_Utilitiesn)のホスト名検証を無効化する必要があります。詳細は、第8.4.8項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第11.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

10.3.2 SOAHOST1でのノード・マネージャの起動

startNodeManager.shスクリプトを使用してノード・マネージャを再起動します。

SOAHOST1でノード・マネージャを再起動する手順は次のとおりです。

1. ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。

- シェルのフォアグラウンドで実行されている場合は、[Ctrl]を押しながら[C]を押します。

- シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、killコマンドを使用して停止します。例:

ps -ef | grep NodeManager
orcl      9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh

kill -9 9139

2. ノード・マネージャを起動します。

cd WL_HOME/server/bin
./startNodeManager.sh

10.3.3 管理対象サーバーのドメイン・ディレクトリへのドメイン変更の伝播

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

起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリをバックアップします。

tar -cpzf BACKUP_LOCATION/edg10.3.3-doman_name.tgz ORACLE_BASE/admin/domain_name

2. 次の一連のコマンドを使用し、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など)を選択します。

3. 次のように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処理の後に再適用する必要があります。

10.4 SOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播

SOAHOST1の構成が完了したら、unpackユーティリティを使用してSOAHOST2、WCPHOST1およびWCPHOST2に構成を伝播し、伝播した構成を検証します。

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

- 第10.4.1項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」

- 第10.4.2項「uploadおよびstageディレクトリの絶対パスへの変更」

- 第10.4.3項「WCPHOST1およびWCPHOST2でのノード・マネージャの起動」

- 第10.4.4項「WCPHOST1でのWC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの起動」

- 第10.4.5項「WebCenter PortalのためのGridLinkデータ・ソース構成およびONS構成の検証」

- 第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管理対象サーバーの検証」

10.4.1 unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播

構成したばかりのドメインをSOAHOST2、WCPHOST1およびWCPHOST2にunpackユーティリティを使用して伝播できます。

注意:
システム間でミドルウェア・ホームが共有されている場合は、ドメイン・テンプレートが適切なディレクトリに存在しているはずなので、次のステップ1を省略できます。

ドメイン構成を伝播する手順は次のとおりです。

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

2. 必要なアプリケーション・デプロイメント・ファイルを管理サーバーから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

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

4. WCPHOST1およびWCPHOST2について、前述の手順を繰り返します。

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

ドメイン変更の伝播後、uploadおよびstageディレクトリを更新します。詳細な手順は、第8.5.2項「uploadおよびstageディレクトリの絶対パスへの変更」を参照してください。

10.4.3 WCPHOST1およびWCPHOST2でのノード・マネージャの起動

startNodeManager.shスクリプトを使用し、ノード・マネージャを起動します。

WCPHOST1およびWCPHOST2上のノード・マネージャを起動する手順:

1. 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で実行されています。

2. WCPHOST1およびWCPHOST2の両方で次のコマンドを実行し、ノード・マネージャを起動します。

WCPHOST1> cd WL_HOME/server/bin
WCPHOST1> ./startNodeManager.sh

WCPHOST2> cd WL_HOME/server/bin
WCPHOST2> ./startNodeManager.sh

10.4.4 WCPHOST1でのWC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの起動

WCPHOST1上のWC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーを起動する手順:

1. 管理コンソール(http://ADMINVHN:7001/console)にアクセスします。
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。

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

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

4. 「制御」タブを開きます。

5. 「WLS_WSM1」および「WLS_WSM2」を選択します。

6. 「起動」をクリックします。

7. WLS_WSM1およびWLS_WSM2管理対象サーバーが稼働中であることを確認します。

8. 「WC_Spaces1」、「WC_Portlet1」、「WC_Utilities1」および「WC_Collaboration1」を選択します。

9. 「起動」をクリックします。

10.4.5 WebCenter PortalのためのGridLinkデータ・ソース構成およびONS構成の検証

WCPHOST2でWC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2を起動する前に、前に作成したGridLinkデータ・ソースの構成とOracle Notification Service (ONS)の設定がデータ・ソースに対して正しいことを検証する必要があります。

GridLinkデータ・ソースとWebCenter Portalの構成を確認するには、次の手順を実行します。

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

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 「データ・ソース」ページ(図10-1)で、作成されたGridLinkデータ・ソースの名前をクリックします。

図10-1 「データ・ソース」ページ

4. 「データ・ソースのテスト」ページ(図10-2)で、「監視」タブをクリックしてから「テスト」タブをクリックし、いずれかのWebCenter Portal管理対象サーバー(WC_Spaces1など)を選択し、「データ・ソースのテスト」をクリックします。
構成が正しい場合、テストは成功します。

図10-2 「データ・ソースのテスト」ページ

5. GridLinkデータ・ソースを使用するWCPHOST1上で実行されている各WebCenter Portal管理対象サーバーに対してテストを繰り返します。

6. 「監視」タブをクリックし、サーバー名の1つをクリックします。

7. 「ONS」→「テスト」タブをクリックします。

8. たとえば、WC_Spaces1など、WebCenter Portal管理対象サーバーの1つを選択し、「ONSのテスト」をクリックします。

図10-3 「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

9. GridLinkデータ・ソースを使用する各WebCenter Portal管理対象サーバーに、ONSテストを繰り返します。

10.4.6 WC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの検証

WCPHOST1上のすべてのWebCenter Portal管理対象サーバーが稼働中であることを確認する手順:

1. 次の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

2. すべてのデプロイメントがアクティブであることを確認します。管理コンソールで、「デプロイ」を選択します。
いずれかに障害が発生した場合は、ログ・ファイルでエラーを確認します。ログ・ファイルは次の場所にあります。

ORACLE_BASE/admin/domain_name/mserver/domain_home/servers/server_name/logs

10.4.7 WCPHOST2でのWC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの起動

管理コンソールを使用してWC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーを起動する手順:

1. 管理コンソール(http://ADMINVHN:7001/console)にアクセスします。
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。

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

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

4. 「制御」タブを開きます。

5. 「WC_Spaces2」、「WC_Portlet2」、「WC_Utilities2」および「WC_Collaboration2」を選択します。

6. 「起動」をクリックします。

10.4.8 WC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの検証

WCPHOST2上のすべてのWebCenter Portal管理対象サーバーが稼働中であることを確認する手順:

1. 次の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

2. すべてのデプロイメントがアクティブであることを確認します。管理コンソールで、「デプロイ」を選択します。
いずれかに障害が発生した場合は、ログ・ファイルでエラーを確認します。ログ・ファイルは次の場所にあります。

ORACLE_BASE/admin/domain_name/mserver/domain_home/servers/server_name/logs

10.5 Spaces_Cluster用のJavaオブジェクト・キャッシュの構成

Spaces_Cluster内のすべての管理対象サーバー間のJavaオブジェクト・キャッシュ(JOC)を構成します。このローカル・キャッシュは、WebCenter Portalアプリケーションのパフォーマンスを向上させるために提供されています。

Javaオブジェクト・キャッシュはMW_HOME/oracle_common/bin/configure-joc.pyスクリプトを使用して構成できます。これはPythonスクリプトであり、管理対象サーバーでJOCを構成するために使用できます。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが稼働中であることが求められます。WLSTのオンライン・モードに関する一般的な情報は、『管理者ガイド』のOracle WebLogic Scripting Tool (WLST)の使用の開始に関する項を参照してください。

注意:
WLSTコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成した後、構成を有効にするために、影響を受ける管理対象サーバーをすべて再起動します。

WebCenter Portal管理対象サーバーのJavaオブジェクト・キャッシュを構成する手順:

1. たとえば、次のようにWLSTを使用し管理サーバーに接続します。

MW_HOME/wc/common/bin/wlst.sh
$ connect()

Oracle WebLogicの管理ユーザー名とパスワードの入力を求められたら、これらを入力します。

2. WLSTを使用して管理サーバーに接続後、execfileコマンドを使用してスクリプトを開始します。たとえば、次のようにします。

wls:/mydomain/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")

3. 指定されたクラスタのすべての管理対象サーバーの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オブジェクト・キャッシュの構成」を参照してください。

10.6 マルチキャストからユニキャストへのディスカッションの変換

(Collab_Cluster内のすべての管理対象サーバー上の)ディスカッションをマルチキャストからユニキャストに変換するには、関係する起動パラメータを追加します。

1. Oracle WebLogic Server管理コンソールで、「サーバー」→「WC_Collaboration1」→「構成」→「サーバーの起動」を選択します。

2. 「引数」ボックスに次の引数を追加します。

-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の通信用に予約されているポートです。

3. 正確に同じパラメータ値を使用して、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

4. WC_Collaborationサーバーを再起動します。

10.7 ディスカッション・サーバーでのクラスタリングの構成

ユニキャスト・クラスタの場合は、まず、第10.6項「マルチキャストからユニキャストへのディスカッションの変換」の手順をすべて完了します。

ディスカッション・クラスタ内のすべてのメンバーが互いに通信できるようにするには、次の手順を実行します。

1. 次の場所にあるクラスタ内の各メンバー用のディスカッション・サーバーの管理コンソールにログインします。

http://WCPHOSTn:9002/owc_discussions/admin

2. 「キャッシュ設定」を選択します。

3. キャッシュ機能セクション(図10-4)で、「クラスタリング」が「有効」に設定されていることを確認します。
サーバーは、クラスタを結合すると、画面の上部に表示されます。

注意:
クラスタ化されたキャッシュが有効な場合、ディスカッション・コンテンツの更新は即座にリフレッシュされません。ユーザーは、いつでも「リフレッシュ」アイコンをクリックして、強制的に手動でリフレッシュできます。

図10-4 キャッシュ機能セクション

4. 「ツール」セクション(図10-5)で、「クラスタ・メンバーをすべてリセット」と「キャッシュ・ウォームアップ・タスクの開始」を選択します。クラスタのすべてのメンバーで、キャッシュのウォームアップ・タスクを繰り返します。

図10-5 キャッシュ・ツール・セクション

5. クラスタのすべてのメンバーに対して、手順1から4を繰り返します。
サーバーは、クラスタを結合すると、画面の上部に表示されます。

10.8 Analyticsの構成

分析コレクタは、デフォルトでローカルのWebCenter Portalアプリケーションと1対1の関係で通信できるよう構成されています(コレクタはlocalhostをリスニングします)。分析コレクタは、別途構成する必要はありません。

ただし、localhostにイベント・メッセージを送信するよう、WebCenter Portalアプリケーションを構成する必要があります。

注意:
クラスタ化された分析コレクタでは、WebCenter Portalのイベントの収集はサポートしていません。

WebCenter Portalアプリケーションを分析コレクタに接続する手順は次のとおりです。

1. WLSTを使用して、WebCenter Portalアプリケーションが実行されている管理対象サーバーに、たとえば次のように接続します。

MW_HOME/wc/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "WCPHOST1:9000")

WC_Spacesサーバーのホストとポートに接続します。

2. 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に関する項も参照してください。

3. 変更を確認します。

listDefaultAnalyticsCollectorConnection(appName="webcenter")

『WebLogic Scripting Toolコマンド・リファレンス』のlistDefaultAnalyticsCollectorConnectionに関する項も参照してください。

4. 分析タスク・フローがデータを表示するには、アクティビティ・グラフ・エンジンが1回以上実行されている必要があります。詳細は、第10.9項「アクティビティ・グラフの構成」を参照してください。

10.9 アクティビティ・グラフの構成

アクティビティ・グラフはシングルトンとして実行する必要があります。クラスタ環境では、すべてのアクティビティ・グラフ・アプリケーションのインスタンスは1つを除いてすべて無効化する必要があります。

アクティビティ・グラフ・エンジン・アプリケーションを無効化する手順は次のとおりです。

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

2. WC_Spacesn、WC_Portletn、WC_CollaborationnおよびWC_Utilitiesnサーバーを停止します。

3. 「デプロイメント」を選択します。

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

5. これらの各デプロイメントのターゲットを変更します。

- 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)

1. デプロイメントを選択します。

2. 「ターゲット」タブを選択します。

3. エンタープライズ・アプリケーションの場合は、「エンタープライズ・アプリケーション」チェック・ボックスを選択します。

4. 「ターゲットの変更」をクリックします。

5. Utilities_Clusterのターゲット設定を、「クラスタのすべてのサーバー」からWC_Utilities1管理対象サーバーのみに変更します。その他のターゲットの詳細は変更しないでください。

6. 「はい」をクリックして変更を保存します。

6. 3つのデプロイメントのすべての手順を完了したら、「すべての変更のアクティブ化」をクリックします。

7. WC_Spacesn、WC_Portletn、WC_CollaborationnおよびWC_Utilitiesnサーバーを起動します。

8. アクティビティ・グラフが推奨事項を表示し、分析タスク・フローがデータを表示するには、アクティビティ・グラフ・エンジンが1回以上実行されている必要があります。

1. WebLogic管理ユーザーとして、アクティビティ・グラフ(http://WCPHOST1:9003/activitygraph-engines)にログインします。
このページにアクセスするには、Administratorsグループのメンバーである必要があります。

2. 「開始」/「実行」をクリックして、統計の収集を開始します。

『Oracle WebCenter Portalの管理』のアクティビティ・グラフのデータの準備に関する項も参照してください。

アクティビティ・グラフは1つのノードでのみ実行されているので、このノードが失われたり、管理対象サーバーが使用不可能であったりすると、アクティビティ・グラフが使用不可能になります。ノードに障害が発生した場合は、アクティビティ・グラフをクラスタ内で使用可能な他のいずれかの管理対象サーバーに手動でデプロイできます。

注意:
アクティビティ・グラフはフェイルオーバーできない他のコンポーネントと同じサーバー上にあるため、サーバーの移行をアクティビティ・グラフには構成しないことをお薦めします。サーバーの移行の詳細は、第14章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。

10.10 REST APIの構成

WebCenter Portal REST APIを使用する場合、この項で説明するサーバー側の構成を実行する必要があります。

RESTセキュリティ・トークンを正しく機能させる、資格証明ストア内のエントリをシードするには、次の手順を実行します。

1. コマンド行のOracle WebLogic Scripting Tool (WLST)を使用して管理サーバーに接続します。例:

MW_HOME/wc/common/bin/wlst.sh
connect()

2. 次の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 拡張したドメインでのOracle HTTP Serverの構成

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

- 第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」

- 第10.11.2項「Oracle HTTP Serverを介したアクセスの検証」

10.11.1 WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成

Oracle HTTP ServerがWebCenter Portalクラスタにルーティングできるようにするには、クラスタ内のノードのリストをWebLogicClusterパラメータに設定する必要があります。

1. 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に対する以前の構成は残してください。

1. 例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統合の管理に関する項を参照してください。

2. 例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>

2. 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サーバー・プラグインの使用』を参照してください。

10.11.1.1 Microsoftクライアントの構成

Microsoftクライアントに対応するには、『Oracle WebCenter Portalの管理』で説明する概要および詳細手順を参照してください。

具体的には、これらのクライアントに別のコンテキスト・ルートを提供するには、別に仮想ホストを作成する必要があります。手順については、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』の仮想ホストでのSSOの構成に関する項を参照してください。

Windows認証サービスを正しく構成するには、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のMicrosoftクライアント用のSSOの構成に関する項の手順に従ってください。

10.11.2 Oracle HTTP Serverを介したアクセスの検証

次のロード・バランサ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

10.12 WebCenter Portalの構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

バックアップを必要とするOracle HTTP Serverのデータの詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法の詳細は、『Oracle Fusion Middleware管理者ガイド』のコンポーネントのリカバリに関する項とコンポーネント・ホストが失われた後のリカバリに関する項を、ホストの損失からのリカバリに固有の推奨事項はこのガイドの別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。

データベースのバックアップの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドも参照してください。

ドメイン構成をバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl startall

2. データベースのバックアップを取ります。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップします。バックアップを実行してドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/admin/domain_name

管理サーバーをバックアップするには、SOAHOST1で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

脚注の凡例

脚注 1: 前のリリースでは、すぐに使用できるアプリケーションWebCenter Portalはスペースと呼ばれていました。構成ウィザードの一部の画面では、前の名前で呼ばれています。

11 エンタープライズ・デプロイメント用のノード・マネージャの設定

この章では、エンタープライズ・デプロイメントの推奨事項に従ってノード・マネージャを構成する方法を説明します。

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

- ノード・マネージャの概要

- ノード・マネージャのログの場所の変更

- ノード・マネージャのホスト名検証証明書の有効化

- ノード・マネージャの起動

- カスタム・キーストアを使用するためのWebLogic Serverの構成

11.1 ノード・マネージャの概要

ノード・マネージャを使用すると、管理サーバーおよび各管理対象サーバーの起動と停止が可能です。

オラクル社では、ノード・マネージャと管理サーバー間の通信にホスト名を使用した検証を使用することを推奨しています。このホスト名検証には、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。この章では、ホスト名検証に使用する証明書をSOAHOST1およびSOAHOST2に構成する手順を説明します。WCPHOST1とWCPHOST2についても同様の手順が必要です。その手順ではWCPHOST1とWCPHOST2に応じたホスト名の変更が必要ですが、一連の手順や構文はまったく同じです。

11.2 ノード・マネージャのログの場所の変更

Oracle Fusion Middlewareデプロイメントのノード・マネージャのログ・ファイルは、デフォルト(ノード・マネージャが存在するMW_Home内)以外の場所に置くことをお薦めします。

ノード・マネージャのログの場所を変更するには、次のディレクトリにあるnodemanager.propertiesファイルを編集します。

MW_HOME/wlserver_10.3/common/nodemanager

このファイルは、MW_HOMEディレクトリでなく、デプロイメントのadminディレクトリ内に置くことをお薦めします。

nodemanager.propertiesに次の行を追加します。

LogFile=ORACLE_BASE/admin/nodemanager.log

ノード・マネージャを再起動して、変更を有効にします。

11.3 ノード・マネージャのホスト名検証証明書の有効化

ホスト名検証はノード・マネージャと管理サーバー間の通信を可能にするものです。この検証では、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。

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

- ステップ1: utils.CertGenユーティリティを使用した自己署名証明書の生成

- ステップ2: utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

- ステップ3: Keytoolユーティリティを使用した信頼キーストアの作成

- ステップ4: カスタム・キーストアを使用するためのノード・マネージャの構成

- ステップ5: 共通または共有記憶域インストールの使用

11.3.1 utils.CertGenユーティリティを使用した自己署名証明書の生成

この項では、SOAHOST1.example.comの自己署名証明書を作成する手順を説明します。これらの証明書はネットワーク名/別名を使用して作成します。

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的に使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします(HTTP呼出しのSSL設定など)。この場合、SOAHOST2、WCPHOST1およびWCPHOST2では、SOAHOST1の証明書用に作成されたcertsディレクトリを使用します。

自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。

パスワードについて

このマニュアルのパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。

自己署名証明書を作成する手順は次のとおりです。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。
Bourneシェルの場合、SOAHOST1上で次のコマンドを実行します。

.WL_HOME/server/bin/setWLSEnv.sh

CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

2. 証明書用のユーザー定義ディレクトリを作成します。

mkdir ORACLE_BASE/admin/domain-name/certs

3. ディレクトリをユーザー定義ディレクトリに変更します。

cd ORACLE_BASE/admin/domain-name/certs

4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、SOAHOST1、SOAHOST1VHN VIP、管理サーバーVIP、WCPHOST1および環境内のすべてのホストおよびVIPの証明書を作成します。
構文:

java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [host_name]

コマンド例

java utils.CertGen password SOAHOST1.example.com_cert SOAHOST1.example.com_key domestic SOAHOST1.example.com

java utils.CertGen password SOAHOST1VHN1.example.com_cert SOAHOST1VHN1.example.com_key domestic SOAHOST1VHN1.example.com

java utils.CertGen password SOAHOST2.example.com_cert SOAHOST2.example.com_key domestic SOAHOST2.example.com

java utils.CertGen password SOAHOST2VHN1.example.com_cert SOAHOST1VHN2.example.com_key domestic SOAHOST1VHN2.example.com

java utils.CertGen password ADMINVHN.example.com_cert ADMINVHN.example.com_key domestic ADMINVHN.example.com

java utils.CertGen password WCPHOST1.example.com_cert WCPHOST1.example.com_key domestic WCPHOST1.example.com

java utils.CertGen password WCPHOST2.example.com_cert WCPHOST2.example.com_key domestic WCPHOST2.example.com

11.3.2 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

前の項に示された手順で、アイデンティティ・キーストアが作成されました。SOAHOST1、SOAHOST1VHN1、ADMINVHNおよびWCPHOST1の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

次の手順に従って、SOAHOST1にアイデンティティ・キーストアを作成します。

1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreという名前の新しいアイデンティティ・キーストアを作成します。このキーストアは、証明書と同じディレクトリに作成します( ORACLE_BASE/admin/domain_name/certs)。

注意:
utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートする際、アイデンティティ・ストアが1つも存在しない場合は、新しく作成されます。

2. アイデンティティ・ストアに、SOAHOST1、SOAHOST1VHN1、SOAHOST2、SOAHOST2VHN1、ADMINVHN、WCPHOST1およびWCPHOST2の証明書と秘密鍵をインポートします。必ず、インポートする証明書と鍵のペアごとに異なる別名を使用してください。
構文(すべてを1行で入力します):

java utils.ImportPrivateKey Keystore_File Keystore_Password
Certificate_Alias_to_Use Private_Key_Passphrase
Certificate_File
Private_Key_File
[Keystore_Type]

例:

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appidentitySOAHOST1 password
ORACLE_BASE/admin/domain_name/certs/SOAHOST1.example.com_cert.pem
ORACLE_BASE/admin/domain_name/certs/SOAHOST1.example.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appidentitySOAHOST1VHN1 password
ORACLE_BASE/admin/domain_name/certs/SOAHOST1VHN1.example.com_cert.pem
ORACLE_BASE/admin/domain_name/certs/SOAHOST1VHN1.example.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appidentitySOAHOST2 password
ORACLE_BASE/admin/domain_name/certs/SOAHOST2.example.com_cert.pem
ORACLE_BASE/admin/domain_name/certs/SOAHOST2.example.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appidentitySOAHOST2VHN1 password
ORACLE_BASE/admin/domain_name/certs/SOAHOST2VHN1.example.com_cert.pem
ORACLE_BASE/admin/domain_name/certs/SOAHOST2VHN1.example.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appidentityADMINVHN password
ORACLE_BASE/admin/domain_name/certs/ADMINVHN.example.com_cert.pem
ORACLE_BASE/admin/domain_name/certs/ADMINVHN.example.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appidentityWCPHOST1 password
ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_cert.pem
ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appidentityWCPHOST1 password
ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_cert.pem
ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_key.pem

3. keytoolを使用してキーストア内の新しい別名の一覧を表示します。次に例を示します。

keytool -list -keystore ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks -storepass password

11.3.3 Keytoolユーティリティを使用した信頼キーストアの作成

SOAHOST1.example.comに信頼キーストアを作成するには:

1. 新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアCA証明書をその証明書と同じディレクトリにコピーします。例:

cp WL_HOME/server/lib/cacerts
ORACLE_BASE/admin/domain_name/certs/appTrustKeyStore.jks

2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは常に変更することをお薦めします。これを実行するにはHOST上でkeytoolユーティリティを使用します。構文は次のとおりです。

keytool -storepass -new NewPassword -keystore TrustKeyStore -storepass Original_Password

例:

keytool -storepass -new password -keystore appTrustKeyStore.jks -storepass changeit

3. CA証明書CertGenCA.derは、utils.CertGenツールによって生成されるすべての証明書の署名に使用され、WL_HOME/server/libディレクトリに置かれています。このCA証明書は、HOST上でkeytoolユーティリティを使用して、appTrustKeyStoreにインポートする必要があります。構文は次のとおりです。

keytool -import -v -noprompt -trustcacerts -alias AliasName
-file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password

例:

keytool -import -v -noprompt -trustcacerts -alias clientCACert -file
WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass password

4. SOAHOST2、WCPHOST1およびWCPHOST2の各サーバーに、キーストアをレプリケートします。

1. SOAHOST2に、証明書のためのユーザー定義ディレクトリを作成します。

mkdir ORACLE_BASE/admin/domain_name/certs

2. キーストアをSOAHOST1からSOAHOST2にコピーします。

scp SOAHOST1:/ORACLE_BASE/admin/domain_name/certs/appTrustKeyStore.jks \
/ORACLE_BASE/admin/domain_name/certs/appTrustKeyStore.jks
scp SOAHOST1:/ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks \
/ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks

3. WCPHOST1およびWCPHOST2に手順1と2を繰り返します。

11.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成するには、WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity KeyStore
CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd
CustomIdentityAlias=Identity Key Store Alias
CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate

各ノードに個々に割り当てられたカスタム・アイデンティティの別名が、各ノードのCustomIdentityAlias値に正しく使用されていることを確認します。たとえば、SOAHOST1では、第11.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」の手順に従ってappIdentitySOAHOST1を使用します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentitySOAHOST1
CustomIdentityPrivateKeyPassPhrase=password

第11.4項「ノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、 nodemanager.propertiesファイル内のエントリが暗号化されないままになっている時間を最小限に抑える必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

11.3.5 共通または共有記憶域インストールの使用

MW_HOMEの共通または共有記憶域のインストールを使用する場合、ノード・マネージャは、同じ基本構成(nodemanager.properties)を使用して、異なるノードから起動されます。第11.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」に記載されているように、新しいノードの証明書を作成し、appIdentityKeyStore.jksにそれをインポートすることで、バイナリを共有するすべてのノードの証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加します。ストアに証明書が用意されたら、各ノード・マネージャ・インスタンスは、管理サーバーに正しい証明書を送信するために、異なるアイデンティティ別名を指す必要があります。

次の例は、異なるノードでノード・マネージャを起動する前に異なる環境変数を設定する方法を示しています。

SOAHOST1> cd WL_HOME/server/bin
SOAHOST1> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1

SOAHOST2> cd WL_HOME/server/bin
SOAHOST2> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST2

WCPHOST1> cd WL_HOME/server/bin
WCPHOST1> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityWCPHOST1

WCPHOST2> cd WL_HOME/server/bin
WCPHOST2> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityWCPHOST2

11.4 ノード・マネージャの起動

startNodeManager.shスクリプトを使用して、SOAHOST1、SOAHOST2、WCPHOST1およびWCPHOST2のノード・マネージャを起動します。

注意:
ノード・マネージャが未構成で、まだ起動もしていない場合は、第8.4.2項「SOAHOST1でのノード・マネージャの起動」の説明に従ってsetNMProps.shスクリプトを実行してください。これにより、SOAに必要な起動スクリプトを使用できるようになります。

1. SOAHOST1でノード・マネージャを起動する手順は次のとおりです。

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1
./startNodeManager.sh

注意:
各ホストに専用に割り当てられたカスタム・アイデンティティ・別名を指定します(SOAHOST1はappIdentitySOAHOST11、SOAHOST2はappIdentitySOAHOST2など)。

2. 同じ手順に従って、SOAHOST2、WCPHOST1およびWCPHOST2のノード・マネージャを起動します。

11.5 カスタム・キーストアを使用するためのWebLogic Serverの構成

Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。この手順を、管理サーバーおよびすべての管理対象サーバーで完了します(WLS_WSMn、WLS_SOAn、WC_Spacesn、WC_Collaborationn、WC_UtilitiesnおよびWC_Portletn)。

この例は、第11.3項「ノード・マネージャに対するホスト名検証証明書の有効化」に記載された推奨のディレクトリ構造およびキーストアの場所に従っています。

アイデンティティ・キーストアおよび信頼キーストアを構成する手順は次のとおりです。

1. 管理コンソールにログインして「ロックして編集」をクリックします。

2. 左ペインで「環境」を開き、「サーバー」を選択します。

3. アイデンティティ・キーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。

4. 「構成」を選択して、「キーストア」を選択します。

5. 「キーストア」フィールドの横にある「変更」をクリックして、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書を格納し管理するための「カスタムIDとカスタム信頼」方法を選択します。

6. 「ID」セクションで、アイデンティティ・キーストアの属性を定義します。

1. カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。

ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks

2. カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

3. カスタムIDキーストアのパスフレーズ: 第11.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します。
この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

7. 「信頼」セクションで、信頼キーストアのプロパティを定義します。

1. カスタム信頼キーストア: 信頼キーストアの完全修飾パスを入力します。

ORACLE_BASE/admin/domain_name/certs/appTrustKeyStore.jks

2. カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

3. カスタム信頼キーストアのパスフレーズ: 第11.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」でNew_Passwordとして指定したパスワード。
前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。

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

9. これらの変更を有効にするために、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。

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

11. 「構成」をクリックし、「SSL」をクリックします。

12. 「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第11.3.3項「Keytoolユーティリティを使用した信頼キーストアの作成」で作成したキーストアのパスワードを入力します。

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

14. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

15. 変更を適用したサーバーを再起動します。

16. これらの手順を、管理サーバーおよびすべての管理対象サーバー(WLS_WSMn、WLS_SOAn、WC_Spacesn、WC_Collaborationn、WC_UtilitiesnおよびWC_Portletn)に対して繰り返します。

17. ホスト名検証を有効化して、ノード・マネージャ、管理サーバーおよび管理対象サーバー間の通信が正しいことを検証します。

1. 各サーバーの管理コンソールで、「構成」、「SSL」、「詳細」、「ホスト名の検証」、「BEAホスト名の検証」を選択します。

2. 管理コンソールを使用してサーバーを再起動します。

12 エンタープライズ・デプロイメントにおけるWebCenter Portalの外部ツールおよびサービスの構成

この章では、Fusion Middleware ControlまたはWLSTコマンドを使用して、WebCenter Portalアプリケーション用に外部のツールおよびサービスを構成する方法を説明します。多くの外部サービスでは、WebCenter Portalアプリケーションとバックエンド・サーバー間に接続を設定する必要があります。

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

- WebCenter Portal、ディスカッションおよびポートレット・プロデューサ・アプリケーション用デフォルトWebサービス・ポリシーの構成

- ディスカッション・サーバーの接続の構成

- インスタント・メッセージおよびプレゼンス(IMP)サーバー接続の構成

- ワークリストおよびワークフロー用のBPELサーバー接続の構成

- ポートレット・プロデューサの登録

- ページレット・プロデューサの登録

- 検索サービスの構成

- 通知用のメール・サーバーの構成

12.1 WebCenter Portal、ディスカッションおよびポートレット・プロデューサ・アプリケーション用デフォルトWebサービス・ポリシーの構成

Oracle WebCenter Portalのインストール後に、デフォルトのOracle Web Services Manager (OWSM)セキュリティ・ポリシーを次にアタッチする必要があります。

- WebCenter Portalアプリケーション(webcenter)

- ディスカッション・アプリケーション(owc_discussions)

- WebCenterサービス・ポートレット・プロデューサ(services-producer)

- WSRPツール・プロデューサ(wsrp-tools)

これらのWebサービス・エンド・ポイントに対するセキュリティ・ポリシーは出荷時には構成されていないため、これらの手順が必要になります。

デフォルトのWebサービス・セキュリティ・ポリシーをアタッチする手順は次のとおりです。

1. WC_Spaces1、WC_Spaces2、WC_Collaboration1、WC_Collaboration2、WC_Portlet1およびWC_Portlet2管理対象サーバーが稼働中であることを確認します。

2. WebLogic Scripting Toolを起動します。

WCPHOST1> MW_HOME/wc/common/bin/wlst.sh

3. 管理者として管理サーバーに接続します。
例:

connect("weblogic","admin password","ADMINVHN:7001")

詳細は、『Oracle WebCenter Portalの管理』のOracle WebLogic Scripting Tool (WLST)コマンドの実行に関する項を参照してください。

4. WLSTコマンドを実行し、デフォルトのOWSMセキュリティ・ポリシー(oracle/wss10_saml_token_service_policy)を次の各エンド・ポイントにアタッチします。

- WebCenter Portalアプリケーション(webcenter)

- ディスカッション・アプリケーション(owc_discussions)

- WebCenterサービス・ポートレット・プロデューサ(services-producer)

- WSRPツール・プロデューサ(wsrp-tools)

1. デフォルトのOWSMセキュリティ・ポリシーをクラスタ内の各サーバー(WC_Spaces1とWC_Spaces2)上のWebCenter PortalのSpacesWebServiceにアタッチするには、次のWLSTコマンドを実行します。

attachWebServicePolicy(application='/wcedg/WC_Spaces1/webcenter', moduleName='webcenter', moduleType='web', serviceName='SpacesWebService', subjectName='SpacesWebServiceSoapHttpPort', policyURI='oracle/wss10_saml_token_service_policy')

attachWebServicePolicy(application='/wcedg/WC_Spaces2/webcenter', moduleName='webcenter', moduleType='web', serviceName='SpacesWebService', subjectName='SpacesWebServiceSoapHttpPort', policyURI='oracle/wss10_saml_token_service_policy')

2. デフォルトのOWSMセキュリティ・ポリシーをクラスタ内の各サーバー(WC_Collaboration1とWC_Collaboration2)上のディスカッションWebサービスにアタッチするには、次のWLSTコマンドを実行します。

attachWebServicePolicy(application='/wcedg/WC_Collaboration1/owc_discussions', moduleName='owc_discussions', moduleType='web', serviceName='OWCDiscussionsServiceAuthenticated', subjectName='OWCDiscussionsServiceAuthenticated', policyURI='oracle/wss10_saml_token_service_policy')

attachWebServicePolicy(application='/wcedg/WC_Collaboration2/owc_discussions', moduleName='owc_discussions', moduleType='web', serviceName='OWCDiscussionsServiceAuthenticated', subjectName='OWCDiscussionsServiceAuthenticated', policyURI='oracle/wss10_saml_token_service_policy')

3. デフォルトのOWSMセキュリティ・ポリシーをクラスタ内の各サーバー(WC_Portlet1とWC_Portlet2)上のサービス・プロデューサのWebサービス・エンド・ポイントにアタッチするには、次のWLSTコマンドを実行します。

attachWebServicePolicy(application='/wcedg/WC_Portlet1/services-producer#11.1.1.6.0', moduleName='services-producer', moduleType='web', serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

attachWebServicePolicy(application='/wcedg/WC_Portlet2/services-producer#11.1.1.6.0', moduleName='services-producer', moduleType='web', serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

4. デフォルトのOWSMセキュリティ・ポリシーをクラスタ内の各サーバー(WC_Portlet1とWC_Portlet2)上のWSRPツール・プロデューサのWebサービス・エンド・ポイントにアタッチするには、次のWLSTコマンドを実行します。

attachWebServicePolicy(application='/wcedg/WC_Portlet1/wsrp-tools#11.1.1.4.0', moduleName='wsrp-tools', moduleType='web', serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

attachWebServicePolicy(application='/wcedg/WC_Portlet2/wsrp-tools#11.1.1.4.0', moduleName='wsrp-tools', moduleType='web', serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

5. WC_Spaces1、WC_Spaces2、WC_Collaboration1、WC_Collaboration2、WC_Portlet1およびWC_Portlet2管理対象サーバーを再起動します。

12.2 ディスカッション・サーバーの接続の構成

WebCenter Portalでディスカッションまたはお知らせを提供するには、アプリケーションをディスカッション・サーバーに接続する必要があります。WebCenter Portalエンタープライズ・デプロイメントで接続を構成するには、次の値が必要です。

- ディスカッション・サーバーのURL: http://wcpinternal.example.com/owc_discussions

- ディスカッション管理ユーザー: ディスカッション・サーバーの管理ユーザー名

- ディスカッション管理パスワード: ディスカッション・サーバーの管理パスワード

- 認証されたユーザーのWebサービス・ポリシーURI: WSS 1.0 SAMLトークン・クライアント・ポリシー

ディスカッション・サーバーには、次に従ってFusion Middleware ControlまたはWLSTコマンドを使用して接続できます。

- 第12.2.1項「Fusion Middleware Controlを使用したディスカッション・サーバーの接続の作成」

- 第12.2.2項「WLSTを使用したディスカッション・サーバーの接続の作成」

詳細は、『Oracle WebCenter Portalの管理』の「お知らせおよびディスカッションの管理」を参照してください。

注意:
ディスカッションまたはお知らせを提供するには、ディスカッションWebサービスに対するセキュリティ・ポリシーも構成する必要があります。詳細は、第12.1項「WebCenter Portal、ディスカッションおよびポートレット・プロデューサ・アプリケーション用デフォルトWebサービス・ポリシーの構成」を参照してください。

12.2.1 Fusion Middleware Controlを使用したディスカッション・サーバーの接続の作成

ディスカッション・サーバーにFusion Middleware Controlを使用してWebCenter Portalアプリケーションを接続するには、次の手順を実行します。

1. アプリケーションがデプロイされている管理対象サーバーが最低1つは起動され稼働していることを確認します。
たとえば、いずれかのWC_Spaces管理対象サーバー。

2. http://SOAHOST1:7001/emでEnterprise Manager Fusion Middleware Control Consoleにログオンします。

3. WebCenter Portalアプリケーションのホーム・ページに移動します。
たとえば、WebCenter Portalアプリケーションのホーム・ページに移動するには、「Farm_wcpedg_domain」→「WebCenter」→「ポータル」→「スペース」→WebCenter Portal (WC_Spaces1)の順に選択します。

4. WebCenter Portalのドロップダウン・メニューから、「設定」→「サービス構成」を選択します。

5. 「ディスカッションおよびお知らせ」をクリックし、「追加」をクリックします。

6. 「ディスカッションおよびお知らせ接続の追加」画面で、次のように設定します。

- 接続名: DFConnection

- アクティブな接続: 接続を有効にするは、このチェック・ボックスを選択します

- サーバーURL: http://wcpinternal.example.com/owc_discussions

- 管理者ユーザー名: 管理者権限を持つディスカッション・サーバー・ユーザーの名前

- 認証されたユーザーのWebサービス・ポリシーURI: 「WSS 1.0 SAMLトークン・クライアント・ポリシー」(oracle/wss10_saml_token_client_policy)を選択します。

7. 「OK」をクリックして設定を保存します。

8. アプリケーションがデプロイされている管理対象サーバーを再起動します。
WebCenter Portalアプリケーションについては、Spaces_Cluster内の管理対象サーバーをすべて再起動します。

12.2.2 WLSTを使用したディスカッション・サーバーの接続の作成

WebLogic Scripting Toolを使用し、WebCenter Portalアプリケーションをディスカッション・サーバーに接続するには、次の手順を実行します。

1. WebLogic Scripting Toolを起動します。

WCPHOST1> MW_HOME/wc/common/bin/wlst.sh

2. WLSTで、管理者として接続します。
例:

connect("weblogic","admin password","ADMINVHN:7001")

3. createDiscussionForumConnectionコマンドを使用し、ディスカッション・サーバーに接続します。
例:

createDiscussionForumConnection(appName="webcenter",name="DFConnection",
url="http://wcpinternal.example.com/owc_discussions",
adminUser="weblogic_wc",default=1,policyURIForAuthAccess="oracle/wss10_saml_token_client_policy",server="WC_Spaces1")

ここで、webcenterはWC_Spaces1にデプロイされたWebCenter Portalアプリケーションの名前であり、weblogic_wcはディスカッション・サーバーの管理ユーザーの名前です。

『WebLogic Scripting Toolコマンド・リファレンス』のcreateDiscussionForumConnectionに関する項も参照してください。

4. アプリケーションがデプロイされている管理対象サーバーを再起動します。
WebCenter Portalアプリケーションについては、Spaces_Cluster内の管理対象サーバーをすべて再起動します。

12.3 インスタント・メッセージおよびプレゼンス(IMP)サーバー接続の構成

インスタント・メッセージングおよびプレゼンス・サーバーの構成方法の手順は、『Oracle WebCenter Portalの管理』のインスタント・メッセージおよびプレゼンス・サーバーの登録に関する項を参照してください。

12.4 ワークリストおよびワークフロー用のBPELサーバー接続の構成

ポータル・メンバーシップ・ワークフローなどのワークリストやワークフローでは、BPELサーバーへの接続が必要です。WebCenter Portalエンタープライズ・デプロイメントの接続を構成するには、次の値が必要です。

- SOAPサーバーURL: http://wcpinternal.example.com

BPELサーバーには、次に従って、Fusion Middleware ControlまたはWLSTコマンドを使用して接続します。

- 第12.4.1項「開始する前に」

- 第12.4.2項「Fusion Middleware Controlを使用したワークリストおよびワークフローの構成」

- 第12.4.3項「WLSTを使用したワークリストおよびワークフローの構成」

12.4.1 開始する前に

ワークリストとワークフロー・アプリケーションをホストするBPELサーバーに、WebCenter Portalアプリケーションを接続する前に、次の手順を実行する必要があります。

1. ワークリストの前提条件の手順を完了します。
詳細は、『Oracle WebCenter Portalインストレーション・ガイド』のワークリストのバックエンド要件に関する項を参照してください。

2. (WebCenter Portalアプリケーションのみ) WebCenter Portalワークフローの前提条件の手順を完了します。
詳細は、『Oracle WebCenter Portalインストレーション・ガイド』のWebCenter Portalワークフローのバックエンド要件に関する項を参照してください。

12.4.2 Fusion Middleware Controlを使用したワークリストおよびワークフローの構成

Fusion Middleware Controlを使用しWebCenter PortalアプリケーションをBPELサーバーに接続するには、次の手順を実行する必要があります。

1. アプリケーションがデプロイされている管理対象サーバーが最低1つは起動され稼働していることを確認します。
たとえば、いずれかのWC_Spaces管理対象サーバー。

2. http://SOAHOST1:7001/emでEnterprise Manager Fusion Middleware Control Consoleにログオンします。

3. WebCenter Portalアプリケーションのホーム・ページに移動します。
たとえば、WebCenter Portalアプリケーションのホーム・ページに移動するには、「Farm_wcpedg_domain」→「WebCenter」→「ポータル」→「スペース」→WebCenter Portal (WC_Spaces1)の順に選択します。

4. ワークリストの接続を構成する手順は次のとおりです。

1. WebCenter Portalのドロップダウン・メニューから、「設定」→「サービス構成」を選択します。

2. 「ワークリスト」→「追加」をクリックします。

3. 「ワークリスト接続の追加」画面で、次のように設定します。
接続名: WorklistConnection

アクティブな接続: チェック・ボックスを選択すると、ワークリストの接続が有効になります。

BPEL SOAP URL: http://wcpinternal.example.com

4. 「OK」をクリックして設定を保存します。

5. (WebCenter Portalアプリケーションのみ) WebCenter PortalワークフローをホストするBPELサーバーを指定します。

1. WebCenter Portalのドロップダウン・メニューから、「設定」→「アプリケーション構成」を選択します。

2. 「接続名」ドロップダウンで、ワークフローがデプロイされているBPELサーバー接続を選択します。
希望のBPELサーバーがリストにない場合、手順4に従って接続を設定します。

3. 「適用」をクリックして設定を保存します。

6. アプリケーションがデプロイされている管理対象サーバーを再起動します。
WebCenter Portalについては、Spaces_Cluster内の管理対象サーバーをすべて再起動します。

12.4.3 WLSTを使用したワークリストおよびワークフローの構成

WLSTを使用して、WebCenter PortalアプリケーションをBPELサーバーに接続し、ワークリストおよびWebCenter Portalワークフロー用のBPELサーバーを指定する手順は次のとおりです。。

1. WebLogic Scripting Toolを起動します。

WCPHOST1> MW_HOME/wc/common/bin/wlst.sh

2. WLSTで、管理者として接続します。
例:

connect("weblogic","admin password","ADMINVHN:7001")

3. 次のようにBPELサーバー接続を構成します。
例:

createBPELConnection(appName="webcenter", name="WorklistConnection", url="http://wcpinternal.example.com",server="WC_Spaces1")

ここで、webcenterは、WC_Spaces1にデプロイされたWebCenter Portalアプリケーションの名前です。

『WebLogic Scripting Toolコマンド・リファレンス』のcreateBPELConnectionに関する項も参照してください。

4. BPEL接続を使用するためのワークリストを構成します。
例:

addWorklistConnection(appName="webcenter", name="WorklistConnection", verbose=1,server="WC_Spaces1")

『WebLogic Scripting Toolコマンド・リファレンス』のaddWorklistConnectionに関する項も参照してください。

5. (WebCenter Portalのみ) WebCenter PortalワークフローがデプロイされているBPELサーバーをポイントする接続を指定します。
例:

setSpacesWorkflowConnectionName(appName="webcenter", name="WorklistConnection",server="WC_Spaces1")

getSpacesWorkflowConnectionName(appName="webcenter",server="WC_Spaces1")

『WebLogic Scripting Toolコマンド・リファレンス』のsetSpacesWorkflowConnectionNameに関する項も参照してください。

6. アプリケーションがデプロイされている管理対象サーバーを再起動します。
WebCenter Portalについては、Spaces_Cluster内の管理対象サーバーをすべて再起動します。

12.5 ポートレット・プロデューサの登録

WebCenter Portalアプリケーションに、すぐに使用できるいくつかのポートレット・プロデューサを登録できます。WebCenter Portalエンタープライズ・デプロイメントでは、必要なプロデューサのURLは次のとおりです。

- WSRPプロデューサURL:
http://wcpinternal.example.com/wsrp-tools/portlets/wsrp2?WSDL

- WebClippingプロデューサURL:
http://wcpinternal.example.com/portalTools/webClipping/providers

- OmniPortletプロデューサURL:
http://wcpinternal.example.com/portalTools/omniPortlet/providers

ポートレット・プロデューサは、次に従ってFusion Middleware ControlまたはWLSTコマンドを使用して登録できます。

- 第12.5.1項「Fusion Middleware Controlを使用したすぐに使用できるポートレット・プロデューサの登録」

- 第12.5.2項「WLSTを使用したすぐに使用できるポートレット・プロデューサの登録」

12.5.1 Fusion Middleware Controlを使用したすぐに使用できるポートレット・プロデューサの登録

Fusion Middleware Controlを使用してポートレット・プロデューサを登録する方法の詳細は、『Oracle WebCenter Portalの管理』の「ポートレット・プロデューサの管理」の章を参照してください。

12.5.2 WLSTを使用したすぐに使用できるポートレット・プロデューサの登録

WLSTを使用し、すぐに使用できるポートレット・プロデューサを登録するには、次の手順を実行します。

1. WebLogic Scripting Toolを起動します。

WCPHOST1> MW_HOME/wc/common/bin/wlst.sh

2. WLSTで、管理者として接続します。
例:

connect("weblogic","admin password","ADMINVHN:7001",server="WC_Spaces1")

3. すぐに使用できる3つのWSRPおよびPDK-Javaプロデューサをすべて登録します。
例:

registerOOTBProducers(producerHost='wcpinternal.example.com',producerPort=80, appName='webcenter', server='WC_Spaces1')

ここで、webcenterは、WC_Spaces1にデプロイされたWebCenter Portalアプリケーションの名前です。

『WebLogic Scripting Toolコマンド・リファレンス』のregisterOOTBProducersに関する項も参照してください。

12.6 ページレット・プロデューサの登録

WSRP、Oracle JPDKポートレットおよびOpenSocialガジェットをWebCenter Portalでページレットとして公開するには、ページレット・プロデューサを登録する必要があります。WebCenter Portalエンタープライズ・デプロイメントでは、必要なページレット・プロデューサのURLは次のとおりです。

http://wcpinternal.example.com/pagelets

ページレット・プロデューサはFusion Middleware ControlまたはWLSTコマンドを使用して登録できます。詳細な手順は、『Oracle WebCenter Portalの管理』を参照してください。

- Fusion Middleware Controlを使用したページレット・プロデューサの登録

- WLSTを使用したページレット・プロデューサの登録

12.7 検索サービスの構成

『Oracle WebCenter Portalの管理』のOracle SES検索の管理に関する項の手順を使用して、Oracle Secure Enterprise Search (Oracle SES)のサービスとクローラを構成できます。

次のことを確認します。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のOracle SES - 構成に関する項の説明のとおり、Oracle Secure Enterprise SearchはOracle Internet Directoryに登録され、WebCenter PortalアプリケーションはOracle SESの信頼できるエンティティとして構成されています。

- 『Oracle WebCenter Portalの管理』のOracle SES接続の設定に関する項の説明のとおり、WebCenter PortalアプリケーションとOracle Secure Enterprise Searchの間には接続が存在します。

次に示すように、新しいURLがいずれも、wcinternal_vh.confファイルのwcpinternal.example.comホストに追加されていることを確認します。

<Location /rsscrawl>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
</Location>

<Location /sesUserAuth>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
</Location>

第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」も参照してください。

12.8 通知用のメール・サーバーの構成

WebCenter Portalアプリケーションの通知サービスの設定方法の詳細は、『Oracle WebCenter Portalの管理』の通知の設定に関する項を参照してください。

WebCenter Portalエンタープライズ・デプロイメントで、メールを使用して通知を送信するよう選択した場合、メール通知用に構成されたすべての送信者のメール・アドレス(つまり「送信者」フィールド)をオーバーライドする、mail.user.emailAddressというプロパティをメール・サーバー接続に追加設定する必要があります。このプロパティを追加設定しない場合には、sender_mail_address@server1などのように、クラスタ内のサーバー名の1つが送信者のメール・アドレスに追加されます。

Fusion Middleware ControlまたはWLSTを使用すると、メール・サーバー接続用にプロパティを追加設定できます。詳細は、次を参照してください。

- Fusion Middleware Controlを使用したメール・サーバーの登録(表17-7 )

- WLSTを使用したメール・サーバーの登録

たとえば、WLSTを使用し、次を行います。

setMailConnectionProperty(appName='webcenter', name='myMail_Server_Connection_Name', key='mail.user.emailAddress', value='myShared_User_Email_Address')

説明:

myMail_Server_Connection_Name - 通知サービスで使用するメール・サーバー接続の名前。

myShared_User_Email_Address - 共有メール・アドレス。これは、外部アプリケーションの共有資格証明に指定されたユーザーに関連付けられたメール・アドレスです。このメール・アドレスを使用してメール・サーバーにログインできることを確認します。

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

この章では、Oracle WebCenter ContentをWebCenter Portalエンタープライズ・デプロイメントで使用するために、ドメインを拡張および構成する手順について説明します。

注意:
セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

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

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

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

- unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播

- WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成

- WCPHOST1およびWCPHOST2でのノード・マネージャの起動

- 管理サーバーの再起動

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

- WebCenter ContentのためのGridLinkデータ・ソース構成およびONS構成の検証

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

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

- WLS_WCC2管理対象サーバーの起動および構成

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

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

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

- Oracle HTTP Serverを介したアクセスの検証

- インストールのバックアップ

- WebCenter Portal用のOracle WebCenter Contentの構成

- WebCenter PortalアプリケーションへのOracle WebCenter Contentの登録

- Inbound Refineryのインストールおよび構成

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

Oracle WebCenter Contentシステムは、第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」で作成された、共有記憶域上のWL_HOMEとORACLE_HOMEの場所を使用してインストールされます。WCPHOST1およびWCPHOST2では、MW_HOMEをマウントし、既存のOracle Weblogic Server、Oracle SOA Suite、Oracle WebCenter PortalおよびOracle WebCenter Contentバイナリ・インストールを使用します。

まだインストールしていない場合は、Oracle WebCenter Contentをドメインに追加する前にOracle WebCenter ContentバイナリをMiddlewareホームにインストールします。詳細は、第6.3.2.3項「Oracle WebCenter Contentのインストール」を参照してください。

Oracle WebCenter Contentを追加するためのドメインを拡張します。表13-1に、WebCenter Contentを構成する手順と、WebCenter Content管理対象サーバーを含むドメインを拡張するために必要なタスクを示します。

表13-1 WebCenter Contentを含むドメインの拡張手順

手順

説明

詳細

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogic Serverドメインを拡張します。

第13.2項「Oracle WebCenter Contentを追加するためのドメインの拡張」

ドメイン構成の伝播

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

第13.3項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」

WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成

WebCenter Contentトラフィックをルーティングする方法を指定するルールを、ロード・バランサに構成します。

第13.4項「WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成」

WCPHOST1およびWCPHOST2でのノード・マネージャの起動

WCPHOST1およびWCPHOST2でノード・マネージャを起動します。

第13.5項「WCPHOST1およびWCPHOST2でのノード・マネージャの起動」

ドメインの管理サーバーの再起動

管理サーバーを停止し、再起動します。

第13.6項「管理サーバーの再起動」

1台目のWebCenter Content管理対象サーバーの起動および Oracle WebCenter Content Serverインスタンスの構成

WLS_WCC1管理対象サーバーを起動し、コンテンツ・サーバーの初期構成を完了します。

第13.7項「WLS_WCC1管理対象サーバーの起動」

cwallet.ssoファイルの変更を元の管理サーバーに伝播

更新されたcwallet.ssoファイルを管理サーバー・ディレクトリにコピーします。

第13.10項「管理サーバーのcwalletファイルの更新」

2台目のWebCenter Content管理対象サーバーの起動およびコンテンツ・サーバーのインスタンスの構成

WLS_WCC2管理対象サーバーを構成し、コンテンツ・サーバーの初期構成を完了します。

第13.11項「WLS_WCC2管理対象サーバーの起動および構成」

Oracle RACフェイルオーバー後のサービス再試行の有効化

コンテンツ・サーバーのconfig.cfgファイルでServiceAllowRetry構成パラメータをtrueに設定します。

第13.13項「Oracle WebCenter Contentのサービス再試行の構成」

拡張したドメインでのOracle HTTP Serverの構成

管理対象サーバーとともにOracle HTTP Serverを構成し、フロントエンドHTTPのホストおよびポートの設定、およびWCC_ClusterのWLSクラスタ・アドレスを設定します。

第13.14項「WLS_WCC管理対象サーバー用のOracle HTTP Serverの構成」

Oracle HTTP Serverを介したWebCenter Contentへのアクセスの検証

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

第13.15項「Oracle HTTP Serverを介したアクセスの検証」

WebCenter Contentの構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第13.16項「インストールのバックアップ」

WebCenter Portalで使用するためのコンテンツ・サーバーの設定

WebCenter Portalなどのアプリケーション用にコンテンツ・サーバーを構成します。

第13.17項「WebCenter Portal用のOracle WebCenter Contentの構成」

WebCenter Portalアプリケーションへのコンテンツ・サーバーの登録

コンテンツ・サーバーにWebCenter Portalアプリケーションを接続します。

第13.18項「WebCenter PortalアプリケーションへのOracle WebCenter Contentの登録」

Oracle WebCenter Content: Inbound Refineryのドメインの拡張

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogic Serverドメインを拡張します。

第13.19項「Inbound Refineryのインストールおよび構成」

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

Oracle WebCenter Contentを追加するには、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを拡張する必要があります。オプションで、Oracle WebCenter Contentのみを含む新しいドメインを作成することもできます。

注意:
これらの手順を実行する前に、Oracle Fusion Middleware管理者ガイドの説明に従ってドメインをバックアップしてください。

Oracle WebCenter Contentを追加するためにドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内のすべての管理対象サーバーを停止します。

3. ディレクトリをOracle Fusion Middleware構成ウィザードの場所に変更します。これは共通のOracleホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するSOAHOST1から実行することに注意してください)。

cd ORACLE_COMMON_HOME/common/bin

4. 構成ウィザードを起動します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. 「WebLogicドメイン・ディレクトリ」画面で、WebLogicドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name)を選択し、「次へ」をクリックします。

7. 図13-1に示すとおり、「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。

- Oracle Universal Content Management - Content Server - 11.1.1.0 wcc

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

注意:
Oracle Universal Content Management - Inbound Refinery - 11.1.1.0は選択しないでください。この機能は、第13.19.6項「Inbound Refineryの構成」の説明に従って、後で構成します。

図13-1 Oracle WebCenter Contentの「拡張ソースの選択」画面

8. 「JDBCコンポーネント・スキーマの構成」画面(図13-2)で次を実行します。

1. 「UCMスキーマ」を選択します。

2. RACの構成には、(付録A「Oracle RACでのマルチ・データ・ソースの使用」で説明した)「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます。
ここの手順では、「GridLinkへ変換」を選択します。

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

図13-2 Oracle WebCenter Contentの「JDBCコンポーネント・スキーマの構成」画面

9. 「GridLink RACコンポーネント・スキーマの構成」画面で(図13-3)、次を実行します。

1. 「UCMスキーマ」を選択します。その他のSOAとWebCenter Portalデータ・ソースはそのままにします。

2. 次の各フィールドに値を入力して、RCUでシードされたOracle GridLink 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をサポートしない場合は次を実行します。

- Oracle Database 11gリリース1 (11.1)の場合、各データベースのインスタンス・リスナーの仮想IPとポートを次のように入力します。
custdbhost1-vip.example.com (Port 1521)

および

custdbhost2-vip.example.com (Port 1521)

- Oracle Database 10gの場合、マルチ・データ・ソースを使用し、Oracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- 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サービスのホスト名とポートを入力します。例:
custdbhost1.example.com (Port 6200)

および

custdbhost2.example.com (Port 6200)

図13-3 Oracle WebCenter Contentの「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

その他のすべてのSOAとWebCenter Portalスキーマはそのままにします。

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

11. 「JDBCデータ・ソースのテスト」画面で、UCMスキーマを選択し(または「すべて選択」をクリックし)、「接続のテスト」をクリックします。
「接続結果ログ」に結果が表示されます。スキーマを含むデータベースに正常に接続できたことを確認します。できなかった場合は、「前」をクリックし、前の画面に戻り、入力を修正し、テストを再試行します。

すべての接続に成功したら「次へ」をクリックします。

12. 「オプションの構成」画面で、次の項目を選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

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

13. 「管理対象サーバーの構成」画面で、サーバー名をUCM_server1からWLS_WCC1に変更し、「追加」をクリックしてWLS_WCC2という新しいサーバーを追加し、これらのサーバーに表13-2に示す属性を設定します。
この画面に表示される他のサーバーは変更しないでください。

表13-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_WCC1

WCPHOST1

16200

該当なし

いいえ

WLS_WCC2

WCPHOST2

16200

該当なし

いいえ

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

14. 「クラスタの構成」画面で、「追加」をクリックし、表13-3に示すクラスタを追加します。画面に表示されている他のクラスタは変更せず、そのままにしておきます。

表13-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

WCC_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

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

15. 「サーバーのクラスタへの割当」画面で、次の項目を追加します。この画面に表示されている他の割当ては、このまま変更しません。

- WCC_Cluster

- WLS_WCC1

- WLS_WCC2

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

16. 「マシンの構成」画面で「Unixマシン」タブをクリックし、次の2つの新規マシンが表示されることを確認します。

表13-4 マシン

名前

ノード・マネージャのリスニング・アドレス

WCPHOST1

WCPHOST1

WCPHOST2

WCPHOST2

その他すべてのフィールドはデフォルト値のままにします。「次へ」をクリックします。

17. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- WLS_WCC1をWCPHOST1に割り当てます。

- WLS_WCC2をWCPHOST2に割り当てます。
「次へ」をクリックします。

18. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

19. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

20. 「構成のサマリー」画面で、「拡張」をクリックします。

21. ドメインのポートの競合に関する警告ダイアログで「OK」をクリックします。

22. 「ドメインの作成中」画面で、「完了」をクリックします。

23. 管理サーバーを起動し、これらの変更を反映します。第13.6項「管理サーバーの再起動」を参照してください。

24. 管理コンソールにログインし、手動により次のデプロイメントのターゲットをクラスタの1つのノードのみに変更し(第10.9項「アクティビティ・グラフの構成」の手順を繰り返す)、すべての管理対象サーバーを再起動します。

- activitygraph-engines

- oracle.webcenter.activitygraph.enginelib

- oracle.webcenter.activitygraph.lib

13.3 unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播

ドメイン構成を伝播する手順は次のとおりです。

1. 次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

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

注意:
前回のpack/unpack処理からの指定されたテンプレート・パックjarファイルが存在する場合は、別の名前(edgdomaintemplateWCC2.jarなど)を選択します。

2. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・パックをSOAHOST2、WCPHOST1およびWCPHOST2にコピーします。

注意:
WCPHOST1がORACLE_HOMEをWCPHOST2と共有していると仮定した場合、テンプレートは、WCPHOST2の同一のディレクトリに存在します(そうでなければ、これもWCPHOST2にコピーします)。

scp edgdomaintemplateWCC.jar oracle@SOAHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin

scp edgdomaintemplateWCC.jar oracle@WCPHOST1:ORACLE_BASE/product/fmw/oracle_common/common/bin

scp edgdomaintemplateWCC.jar oracle@WCPHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin

3. unpackコマンドをSOAHOST2、WCPHOST1とWCPHOST2で実行し、伝播されたテンプレートを解凍します。

注意:
unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

SOAHOST2> cd ORACLE_COMMON_HOME/common/bin
SOAHOST2> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name -template=edgdomaintemplateWCC.jar -app_dir=ORACLE_BASE
/admin/domain_name/mserver/applications -overwrite_domain=true

WCPHOST1> cd ORACLE_COMMON_HOME/common/bin
WCPHOST1> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name -template=edgdomaintemplateWCC.jar -app_dir=ORACLE_BASE
/admin/domain_name/mserver/applications -overwrite_domain=true

WCPHOST2> cd ORACLE_COMMON_HOME/common/bin
WCPHOST2> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name -template=edgdomaintemplateWCC.jar -app_dir=ORACLE_BASE
/admin/domain_name/mserver/applications -overwrite_domain=true

注意:
unpackを実行する前に、ORACLE_BASE/admin/domain_name/mserver/ディレクトリが存在している必要があります。また、ORACLE_BASE/admin/domain_name/mserver/applications/ディレクトリが空である必要があります。

13.4 WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成

このWebCenter Portalエンタープライズ・デプロイメントでは、ロード・バランサが両方のコンテンツ・サーバー・インスタンス間でトラフィックの負荷を分散します。ロード・バランサは、WebCenter PortalからWCPHOST1またはWCPHOST2のいずれかのコンテンツ・サーバー・インスタンスに、ソケット接続で転送します。

WebCenter Portalからコンテンツ・サーバーへの接続はHTTPではなくソケット接続であるため、このソケットをオープンした後は、新しいソケットをオープンせずに、再利用されます。これは、最初にオープン・ソケットを取得したいずれかのコンテンツ・サーバー・インスタンスが継続的に使用され、トラフィックの大部分を受信することを意味します。

ロード・バランサでは、固定性を有効にできません。WebCenter Portalクライアントは一度に1つの接続のみをオープンしますが、両方のコンテンツ・サーバー・インスタンスが要求を処理できるようにする必要があります。追加のWebCenter Portalクライアントがこれらのコンテンツ・サーバー・インスタンスを使用している場合、これは特に重要です。

WebCenter Contentトラフィックをルーティングする方法を指定するルールによって、ロード・バランサを構成する必要があります。次に例を示します。

- (LBR) LBR_IP_ADDRESS:4444 -> WCPHOST1_IP_ADDRESS:4444 (WCPHOST1) -> WCPHOST1_IP_ADDRESS:4444 (WCPHOST2)

第3.3項「ロード・バランサの構成」も参照してください。

ロード・バランサのWebCenter Contentソケット(ポート4444)の構成方法の詳細は、第13.9項「(WLS_WCC1管理対象サーバー上の)コンテンツ・サーバーの構成」を参照してください。

13.5 WCPHOST1およびWCPHOST2でのノード・マネージャの起動

ノード・マネージャが起動されていない場合、次の手順を実行し、WCPHOST1とWCPHOST2上のノード・マネージャを起動します。

1. ノード・マネージャを起動する前に、WCPHOST1およびWCPHOST2の両方で、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティを'true'に設定します。

WCPHOSTn> cd ORACLE_COMMON_HOME/common/bin
WCPHOSTn> ./setNMProps.sh

注意:
クラスのロード失敗などの問題を回避するために、StartScriptEnabledプロパティを使用する必要があります。

注意:
第3章「エンタープライズ・デプロイメント用のネットワークの準備」の共有記憶域構成で示しているように、Oracle WebCenter Content Serverがローカル記憶域または共有記憶域でSOAおよびWebCenter PortalとMW_HOMEを共有している場合には、setNMProps.shを再度実行する必要はありません。この場合、ノード・マネージャはすでに起動スクリプトを使用するように構成されています。

2. WCPHOST1およびWCPHOST2の両方で次のコマンドを実行し、ノード・マネージャを起動します。

WCPHOSTn> cd WL_HOME/server/bin
WCPHOSTn> ./startNodeManager.sh

13.6 管理サーバーの再起動

加えた変更を有効にするために管理サーバーを再起動します。管理サーバーを再起動するには、最初に管理コンソールを使用してサーバーを停止し、次に第8章「SOAHOST1での管理サーバーの起動」の説明に従って再起動します。

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

この項では、新しいWLS_WCC1管理対象サーバーを起動する方法について説明します。

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

1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_WCC1管理対象サーバーを起動します。

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

2. 「サーバー」を選択します。

3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

4. 「WLS_WCC1」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

13.8 WebCenter ContentのためのGridLinkデータ・ソース構成およびONS構成の検証

コンテンツ・サーバーの構成やWLS_WCC1の伝播を行う前に、前に作成したGridLinkデータ・ソースの構成とOracle Notification Service (ONS)の設定がデータ・ソースに対して正しいことを検証する必要があります。

WebCenter Content用のGridLinkデータ・ソースの構成とONSの構成を検証するには、次の手順を実行します。

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

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 作成されたGridLinkデータ・ソース名をクリックします。たとえば、CSDSです。

4. 「監視」→「テスト」の順にクリックし、「WLS_WCC1」を選択して「データ・ソースのテスト」をクリックします。
構成が正しい場合、テストは成功します。

5. 「統計」タブをクリックし、「WLS_WCC1」をクリックします。

6. 「ONS」→「テスト」タブをクリックします。

7. サーバーを選択し、「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データ・ソースを使用するすべてのWebLogic Serverインスタンスで、ONSテストを繰り返します。

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

この項では、WebCenter Portalエンタープライズ・デプロイメントに、コンテンツ・サーバー(WLS_WCC1上)を構成する方法を説明します。

注意:
このWebCenter Portalエンタープライズ・デプロイメントでは、ロード・バランサが両方のContent Server間のトラフィックの負荷を分散します。まだ実行していない場合は、WebCenter Contentのトラフィックのルーティング方法を指定するルールをロード・バランサに構成する必要があります。詳細は、第13.4項「WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成」を参照してください。

Content Serverを構成するには、次の手順を実行します。

1. Oracle WebLogic Serverの管理ユーザー名とパスワードを使用してhttp://WCPHOST1:16200/csのコンテンツ・サーバーにログインし、構成ページを表示します。

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

2. サーバー構成ページで次の値を変更します(すべてのオプションを参照するには、「コンテンツ・サーバーの新規インスタンス」チェック・ボックスを選択してください)。

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

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

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

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

- サーバーのソケット・ポート: これを4444に設定します。

- ソケット接続アドレス・セキュリティ・フィルタを着信中: これを次に示すとおりローカル・ホストおよびサーバーのIPのパイプ区切り一覧に設定します。
127.0.0.1|WCPHOST1_IP_Address|WCPHOST2_IP_Address|WEBHOST1_IP_Address|WEBHOST2_IP_Address |LBR_IP_Address

注意:
この手順では、ホスト名ではなくIPアドレスを使用します。

- WebサーバーのHTTP/HTTPSアドレス: これを wcpinternal.example.comに設定します。
/csへのリクエストで利用可能なすべてのContent Serverノードを使用できるように、ここにロード・バランサのアドレスを入力します。

注意:
まだ実行していない場合、WebCenter Contentトラフィックをルーティングする方法のルールを、次のようにロード・バランサに追加します。

- (LBR) LBR_IP_ADDRESS:4444 -> WCPHOST1_IP_ADDRESS:4444 (WCPHOST1) -> WCPHOST1_IP_ADDRESS:4444 (WCPHOST2)

第13.4項「WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成」も参照してください。

- HTTPSのWebアドレス: このチェック・ボックスを選択解除します。

- コンテンツ・サーバーのインスタンス名: これをWCC_Cluster1に設定します。

- コンテンツ・サーバーのインスタンス・ラベル: これをWCC_Cluster1に設定します。

- サーバー・インスタンスの説明: これをCluster WCC_Cluster1に設定します。

- 自動採番接頭辞: これをWCC_Cluster1-に設定します。

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

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

Oracle WebCenter Content Serverは、起動時にORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfigにあるcwallet.ssoファイルを更新します。この変更を管理サーバーに伝播して戻す必要があります。これを行うには、次のコマンド(全部で1行)を使用して、ファイルをSOAHOST1のORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfigにコピーします。

WCPHOST1> scp ORACLE_BASE/admin/domain_name/mserver/
domain_name/config/fmwconfig/cwallet.sso oracle@SOAHOST1:ORACLE_BASE
/admin/domain_name/aserver/domain_name/config/fmwconfig/

注意:
WLS_WCCnサーバーでORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfigディレクトリにあるcwallet.ssoファイルを変更する操作を行った場合は、SOAHOST1の管理サーバー・ドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig)にそのファイルをすぐにコピーする必要があります。

13.11 WLS_WCC2管理対象サーバーの起動および構成

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

次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_WCC2管理対象サーバーを起動します。

1. Oracle WebLogic Server管理コンソールを使用して次の操作を実行します。

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

2. 「サーバー」を選択します。

3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

4. 「WLS_WCC2」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.9項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

WLS_WCC2管理対象サーバーの構成

WLS_WCC2管理対象サーバーを構成する手順:

1. http://WCPHOST2:16200/csでOracle WebLogic Serverの管理ユーザー名とパスワードを使用してWLS_WCC2にログインし、構成ページを表示します。

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

2. 「サーバーの構成」ページで次の値を変更します。

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

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

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

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

3. 「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。

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

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

テキスト・エディタを使用して、次のオプションを各クラスタ・ノードのMSERVER_HOME/ucm/cs/bin/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はWCPHOST1上にあり、WLS_WCC2はWCCPHOST2上にあるなど、ノードのサーバー名と一致している必要があります。

この変更は、第13.13項「Oracle WebCenter Contentのサービス再試行の構成」で説明される手順の最後に、すべてのWebCenter Content管理対象サーバーを再起動させてから有効になります。

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

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

Oracle RACのフェイルオーバー時にログインの再試行を可能にするため、Oracle Content Serverのconfig.cfgファイル内の次のパラメータを設定します。

ServiceAllowRetry=true

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

Oracle WebCenter Content用のServiceAllowRetry構成パラメータを追加する手順は次のとおりです。

1. Oracle WebCenter ContentのWebLogic Server管理コンソール(http://WCPHOST1:16200/cs)にアクセスし、Oracle WebLogic Serverの管理ユーザー名とパスワードを使用してログインします。

2. 「管理」ページを開き、「管理サーバー」を選択します。

3. 「コンテンツ管理サーバー」ページで、左側の「一般構成」をクリックします。

4. 「一般構成」ページで、「追加の構成変数」ボックスに、次のパラメータを追加します。

ServiceAllowRetry=true

5. 「保存」をクリックし、すべてのWebCenter Content管理対象サーバー(WLS_WCCn)を再起動します。

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

ORACLE_BASE/admin/wc_domain/WCC_Cluster/cs/config/config.cfg

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

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

(WLS_WCC1およびWLS_WCC2管理対象サーバーを含む)WCC_ClusterにOracle HTTP Serverをルーティングするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

1. WEBHOST1とWEBHOST2上で、例13-1で太字で示したディレクティブを、次のディレクトリにあるwcp_vh.confファイルに追加します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

第7.6項「仮想ホストの定義」の指示に従って、wcp_vh.confファイルを作成している必要があります。

wcp_vh.confファイルは例13-1のように表示されます。

例13-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>
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>

#Oracle WebCenter Content
<Location /cs>
WebLogicCluster WCPHOST1:16200,WCPHOST2:16200
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /adfAuthentication>
WebLogicCluster WCPHOST1:16200,WCPHOST2:16200
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /_ocsh>
WebLogicCluster WCPHOST1:16200,WCPHOST2:16200
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

</VirtualHost>

注意:
エンタープライズ・デプロイメントにMicrosoft Officeの統合またはMicrosoft SharePointサーバーへのアクセスが必要な場合は、仮想ホストの追加が必要です。詳細は、『Oracle WebCenter Portalの管理』のMicrosoft Office統合の管理に関する項を参照してください。

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

13.15 Oracle HTTP Serverを介したアクセスの検証

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

1. WLS_WCC2が稼働している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_WCC1を停止します。

2. http://wcp.example.com/csにアクセスし、正しく動作していることを確認します。

3. Oracle WebLogic Server管理コンソールでWLS_WCC1を起動します。

4. Oracle WebLogic Server管理コンソールでWLS_WCC2を停止します。

5. http://wcp.example.com/csにアクセスし、正しく動作していることを確認します。

13.16 インストールのバックアップ

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』も参照してください。

インストールをバックアップするには、次の手順を実行します。

1. Web層をバックアップします。SOAHOST1からコマンドを実行します。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドを実行して、Web層のOracleインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

cd ORACLE_BASE/admin/instance_name/bin
opmnctl startall

2. データベースのバックアップを取ります。これは、Oracle Recovery Manager(推奨)またはtarなどのオペレーティング・システム・ツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。オペレーティング・システム・ツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは、すべてORACLE_BASE/admin/ domain_nameディレクトリの下にあります。
次のコマンドを実行してバックアップを作成します。

SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

13.17 WebCenter Portal用のOracle WebCenter Contentの構成

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

- 第13.17.1項「必須のContent Serverコンポーネントの有効化」

- 第13.17.2項「Dynamic Converterコンポーネントの有効化および構成」

- 第13.17.3項「その他のContent Server機能の追加構成」

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

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

- WebCenterConfigure - WebCenter PortalおよびPortal Frameworkアプリケーション用のContent Serverのインスタンスを構成できます。

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

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

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

詳細な手順は、『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

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

オプションであるが強く推奨

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

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

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

その他のいくつかのContent Server機能は、必須ではないものの、WebCenter Portalエンタープライズ・デプロイメントにおける追加機能を提供します。たとえば、Site Studio、OracleTextSearchなどの機能を有効にすることも可能です。詳細説明および詳細手順については、『Oracle WebCenter Portalの管理』のコンテンツ・サーバーの構成ロードマップに関する項を参照してください。

13.18 WebCenter PortalアプリケーションへのOracle WebCenter Contentの登録

Oracle WebCenter Content ServerをWebCenter Portalアプリケーションに追加する手順は次のとおりです。

注意:
Content Serverの登録の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のコンテンツ・リポジトリの管理に関する説明を参照してください。

1. Enterprise Manager Fusion Middleware Controlにログインし、アプリケーションのホーム・ページに移動します。
たとえば、WebCenter Portalのホーム・ページに移動するには、「WebCenter」→「Portal」→「スペース」→「WebCenterポータル」を開きます。

2. 「WebCenter Portal」メニューから「設定」→「サービス構成」を選択します。

3. 「WebCenterサービス構成」ページのサービスのリストから、「コンテンツ・リポジトリ」を選択します。

4. 新しいコンテンツ・リポジトリに接続するには、「追加」をクリックします。

5. この接続の一意の名前を入力し、コンテンツ・リポジトリ・タイプを指定します。また、この接続がアプリケーションのアクティブな(デフォルトの)接続であるかどうかを指定します。

- 接続名
コンテンツ・リポジトリ接続に一意の名前を入力します。この名前は、WebCenter Portalアプリケーション内のすべての接続タイプ間で一意である必要があります。

- リポジトリ・タイプ
接続先のリポジトリのタイプとして「Oracle Content Server」を選択します。

- アクティブな接続
これをWebCenter Portalアプリケーションのデフォルトのコンテンツ・リポジトリにします。

WebCenter Portalアプリケーションを複数のコンテンツ・リポジトリに接続して、すべての接続を使用することができます。1つの接続をデフォルト(またはアクティブな)接続に指定する必要があります。

6. WebCenter Portalのコンテンツ・リポジトリの詳細を追加入力します。

- コンテンツ管理者
このContent Serverインスタンスに対する管理者権限を持つユーザー名を入力します。このユーザーは、WebCenter Portalコンテンツ用のフォルダの作成および保守、さらにコンテンツ・アクセス権の管理に使用されます。デフォルトはsysadminです。ここで、有効な管理ユーザーを構成します。WebCenter Portalユーザーにかわって操作を実行するには、この接続に対する管理権限が必要です。

- ルート・フォルダ
WebCenter Portalのすべてのコンテンツが格納されるルート・フォルダを入力します。まだ存在しないコンテンツ・リポジトリ・フォルダを指定するには、/foldernameの形式を使用します。たとえば、/MyWebCenterPortalなどです。ルート・フォルダは、ルート自体である/にはできず、アプリケーション全体で一意である必要があります。指定したフォルダはアプリケーションの起動時に作成されます。無効なエントリは、/、/foldername/、/foldername/subfolderなどです。

- アプリケーション名
このコンテンツ・リポジトリ内のWebCenter Portalアプリケーションに対して一意の名前を入力します。たとえば、MyWebCenterPortalAppなどです。

名前は、先頭がアルファベットで、その後はアルファベットまたはアンダースコアの任意の組合せである必要があります。文字列は、14文字以下である必要があります。

この名前は、複数のWebCenter Portalアプリケーションが同じコンテンツ・リポジトリを共有している場合にデータを区別するために使用され、アプリケーション間で一意であることが必要です。また、ドキュメント関連のワークフロー、そのポータル・アプリケーションで作成されたすべてのデータが格納されるセキュリティ・グループおよびセキュリティ・ロールを指定するため、また特定のWebCenter Portalインスタンスに対するユーザー権限およびデフォルト属性をストライプするために使用されます。

7. コンテンツ・リポジトリの接続の詳細を入力します。

- RIDCソケット・タイプ
「ソケット」を選択すると、Content Serverとの接続に、intradocソケットが使用されます。

Content Serverの認証アドレスのリストにクライアントIPアドレスを追加する必要があります。この場合、クライアントは、Oracle WebCenter Portalが実行されているマシンです。

- サーバー・ホスト
/csへのリクエストで利用可能なすべてのコンテンツ・サーバー・ノードを使用できるように、ここにはロード・バランサのアドレス(wcpinternal.example.com)を入力します。

第13.9項「(WLS_WCC1管理対象サーバー上の) コンテンツ・サーバーの構成」の手順2で説明したように、ロード・バランサ上で構成されている仮想ホストのIPアドレスおよびロード・バランサのSelf-IPを、コンテンツ・サーバーの「受信ソケット接続アドレス・セキュリティ・フィルタ」に追加する必要があります。

注意:
まだ実行していない場合、WebCenter Contentトラフィックをルーティングする方法のルールを、次のようにロード・バランサに追加します。

- (LBR)10.110.10.135:4444 -> 10.110.10.23:4444 (WCPHOST1) -> 10.110.10.24:4444 (WCPHOST2)

第3.3項「ロード・バランサの構成」も参照してください。

- サーバー・ポート
Content Serverがリスニングするポート4444を入力します。

- 接続タイムアウト(ミリ秒)
接続タイムアウト・メッセージを発行するまで、Content Serverへのログインを許可する時間の長さ(ミリ秒)を指定します。タイムアウトが設定されていない場合、ログイン操作の時間制限はありません。環境に応じた適切なタイムアウトを選択します。たとえば、30000です。

- 認証方式
「アイデンティティ伝播」を選択します。このエンタープライズ・デプロイメントでは、Content ServerとWebCenter Portalアプリケーションは、ユーザーの認証に同じアイデンティティ・ストアを使用します。

- Webコンテキスト・ルート
Content ServerのWebサーバー・コンテキスト・ルートとして/csを入力します。

- 管理者ユーザー名
このOracle Content Serverインスタンスに対する管理者権限を持つユーザー名を入力します。このユーザーは、プロファイルに基づくコンテンツ・タイプ情報のフェッチおよびWebCenter Portalキャッシュ無効化のためのドキュメント変更の追跡に使用されます。デフォルトはsysadminです。

- 管理者パスワード
Content Server管理者のパスワード。socketTypeがwebに設定されている場合に必要です。

8. 「OK」をクリックしてこの接続を保存します。

9. 新しい(アクティブな)接続の使用を開始するには、WebCenter Portalアプリケーションがデプロイされている管理対象サーバーを再起動する必要があります。

13.19 Inbound Refineryのインストールと構成

Inbound Refineryは、Oracle WebCenter Contentによるドキュメント変換のために必要です。

可用性の理由から、少なくとも2つのInbound Refinery管理対象サーバーを別々のマシン上にインストールおよび構成することをお薦めします。WebCenter Portalエンタープライズ・デプロイメント・トポロジ内では、Oracle Webcenter Content Serverと同じマシン上にInbound Refineryをインストールして構成します。

Inbound Refineryを含むドメインを拡張するプロセスでIBR_Clusterというサーバー・グループを作成しても、各Inbound Refineryインスタンスは完全に独立しており、クラスタとして機能することはありません。サーバー・グループは管理のためにのみ使用されます。

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

- 第13.19.1項「Inbound Refineryを追加するためのドメインの拡張」

- 第13.19.2項「unpackユーティリティを使用したWCPHOST1およびWCPHOST2へのドメイン構成の伝播」

- 第13.19.3項「uploadおよびstageディレクトリの絶対パスへの変更」

- 第13.19.4項「管理サーバーの再起動」

- 第13.19.5項「Inbound Refinery管理対象サーバーの起動」

- 第13.19.6項「Inbound Refineryの構成」

13.19.1 Inbound Refineryを追加するためのドメインの拡張

Oracle WebCenter Content: Inbound Refinery (Inbound Refinery)を追加するには、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを拡張する必要があります。

注意:
これらの手順を実行する前に、『Oracle Fusion Middleware管理者ガイド』の説明に従ってドメインをバックアップします。

Inbound Refineryを追加するためにドメインを拡張する手順:

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内のすべての管理対象サーバーを停止します。

3. ディレクトリをOracle Fusion Middleware構成ウィザードの場所に変更します。これは共通のOracleホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するSOAHOST1から実行することに注意してください)。

cd ORACLE_COMMON_HOME/common/bin

4. 構成ウィザードを起動します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリ (ORACLE_BASE/admin/domain_name/aserver/domain_name)を選択し、「次へ」をクリックします。

7. 「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。

- Oracle Universal Content Management - Inbound Refinery - 11.1.1.0 [wcc]

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

8. 「JDBCコンポーネント・スキーマの構成」画面で必要な手順はありません。Inbound Refineryでは、データベースにスキーマがありません。「次へ」をクリックして続行します。

9. 「オプションの構成」画面で、次の項目を選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

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

10. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
サーバーが自動的に作成されます。このサーバーの名前をWLS_IBR1に変更し、WLS_IBR2という新しいサーバーを追加します。表13-5に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは変更せず、そのままにしておきます。

表13-5 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_IBR1

WCPHOST1

16250

該当なし

いいえ

WLS_IBR2

WCPHOST2

16250

該当なし

いいえ

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

11. 「クラスタの構成」画面で、「追加」をクリックし、表13-6に示すクラスタを追加します。画面に表示されている他のクラスタは変更せず、そのままにしておきます。

表13-6 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

IBR_Cluster

ユニキャスト

該当なし

該当なし

空のままにします。

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

注意:
すべてのInbound Refineryインスタンスは完全に独立しています。サーバー・グループIBR_Clusterは管理のためにのみ使用されます。

12. 「サーバーのクラスタへの割当」画面で、IBR_Clusterに次のサーバーを割り当てます。

- WLS_IBR1

- WLS_IBR2

この画面に表示されている他の割当ては変更しないでください。「次へ」をクリックします。

13. 「マシンの構成」画面で、「次へ」をクリックします。

14. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- WLS_IBR1をWCPHOST1に割り当てます。

- WLS_IBR2をWCPHOST2に割り当てます。

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

15. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- usermessagingserverおよびusermessagingdriver-emailが、SOA_Clusterにのみターゲット設定されていること。
usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです。

- wsm-pmアプリケーションが、WSM-PM_Clusterにのみターゲット設定されていること。
Web Services ManagerをSOA_Clusterにデプロイする予定である場合は、wsm-pmアプリケーションをSOA_Clusterにもターゲット設定します。

- oracle.rules.*およびoracle.soaの各デプロイメントが、SOA_ClusterおよびSpaces_Clusterにのみターゲット設定されていること。

- oracle oracle.sdp.*およびoracle.soa.workflow.wcの各デプロイメントが、SOA_Cluster、Spaces_ClusterおよびPortlet_Clusterにのみターゲット設定されていること。

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

16. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

17. 「構成のサマリー」画面で、「拡張」をクリックします。

18. 「ドメインの作成中」画面で、「完了」をクリックします。

19. 管理サーバーを起動し、これらの変更を反映します。第8.4.3項「SOAHOST1での管理サーバーの起動」を参照してください。

20. 管理コンソールにログインし、手動により次のデプロイメントのターゲットをクラスタの1つのノードのみに変更し(第10.9項「アクティビティ・グラフの構成」の手順を繰り返す)、すべての管理対象サーバーを再起動します。

- activitygraph-engines

- oracle.webcenter.activitygraph.enginelib

- oracle.webcenter.activitygraph.lib

13.19.2 unpackユーティリティを使用したWCPHOST1およびWCPHOST2へのドメイン構成の伝播

ドメイン構成を伝播する手順は次のとおりです。

1. 次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=edgdomaintemplateIBR.jar -template_name=edgdomain_templateIBR

注意:
前回のpack/unpack処理からの指定されたテンプレート・パックjarファイルが存在する場合は、別の名前(edgdomaintemplateIBR2.jarなど)を選択します。

2. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・パックをWCPHOST2にコピーします。

注意:
WCPHOST1がORACLE_HOMEをSOAHOST1と共有していると仮定した場合、テンプレートは、WCPHOST1の同一のディレクトリに存在します(そうでなければ、これもWCPHOST1にコピーします)。

scp edgdomaintemplateIBR.jar oracle@WCPHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin

3. unpackコマンドをWCPHOST1で実行し、伝播されたテンプレートを解凍します。

注意:
unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-template=edgdomaintemplateIBR.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
-overwrite_domain=true

注意:
unpackを実行する前に、ORACLE_BASE/admin/domain_name/mserver/ディレクトリが存在している必要があります。また、ORACLE_BASE/admin/domain_name/mserver/applications/ディレクトリが空である必要があります。

4. WCPHOST2に対して3の手順を繰り返します。

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

ドメイン変更の伝播後、uploadおよびstageディレクトリを更新します。詳細な手順は、第8.5.2項「uploadおよびstageディレクトリの絶対パスへの変更」を参照してください。

13.19.4 管理サーバーの再起動

管理サーバーを再起動して、ここまでの変更を有効にします。管理サーバーを再起動するには、最初に管理コンソールを使用してサーバーを停止し、第8.4.3項「SOAHOST1での管理サーバーの起動」の説明に従って再起動します。

13.19.5 Inbound Refinery管理対象サーバーの起動

WCPHOST1上のWLS_IBR1とWCPHOST2上のWLS_IBR2管理対象サーバーを起動する手順:

1. http://ADMINVHN:7001/consoleのOracle WebLogic Server管理コンソールにログインします。

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

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

4. 表の「サーバー」列から「WLS_IBR1」と「WLS_IBR2」を選択します。

5. 「起動」をクリックします。

13.19.6 Inbound Refineryの構成

Inbound Refineryの構成を初期化するために、その管理対象サーバーにHTTP経由で1回のみアクセスする必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound RefineryインスタンスはHTTPサーバーの後方に配置する必要があります。

Inbound Refinery管理対象サーバーに対する以降のすべてのアクセスは、ソケット・リスナーを介して行われます。このリスナーは、次の項で構成する着信ソケット接続アドレス・セキュリティ・フィルタによって保護されます。

すべてのInbound Refineryインスタンスを使用して各Oracle WebCenter Content Serverを構成することをお薦めします。Oracle WebCenter Contentの構成プロセスは、Inbound Refineryインスタンスをプロバイダとして追加することです。Inbound Refineryのインストール後の手順も実行する必要があります。

次の項では、Inbound Refineryのインストール後の構成手順について説明します。

- 第13.19.6.1項「Inbound Refineryの設定の構成」

- 第13.19.6.2項「ドキュメント変換の構成」

- 第13.19.6.3項「Inbound RefineryインスタンスのOracle WebCenter Contentへの構成」

13.19.6.1 Inbound Refineryの設定の構成

Inbound Refineryの設定を構成する手順は次のとおりです。

1. 次のURLからInbound Refineryのインストール後の構成画面にアクセスします。

http://WCPHOST1:16250/ibr/

2. 構成画面で、構成を次のとおり設定します。

- Inbound Refineryのインスタンス・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/ibr1に設定します。ディレクトリ・パスは共有ディスクに配置し、Inbound Refineryインスタンスごとに一意である必要があります。

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

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

- ユーザー・プロファイル・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/ibr1/data/users/profilesに設定します。

- ソケット接続アドレス・セキュリティ・フィルタ: これを、次に示すとおりローカル・ホストおよびサーバーのIPのパイプ区切り一覧に設定します。

127.0.0.1|WCPHOST1-IP|WCPHOST2-IP|WEBHOST1-IP|WEBHOST2-IP

これにより、Oracle WebCenter Content Serverから接続できるようになります。WCPHOST1-IPおよびWCPHOST2-IPの値は、Inbound Refineryにジョブを送信するコンテンツ・サーバー・インスタンスを持つマシンのIPアドレスである必要がありますが、必ずしもInbound RefineryのIPアドレスとはかぎりません。(ただし、このエンタープライズ・デプロイメント・ガイドで使用される参照トポロジでは、これらのIPアドレスは同じです。)

このフィールドでは、ワイルドカードを含む値(192.0.2.*など)を使用できます。この値は、ORACLE_BASE/admin/domain_name/mserver/domain_name/ucm/ibr/config/config.cfgのSocketHostAddressSecurityFilterを設定し、Inbound Refineryを再起動することによって、後で変更できます。

- サーバーのソケット・ポート: 5555のように、使用されていないポート番号を入力します。この値は、トップレベルのサービスを呼び出すためのポートの番号です。このフィールドの値を変更すると、ORACLE_BASE/admin/domain_name/mserver/domain_name/ucm/ibr/config/config.cfg内の IntradocServerPortエントリが変更されます。このポート番号は、後でOracle WebCenter Contentの構成時に必要となるため、書き留めておいてください。

- サーバー・インスタンス名: Inbound Refinery管理対象サーバー・インスタンス名を指定します。デフォルトの値をそのまま使用することも、より便利な名前に変更することもできます。このサーバー名は、後でOracle WebCenter Contentの構成時に必要となるため、書き留めておいてください。

構成ページの他のすべてのフィールドはそのままにします。

3. Inbound Refinery管理対象サーバーを再起動します。

4. コンテンツ・フォルダには異なる名前を使用して、すべてのInbound Refineryに対してこれらの手順を繰り返します。

Inbound Refineryが正常に機能するには、フォント・イメージを生成するために使用されるフォントへのパスを指定する必要があります。デフォルトでは、フォント・パスはInbound Refineryで使用されるJVM内のフォント・ディレクトリ(MW_HOME/jdk160_version/jre/lib/fonts)に設定されます。ただし、デフォルト・ディレクトリに含まれるフォントは限定されているため、レンディションが低下する可能性があります。また、非標準のJVMを使用した場合、デフォルトで指定されているJVMのフォント・パスと異なることがあります。この場合、エラー・メッセージがInbound RefineryとContent Serverの両方から表示されます。これが発生した場合は、変換を正しくレンダリングするために必要なフォントを含むディレクトリにフォント・パスが設定されていることを確認してください。詳細は、『Oracle WebCenter Content Conversion管理者ガイド』のフォント・パスの指定に関する項を参照してください。

13.19.6.2 ドキュメント変換の構成

ドキュメント変換を構成する手順は次のとおりです。

1. 次のURLからInbound Refineryにログインします。

http://WCPHOST1:16250/ibr/

2. Inbound Refineryでの変換コンポーネントを有効にします。コアInbound Refineryは、ファイルをTIFF Web表示可能ファイルおよびJPEGイメージ・サムネイルに変換します。追加の変換タイプを使用するには、必要なコンポーネントを有効にする必要があります。

注意:
変換コンポーネントの詳細は、Oracle Fusion Middleware変換についての管理者ガイドのInbound Refinery変換オプションと関連コンポーネントに関する項を参照してください。

1. 「管理」トレイまたはメニューを開き、「管理サーバー」を選択し、「コンポーネント・マネージャ」を選択します。

2. 目的のコンポーネントを選択します。詳細は、readmeファイルおよび各コンポーネントのドキュメントを参照してください。

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

4. 「OK」をクリックして、コンポーネントを有効にします。

5. Inbound Refinery管理対象サーバーを再起動します。

3. Inbound RefineryでPDFExportConverterを有効にします。PDFExportConverterは、Outside Inを使用して、ドキュメントを直接PDFファイルに変換します。この変換はクロス・プラットフォームにすることができ、サードパーティ製品を必要としません。Inbound Refinery用のPDFExportConverterはサービス機能として有効にできます。

1. 「管理」トレイまたはメニューを開き、「管理サーバー」を選択し、「コンポーネント・マネージャ」を選択します。

2. 「PDFExportConverter」を選択します。

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

4. 「OK」をクリックして、この機能を有効にします。

5. Inbound Refinery管理対象サーバーを再起動します。

4. プライマリWeb表示可能変換をPDFエクスポートに設定します。

1. 「変換設定」→「プライマリWebレンディション」を選択します。

2. 「プライマリWeb表示可能レンディション」ページで、「PDFエクスポートによるPDFへの変換」を選択します。

3. 「更新」をクリックして変更内容を保存します。

これで、Inbound Refineryは、サードパーティ・アプリケーションを使用せずに、Outside In PDF Exportを使用してファイルをPDFに直接変換します。

5. 管理サーバーとすべてのInbound Refinery管理対象サーバーを再起動します。

13.19.6.3 Inbound RefineryインスタンスのOracle WebCenter Contentへの構成

Oracle WebCenter ContentでInbound Refineryインスタンスを構成するには、(第13.19.1項「Inbound Refineryを追加するためのドメインの拡張」の説明に従って)次の手順を繰り返し、インストールされ構成されている各Inbound Refineryサービスを登録します。

1. http://WCPHOST1:16200/csでContent Serverにログインします。

2. 「管理」→「プロバイダ」を選択します。

3. 「プロバイダ」ページの「新規プロバイダの作成」セクションで、「送信」行の「追加」をクリックします。

4. 名前、説明、ホスト、サーバー・ポート(IBR intradocポート)、コンテキスト・ルート、インスタンス名など、Inbound Refineryインスタンスの詳細を入力します。

- プロバイダ名:WLS_IBRn (空白が含まれない任意の短い宣言された名前)。「インスタンス名」と同じ値を使用することをお薦めします。
Inbound Refineryインスタンス名は、Inbound Refineryサーバーから取得します。インスタンス名を検索するには、Inbound Refineryにログインし、「管理」→「instanceNameの構成」を選択します。

注意:
この手順を実行しないと、「管理」メニューに「リファイナリ管理」メニュー・アイテムが表示されなくなります。

- プロバイダの説明: テキスト文字列。

- サーバー・ホスト名: Inbound Refineryインスタンスが実行されているホスト・マシンの名前。たとえば、WCPHOST1など。

- HTTPサーバー・アドレス: Inbound Refineryインスタンスのアドレス。たとえば、WCPHOST1: 16250など。

- サーバー・ポート: 第13.19.6.1項「Inbound Refineryの設定の構成」で指定されているInbound Refineryインスタンスの「サーバーのソケット・ポート」フィールドの値(たとえば、5555など)。これは、Content Serverのconfig.cfgファイルにあるIntradocServerPortの値です。

- インスタンス名: 第13.19.6.1項「Inbound Refineryの設定の構成」で指定されているInbound Refineryのサーバー・インスタンス名。これは、Content Serverのconfig.cfgファイルにあるIDC_Nameの値です。

- 相対Webルート: Inbound RefineryインスタンスのWebルート。たとえば、/ibr/など。

5. 「変換オプション」で、「Inbound Refinery変換ジョブの処理」を選択します。
「Inbound Refineryの読取り専用モード」は選択しないでください。

6. 「追加」をクリックします。

7. WLS_IBRnを再起動します。

8. すべてのInbound Refineryサービスについて手順2から7を繰り返します。

9. Inbound Refineryに送信されるファイル・タイプを選択します。

1. 「管理」→「リファイナリ管理」→「ファイル・フォーマット・ウィザード」を選択します。

2. リファイナリに送信する適切なファイル・タイプのボックスを選択します。
WebCenterConversionsコンポーネントを介して、変換を有効にしている場合を除き、「HTML」や「Wiki」、「ブログ」は選択しないでください。『Oracle WebCenter Portalの管理』の変換するファイル形式の選択に関する項も参照してください。

10. WikiとブログのPDFへの変換を有効にします。
詳細は、『Oracle WebCenter Portalの管理』のWikiおよびブログのPDFへの変換の有効化に関する項を参照してください。

14 エンタープライズ・デプロイメント用のサーバー移行の構成

この章では、エンタープライズ・デプロイメント用にサーバー移行を構成する手順を説明します。

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

- エンタープライズ・デプロイメント用のサーバー移行の概要

- サーバー移行リース表のユーザーおよび表領域の設定

- 管理コンソールによるリース用のGridLinkデータ・ソースの作成

- ノード・マネージャのプロパティ・ファイルの編集

- wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定

- サーバー移行ターゲットの構成

- サーバー移行のテスト

14.1 エンタープライズ・デプロイメント用のサーバー移行の概要

WLS_SOA1およびWLS_SOA2管理対象サーバーのサーバー移行を構成します。サーバー移行が構成されていると、障害が発生したときに、WLS_SOA1管理対象サーバーがSOAHOST2で再起動し、WLS_SOA2管理対象サーバーがSOAHOST1で再起動します。WLS_SOA1およびWLS_SOA2サーバーは、Oracle WebLogic Serverによってフェイルオーバーされる特定の浮動IPをリスニングします。

次の項の手順を実行し、管理対象サーバーのサーバー移行を構成します。

14.2 サーバー移行リース表のユーザーおよび表領域の設定

create tablespace leasingコマンドを使用して、サーバー移行リース表のユーザーおよび表領域を設定します。

サーバー移行リース表のユーザーおよび表領域を設定する手順は次のとおりです。

1. leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。

SQL> create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. leasingというユーザー名を作成し、リース表領域に割り当てます。

SQL> create user leasing identified by password;

SQL> grant create table to leasing;

SQL> grant create session to leasing;

SQL> alter user leasing default tablespace leasing;

SQL> alter user leasing quota unlimited on LEASING;

3. leasing.ddlスクリプトを使用してリース表を作成します。

1. 次のいずれかのディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。

WL_HOME/server/db/oracle/817
WL_HOME/server/db/oracle/920

2. leasingユーザーとしてデータベースに接続します。

3. leasing.ddlスクリプトをSQL*Plusで実行します。

SQL> @copy_location/leasing.ddl;

14.3 管理コンソールによるリース用のGridLinkデータ・ソースの作成

Oracle WebLogic Server管理コンソールからリース表用のGridLinkデータ・ソースを作成します。

GridLinkデータ・ソースを作成する手順は次のとおりです。

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

2. まだ行っていない場合は、「チェンジ・センター」で「ロックして編集」をクリックし、「次へ」をクリックします。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. 「データ・ソースのサマリー」ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次を入力します。

- 「名前」フィールドにデータ・ソースの論理名を入力します。たとえば、leasingです。

- JNDIの名前を入力します。たとえば、jdbc/leasingです。

- 「データベース・ドライバ」には、OracleのGridLink接続用ドライバ(Thin) バージョン 11以降を選択します。

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

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」で「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACサービス名を入力します。例:

wcpedg.example.com

- ホスト名およびポート: 使用しているRACデータベースのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用しデータベースで適切なパラメータを問い合せることによって特定できます。

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string db-scan.example.com:1521

注意:
Oracle Database 11g R1では、次のように、各データベースのインスタンス・リスナーにVIPとポートを使用します。

custdbhost1-vip.example.com (port 1521)

および

custdbhost2-vip.example.com (1521)

- データベース・ユーザー名: leasing。

- パスワード: passwordなど

- パスワードの確認: 再度パスワードを入力し、「次へ」をクリックします。

8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。正常に接続された場合の通知例を次に示します。

Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.example.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=wcpedg.example.com))) succeeded.

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

9. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- データベースよりレポートされたRACデータベースとONSリモート・ポートのSCANアドレスもここに入力し(例は下を参照)、「ADD」をクリックします。

[orcl@db-scan ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

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

注意:
Oracle Database 11g R1には、各データベースのONSサービスのホスト名とポートを次のように使用します。

custdbhost1.example.com (port 6200)

および

custdbhost2.example.com (6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
正常に接続された場合の通知例を次に示します。

Connection test for db-scan.example.com:6200 succeeded.

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

11. 「ターゲットの選択」ページで「SOA_Cluster」をターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 「変更のアクティブ化」をクリックします。

14.4 ノード・マネージャのプロパティ・ファイルの編集

サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。nodemanager.propertiesファイルは次のディレクトリにあります。

WL_HOME/common/nodemanager

次のプロパティを追加してサーバー移行が正常に動作するようにします。

- Interface

Interface=eth0

このプロパティは浮動IP (eth0など)のインタフェース名を指定します。

注意:
サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

- NetMask

NetMask=255.255.255.0

このプロパティは浮動IP用インタフェースのネット・マスクを指定します。

- UseMACBroadcast

UseMACBroadcast=true

このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力結果は次のようになります。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:
サーバーのプロパティ(起動プロパティ)が設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

1. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

2. WL_HOME/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。

注意:
共有記憶域インストールからノード・マネージャを実行する場合、同じnodemanager.propertiesファイルを使用して複数のノードが起動します。ただし、NetMaskプロパティやInterfaceプロパティにはノードごとに異なる値が必要です。この場合、環境変数を使用して、ノードごとに個別にパラメータを指定します。たとえば、SOAHOSTnで異なるインタフェース(eth3)を使用するには、Interface環境変数をSOAHOSTn export JAVA_OPTIONS=-DInterface=eth3のように使用し、この変数がシェルに設定された後、ノード・マネージャを起動します。

14.5 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定するには、次の手順を実行します。

1. 表14-1に示すファイルをPATH環境変数で指定していることを確認します。

表14-1 PATH環境変数に必要なファイル

ファイル

ディレクトリの場所

wlsifconfig.sh

ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domain

WL_HOME/common/nodemanager

2. sudoの構成をwlsifconfig.shスクリプトに付与します。

- パスワードの要求がなくても動作するようにsudoを構成します。

- セキュリティ上の理由から、sudoの付与はwlsifconfig.shスクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限は次のように設定します。

1. パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

2. スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。

oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

注意:
この手順に適切なsudo権限とシステム権限については、システム管理者に問い合せてください。

14.6 サーバー移行ターゲットの構成

サーバー移行ターゲットを構成します。「クラスタの移行の構成」では、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。

クラスタ内の移行を構成する手順は次のとおりです。

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

http://host:adminPort/console

通常、adminPortはデフォルトの7001です。

2. 「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

3. 表の「名前」列で、移行を構成するクラスタ(SOA_Cluster)をクリックします。

4. 「移行」タブをクリックします。

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

6. 「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。この場合は、「SOAHOST1」と「SOAHOST2」を選択します。

7. 自動移行に使用するデータソースを選択します。この場合は、リース・データソースを選択します。

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

9. 「変更のアクティブ化」をクリックします。

10. サーバー移行の候補となるマシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。

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

2. 移行を構成するサーバーを選択します。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。「WLS_SOA1」に対しては「SOAHOST2」を選択します。「WLS_SOA2」に対しては「SOAHOST1」を選択します。

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

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

7. 管理サーバーと、サーバー移行が構成されているサーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

ヒント:
「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、実際の構成と異なる内容が表示されます。

14.7 サーバー移行のテスト

サーバーの移行が適切に行われていることを確認する手順は次のとおりです。

ノード1からテストする手順は次のとおりです。

1. WLS_SOA1管理対象サーバーを停止します。

kill -9 pid

pidには、管理対象サーバーのプロセスIDを指定します。ノード内のPIDは、次のコマンドを実行して識別できます。

ps -ef | grep WLS_SOA1

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

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

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

ノード2からテストする手順は次のとおりです。

1. ローカル・ノード・マネージャのコンソールを確認します。ノード1でのWLS_SOA1の再起動が前回試行されてから30秒間経過した後に、WLS_SOA1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。

2. 同じIPでsoa-infraコンソールにアクセスします。

管理コンソールでの確認

管理コンソールを使用して移行を検証することも可能です。

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

2. 左のコンソールで「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。

図14-1 管理コンソールの「移行の状態」画面

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

15 エンタープライズ・デプロイメントとOracle Identity Managementの統合

この章では、Oracle WebCenter PortalをOracle Identity Managementと統合する方法について説明します。

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

- Oracle Identity Managementとの統合の概要

- 資格証明ストアの構成

- ポリシー・ストアの構成

- ドメイン・ポリシーおよび資格証明ストアの再関連付け

- Oracle Access Manager 10gの統合

- Oracle Access Manager 11gの統合

- SSO用のWebCenter Portalアプリケーションの構成

- WebCenter PortalおよびBPEL認証の構成

- アイデンティティ管理構成のバックアップ

15.1 Oracle Identity Managementとの統合の概要

Oracle Fusion Middlewareエンタープライズ・デプロイメントをOracle Identity Manager 10gまたは11gと統合できます。次の各項では、まず資格証明ストアとポリシー・ストアを構成する方法とそれらの資格証明ストアおよびポリシー・ストアを再関連付けする方法を説明し、Oracle Identity Manager 10gまたは11gと統合します。

表15-1は、Oracle Identity Manager 10gをOracle WebCenter Portalエンタープライズ・デプロイメントに統合するための大まかな手順を示しています。

表15-2は、Oracle Identity Manager 11gをOracle WebCenterエンタープライズ・デプロイメントに統合するための大まかな手順を示しています。

注意:
Oracle Identity Managementとの統合時には、Oracle Identity Managementサーバーで現在使用されているトランスポート・モードを使用します。たとえば、オープン、簡易、証明書などです。

表15-1 Oracle Identity Manager 10gとの統合手順

手順

説明

詳細

資格証明ストアの構成

Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成します。

第15.2項「資格証明ストアの構成」

ポリシー・ストアの構成

Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成します。

第15.3項「ポリシー・ストアの構成」

OAM構成ツールの使用

OAM構成ツール(oamcfg)を使用し、一連のスクリプトを起動し、必要なポリシーを設定します。

第15.5.3項「OAM構成ツールの使用」

WebGateのインストールと構成

各WEBHOSTnマシンにWebGateをインストールし、Web層を保護します。

第15.5.4項「WebGateのインストールと構成」

WebGateのIP検証の構成

アクセス・システム・コンソールを使用して、WebGateのIP検証を構成します。

第15.5.5項「WebGateのIP検証の構成」

WebLogicオーセンティケータの設定

構成ファイルのバックアップ、OAM IDアサータの設定およびプロバイダの順序設定によって、WebLogicオーセンティケータを設定します。

第15.5.6項「WebLogicオーセンティケータの設定」

SSO用のWebCenter Portalアプリケーションの構成

SSOのシステム・プロパティ、WebCenter Portalアプリケーションの管理者ロール、SSO用のディスカッション・サーバーを構成します。

第15.7項「SSO用のWebCenter Portalアプリケーションの構成」

WebCenter PortalおよびBPELサーバー認証の構成

WebCenter PortalとBPELサーバーを構成します。

第15.8項「WebCenter PortalおよびBPEL認証の構成」

表15-2 Oracle Identity Manager 11gとの統合手順

手順

説明

詳細

資格証明ストアの構成

Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成します。

第15.2項「資格証明ストアの構成」

ポリシー・ストアの構成

Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成します。

第15.3項「ポリシー・ストアの構成」

WebGateのインストール

HTTPサーバーがすでにインストールされている各WEBHOSTマシンにWebGateをインストールします。

第15.6.3項「WebGateの設定」

WebGateエージェントの登録

RREGツールを使用したWebGateエージェントの登録

第15.6.4項「WebGateエージェントの登録」

WebLogicオーセンティケータの設定

構成ファイルのバックアップ、OAM IDアサータの設定およびプロバイダの順序設定によって、WebLogicオーセンティケータを設定します。

第15.6.5項「WebLogicオーセンティケータのセットアップ」

SSO用のWebCenter Portalアプリケーションの構成

SSOのシステム・プロパティ、WebCenter Portalアプリケーションの管理者ロール、SSO用のディスカッション・サーバーを構成します。

第15.7項「SSO用のWebCenter Portalアプリケーションの構成」

WebCenter PortalおよびBPEL認証の構成

WebCenter PortalとBPELサーバーを構成します。

第15.8項「WebCenter PortalおよびBPEL認証の構成」

15.2 資格証明ストアの構成

Oracle Fusion Middlewareでは、WebLogic Serverドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、Oracle Database、XMLファイル(デフォルト)、または様々なタイプのLDAPプロバイダに基づいてストアを使用できます。ドメインでデータベースまたはLDAPを使用する場合は、すべてのポリシー・データと資格証明データが、一元化されたストアで保持および管理されます。ただし、XMLポリシー・ストアを使用すると、管理対象サーバー上で行われる変更は、管理サーバーに伝播されません(両方のサーバーが同じドメイン・ホームを使用していない場合)。

データベースまたはLDAPベースのストアでは、資格証明およびポリシー・ストアは、システムおよびアプリケーション固有のポリシー、資格証明およびキーのリポジトリであるセキュリティ・ストアの一部です。 この集中化により、ポリシー、資格証明、およびキーに関するデータの管理と保守が容易になります。

注意:
デフォルトのファイル・ベースのポリシーおよび資格証明ストアは、開発のみに使用され、単一ノードのWebCenter Portal構成でのみ使用する必要があります。エンタープライズ・デプロイメントの場合、ポリシー・ストアおよび資格証明ストアをデータベース・ベースのセキュリティ・ストアまたは外部のLDAPベースのストアに再度関連付ける必要があります。この再関連付を、ドメインの作成直後(拡張の前)に実行すると、ポリシーが上書きされず、Oracle Enterprise Manager Fusion Middleware Controlにドメインのアプリケーション・ストライプが表示されます。
本番環境にはデータベース・ベースのセキュリティ・ストアをお薦めします。詳細は、『Oracle Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」を参照してください。

Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジでは、管理サーバーと管理対象サーバーで異なるドメイン・ホームを使用するので、整合性および一貫性を保持するために、ポリシー・ストアおよび資格証明ストアとしてLDAPストアを使用する必要があります。デフォルトでは、Oracle WebLogic Serverドメインは、ポリシー・ストアにXMLファイルを使用します。次の項では、デフォルト・ストアを資格証明またはポリシー用のOracle Internet Directory LDAPに変更するために必要な手順について説明します。

注意:
ポリシー・ストアおよび資格証明ストアのバックエンド・リポジトリは、同じ種類のLDAPサーバーを使用する必要があります。この一貫性を保持するために、一方のストアを再関連付けるともう一方も再関連付けることになります。つまり、資格証明ストアとポリシー・ストアの両方の再関連付けは、Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドreassociateSecurityStoreを使用して、1つの単位として実行されます。詳細は、第15.4項「ドメイン・ポリシーおよび資格証明ストアの再関連付け」を参照してください。

資格証明ストアは、セキュリティ・データ(資格証明)のリポジトリです。資格証明には、ユーザー名とパスワードの組合せ、チケット、または公開鍵証明書が保持されます。資格証明は、認証中(プリンシパルがサブジェクトに移入されるとき)に使用され、さらに認可(サブジェクトが実行可能なアクションを決定するとき)にも使用されます。この項では、Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成する手順を示します。資格証明ストアの構成の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「資格証明ストアの管理」の章を参照してください。

次の項では、資格証明ストアの構成について説明します。

- 第15.2.1項 LDAPオーセンティケータの作成

- 第15.2.2「WebLogic管理者のLDAPへの移行」

15.2.1 LDAPオーセンティケータの作成

この項では、WebLogic Server管理コンソールを使用して、LDAPオーセンティケータを作成する方法について説明します。

前提条件

LDAPオーセンティケータを作成する前に、関連構成ファイルをバックアップする必要があります。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/system-jazn-data.xml

次のディレクトリにある、管理サーバーのboot.propertiesファイルをバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security

LDAPを使用するように資格証明ストアを構成する手順は次のとおりです。

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

2. 左のナビゲーション・バーにある「セキュリティ・レルム」リンクをクリックします。

3. myrealmデフォルト・レルム・エントリをクリックして構成します。

4. このレルム内の「プロバイダ」タブを開きます。

5. このレルム用に構成したDefaultAuthenticatorプロバイダがあることを確認します。

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

7. 「新規」ボタンをクリックし、新しいプロバイダを追加します。

8. プロバイダの名前を入力します。たとえば、OIDAuthenticator (Oracle Internet Directoryが使用される場合)、またはOVDAuthenticator (Oracle Virtual Directoryが使用される場合)のような名前にします。

9. オーセンティケータのリストから、OracleInternetDirectoryAuthenticator (Oracle Internet Directoryが使用される場合)、またはOracleVirtualDirectoryAuthenticator (Oracle Virtual Directoryが使用される場合)のいずれかのタイプを選択し、「OK」をクリックします。

10. 「プロバイダ」画面で、新しく作成したオーセンティケータをクリックします。

11. 「制御フラグ」を「SUFFICIENT」に設定します。このフラグは、このオーセンティケータによって正常に認証されたユーザーは、その認証を受け入れたうえで、他のオーセンティケータを呼び出さないようにすることを示しています。認証に失敗した場合、そのユーザーは、チェーンにある次の順番のオーセンティケータに引き継がれます。以降のすべてのオーセンティケータの制御フラグも「SUFFICIENT」に設定されていることを確認してください。特に「DefaultAuthenticator」を確認し、その制御フラグを「SUFFICIENT」に設定します。

12. 「保存」をクリックしてこの設定を保存します。

13. 「プロバイダ固有」タブを開き、LDAPサーバーの詳細情報を入力します。

14. 次の表に示されているように、使用しているLDAPサーバーに固有の詳細情報を入力します。

パラメータ

値

値の説明

ホスト

例: oid.example.com

LDAPサーバーのサーバーID。

ポート

例: 636

LDAPサーバーのポート番号。

プリンシパル

例: cn=orcladmin

LDAPサーバーに接続するために使用されるLDAPユーザーDN。

資格証明

なし

LDAPサーバーに接続するために使用されるパスワード。

SSL有効

チェック・ボックスを選択

LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。

ユーザー・ベースDN

例: cn=users,dc=us,dc=example,dc=com

ユーザーが起動するDNを指定します。

グループ・ベースDN

例: cn=groups,dc=us,dc=example,dc=com

グループ・ノードを示すDNを指定します。

取得したユーザー名をプリンシパルとして使用する

チェック・ボックスを選択

オンにする必要があります。

完了したら「保存」をクリックします。

15. 「変更のアクティブ化」をクリックして変更を伝播します。

オーセンティケータの並替え

OID/OVDオーセンティケータおよびデフォルト・オーセンティケータを並べ替えて、それぞれのオーセンティケータの制御フラグが次のように設定されていることを確認します。

オーセンティケータの順序を設定する手順は次のとおりです。

1. WebLogicコンソールにログインしていない場合は、ログインします。

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

3. 「セキュリティ・レルム」→デフォルト・レルム名→「プロバイダ」に移動し、「並替え」をクリックします。

4. OID/OVDオーセンティケータおよびデフォルト・オーセンティケータの制御フラグが次のように設定されていることを確認し、これらのオーセンティケータを並べ替えます。

- OID LDAPオーセンティケータ(またはOVD LDAPオーセンティケータ): SUFFICIENT

- デフォルト・オーセンティケータ: SUFFICIENT

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

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

7. 管理サーバーとすべての管理対象サーバーを再起動します。

15.2.2 WebLogic管理者のLDAPへの移行

この項では、Oracle Fusion MiddlewareのWebCenter Portal WebLogic Serverドメインを管理するために、新しい管理者ユーザーおよびグループをプロビジョニングする方法の詳細を説明します。この項では、次の作業について説明します。

- 第15.2.2.1項「LDAPディレクトリでの管理ユーザーおよびグループのプロビジョニング」

- 第15.2.2.2項「管理ロールの管理グループへの割当て」

- 第15.2.2.3項「接続での新しい管理ユーザーの指定」

- 第15.2.2.4項「boot.propertiesファイルの更新およびシステムの再起動」

15.2.2.1 LDAPディレクトリでの管理ユーザーおよびグループのプロビジョニング

この項の冒頭で述べたように、複数のWebLogic Serverドメインのユーザーおよびグループは、中央のLDAPユーザー・ストアにプロビジョニングできます。そのような場合、1人のWebLogic管理ユーザーが企業内のすべてのドメインへのアクセス権を所有している可能性があります。これはお薦めしません。特定のWebLogic Server管理ユーザーによるすべてのドメインへのアクセスを防止するには、プロビジョニングされる各ユーザーおよびグループが、ディレクトリ・ツリー内で一意の識別名を持つ必要があります。このマニュアルで説明するWebCenter Portalエンタープライズ・デプロイメントのWebLogic Serverドメインでは、管理ユーザーおよびグループは、次のDNでプロビジョニングされます。

- 管理ユーザーDN:

cn=weblogic_wc,cn=Users,dc=us,dc=example,dc=com

- 管理グループDN:

cn=WC_Administrators,cn=Groups,dc=us,dc=example,dc=com

管理ユーザーおよび管理グループをOracle Internet Directoryにプロビジョニングする手順は次のとおりです。

1. Oracle Internet Directoryホスト上に、次の内容を含む、admin_user.ldifという名前のldifファイルを作成して保存します。

dn: cn=weblogic_wc, cn=users, dc=us, dc=example, dc=com
orclsamaccountname: weblogic_wc
givenname: weblogic_wc
sn: weblogic_wc
userpassword: MyPassword1
mail: weblogic_wc
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
uid: weblogic_wc
cn: weblogic_wc
description: Admin User for the WebCenter Portal Domain

2. ORACLE_HOME/binディレクトリにあるldapaddコマンドを実行して、このユーザーをOracle Internet Directory内でプロビジョニングします。

注意:
ここで使用するOracleホームは、Oracle Internet Directoryが存在するアイデンティティ管理インストールのOracleホームです。ldapaddコマンドが成功するには、ORACLE_HOME環境変数を設定する必要があります。

次に例を示します(次の例では、読み易さを考慮してコマンドを2行に分けて示してありますが、実際には1行に入力する必要があります)。

OIDHOST1> ORACLE_HOME/bin/ldapadd -h oid.example.com -p 389 -D
cn="orcladmin" -w password -c -v -f admin_user.ldif

3. admin_group.ldifという名前のldifファイルを作成して、次の内容を入力してからこのファイルを保存します。

dn: cn=WC_Administrators, cn=groups, dc=us, dc=example, dc=com
displayname: WC_Administrators
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_wc,cn=users,dc=us,dc=example,dc=com
cn: WC_Administrators
description: Administrators Group for the WebCenter Portal Domain

4. ORACLE_HOME/bin/ディレクトリにあるldapaddコマンドを実行し、グループをOracle Internet Directoryにプロビジョニングします(次の例では、読み易さを考慮してコマンドを2行に分けて示してありますが、実際には1行に入力する必要があります)。

OIDHOST1> ORACLE_HOME/bin/ldapadd -h oid.example.com -p 389 -D
cn="orcladmin" -w password -c -v -f admin_group.ldif

15.2.2.2 管理ロールの管理グループへの割当て

Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内で、グループに管理ロールを割り当てる必要があります。それによって、グループに属すすべてのユーザーをこのドメインの管理者にできるようになります。

管理ロールを管理グループに割り当てる手順は次のとおりです。

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

2. コンソールの左ペインで、「セキュリティ・レルム」をクリックします。

3. 「セキュリティ・レルムのサマリー」ページの表「レルム」で「myrealm」をクリックします。

4. 「myrealm」の「設定」ページで、「ロールとポリシー」タブをクリックします。

5. 「レルム・ロール」ページの表「ロール」の「グローバル・ロール」エントリを開きます。すると、「ロール」のエントリが表示されます。「ロール」リンクをクリックして、「グローバル・ロール」ページを表示します。

6. 「グローバル・ロール」ページで、「管理」ロールをクリックして「グローバル・ロールの編集」ページを開きます。

1. 「グローバル・ロールの編集」ページの表「ロール条件」の「条件の追加」ボタンをクリックします。

2. 「述部の選択」ページで、条件のドロップダウン・リストから「グループ」を選択し、「次へ」をクリックします。

3. 「引数の編集」ページのグループ引数フィールドで「WC_Administrators」を指定し、「追加」をクリックします。

7. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。

8. 「ロール条件」表にWC_Administratorsグループがエントリとして表示されます。

9. 「保存」をクリックして、WC_Administratorsグループへの管理ロールの追加を終了します。

10. Webブラウザを使用してWebLogic管理サーバー・コンソールを起動し、変更が正常に完了したことを検証します。weblogic_wcユーザーの資格証明を使用してログインします。

注意:
Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジの各Oracleアプリケーションには、あらかじめ定義されたロールや管理目的および監視目的で定義されたグループが存在する可能性があります。デフォルトでは、Administratorグループでその作業を実行できます。ただし、Administratorグループは広範になりすぎることもあります。たとえば、Oracle SOA Suite、Oracle WebCenter PortalおよびOracle WebCenter Contentが稼働しているOracle WebLogic Serverドメインの管理者がOracle SOA Suiteの管理者を兼務するのは、望ましくないとも考えられます。したがって、この項で説明するように、WC_Administratorsなど、WebCenter Portal用のより限定的なグループを作成した方がよい場合もあります。様々なアプリケーションでWC Administratorグループが各種のシステムを管理できるようにするには、そのグループに必要なロールを追加する必要があります。たとえば、SOA Worklistappの管理用には、SOA管理者グループにSOAAdminロールを追加します。それぞれのケースで必要なロールについては、各コンポーネントの固有のロールを参照してください。

15.2.2.3 接続での新しい管理ユーザーの指定

新しい管理ユーザーweblogic_wcがLDAPに存在するため、このユーザーをすべての管理操作に使用します。

たとえば、第12.2項「ディスカッション・サーバー接続の構成」で作成したディスカッション・サーバー接続を確認し、管理ユーザーとしてweblogic_wcを指定します。また、第15.7.3.1項「ディスカッション・サーバーでの管理者権限の付与」で説明しているように、このユーザーにディスカッション・サーバーに対する管理者権限があることを確認します。

15.2.2.4 boot.propertiesファイルの更新およびシステムの再起動

管理サーバー用のboot.propertiesファイルは、Oracle Internet Directoryで作成されたWebLogic管理ユーザーを追加して更新する必要があります。次の手順に従って、boot.propertiesファイルを更新します。

1. SOAHOST1で、次のディレクトリに移動します。

cd ORACLE_BASE/admin/domainName/aserver/domainName/servers/
AdminServer/security

2. 既存のboot.propertiesファイルの名前を変更します。

mv boot.properties boot.properties.backup

3. テキスト・エディタを使用して、セキュリティ・ディレクトリにboot.propertiesというファイルを作成します。次の行をこのファイルに入力します。

username=weblogic_wc
password=MyPassword1

4. ファイルを保存します。

5. 管理サーバーを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

6. 管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で再起動します。

15.2.3 ドメイン資格証明ストアの再関連付け

ドメインの資格証明ストアとポリシー・ストアの構成後に、資格証明ストアを再度関連付ける必要があります。必要な手順については、第15.4項「ドメイン・ポリシーおよび資格証明ストアの再関連付け」を参照してください。

15.3 ポリシー・ストアの構成

Oracle Fusion Middlewareでは、WebLogic Serverドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、Oracle Database、XMLファイル(デフォルト)、または様々なタイプのLDAPプロバイダに基づいてストアを使用できます。ドメインでデータベースまたはLDAPを使用する場合は、すべてのポリシー・データと資格証明データが、一元化されたストアで保持および管理されます。ただし、XMLポリシー・ストアを使用すると、管理対象サーバー上で行われる変更は、管理サーバーに伝播されません(両方のサーバーが同じドメイン・ホームを使用していない場合)。

データベースまたはLDAPベースのストアでは、資格証明およびポリシー・ストアは、システムおよびアプリケーション固有のポリシー、資格証明およびキーのリポジトリであるセキュリティ・ストアの一部です。 この集中化により、ポリシー、資格証明、およびキーに関するデータの管理と保守が容易になります。

注意:
デフォルトのファイル・ベースのポリシーおよび資格証明ストアは、開発のみに使用され、単一ノードのWebCenter Portal構成でのみ使用する必要があります。エンタープライズ・デプロイメントの場合、ポリシー・ストアおよび資格証明ストアをデータベース・ベースのセキュリティ・ストアまたは外部のLDAPベースのストアに再度関連付ける必要があります。この再関連付を、ドメインの作成直後(拡張の前)に実行すると、ポリシーが上書きされず、Oracle Enterprise Manager Fusion Middleware Controlにドメインのアプリケーション・ストライプが表示されます。
本番環境にはデータベース・ベースのセキュリティ・ストアをお薦めします。詳細は、『Oracle Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」を参照してください。

ドメイン・ポリシー・ストアは、システム固有のポリシーおよびアプリケーション固有のポリシーのリポジトリです。特定のドメインには、そのドメインにデプロイされるすべてのアプリケーションが使用可能なすべてのポリシーを格納する1つのストアが存在します。この項では、Oracle Fusion Middleware WebCenter Portalエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成する手順を示します。この手順は、2つの部分で構成されています。

- サーバー・ディレクトリでのノードの設定

- ドメイン・ポリシー・ストアの再関連付け

ポリシー・ストアの構成の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」の章を参照してください。

15.3.1 サーバー・ディレクトリでのノードの設定

ポリシー・ストアとして使用されるLDAPサーバー・ディレクトリ(Oracle Internet Directory)に正しくアクセスするためには、このサーバー・ディレクトリにノードを設定する必要があります。この手順はOracle Internet Directory管理者が実行する必要があります。

Oracle Internet Directoryサーバーに適切なノードを作成する手順は次のとおりです。

1. LDIFファイル(この例ではjpstestnode.ldifを想定)を作成し、次のDNエントリおよびCNエントリを指定します。

dn: cn=jpsroot_wc
cn: jpsroot_wc
objectclass: top
objectclass: OrclContainer

ルート・ノードの識別名(前述の文字列jpsroot_wc)は、他の識別名と異なっている必要があります。1つのルート・ノードを複数のWebLogic Serverドメインで共有できます。サブツリーへの読取り権限および書込み権限がOracle Internet Directory管理者に付与されているかぎり、このノードを最上位レベルに作成する必要はありません。

2. 次の例に示すように、ldapaddコマンドを使用して、このデータをOracle Internet Directoryサーバーにインポートします(次の例では、読み易さを考慮してコマンドを2行に分けて示してありますが、実際には1行に入力する必要があります)。

OIDHOST1> ORACLE_HOME/bin/ldapadd -h ldap_host -p ldap_port -D
cn=orcladmin -w password -c -v -f jpstestnode.ldif

3. 次の例に示すように、ldapsearchコマンドを使用して、ノードが正常に挿入されたことを確認します(次の例では、読み易さを考慮してコマンドを2行に分けて示してありますが、実際には1行に入力する必要があります)。

OIDHOST1> ORACLE_HOME/bin/ldapsearch -h ldap_host -p ldap_port -D
cn=orcladmin -w password -b "cn=jpsroot_wc" objectclass="orclContainer"

4. Oracle Internet DirectoryをLDAPベースのポリシー・ストアとして使用する場合は、ユーティリティoidstats.sqlをINFRADBHOSTで実行し、最適なデータベース・パフォーマンスを実現するためのデータベース統計を生成します。

ORACLE_HOME/bin/sqlplus

ユーザー名にODSを入力します。ODSユーザーの資格証明を入力するよう求められます。sqlplusに入って、統計情報を収集する次のコマンドを入力します。

SQLPLUS> @ORACLE_HOME/ldap/admin/oidstats.sql

oidstats.sqlユーティリティは、初期プロビジョニング後に1回だけ実行する必要があります。このユーティリティの詳細は、『Oracle Identity Managementリファレンス』を参照してください。

15.3.2 ドメイン・ポリシー・ストアの再関連付け

ファイルまたはLDAPベースのリポジトリから、LDAPベースのリポジトリにポリシー・データを移行して、ポリシー・ストアを再度関連付けます。再関連付けでは、格納データの整合性を維持しながらリポジトリが変更されます。ソース・ポリシー・ストアの各ポリシーに対して再関連付けを行うと、ターゲットのLDAPディレクトリが検索され、一致が見つかると、一致したポリシーが必要に応じて更新されます。何も見つからない場合は、ポリシーがそのまま移行されます。

ドメイン・ポリシー・ストアをインスタンス化したら、ファイルベースまたはLDAPベースのポリシー・ストアを、同じデータを格納するLDAPベースのポリシー・ストアにいつでも再関連付けできます。そのためには、LDAPポリシー・ストアを使用できるようにドメインが適切に構成されている必要があります。

手順の詳細は、第15.4項「ドメイン・ポリシーおよび資格証明ストアの再関連付け」を参照してください。

15.4 ドメイン・ポリシーおよび資格証明ストアの再関連付け

ポリシー・ストアおよび資格証明ストアをOracle Internet Directoryに再関連付けするには、WLSTのreassociateSecurityStoreコマンドを使用します。

ポリシーおよび資格証明ストアを再関連付けする手順:

1. SOAHOST1から、wlstシェルを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

2. 次に示すwlst connectコマンドを使用して、WebLogic管理サーバーに接続します。
構文:

connect("AdminUser","AdminUserPassword",t3://hostname:port)

例:

connect("weblogic_wc","password","t3://ADMINVHN:7001")

3. 次に示すように、reassociateSecurityStoreコマンドを実行します。
構文:

reassociateSecurityStore(domain="domainName",admin="cn=orcladmin", password="orclPassword",ldapurl="ldap://LDAPHOST:LDAPPORT",servertype="OID",
jpsroot="cn=jpsroot_wc")

例:

wls:/WCPEDGDomain/serverConfig>reassociateSecurityStore(domain="wcpedg_domain",
admin="cn=orcladmin",password="password",ldapurl="ldap://oid.example.com:389",servertype="OID",jpsroot="cn=jpsroot_wc")

このコマンドの出力を次に示します。

{servertype=OID,jpsroot=cn=jpsroot_wc_idm_idmhost1,admin=cn=orcladmin,
domain=IDMDomain,ldapurl=ldap://oid.example.com:389,password=password}
Location changed to domainRuntime tree. This is a read-only tree with
DomainMBean as the root.

For more help, use help(domainRuntime)

Starting Policy Store reassociation.
LDAP server and  ServiceConfigurator setup done.

Schema is seeded into LDAP server
Data is migrated to LDAP server
Service in LDAP server after migration has been tested to be available
Update of jps configuration is done
Policy Store reassociation done.
Starting credential Store reassociation
LDAP server and  ServiceConfigurator setup done.
Schema is seeded into LDAP server
Data is migrated to LDAP server
Service in LDAP server after migration has been tested to be available
Update of jps configuration is done
Credential Store reassociation done
Jps Configuration has been changed. Please restart the server.

4. コマンドが正常に完了した後に、管理サーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

注意:
資格証明とポリシーの変更を有効にするには、ドメイン内のサーバーを再起動する必要があります。

Oracle Internet Directoryの属性のカタログ化

検索フィルタで使用するOracle Internet Directoryの属性に索引を付けます。索引付けは、パフォーマンス向上のためのオプションの手順です。このOracle Internet Directory内の属性への索引付けが済んでいない場合は、catalogツールを使用して索引付けます。

たとえば、orclerolescope属性に索引付けを行う場合は、次のようにします。

catalog connect="orcl" add=true attribute="orclrolescope" verbose="true"

ファイルに複数の属性名を記載してバッチとして処理すると、複数の属性名に索引を付けることができます。

orclrolescope
orclassignedroles
orclApplicationCommonName
orclAppFullName
orclCSFAlias
orclCSFKey
orclCSFName
orclCSFDBUrl
orclCSFDBPort
orclCSFCredentialType
orclCSFExpiryTime
modifytimestamp
createtimestamp
orcljpsassignee

OID属性の索引付けの詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』のタスクおよびカタログの例に関する項を参照してください。

15.5 Oracle Access Manager 10gの統合

この項では、Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのシングル・サインオン・ソリューションとしてOracle Access Manager 10gを設定する方法について説明します。

注意:
Oracle Access Manager 11gと統合する場合は、この項はスキップして第15.6項「Oracle Access Manager 11gの統合」の手順に従い、その後第15.7項「SSO用のWebCenter Portalアプリケーションの構成」に進み、この章の後半の部分を続行します。

この項の内容は次のとおりです。

- 第15.5.1項「Oracle Access Manager 10gの統合の概要」

- 第15.5.2項「Oracle Access Manager 10gの前提条件」

- 第15.5.3項「OAM構成ツールの使用」

- 第15.5.4項「WebGateのインストールと構成」

- 第15.5.5項「WebGateのIP検証の構成」

- 第15.5.6項「WebLogicオーセンティケータの設定」

- 第15.5.7項「OAM 10gでの仮想ホストの構成」

15.5.1 Oracle Access Manager 10gの統合の概要

Oracle Access Manager (OAM)は、Oracle Fusion Middleware 11g リリース1において推奨されるシングル・サインオン・ソリューションです。OAMのインストールおよび構成の詳細は、Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイドを参照してください。この章では、WebCenter Portalのインストールを構成して既存のOAMインストールおよび基礎となるディレクトリ・サービスと連携させる手順について説明します。これらのディレクトリ・サービスには、Oracle Internet Directory (OID)またはOracle Virtual Directory (OVD)、またはその両方を使用することをお薦めします。

注意:
このドキュメントで説明するWebCenter Portalエンタープライズ・デプロイメント・トポロジでは、WebCenter Portalシステムとシングル・サインオン・システムの両方が、同一のネットワーク・ドメイン(example.com)内に存在し、シングル・サインオン構成を使用しています。複数ドメイン構成の場合は、Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service Managerの管理者ガイドのシングル・サインオンの構成に関する項に記載されている、必要な構成手順を参照してください。

15.5.2 Oracle Access Manager 10gの前提条件

Oracle Access Manager (OAM)の設定では、Access Managerおよびポリシー・マネージャを保護するポリシーを完備した、OAMインストールが存在することを前提としています。OAMのインストールおよび構成の詳細は、Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイドを参照してください。この設定には、スタンドアロンのOracle Virtual Directory (OVD)構成またはその一部としてのOracle Internet Directory (OID)などのディレクトリ・サービスがあります。この章では、WebCenter Portalをインストールした環境をOIDまたはOVDを使用して構成する際に必要な手順を説明します。

さらに、OAMのインストール環境にはWebGateで構成した専用のWebサーバーが必要です。またこの項では、OAM Webサーバーを委任認証サーバーとして使用する手順についても説明します。

15.5.3 OAM構成ツールの使用

OAM構成ツール(oamcfg)は、一連のスクリプトを起動して必要なポリシーを設定します。そのためには、入力情報として様々なパラメータが必要となります。具体的には次の項目が作成されます。

- OAMのフォーム認証スキーム

- WebLogicサーバーでの認証を可能にするポリシー

- Web層にあるOracle HTTP Server WebGateで構成済アプリケーションを保護できるようにOAMで指定するWebGateエントリ

- 選択したシナリオに応じたホスト識別子(指定しない場合はデフォルトのホスト識別子が使用されます)

- アプリケーション固有のURLを保護するポリシーおよび保護対象としないポリシー

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

- 第15.5.3.1項「OAM構成ツールの実行の前提条件」

- 第15.5.3.2項「OAM構成ツールの実行」

- 第15.5.3.3項「RESTポリシーの更新」

- 第15.5.3.4項「Oracle SESおよびポートレット用の除外ポリシーの作成」

- 第15.5.3.5項「ポリシー・ドメインおよびアクセス・ゲートを正常に作成したことの確認」

- 第15.5.3.6項「ホスト識別子の更新」

- 第15.5.3.7項「WebGateプロファイルの更新」

- 第15.5.3.8項「アクセス・サーバーの追加」

- 第15.5.3.9項「委任フォーム認証の構成」

15.5.3.1 OAM構成ツールの実行の前提条件

OAM構成ツールを実行する前に次の前提条件を確認します。

- パスワード: セキュアなパスワードを作成します。このパスワードは、この後に作成するWebGateインストールのパスワードとして使用します。

- LDAPホスト: 高可用性やエンタープライズ・デプロイメントの構成の場合は、ディレクトリ・サーバーのホスト名またはロード・バランサのアドレスを用意します。

- LDAPポート: ディレクトリ・サーバーのポートを用意します。

- LDAP USER DN: LDAP管理ユーザーのDNを用意します。これは「cn=orcladmin」などの値です。

- LDAPパスワード: LDAP管理ユーザーのパスワードを用意します。

- oam_aa_host: Oracle Access Managerのホスト名を用意します。

- oam_aa_port: Oracle Access Managerのポートを用意します。

15.5.3.2 OAM構成ツールの実行

OAM構成ツールは次の場所にあります。

ORACLE_COMMON_HOME/modules/oracle.oamprovider_11.1.1

ORACLE_COMMON_HOMEは構成ツールを実行するマシンによって異なります。このツールは、必要なインストール・ファイルがあればすべてのマシンから実行できます。この項で説明する手順では、WCPHOST1からツールを実行します。

OAM構成ツールは、保護されているリソースやパブリック・リソースをOAMシステムに登録する手段を提供します。例15-1と例15-1に、OAMシステムに追加される、保護されているリソースおよびパブリック・リソースのリストを示します。

- ドメインにWebCenter Portal、WebCenter Content、Inbound RefineryおよびSOAがインストールされている場合には、例15-1が当てはまります。

- ドメインにWebCenter Portal、WebCenter ContentおよびInbound Refineryがインストールされている場合には、例15-2が当てはまります。

注意:
「/…/*」は、URLコンテキストの下のすべてのリソースを表します。

例15-1 保護されているURIおよび公開URI (Oracle SOA Suiteを含む)

#########################################
#Product Name: Oracle WebCenter Portal
#########################################
#########################################
protected_uris
#########################################
/webcenter/adfAuthentication
/integration/worklistapp
/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow
/workflow/WebCenterWorklistDetail/faces/adf.task-flow
/workflow/sdpmessagingsca-ui-worklist
/rss/rssservlet
/owc_discussions/login!withRedirect.jspa
/owc_discussions/login!default.jspa
/owc_discussions/login.jspa
/owc_discussions/admin
/rest/api/resourceIndex
/rest/api/spaces
/rest/api/discussions
/rest/api/tags
/rest/api/taggeditems
/rest/api/activities
/rest/api/activitygraph
/rest/api/feedback
/rest/api/people
/rest/api/messageBoards
/rest/api/searchresults
/activitygraph-engines
/wcps/api
/pagelets/admin
/pagelets/authenticateWithApplicationServer
/services-producer/adfAuthentication
/rsscrawl
/sesUserAuth
/services-producer/portlets
/wsrp-tools/portlets
/em
/console
/DefaultToDoTaskFlow
/sdpmessaging/userprefs-ui
/adfAuthentication
/ibr/adfAuthentication
/soa-infra
/soa/composer
/soa-infra/deployer
/soa-infra/events/edn-db-log
/soa-infra/cluster/info
/inspection.wsil
#########################################
public_uris
#########################################
/webcenter
/owc_discussions
/rss
/workflow
/rest/api/cmis
/pagelets
/services-producer
/wsrp-tools
/cs
/ibr
/idcnativews
/
/soa-infra/services/…/*
/soa-infra/directWSDL
/soa-infra/directWSDL/…/*
/ucs/messaging/webservice
/ucs/messaging/webservice/…/*

例15-2 保護されているURIおよび公開URI (Oracle SOA Suiteを含まない)

#########################################
#Product Name: Oracle WebCenter Portal
#########################################
#########################################
protected_uris
#########################################
/webcenter/adfAuthentication
/integration/worklistapp
/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow
/workflow/WebCenterWorklistDetail/faces/adf.task-flow
/workflow/sdpmessagingsca-ui-worklist
/soa-infra
/rss/rssservlet
/owc_discussion/login!withRedirect.jspa
/owc_discussions/login!default.jspa
/owc_discussions/login.jspa
/owc_discussions/admin
/rest/api/resourceIndex
/rest/api/spaces
/rest/api/discussions
/rest/api/tags
/rest/api/taggeditems
/rest/api/activities
/rest/api/activitygraph
/rest/api/feedback
/rest/api/people
/rest/api/messageBoards
/rest/api/searchresults
/activitygraph-engines
/wcps/api
/pagelets/admin
/pagelets/authenticateWithApplicationServer
/services-producer/adfAuthentication
/rsscrawl
/sesUserAuth
/services-producer/portlets
/wsrp-tools/portlets
/em
/console
/adfAuthentication
/ibr/adfAuthentication

#########################################
public_uris
#########################################

/webcenter
/owc_discussions
/rss
/rest/api/cmis
/pagelets
/services-producer
/wsrp-tools
/workflow
/cs
/ibr
/idcnativews

OAM構成ツールを実行する手順は次のとおりです。

1. 使用しているトポロジに応じて、例15-1または例15-2を使用して、保護されるURIおよび公開URIのリストを含むファイルを作成します。

- ドメインにWebCenter Portal、WebCenter Content、Inbound RefineryおよびSOAがインストールされている場合には、例15-1を使用します。

- ドメインにWebCenter Portal、WebCenter ContentおよびInbound Refineryがインストールされている場合には、例15-2を使用します。

OAM 10gでは、URL接頭辞に含まれるすべてのリソースは、ポリシーを介してより個別性の高いルールが適用されている場合を除いて、ポリシー・ドメインのデフォルト・ルールによって保護されます。特別な保護パターンを使用する必要がある場合は、10g版の『Oracle Access Managerアクセス管理ガイド』を参照して、使用可能な他のパターンを確認してください。

2. OAM 10gへの登録のため、次のコマンドを使用して1行のコマンド行でOAM構成ツールを実行します。

MW_HOME/jrockit_160_<version>/bin/java -jar oamcfgtool.jar mode=CREATE
app_domain="WebCenter_EDG"
uris_file="full_path_to_file_containing_uri_definitions"
app_agent_password=<Password_to_be_provisioned_for_App_Agent>
ldap_host=OID.EXAMPLE.COM
ldap_port=389
ldap_userdn="cn=orcladmin"
ldap_userpassword=<Password_of_LDAP_Admin_User>
oam_aaa_host=OAMHOST1
oam_aaa_port=OAMPORT1

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

3. コマンドが正常に実行されたことを確認します。次の出力が表示されます。

Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation
Operation Summary:
Policy Domain: WebCenter_EDG
Host Identifier: WebCenter_EDG
Access Gate ID: WebCenter_EDG_AG

注意:

- SOAを後で追加する場合または別のURLの保護が必要になった場合は、同じapp_domainを使用し、新しいURLのみではなく、保護するURLをすべて指定して、再度OAM構成ツールを実行してください。

- WebCenter Portal、SOAおよびWebCenter Contentにはそれぞれ、公開URIおよび保護されたURIの要件がリストされた.confファイルがあります。ここで示したように単一のファイルに公開URIと保護されるURIを指定するかわりに、uris_file=パラメータを使用して各.confファイルを順に参照するように指定して、OAM構成ツールを複数回実行することもできます。詳細および手順は、『Oracle WebCenter Portalの管理』のWebCenter Portalのポリシー・ドメインの構成に関する項を参照してください。

15.5.3.3 RESTポリシーの更新

基本の認証を使用するようにRESTエンド・ポイントを更新するには、次の手順を実行します。

1. 次の場所にあるOracle Access Managerコンソールにログインします。

http://OAM_HOST:OAM_ADMINSERVER_PORT/oamconsole

2. 「ポリシー・マネージャ」→「ポリシー・ドメイン」をクリックし、前の手順で作成および検証したポリシー・ドメインを選択します。
すでに作成されている2つのポリシー(Protected_JSessionId_Policyおよびデフォルト・パブリック・ポリシー)が表示されるはずです。

3. 「ポリシー」タブを開きます。

4. 次の値を使用して、WebCenterRESTPolicyという名前の別のポリシーを作成します。
説明: このポリシーは、WebCenter OutlookプラグインまたはiPhoneとの統合で必要なBASIC認証スキームを使用する、REST保護対象のURIを保護します。

リソース・タイプ: http

リソース操作: GET,POST

リソース: /restで始まる、/rest/cmis/repository以外のすべてのリソースを選択します。

/rest/api/resourceIndex
/rest/api/spaces
/rest/api/discussions
/rest/api/tags
/rest/api/taggeditems
/rest/api/activities
/rest/api/activitygraph
/rest/api/feedback
/rest/api/people
/rest/api/messageBoards
/rest/api/searchresults

ホスト識別子: リソースで使用するものと同じです。

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

6. 新しく作成したポリシーの「認証ルール」に移動し、認証スキームOraDefaultBasicAuthNSchemeを使用して新しいルールを追加します。

7. 「ポリシー」タブを開き、ポリシーが次の順序になっていることを確認します。
WebCenterRESTPolicy

Protected_JSessionId_Policy

デフォルトのパブリック・ポリシー

15.5.3.4 Oracle SESおよびポートレット用の除外ポリシーの作成

Oracle SES (Secure Enterprise Search)とポートレットの除外ポリシーを作成するには、次の手順を実行します。

1. 次の場所にあるOracle Access Managerコンソールにログインします。

http://OAM_HOST:OAM_ADMINSERVER_PORT/oamconsole

2. OAM 10gインストールでOraDefaultExclusionAuthNSchemeが利用可能であることを確認します。見つからない場合は、次の手順に従ってOraDefaultExclusionAuthNSchemeを作成します。

1. 「認証管理」をクリックします。

2. 「追加」をクリックします。

3. 「名前」フィールドにOraDefaultExclusionAuthNSchemeを指定します。

4. 「説明」フィールドにTo exclude resources from being protected by OAMを入力します。

5. 「レベル」フィールドに0を入力します。

6. 「チャレンジ・メソッド」にNoneを指定します。

7. 「チャレンジ・パラメータ」フィールドに、unprotected:trueを追加します。

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

9. この認証スキームの「プラグイン」タブを開き、「変更」をクリックします。

10. ドロップ・ダウン・リストからcredential_mappingを選択します。

11. 値を次のように指定します。
obMappingBase="dc=us,dc=oracle,dc=com",obMappingFilter="(uid=OblixAnonymous)"

この値がOraDefaultAnonAuthNSchemeの対応するフィールドと一致することを確認します。

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

13. 再度「一般」タブを開き、「変更」をクリックします。

14. 「有効」に対しYesを選択します。

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

3. Exclusion Schemeという新しいポリシーを作成するには、次の手順を実行します。

1. 「ポリシー・マネージャ」→「ポリシー・ドメイン」をクリックし、前の手順で作成および検証したポリシー・ドメインを選択します。
WebCenterRESTPolicy、Protected_JSessionId_PolicyおよびDefault Public Policyの3つのポリシーが表示されます。

2. 「ポリシー」タブを開きます。

3. 次に示す値を使用し、Exclusion Schemeという新しいポリシーを作成します。
説明: This policy excludes SES and portlet end points.

リソース・タイプ: http

リソース操作: GET,POST

リソース: 次のリソースを選択します。

/rsscrawl
/sesUserAuth
/services-producer/portlets
/wsrp-tools/portlets

ホスト識別子: リソースで使用するものと同じです。

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

5. 新しく作成したポリシーの「認証ルール」に移動し、認証スキームOraDefaultExclusionAuthNSchemeを使用して新しいルールを追加します。

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

4. 「ポリシー」タブを開き、ポリシーが次の順序になっていることを確認します。
WebCenterRESTPolicy

Exclusion Scheme

Protected_JSessionId_Policy

デフォルトのパブリック・ポリシー

15.5.3.5 ポリシー・ドメインおよびアクセス・ゲートを正常に作成したことの確認

ポリシー・ドメインとAccessGateの作成を検証する手順は2つの部分で構成されます。

ポリシー・ドメインを検証する手順は次のとおりです。

1. 次のURLを使用してアクセス・システム・コンソールにログオンします。

http://OAMADMINHOST:port/access/oblix

2. 「ポリシー・マネージャ」をクリックします。

3. 左側のパネルで「ポリシー・ドメイン」リンクをクリックします。
すべてのポリシー・ドメインのリストが表示されます。先ほど作成したドメインがここに表示されます。その接尾辞は_PD(たとえば、WebCenter_EDG_PD)となります。3番目の列「URL接頭辞」には、このドメインの作成時に指定したURIが表示されます。

4. 先ほど作成したポリシー・ドメインのリンクをクリックします。
このリンクから、このドメインの「一般」エリアに移動できます。

5. 「リソース」タブをクリックします。
指定したURIが表示されます。他のタブをクリックし、他の設定を表示することもできます。

AccessGate構成を検証する手順は次のとおりです。

1. 右上にある「アクセス・システム・コンソール」リンクをクリックします。
これはトグルのように機能し、クリックすると「ポリシー・マネージャ」リンクに切り替わります。

2. 「アクセス・システム構成」タブをクリックします。

3. 左のパネルにある「アクセス・ゲート構成」リンクをクリックします。

4. 検索条件にWebCenter_EDGと入力し(または第15.5.3.2項「OAM構成ツールの実行」でapp_domain名として使用した他のサブストリングなどを入力)、「実行」をクリックします。

5. 作成したドメインのアクセス・ゲートが表示されたら(アクセス・ゲートの接尾辞は_AGであるため、たとえばWebCenter_EDG_AGなど)、それをクリックすると作成したばかりのアクセス・ゲートの詳細が表示されます。

15.5.3.6 ホスト識別子の更新

OAM構成ツールは、app_domainパラメータの値を使用して(例: WebCenter_EDG)ポリシー・ドメインのホスト識別子を作成します。構成が正常に機能するためには、ホストに対するすべてのホスト名バリエーションを反映してホスト識別子を更新する必要があります。OAM構成ツールで作成したホスト識別子を更新する手順は次のとおりです。

1. 次のURLを使用してアクセス・システム・コンソールにログインします。

http://host_name:port/access/oblix

host_nameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. ユーザー名とパスワードの入力を求められたら、管理者としてログインします。「OK」をクリックします。

3. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックします。

4. 「アクセス・システム・コンソール」ページで、「アクセス・システム構成」タブをクリックします。

5. 「アクセス・システム構成」ページで、左下にある「ホスト識別子」をクリックします。

6. 「すべてのホスト識別子をリスト」ページで、OAM構成ツールで作成したホスト識別子をクリックします。たとえば、「WebCenter_EDG」を選択します。

7. 「ホスト識別子詳細」ページで「変更」をクリックします。

8. アクセス・システム構成で使用される「優先HTTPホスト」の値を追加します。次のリストは、SSO/WebGateを使用する可能性のあるすべてのホスト名のバリエーションを示しています。

- webhost1.mydomain.com:7777

- webhost2.mydomain.com:7777

- wcphost1.example.com:9000

- wcphost2.example.com:9000

- wcphost1.example.com:9001

- wcphost2.example.com:9001

- wcphost1.example.com:9002

- wcphost2.example.com:9002

- wcphost1.example.com:9003

- wcphost2.example.com:9003

- admin.example.com:80

- adminvhn.example.com:7001

- soahost1vhn1.example.com:8001

- soahost2vhn1.example.com:8001

- soahost1vhn1.example.com:8010

- soahost2vhn1.example.com:8010

9. 「キャッシュの更新」の横にあるチェック・ボックスを選択し、「保存」をクリックします。
次のメッセージ・ボックスが表示されます: 「時点でキャッシュを更新すると、システム内のすべてのキャッシュがフラッシュされます。よろしいですか。」。

「OK」をクリックして、構成変更の保存を終了します。

10. 「ホスト識別子詳細」ページで変更内容を確認します。

15.5.3.7 WebGateプロファイルの更新

OAM構成ツールでは、app_domainパラメータの値で作成したWebGateプロファイルのPreferred_HTTP_Hostおよびホスト名属性に値が移入されます。正しく機能する構成とするには、この2つの属性の両方を適切な値で更新する必要があります。OAM CFGツールで作成したWebGateプロファイルを更新する手順は次のとおりです。

1. 次のURLを使用してアクセス・システム・コンソールにログインします。

http://host_name:port/access/oblix

host_nameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。

3. 「アクセス・システム・コンソール」メイン・ページで、「アクセス・システム構成」をクリックし、左ペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

4. 適切な検索条件を入力して、「実行」をクリックし、アクセス・ゲートのリストを表示します。

5. OAM構成ツールで作成したアクセス・ゲートを選択します。たとえば、WebCenter_EDG_AGを選択します。

6. 「アクセス・ゲート詳細」ページで、「変更」を選択し、「アクセス・ゲートの変更」ページを表示します。

7. 「アクセス・ゲートの変更」ページで、次のように更新します。

- ホスト名: WebGateを実行しているコンピュータの名前でホスト名を更新します(webhost1.example.comなど)。

- 優先HTTPホスト: 前述の項で指定したホスト名バリエーションの1つにPreferred_HTTP_Hostを更新します(admin.example.com:80など)。

- プライマリHTTP Cookieドメイン: ドメインの接尾辞がホスト識別子(例: example.com)であるプライマリHTTP Cookieドメインを更新します。

8. 「保存」をクリックします。「これらの変更をコミットしますか。」という内容のメッセージ・ボックスが表示されます。

9. 「OK」をクリックして、構成の更新を終了します。

10. 「アクセス・ゲートの詳細」ページに表示される値を確認し、正常に更新されたことを確認します。

15.5.3.8 アクセス・サーバーの追加

アクセス・サーバーをWebGateに割り当てるには:

1. 次のURLを使用し、Oracle Access Managerに管理者としてログインします。

http://OAMADMINHOST:port/access/oblix

ここで、OAMADMINHOSTにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 必要に応じて、「アクセス・ゲート」ページの「詳細」に移動します。「アクセス・システム・コンソール」から、「アクセス・システム構成」→「アクセス・ゲート構成」→WebGateへのリンク(WebCenter_EDG_AG)を選択します。

3. 「アクセス・ゲート」ページの「詳細」で、「アクセス・サーバーをリスト」をクリックします。

4. このWebGateに現在構成されているプライマリ・アクセス・サーバーまたはセカンダリ・アクセス・サーバーを示すページが表示されます。
「追加」をクリックします。

5. 「新規アクセス・サーバーの追加」ページで、「サーバーの選択」リストから「アクセス・サーバー」を選択して、「プライマリ・サーバー」を指定し、WebGateの「接続数」を増やします。たとえば接続数を1から2に増やします。
「追加」ボタンをクリックして関連付けを完了します。

6. アクセス・サーバーとWebGateの関連を示すページが表示されます。リンクをクリックしてサマリーを表示し、後で使用するためにこのページを印刷します。

7. 手順3から6を繰り返し、WebGateに定義したすべてのアクセス・サーバーを関連付けます。

15.5.3.9 委任フォーム認証の構成

OAMインストールとともにインストールしたWebGateにリダイレクトするようにフォーム認証を構成する手順は次のとおりです。

1. 「アクセス・システム・コンソール」を開きます。

2. 「アクセス・システム構成」画面で、左側のバーから「認証管理」を選択します。

3. 「OraDefaultFormAuthNScheme」を選択します。

4. 「変更」をクリックします。

5. 「チャレンジ・リダイレクト」フィールドで、IDMインストール用のOracle HTTP Serverのホストとポートを入力します(http://sso.example.com:7777など)。

WebGateはIDMのインストール時にすでにインストールされているはずです。詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のWebGateのインストールおよび構成に関する項を参照してください。

15.5.4 WebGateのインストールと構成

Web層を保護するために、各WEBHOSTnマシンにWebGateをインストールします。

WebGateをインストールし構成する手順は次のとおりです。

1. 次のコマンドを使用して、WebGateインストーラ(取得場所の詳細は、第2.5項「インストールするソフトウェア・コンポーネント」を参照)を起動します。

./Oracle_Access_Manager10_1_4_3_0_linux_OHS11g_WebGate –gui

2. 「ようこそ」画面が表示されます。「次へ」をクリックします。

3. 「顧客情報」画面(図15-1)で、Webサーバーを実行しているユーザー名とユーザー・グループを入力します。「次へ」をクリックして続行します。

図15-1 「顧客情報」画面

4. インストール先画面(図15-2)で、WebGateをインストールするディレクトリを指定します。「次へ」をクリックして続行します。

図15-2 インストール先画面

5. インストールのサマリーの画面で「次へ」をクリックします。

6. WebGate構成画面(図15-3)の説明に従って、WebGateに必要なGCCランタイム・ライブラリをダウンロードし、「参照」を使用して、このGCCランタイム・ライブラリのローカル・コンピュータ上の場所を指定します。「次へ」をクリックして続行します。

図15-3 ラインタイム・ライブラリ画面

7. この段階で、インストーラにより必要なアーティファクトが作成されます。作成が完了したら、「次へ」をクリックして続行します。

8. 「トランスポート・セキュリティ・モード」画面(図15-4)で、「オープン・モード: 暗号化なし」を選択し、「次へ」をクリックして続行します。

図15-4 トランスポート・セキュリティ・モード画面

9. WebGate構成画面で、使用するアクセス・サーバーの詳細を入力します。入力する情報は次のとおりです。

- WebGate ID: OAM構成ツールを実行したときの指定のID

- WebGateのパスワード

- アクセス・サーバーID: OAMアクセス・サーバー構成から報告されたID

- アクセス・サーバーのホスト名: OAMアクセス・サーバー構成から報告された名前

- アクセス・サーバーのポート番号: OAMアクセス・サーバー構成から報告された番号

注意:
アクセス・サーバーのID、ホスト名およびポートは、すべて入力が必須の項目です。

これらの詳細は、Oracle Access Manager管理者から取得できます。「次へ」をクリックして続行します。

図15-5 アクセス・サーバー構成画面

10. 「Webサーバーの構成」画面で「はい」をクリックすると、自動的にWebサーバーが更新されます。「次へ」をクリックして続行します。

11. 表示された「Webサーバーの構成」画面で、httpd.confファイルが格納されているディレクトリのフルパスを指定します。このファイルは、次のディレクトリにあります。

ORACLE_BASE/admin/OHS_Instance/config/OHS/OHS_ComponentName

例:

ORACLE_BASE/admin/ohs_instance2/config/OHS/ohs2/httpd.conf

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

12. 表示された「Webサーバーの構成」ページに、Webサーバー構成がWebGate向けに変更されたことを示すメッセージが示されます。「はい」をクリックして確認します。

13. Webサーバーをいったん停止してから再起動し、構成の更新を有効にします。「次へ」をクリックして続行します。

14. 次の「Webサーバーの構成」ページに、次のメッセージが表示されます。
WebサーバーがSSLモードで設定されている場合は、SSL関連のパラメータでhttpd.confファイルを構成する必要があります。SSLの構成を手動で調整するには、表示される説明に従ってください。.

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

15. 表示された「Webサーバーの構成」画面に、製品設定とWebサーバーの構成の残りの部分に関する情報が記載されているドキュメントの場所を示すメッセージが表示されます。「いいえ」を選択し、「次へ」をクリックして続行します。

16. 最後の「Webサーバーの構成」画面が表示されます。Webサーバーの構成に関する詳細情報を得るには、手動でブラウザを起動し、該当のHTMLドキュメントを開くように指示するメッセージが表示されます。「次へ」をクリックして続行します。

17. 「Oracle COREid Readme」画面が表示されます。画面の情報を確認し、「次へ」をクリックして続行します。

18. 正常にインストールが完了したことを示すメッセージが、インストールの詳細とともに表示されます。

15.5.5 WebgateのIP検証の構成

IP検証により、クライアントのIPアドレスが、シングル・サインオン用に生成されてObSSOCookieに格納されたIPアドレスと同じかどうかが判定されます。IPターミネーションを実行するように構成されたロード・バランサ・デバイスを使用しているシステムにおいては、また認証するWebGateのフロントエンドのロード・バランサがエンタープライズ・デプロイメントのフロントエンドのロード・バランサと異なる場合は、IP検証で問題が発生することがあります。

このような場合に検証が行われないようにロード・バランサを構成する手順は次のとおりです。

1. 次のURLを使用して、アクセス・システム・コンソールに移動します。

http://host_name:port/access/oblix

host_nameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。

3. 「アクセス・システム・コンソール」メイン・ページで、「アクセス・システム構成」をクリックし、左ペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

4. 適切な検索条件を入力して、「実行」をクリックし、アクセス・ゲートのリストを表示します。

5. Oracle Access Manager構成ツールで作成したアクセス・ゲートを選択します。

6. ページの一番下にある「変更」をクリックします。

7. 「IPValidationException」フィールドに、デプロイメントのフロントエンドに位置するロード・バランサのアドレスを入力します。

8. ページの一番下にある「保存」をクリックします。

15.5.6 WebLogicオーセンティケータの設定

この項では、WebLogicオーセンティケータの設定方法を説明します。

前提条件

LDAPオーセンティケータをまだ作成していない場合は、この項の作業を進める前に作成しておいてください。LDAPオーセンティケータを設定するには、第15.2.1項「LDAPオーセンティケータの作成」の手順を実行します。

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

- 第15.5.6.1項「構成ファイルのバックアップ」

- 第15.5.6.2項「OAM IDアサータの設定」

- 第15.5.6.3項「プロバイダの順序の設定」

15.5.6.1 構成ファイルのバックアップ

安全を期して、まず該当の構成ファイル(WebCenter Portalの管理サーバー・ディレクトリ下に格納)をバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/system-jazn-data.xml

管理サーバーのboot.propertiesファイルもバックアップします。

15.5.6.2 OAM IDアサータの設定

WebLogic Server管理コンソールを使用し、OAM IDアサータを構成します。

OAM IDアサータを設定するには:

1. WebLogic Serverの管理コンソールに管理者としてログインします。

2. 次の場所に移動します。

SecurityRealms\Default_Realm_Name\Providers

3. 「新規」をクリックし、ドロップダウン・メニューからOAMアイデンティティ・アサータを選択します。

4. アサータの名前(OAM ID Asserterなど)を入力し、「保存」をクリックします。

5. 新しく追加したアサータをクリックし、OAMアイデンティティ・アサータの構成画面を確認します。

6. 「制御フラグ」を「REQUIRED」に設定して、「保存」をクリックします。

7. 「選択したタイプ」にOAM_REMOTE_USERおよびObSSOCookieが設定されていることを確認します。

8. 設定を保存します。

15.5.6.3 プロバイダの順序の設定

プロバイダの順序を設定する手順は次のとおりです。

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

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

3. 「セキュリティ・レルム」→デフォルト・レルム名→「プロバイダ」に移動し、「並替え」をクリックします。

4. OAMアイデンティティ・アサータ、OID/OVDオーセンティケータおよびデフォルト・オーセンティケータの制御フラグが次のように設定されていることを確認し、これらのオーセンティケータを並べ替えます。

- OAMアイデンティティ・アサータ: REQUIRED

- OID LDAPオーセンティケータ(またはOVD LDAPオーセンティケータ): SUFFICIENT

- デフォルト・オーセンティケータ: SUFFICIENT

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

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

7. 管理サーバーとすべての管理対象サーバーを再起動します。

15.5.7 OAM 10gでの仮想ホストの構成

仮想ホスト用にOAM 10gを構成するには、基本的な認証のみをサポートする、またはシングル・サインオンを必要としないアプリケーション(WebCenter PortalのSharePointサーブレットなど)に対して、シングル・サインオンをバイパスする必要があります。

注意:
『Oracle WebCenter Portalの管理』の仮想ホストでのSSOの構成に関する項および10g用のOracle Access Managerアクセス管理ガイドのWebgate for Apacheと仮想ホスト、ディレクトリまたはファイルの関連付けに関する項も参照してください。

OAM 10gで仮想ホストを構成するには:

1. httpd.confから次の構成を見つけ、コメント・アウトします。

#<LocationMatch "/*">
#AuthType Oblix
#require valid-user
#</LocationMatch>

このエントリによって、WebGateはすべての要求をインターセプトし、処理するようになります。

ヒント: httpd.confはORACLE_BASE/admin/instance_name/config/OHS/component_nameにあります。

2. 次の仮想ホスト構成ファイルを見つけて変更します。

- wcp_vh.conf

- wcpinternal_vh.conf

- admin_vh.conf:

ヒント: これらの.confファイルはORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf/にあります。

1. wcp_vh.confで次のセクションを変更します。
<VirtualHost *:7777>

ServerName https://wcp.example.com:443

ServerAdmin you@your.address

RewriteEngine On

RewriteOptions inherit

...

</VirtualHost>

次にハイライトしたセクションと一致するようにエントリを変更します。

<VirtualHost *:7777>

ServerName https://wcp.example.com:443

<LocationMatch "/*">

AuthType Oblix

require valid-user

</LocationMatch>

...

</VirtualHost>

2. wcpinternal_vh.confで次のセクションを変更します。
<VirtualHost *:7777>

ServerName wcpinternal.example.com:80

ServerAdmin you@your.address

RewriteEngine On

RewriteOptions inherit

...

</VirtualHost>

次にハイライトしたセクションと一致するようにエントリを変更します。

<VirtualHost *:7777>

ServerName wcpinternal.example.com:80

<LocationMatch "/*">

AuthType Oblix

require valid-user

</LocationMatch>

...

</VirtualHost>

3. admin_vh.confで次のセクションを変更します。
<VirtualHost *:7777>

ServerName admin.example.com:80

ServerAdmin you@your.address

RewriteEngine On

RewriteOptions inherit

...

</VirtualHost>

次にハイライトしたセクションと一致するようにエントリを変更します。

<VirtualHost *:7777>

ServerName admin.example.com:80

<LocationMatch "/*">

AuthType Oblix

require valid-user

</LocationMatch>

...

</VirtualHost>

3. Oracle HTTP Serverを再起動します。

15.6 Oracle Access Manager 11gの統合

この項では、Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのシングル・サインオン・ソリューションとしてOracle Access Manager 11gを設定する方法について説明します。

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

- 第15.6.1項「Oracle Access Manager 11gの統合の概要」

- 第15.6.2項「Oracle Access Manager 11gの前提条件」

- 第15.6.3項「WebGateの設定」

- 第15.6.4項「WebGateエージェントの登録」

- 第15.6.5項「WebLogicオーセンティケータのセットアップ」

- 第15.6.6項「OAM 11gでの仮想ホストの構成」

15.6.1 Oracle Access Manager 11gの統合の概要

Oracle Access Manager (OAM)は、Oracle Fusion Middleware 11g リリース1において推奨されるシングル・サインオン・ソリューションです。OAMのインストールおよび構成の詳細は、Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイドを参照してください。この項では、WebCenter Portalのインストールを構成して既存のOAM 11gインストールおよび基礎となるディレクトリ・サービスと連携させる手順について説明します。これらのディレクトリ・サービスには、Oracle Internet Directory (OID)またはOracle Virtual Directory (OVD)、またはその両方を使用することをお薦めします。

注意:
このマニュアルで説明するWebCenter Portalトポロジでは、WebCenter Portalシステムとシングル・サインオン・システムの両方が同じネットワーク・ドメイン(example.com)にある、シングル・サインオン構成を使用します。マルチ・ドメイン構成については、Oracle Access Managerアクセス管理ガイドのOAMポリシー・モデル、シングル・サインオンの概要に関する項に記載されている、必須の構成手順を参照してください。

15.6.2 Oracle Access Manager 11gの前提条件

Oracle Access Manager (OAM)は、Oracle Fusion Middleware 11g リリース1において推奨されるシングル・サインオン・ソリューションです。OAMのインストールおよび構成の詳細は、Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイドを参照してください。この項では、WebCenter Portalのインストールを既存のOAM 11gインストールおよび基礎となるディレクトリ・サービスと構成する手順について説明します。これらのディレクトリ・サービスには、Oracle Internet Directory (OID)またはOracle Virtual Directory (OVD)、またはその両方を使用することをお薦めします。

また、Oracle Access Managerインストールには、Webゲートを使用するように構成された独自のWebサーバーが必要です。この項では、Oracle Access Manager Webサーバーを委任認証サーバーとして使用するための手順も説明します。

15.6.3 WebGateの設定

この項では、HTTPサーバーがすでにインストールされている各WEBHOSTマシンにWebGateをインストールする方法を説明します。

- GCCライブラリのインストール

- WebGateのインストール

- インストール後の手順

15.6.3.1 GCCライブラリのインストール

WebGateをインストールする前に、マシンにサード・パーティ製GCCライブラリをダウンロードおよびインストールする必要があります。次のサードパーティWebサイトから該当するGCCライブラリをダウンロードできます。

http://gcc.gnu.org/

32ビットのLinuxの場合、必要なライブラリはバージョン3.3.2のlibgcc_s.so.1およびlibstdc++.so.5です。表15-3は、LinuxおよびSolarisのGCCサード・パーティ製ライブラリのバージョンを示しています。

表15-3 LinuxおよびSolarisのGCCサードパーティ製ライブラリのバージョン

オペレーティング・システム

アーキテクチャ

GCCライブラリ

必要なライブラリ・バージョン

Linux 32ビット

x86

libgcc_s.so.1

libstdc++.so.5

3.3.2

Linux 64ビット

x64

libgcc_s.so.1

libstdc++.so.6

3.4.6

Solaris 64ビット

SPARC

libgcc_s.so.1

libstdc++.so.5

3.3.2

15.6.3.2 WebGateのインストール

この項では、WebGateのインストール手順について説明します。

Oracle HTTP Server 11g Webgate for Oracle Access Managerのインストーラ・プログラムはwebgate.zipファイルに含まれています。

WebGateをインストールする手順は次のとおりです。

1. webgate.zipファイルのコンテンツを、ディレクトリに解凍します。
デフォルトでは、このディレクトリはwebgateと名前が付けられています。

2. webgateディレクトリの下のDisk1ディレクトリに移動します。

3. MW_HOME環境変数をWeb層のミドルウェア・ホームに設定します。

export MW_HOME=ORACLE_BASE/product/fmw/web

4. 次のコマンドを使用してインストーラを起動します。

$ ./runInstaller -jreLoc MW_HOME/jdk

注意:
Oracle HTTP Serverをインストールするときに、WebTier_Homeディレクトリの下にjdkディレクトリが作成されます。インストーラを起動するときに、このJDKの中にあるJREフォルダの絶対パスを入力する必要があります。

インストーラが起動すると、「ようこそ」画面が表示されます。

5. 「ようこそ」画面で「次へ」をクリックします。

6. 「前提条件のチェック」画面で、「次へ」をクリックします。

7. 「インストール場所の指定」画面で、Oracleミドルウェア・ホームとOracleホームの場所を指定します。

- ORACLE_BASE/product/fmw

- Oracle_OAMWebGate1 (デフォルト名のまま)

注意:
ミドルウェア・ホームには、Oracle Web層のOracleホームが含まれます。このOracleホーム・ディレクトリのデフォルト名はOracle_OAMWebGate1で、これはミドルウェア・ホームの下に作成されます。

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

8. 「インストール・サマリー」画面で情報を確認し、「インストール」をクリックしてインストールを開始します。

9. 「インストールの進行状況」画面で、ファイルおよびディレクトリに対して正しい権限を設定するために、ORACLE_HOME/oracleRoot.shスクリプトの実行を求められる場合があります。
「次へ」をクリックして続行します。

10. 「インストール完了」画面で、「終了」をクリックし、インストーラを終了します。

15.6.3.3 インストール後の手順

Oracle HTTP Server 11g Webgate for Oracle Access Managerのインストール後に次の手順を実行します。

1. WebgateのOracleホームの下にある次のディレクトリに移動します。

$ cd Webgate_Oracle_Home/webgate/ohs/tools/deployWebGate

Webgate_Oracle_Homeは、次の例のように、Oracle HTTP Server Webgateをインストールし、WebgateのOracleホームとして作成したディレクトリです。

MW_HOME/Oracle_OAMWebGate1

2. コマンド行で次のコマンドを実行し、Webgate_Oracle_HomeディレクトリからWebgateインスタンスの場所に必要なエージェント・ビットをコピーします。

$ ./deployWebGateInstance.sh -w ORACLE_BASE/admin/webN/config/OHS/ohsN
-oh Webgate_Oracle_Home

ORACLE_BASE/admin/webN/config/OHS/ohsNディレクトリは、Oracle HTTP Serverのインスタンス・ホームになります(Nはインストールごとに付される連番で、1番目はWEBHOST1、2番目はWEBHOST2などとなります)。

注意:
Oracle HTTP Serverのインスタンス・ホームは、Oracle HTTP Serverを構成した後に作成されます。

3. 次のコマンドを実行し、LD_LIBRARY_PATH変数にOracle_Home_for_Oracle_HTTP_Server/libが含まれるようにします。

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:ORACLE_BASE/product/fmw/web/lib

注意:
Oracle_Home_for_Oracle_HTTP_ServerはMW_HOME (Web層)です。
ORACLE_BASE/product/fmw/web

4. 現在の作業ディレクトリから1つ上のディレクトリに移動します。

$ cd Webgate_Oracle_Home/webgate/ohs/tools/setup/InstallTools

5. コマンド行で次のコマンドを実行して、Webgate_Oracle_HomeディレクトリからWebgateインスタンスの場所にapache_webgate.templateをコピーし(名前がwebgate.confに変更されます)、httpd.confファイルを更新してwebgate.confの名前が含まれる1つの行を追加します。

$ ./EditHttpConf -w ORACLE_BASE/admin/webN/config/OHS/ohsN [-oh Webgate_Oracle_Home] [-o output_file]

注意:
-oh WebGate_Oracle_Homeおよび-o output_fileパラメータはオプションです。

ここでWebGate_Oracle_Homeは、Oracle HTTP Server Webgate for Oracle Access Managerをインストールし、WebgateのOracleホームを作成したディレクトリです。次に例を示します。

MW_HOME/Oracle_OAMWebGate1

ORACLE_BASE/admin/webN/config/OHS/ohsNディレクトリは、Oracle HTTP Serverのインスタンス・ホームになります(Nはインストールごとに付される連番で、1番目はWEBHOST1、2番目はWEBHOST2などとなります)。

output_fileはツールによって使用される一時出力ファイルの名前です。次に例を示します。

Edithttpconf.log

15.6.4 WebGateエージェントの登録

この項では、WebGateエージェントの登録手順について説明します。

- RREGツール

- OAM11gRequestファイルの更新

- oamregツールの実行

- WEBHOSTへのアクセス・ファイルのコピー

- RESTポリシーの更新

15.6.4.1 RREGツール

RREGツールはOAM 11gのインストールの一部です。見つからない場合は、次の手順を使用して抽出します。

1. Oracle Access Managerのインストールおよび構成が終わった後、次の場所に移動します。

IDM_Home/oam/server/rreg/client

2. コマンド行から、次の例のとおり、gunzipを使用してRREG.tar.gzファイルを解凍します。

gunzip RREG.tar.gz

tar -xvf RREG.tar

3. RREG_HOME/binディレクトリにあるoamreg.shスクリプトを編集し、設定に応じてOAM_REG_HOMEパラメータを変更します。

OAM_REG_HOME=RREG_Home

(RREG_Homeは、RREG.tar.gzおよびrregの内容を展開したディレクトリです。)

スクリプト・ファイルを保存します。

RREG構成ツールは、保護されているリソース、パブリック・リソースおよび除外されたリソースをOAMシステムに登録する手段を提供します。例15-3に示すように、OAMシステムに追加されるリソースのリストはOAM11gRequest.xmlに指定されています。

15.6.4.2 OAM11gRequestファイルの更新

RREG_Home/inputディレクトリの中に、OAM11gRequest.xmlという名前のテンプレート・ファイルがあります。このファイルをコピーおよび編集して、WebCenter Portalインストールのポリシーを作成します。

1. RREG_Home/inputにあるテンプレートOAM11gRequest.xmlファイルを開きます。

2. 例15-3に示す、WebCenter Portalエンタープライズ・デプロイメントに必要なポリシーをコピーします。

3. 次の値を置き換えます。

- $$webtierhost$$、$$oamadminserverport$$および$$oamhost$$を、実際のインストールのホスト名に置換します。

- ipvalidationExceptions値をロード・バランサのIPアドレスにします。

注意:
このガイドでは、Oracle Access Manager 11g (11.1.1.2)以降のリクエスト・ファイルの検証フィールドのエントリについて説明します。以前のバージョンのOracle Access Manager 11gでは、検証例外リストの定義方法が異なります。以前のバージョンでは、前のテキストに示されているように<ValList>エントリを使用するかわりに、</publicResourcesList>エントリの後で次の構文を使用します。

<userDefinedParameters>
<userDefinedParam>
<name>ipValidationExceptions</name>
<value>10.1.1.1</value>
</userDefinedParam>
</userDefinedParameters>

IP検証例外の追加の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

4. 変更を保存します。

5. oamreg.shスクリプトの実行権限を追加します。

chmod u+x /RREG_Home/bin/oamreg.sh

例15-3 WebCenter Portalエンタープライズ・デプロイメント用のOAM11gRequest.xml

OAM11gRequest.xmlの編集後、ファイルには次が含まれている必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
NAME: OAM11GRequest_short.xml - Template for OAM 11G Agent Registration request file
(Shorter version - Only mandatory values - Default values will be used for all other fields)
DESCRIPTION: Modify with specific values and pass file as input to the tool.
-->
<OAM11GRegRequest>
<serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress>
<hostIdentifier>$$webtierhost$$_webcenter</hostIdentifier>
<agentName>$$webtierhost$$_webcenter</agentName>
<applicationDomain>$$webtierhost$$_webcenter</applicationDomain>
<ipValidation>1</ipValidation>
<ValList ListName="ipValidationExceptions">
<ValListMember Value="10.1.1.1"/>
<logOutUrls>
<url>/oamsso/logout.html</url>
</logOutUrls>
<protectedResourcesList>
<resource>/webcenter/adfAuthentication</resource>
<resource>/integration/worklistapp</resource>
<resource>/integration/worklistapp/.../*</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow</resource>
<resource>/workflow/WebCenterWorklistDetail/faces/adf.task-flow</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist/.../*</resource>
<resource>/sdpmessaging/userprefs-ui</resource>
<resource>/sdpmessaging/userprefs-ui/.../*</resource>
<resource>/rss/rssservlet</resource>
<resource>/owc_discussions/login!withRedirect.jspa</resource>
<resource>/owc_discussions/login!default.jspa</resource>
<resource>/owc_discussions/login.jspa</resource>
<resource>/owc_discussions/admin</resource>
<resource>/owc_discussions/admin/.../*</resource>
<resource>/rest/api/resourceIndex</resource>
<resource>/rest/api/spaces</resource>
<resource>/rest/api/spaces/.../*</resource>
<resource>/rest/api/discussions</resource>
<resource>/rest/api/discussions/.../*</resource>
<resource>/rest/api/tags</resource>
<resource>/rest/api/tags/.../*</resource>
<resource>/rest/api/taggeditems</resource>
<resource>/rest/api/taggeditems/.../*</resource>
<resource>/rest/api/activities</resource>
<resource>/rest/api/activities/.../*</resource>
<resource>/rest/api/activitygraph</resource>
<resource>/rest/api/activitygraph/.../*</resource>
<resource>/rest/api/feedback</resource>
<resource>/rest/api/feedback/.../*</resource>
<resource>/rest/api/people</resource>
<resource>/rest/api/people/.../*</resource>
<resource>/rest/api/messageBoards</resource>
<resource>/rest/api/messageBoards/.../*</resource>
<resource>/rest/api/searchresults</resource>
<resource>/rest/api/searchresults/.../*</resource>
<resource>/activitygraph-engines</resource>
<resource>/activitygraph-engines/.../*</resource>
<resource>/wcps/api</resource>
<resource>/wcps/api/.../*</resource>
<resource>/adfAuthentication</resource>
<resource>/pagelets/admin</resource>
<resource>/pagelets/admin/.../*</resource>
<resource>/pagelets/authenticateWithApplicationServer</resource>
<resource>/services-producer/adfAuthentication</resource>
<resource>/em</resource>
<resource>/em/.../*</resource>
<resource>/console</resource>
<resource>/console/.../*</resource>
<resource>/soa/composer</resource>
<resource>/soa/composer/.../*</resource>
<resource>/soa-infra</resource>
<resource>/soa-infra/deployer</resource>
<resource>/soa-infra/deployer/.../*</resource>
<resource>/soa-infra/events/edn-db-log</resource>
<resource>/soa-infra/events/edn-db-log/.../*</resource>
<resource>/soa-infra/cluster/info</resource>
<resource>/soa-infra/cluster/info/.../*</resource>
<resource>/inspection.wsil</resource>
<resource>/cs/idcplg</resource>
<resource>/cs/idcplg/.../*</resource>
<resource>/cs/groups</resource>
<resource>/cs/groups/.../*</resource>
<resource>/ibr/adfAuthentication</resource>
<resource>/ibr/adfAuthentication/.../*</resource>
</protectedResourcesList>
<publicResourcesList>
<resource>/webcenter</resource>
<resource>/webcenter/.../*</resource>
<resource>/webcenterhelp</resource>
<resource>/webcenterhelp/.../*</resource>
<resource>/owc_discussions</resource>
<resource>/owc_discussions/.../*</resource>
<resource>/rss</resource>
<resource>/rss/.../*</resource>
<resource>/workflow</resource>
<resource>/workflow/.../*</resource>
<resource>/rest/api/cmis/.../*</resource>
<resource>/pagelets</resource>
<resource>/services-producer</resource>
<resource>/wsrp-tools</resource>
<resource>/cs</resource>
<resource>/cs/.../*</resource>
<resource>/ibr</resource>
<resource>/ibr/.../*</resource>
<resource>/soa-infra/directWSDL</resource>
<resource>/integration/services</resource>
<resource>/integration/services/.../*</resource>
</publicResourcesList>
<excludedResourcesList>
<resource>/rsscrawl*</resource>
<resource>/rsscrawl/.../*</resource>
<resource>/sesUserAuth*</resource>
<resource>/sesUserAuth/.../*</resource>
<resource>/services-producer/portlets*</resource>
<resource>/services-producer/portlets/.../*</resource>
<resource>/soa-infra/services/.../*</resource>
<resource>/wsrp-tools/portlets*</resource>
<resource>/wsrp-tools/portlets/.../*</resource>
<resource>/wsm-pm</resource>
<resource>/wsm-pm/.../*</resource>
<resource>/ucs/messaging/webservice</resource>
<resource>/ucs/messaging/webservice/.../*</resource>
</excludedResourcesList>

</OAM11GRegRequest>

注意:
WebCenter Portal、SOAおよびWebCenter Contentにはそれぞれ、公開および保護されたURIの要件がリストされた.confファイルがあります。次のprotected_uris=とpublic_uris=の構文を使用して、公開および保護URIを指定するかわりに、構文uris_file=を使用して各ファイルを順に参照できます。詳細および手順は、『Oracle WebCenter Portalの管理』のWebCenter Portalのポリシー・ドメインの構成に関する項を参照してください。

15.6.4.3 oamregツールの実行

1. 次のコマンドを使用し、oamregツールを実行します。

$ ./RREG_Home/bin/oamreg.sh inband input/WebCenterOAM11GRequest.xml

2. エージェントの資格証明が求められたら、自身のOAM管理者資格証明を入力します。
実行時の出力は次のようになります。

------------------------------------------------
Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: MW_HOME/Oracle_IDM1/oam/server/rreg/input/WebCenterOAM11gRequest.xml
Enter your agent username:weblogic
Username: weblogic
Enter agent password:
Do you want to enter a Webgate password?(y/n):
y
Enter webgate password:
Enter webgate password again:
Password accepted. Proceeding to register..
Aug 16, 2010 1:22:30 AM oracle.security.am.engines.rreg.client.handlers.request.OAM11GRequestHandler getWebgatePassword
INFO: Passwords matched and accepted.
Do you want to import an URIs file?(y/n):
n
----------------------------------------
Request summary:
OAM11G Agent Name:WEBHOST1_webcenter
URL String:WEBHOST1_webcenter
Registering in Mode:inband
Your registration request is being been sent to the Admin server at: http://oamserver.example.com:7001
----------------------------------------
Inband registration process completed successfully! Output artifacts are created in the output folder.

15.6.4.4 WEBHOSTへのアクセス・ファイルのコピー

次のファイルがRREG_Home/output/$$webtierhost$$_webcenterに生成されます。

- ObAccessClient.xml

- cwallet.sso

- password.xml

- aaa_cert.pem

- aaa_key.pem

これらのファイルをWEBHOST1およびWEBHOST2上のWebGateインスタンスの場所に適宜コピーする手順:

1. ObAccessClient.xml、cwallet.ssoおよびpassword.xmlをWEBHOST1とWEBHOST2上のWebGateインスタンス・ディレクトリにコピーします。
例:

scp ObAccessClient.xml oracle@WEBHOSTN:ORACLE_BASE/admin/webN/config/OHS/ohsN/webgate/config/
scp cwallet.sso oracle@WEBHOSTN:ORACLE_BASE/admin/webN/config/OHS/ohsN/webgate/config/
scp password.xml oracle@WEBHOSTN:ORACLE_BASE/admin/webN/config/OHS/ohsN/webgate/config/

ここでNは、WEBHOST1には1、WEBHOST2には2などインストール上の連番を示します。

2. SIMPLEモードの証明書ファイル(aaa_cert.pemおよびaaa_key.pem)を、WebGateインスタンス・ディレクトリのsimpleサブフォルダにコピーします。
例:

scp aaa_cert.pem oracle@WEBHOSTN:ORACLE_BASE/admin/webN/config/OHS/ohsN/webgate/config/simple/
scp aaa_key.pem oracle@WEBHOSTN:ORACLE_BASE/admin/webN/config/OHS/ohsN/webgate/config/simple/

このコマンドでは、Nは、WEBHOST1には1、WEBHOST2には2などインストール上の連番を示します。

3. Oracle HTTP Serverを再起動します。

15.6.4.5 RESTポリシーの更新

OutlookプラグインやiPhoneアプリケーションなどの外部クライアントが、SSOで保護されているWebCenter RESTに接続することができるよう、RESTはBASIC認証スキームに従う必要があります。

基本の認証を使用するようにRESTエンド・ポイントを構成するには、次の手順を実行します。

1. http://OAM_HOST:OAM_ADMINSERVER_PORT/oamconsoleにあるOracle Access Managerコンソールにログインします。

2. 前の手順で作成および検証したポリシー・ドメインを見つけ、「ポリシー」タブを開きます。

3. 「アプリケーション・ドメイン」→「$$webtierhost$$_webcenter」→「認証ポリシー」に移動します。

4. 「WebCenter REST Auth Policy」という新しいポリシーを作成し、基本スキームとして「認証スキーム」を選択し、「適用」をクリックします。

5. 「アプリケーション・ドメイン」→「$$webtierhost$$_webcenter」→「リソース」に移動します。

6. すべてのRESTリソースを検索します。/rest*と「リソースURL」フィールドに入力し、「検索」をクリックします。

7. /rest/api/cmisエントリを除く各RESTリソースを編集し、「認証ポリシー」を「保護されたリソース・ポリシー」から「WebCenter REST認証ポリシー」に変更します。

図15-6 基本認証を使用したRESTエンド・ポイントの構成

次のエントリを確認できます。

/rest/api/resourceIndex
/rest/api/resourceIndex/.../*
/rest/api/spaces
/rest/api/spaces/.../*
/rest/api/discussions
/rest/api/discussions/.../*
/rest/api/tags
/rest/api/tags/.../*
/rest/api/taggeditems
/rest/api/taggeditems/.../*
/rest/api/activities
/rest/api/activities/.../*
/rest/api/activitygraph
/rest/api/activitygraph/.../*
/rest/api/feedback
/rest/api/feedback/.../*
/rest/api/people
/rest/api/people/.../*
/rest/api/messageBoards
/rest/api/messageBoards/.../*
/rest/api/searchresults
/rest/api/searchresults/.../*

15.6.5 WebLogicオーセンティケータの設定

構成ファイルのバックアップ、OAM IDアサータの設定およびプロバイダの順序設定によって、WebLogicオーセンティケータを設定します。

前提条件

WebLogicのオーセンティケータを設定する前に、第15.2.1項「LDAPオーセンティケータの作成」の手順に従ってLDAPオーセンティケータをすでに設定している必要があります。まだLDAPオーセンティケータを作成していない場合は、それを作成してからこの項の続きを実行してください。

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

- 第15.6.5.1項「構成ファイルのバックアップ」

- 第15.6.5.2項「OAM IDアサータの設定」

- 第15.6.5.3項「プロバイダの順序の設定」

15.6.5.1 構成ファイルのバックアップ

安全を期して、まず該当の構成ファイル(WebCenter Portalの管理サーバー・ディレクトリ下に格納)をバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fwmconfig/system-jazn-data.xml

また、管理サーバーのboot.propertiesファイルもバックアップします。

15.6.5.2 OAM IDアサータの設定

OAM IDアサータを設定するには:

1. Oracle WebLogicコンソールの管理者としてログインします。

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

3. 「SecurityRealms」→「デフォルト・レルム名」→「プロバイダ」に移動します。

4. 「新規」をクリックし、ドロップダウン・メニューから「OAMアイデンティティ・アサータ」を選択します。

5. アサータに名前(OAM ID Asserterなど)を付け、「OK」をクリックします。

6. 新しく追加したアサータをクリックし、OAMアイデンティティ・アサータの構成画面を確認します。

7. 制御フラグを「必須」に設定します。

8. 「選択済み」タイプで「ObSSOCookie」および「OAM_REMOTE_USER」の2つのオプションを選択します。

9. 設定を保存します。

10. 「変更の適用」をクリックします。

11. 最後に、WLSTを使用しWebLogic Serverドメインに接続し、次のコマンドを実行してOAM SSOプロバイダを追加します。

addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", logouturi="/oamsso/logout.html")

15.6.5.3 プロバイダの順序の設定

WebLogic管理コンソールを使用してプロバイダの順序を設定します。

プロバイダの順序を設定する手順は次のとおりです。

1. Oracle WebLogicコンソールの管理者としてログインします。

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

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. OAMアイデンティティ・アサータ、OID/OVDオーセンティケータおよびデフォルト・オーセンティケータの制御フラグが次のように設定されていることを確認し、これらのオーセンティケータを並べ替えます。

- OAMアイデンティティ・アサータ: REQUIRED

- OID LDAPオーセンティケータ(またはOVD LDAPオーセンティケータ): SUFFICIENT

- デフォルト・オーセンティケータ: SUFFICIENT

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

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

7. 管理サーバーとすべての管理対象サーバーを再起動します。

15.6.6 OAM 11gでの仮想ホストの構成

仮想ホスト用にOAM 11gを構成するには、基本的な認証のみをサポートする、またはシングル・サインオンを必要としないアプリケーション(WebCenter PortalのSharePointサーブレットなど)に対して、シングル・サインオンをバイパスする必要があります。

OAM 11gで仮想ホストを構成する手順:

1. 次の仮想ホスト構成ファイルを見つけて変更します。

- wcp_vh.conf

- wcpinternal_vh.conf

- admin_vh.conf:

ヒント: これらの.confファイルはORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf/にあります。

1. wcp_vh.confで次のセクションを変更します。
<VirtualHost *:7777>

ServerName https://wcp.example.com:443

ServerAdmin you@your.address

RewriteEngine On

RewriteOptions inherit

<Location ...

...

</Location>

</VirtualHost>

次にハイライトしたセクションと一致するようにこのセクションを変更します。

<VirtualHost *:7777>

ServerName https://wcp.example.com:443

<LocationMatch "/*">

AuthType Oblix

require valid-user

</LocationMatch>

<Location ...

...

</Location>

</VirtualHost>

2. wcpinternal_vh.confで次のセクションを変更します。
<VirtualHost *:7777>

ServerName wcpinternal.example.com:80

ServerAdmin you@your.address

RewriteEngine On

RewriteOptions inherit

...

</VirtualHost>

次にハイライトしたセクションと一致するようにこのセクションを変更します。

<VirtualHost *:7777>

ServerName wcpinternal.example.com:80

<LocationMatch "/*">

AuthType Oblix

require valid-user

</LocationMatch>

...

</VirtualHost>

3. admin_vh.confで次のセクションを変更します。
<VirtualHost *:7777>

ServerName admin.example.com:80

ServerAdmin you@your.address

RewriteEngine On

RewriteOptions inherit

...

</VirtualHost>

次にハイライトしたセクションと一致するようにこのセクションを変更します。

<VirtualHost *:7777>

ServerName admin.example.com:80

<LocationMatch "/*">

AuthType Oblix

require valid-user

</LocationMatch>

RewriteEngine On

RewriteOptions inherit

RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end_url=/console"

...

</VirtualHost>

2. Oracle HTTP Serverを再起動します。

15.7 SSO用のWebCenter Portalアプリケーションの構成

この項の内容は次のとおりです。

- 第15.7.1項「WebCenter Portal用のシステム・プロパティの構成」

- 第15.7.2項「WebCenter Portalの管理者ロールの構成」

- 第15.7.3項「ディスカッション・サーバーでSSOプロバイダとしてOAMを使用するための設定」

15.7.1 WebCenter Portal用のシステム・プロパティの構成

EXTRA_JAVA_PROPERTIESに設定を追加し、SSO用にWebCenter Portalアプリケーションを構成します。

システム・プロパティoracle.webcenter.spaces.ossoにより、アプリケーションがSSOモードで構成されているために特殊な処理が必要であることをWebCenter PortalとADFは通知されます。次のシステム・プロパティが必要です。

表15-4 システム・プロパティ

プロパティ

値

コメント

oracle.webcenter.spaces.osso

true

このフラグは、SSOが使用されているためにデフォルトのランディング・ページにログイン・フォームが表示されないことをWebCenter Portalに通知します。かわりに、ユーザーがクリックするとSSO認証が起動するログイン・リンクが表示されます。

WCPHOST1およびWCPHOST2でWebCenter Portalアプリケーション用にこのプロパティを設定するには、managedserver_domain_home/binディレクトリにあるsetDomainEnv.shスクリプトを編集します。次のように、このプロパティをEXTRA_JAVA_PROPERTIES変数に追加します。

EXTRA_JAVA_PROPERTIES="-Doracle.webcenter.spaces.osso=true ${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES

15.7.2 WebCenter Portalの管理者ロールの構成

Oracle Internet DirectoryまたはOracle Virtual DirectoryをWebCenter Portalアプリケーションのプライマリ・オーセンティケータに構成したら、デフォルトのweblogicユーザーはWebCenter Portal管理者として使用しないようにする必要があります。Oracle Internet Directoryにユーザーを作成し、WLSTまたはEnterprise Managerを使用して、そのユーザーをWebCenter Portal管理者にします。

- 第15.7.2.1項「WLSTを使用したWebCenter Portal管理者ロールの付与」

- 第15.7.2.2項「Fusion Middleware Controlを使用したWebCenter Portal管理者ロールの付与」

15.7.2.1 WLSTを使用したWebCenter Portal管理者ロールの付与

WLSTを使用してWebCenter Portalの管理者ロールを付与する手順は、次のとおりです。

1. LDAPストアにWCAdminという名前のユーザーを作成します。
このユーザーは、WebCenter Portalの管理者ロールに割り当てられます。

ユーザーの作成方法の詳細は、第15.2.2.1項「LDAPディレクトリでの管理ユーザーおよびグループのプロビジョニング」を参照してください。

2. WebCenter Portal Oracleホーム・ディレクトリに移動し、WLSTスクリプトを起動します。
(UNIX) MW_HOME/wc/common/bin/wlst.sh

(Windows) MW_HOME\wc\common\bin\wlst.cmd

3. 次のコマンドを使用し、ターゲット・ドメインの管理サーバーに接続します。

wls:/offline>connect("user_name","password", "host_name:port_number")

4. grantAppRoleコマンドを使用し、LDAPのWCAdminユーザーにWebCenter Portalの管理者アプリケーション・ロールを付与します。
例:

grantAppRole(appStripe="webcenter", appRoleName="s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator",
principalClass="weblogic.security.principal.WLSUserImpl", principalName="WCAdmin")

WCAdminは、手順3で作成した管理者アカウントの名前です。

5. WC_Spacesn管理対象サーバーを再起動します。

6. 新しいアカウントをテストするには、新しいアカウント名を使用してWebCenter Portalにログインします。
ブラウザでhttp://wcp.example.com:/webcenterを使用して、WebCenter Portalを開きます。ログイン後、「管理」リンクが表示されて、すべての管理操作を実行できるようになります。

15.7.2.2 Fusion Middleware Controlを使用したWebCenter Portal管理者ロールの付与

この項では、デフォルトのweblogicアカウント以外のユーザー・アカウントにWebCenter PortalのAdministratorロールを付与する方法を説明します。

Fusion Middleware Controlを使用してWebCenter Portalの管理者ロールを付与する手順は、次のとおりです。

1. Fusion Middleware Controlにログインし、WebCenter Portalのホーム・ページに移動します。

2. 「WebCenter Portal」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。
「アプリケーション・ロール」ページが表示されます。

3. WebCenter Portalの管理者ロールを検索します。

1. 「検索するアプリケーション・ストライプの選択」チェック・ボックスを選択します。

2. 「webcenter」 (WebCenter Portalアプリケーションの名前)を選択します。

3. 「ロール名」フィールドにs8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administratorと入力し、「検索」(矢印)アイコンをクリックします。

4. 「ロール名」列で管理者ロール名(s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator)をクリックします。
「アプリケーション・ロールの編集」ページが表示されます。

5. 「ユーザーの追加」をクリックします。
「ユーザーの追加」ポップアップが表示されます。

6. 検索機能を使用して、Administratorロールを割り当てるユーザーを検索します。

7. 矢印キーを使用して、「使用可能なユーザー」列から「選択したユーザー」列にユーザーを移動し、「OK」をクリックします。

8. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

9. WC_Spacesn管理対象サーバーを再起動します。
WebCenter Portalにログインすると、「管理」リンクが表示されて、すべての管理操作を実行できるようになります。

15.7.3 ディスカッション・サーバーでSSOプロバイダとしてOAMを使用するための設定

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

- 第15.7.3.1項「ディスカッション・サーバーでの管理者権限の付与」

- 第15.7.3.2項「ディスカッション・サーバー用のシステム・プロパティの構成」

- 第15.7.3.3項「ディスカッション・サーバー接続に対する新しい管理ユーザーの指定」

15.7.3.1 ディスカッション・サーバーでの管理者権限の付与

ドメインをAdministratorsグループを含まないアイデンティティ・ストアに関連付ける場合、ディスカッション・サーバー用に他の有効なユーザーまたはグループを割り当てる必要があります。

addDiscussionsServerAdminのWLSTコマンドを使用すると、ユーザーまたはグループにディスカッション・サーバーのシステム管理者権限を付与できます。コマンドの構文と例については、『WebLogic Scripting Toolコマンド・リファレンス』のaddDiscussionsServerAdminに関する項を参照してください。

例:

1. 管理サーバーに接続します。
例:

cd MW_HOME/wc/common/bin/
./wlst.sh

connect("weblogic","mypassword1", "ADMINHOST:7001")

2. ユーザーまたはグループに管理者権限を付与します。

addDiscussionsServerAdmin(appName='owc_discussions', name='weblogic_wc', type='USER', server='WC_Collaboration1')

または、

addDiscussionsServerAdmin(appName='owc_discussions', name='discussions-admin-group', type='GROUP', server='WC_Collaboration1')

ここで、weblogic_wcとdiscussions-admin-groupは、ディスカッション・サーバーに割り当てる管理者ロールのユーザーおよびグループ例です。

コマンドの構文と例については、『WebLogic Scripting Toolコマンド・リファレンス』のaddDiscussionsServerAdminに関する項を参照してください。

15.7.3.2 ディスカッション・サーバー用のシステム・プロパティの構成

Oracle WebCenterディスカッション・サーバーをOAMシングル・サインオン用に構成するには:

1. 次の場所でOracle WebCenterディスカッション・サーバーの管理コンソールにログインします。
http://wcpinternal.example.com/owc_discussions/admin

2. 「システム・プロパティ」ページを開き、「owc_discussions.sso.mode」プロパティを編集(このプロパティがすでに存在する場合)または追加して、その値を「true」に設定します。

3. 次に例を示すように、jiveURLプロパティを編集または追加して、フロントエンド・ロードバランサのディスカッションのベースURLを指定します。

jiveURL = wcp.example.com/owc_discussions

4. WebLogic Server管理コンソールを使用して、両方のコラボレーション管理対象サーバーを再起動します。

15.7.3.3 ディスカッション・サーバー接続に対する新しい管理ユーザーの指定

第12.2項「ディスカッション・サーバー接続の構成」で作成したディスカッション・サーバー接続を確認します。接続に対して指定されている管理ユーザー(weblogic_wcなど)がLDAPで使用可能であり、ディスカッション・サーバーに対する管理者権限を持つことを確認します。

15.8 WebCenter PortalおよびBPEL認証の構成

この項の内容は次のとおりです。

- 第15.8.1項「オーセンティケータの検証」

- 第15.8.2項「soa-infraのBPMWorkflowAdminアプリケーション・ロールのロール・メンバーの設定」

- 第15.8.3項「SOAコールバックURLの構成」

15.8.1 オーセンティケータの検証

SOAドメインでWebCenter Portalドメインと同じオーセンティケータが使用され、OAM認証が構成されていることを検証します。

15.8.2 soa-infraのBPMWorkflowAdminアプリケーション・ロールのロール・メンバーの設定

デフォルト・ユーザーweblogicを含まないアイデンティティ・ストアにドメインを関連付ける場合、他の有効なユーザーをアプリケーション・ロール、BPMWorkflowAdminに割り当てる必要があります。

BPMWorkflowAdminを有効なユーザーに付与する手順は次のとおりです。

1. ロールを割り当てるユーザーをLDAPストア内で選択します。
たとえば、以前作成した管理ユーザーWCAdminなどです。

2. WLSTを使用し、BPMWorkflowAdminロールを割り当てます。この作業は、SOAのOracleホームからWLSTを使用して実行できます。
例:

cd ORACLE_HOME/common/bin/
wlst.sh

connect("weblogic","mypassword1", "ADMINHOST:7001")
revokeAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin",
principalClass="oracle.security.jps.service.policystore.ApplicationRole", principalName="SOAAdmin")
grantAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin",
principalClass="weblogic.security.principal.WLSUserImpl", principalName="WCAdmin")

15.8.3 SOAコールバックURLの構成

Oracle Access Managerが有効なときにワークリストが正常に機能するには、SOAコールバックURLが必ず正しく構成されている必要があります。コールバックURLの詳細は、第9.6.3項「フロントエンドHTTPホストおよびポートの設定」を参照してください。

SOAアプリケーションについては、次のコールバックURLがhttp://wcpinternal.example.comに設定されている必要があります。

- コールバック・サーバーURL

- サーバーURL

Fusion Middleware Controlを使用し、これらのURLを変更するには、次の手順を実行します。

1. 「Farm_wcpedg_domain」→「SOA」→「soa-infra (wls_soa1)」→「SOAインフラストラクチャ」→「SOA管理」→「共通プロパティ」を選択します。

2. 「コールバック・サーバーURL」および「サーバーURL」には、http://wcpinternal.example.comを入力します。

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

4. SOAサーバーを再起動します。

15.9 アイデンティティ管理構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

この時点で構成をバックアップするには:

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl startall

2. データベースのバックアップを取ります。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/ admin/domain_name

管理サーバーをバックアップするには、SOHOST1で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

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

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

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

- トポロジの管理および監視の概要

- SOAインフラストラクチャ・データベースでのスペースの管理

- UMSドライバの構成

- トポロジのスケール・アップ(既存のノードへの管理対象サーバーの追加)

- トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)

- WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行

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

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

- Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング

16.1 トポロジの管理および監視の概要

WebCenter Portalエンタープライズ・デプロイメントを構成したら、この章の情報を使用してトポロジを管理します。

トポロジおよびWebCenter Portalアプリケーションの監視の詳細は、『Oracle WebCenter Portalの管理』のOracle WebCenter Portalのパフォーマンスの監視に関する項を参照してください。

スケール・アップやスケール・アウトなどの方法で、トポロジの拡張が必要になることがあります。スケール・アップとスケール・アウトの違いおよびこれらのタスクの実行方法の詳細は、第16.4項「トポロジのスケール・アップ(管理対象サーバーを既存ノードに追加)」および第16.5項「トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)」を参照してください。

構成の変更前後にはトポロジをバックアップします。構成変更後の問題発生に対応するためバックアップしておく必要のあるディレクトリとファイルについては、第16.6項「WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行」で説明します。

この章では、トポロジの構成後に発生する可能性のある既知の問題の解決方法も示します。

16.2 SOAインフラストラクチャ・データベースでのスペースの管理

すべてのコンポジットでデータベースが頻繁に使用されるわけではありませんが、サービス・エンジンは大量のデータをCUBE_INSTANCEスキーマとMEDIATOR_INSTANCEスキーマで生成します。データベースの領域が不足していると、SOAコンポジットが機能しなくなる可能性があります。

SOAインフラストラクチャ・データベースでスペースを管理する手順は次のとおりです。

- Oracle Enterprise Manager Fusion Middleware Controlコンソール(のダッシュボードなど)で"Oracle.fabric.common.FabricInvocationException"などの汎用エラーがないか確認します。

- SOAサーバーのログで次のようなエラーを検索します。

Error Code: 1691
...
ORA-01691: unable to extend lob segment
SOAINFRA.SYS_LOB0000108469C00017$$ by 128 in tablespace SOAINFRA

これらのメッセージは通常、データベースの領域の問題を示しています。たとえば、既存のファイルにデータ・ファイルまたは領域を追加する必要があるような場合です。SOAデータベース管理者は、領域の追加で使用される拡張ポリシーとパラメータを決定する必要があります。

- 古いコンポジット・インスタンスをパージしてSOAインフラストラクチャ・データベースのサイズを縮小します。このタイプの操作に、Oracle Enterprise Manager Fusion Middleware Controlを使用することはお薦めしません。操作でトランザクション・タイム・アウトが高い確率で発生します。リポジトリ作成ユーティリティでは、インスタンスを消去するための特別なパッケージが提供されています。例:

DECLARE
FILTER INSTANCE_FILTER := INSTANCE_FILTER();

MAX_INSTANCES NUMBER;
DELETED_INSTANCES NUMBER;
PURGE_PARTITIONED_DATA BOOLEAN := TRUE;
BEGIN
.
FILTER.COMPOSITE_PARTITION_NAME:="default";
FILTER.COMPOSITE_NAME := "FlatStructure";
FILTER.COMPOSITE_REVISION := "10.0";
FILTER.STATE := fabric. STATE_UNKNOWN;
FILTER.MIN_CREATED_DATE := to_timestamp("2010-09-07","YYYY-MM-DD");
FILTER.MAX_CREATED_DATE := to_timestamp("2010-09-08","YYYY-MM-DD");
MAX_INSTANCES := 1000;
.
DELETED_INSTANCES := FABRIC.DELETE_COMPOSITE_INSTANCES(
FILTER => FILTER,
MAX_INSTANCES => MAX_INSTANCES,
PURGE_PARTITIONED_DATA => PURGE_PARTITIONED_DATA
);

これにより、2010-09-07から2010-09-08までの間に作成されたUNKNOWN状態のFlatStructureコンポジット(バージョン10)の最初の1000個のインスタンスが削除されます。提供されるSQLパッケージに含まれている可能性のある操作の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のSOAコンポジット・アプリケーション・インスタンスの管理に関する項を参照してください。必ず、適切に消去できるようにするために提供されているスクリプトを使用してください。composite_dn表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。

16.3 UMSドライバの構成

UMSドライバの構成情報は、SOAクラスタに自動的には伝播されません。UMSドライバの構成をクラスタに伝播する手順は次のとおりです。

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

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

ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml

ディレクトリ・パスの「*」は、デプロイ中にOracle WebLogic Serverによってランダムに生成されるディレクトリ名を表します。たとえば、3682yqなどです。

フェイルオーバーに備え、強制的にサーバー移行を実行しファイルをソース・ノードからコピーする方法でUMSドライバ構成ファイルを作成します。

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

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

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

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

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

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

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

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

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

16.4 トポロジのスケール・アップ(管理対象サーバーを既存ノードに追加)

トポロジのスケールアップとは、1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することです。新しい管理対象サーバーを作成する場合は、既存ノードのインストール(WebLogic Serverホーム、Oracle Fusion Middlewareホーム、ドメイン・ディレクトリなど)を使用できます。WebLogic Server、SOAまたはWebCenter Portalのバイナリを新しい場所にインストールしたり、packとunpackを実行したりする必要はありません。

サーバー移行を使用してサーバーのスケール・アップを行う場合は、必要となる容量およびリソース割当てについて計画します。例として、次のシナリオについて考えてみます。

- サーバー1がノード1上にあり、このサーバーはノード2上のサーバー2を使用するクラスタ内サーバー移行を使用します。

- スケールアップ操作によって、ノード1のクラスタにサーバー3が追加されます。これもサーバー移行を使用します。

このシナリオでは、ノード1またはノード2のいずれかですべてのサーバー(サーバー1、サーバー2、サーバー3および管理サーバー)が実行される恐れがあります。つまり、サーバー移行を使用するすべてのサーバーが1つのノード上(サーバー移行候補マシンの構成で定義される)で実行される最悪のケースに対応できるように、各ノードを十分なリソースで設計する必要があるということです。

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

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

- 第16.4.1項「Oracle SOA (WSMを含む)のスケール・アップ」

- 第16.4.2項「Oracle WebCenter Portalのスケール・アップ」

- 第16.4.3項「Oracle WebCenter Contentのスケール・アップ」

16.4.1 Oracle SOA (WSMを含む)のスケール・アップ

SOAトポロジ(WSMを含む)をスケール・アップするには、次の手順を実行します。

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

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーのサマリー」ページが表示されます。

2. 「ロックして編集」をクリックして、クローニングする管理対象サーバー(たとえばWLS_SOA1)を選択します。

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

4. 新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。ここでは、WLS_SOA1が実行されていたノード1に新しいサーバーを追加します。

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

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

3. WLS_WSMサーバーの場合は、第8.6項「Oracle WSMについてのJavaオブジェクト・キャッシュの構成」で説明されているように、Javaオブジェクト・キャッシュの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。同じノードの複数のWLS_WSMサーバー用に同じディスカバリ・ポートを使用できます。第8.6項「Oracle WSMについてのJavaオブジェクト・キャッシュの構成」の手順をWLS_WSMサーバーごとに繰り返すと、サーバー・リストが更新されます。

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

1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms

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

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

3. 新しいUMS JMSサーバー用の新しい永続ストアを作成し(UMS JMSサーバーの作成方法は後述します)、UMSJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms

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

注意:
新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

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

5. BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms

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

6. BPMシステムの場合のみ: BPM用の新しいJMSサーバー(たとえばBPMJMSServer_N)を作成します。このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

7. UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。

8. SOA、UMSおよび(適用可能な場合)BPM JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BPM: BPMJMSMOdule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

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

このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。「保存してアクティブ化」をクリックします。

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

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

6. 管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=myPassword1

「保存してアクティブ化」をクリックします。

7. 新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

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

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

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

3. 「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

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

9. 新しい管理対象サーバーのサーバー移行を構成します。Oracle WebLogic Server管理コンソールを使用してサーバー移行を構成する手順は次のとおりです。

注意:
これはスケールアップ操作であるため、ノードにノード・マネージャが存在していること、およびサーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済であることが必要です。新しいSOA管理対象サーバーの浮動IPも、すでに存在している必要があります。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

2. 表の「名前」列で、移行を構成するサーバーの名前(ハイパーリンクとして表示される)をクリックします。選択したサーバーの「設定」ページが表示されます。

3. 「移行」サブタブをクリックします。

4. 「移行の構成」セクションで、移行に参加するサーバーを「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、SOAHOST1(すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

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

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

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

7. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

10. 新しいサーバーを含むように、クラスタのアドレスを更新します。

1. 管理コンソールで、「環境」を選択し、「クラスタ」を選択します。

2. SOA_Clusterサーバーをクリックします。
SOA_Clusterの「設定」画面が表示されます。

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

4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例: SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOST1VHN1:8001

5. 変更を保存してアクティブ化します。

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

1. WLS_SOAn管理対象サーバーを停止します。
これを実行するには、run kill -9 <pid>を管理対象サーバーのPIDに対して実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを実行します。

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

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

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

16.4.2 Oracle WebCenter Portalのスケール・アップ

WebCenter Portalトポロジをスケール・アップするには、次の手順を実行します。

注意:
1つのノードでの複数の管理対象サーバーの実行は、WC_SpacesおよびWC_Portletサーバーでのみサポートされます。

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

1. 管理コンソールで、「環境」を選択し、「サーバー」を選択します。

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

3. クローニングする管理対象サーバー(たとえば、WC_Spaces1またはWC_Portlet1)を選択します。

4. 「クローン」を選択します。

5. 新しい管理対象サーバーにWC_SERVERNAMEnという名前を付けます(ここで、nは新しい管理対象サーバーを識別する番号です)。

以降の手順では、すでにWC_Spaces1またはWC_Portlet1が実行されている新しいサーバーにWCPHOST1を追加します。

2. リスニング・アドレスには、この新しい管理対象サーバーに使用するホスト名またはIP(既存サーバーと同じもの)を割り当てます。
この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。

3. 新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します。詳細は、第10.5項「Spaces_Cluster用のJavaオブジェクト・キャッシュの構成」を参照してください。

4. Oracle HTTP Serverモジュールをクラスタの新規メンバーで再構成します。詳細は、第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」を参照してください。WebLogicClusterパラメータの終わりに、新しいサーバーのホストとポートを追加します。

- WC_Spacesの場合は、メンバーを/webcenter、/webcenterhelp、/rss、/restのLocationブロックに追加します。

- WC_Portletの場合は、メンバーを/portalTools、/wsrp-tools、/pageletsのLocationブロックに追加します。

16.4.3 Oracle WebCenter Contentのスケール・アップ

1つのドメイン、1つのノードに対して、Oracle WebCenter Content管理対象サーバー1台のみが、Oracle Fusion Middlewareによってサポートされます。Oracle WebCenter Content管理対象サーバーを追加するには、『Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド』のWebCenter Contentのスケール・アウト手順に関する項の手順に従って、Oracle WebCenter Content管理対象サーバーを新しいノードに追加します。

16.5 トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)

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

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

- 第16.5.1項「Oracle SOA (WSMを含む)のスケール・アウト」

- 第16.5.2項「Oracle WebCenter Portalのスケール・アウト」

- 第16.5.3項「Oracle WebCenter Contentのスケール・アウト」

16.5.1 Oracle SOA (WSMを含む)のスケール・アウト

トポロジをスケールアウトするには、SOAおよび(または)WSM-PMで構成した新しい管理対象サーバーを新しいノードに追加します。

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

前提条件

- SOAおよびWSM-PMで構成された管理対象サーバーを実行している既存ノードがトポロジ内に存在していること。

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

- ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておきます。ノード内のoraInventoryを更新し、これに共有記憶域のインストールをアタッチするには、次の場所でattachHome.shスクリプトを使用します。

ORACLE_HOME/oui/bin/

ミドルウェア・ホーム・リストを更新してWL_HOMEを追加または削除するには、次のディレクトリにあるbeahomelistファイルを編集します。

user_home/bea/

トポロジをスケール・アウトするには:

1. 新しいノード上に、既存のMW_Home (SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。

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

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

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

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

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

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

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

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

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

7. 新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。
このサーバーでサーバー移行を実行する場合(推奨)、ここでサーバーのVIP(浮動IPとも呼ばれる)を指定します。このVIPは、既存の管理対象サーバーとは別のものを使用してください。

8. WLS_WSMサーバーの場合は、第8.6項「Oracle WSMでのJava Object Cacheの構成」で説明されているように、Java Object Cacheの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。

9. 新しい管理対象サーバーにSOA、BPM(該当する場合)およびUMSのJMSサーバーを作成します。

注意:
この手順は、WLS_SOA管理対象サーバーの場合にのみ実行し、WLS_WSM管理対象サーバーをスケール・アウトする場合は不要です。

SOA用およびUMS用のJMSサーバーを作成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms

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

2. SOA用の新しいJMSサーバーを作成します(例: SOAJMSServer_N)。SOAJMSFileStore_Nは、このJMSサーバーで使用します。先ほど作成した管理対象サーバー(WLS_SOAn)をSOAJMSServer_Nサーバーのターゲットに指定します。

3. 新しいUMSJMSServer用の新しい永続ストアを作成し、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」でJMS永続ストアのディレクトリとして推奨されているパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms

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

注意:
新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

4. UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。先ほど作成した管理対象サーバー(WLS_SOAn)を、UMSJMSServer_Nサーバーのターゲットに指定します。

5. BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms

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

6. BPMシステムの場合のみ: BPM用の新しいJMSサーバー(たとえばBPMJMSServer_N)を作成します。このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

7. SOA、UMSおよび(適用可能な場合)BPM JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BPM: BPMJMSModule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

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

このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。「保存してアクティブ化」をクリックします。

8. UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。

10. 次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

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

SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_COMMON_HOME/common/bin

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

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name/ -template=soadomaintemplateScale.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications -overwrite_domain=true

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

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

12. 管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=myPassword1

「保存してアクティブ化」をクリックします。

13. 新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

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

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

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

3. 「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

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

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

SOAHOSTN> WL_HOME/server/bin/startNodeManager

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

1. 新しく作成したWLS_SOAn管理対象サーバーが実行中であることを確認します。

2. ロード・バランサ上のアプリケーションにアクセスします(https://soa.example.com/soa-infra)。アプリケーションが機能している必要があります。

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

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

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

Oracle WebLogic Server管理コンソールにログインし、サーバーの移行を構成します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーのサマリー」ページが表示されます。

2. 表の「名前」列で、移行を構成するサーバー(ハイパーリンクとして表示される)を選択します。そのサーバーの「設定」ページが表示されます。

3. 「移行」タブをクリックします。

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

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

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

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

7. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

18. 新しいサーバーを含むように、クラスタのアドレスを更新します。

1. 管理コンソールで、「環境」を選択し、「クラスタ」を選択します。

2. SOA_Clusterサーバーをクリックします。
SOA_Clusterの「設定」画面が表示されます。

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

4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。たとえば、ADMINVHN:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8001と入力します。

5. 変更を保存してアクティブ化します。

19. この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。

1. 管理対象サーバーのPID (プロセスID)で次のコマンドを実行して、WLS_SOAn管理対象サーバーを停止します。

kill -9 pid

ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_SOAn

注意:
Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid pid

pidは、管理対象サーバーのプロセスIDを表します。

WLS_SOAn管理対象サーバーのプロセスIDを確認するには、次のコマンドを実行します。

MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v

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

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

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

16.5.2 Oracle WebCenter Portalのスケール・アウト

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

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

前提条件

- WebCenter Portalで構成された管理対象サーバーを実行している既存ノードがトポロジ内に存在する必要があります。

- 新しいノードは、WebLogic ServerおよびOracle WebCenter Portal用の既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerまたはWebCenter Portalのバイナリを新しい場所にインストールする必要はありませんが、packとunpackを実行して管理対象サーバーのドメインを作成する必要があります。

- WC_SpacesとWC_Utilitiesサーバーは、どちらも新しいノードでスケール・アウトされるか、どちらもスケール・アウトされない必要があります。これは、WebCenter Portalアプリケーションと分析アプリケーションの間のローカル・アフィニティによるものです。

トポロジをスケール・アウトするには:

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

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

WCPHOSTn> cd ORACLE_BASE/product/fmw/wc/
WCPHOSTn> ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_verion

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

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

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

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

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

6. Oracle WebLogic Server管理コンソールを使用して、新しい管理対象サーバーにWC_Spaces1、WC_Portlet1、WC_Collaboration1またはWC_Utilities1のいずれかをクローニングします。それにWC_XXXnという名前を付けます(nはその新しいマシンに割り当てる番号です)。

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

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

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

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

4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

5. 表の「名前」列で、更新するリスニング・アドレスを持つ管理対象サーバーを選択します。その管理対象サーバーの「設定」ページが表示されます。

6. 「リスニング・アドレス」をWCPHOSTnに設定します(ここで、WCPHOSTnは、新しいマシンのDNS名です)。

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

8. 変更を保存してアクティブ化します。
変更内容は、管理対象サーバーが再起動されるまでは有効になりません。

8. packコマンドをSOAHOST1上で実行してテンプレート・パックを作成し、WCPHOSTnに解凍します。
これらの手順は、第10.4.1項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」に記載されています。

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

WCPHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip

10. これが新しいコラボレーション管理対象サーバーである場合:

1. 第10.7項「ディスカッション・サーバーでのクラスタリングの構成」の手順に従って新しいディスカッション・サーバーのクラスタリングを構成します。

2. また、第10.6項「マルチキャストからユニキャストへのディスカッションの変換」の手順を、coherence.localhostパラメータに新しいホストのホスト名を使用して実行済であることも確認します。

11. これが新しいユーティリティ管理対象サーバーである場合は、第10.9項「アクティビティ・グラフの構成」の手順に従ってアクティビティ・グラフが無効化済であることを確認します。また、ユーティリティおよびローカルSpacesサーバーで、第10.8項「Analyticsの構成」の新しいAnalyticsコレクタの構成手順が実行済であることも確認します。

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

1. 新しく作成したWLS_SOAn管理対象サーバーが実行中であることを確認します。

2. ロード・バランサ上のアプリケーションにアクセスします(https://soa.example.com/soa-infra)。アプリケーションが機能している必要があります。

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

16.5.3 Oracle WebCenter Contentのスケール・アウト

Oracle WebCenter Content管理対象サーバーを追加するには、『Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド』のWebCenter Contentのスケール・アウト手順に関する項の手順に従って、Oracle WebCenter Content管理対象サーバーを新しいノードに追加します。

16.6 WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行

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

表16-1 WebCenter Portal (11g)エンタープライズ・デプロイメントでバックアップする静的アーティファクト

タイプ

ホスト

場所

層

ORACLEホーム(DB)

RACデータベース・ホスト - CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

データ層

Oracleホーム(OHS)

WEBHOST1およびWEBHOST2

ORACLE_BASE/admin/instance_name

Web層

MWホーム(SOAおよびWC)

SOAHOST1およびSOAHOST2 - SOA

WCPHOST1とWCPHOST2 - WC

すべてのホスト上のMW_HOME

アプリケーション層

ORACLE HOME (WCC)

WCPHOST1とWCPHOST2

共有ディスク上: /share/oracle/wcc

各ホストのORACLE_HOME/wccにあるローカル・ファイル

アプリケーション層

インストール
関連のファイル

OraInventory

user_home/bea/beahomelist, oraInst.loc, oratab

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

表16-2 WebCenter Portal (11g)エンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト

タイプ

ホスト

場所

層

ドメイン・ホーム

SOAHOST1

SOAHOST2

WCPHOST1

WCPHOST2

ORACLE_BASE/admin/domain_name/ mserver/domain_name

アプリケーション層

アプリケーション・アーティファクト(earおよびwarファイル)

SOAHOST1

SOAHOST2

WCPHOST1

WCPHOST2

管理コンソールですべてのデプロイメントを確認し、すべてのアプリケーション・アーティファクトをバックアップする

アプリケーション層

OHSインスタンス・ホーム

WEBHOST1およびWEBHOST2

ORACLE_BASE/admin/instance_name

Web層

OHS WCC構成ファイル

WEBHOST1およびWEBHOST2

各ホストの/share/oracle/wcc(ローカル・ファイル・システム)

Web層

RACデータベース

CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

データ層

Oracle WebCenter Contentリポジトリ

データベース・ベース

データ層

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

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

ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。次に、SOAHOST1およびSOAHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。

前提条件:

- 管理サーバーが、すべてのアドレスではなく、ADMINVHNでリスニングするように構成されている。第8.3項「SOAHOST1での構成ウィザードによるドメインの作成」の手順14を参照してください。

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

- SOAHOST1: 100.200.140.165

- SOAHOST2: 100.200.140.205

- ADMINVHN: 100.200.140.206. これは管理サーバーを実行している場所の仮想IPであり、ethX:Yに割り当てられており、SOAHOST1とSOAHOST2からアクセスできます。

- SOAHOST1での管理サーバーの実行場所であるドメイン・ディレクトリは、共有記憶域にあります。この共有記憶域は一度に1つのマシンにのみマウントする必要がありますが、SOAHOST2にマウントできます。管理サーバーがSOAHOST2にフェイルオーバーした場合、ASERVER_HOMEをSOAHOST2にマウントし、SOAHOST1からアンマウントする必要があります。

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

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

- 第16.7.1項「別ノードへの管理サーバーのフェイルオーバー」

- 第16.7.2項「Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証」

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

16.7.1 別ノードへの管理サーバーのフェイルオーバー

次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーしたうえで、同じWebLogic Serverマシン(これは物理マシンではなく論理マシンです)を引き続きその管理サーバーで使用する方法を示しています。

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

1. 管理サーバーを停止します。

2. 最初のノードからaserver共有をアンマウントします。

3. 第2ノードにaserver共有をマウントします。

4. IPを第2ノードに移行します。

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

/sbin/ifconfig ethX:Y down

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

/sbin/ifconfig interface:index IP_Address netmask netmask

例:

/sbin/ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0

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

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

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

6. SOAHOST2上の管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して起動します。

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

1. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。

http://ADMINVHN:7001/console

2. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。

http://ADMINVHN:7001/em

注意:
管理サーバーでは、フェイルオーバーにノード・マネージャを使用しません。手動でフェイルオーバーした後、サーバーの管理コンソールの「現在のマシン」フィールドに表示されるマシン名は、フェイルオーバー・マシン「SOAHOST2」でなく、「SOAHOST1」になります。ノード・マネージャでは管理サーバーを監視しないので、「現在のマシン」フィールドに表示されるマシン名は関係ないため、無視してかまいません。

16.7.2 Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証

第8.7.5項「Oracle HTTP Serverを介したアクセスの検証」と同じ手順を実行します。この目的は、SOAHOST2で実行している管理サーバーにもアクセスできることを確認することです。

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

この手順では、管理サーバーをフェイルバックできることを確認します。フェイルバックとは、SOAHOST2で実行している管理サーバーを停止し、ADMINVHNをSOAHOST1ノードに戻して、SOAHOST1で再び管理サーバーを実行することです。

ADMINVHNをSOAHOST1に戻す手順は次のとおりです。

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

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

/sbin/ifconfig ethZ:N down

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

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

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

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

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

5. 第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して、SOAHOST1上の管理サーバーを再度起動します。

cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin
./startWebLogic.sh

6. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。

http://ADMINVHN:7001/console

7. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。

http://ADMINVHN:7001/em

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

エンタープライズ・デプロイメントの本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Cluster (Oracle RAC)については、データベース接続はOracle RAC VIPとデータベース・リスナー・ポートを使用して確立されます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。このような構成が不可能である場合は、次のディレクトリにあるsqlnet.oraファイル内の*SQLNET.EXPIRE_TIME=n*パラメータを設定します。

ORACLE_HOME/network/admin

nは分単位の時間です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。

16.9 Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング

この項では、WebCenter Portalエンタープライズ・デプロイメントで発生する可能性のある問題を示し、その解決方法を提案します。

注意:
内部URLにアクセスしようとすると404エラーが発生する場合は、独自のポータルまたはランディング・ページへのリダイレクトを追加できます。

この項の内容は次のとおりです。

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

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

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

- 第16.9.4項「ドメインの伝播後WC_Spaces Serverが起動しない」

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

- 第16.9.6項「データベースのフェイルオーバー後にポートレットが使用できなくなる」

- 第16.9.7項「構成済のJOCポートがすでに使用中」

- 第16.9.8項「JMS構成の復元」

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

- 第16.9.10項「RESTポリシーの構成後に2次認証を無効にする」

- 第16.9.11項「サーバー移行時にSudoエラーが発生する」

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

- 第16.9.13項「最大サイズ超過エラー・メッセージ」

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

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

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

解決方法: このエラーが発生するのは、サーバーの起動パラメータが管理コンソールで変更された場合です。この場合は、構成を変更しようとしていたサーバーの起動構成の一部であるユーザー名/パスワードの情報を管理コンソールで指定するか、<password-encrypted></password-encrypted>エントリをconfig.xmlファイルから削除してください(管理サーバーの再起動が必要)。

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

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

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

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

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

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

解決方法: これは、OAM SSOが構成済のときに発生する現象で、管理サーバーによってリダイレクトが実行された結果です。このリダイレクトにかかわらず、アクティブ化は完了します。必要であれば、ユーザーは手動で目的のコンテキスト・メニューに戻ることができます。

16.9.4 ドメインの伝播後WC_Spaces Serverが起動しない

問題: unpackユーティリティを使用し、SOAHOST2、WCPHOST1およびWCPHOST2にドメイン構成を伝播した後、WC_Spacesサーバーを起動できません。

[Deployer:149158]No application files exist at '/u01/app/oracle/admin/wcpedg_domain/aserver/wcpedg_domain/custom.webcenter.spaces.fwk'...

解決方法: 管理サーバーがマウントされているかどうかに関係なく、管理サーバーが作成したconfig.xml内のパスは、すべてのマシンで使用可能にする必要があります。これは、欠落しているフォルダまたはファイルを、プライマリ・ドメインから新しいノードのローカル・ファイル・システムにコピーすることによって行われます。

1. 各マシンで、WebCenter Portalファイルを共有記憶域からローカル記憶域にコピーします。
管理サーバーがマウントされた状態では、次のように一時ディレクトリに対して実行できます。

$ mkdir /tmp/wcptemp
$ cp ORACLE_BASE/admin/domain_name/aserver/applications/domain_name/* /tmp/wcptemp

2. 管理サーバーがディスマウントされた状態の各マシンでは、ローカル・ディレクトリを作成してから、そのディレクトリに次のファイルを移動します。

$ mkdir -p ORACLE_BASE/admin/domain_name/aserver/applications/domain_name
$ mv /tmp/webcentertemp/* ORACLE_BASE/admin/domain_name/aserver/applications/domain_name

すべての管理対象サーバーが正常に起動されるはずです。

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

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

<Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory:
ORACLE_BASE/admin/soadomain/aserver/
soadomain/servers/AdminServer/data/ldap/ldapfiles.
Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

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

ORACLE_BASE/ admin/domain_name/aserver/domain_name/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lok

16.9.6 データベースのフェイルオーバー後にポートレットが使用できなくなる

問題: WebCenter Portal内でページを作成しているときに、そのページにポートレットを追加した後でデータベース・フェイルオーバーが発生すると、エラーがあるコンポーネントがページに表示されます。

"Error"
"Portlet unavailable"

このメッセージは、ページをリフレッシュしたり、いったんログアウトして再度ログインしてもなくなりません。

解決方法: この問題を解決するには、該当のコンポーネントを削除してからもう一度追加します。

16.9.7 構成済のJOCポートがすでに使用中

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

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

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

16.9.8 JMS構成の復元

問題: soa-createUDD.pyスクリプトに渡されたパラメータに誤りがあるか、別の誤りによってSOAクラスタのJMS構成で障害が発生しています。

解決方法: soa-createUDD.pyを使用して、構成をリストアします。

SOAクラスタがOracle Fusion Middleware構成ウィザードから作成された後でsoa-createUDD.pyスクリプトを実行しているときに、なんらかの誤りが生じた(誤ったオプションが使用された、ターゲットが変更された、またはモジュールが間違って削除された)場合。このような状況では、soa-createUDD.pyスクリプトを使用し、次の手順で適切なJMS構成をリストアできます。

1. 既存のSOA JMSリソース(SOAインフラストラクチャ・システムが所有するJMSモジュール)を削除します。

2. soa-createUDD.pyを再実行します。このスクリプトは、SOA用に作成されたJMSサーバーが保持され、SOA用の共通分散送り先を使用するために必要な宛先とサブデプロイメント・モジュールが作成されることを想定しています。この場合、オプション--soaclusterを指定してスクリプトが実行される必要があります。スクリプトを再実行後、WebLogic Server管理コンソールから次のアーティファクト(ドメイン構造、サービス、メッセージング、JMSモジュール)が存在することを確認します。

SOAJMSModuleUDDs        ---->SOAJMSSubDM targeted to SOAJMSServer_auto_1 and SOAJMSServer_auto_2
UMSJMSSystemResource    ---->UMSJMSSubDMSOA targeted to UMSJMSServer_auto_1 and UMSJMSServer_auto_2

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

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

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

16.9.10 RESTポリシーの構成後に2次認証を無効にする

問題: RESTポリシーの構成後、その後の認証でもOAMを介した外部のクライアントの認証が要求されます。

解決方法: 2次認証はWebLogic Serverから発生しています。WebLogic Serverの資格証明の要求を無効にするには、次のようにセキュリティ・ポリシーを更新する必要があります。

1. 次のファイルを探します。

/aserver/domain_name/config/config.xml

2. セキュリティの構成の終わりの部分で(つまり</security-configuration>の前に)、次の行を追加します。

<enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credenti als>

3. ドメイン内のすべてのサーバーを再起動します。

16.9.11 サーバー移行時にSudoエラーが発生する

問題: サーバー移行のためwlsifconfigを実行すると、次の警告が表示されます。

sudo: sorry, you must have a tty to run sudo

解決方法: WebLogicユーザー('oracle')がバックグラウンドでsudoを実行できません。この問題を解決するには、次の行を/etc/sudoersに追加します。

Defaults:oracle !requiretty

詳細は、第14.5項「wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定」を参照してください。

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

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

Internal Exception: java.sql.SQLException: Unexpected exception while enlisting
XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start()
failed on resource 'SOADataSource_wcpedg_domain': XAER_NOTA : The XID
is not valid

解決方法: トランザクション・タイムアウト設定を確認し、JTAトランザクション・タイムアウトがデータ・ソースXAトランザクション・タイムアウトよりも短いことを確認します(後者はデータベースでのdistributed_lock_timeoutよりも短い)。

出荷時の構成では、SOAデータ・ソースではXAタイムアウト値は設定されていません。WebLogic Server管理コンソールでは、Set XA Transaction Timeout構成パラメータのチェック・ボックスの選択が解除されています。この場合、データ・ソースはドメイン・レベルのJTAタイムアウトを使用します。これは30に設定されています。また、データベースに対するデフォルトのdistributed_lock_timeout値は60です。このため、トランザクションの期間がこれらの値より低いことが想定されるシステムでは、SOA構成は正しく機能します。特定の処理にかかると想定されるトランザクション時間に応じてこれらの値を調整してください。

16.9.13 最大サイズ超過エラー・メッセージ

問題: SOAクラスタで複合ルールを編集して保存すると、サーバーの出力ファイルに、レプリケーション・メッセージの最大サイズを超えたことを報告するエラー・メッセージが記録されることがあります。例:

<rws3211539-v2.company.com> <WLS_SOA1> <ExecuteThread: '2' for queue:
'weblogic.socket.Muxer'> <<WLS Kernel>> <> <> <1326464549135> <BEA-000403>
<IOException occurred on socket:
Socket[addr=/10.10.10.10,port=48290,localport=8001]
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'.
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'

解決方法: このエラーは、HTTPセッションに配置され、クラスタにレプリケートされたシリアル化メッセージのサイズが大きいために発生します。使用しているルールのサイズに応じて最大メッセージ・サイズを大きくします。

最大メッセージ・サイズを大きくする手順は次のとおりです。

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

2. 「サーバー」→Server_name→「プロトコル」→「一般」を選択します。

3. 必要に応じて「最大メッセージ・サイズ」フィールドを変更します。

A Oracle RACでのマルチ・データ・ソースの使用

この付録では、Oracle RACでのマルチ・データ・ソースの使用方法について説明します。新しいOracle RACアプリケーションを構築する際には、GridLinkデータ・ソースを使用することをお薦めします。ただし、GridLinkデータ・ソースをサポートしないレガシー・アプリケーションとデータベースを使用している場合、この付録の次の情報を参照します。

この付録の内容は次のとおりです。

- マルチ・データ・ソースおよびOracle RACについて

- EDGトポロジ用のマルチ・データ・ソースの構成の標準的な手順

A.1 マルチ・データ・ソースおよびOracle RACについて

マルチ・データ・ソースには、接続リクエストに対応するために使用する順番付きのデータ・ソースのリストがあります。通常、このようなマルチ・データ・ソースへのすべての接続リクエストは、リストの最初のデータ・ソースによって処理されます。データベースの接続のテストが失敗し、接続を置換できない場合、またはデータ・ソースが中止となった場合、リスト内の次のデータ・ソースから接続が順番に探されます。

Oracle RACでマルチ・データ・ソースを構成する方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のOracle RACでのマルチ・データ・ソースの使用に関する項を参照してください。

A.2 EDGトポロジ用のマルチ・データ・ソースの構成の標準的な手順

ドメインの構成時、データ・ソースを構成できます。たとえば、エンタープライズ・デプロイメントの参照トポロジ用に最初の管理ドメインを構成する場合、構成ウィザードを使用してドメインの特徴とデータ・ソースを定義できます。

このエンタープライズ・デプロイメント・ガイドのトポロジの構成手順では、Oracle RACでGridLinkデータ・ソースを定義する場合の具体的な手順が含まれています。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLinkの手順を次に置き換えます。

1. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

1. 適切なスキーマを選択します。

2. コンポーネント・スキーマのRAC構成については、「RACマルチ・データ・ソースへ変換」を選択します。

3. Repository Creation Utilityを実行したときに、次のデータ・ソースがスキーマ接頭辞とともに画面に表示されることを確認します。

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

2. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面が表示されます(図A-1)。

図A-1 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

この画面で、次の手順を実行します。

1. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。

- サービス名: データベースのサービス名を入力します。

- ユーザー名: データベース・スキーマの完全なユーザー名(接頭辞を含む)を入力します。

- パスワード: スキーマへのアクセスに使用するパスワードを入力します。

2. ホスト名、インスタンス名およびポートを入力します。

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

4. この手順をOracle RACインスタンスごとに実行します。

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

3. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

B アプリケーションおよびリソースのサーバーへのターゲット設定

この付録では、Oracle WebCenter Portal用のOracle WebLogic Serverドメイン内のサーバーにターゲット設定されるアプリケーション、データ・ソース、永続ストア、Java Messaging Service (JMS)モジュールおよび起動クラスと停止クラスのリストを示します。

この付録では、次の管理対象サーバーにターゲット設定されるアプリケーションおよびリソースのリストを示します。

- WebCenter Portal管理対象サーバー

- WebCenter Portalポートレット管理対象サーバー

- WebCenter Portalコラボレーション管理対象サーバー

- WebCenter Portalユーティリティ管理対象サーバー

- Oracle SOA Suite管理対象サーバー

- Oracle WSMポリシー・マネージャ管理対象サーバー

- WebCenter Content管理対象サーバー

- Inbound Refinery管理対象サーバー

- 管理サーバー

B.1 WebCenter Portal管理対象サーバー

次のアプリケーションおよびリソースは、これらの管理対象サーバーを含むWebCenter Portalクラスタ(Spaces_Cluster)にターゲット設定されます。

- WCPHOST1上のWC_Spaces1

- WCPHOST2上のWC_Spaces2

アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- webcenter#11.1.1.4.0

- webcenter-help#11.1.1.4.0

- wsil-wls

- wsm-pm

データ・ソース

- ActivitiesDS

- mds-owsm

- mds-SpacesDS

- WebCenterDS

永続ストア

- なし

JMSデプロイメント・モジュール

- なし

起動クラスと停止クラス

- AWTアプリケーション・コンテキスト起動クラス - oracle.jrf.AppContextStartup

- DMS起動 - oracle.dms.wls.DMSStartup

- DMS停止 - oracle.dms.wls.DMSShutdown

- JMXフレームワーク起動クラス - oracle.as.jmx.framework.wls.spi.StartupListener

- JOC起動 - oracle.ias.cache.Startup

- JOC停止 - oracle.ias.cache.Startup

- JRF起動クラス - oracle.jrf.wls.JRFStartup

- JPS起動クラス - oracle.security.jps.wls.JpsWlsStartupClass

- ODL起動 - oracle.core.ojdl.weblogic.ODLConfiguration

- Webサービス起動クラス - oracle.j2ee.ws.server.WebServiceServerStartup

B.2 WebCenter Portalポートレット管理対象サーバー

次のアプリケーションおよびリソースは、これらの管理対象サーバーを含むポートレット・クラスタ(Portlet_Cluster)にターゲット設定されます。

- WCPHOST1上のWC_Portlet1

- WCPHOST2上のWC_Portlet2

アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- pagelet-producer#11.1.1.6.0

- portalTools#11.1.1.4.0

- services-producer#11.1.1.6.0

- wsrp-tools#11.1.1.4.0

- wsil-wls

- wsm-pm

データ・ソース

- mds-owsm

- mds-PageletProducerDS

- mds-ServicesProducerDS

- Portlet-ServicesProducerDS

- PortletDS

- WC-ServicesProducerDS

永続ストア

- なし

JMSデプロイメント・モジュール

- なし

起動クラスと停止クラス

- AWTアプリケーション・コンテキスト起動クラス - oracle.jrf.AppContextStartup

- DMS起動 - oracle.dms.wls.DMSStartup

- DMS停止 - oracle.dms.wls.DMSShutdown

- JMXフレームワーク起動クラス - oracle.as.jmx.framework.wls.spi.StartupListener

- JOC起動 - oracle.ias.cache.Startup

- JOC停止 - oracle.ias.cache.Startup

- JRF起動クラス - oracle.jrf.wls.JRFStartup

- JPS起動クラス - oracle.security.jps.wls.JpsWlsStartupClass

- ODL起動 - oracle.core.ojdl.weblogic.ODLConfiguration

- Webサービス起動クラス - oracle.j2ee.ws.server.WebServiceServerStartup

B.3 WebCenter Portalコラボレーション管理対象サーバー

次のアプリケーションおよびリソースは、これらの管理対象サーバーを含むコラボレーション・クラスタ(Collab_Cluster)にターゲット設定されます。

- WCPHOST1上のWC_Collaboration1

- WCPHOST2上のWC_Collaboration2

アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- owc_discussions#11.1.1.4.0

- wsil-wls

- wsm-pm

データ・ソース

- mds-owsm

- OWC_DiscussionDS

永続ストア

- なし

JMSデプロイメント・モジュール

- なし

起動クラスと停止クラス

- AWTアプリケーション・コンテキスト起動クラス - oracle.jrf.AppContextStartup

- DMS起動 - oracle.dms.wls.DMSStartup

- DMS停止 - oracle.dms.wls.DMSShutdown

- JMXフレームワーク起動クラス - oracle.as.jmx.framework.wls.spi.StartupListener

- JOC起動 - oracle.ias.cache.Startup

- JOC停止 - oracle.ias.cache.Startup

- JRF起動クラス - oracle.jrf.wls.JRFStartup

- JPS起動クラス - oracle.security.jps.wls.JpsWlsStartupClass

- ODL起動 - oracle.core.ojdl.weblogic.ODLConfiguration

- Webサービス起動クラス - oracle.j2ee.ws.server.WebServiceServerStartup

B.4 WebCenter Portalユーティリティ管理対象サーバー

次のアプリケーションおよびリソースは、これらの管理対象サーバーを含むユーティリティ・クラスタ(Utilities_Cluster)にターゲット設定されます。

- WCPHOST1上のWC_Utilities1

- WCPHOST2上のWC_Utilities2

アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- activitygraph-engines#11.1.1.4.0 (WC_Utilities1のみ)

- analytics-collector#11.1.1.4.0

- wcps-services#11.1.1.4.0

- wsil-wls

- wsm-pm

データ・ソース

- ActivitiesDS

- mds-wcpsDS

- PersonalizationDS

永続ストア

- なし

JMSデプロイメント・モジュール

- なし

起動クラスと停止クラス

- AWTアプリケーション・コンテキスト起動クラス - oracle.jrf.AppContextStartup

- DMS起動 - oracle.dms.wls.DMSStartup

- DMS停止 - oracle.dms.wls.DMSShutdown

- JMXフレームワーク起動クラス - oracle.as.jmx.framework.wls.spi.StartupListener

- JOC起動 - oracle.ias.cache.Startup

- JOC停止 - oracle.ias.cache.Startup

- JRF起動クラス - oracle.jrf.wls.JRFStartup

- JPS起動クラス - oracle.security.jps.wls.JpsWlsStartupClass

- ODL起動 - oracle.core.ojdl.weblogic.ODLConfiguration

- Webサービス起動クラス - oracle.j2ee.ws.server.WebServiceServerStartup

B.5 Oracle SOA Suite管理対象サーバー

次のアプリケーションおよびリソースは、これらの管理対象サーバーを含むOracle SOA Suiteクラスタ(SOA_Cluster)にターゲット設定されます。

- SOAHOST1上のWLS_SOA1

- SOAHOST2上のWLS_SOA2

アプリケーション

- AqAdapter

- b2bu

- composer

- DbAdapter

- DefaultToDoTaskFlow

- DMSアプリケーション(11.1.1.1.0)

- FileAdapter

- FtpAdapter

- JmsAdapter

- MQSeriesAdapter

- OracleAppsAdapter

- OracleBamAdapter

- soa-infra

- SocketAdapter

- UMSAdapter

- usermessagingdriver-email

- usermessagingserver

- worklistapp

- wsil-wls

- wsm-pm

データ・ソース

- EDNDataSource

- EDNLocalTxDataSource

- mds-owsm

- mds-soa

- OraSDPMDataSource

- SOADataSource

- SOALocalTxDataSource

永続ストア

- BPMJMSFileStore_auto_1

- BPMJMSFileStore_auto_2

- PS6SOAJMSFileStore_auto_1

- PS6SOAJMSServer_auto_2

- SOAJMSFileStore_auto_1

- SOAJMSServer_auto_2

- UMSJMSFileStore_auto_1

- UMSJMSFileStore_auto_2

JMSデプロイメント・モジュール

- BPMJMSServer_auto_1

- BPMJMSServer_auto_2

- PS6SOAJMSServer_auto_1

- PS6SOAJMSServer_auto_2

- SOAJMSServer_auto_1

- SOAJMSServer_auto_2

- UMSJMSServer_auto_1

- UMSJMSServer_auto_2

起動クラスと停止クラス

- AWTアプリケーション・コンテキスト起動クラス - oracle.jrf.AppContextStartup

- DMS起動 - oracle.dms.wls.DMSStartup

- DMS停止 - oracle.dms.wls.DMSShutdown

- JMXフレームワーク起動クラス - oracle.as.jmx.framework.wls.spi.StartupListener

- JOC起動 - oracle.ias.cache.Startup

- JOC停止 - oracle.ias.cache.Startup

- JRF起動クラス - oracle.jrf.wls.JRFStartup

- JPS起動クラス - oracle.security.jps.wls.JpsWlsStartupClass

- ODL起動 - oracle.core.ojdl.weblogic.ODLConfiguration

- SOA起動クラス - oracle.bpel.services.common.util.GenerateBPMCryptoKey

- Webサービス起動クラス - oracle.j2ee.ws.server.WebServiceServerStartup

B.6 Oracle WSMポリシー・マネージャ管理対象サーバー

次のアプリケーションおよびリソースは、これらの管理対象サーバーを含むOracle WSMポリシー・マネージャ・クラスタ(WSM-PM_Cluster)にターゲット設定されます。

- SOAHOST1上のWLS_WSM1

- SOAHOST2上のWLS_WSM2

アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- wsil-wls

- wsm-pm

データ・ソース

- mds-owsm

永続ストア

- なし

JMSデプロイメント・モジュール

- なし

起動クラスと停止クラス

- AWTアプリケーション・コンテキスト起動クラス - oracle.jrf.AppContextStartup

- DMS起動 - oracle.dms.wls.DMSStartup

- DMS停止 - oracle.dms.wls.DMSShutdown

- JMXフレームワーク起動クラス - oracle.as.jmx.framework.wls.spi.StartupListener

- JOC起動 - oracle.ias.cache.Startup

- JOC停止 - oracle.ias.cache.Startup

- JRF起動クラス - oracle.jrf.wls.JRFStartup

- JPS起動クラス - oracle.security.jps.wls.JpsWlsStartupClass

- ODL起動 - oracle.core.ojdl.weblogic.ODLConfiguration

- Webサービス起動クラス - oracle.j2ee.ws.server.WebServiceServerStartup

B.7 WebCenter Content管理対象サーバー

次のアプリケーションおよびリソースは、これらの管理対象サーバーを含むWebCenter Contentクラスタ(WCC_Cluster)にターゲット設定されます。

- WCCHOST1上のWLS_WCC1

- WCCHOST2上のWLS_WCC2

アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- Oracle UCM Help

- Oracle UCMネイティブWebサービス

- Oracle UCM Webサービス

- Oracle WebCenter Content - Content Server

- wsil-wls

データ・ソース

- CSDS

永続ストア

- なし

JMSデプロイメント・モジュール

- なし

起動クラスと停止クラス

- AWTアプリケーション・コンテキスト起動クラス - oracle.jrf.AppContextStartup

- DMS起動 - oracle.dms.wls.DMSStartup

- DMS停止 - oracle.dms.wls.DMSShutdown

- JMXフレームワーク起動クラス - oracle.as.jmx.framework.wls.spi.StartupListener

- JOC起動 - oracle.ias.cache.Startup

- JOC停止 - oracle.ias.cache.Startup

- JRF起動クラス - oracle.jrf.wls.JRFStartup

- JPS起動クラス - oracle.security.jps.wls.JpsWlsStartupClass

- ODL起動 - oracle.core.ojdl.weblogic.ODLConfiguration

- Webサービス起動クラス - oracle.j2ee.ws.server.WebServiceServerStartup

B.8 Inbound Refinery管理対象サーバー

次のアプリケーションおよびリソースは、これらの管理対象サーバーを含むInbound Refineryサーバー・グループ(IBR_Cluster)にターゲット設定されます。

- WCCHOST1上のWLS_IBR1

- WCCHOST2上のWLS_IBR2

アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- Oracle UCM Help

- Oracle UCMネイティブWebサービス

- Oracle UCM Webサービス

- Oracle WebCenter Content - Inbound Refinery

- wsil-wls

データ・ソース

- 該当なし

永続ストア

- なし

JMSデプロイメント・モジュール

- なし

起動クラスと停止クラス

- AWTアプリケーション・コンテキスト起動クラス - oracle.jrf.AppContextStartup

- DMS起動 - oracle.dms.wls.DMSStartup

- DMS停止 - oracle.dms.wls.DMSShutdown

- JMXフレームワーク起動クラス - oracle.as.jmx.framework.wls.spi.StartupListener

- JOC起動 - oracle.ias.cache.Startup

- JOC停止 - oracle.ias.cache.Startup

- JRF起動クラス - oracle.jrf.wls.JRFStartup

- JPS起動クラス - oracle.security.jps.wls.JpsWlsStartupClass

- ODL起動 - oracle.core.ojdl.weblogic.ODLConfiguration

- Webサービス起動クラス - oracle.j2ee.ws.server.WebServiceServerStartup

B.9 管理サーバー

この項に示すアプリケーションおよびリソースは、SOAHOST1およびSOAHOST2上で実行されるOracle WebLogic Server管理サーバー(AdminServer)にターゲット設定されます。

アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- em

- FMWようこそページ・アプリケーション(11.1.0.0.0)

- NonJ2EEManagement (11.1.1)

- wsil-wls

データ・ソース

- mds-owsm

- mds-soa

- mds-ServicesProducerDS

- mds-SpacesDS

永続ストア

- なし

JMSデプロイメント・モジュール

- なし

起動クラスと停止クラス

- AWTアプリケーション・コンテキスト起動クラス - oracle.jrf.AppContextStartup

- DMS起動 - oracle.dms.wls.DMSStartup

- DMS停止 - oracle.dms.wls.DMSShutdown

- JMXフレームワーク起動クラス - oracle.as.jmx.framework.wls.spi.StartupListener

- JOC起動 - oracle.ias.cache.Startup

- JOC停止 - oracle.ias.cache.Startup

- JRF起動クラス - oracle.jrf.wls.JRFStartup

- JPS起動クラス - oracle.security.jps.wls.JpsWlsStartupClass

- ODL起動 - oracle.core.ojdl.weblogic.ODLConfiguration

- Webサービス起動クラス - oracle.j2ee.ws.server.WebServiceServerStartup

索引
A B C D E F G H I J K L M N O P R S T U V W

A

アクセス・ゲート, 15.5.3.5

クラスタの追加, 9.3, 10.2

管理対象サーバーの追加, 9.3, 10.2

管理対象サーバーの既存ノードへの追加, 16.4

管理対象サーバーの新しいノードへの追加, 16.5

アドレス・セキュリティ・フィルタ, 13.19.6.1

admin_vh.conf, 7.6.2

admin_vh.confファイル, 8.7.1

admin.example.com, 3.2.2

管理コンソール

フロントエンドURL, 8.7.4

ホーム・ページへのリダイレクト, 16.9.3, 16.9.7

ログイン画面へのリダイレクト, 16.9.2

サーバー移行の検証, 14.7

管理サーバー, 8.4.1, 8.4.6, 8.7.1

フェイルオーバー, 8.7.6, 16.7, 16.7.3

ホスト名の検証, 8.4.8, 8.5.3

再起動, 13.19.4

SSL通信, 11.3

起動, 8.4.3

検証, 8.4.5

WebCenter Portalの管理者ロール, 15.7.2 アプリケーション層, 2.1.4 arping, 8.2 ASM

「自動ストレージ管理(ASM)」を参照

サーバーのクラスタへの割当て, 9.3, 10.2 サーバーのマシンへの割当て, 9.3, 10.2 オーセンティケータ, 15.5.6, 15.6.5, 15.8.1 自動ストレージ管理(ASM), 5.2.1

B

バックアップ

Oracle HTTP Serverの設定後, 6.2.3

構成ファイル, 15.2.1, 15.5.6.1, 15.6.5.1

Content Server, 13.13, 13.16

データベース, 5.6

ドメイン, 9.3, 10.2

エンタープライズ・デプロイメント, 16.6

インストール, 6.3.3, 8.8, 9.9, 10.12, 15.9

Oracle HTTP Server, 6.2.3

ベスト・プラクティス

SQLNet接続のタイムアウト, 16.8

boot.properties, 8.4.1 BPEL認証, 15.8 BPMWorkflowAdminアプリケーション・ロール, 15.8.2 組込みセキュリティ, 1.3.1

C

Javaオブジェクト・キャッシュ, 10.5

コールバックURL, 9.6.3.2

クラスタ・エージェント, 1.2

クラスタ, 1.2, 8.3

追加, 9.3, 10.2

サーバーの割当て, 9.3, 10.2

クラスタウェア, 1.2 Coherence

「Oracle Coherence」を参照

構成

データベース, 5.1

委任フォーム認証, 15.5.3.9

ディレクトリ構造, 4.1

ディスカッション・サーバー, 12.2

SOAHOST1上のドメイン, 8.3

フロントエンドHTTPホストとポート, 9.6.3

Oracleファイル/FTPアダプタの高可用性, 9.8.1

インスタント・メッセージおよびプレゼンス(IMP), 12.3

ネットワーク, 3

Oracle Coherence, 9.4

Oracle HTTP Server, 7.5, 8.7.1

WLS管理対象サーバーのOracle HTTP Server, 9.6.1, 10.11.1

ページレット・プロデューサ, 12.6

トランザクション・リカバリ用の永続ストア, 9.7

ポートレット・プロデューサ, 12.5

ドメイン構成の伝播, 13.19.2

Oracle Databaseアダプタのスケーリング, 9.8.3

共有JMS永続ストア, 9.3

共有ストレージ, 4.1, 4.4

サーバー移行のターゲット, 14.6

UMSドライバ, 16.3

カスタム・キーストアの使用, 11.3.4

OAM用のWebCenter Portal, 15.7

WebGate, 15.5.4

ワークフロー, 12.4

ワークリスト, 12.4

構成ウィザード, 8.3, 9.3, 10.2 configure-joc.pyスクリプト, 8.6, 10.5 構成

ロード・バランサ用のポート, 3.3

ロード・バランサ上の仮想サーバー名, 3.3

接続ファクトリのパラメータ, 9.8.1.1 接続

ディスカッション・サーバー, 12.2

インスタント・メッセージおよびプレゼンス(IMP), 12.3

ワークフロー, 12.4

ワークリスト, 12.4

コンテンツ・サーバー, 2.1.4

バックアップ, 13.13, 13.16

createCentralInventory.shスクリプト, 6.2.2, 6.3.2.1 アイデンティティ・キーストアの作成, 11.3.2 信頼キーストアの作成, 11.3.3 CUSTDBHOSTノード, 2.1.5, 5.2.1 カスタム・キーストア, 11.3.4

D

データ・ソース, 8.3, 14.3, A.2

データ層, 2.1.5

データベース

バックアップ, 5.6

CREATE_SERVICE, 5.3

ホストの要件, 5.2.1

初期化パラメータ, 5.2.3

リポジトリのロード, 5.4

mutexロック, 9.8.1.1

サービス, 5.3

設定, 5.2

サポートされているバージョン, 5.2.2

データベース・リスナー・ポート, 2.1.5 データベースの事前構成, 5.1 トランザクション・リカバリ用のデフォルト永続ストア, 9.7 委任フォーム認証, 15.5.3.9 ディレクトリ構造, 4.1, 4.3, 4.3.4, 4.3.5 ホスト名の検証の無効化, 8.4.8, 8.5.3, 9.5.1, 10.3.1 ディスカッション・サーバー, 12.2 DMZ, 1.3.1, 2.1.3, 2.1.4 ドメイン

バックアップ, 9.3, 10.2

SOAHOST1上での作成, 8.3

SOAコンポーネント用に拡張, 9, 9.3

WebCenter Portalコンポーネントのための拡張, 10, 10.2

ドメイン構成の伝播, 13.19.2

ドメイン構成

伝播, 8.5.1, 9.5.3, 9.5.5, 10.3.3, 10.4.1

ドメイン・ディレクトリ, 8.4.6 ドメイン・ディレクトリ, 4.2

E

SOAHOST1上でのADMINVHNの有効化, 8.2

エンタープライズ・デプロイメント, 1.1

バックアップとリカバリ, 16.6

トポロジ, 2.1

環境権限, 14.5 ドメインの拡張

SOAコンポーネント, 9, 9.3

WebCenter Portalコンポーネント, 10, 10.2

ドメインの拡張, WebCenter Contentコンポーネント, 13 外部通信, 1.3.1 外部サービス

ディスカッション・サーバー, 12.2

インスタント・メッセージおよびプレゼンス(IMP), 12.3

ページレット・プロデューサ, 12.6

ポートレット・プロデューサ, 12.5

ワークリスト, 12.4

EXTRA_JAVA_PROPERTIES, 15.7.1

F

フェイルバック, 1.2

フェイルオーバー, 1.2, 16.9.5

管理サーバーのフェイルオーバー, 8.7.6, 16.7, 16.7.3

ファイアウォール, 3.6

フロントエンドHTTPホストとポート, 9.6.3

管理コンソールのフロントエンドURL, 8.7.4

Fusion Middleware

「Oracle Fusion Middleware」を参照

G

generating self-signed certificates, 11.3.1

WebCenter Portal管理者ロールの付与, 15.7.2

グリッド・サーバー, 1.1

GridLinkデータ・ソース

構成, 10.2

構成の検証, 10.4.5, 13.8

H

ハードウェア・クラスタ, 1.2

ハードウェア要件, 2.2

高可用性, 1.1, 1.3.2, 9.4.1

Oracleファイル/FTPアダプタ, 9.8.1

ホーム・ページ、リダイレクト, 16.9.3, 16.9.7 ホスト識別子, 15.5.3.6 ホスト名, 9.4.2

ネットワーク, 1.2

物理, 1.2

仮想, 1.2

ホスト名の検証, 8.4.8, 8.5.3, 9.5.1, 10.3.1 HTTPポート, 2.1.3 httpd.conf, 7.6.1, 7.6.2 HTTPSポート, 2.1.3

I

IDアサータ, 15.5.6.2, 15.6.5.2

identity keystore, 11.3.2

ifconfig, 8.2

IMP

「インスタント・メッセージおよびプレゼンス(IMP)」を参照

Inbound Refinery

構成, 13.19.6

ドメインの拡張, 13.19

起動, 13.19.5

誤ったURL, 16.9.9 データベースの初期化パラメータ, 5.2.3 インストール

Oracle Fusion Middleware, 6.3.2.2

Oracle Fusion Middlewareのコンポーネント, 6.3.2

Oracle Fusion Middlewareホーム, 6.3

Oracle HTTP Server, 6.2.2

Oracle WebCenter Content, 6.3.2.1

Oracle WebLogic Server, 6.3.1

手順, 2.6

計画, 2.6.3

Web層の検証, 7.4

WebGate, 15.5.4

インストールするコンポーネント, 2.5

インスタント・メッセージおよびプレゼンス(IMP), 12.3 IP, 3.4, 3.4

J

Javaオブジェクト・キャッシュ, 10.5

JDK, 6.3.1

JMS永続ストア, 9.3

JRockit, 6.3.1

K

キーストア

カスタム, 11.3.4

アイデンティティ, 11.3.2

信頼, 11.3.3

keytoolユーティリティ, 11.3.3

L

LDAP

WebLogic管理者の移動, 15.2.2

leading.ddlスクリプト, 14.2 サーバー移行用のリース表, 14.2 リスニング・アドレス

WLS_WCC管理対象サーバー, 13.19.1

リスニング・ポート

WLS_WCC管理対象サーバー, 13.19.1

ロード・バランサ, 2.1.3, 7.6

ポートの構成, 3.3

仮想サーバー名の構成, 3.3

Oracle HTTP Serverを使用した構成, 7.5

要件, 2.1.3.1

アクセスの検証, 10.11.2

ディレクトリの場所, 4.3, 4.3.4, 4.3.5 ログイン画面、リダイレクト, 16.9.2

M

管理対象サーバー, 8.3, 8.4.6

追加, 9.3, 10.2

既存ノードへの追加, 16.4

既存のノードへの追加(WebCenter Content), 16.4.3, 16.5.3

新しいノードへの追加, 16.5

ドメイン変更の伝播, 9.5.3, 10.3.3

検証, 9.5.4, 9.5.7

WC_Collaboration, 10.4.4, 10.4.6, 10.4.7, 10.4.8, 10.11.1

WC_Portlet, 10.4.4, 10.4.6, 10.4.7, 10.4.8, 10.11.1

WC_Spaces, 10.4.4, 10.4.6, 10.4.7, 10.4.8, 10.11.1

WC_Utilities, 10.4.4, 10.4.6, 10.4.7, 10.4.8, 10.11.1

WebCenter Portal, 10.3.1

WLS_SOA, 9.5.1, 9.5.4, 9.5.7

WLS_WCC, 13.19.1

WLS_WSM, 8.4.1, 8.4.8, 8.4.9, 8.5.3, 8.5.5, 8.7.1

トポロジの管理, 16 手動フェイルオーバー, 16.9.5 管理サーバーの手動フェイルオーバー, 8.7.6, 16.7 IPとVIPのマッピング, 3.4, 3.4 ミドルウェア・ホーム, 1.2 サーバーの移行

「サーバー移行」も参照

トポロジの監視, 16.1 マルチデータ・ソース, 14.3 mutexロック, 9.8.1.1 MW_HOME, 4.2

N

仮想サーバーの名前, 3.2

httpd.confのNameVirtualHostエントリ, 7.6.1

ネットワーク

ファイアウォール, 3.6

IP, 3.4

ロード・バランサ, 3.3

ポート, 3.6

共有記憶域, 4.3.5

仮想IP (VIP), 3.4

仮想サーバー, 3.2

ネットワーク・ホスト名, 1.2 ネットワーク事前構成, 3 ノード・マネージャ

プロパティ・ファイル, 14.4

再起動, 9.5.2

設定, 11

SSL通信, 11.3

起動, 8.4.2, 8.5.4, 10.3.2, 10.4.3, 11.4, 13.5

カスタム・キーストアの使用, 11.3.4

ノード

サーバーの既存ノードへの追加, 16.4

既存の--へのサーバーの追加(WebCenter Content), 16.5.3

既存のへのサーバーの追加(WebCenter Content), 16.4.3

新規へのサーバーの追加, 16.5

アプリケーション層, 2.1.4

CUSTDBHOST, 2.1.5, 5.2.1

データ層, 2.1.5

1次, 1.2

2次, 1.2

SOAHOST, 8.2, 8.3, 8.4.1, 8.4.2, 8.5.4, 9.5.2, 10.3.2, 13.5

WCPHOST, 10.3.2, 10.4.3

Web層, 2.1.3

WEBHOST, 2.1.3, 6.2.2

O

OAM

「Oracle Access Manager (OAM)」を参照

OAMCFGツール, 16.9.9

概要, 15.5.3, 15.5.3.1

実行, 15.5.3.2

OAPポート, 2.1.4 OIDオーセンティケータ, 15.2.1 OIDポート, 2.1.5 OmniPortlet URL, 12.5 Oracle Access Manager, 2.1.3 Oracle Access Manager (OAM)

BPEL認証, 15.8

WebCenter Portalの構成, 15.7

委任フォーム認証, 15.5.3.9

IDアサータ, 15.5.6.2, 15.6.5.2

OAMCFGツール, 15.5.3, 15.5.3.1

プロバイダの順序, 15.5.6.3, 15.6.5.3

概要, 15.5.1, 15.6.1

前提条件, 15.5.2, 15.6.2

ホスト識別子の更新, 15.5.3.6

WebGateプロファイルの更新, 15.5.3.7

アクセス・ゲートの検証, 15.5.3.5

ポリシー・ドメインの検証, 15.5.3.5

WebGate, 15.5.4

WebLogicオーセンティケータ, 15.5.6, 15.6.5

Oracle Access Protocol (OAP), 2.1.3 Oracle Coherence, 9.4

ホスト名の指定, 9.4.2

Oracle Databaseアダプタ、スケーリング, 9.8.3 Oracleファイル/FTPアダプタ, 9.8.1 Oracle Fusion Middleware

インストール, 6.3.2.2

ホームのインストール, 6.3

Oracle WebLogic Serverのインストール, 6.3.1

Oracle Fusion Middleware構成ウィザード, 8.3 Oracle Fusion Middleware (FMW)

FMWコンポーネントのインストール, 6.3.2

Oracleホーム, 1.2 Oracle HTTP Server

バックアップ, 6.2.3

構成, 8.7.1

WLS管理対象サーバーの構成, 10.11.1

インストール, 6.2.2

登録, 8.7.3

アクセスの検証, 8.7.5, 9.6.2, 16.7.2

検証, 7.6

Oracle HTTP Server (OHS)

バックアップ, 6.2.3

構成, 7.5

ロード・バランサ, 7.5

ポート, 6.2.1

Oracleインスタンス, 1.2 Oracle Notification Service

構成, 10.2

構成の検証, 10.4.5, 13.8

Oracle SOA Suite

インストール, 6.3.2.1

Oracle WebCenter Content, 2.1.4

ポート, 3.6, 3.6, 3.6

Oracle WebCenter Portal

Analyticsの構成, 10.8

コレクタ・クラスタの構成, 10.8

WC_Spacesサーバーの構成, 10.8

Oracle WebLogic Server

インストール, 6.3.1

Oracle HTTP Serverの登録, 8.7.3

Oracle WebLogic Server管理コンソール, 14.3 ORACLE_BASE, 4.2 ORACLE_HOME, 4.2 ORACLE_INSTANCE, 4.2 oracleRoot.shスクリプト, 6.2.2

P

ページレット・プロデューサ, 12.6

接続ファクトリのパラメータ, 9.8.1.1

パフォーマンス、エンタープライズ・デプロイメント, 1.1

永続ストア

共有JMS, 9.3

トランザクション・リカバリ, 9.7

物理ホスト名, 1.2 物理IP, 1.2 ポリシー・ドメイン, 15.5.3.5 ポートレット・プロデューサ, 12.5 ポートレット, 16.9.6 ポート

ロード・バランサ向けの構成, 3.3

データベース・リスナー, 2.1.5

フロントエンドHTTP, 9.6.3

HTTP, 2.1.3

HTTPS, 2.1.3

Oracle HTTP Server, 6.2.1

Oracle Internet Directory (OID), 2.1.5

Oracle WebCenter Content, 3.6, 3.6, 3.6

トポロジでの使用, 3.6

事前構成

データベース, 5.1

ディレクトリ構造, 4.1

ネットワーク, 3

共有記憶域, 4.1

1次ノード, 1.2 データベースのPROCESSESパラメータ, 5.2.3 ドメイン変更の伝播, 9.5.3, 10.3.3 ドメイン構成の伝播, 8.5.1, 9.5.5, 10.4.1, 13.19.2 ノード・マネージャのプロパティ・ファイル, 14.4 OAMのプロバイダの順序, 15.5.6.3, 15.6.5.3

R

RACデータベース, 2.1.5, 8.3, A.2

エンタープライズ・デプロイメントのリカバリ, 16.6

ホーム・ページへのリダイレクト, 16.9.3, 16.9.7

ログイン画面へのリダイレクト, 16.9.2

参照トポロジ, 2.1

Oracle HTTP Serverの登録, 8.7.3

ページレット・プロデューサの登録, 12.6

ポートレット・プロデューサの登録, 12.5

リポジトリ作成ユーティリティ(RCU), 5.1, 5.4

要件

データベース・ホスト, 5.2.1

ロード・バランサ, 2.1.3.1

要件、ハードウェア, 2.2 再開

管理サーバー, 13.19.4

ノード・マネージャの再起動, 9.5.2

S

Oracle Databaseアダプタのスケーリング, 9.8.3

トポロジのスケール・アウト, 16.5

トポロジのスケール・アップ, 16.4

Oracle WebCenter Content, 16.4.3, 16.5.3

スクリプト

configure-joc.py, 8.6, 10.5

createCentralInventory.sh, 6.2.2, 6.3.2.1

leasing.ddl, 14.2

oracleRoot.sh, 6.2.2

setDomainEnv.sh, 15.7.1

setNMProps.sh, 8.4.2, 8.5.4

wlsifconfig.sh, 14.5, 14.5

2次ノード, 1.2 セキュリティ, 1.3.1 セキュリティ・フィルタ, 13.19.6.1 自己署名証明書, 11.3.1 サーバーの移行, 14

ターゲットの構成, 14.6

マルチデータ・ソースの作成, 14.3

ノード・マネージャのプロパティ・ファイルの編集, 14.4

リース表, 14.2

マルチデータ・ソース, 14.3

環境とスーパー・ユーザー権限の設定, 14.5

ユーザーと表領域の設定, 14.2

テスト, 14.7

管理コンソールからの検証, 14.7

サーバー, 8.3

クラスタへの割当て, 9.3, 10.2

マシンへの割当て, 9.3, 10.2

サービス・レベル合意, 1.1 setDomainEnv.shスクリプト, 15.7.1 setNMProps.shスクリプト, 8.4.2, 8.5.4 Javaオブジェクト・キャッシュの設定, 10.5 ノード・マネージャの設定, 11 WebLogicオーセンティケータの設定, 15.5.6, 15.6.5 共有JMS永続ストア, 9.3 共有記憶域, 1.2, 4.1, 4.3.5

構成, 4.4

SOAHOSTノード, 8.2, 8.3, 8.4.1, 8.4.2, 8.5.4, 9.5.2, 10.3.2, 13.5

Oracle SOA Suiteのインストール, 6.3.2.1

SOAHOST1VHn仮想ホスト, 9.4.1 SQLNet接続、タイムアウト, 16.8 SSLの高速化, 2.1.3.1 SSL通信, 11.3 SSOモード, 15.7.1 管理サーバーの起動, 8.4.3 ノード・マネージャの起動, 8.4.2, 8.5.4, 10.3.2, 10.4.3, 11.4, 13.5 WC_Collaboration管理対象サーバーの起動, 10.4.4, 10.4.7 WC_Portlet管理対象サーバーの起動, 10.4.4, 10.4.7 WC_Spaces管理対象サーバーの起動, 10.4.4, 10.4.7 WC_Utilities管理対象サーバーの起動, 10.4.4, 10.4.7 WLS_SOA管理対象サーバーの起動, 9.5.4, 9.5.7 WLS_WSM管理対象サーバーの起動, 8.4.9, 8.5.5 記憶域, 4.1, 4.3.5 インストールの計画, 2.6.3 スーパーユーザー権限, 14.5 サポートされているデータベース・バージョン, 5.2.2 スイッチバック, 1.2 スイッチオーバー, 1.2

T

ターゲット指定されるアプリケーション, 9.3

デプロイメントのターゲット設定, 8.3

サーバー移行のターゲット, 14.6

サーバー移行のテスト, 14.7

SQLNet接続のタイムアウト, 16.8

トポロジ, 2.1

アプリケーション層, 2.1.4

データ層, 2.1.5

データベース, 5.1

ディレクトリ構造, 4.1

管理, 16

監視, 16.1

ネットワーク, 3

スケール・アウト, 16.5

スケール・アップ, 16.4

スケール・アップ(Oracle WebCenter Content), 16.4.3, 16.5.3

共有記憶域, 4.1

Web層, 2.1.3

トランザクション・リカバリ, 9.7 トラブルシューティング

管理サーバーでの変更のアクティブ化, 16.9.1

誤ったURL, 16.9.9

手動フェイルオーバー, 16.9.5

使用不可のポートレット, 16.9.6

ホーム・ページへのリダイレクト, 16.9.3, 16.9.7

ログイン画面へのリダイレクト, 16.9.2

信頼キーストア, 11.3.3

U

UMSドライバ, 16.3

ユニキャスト通信, 2.1.6, 9.4

unpackユーティリティ, 8.5.1, 9.5.5, 10.4.1

ホスト識別子の更新, 15.5.3.6

WebGateプロファイルの更新, 15.5.3.7

URL, コールバック, 9.6.3.2

utils.CertGenユーティリティ, 11.3.1

utils.ImportPrivateKeyユーティリティ, 11.3.2

V

検証

ロード・バランサを使用したアクセス, 10.11.2

Oracle HTTP Serverを使用したアクセス, 8.7.5, 9.6.2, 16.7.2

管理サーバー, 8.4.5

Oracle HTTP Server, 7.6

サーバーの移行, 14.7

WC_Collaboration管理対象サーバー, 10.4.6, 10.4.8

WC_Portlet管理対象サーバー, 10.4.6, 10.4.8

WC_Spaces管理対象サーバー, 10.4.6, 10.4.8

WC_Utilities管理対象サーバー, 10.4.6, 10.4.8

Web層のインストール, 7.4

WLS_SOA管理対象サーバー, 9.5.4, 9.5.7

WLS_WSM管理対象サーバー, 8.4.9, 8.5.5, 9.5.4

ホスト名の検証, 8.4.8, 8.5.3, 9.5.1, 10.3.1 VIP, 3.4, 3.4

SOAHOST1上でのADMINVHNの有効化, 8.2

仮想ホスト名, 1.2 仮想IP, 1.2, 1.2 仮想IP (VIP), 3.4, 3.4 仮想サーバー名, 3.2 仮想サーバー, 2.1.3.1

admin.example.com, 3.2.2

wcp.example.com, 3.2.1

VirtualHostディレクティブ, 7.6.2 httpd.confの<VirtualHost>エントリ, 7.6.2

W

WC_Collaboration管理対象サーバー, 10.4.4, 10.4.6, 10.4.7, 10.4.8, 10.11.1

WC_Portlet管理対象サーバー, 10.4.4, 10.4.6, 10.4.7, 10.4.8, 10.11.1

WC_Spaces管理対象サーバー, 10.4.4, 10.4.6, 10.4.7, 10.4.8, 10.11.1

WC_Utilities管理対象サーバー, 10.4.4, 10.4.6, 10.4.7, 10.4.8, 10.11.1

wcp_vh.conf, 7.6.2

wcp_vh.confファイル, 9.6.1, 10.11.1, 13.14

wcp.example.com, 3.2.1

WCPHOST

ドメイン構成の伝播, 13.19.2

WCPHOSTノード, 10.3.2, 10.4.3 wcpinternal_vh.conf, 7.6.2 wcpinternal_vh.confファイル, 8.7.1, 10.11.1 Web層, 2.1.3

インストールの検証, 7.4

WebCenter Portal

管理者ロール, 15.7.2

認証, 15.8

OAM用のアプリケーションの構成, 15.7

ホスト名検証の無効化, 10.3.1

ディスカッション・サーバー, 12.2

ドメインの拡張, 10, 10.2

Oracle Fusion Middlewareのインストール, 6.3.2.2

Javaオブジェクト・キャッシュ, 10.5

ポートレット・プロデューサ, 12.5.1

SSOモード, 15.7.1

ワークフロー, 12.4.2

ワークリスト, 12.4.2

WebClipping URL, 12.5 WebGate, 2.1.3, 15.5.4 WebGateプロファイル, 15.5.3.7 WEBHOST

ロード・バランサとOHSの構成 7.5

Web層の構成, 7.3

WEBHOSTノード, 2.1.3, 6.2.2 WebLogic管理者、LDAPへの移動, 15.2.2 WebLogicオーセンティケータ, 15.5.6, 15.6.5 WebLogic構成ウィザード, 8.3 WebLogic Scripting Tool (WLST)

ディスカッション・サーバー, 12.2.2

ポートレット・プロデューサ, 12.5.2

ワークフロー, 12.4.3

ワークリスト, 12.4.3

WebLogic Server

「Oracle WebLogic Server」を参照

WebLogic Serverホーム, 1.2 WL_HOME, 4.2 WLS_SOA

ホスト名検証の無効化, 9.5.1

WLS_WCC管理対象サーバー, 13.19.1 WLS_WSM, 8.4.1, 8.7.1, 8.7.1

ホスト名検証の無効化, 8.4.8, 8.5.3

起動, 8.4.9、8.5.5

検証, 8.4.9, 8.5.5

wlsifconfig.shスクリプト, 14.5, 14.5 WLST

「WebLogic Scripting Tool」を参照

ワークフロー, 12.4 ワークリスト, 12.4

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。