Oracle® Fusion Middleware

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

リリース12.2.1.2

E85892-01(原本部品番号:E78276-01)

2016年12月

このドキュメントは、管理者を対象に、エンタープライズ・デプロイメントにおけるOracle Fusion Middlewareコンポーネントのインストールおよび構成方法について説明しています。

Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド, リリース12.2.1.2

E85892-01

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

原本著者: Chuck Boucher (MAAエンジニア)、Frank Rizzo (MAAエンジニア)、Melwyn Paul (ライター)、Abirami Sekar (QA)

原本協力著者: Peter LaQuerre

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

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

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

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社およびその関連会社は一切の責任を負いかねます。

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の登録商標です。

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

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- 表記規則

第I部 エンタープライズ・デプロイメントの理解

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

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

- 1.2 エンタープライズ・デプロイメント・ガイドを使用するケース

2 標準的なエンタープライズ・デプロイメントについて

- 2.1 標準的なエンタープライズ・デプロイメントのダイアグラム

- 2.2 標準的なエンタープライズ・デプロイメント・トポロジのダイアグラムについて

- 2.2.1 標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解

- 2.2.2 標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解

- 2.2.3 ハードウェア・ロード・バランサを介したリクエストの受信

- 2.2.3.1 ハードウェア・ロード・バランサ(LBR)の目的

- 2.2.3.1.1 インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト

- 2.2.3.1.2 アプリケーション層のコンポーネント間特有の内部専用通信

- 2.2.3.2 標準的なロード・バランサの仮想サーバー名のサマリー

- 2.2.3.3 外部仮想サーバー名に対するHTTPSリクエストとHTTPリクエストの対比

- 2.2.4 Web層の理解

- 2.2.4.1 リクエストのルーティングにOracle HTTP Serverを使用する利点

- 2.2.4.2 Web層でのOracle HTTP Serverの使用にかわる方法

- 2.2.4.3 Web層でのOracle HTTP Serverの構成

- 2.2.4.4 Mod_WL_OHSについて

- 2.2.5 アプリケーション層の理解

- 2.2.5.1 管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

- 2.2.5.2 アプリケーション層でのOracle Web Services Managerの使用

- 2.2.5.3 アプリケーション層におけるクラスタとホストの構成のベスト・プラクティスとバリエーション

- 2.2.5.4 標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

- 2.2.5.5 アプリケーション層内での通信のためのユニキャストの使用について

- 2.2.5.6 OPSSおよび認証ストアと認可ストアへのリクエストの理解

- 2.2.6 標準的なエンタープライズ・デプロイメントでのCoherenceクラスタについて

- 2.2.7 データ層について

3 WebCenter Portalエンタープライズ・デプロイメント・トポロジの理解

- 3.1 WebCenter Portalエンタープライズ・デプロイメント・トポロジのダイアグラム

- 3.2 プライマリWebCenter Portalトポロジのダイアグラムの理解

- 3.2.1 WebCenter Portalロード・バランサ仮想サーバー名のサマリー

- 3.2.2 WebCenter Portalアプリケーション層の管理対象サーバーとクラスタのサマリー

- 3.3 プライマリWebCenter Portalエンタープライズ・トポロジを実装するためのフロー・チャートとロードマップ

- 3.3.1 WebCenter Portalエンタープライズ・トポロジをインストールおよび構成する手順のフロー・チャート

- 3.3.2 エンタープライズ・デプロイメントの計画と準備のためのロードマップ表

- 3.3.3 Oracle WebCenter Portalトポロジの構成のためのロードマップ表

第II部 エンタープライズ・デプロイメントの準備

4 エンタープライズ・デプロイメント・ワークブックの使用

- 4.1 エンタープライズ・デプロイメント・ワークブックの概要

- 4.2 ワークブックの標準的なユース・ケース

- 4.3 Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの使用

- 4.3.1 Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの場所

- 4.3.2 Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの内容の理解

- 4.3.2.1 スタート・タブの使用

- 4.3.2.2 ハードウェア - ホスト・コンピュータ・タブの使用

- 4.3.2.3 ネットワーク - 仮想ホストとポート・タブの使用

- 4.3.2.4 ストレージ - ディレクトリ変数タブの使用

- 4.3.2.5 「データベース - 接続の詳細」タブの使用

- 4.4 エンタープライズ・デプロイメント・ワークブックの使用対象者

5 エンタープライズ・デプロイメント用のリソースの取得

- 5.1 エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件

- 5.1.1 ハードウェア・ロード・バランサの要件

- 5.1.2 ホスト・コンピュータのハードウェア要件

- 5.1.2.1 エンタープライズ・デプロイメントのホスト・コンピュータに関する一般的な考慮事項

- 5.1.2.2 Oracle Fusion Middlewareシステム要件の確認

- 5.1.2.3 エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタおよびプロセス数

- 5.1.2.4 エンタープライズ・デプロイメントの標準的なディスク領域要件

- 5.1.3 エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件

- 5.2 エンタープライズ・デプロイメント用の必須IPアドレスの予約

- 5.2.1 仮想IP (VIP)アドレスとは

- 5.2.2 仮想ホスト名と仮想IPアドレスを使用する理由

- 5.2.3 エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス

- 5.3 エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得

6 エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

- 6.1 ハードウェア・ロード・バランサでの仮想ホストの構成

- 6.1.1 ハードウェア・ロード・バランサ構成の概要

- 6.1.2 ハードウェア・ロード・バランサの構成の一般的な手順

- 6.1.3 エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー

- 6.1.4 admin.example.comに関する追加手順

- 6.1.5 wcp.example.comに関する追加手順

- 6.1.6 wcpinternal.example.comに関する追加手順

- 6.2 エンタープライズ・デプロイメントのファイアウォールとポートの構成

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

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

- 7.2 エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項

- 7.3 エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解

- 7.4 このガイドで使用するファイル・システムとディレクトリ変数

- 7.5 エンタープライズ・デプロイメント用のディレクトリの作成およびマウントについて

- 7.6 エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー

8 エンタープライズ・デプロイメント用のホスト・コンピュータの準備

- 8.1 各ホストの最小ハードウェア要件の検証

- 8.2 Linuxオペレーティング・システムの要件の検証

- 8.2.1 Linuxのカーネル・パラメータの設定

- 8.2.2 UNIXシステムでのオープン・ファイル制限とプロセス数の設定

- 8.2.2.1 現在開いているファイル数の表示

- 8.2.2.2 オペレーティング・システムのオープン・ファイルおよびプロセス制限の設定

- 8.2.3 DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認

- 8.3 オペレーティング・システムのユーザーおよびグループの構成

- 8.4 Unicodeサポートの有効化

- 8.5 各ホストへの必要な共有ファイル・システムのマウント

- 8.6 各ホストでの必要な仮想IPアドレスの有効化

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

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

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

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

- 9.2.2 その他のデータベース・ソフトウェア要件

- 9.2.3 Oracle Textのインストールと検証

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

- 9.4 Oracleデータベースでのラージ・オブジェクト(LOB)に対するSecureFilesの使用

- 9.5 データベース・バックアップ戦略について

第III部 エンタープライズ・デプロイメントの構成

10 エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

- 10.1 インフラストラクチャ・ドメインの作成時に使用する変数

- 10.2 初期インフラストラクチャ・ドメインについて

- 10.2.1 インフラストラクチャ・ディストリビューションについて

- 10.2.2 ドメインの特徴

- 10.3 WCCHOST1へのOracle Fusion Middleware Infrastructureのインストール

- 10.3.1 サポートされているJDKのインストール

- 10.3.1.1 JDKソフトウェアの検索とダウンロード

- 10.3.1.2 JDKソフトウェアのインストール

- 10.3.2 WCCHOST1でのインフラストラクチャ・インストーラの起動

- 10.3.3 Infrastructureインストール画面のナビゲート

- 10.3.4 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

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

- 10.4 データベース・スキーマの作成

- 10.4.1 動作保証されたデータベースのインストールおよび構成

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

- 10.4.3 RCU画面からスキーマ作成へのナビゲート

- 10.5 Infrastructureドメインの構成

- 10.5.1 構成ウィザードの起動

- 10.5.2 Infrastructureドメインを構成するための構成ウィザード画面のナビゲート

- 10.5.2.1 静的クラスタを含めるドメインの作成

- 10.6 WCCHOST1でのドメイン・ディレクトリの構成とサーバーの起動

- 10.6.1 WCCHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動

- 10.6.2 boot.propertiesファイルの作成

- 10.6.3 ノード・マネージャを使用した管理サーバーの起動

- 10.6.4 管理サーバーの検証

- 10.6.5 Derbyデータベースの無効化

- 10.6.6 WCCHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成

- 10.6.7 WCCHOST1の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

- 10.6.8 WCCHOST1でのWLS_WSM1管理対象サーバーの起動と検証

- 10.7 WCCHOST2でのドメインの伝播とサーバーの起動

- 10.7.1 WCCHOST2でのドメイン構成の解凍

- 10.7.2 WCCHOST2の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

- 10.7.3 WCCHOST2でのWLS_WSM2管理対象サーバーの起動と検証

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

- 10.9 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング

- 10.9.1 サポートされている認証プロバイダについて

- 10.9.2 エンタープライズ・デプロイメントのユーザーおよびグループについて

- 10.9.2.1各ドメインで一意の管理ユーザーの使用について

- 10.9.2.2 ドメイン・コネクタ・ユーザーについて

- 10.9.2.3 集中管理型LDAPディレクトリへのユーザーの追加について

- 10.9.2.4 Oracle WebCenter Portalの製品固有のロールとグループについて

- 10.9.2.5 このガイドで使用するサンプル・ユーザーとサンプル・ロール

- 10.9.3 新しい認証プロバイダの作成と新しいユーザーおよびグループのプロビジョニングの前提条件

- 10.9.4 LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

- 10.9.5 新しい認証プロバイダの作成

- 10.9.6 エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

- 10.9.7 管理グループへの新しい管理ユーザーの追加

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

- 10.10 Administratorsグループへのwsm-pmロールの追加

- 10.11 WebLogicプロキシ・プラグインの構成

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

- 11.1 Web層の構成時に使用される変数

- 11.2 Web層ドメインについて

- 11.3 WEBHOST1へのOracle HTTP Serverのインストール

- 11.3.1 WEBHOST1でのインストーラの起動

- 11.3.2 Oracle HTTP Serverのインストール画面のナビゲート

- 11.3.3 Oracle HTTP Serverインストールの確認

- 11.4 WEBHOST1でのWeb層ドメインの作成

- 11.4.1 WEBHOST1での構成ウィザードの起動

- 11.4.2 Oracle HTTP Serverドメインの構成ウィザード画面のナビゲート

- 11.5 WEBHOST2でのWeb層ドメインのインストールおよび構成

- 11.6 WEBHOST1およびWEBHOST2でのノード・マネージャおよびOracle HTTP Serverインスタンスの起動

- 11.6.1 WEBHOST1およびWEBHOST2でのノード・マネージャの起動

- 11.6.2 Oracle HTTP Serverインスタンスの起動

- 11.7 アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成

- 11.7.1 エンタープライズ・デプロイメント用のOracle HTTP Server構成について

- 11.7.1.1Oracle HTTP Server仮想ホストの目的

- 11.7.1.2 <VirtualHost>ディレクティブのWebLogicClusterパラメータについて

- 11.7.1.3 Oracle HTTP Server構成ファイルの推奨構造

- 11.7.2 仮想ホスト構成ファイルを追加するためのhttpd.confファイルの変更

- 11.7.3 仮想ホスト構成ファイルの作成

- 11.7.4 ロード・バランサでの仮想サーバー構成の検証

- 11.7.5 管理サーバーおよびOracle Web Services Managerへのルーティングの構成

- 11.7.6 管理コンソールおよび管理サーバーへのアクセスの検証

- 11.7.7 Oracle Web Services Policy Managerへのアクセスの検証

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

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

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

- 12.1.2 インストール画面のナビゲート

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

- 12.1.4 インストールの検証

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

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

- 12.1.4.3 Oracleホームの内容の表示

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

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

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

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

- 12.3.1 構成ウィザードの起動

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

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

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

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

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

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

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

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

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

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

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

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

- 12.4.10 GridLinkデータ・ソースの検証

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

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

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

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

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

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

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

- 12.5.2 WebLogicプロキシ・プラグインの構成

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

- 12.5.3.1 URLの検証

- 12.5.3.2 クラスタ・ノードの検証

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

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

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

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

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

- 13.1 Inbound Refineryを使用するためのドメインの拡張

- 13.1.1 構成ウィザードの起動

- 13.1.2 ドメインを拡張するために構成ウィザード画面へ移動

- 13.2 Inbound Refinery用の構成後タスクおよび検証タスクの実行

- 13.2.1 Inbound Refineryのドメイン構成の更新の伝搬

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

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

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

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

- 13.3 Inbound Refinery管理対象サーバーの構成

- 13.3.1 Inbound Refineryの設定の構成

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

- 13.3.3 フォント・パスの指定

- 13.3.4 Inbound Refineryにジョブを送信して変換するためのコンテンツ・サーバーの設定

- 13.3.4.1 送信プロバイダの作成

- 13.3.4.2 コンテンツ・サーバーでのInbound Refinery用のコンポーネントの有効化

- 13.3.4.3 変換するファイル形式の選択

- 13.4 Inbound Refinery管理対象サーバーの構成の検証

14 Oracle SOA Suiteを含めるドメインの拡張

- 14.1 Oracle SOA Suiteの構成時に使用する変数

- 14.2 システム・クロックの同期

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

- 14.3.1 WCCHOST1でのOracle SOA Suiteインストーラの起動

- 14.3.2 インストール画面のナビゲート

- 14.3.3 インストールの検証

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

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

- 14.3.3.3 Oracleホームの内容の表示

- 14.3.4 他のホスト・コンピュータへのOracle SOA Suiteのインストール

- 14.4 Oracle SOA Suiteデータベース・スキーマの作成

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

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

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

- 14.5 Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張

- 14.5.1 構成ウィザードの起動

- 14.5.2 Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

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

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

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

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

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

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

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

- 14.11 WLS_SOA1管理対象サーバーの起動および検証

- 14.11.1 管理対象サーバーWLS_SOA1の起動

- 14.11.2 AdministratorsグループへのSOAAdminロールの追加

- 14.11.3 SOAインフラストラクチャへのログインによる管理対象サーバーの検証

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

- 14.13 トランザクション・ログの場所と作成の検証

- 14.14 拡張したドメイン用のOracle HTTP Serverの構成

- 14.14.1 Oracle WebCenter Portalエンタープライズ・デプロイメントにおけるSOAのためのOracle HTTP Serverの構成

- 14.14.2 WebLogicプロキシ・プラグインの構成

- 14.14.3 ロード・バランサを使用したOracle SOA Suite URLの検証

- 14.15 Oracle SOA Suiteの構成後手順

- 14.15.1 SOAサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

- 14.15.2 SOAクラスタ内の同期/非同期相互作用に関する考慮事項

- 14.15.3 適切なタスク表示のためのワークフロー・フロント・エンド・アドレスの更新

- 14.16 Oracle SOA Suiteに対する自動サービス移行およびJDBC永続ストアの有効化

15 Oracle WebCenter Portalを含めるドメインの拡張

- 15.1 WebCenter Portalのためのドメイン拡張時に使用する変数

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

- 15.2.1 WCCHOST1でのOracle WebCenter Portalインストーラの起動

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

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

- 15.3 Oracle WebCenter Portalデータベース・スキーマの作成

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

- 15.3.2 RCU画面からスキーマ作成へのナビゲート

- 15.4 Oracle WebCenter Portalを含めるエンタープライズ・デプロイメント・ドメインの拡張

- 15.4.1 構成ウィザードの起動

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

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

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

- 15.6 ドメイン解凍後のsetDomainEnv.shへのカスタマイズのリストア

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

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

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

- 15.10 WCPHOST1でのノード・マネージャの起動

- 15.11 WCPHOST2でのノード・マネージャの起動

- 15.12 WC_Portal1、WC_Portlet1、WC_Collaboration1管理対象サーバーの起動と検証

- 15.12.1 WCPHOST1での管理対象サーバーの起動

- 15.12.2 WCPHOST1でのWebCenter Portalの検証

- 15.12.3 ポータル管理者グループへのWCPAdminロールの追加

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

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

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

- 15.12.4 WCPHOST2での管理対象サーバーの起動と検証

- 15.13 分析の構成

- 15.13.1 WebCenter Portalのデフォルトの分析接続の登録

- 15.13.2 スケールアップに対応するための分析の構成

- 15.13.2.1 分析コレクタのポート範囲の構成

- 15.13.2.2 WebCenter Portalでの分析コレクタの追加登録

- 15.13.2.3 ポータルのデフォルト分析登録のフェイルオーバー

- 15.14 REST APIの構成

- 15.15 拡張したドメイン用のOracle HTTP Serverの構成

- 15.15.1 Oracle WebCenter Portalクラスタ用のOracle HTTP Serverの構成

- 15.15.2 WebLogicプロキシ・プラグインの構成

- 15.15.3 ロード・バランサによるOracle WebCenter Portalパブリック・サービスURLの検証

- 15.15.4 内部WebCenterサービス用のHTTPサーバーの構成

- 15.15.5 ロード・バランサによるOracle WebCenter Portal内部サービスURLの検証

- 15.16 外部サービス用のWebCenter Portalの構成

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

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

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

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

- 15.16.3 コンテンツ・サーバーの接続の構成

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

- 15.16.3.2 高可用性のためのWebCenter Portal Content Manager MBeanの構成

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

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

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

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

- 15.16.5.1 Fusion Middleware Controlを使用したページレット・プロデューサの登録

- 15.16.5.2 WLSTを使用したページレット・プロデューサの登録

- 15.16.6 検索サービスの構成

- 15.16.7 SMTPメール・サーバー用のOracle WebCenter Portal通知の構成

- 15.16.7.1 Fusion Middleware Controlを使用したメール・サーバーの登録

- 15.16.7.2 WLSTを使用したメール・サーバーの登録

16 同一ドメイン内でのWebCenter PortalワークフローのOracle SOA Suiteとの統合

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

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

- 16.3 Oracle WebCenter Portal SOAコンポジットのインストール

- 16.3.1 WCCHOST1でのOracle WebCenter Portalインストーラの起動

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

- 16.3.3 インストールしたファイルの確認

- 16.3.4 WCCHOST2でのインストールの実行

- 16.4 WebCenter Portalワークフローをデプロイするためのドメインの拡張

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

- 16.6 ドメイン解凍後のsetDomainEnv.shへのカスタマイズのリストア

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

- 16.8 ドメインの起動およびWebCenter Portal SOAコンポジットのためのドメイン拡張の検証

- 16.8.1 ノード・マネージャを使用した管理サーバーの起動

- 16.8.2 すべての管理対象サーバーの起動と稼働の確認

- 16.8.3 WebCenter Portal SOAコンポジットのデプロイメントの確認

- 16.8.3.1 WebCenter Portal SOAコンポジットおよびアプリケーションのデプロイメントの確認

- 16.8.3.2 SOA_ClusterへのWebCenterWorklistDetailAppアプリケーションのデプロイ

- 16.8.3.3 SOAサービスへのCommunityWorkflows SOAコンポジットのデプロイ

- 16.9 Oracle SOAおよびWebCenter PortalのためのWS-Securityの構成

- 16.9.1 WLSTによるWebCenter Portalキーストアの作成

- 16.10 アプリケーション・ロールの確認

- 16.11 BPELサーバーへの接続の作成

- 16.12 BPELサーバーへの接続の検証

- 16.13 電子メールで送信するためのWebCenter Portalワークフロー通知の構成

- 16.14 WebCenter PortalでのOracle BPM Worklistアプリケーションのテスト

第IV部 エンタープライズ・デプロイメントの共通の構成および管理手順

17 エンタープライズ・デプロイメントの共通の構成および管理タスク

- 17.1 管理サーバーの手動フェイルオーバーの確認

- 17.1.1 別のホストへの管理サーバーのフェイルオーバー

- 17.1.2 Oracle HTTP Serverを介したWCCHOST2上の管理サーバーへのアクセスの検証

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

- 17.2 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

- 17.2.1 中間層とロード・バランサ間のSSL通信が必要になるとき

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

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

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

- 17.2.5 トラスト・ストアへのロード・バランサ証明書のインポート

- 17.2.6 Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

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

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

- 17.2.9 SSLエンドポイントを使用したコンポジットのテスト

- 17.3 エンタープライズ・デプロイメントの管理用のロールの構成

- 17.3.1 特定の管理ロールを持つ製品のサマリー

- 17.3.2 エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加

- 17.4 エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用

- 17.4.1 JMSおよびTLOGのためのJDBC永続ストアについて

- 17.4.2 JMS永続ストアとTLOGを使用する製品およびコンポーネント

- 17.4.3 TLOGおよびJMS永続ストアのパフォーマンスへの影響

- 17.4.4 TLOG用のJDBC永続ストア構成のロードマップ

- 17.4.5 JMS用のJDBC永続ストア構成のロードマップ

- 17.4.6 TLOGのユーザーと表領域の作成

- 17.4.7 JMSのユーザーと表領域の作成

- 17.4.8 TLOGおよびJMSストアのGridLinkデータ・ソースの作成

- 17.4.9 管理対象サーバーへのTLOG JDBCストアの割当て

- 17.4.10 JDBC JMSストアの作成

- 17.4.11 JMSサーバーへのJMS JDBCストアの割当て

- 17.4.12 JMS JDBCストアで必要な表の作成

- 17.5 エンタープライズ・デプロイメントのバックアップとリカバリの実行

18 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

- 18.1 エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について

- 18.1.1 サーバー全体の移行とサービスの移行の違いの理解

- 18.1.2 エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

- 18.1.3 サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

- 18.2 リース用のGridLinkデータ・ソースの作成

- 18.3 エンタープライズ・デプロイメントでのサーバー全体の移行の構成

- 18.3.1 ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

- 18.3.2 wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定

- 18.3.2.1 wlsifconfig.shスクリプトのPATH環境変数の設定

- 18.3.2.2 wlsifconfig.shスクリプトに対する権限の付与

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

- 18.3.4 サーバー全体の移行のテスト

- 18.4 エンタープライズ・デプロイメントでの自動サービス移行の構成

- 18.4.1 エンタープライズ・デプロイメント・クラスタでのリース・メカニズムとデータ・ソースの設定

- 18.4.2 クラスタ内の管理対象サーバーの移行設定の変更

- 18.4.3 サービス移行ポリシーの選択について

- 18.4.4 クラスタ内の各管理対象サーバーでのサービス移行ポリシーの設定

- 18.4.5 自動サービス移行の検証

- 18.4.6 自動サービス移行後のサービスのフェイルバック

19 エンタープライズ・デプロイメント用のシングル・サインオンの構成

- 19.1 Oracle HTTP Server Webゲートについて

- 19.2 Oracle HTTP Server Webゲートの構成の一般的な前提条件

- 19.3 OHS 12c Webgateを構成するためのエンタープライズ・デプロイメントの前提条件

- 19.4 エンタープライズ・デプロイメントでのOracle HTTP Server 12c WebGateの構成

- 19.5 Oracle Access ManagerへのOracle HTTP Server Webゲートの登録

- 19.5.1 RREGインバンドおよびアウトオブバンド・モードについて

- 19.5.2 OAM11gRequest.xmlファイルでの標準プロパティの更新

- 19.5.3 エンタープライズ・デプロイメント用の保護されたリソース、パブリック・リソースおよび除外されたリソースの更新

- 19.5.4 RREGツールの実行

- 19.5.4.1 RREGツールをインバンド・モードで実行

- 19.5.4.2 RREGツールをアウトオブバンド・モードで実行

- 19.5.5 RREGによって生成されるファイルおよびアーティファクト

- 19.5.6 生成済アーティファクトのOracle HTTP Server WebGateインスタンスの場所へのコピー

- 19.5.7 Oracle HTTP ServerインスタンスでのMD5証明書の署名の有効化

- 19.5.8 Oracle HTTP Serverインスタンスの再起動

- 19.6 WebLogic Server認証プロバイダの設定

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

- 19.6.2 Oracle Access Manager IDアサーション・プロバイダの設定

- 19.6.3 デフォルト・オーセンティケータの更新およびプロバイダ順序の設定

- 19.7 Oracle Access Managerを使用したOracle ADFおよびOPSSセキュリティの構成

- 19.8 追加のシングル・サインオン構成

- 19.8.1 SSO用のWebCenter Portalの構成

- 19.8.2 SSO用のディスカッション・サーバーの構成

- 19.8.3 WebCenter Portal RESTインタフェース用のOAMポリシーの構成

- 19.8.4 外部リーダーを使用したRSSフィード用のOAMの構成

- 19.8.5 OAM 11g用のWebLogic Server管理コンソールとEnterprise Managerの構成

- 19.8.6 SSO用のSecure Enterprise Searchの構成

- 19.8.7 SSO用のContent Serverの構成

- 19.8.8 接続フィルタを使用したアクセスの制限

- 19.8.9 ポートレット・プロデューサと追加コンポーネントの構成

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

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

- A.2 エンタープライズ・デプロイメントでマルチ・データ・ソースを構成するための標準的な手順

はじめに

このガイドでは、可用性の高いOracle Fusion Middlewareエンタープライズ・デプロイメントのインストール、構成および管理方法について説明します。詳細は、「エンタープライズ・デプロイメント・ガイドについて」を参照してください。

- 対象読者

- 表記規則

対象読者

一般に、このドキュメントは、本番デプロイメント用にOracle Fusion Middlewareソフトウェアをインストールして構成するタスクを割り当てられている、Oracle Fusion Middlewareの管理者を対象としています。

データベース管理者(DBA)やネットワーク管理者など、より専門的な管理者に特定のタスクを割り当てることも可能です(該当する場合)。

親トピック: はじめに

表記規則

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

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

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

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

注意:

このガイドでは、Oracle Linuxシステムにおけるエンタープライズ・デプロイメント参照用トポロジの実装を中心に取り上げています。

このトポロジは、動作保証済でサポートされている任意のオペレーティング・システムで実装可能ですが、このガイドの例には、多くの場合、Oracle Linux上でbashシェルを使用して実行する必要があるコマンドと構成手順が示されています。

親トピック: はじめに

第I部 エンタープライズ・デプロイメントの理解

Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジを構成する前に、標準的なエンタープライズ・デプロイメントの概念および全般的な特徴を理解することは重要です。

エンタープライズ・デプロイメント・ガイドのこの部には、次のトピックが含まれています。

- エンタープライズ・デプロイメントの概要
エンタープライズ・デプロイメント・ガイドは、選択したOracle Fusion Middleware製品に対してマルチホスト型でセキュアかつ高可用性の本番トポロジを計画、準備、インストールおよび構成する際に役立つ、詳細かつ検証済の手順を提供します。

- 標準的なエンタープライズ・デプロイメントについて
標準的なエンタープライズ・デプロイメント・トポロジのコンポーネントを理解することはきわめて重要です。

- WebCenter Portalエンタープライズ・デプロイメント・トポロジの理解
この章では、WebCenter Portalデプロイメント・トポロジについて説明します。これらのトポロジは、「標準的なエンタープライズ・デプロイメントの理解」で説明した概念の具体的な参照用実装です。

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

エンタープライズ・デプロイメント・ガイドは、選択したOracle Fusion Middleware製品に対してマルチホスト型でセキュアな可用性の高い本番トポロジを計画、準備、インストールおよび構成する際に役立つ、詳細かつ検証済の手順を提供します。

この章ではOracle Fusion Middlewareエンタープライズ・デプロイメントの概念を説明します。また、エンタープライズ・デプロイメント・ガイドを使用する時期についても取り上げます。

- エンタープライズ・デプロイメント・ガイドについて
エンタープライズ・デプロイメント・ガイドは、選択したOracle Fusion Middleware製品のセキュアかつ高可用性の本番品質デプロイメントをインストール、構成および保守するための包括的でスケーラブルな例を提供します。この結果として作成される環境をエンタープライズ・デプロイメント・トポロジと呼びます。

- エンタープライズ・デプロイメント・ガイドを使用するケース
このガイドでは、Oracle Fusion Middlewareの主な3つのインストールおよび構成オプションのうち1つについて説明します。このガイドを使用すると、選択したOracle Fusion Middleware製品のマルチホスト型でセキュアかつ高可用性の本番トポロジを計画、準備、インストールおよび構成できます。

親トピック: エンタープライズ・デプロイメントの理解

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

エンタープライズ・デプロイメント・ガイドは、選択したOracle Fusion Middleware製品のセキュアかつ高可用性の本番品質デプロイメントをインストール、構成および保守するための包括的でスケーラブルな例を提供します。この結果として作成される環境をエンタープライズ・デプロイメント・トポロジと呼びます。

エンタープライズ・デプロイメント・トポロジは、類似のOracle Fusion Middleware環境を各組織に実装するときに使用できる主な概念やベスト・プラクティスを、例を通じて紹介します。

各エンタープライズ・デプロイメント・ガイドには、参照用トポロジを実装するための詳細な検証済手順が記載されています。また、Oracle Fusion Middlewareエンタープライズ・デプロイメントの概念、参考資料および追加オプションについて説明しているサポート・ドキュメントへのリンクも用意されています。

エンタープライズ・デプロイメント・ガイドに記述されているエンタープライズ・デプロイメント・トポロジは、Oracleをご使用のすべてのお客様の要件を完全に満たすものではありません。場合によっては、トポロジのバリエーションがオラクル社によって文書化されサポートされているどうかに応じて、このガイドで説明されている以外の代替手順も検討できます。

エンタープライズ・デプロイメント・ガイドをデプロイメントの第1選択肢として使用することをお薦めします。バリエーションが必要な場合は、関連するOracleドキュメントを確認するか、Oracleサポートと共同でそれらのバリエーションを検証する必要があります。

1.2 エンタープライズ・デプロイメント・ガイドを使用するケース

このガイドでは、Oracle Fusion Middlewareの主な3つのインストールおよび構成オプションのうち1つについて説明します。このガイドを使用すると、選択したOracle Fusion Middleware製品のマルチホスト型でセキュアかつ高可用性の本番トポロジを計画、準備、インストールおよび構成できます。

または次の方法を使用できます。

- 各製品のインストレーション・ガイドを使用して、選択した一連のOracle Fusion Middleware製品の標準インストール・トポロジをインストールおよび構成する。
標準インストール・トポロジは評価用として単一ホストにインストールできますが、より複雑な本番環境にスケール・アウトするための開始点にもなります。

Oracle WebCenter Portalについては、次を参照してください。

Oracle WebCenter Contentについては、次を参照してください。

- Oracle WebCenter Contentのインストールおよび構成

Oracle SOA Suiteについては、次を参照してください。

- SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール

- 『Oracle Fusion Middlewareのインストールのプランニング』を確認する。このドキュメントには、すべてのOracle Fusion Middlewareインストールの準備に役立つ追加情報が記載されています。

2 標準的なエンタープライズ・デプロイメントについて

標準的なエンタープライズ・デプロイメント・トポロジのコンポーネントを理解することはきわめて重要です。

この章では、エンタープライズ・デプロイメント・トポロジのダイアグラムについて説明します。

- 標準的なエンタープライズ・デプロイメントのダイアグラム
このダイアグラムは、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントのすべてのコンポーネントを示しています。すべてのエンタープライズ・デプロイメントは、これらの基本原則に基づいています。

- 標準的なエンタープライズ・デプロイメント・トポロジのダイアグラムについて
標準的なエンタープライズ・デプロイメント・トポロジには、ハードウェア・ロード・バランサ(LBR)、Web層、アプリケーション層およびデータ層が含まれます。この項では、これらのコンポーネントの詳細情報を入手できます。

親トピック: エンタープライズ・デプロイメントの理解

2.1 標準的なエンタープライズ・デプロイメントのダイアグラム

このダイアグラムは、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントのすべてのコンポーネントを示しています。すべてのエンタープライズ・デプロイメントは、これらの基本原則に基づいています。

すべてのOracle Fusion Middlewareエンタープライズ・デプロイメントは、Oracle Fusion Middleware本番環境のインストールと構成に関するベスト・プラクティスを示すように設計されています。

ベスト・プラクティス・アプローチは、複数層デプロイメントと、異なるソフトウェア層間の標準的通信の基本概念で始まります。

図2-1に、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントを示します。すべてのエンタープライズ・デプロイメントは、これらの基本原則に基づいています。

標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで通信に使用される各層と標準プロトコルの説明は、「標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解」を参照してください。

図2-1 標準的なエンタープライズ・デプロイメント・トポロジのダイアグラム

2.2 標準的なエンタープライズ・デプロイメント・トポロジのダイアグラムについて

標準的なエンタープライズ・デプロイメント・トポロジには、ハードウェア・ロード・バランサ(LBR)、Web層、アプリケーション層およびデータ層が含まれます。この項では、これらのコンポーネントの詳細情報を入手できます。

- 標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解

- 標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解

- ハードウェア・ロード・バランサを介したリクエストの受信

- Web層の理解

- アプリケーション層の理解

- 標準的なエンタープライズ・デプロイメントでのCoherenceクラスタについて

- データ層について

2.2.1 標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解

トポロジは、ファイアウォールによって隔てられている、次のようないくつかのセキュリティ・ゾーンに分かれています。

- Web層(またはDMZ)。ハードウェア・ロード・バランサとユーザーからの初期リクエストを受信するWebサーバー(ここではOracle HTTP Serverインスタンス)で使用されます。このゾーンには、ロード・バランサ上で定義されている単一の仮想サーバー名を介してのみアクセスできます。

- アプリケーション層。ビジネス・ロジックとアプリケーション・ロジックが配置されている場所です。

- データ層。インターネットからアクセスできず、可用性の高いデータベース・インスタンス用にこのトポロジで予約されます。

ファイアウォールは、特定の通信ポートを介した場合にのみデータ転送が許可されるように構成されています。これらのポート(または、場合によってはファイアウォール内の開いているポートを必要とするプロトコル)は、ダイアグラム内の各ファイアウォール・ライン上に示しています。

次に例を示します。

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

- アプリケーション層を保護するファイアウォール上では、HTTPポートとMBeanプロキシ・ポートが開いています。
外部HTTPアクセスが必要なアプリケーションは、プロキシとしてOracle HTTP Serverインスタンスを使用できます。このポートはアウトバウンド通信専用であり、Oracle HTTP Serverのプロキシ機能を有効にする必要があります。

- データ層を保護しているファイアウォールでは、データベース・リスナー・ポート(通常は1521)が開かれている必要があります。
また、認可プロバイダとLDAPベースのアイデンティティ・ストア間の通信用に、LDAPポート(通常は389と636)も開いている必要があります。

アプリケーション層がOracle RACデータベース・ワークロードとイベントに関する通知を受信できるように、ONSポート(通常は6200)も必要です。これらのイベントは、Oracle RACデータベース・インスタンスの可用性とワークロードに応じて、Oracle WebLogic Server接続プールが迅速に調整(接続の作成または破棄)するために使用されます。

特定のOracle Fusion Middlewareエンタープライズ・デプロイメント・トポロジにおいて開いておく必要があるポートの全リストは、実装するトポロジについて説明している章を参照するか、実装するトポロジのエンタープライズ・デプロイメント・ワークブックを参照してください。詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください。

2.2.2 標準的なエンタープライズ・デプロイメント・トポロジの各要素の理解

エンタープライズ・デプロイメント・トポロジは、大まかに次の要素で構成されます。

- ハードウェア・ロード・バランサ。インターネットからのリクエストをWeb層内のWebサーバーにルーティングします。また、社内ネットワーク内で内部呼出しを実行する内部クライアントや他のコンポーネントからのリクエストもルーティングします。

- Web層。ハードウェア・ロード・バランサとWebサーバー・インスタンスをホストする2つ以上の物理コンピュータで構成されています(高可用性のため)。
Webサーバー・インスタンスは、ユーザーを認証し(外部アイデンティティ・ストアおよびシングル・サインオン・サーバーを使用)、HTTPリクエストを、アプリケーション層内で実行されているOracle Fusion Middleware製品とコンポーネントにルーティングするように構成されています。

また、Webサーバー・インスタンスは、アプリケーション・ロジックの提供を必要としない静的Webコンテンツをホストします。このようなコンテンツをWeb層に配置することで、アプリケーション・サーバーのオーバーヘッドが低減され、不要なネットワーク・アクティビティが排除されます。

- アプリケーション層。Oracle WebLogic Server管理対象サーバーのクラスタとドメイン用の管理サーバーをホストする2つ以上の物理コンピュータで構成されています。管理対象サーバーは、エンタープライズ・デプロイメントでの製品の選択に応じて、Oracle SOA Suite、Oracle Service Bus、Oracle WebCenter Content、Oracle WebCenter Portalなどの様々なOracle Fusion Middleware製品を実行するように構成されています。

- データ層。Oracle RACデータベースをホストする2つ以上の物理ホストで構成されています。

2.2.3 ハードウェア・ロード・バランサを介したリクエストの受信

次のトピックでは、エンタープライズ・デプロイメントにおけるハードウェア・ロード・バランサとその役割について説明します。

- ハードウェア・ロード・バランサ(LBR)の目的

- 標準的なロード・バランサの仮想サーバー名のサマリー

- 外部仮想サーバー名に対するHTTPSリクエストとHTTPリクエストの対比

2.2.3.1 ハードウェア・ロード・バランサ(LBR)の目的

次のトピックでは、エンタープライズ・デプロイメントでハードウェア・ロード・バランサによって処理されるリクエストのタイプについて説明します。

- インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト

- アプリケーション層のコンポーネント間特有の内部専用通信

2.2.3.1.1 インターネットからWeb層内のWebサーバー・インスタンスへのHTTPリクエスト

ハードウェア・ロード・バランサは、1つの仮想ホスト名へのリクエストを受信して各リクエストをロード・バランシング・アルゴリズムに基づいてWebサーバー・インスタンスの1つにルーティングすることで、Web層でのロードをバランシングします。このようにして、ロード・バランサは、特定のWebサーバーがHTTPリクエストによってオーバーロードにならないようにします。

ハードウェア・ロード・バランサの特定の仮想ホスト名の用途の詳細は、「標準的なロード・バランサの仮想サーバー名のサマリー」を参照してください。

参照用トポロジでは、HTTPリクエストのみがハードウェア・ロード・バランサからWeb層にルーティングされることに注意してください。Secure Socket Layer (SSL)リクエストはロード・バランサで終了され、HTTPリクエストのみがOracle HTTP Serverインスタンスに転送されます。このガイドでは、ロード・バランサとOracle HTTP Serverインスタンス間およびWeb層とアプリケーション層間のSSL構成について説明していません。

ロード・バランサは、Webサーバーの1つが停止した場合に残りの稼働中のWebサーバーにリクエストがルーティングされるようにすることで、高可用性を実現します。

また、標準的な高可用性構成では、メインのロード・バランシング装置で障害が発生した場合にホット・スタンバイ・デバイスがすぐにサービスを再開できるように、複数のハードウェア・ロード・バランサが構成されます。多種のサービスおよびシステムにとってハードウェア・ロード・バランサは呼出しを行う唯一のアクセス・ポイントとなり、保護されていない場合にはシステム全体の単一障害点(SPOF)となるため、このことは重要です。

2.2.3.1.2 アプリケーション層のコンポーネント間特有の内部専用通信

さらに、ハードウェア・ロード・バランサは、Oracle Fusion Middlewareコンポーネントとアプリケーション層のアプリケーション間に特有の通信をルーティングします。内部専用のリクエストも、ロード・バランサを介してルーティングされます(一意の仮想ホスト名を使用する)。

2.2.3.2 標準的なロード・バランサの仮想サーバー名のサマリー

サーバー上のロードのバランシングと高可用性の提供のために、ハードウェア・ロード・バランサは一連の仮想サーバー名を認識するように構成されています。ダイアグラムに示すように、このトポロジではハードウェア・ロード・バランサによって次の仮想サーバー名が認識されます。

- wcp.example.com: この仮想サーバー名はすべての着信トラフィックに使用されます。
ユーザーは、このURLを入力して、デプロイしたOracle Fusion Middleware製品およびこのサーバー上で使用可能なカスタム・アプリケーションにアクセスします。その後、ロード・バランサによってそれらのリクエストが(ロード・バランシング・アルゴリズムを使用して)Web層内のサーバーの1つにルーティングされます。このようにすることで、1つの仮想サーバー名を使用してトラフィックを複数のサーバーにルーティングすることが可能になり、Webサーバー・インスタンスのロード・バランシングと高可用性が実現されます。

- wcpinternal.example.com: この仮想サーバー名は、内部通信専用です。
ロード・バランサは、そのネットワーク・アドレス変換(NAT)機能を使用して、アプリケーション層コンポーネントからこのURLへの内部通信をすべてルーティングします。このURLは、インターネット上の外部顧客またはユーザーには公開されていません。各製品には、内部URLに固有の用途があるため、デプロイメント手順では、接頭辞に製品名を付加しています。

- admin.example.com: この仮想サーバー名は、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server管理コンソール・インタフェースにアクセスする必要がある管理者用です。
このURLは、内部管理者のみが知っています。また、ロード・バランサのNAT機能を使用することで、管理者はドメイン内のアクティブな管理サーバーにルーティングされます。

自身のトポロジに対して定義する必要がある仮想サーバー名の完全なセットについては、製品固有のトポロジが記載されている章を参照してください。

2.2.3.3 外部仮想サーバー名に対するHTTPSリクエストとHTTPリクエストの対比

ハードウェア・ロード・バランサを構成する場合は、メインの外部URL (たとえば、http://myapplication.example.com)をポート80およびポート443に割り当てることをお薦めします。

ポート80 (非SSLプロトコル)に対するリクエストはすべて、ポート443 (SSLプロトコル)にリダイレクトする必要があります。このルールの例外としては、パブリックWSDLからのリクエストがあります。詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

2.2.4 Web層の理解

参照トポロジのWeb層は、ロード・バランサからリクエストを受信するWebサーバーで構成されます。標準的なエンタープライズ・デプロイメントでは、Web層内に2つ以上のOracle HTTP Serverインスタンスが構成されています。次のトピックで、詳細を説明します。

- リクエストのルーティングにOracle HTTP Serverインスタンスを使用する利点

- Web層でのOracle HTTP Serverの使用にかわる方法

- Web層でのOracle HTTP Serverの構成

- Mod_WL_OHSについて

2.2.4.1 リクエストのルーティングにOracle HTTP Serverインスタンスを使用する利点

Oracle HTTP Serverを含むWeb層の使用は、多くのOracle Fusion Middleware製品の必要条件ではありません。アプリケーション層でハードウェア・ロード・バランサからWLSサーバーへ直接トラフィックをルーティングできます。ただし、Web層にはいくつかの利点があり、それが、参照用トポロジの一部としてお薦めする理由です。

- Web層はDMZパブリック・ゾーンを提供します。これはセキュリティ監査における一般的な必要条件です。ロード・バランサがWebLogic Serverに直接ルーティングを行うと、リクエストがロード・バランサからアプリケーション層に1回のHTTPジャンプで移動するため、セキュリティ上の問題を引き起こす可能性があります。

- Web層では、Webサーバー構成を変更することなく、WebLogic Serverクラスタ・メンバーシップを再構成(新規サーバーの追加とサーバーの削除)できます(構成したリスト内のサーバーのいくつかがアライブであることが条件)。

- Oracle HTTP ServerはWebLogic Serverより効率的かつ高速に静的コンテンツを提供します。また、一部のエンタープライズ・デプロイメントに必要なFTPサービス、およびOracle HTTP Server構成ファイルによる仮想ホストおよびプロキシの作成機能も提供します。

- Oracle HTTP Serverは、WebLogic Serverが提供する機能に加えてHTTPリダイレクションを提供します。Oracle HTTP Serverを多様なWebLogic Serverクラスタのフロント・エンドとして使用でき、場合によっては、コンテンツ・ベースのルーティングを実行してルーティングを制御できます。

- Oracle HTTP Serverは、エンタープライズ・デプロイメントにシングル・サインオン機能を統合する機能を提供します。たとえば、Oracle Identity and Access Management製品ファミリの一部であるOracle Access Managerを使用して、後からシングル・サインオンをエンタープライズ・デプロイメントに実装できます。

- Oracle HTTP Serverは、WebLogic Server内にデプロイされているWebSocket接続のサポートを提供します。

Oracle HTTP Serverの詳細は、『Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの概要を参照してください。

2.2.4.2 Web層でのOracle HTTP Serverの使用にかわる方法

Oracle HTTP Serverはエンタープライズ・トポロジに様々な利点をもたらしますが、中間層でハードウェア・ロード・バランサから管理対象サーバーへリクエストを直接ルーティングする方法もサポートされています。

この方法には、次の利点があります。

- フロントエンドOracle HTTP ServerのWeb層フロントエンドを使用するよりも構成と処理のオーバーヘッドが小さい。

- 管理対象サーバーごとに固有のURLを監視するようにLBRを構成できるので、アプリケーション・レベルでの監視が可能(OHSでは不可能)。
この場合、すべてのコンポジットがデプロイされたときにのみ管理対象サーバーへのルーティングが可能になります。また、適切な監視ソフトウェアを使用する必要があります。

2.2.4.3 Web層でのOracle HTTP Serverの構成

Oracle Fusion Middleware 12c以降、Oracle HTTP Serverソフトウェアは既存のOracle WebLogic Serverドメインの一部として構成するか、または独自のスタンドアロン・ドメインで構成できるようになりました。各構成には、固有の利点があります。

Oracle HTTP Serverインスタンスを既存のWebLogic Serverドメインの一部として構成すると、Oracle Enterprise Manager Fusion Middleware Controlを使用して、WebサーバーとOracle WebLogic Server管理対象サーバー間の通信のワイヤリングなど、Oracle HTTP Serverインスタンスの管理を行うことができます。Oracle HTTP Serverをスタンドアロン構成で構成すると、Oracle HTTP Serverインスタンスをアプリケーション層のドメインとは別に構成および管理できます。

このエンタープライズ・デプロイメント・ガイドでは、Oracle HTTP Serverインスタンスは、各Web層ホストに1つずつ、別個のスタンドアロン・ドメインとして構成されます。Oracle HTTP Serverインスタンスをアプリケーション層ドメインの一部として構成することもできますが、このエンタープライズ・デプロイメント・ガイドでは、そのようにOracle HTTP Serverインスタンスを構成するための手順は示されません。

詳細は、『Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverに関する項を参照してください。

2.2.4.4 Mod_WL_OHSについて

ダイアグラムに示すように、Oracle HTTP Serverインスタンスは、Oracle HTTP Serverからアプリケーション層のOracle WebLogic Server管理対象サーバーへのHTTPリクエストのプロキシに、WebLogicプロキシ・プラグイン(mod_wl_ohs)を使用します。

詳細は、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のOracle WebLogic Serverプロキシ・プラグインとはに関する項を参照してください。

2.2.5 アプリケーション層の理解

アプリケーション層は2つの物理ホスト・コンピュータで構成されており、そこにOracle WebLogic ServerおよびOracle Fusion Middleware製品がインストールされて構成されます。アプリケーション層のコンピュータは、ファイアウォール1とファイアウォール2の間のセキュリティ保護されたゾーンに配置されます。

次のトピックで詳細情報を提供します。

- 管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

- アプリケーション層でのOracle Web Services Managerの使用

- アプリケーション層におけるクラスタとホストの構成のベスト・プラクティスとバリエーション

- 標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

- アプリケーション層内での通信のためのユニキャストの使用について

- OPSSおよび認証ストアと認可ストアへのリクエストの理解

2.2.5.1 管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

ドメイン内の管理対象サーバーとは異なり、管理サーバーはアクティブ/パッシブ高可用性構成を使用します。これは、Oracle WebLogic Serverドメイン内で実行できる管理サーバーは1つのみであるためです。

トポロジ・ダイアグラムでは、HOST1上の管理サーバーがアクティブな状態で、HOST2上の管理サーバーがパッシブ(非アクティブ)の状態です。

システム障害時に管理サーバーの手動フェイル・オーバーをサポートする標準的なエンタープライズ・デプロイメント・トポロジには、次のものが含まれます。

- 管理サーバーのリクエストのルーティング用の仮想IPアドレス(VIP)

- 共有記憶域デバイス上の管理サーバー・ドメイン・ディレクトリの構成

システム障害(HOST1の障害など)が発生した場合、管理サーバーのVIPアドレスをドメイン内の別のホストに手動で再割当てし、管理サーバーのドメイン・ディレクトリをその新しいホストにマウントして、新しいホスト上で管理サーバーを起動できます。

ただし、管理サーバーと違い、管理対象サーバーを共有記憶域に格納するメリットはありません。実際に、管理対象サーバーの構成データをホスト・コンピュータのローカル・ディスクに格納しないと、パフォーマンスに影響するおそれがあります。

したがって、標準的なエンタープライズ・デプロイメントでは、管理サーバーのドメインを共有記憶域上で構成すると、ドメイン構成のコピーが各ホスト・コンピュータのローカル記憶域デバイスに配置され、このドメイン構成のコピーから管理対象サーバーが起動されます。このコピーの作成には、Oracle WebLogic Serverのpackおよびunpackユーティリティを使用します。

結果として、各ホストに別個のドメイン・ディレクトリを配置する構成となります。つまり、管理サーバー(共有記憶域上)と管理対象サーバー(ローカル記憶域上)に1つずつ配置します。必要なアクションに応じて、いずれかのドメイン・ディレクトリから構成タスクを実行する必要があります。

管理サーバーのドメイン・ディレクトリと管理対象サーバーのドメイン・ディレクトリの構造、およびこれらのディレクトリの参照に使用する変数の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。

複数ドメイン・ディレクトリ・モデルには追加の利点があります。管理サーバーを管理対象サーバーから切り離すことができます。デフォルトのプライマリ・エンタープライズ・デプロイメント・トポロジでは、アプリケーション層のホストの1つに管理サーバーのドメイン・ディレクトリが存在することを想定していますが、管理サーバーによるCPUまたはRAMの消費量が多いときなど、必要な場合に管理サーバーを独自のホストから実行することで、管理サーバーをさらに分離できます。別の専用ホストに管理サーバーを構成する管理者もいますが、複数ドメイン・ディレクトリ・モデルによってそれが可能となっています。

2.2.5.2 アプリケーション層でのOracle Web Services Managerの使用

Oracle Web Services Manager (Oracle WSM)は、エンタープライズ・デプロイメント・トポロジにおけるWebサービスの管理と保護を目的としたポリシー・フレームワークを提供します。

ほとんどのエンタープライズ・デプロイメント・トポロジでは、Oracle Web Services Manager Policy Managerは、アクティブ/アクティブの高可用性構成でデプロイできる、別のクラスタ内の管理対象サーバー上で実行されます。

その影響について認識している場合は、Oracle Web Services ManagerおよびFusion Middleware製品またはアプリケーションを同じクラスタにターゲット指定することができます。

Oracle Web Services Managerを専用の管理対象サーバーにデプロイする主な理由は、パフォーマンスと可用性の分離性を高めるためです。Oracle Web Services Managerは、多くの場合、ドメイン内のカスタムWebサービスやその他の製品およびコンポーネントにポリシーを提供します。このような場合に、Oracle Web Services Managerの追加アクティビティが、Oracle Web Services Managerと同じ管理対象サーバーまたはクラスタを共有するアプリケーションのパフォーマンスに影響を及ぼすことは望ましくありません。

スケール・アウトやスケール・アップのプロセスが発生した場合でも、コンポーネント同士が分離されていれば、より適切な対応が可能です。他の製品に影響を及ぼすことなく、独自の製品がデプロイされているFusion Middlewareアプリケーションの管理対象サーバーのみ、またはOracle Web Services Managerがデプロイされている管理対象サーバーのみをスケール・アウトしたりスケール・アップしたりできます。

2.2.5.3 アプリケーション層におけるクラスタとホストの構成のベスト・プラクティスとバリエーション

標準的なエンタープライズ・デプロイメントでは、アプリケーション層内の2つ以上のホスト上にあるクラスタで管理対象サーバーを構成します。特定のOracle Fusion Middleware製品について、エンタープライズ・デプロイメント参照トポロジは、管理対象サーバー数、クラスタ数および各クラスタをターゲットとするサービスに関するベスト・プラクティスを示しています。

これらのベスト・プラクティスは、各製品の標準的なパフォーマンス、メンテナンスおよびスケールアウトの各要件を考慮したものです。その結果、管理対象サーバーは、ドメイン内の適切なクラスタ・セットにグループ化されます。

エンタープライズ・デプロイメント・トポロジのバリエーションとして、特定の製品またはコンポーネントを追加のクラスタまたはホストにターゲット設定できます。これにより、パフォーマンスと独立性が向上します。

たとえば、管理サーバーを別個の比較的小規模なホスト・コンピュータにホストすることで、FMWコンポーネントおよび製品を管理サーバーから隔離することを考慮できます。

トポロジのこれらのバリエーションはサポートされていますが、エンタープライズ・デプロイメント参照トポロジでは、高可用性、スケーラビリティおよびセキュリティに留意しながら最小のハードウェア・リソースを使用します。各種サーバーのシステム要件と、システムが対応する必要のある負荷に応じて、適切なリソース・プランニングおよびサイジングを実施してください。これらの決定に基づいて、これらのバリエーションをインストールおよび構成する手順を、このガイドに記載の説明から適切に変更する必要があります。

2.2.5.4 標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

Oracle Fusion Middleware 12c以降では、ドメインごとのノード・マネージャまたはホストごとのノード・マネージャのいずれかを使用できます。次の項では、通常のエンタープライズ・デプロイメントに対するノード・マネージャ構成の影響に関して詳細に説明します。

注意:

2つのタイプのノード・マネージャの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の概要に関する項を参照してください。

ドメインごとのノード・マネージャ構成の使用について

ドメインごとのノード・マネージャを構成では、ホストごとのノード・マネージャ構成とは異なり、実際に管理サーバー上で2つのノード・マネージャ・インスタンスを起動します。1つは管理サーバーのドメイン・ディレクトリから、もう1つは管理対象サーバーのドメイン・ディレクトリから起動します。また、トポロジ内の他のホストのそれぞれで別のノード・マネージャ・インスタンスが実行されます。

管理サーバーを制御するノード・マネージャでは、管理サーバー用に作成された仮想ホスト名のリスニング・アドレスが使用されます。管理対象サーバーを制御するノード・マネージャでは、物理ホストのリスニング・アドレスが使用されます。管理サーバーが別のホストにフェイルオーバーされると、ノード・マネージャの追加のインスタンスが開始され、フェイルオーバー・ホスト上の管理サーバーが制御されます。

ドメインごとの構成の主な利点は、ノード・マネージャの初期設定がより簡単かつ単純になることと、管理サーバーで一意のノード・マネージャ・プロパティを設定できることです。クラッシュ・リカバリなどの一部の機能が、管理対象サーバーではなく管理サーバーにのみ適用されていたため、この最後の機能は前のリリースで重要でした。現在のリリースでは、Oracle SOA Suite製品をサーバー全体の移行ではなく、サービスの自動移行用に構成できます。つまり、管理対象サーバーと管理サーバーでクラッシュ・リカバリを利用できるため、管理サーバーおよび管理対象サーバーのドメイン・ディレクトリに別のプロパティを適用する必要がありません。

別の利点は、ドメインごとのノード・マネージャでは、各ドメインに作成されたデモ・アイデンティティ・ストアに基づいて、ノード・マネージャからサーバーへの通信用のデフォルトSSLが提供されることです。

ホストごとのドメイン・マネージャ構成の使用について

ホストごとのノード・マネージャ構成では、単一のノード・マネージャ・インスタンスを起動して、ホスト上の管理サーバーおよびすべての管理対象サーバーを、別のドメインに存在するものも含めて制御します。これにより、特に同じマシンに複数のドメインが共存する場合に、管理サーバー・ホストでのフットプリントおよびリソース使用率が削減されます。

ホストごとのノード・マネージャ構成を使用すると、すべてのノード・マネージャでANYのリスニング・アドレスを使用できるため、ノード・マネージャでホスト上の使用可能なすべてのアドレスがリスンされます。つまり、管理サーバーが新しいホストにフェイルオーバーした場合に、追加の構成が必要ありません。ホストごとの構成を使用すると、複数のノード・マネージャ・プロパティ・ファイルではなく、単一のノード・マネージャ・プロパティ・ファイルを各ホストで更新および管理できるため、管理がより簡単になります。

ホストごとのノード・マネージャ構成には、追加の構成手順が必要です。ノード・マネージャからサーバーへの通信用のSSLが必要な場合は、追加のアイデンティティおよび信頼ストアを構成する必要があります。また、ノード・マネージャで複数のアドレスがリスンされるため、サブジェクト代替名(SAN)を使用する必要があります。SSL通信は2つのファイアウォールによって保護されているため、通常、アプリケーション層は必要ありません。

2.2.5.5 アプリケーション層内での通信のためのユニキャストの使用について

エンタープライズ・デプロイメントにおける管理対象サーバーとOracle WebLogic Serverクラスタ内のホストの間の通信にはユニキャスト通信プロトコルをお薦めします。マルチキャスト通信と異なり、ユニキャストではネットワーク間構成は不要です。また、これによって、マルチキャスト・アドレス競合により発生する場合がある潜在的なネットワーク・エラーも減少します。

独自のデプロイメントでマルチキャストかユニキャストのどちらのプロトコルを使用するかを検討するときは、ネットワークの種類、クラスタ内のメンバー数、およびクラスタ・メンバーシップの信頼性要件を考慮してください。また、各プロトコルが持つ次の利点も考慮してください。

エンタープライズ・デプロイメントにおけるユニキャストの利点:

- グループ・リーダーを使用し、このリーダーにすべてのサーバーがメッセージを直接送信します。このリーダーは、他のすべてのグループ・メンバーと他のグループ・リーダー(該当する場合)にメッセージを再送信する役割を担います。

- ほとんどのネットワーク・トポロジでそのまま動作します。

- ネットワーク・トポロジに関係なく、追加の構成は不要です。

- 単一の欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。

エンタープライズ・デプロイメントにおけるマルチキャストの利点:

- マルチキャストは、より拡張性の高いピア・ツー・ピア・モデルを採用します。このモデルでは、サーバーが各メッセージを一度だけネットワークに直接送信し、各クラスタ・メンバーがネットワークからメッセージを直接受信することをネットワークが保証します。

- クラスタ・メンバーが単一のサブネット内にある最近のほとんどの環境でそのまま動作します。

- クラスタ・メンバーが複数のサブネットにまたがっている場合は、ルーターとWebLogic Server (マルチキャストTTL)で追加構成が必要です。

- 連続する3つの欠落ハートビートを使用して、サーバーをクラスタ・メンバーシップ・リストから削除します。

どちらのモデルの方がより適切に動作するかは、クラスタ内のサーバー数と、基礎となるアプリケーションにとってクラスタ・メンバーシップが不可欠かどうか(たとえば、セッション・レプリケーションを大量に行うアプリケーションやクラスタ全体でRMI呼出しが大量に発生するクラスタなど)によって異なります。

使用するトポロジがアクティブ/アクティブ型の障害時リカバリ・システムに参加するかどうか、またクラスタが複数のサブネットを横断するどうかを考慮してください。一般に、これらの場合にはユニキャストの方がより適切に動作します。

詳細は、次のリソースを参照してください。

- 『高可用性ガイド』のWebLogic Serverクラスタ用マルチキャスト・メッセージングの構成に関する項

- 『Oracle WebLogic Serverクラスタの管理』のユニキャストを使用した1対多通信に関する項

2.2.5.6 OPSSおよび認証ストアと認可ストアへのリクエストの理解

Oracle Fusion Middleware製品およびコンポーネントの多くでは、認証プロバイダ(アイデンティティ・ストア)、ポリシー、資格証明、キーストアおよび監査データのためにOracle Platform Security Services (OPSS)セキュリティ・ストアが必要です。結果として、アプリケーション層とセキュリティ・プロバイダとの間でリクエストを送受信できるように通信を有効化する必要があります。

認証の場合、この通信は、一般的にポート389または636で通信するOracle Internet Directory (OID)、Oracle Unified Directory (OUD)などのLDAPディレクトリ宛てです。Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダを使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用する必要があります。

認可(およびポリシー・ストア)の場合、層によってセキュリティ・ストアの位置が異なります。

- アプリケーション層では、認可ストアはデータベース・ベースです。したがって、必要なOPSSデータを取得するために、Oracle WebLogic Server管理対象サーバーからデータベースへの頻繁な接続が必要になります。

- Web層では、認可ストアはファイル・ベースです。したがって、データベースへの接続は必要ありません。

OPSSセキュリティ・ストアの詳細は、Oracle Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護の次の項を参照してください。

- 認証の基本に関する項

- セキュリティ・モデルに関する項

2.2.6 標準的なエンタープライズ・デプロイメントでのCoherenceクラスタについて

標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントには、記憶域が有効な管理対象Coherenceサーバーを含むCoherenceクラスタが含まれます。

この構成はCoherenceの使用には適切な出発点ですが、特定の要件によっては、本番環境でのパフォーマンスを向上させるため、またはポートの競合を解決するために、Coherenceをチューニングして再構成することを検討できます。

ポートの割当てを確認する際、Oracle Fusion Middleware製品およびコンポーネントが、構成ウィザードの「Coherenceクラスタ」画面で指定されたポートを使用するウェル・ノウン・アドレス(WKA)リストにデフォルト設定されていることに注意してください。WKAリストでは、coherenceクラスタに参加しているすべてのサーバーのリスニング・アドレスも、WKAリストのリスニング・アドレスとして使用されます。これらの設定は、WLS管理コンソールを使用してカスタマイズできます。

詳細は、次のマニュアルを参照してください。

- Coherenceクラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』の「Coherenceクラスタの構成と管理」を参照してください。

- Coherenceのチューニングの詳細は、『Oracle Coherenceの管理』の「パフォーマンス・チューニング」を参照してください。

- CoherenceにおけるHTTPセッション・データの格納の詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』のWebLogicサーバーでのCoherence*Webの使用を参照してください。

- Coherenceアプリケーションの作成およびデプロイの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』の「WebLogic Server用Coherenceアプリケーションの作成」と「WebLogic ServerでのCoherenceアプリケーションのデプロイ」を参照してください。

2.2.7 データ層について

データ層では、Oracle RACデータベースは2つのホスト(DBHOST1とDBHOST2)上で実行されます。データベースには、Oracle WebCenter PortalコンポーネントとOracle Platform Security Services (OPSS)ポリシー・ストアが必要とするスキーマが含まれています。

エンタープライズ・デプロイメントでは製品およびコンポーネントごとに複数のサービスを定義することで、スループットとパフォーマンスの分離および優先順位の決定ができます。このガイドでは、例として1つのデータベース・サービスを使用します。また、データベースを保護する他の高可用性データベース・ソリューションも使用できます。

- Oracle Data Guard: 詳細は、Oracle Data Guard概要および管理のOracle Data Guardの概要に関する項を参照してください。

- Oracle RAC One Node: 詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドのOracle RAC One Nodeの概要に関する項を参照してください。

これらのソリューションは、エンタープライズ・デプロイメントに一般に適用されるスケーラビリティと可用性の要件を満たす場合、Oracle RACデータベースの使用に重点を置いたこのガイドに記載されている情報以上のデータベース保護を実現します。

高可用性環境でのOracleデータベースの使用の詳細は、『高可用性ガイド』の「データベースに関する考慮事項」を参照してください。

3 WebCenter Portalエンタープライズ・デプロイメント・トポロジの理解

この章では、WebCenter Portalデプロイメント・トポロジについて説明します。これらのトポロジは、「標準的なエンタープライズ・デプロイメントの理解」で説明した概念の具体的な参照用実装です。

この章では、プライマリWebCenter Portalトポロジのダイアグラムを示します。

- WebCenter Portalエンタープライズ・デプロイメント・トポロジのダイアグラム

- プライマリWebCenter Portalトポロジのダイアグラムの理解

- プライマリWebCenter Portalエンタープライズ・トポロジを実装するためのフロー・チャートとロードマップ

親トピック: エンタープライズ・デプロイメントの理解

3.1 WebCenter Portalエンタープライズ・デプロイメント・トポロジのダイアグラム

次のダイアグラムは、このガイドで説明するプライマリOracle WebCenter Portalエンタープライズ・デプロイメント・トポロジを示しています。

3.2 プライマリWebCenter Portalトポロジのダイアグラムの理解

Oracle WebCenter Portalトポロジは、オラクル社が推奨するベスト・プラクティスに基づいたエンタープライズ・トポロジへの標準アプローチに準拠しています。Oracle Fusion Middlewareエンタープライズ・トポロジの標準要素の詳細は、「標準的なエンタープライズ・デプロイメントの理解」を参照してください。

ここで説明する情報は、「標準的なエンタープライズ・デプロイメントの理解」の情報を確認したこと、およびエンタープライズ・デプロイメント・トポロジの一般的概念を理解していることを前提としています。

この章で説明するトポロジに特有の要素については、次の各項を参照してください。

- WebCenter Portalロード・バランサ仮想サーバー名のサマリー

- WebCenter Portalアプリケーション層の管理対象サーバーとクラスタのサマリー

3.2.1 WebCenter Portalロード・バランサ仮想サーバー名のサマリー

サーバー上のロードのバランシングと高可用性の提供のために、ハードウェア・ロード・バランサは一連の仮想サーバー名を認識するように構成されています。

これらの各サーバー名の用途については、「標準的なロード・バランサの仮想サーバー名のサマリー」を参照してください。

Oracle WebCenter Portalトポロジでは、ハードウェア・ロード・バランサによって次の仮想サーバー名が認識されます。

- wcp.example.com: この仮想サーバー名はすべての着信エンドユーザー・クライアント・トラフィックに使用されます。ランタイムWebCenter PortalコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして動作します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してリスニングします。必要に応じて、ポート80で構成される追加仮想サーバーを、すべてのトラフィックをポート443に自動的にリダイレクトするルールを使用して設定できます。その結果、クライアントは、次のセキュア・アドレスを使用してこの環境のサービスにアクセスします。

https://wcp.example.com:443

- wcpinternal.example.com: この仮想サーバー名は、Oracle WebCenterサービスへの内部コールに使用されます。ハードウェア・ロード・バランサで構成される仮想サーバーが2つあります。1つ目(ポート80でリスニング)は、Webベース・サービスに使用されます。2つ目(ポート6300でリスニング)は、WebCenter Conent Remote Intradoc Client (RIDC) APIコール用です。
クライアントからの着信トラフィックは、SSL対応ではありません。クライアントは次のアドレスを使用してHTTPサービスにアクセスします。これらのリクエストは、WEBHOST1およびWEBHOST2のポート7777に転送されます。

http://wcpinternal.example.com:80/...

WebCenter Content RIDC対応のアプリケーション(WebCenter Content Desktop Integration Suite (DIS)やWebCenter Portal Document Servicesなど)では、WebCenter Content ServerのRIDC APIエンドポイントへのTCP接続にポート6300を使用します。これらのリクエストは、WCCHOST1およびWCCHOST2のポート4444に転送されます。

wcpinternal.example.com:6300

- admin.example.com: この仮想サーバー名は、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server管理コンソール・インタフェースにアクセスする必要がある管理者用です。

http://admin.example.com:80/...

このガイドで後ほど説明する手順に従って、次のタスクを実行します。

- リクエストを認識し、仮想ホスト名にルーティングするようにハードウェア・ロード・バランサを構成する

- これらの仮想ホスト名へのリクエストを認識し、正しいホスト・コンピュータに適切にルーティングできるように、Web層のOracle HTTP Serverインスタンスを構成する。

3.2.2 WebCenter Portalアプリケーション層の管理対象サーバーとクラスタのサマリー

アプリケーション層は、Oracle WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーをホストします。

選択したトポロジに応じて、ドメイン用のOracle WebLogic Serverドメインは、表3-1に示すクラスタで構成されています。これらのクラスタは、アクティブ/アクティブ高可用性構成として機能します。

表3-1 Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのクラスタのサマリー

製品コンポーネント

クラスタ

管理対象サーバー

Oracle Web Services Manager。

WSM-PM_Cluster

WLS_WSM1、WLS_WSM2

Oracle WebCenter Portal

Portal_Cluster

WLS_Portal1、WLS_Portal2

Oracle WebCenter Portlet

Portlet_Cluster

WLS_Portlet1、WLS_Portlet2

Oracle WebCenter Collaboration

Collab_Cluster

WLS_Collaboration1、WLS_Collaboration2

Oracle WebCenter Content

WCC_Cluster

WLS_WCC1、WLS_WCC2

Oracle Inbound Refinery

IBR_Servers

WLS_IBR1、WLS_IBR2

Oracle SOA Suite

SOA_Cluster

WLS_SOA1、WLS_SOA2

3.3 プライマリWebCenter Portalエンタープライズ・トポロジを実装するためのフロー・チャートとロードマップ

次の各トピックでは、この章で説明するエンタープライズ・トポロジをインストールおよび構成するために実行する必要がある大まかな手順を示します。

- WebCenter Portalエンタープライズ・トポロジをインストールおよび構成する手順のフロー・チャート

- エンタープライズ・デプロイメントの計画と準備のためのロードマップ表

- Oracle WebCenter Portalトポロジの構成のためのロードマップ表

3.3.1 WebCenter Portalエンタープライズ・トポロジをインストールおよび構成する手順のフロー・チャート

次のフロー・チャートに、この章で説明するプライマリ・エンタープライズ・デプロイメント・トポロジをインストールおよび構成するために必要な手順を示します。フロー・チャートに続くセクションで、フロー・チャート内の各手順について説明します。

このガイドは、動作しているWebCenter Portalドメインから始め、その後、そのドメインを拡張してさらに機能を追加できるように策定されています。

トポロジを構築するためのこのモジュラ・アプローチにより、ご使用のハードウェアおよびソフトウェア・リソース、さらに組織にとって最も重要なOracle WebCenter Portal機能に基づいて、戦略的な決定を行えます。

また、個々の製品またはコンポーネントを構成する際、検証とトラブルシューティングを行うこともできます。

これは、1つの構成ウィザード・セッションで複数の製品を構成できないという意味ではありません。このガイドで示すような様々な拡張機能を1回の構成ウィザード実行でグループ化できます。ただし、このガイドで説明する手順では、主にモジュラ・アプローチを中心にエンタープライズ・デプロイメントを構築します。

3.3.2 エンタープライズ・デプロイメントの計画と準備のためのロードマップ表

次の表で、エンタープライズ・トポロジ・フロー・チャートに示した計画と準備の各手順を説明します。

フロー・チャートの手順

詳細情報

標準的なエンタープライズ・デプロイメントの基礎の理解

標準的なエンタープライズ・デプロイメントの理解

デプロイしようとしている製品固有の参照用トポロジの理解。

必要な仮想サーバーや、製品固有のデプロイメントで推奨されるクラスタおよび管理対象サーバーのサマリーなど、製品固有のトポロジおよびトポロジの説明を確認します。

Oracle WebCenter Portal EDGワークブックの確認

エンタープライズ・デプロイメント・ワークブックの使用

ハードウェア、IPアドレスおよびソフトウェア・ダウンロードの入手

エンタープライズ・デプロイメント用のリソースの取得

ハードウェア・ロード・バランサとファイアウォールの準備

エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

ファイル・システムの準備

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

システム要件の確認、共有記憶域のマウントおよび仮想IPの有効化

エンタープライズ・デプロイメント用のホスト・コンピュータの準備

サポートされているOracle RACデータベースの特定またはインストール

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

3.3.3 Oracle WebCenter Portalトポロジの構成のためのロードマップ表

表3-2では、「WebCenter Portalエンタープライズ・デプロイメント・トポロジのダイアグラム」に示したトポロジを構成するときに必要になる構成手順それぞれを説明します。

次の各手順は、「WebCenter Portalエンタープライズ・トポロジをインストールおよび構成する手順のフロー・チャート」のフロー・チャートに示したステップに対応します。

表3-2 Oracle WebCenter Portalトポロジの構成のためのロードマップ表

フロー・チャートの手順

詳細情報

初期インフラストラクチャ・ドメインの作成

エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

Web層を追加するドメインの拡張

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

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

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

Inbound Refineryを追加するドメインの拡張

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

Oracle SOA Suiteを含めるドメインの拡張

Oracle SOA Suiteを含めるドメインの拡張

Oracle WebCenter Portalを含めるドメインの拡張

Oracle WebCenter Portalを含めるドメインの拡張

同一ドメイン内でのWebCenter PortalのOracle SOA Suiteとの統合

同一ドメイン内でのWebCenter PortalワークフローのOracle SOA Suiteとの統合

第II部 エンタープライズ・デプロイメントの準備

エンタープライズ・デプロイメントの準備のために実行する必要があるタスクを理解することは重要です。

エンタープライズ・デプロイメント・ガイドのこの部の内容は次のとおりです。

- エンタープライズ・デプロイメント・ワークブックの使用
エンタープライズ・デプロイメント・ワークブックを使用して、組織のエンタープライズ・デプロイメントを計画できます。

- エンタープライズ・デプロイメント用のリソースの取得
Oracle WebCenter Portalの参照用トポロジを構成する前に、必要なハードウェア、ソフトウェアおよびネットワーク設定を取得することはきわめて重要です。

- エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備
ハードウェア・ロード・バランサの構成方法およびファイアウォールでエンタープライズ・デプロイメントに対して開く必要があるポートの構成方法を理解することは重要です。

- エンタープライズ・デプロイメント用のファイル・システムの準備
エンタープライズ・デプロイメント用のファイル・システムの準備には、ローカルおよび共有記憶域の要件、およびエンタープライズ・トポロジのインストール時および構成時における重要なディレクトリとファイルの場所の参照に使用される用語を理解することが含まれます。

- エンタープライズ・デプロイメント用のホスト・コンピュータの準備
エンタープライズ・デプロイメント・トポロジを構成する前に、各コンピュータまたはサーバーに対して一連のタスクを実行することが重要です。これには、各ホストでのハードウェアおよびオペレーティング・システムの最小要件の確認、オペレーティング・システムのユーザーおよびグループの構成、Unicodeサポートの有効化、ホストへの必要な共有記憶域システムのマウント、および各ホストでの必要な仮想IPアドレスの有効化が含まれます。

- エンタープライズ・デプロイメント用のデータベースの準備
エンタープライズ・デプロイメント用のデータベースの準備には、データベースが特定の要件を満たしていることの確認、データベース・サービスの作成、データベースのラージ・オブジェクトに対するSecureFilesの使用、およびデータベース・バックアップ戦略の作成が含まれます。

4 エンタープライズ・デプロイメント・ワークブックの使用

エンタープライズ・デプロイメント・ワークブックを使用して、組織のエンタープライズ・デプロイメントを計画できます。

この章では、エンタープライズ・デプロイメント・ワークブック、ユースケースおよびエンタープライズ・デプロイメント・ワークブックの対象ユーザーについて説明します。

- エンタープライズ・デプロイメント・ワークブックの概要
エンタープライズ・デプロイメント・ワークブックは、アーキテクト、システム・エンジニア、データベース管理者などが環境インストールの詳細(サーバー名、URL、ポート番号、インストール・パス、その他のリソースなど)をすべて計画したり記録したりするために使用するスプレッドシートです。

- ワークブックの標準的なユース・ケース
エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースに関連するロールと作業を理解することは重要です。

- Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの使用
Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの場所と内容がわかると、効率的に使用できます。

- エンタープライズ・デプロイメント・ワークブックの使用対象者
エンタープライズ・デプロイメント・ワークブックの詳細は、リソースの各カテゴリの計画、取得または設定を担当する個人またはチームによって入力されます。

親トピック: エンタープライズ・デプロイメントの準備

4.1 エンタープライズ・デプロイメント・ワークブックの概要

エンタープライズ・デプロイメント・ワークブックは、アーキテクト、システム・エンジニア、データベース管理者などが環境インストールの詳細(サーバー名、URL、ポート番号、インストール・パス、その他のリソースなど)をすべて計画したり記録したりするために使用するスプレッドシートです。

エンタープライズ・デプロイメント・ワークブックは、プロセス全体の入力変数の追跡に使用できる唯一のドキュメントとしての役割を果たします。これにより、次のことが可能になります。

- アーキテクト、システム・エンジニア、データベース管理者および組織上重要な他のロール間での作業の切り分け

- 実装前の包括的な計画

- 計画内容を実際の実装前に検証

- 実装時の一貫性

- 将来の使用に備えた環境の記録

4.2 ワークブックの標準的なユース・ケース

エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースに関連するロールと作業を理解することは重要です。

Oracle Fusion Middlewareエンタープライズ・デプロイメントの準備として、エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースには次のロールと作業が関わります。

- アーキテクトがこのガイドの最初から第5章までを読み、ワークブックの対応する各項を記入します。

- ワークブックを他のアーキテクトとシステム・エンジニアが検証します。

- アーキテクトが検証済のワークブックを使用して、ネットワークとシステムの変更リクエストをシステム・エンジニアリング部門とともに開始します

- ソフトウェアのインストールと構成を担当する管理者とシステム・インテグレータがワークブックとこのガイドの以降の章を参照して、インストールと構成の作業を行います。

4.3 Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの使用

Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの場所と内容がわかると、効率的に使用できます。

次の各項では、Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの場所と内容について説明します。

- Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの場所

- Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの内容の理解

4.3.1 Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの場所

Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックは、Oracle Fusion Middlewareドキュメント・ライブラリにMicrosoft Excelスプレッドシートとして用意されています。ライブラリのインストール、パッチおよびアップグレード・ページのリンクから入手できます。

4.3.2 Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの内容の理解

次の各項では、Oracle WebCenter Portalエンタープライズ・デプロイメント・ワークブックの内容について説明します。ワークブックは複数のタブに分かれており、各タブには、エンタープライズ・デプロイメント・トポロジのインストールと構成に必要な一連の関連する変数と値が含まれます。

- スタート・タブの使用

- ハードウェア - ホスト・コンピュータ・タブの使用

- ネットワーク - 仮想ホストとポート・タブの使用

- ストレージ - ディレクトリ変数タブの使用

- 「データベース - 接続の詳細」タブの使用

4.3.2.1 スタート・タブの使用

エンタープライズ・デプロイメント・ワークブックのスタート・タブは、このワークブックの目次の役割を果たします。また、スプレッドシートの記入者を特定する目的にも使用できます。

スタート・タブには、値が必要なワークブック・フィールドや情報提供を目的としたフィールドの識別に使用する色を指定するためのキーも用意されています。

次の図にスプレッドシートのスタート・タブを示します。

4.3.2.2 ハードウェア - ホスト・コンピュータ・タブの使用

ハードウェア - ホスト・コンピュータ・タブには、Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのインストールと構成に必要なホスト・コンピュータが一覧表示されます。

参照トポロジは、通常、少なくとも6台のホスト・コンピュータ(Web層に2台、アプリケーション層に2台、データ層のOracle RACデータベース用に2台)を必要とします。環境を拡張してシステムを追加する場合は、追加するホスト・コンピュータごとに行を追加してください。

抽象ホスト名は、このガイド全体を通してホスト名の記述に使用される名前です。各行のホスト・コンピュータを調達し、実際のホスト名を入力してください。これにより、このガイドで抽象名が記述されているときに実際のホスト名を参照できるようになります。

たとえば、このガイドの手順にWCPHOST1と記述されている場合、このWCPHOST1という変数を、ワークブックのハードウェア - ホスト・コンピュータ・タブに記載されている実際の名前に置き換えることができます。

注意:

2つのドメインが同じノードを共有する場合、たとえば、Oracle SOA Suiteを設定してからMFTを独自のドメインで作成した場合、同じノードに2つのドメインが存在することになります。この場合、各ドメインで1つずつ、WCPHOST1とMFTHOST1を同時に使用することになります。

簡単に参照できるように、各ホストのIPアドレス、オペレーティング・システム(バージョンを含む)、CPU数およびRAMの量も記入しておくことをお薦めします。この情報は、エンタープライズ・デプロイメントのインストール、構成および保守時に役立つことがあります。

詳細は、「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」を参照してください。

4.3.2.3 ネットワーク - 仮想ホストとポート・タブの使用

ネットワーク - 仮想ホストとポート・タブには、エンタープライズ・デプロイメント・トポロジのインストールと構成を行う前に、ネットワーク管理者が定義する必要のある仮想ホストの一覧が記載されています。

ポート番号は様々な理由から重要です。管理コンソールにアクセスするためには、ポート番号のクイック・リファレンスが必要です。また、特定のポート経由のネットワーク・トラフィックを許可するようにファイアウォールを構成する必要があります。

各仮想ホスト、仮想IPアドレスおよび各ネットワーク・ポートには、デプロイメントにおけるはっきりした目的があります。詳細は、「エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備」を参照してください。

ネットワーク - 仮想ホスト表で、抽象仮想ホストまたは仮想IP名列の項目を確認してください。これらは、このガイドの手順で使用される仮想ホストと仮想IP名です。それぞれの抽象名に対して、ネットワーク管理者が定義した実際の仮想ホスト名を入力します。このガイドで抽象仮想ホストまたは抽象仮想IP名が記述されている箇所では、このテーブル内の対応する実際値に置き換えてください。

また、多くの場合、このガイドでは、インストールおよび構成するコンポーネントまたは製品にデフォルトのポート番号を使用することを前提としています。しかし実際には、異なるポート番号を使用する可能性があります。ネットワーク - ポート番号表を使用すると、デフォルトのポート値を、特定のインストールで使用する実際の値にマッピングできます。

4.3.2.4 ストレージ - ディレクトリ変数タブの使用

エンタープライズ・デプロイメントの準備の一環として、Oracleエンタープライズ・デプロイメントで推奨される標準ディレクトリ構造を使用することが前提となっています。

また、このガイドの手順では、特定のディレクトリ場所が記述されています。手順内でディレクトリごとに一貫して割り当てられている変数を、インストールにおける実際のディレクトリの場所に置き換える必要があります。

このタブに掲載されている各ディレクトリ場所に、インストールにおける実際のディレクトリ・パスを入力してください。

また、アプリケーション層では、これらの標準ディレクトリの多くを共有記憶域デバイス上に作成することをお薦めします。このようなディレクトリのために、共有記憶域場所の名前と共有場所をマウントするときに使用したマウント・ポイントを入力できる欄もこの表に用意されています。

詳細は、「エンタープライズ・デプロイメント用のファイル・システムの準備」を参照してください。

4.3.2.5 「データベース - 接続の詳細」タブの使用

エンタープライズ・デプロイメント・トポロジのインストールおよび構成時には、多くの場合、高可用性のOracle Real Application Clusters (RAC)データベースに接続する必要があります。このガイドの手順では、構成ウィザードやリポジトリ作成ユーティリティなどのツールからデータベースに接続するために指定する必要がある情報を示す一連の変数が記述されています。

このタブを使用して、これらの変数の、データベース・インストールにおける実際の値を入力し、いつでも参照できるようにしておいてください。

詳細は、「エンタープライズ・デプロイメント用のデータベースの準備」を参照してください。

4.4 エンタープライズ・デプロイメント・ワークブックの使用対象者

エンタープライズ・デプロイメント・ワークブックの詳細は、リソースの各カテゴリの計画、取得または設定を担当する個人またはチームによって入力されます。

エンタープライズ・デプロイメント・ワークブックの情報はカテゴリごとに分かれています。組織構成およびチームで規定されているロールに応じて、ワークブックの詳細を記入する組織内の特定の個人を割り当てることができます。同様に、各カテゴリの情報は、リソースの各カテゴリの計画、取得または設定を担当する個人またはチームに割り当てることができます。

たとえば、ワークブックは組織内の次のロールを担う人物が記入、確認および使用できます。

- 情報テクノロジ(IT)担当責任者

- アーキテクト

- システム管理者

- ネットワーク・エンジニア

- データベース管理者

5 エンタープライズ・デプロイメント用のリソースの取得

Oracle WebCenter Portalの参照用トポロジを構成する前に、必要なハードウェア、ソフトウェアおよびネットワーク設定を取得することはきわめて重要です。

この章では、必須IPアドレスの予約およびエンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得について説明します。

- エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件
エンタープライズ・デプロイメント・トポロジのハードウェア・ロード・バランサの要件、ホスト・コンピュータのハードウェア要件およびオペレーティング・システム要件を理解することは重要です。

- エンタープライズ・デプロイメント用の必須IPアドレスの予約
エンタープライズ・トポロジをインストールして構成する前に、一連のIPアドレスを取得して予約する必要があります。予約する必要がある一連のIPアドレスは、この項にリストされています。

- エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得
エンタープライズ・トポロジのインストールおよび構成を開始する前に、トポロジの実装に必要なソフトウェア・ディストリビューションを見つけてダウンロードする必要があります。

親トピック: エンタープライズ・デプロイメントの準備

5.1 エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件

エンタープライズ・デプロイメント・トポロジのハードウェア・ロード・バランサの要件、ホスト・コンピュータのハードウェア要件およびオペレーティング・システム要件を理解することは重要です。

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

- ハードウェア・ロード・バランサの要件
この項では、外部ロード・バランサの適切な機能を示します。

- ホスト・コンピュータのハードウェア要件
この項では、エンタープライズ・デプロイメント・トポロジをサポートするように構成されるホスト・コンピュータの取得に役立つ情報を提供します。

- エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件
この項では、オペレーティング・システム要件の詳細について説明します。

5.1.1 ハードウェア・ロード・バランサの要件

この項では、外部ロード・バランサの適切な機能を示します。

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

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

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

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

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

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

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

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

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

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

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

- ロード・バランサはSSLリクエストをロード・バランサで終了して、同等の非SSLプロトコル(たとえば、HTTPSからHTTP)を使用してトラフィックを実際のバックエンド・サーバーに転送できる必要があります。

- SSLアクセラレーション(これは推奨する機能ですが、エンタープライズ・トポロジに必須ではありません)。

- TCP/IPリクエストをルーティングする機能: これは、TCP経由のMinimum Lower Layer Protocol (MLLP)を使用するOracle SOA Suite for healthcare integrationの要件です。

5.1.2 ホスト・コンピュータのハードウェア要件

この項では、エンタープライズ・デプロイメント・トポロジをサポートするように構成されるホスト・コンピュータの取得に役立つ情報を提供します。

内容は次のとおりです。

- エンタープライズ・デプロイメントのホスト・コンピュータに関する一般的な考慮事項
この項では、エンタープライズ・デプロイメントのホスト・コンピュータに必要とされる一般的な考慮事項について説明します。

- Oracle Fusion Middlewareシステム要件の確認
この項では、環境が必要な最小要件を満たしていることを確認するために役立つシステム要件の情報に対する参照を提供します。

- エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタおよびプロセス数
この項では、エンタープライズ・デプロイメントに必要とされる標準的なメモリー、ファイル・ディスクリプタの数、およびオペレーティング・システムのプロセスとタスクの数の詳細について説明します。

- エンタープライズ・デプロイメントの標準的なディスク領域要件
この項では、このエンタープライズ・デプロイメントに必要とされる標準的なディスク領域について説明します。

5.1.2.1 エンタープライズ・デプロイメントのホスト・コンピュータに関する一般的な考慮事項

この項では、エンタープライズ・デプロイメントのホスト・コンピュータに必要とされる一般的な考慮事項について説明します。

Oracle Fusion Middlewareエンタープライズ・デプロイメントを構成するプロセスを開始する前に、適切なキャパシティ・プランニングを実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。これらの要件は、アプリケーションごと、あるいは使用しているカスタムOracle WebCenter Portalシステムごとに異なります。

この章で提供する情報は、ホスト・コンピュータ要件を判断するために役立つ一般的なガイドラインおよび情報です。これにより、個別の本番環境に対するキャパシティ・プランニングを実行する必要がなくなるわけではありません。

注意:

この項でホスト・コンピュータを取得し確保したら、ホスト名とシステム特性をエンタープライズ・デプロイメント・ワークブックに記録してください。これらのアドレスは、後で各ホスト・コンピュータでIPアドレスを有効化するときに使用します。

詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください

5.1.2.2 Oracle Fusion Middlewareシステム要件の確認

この項では、環境が必要な最小要件を満たしていることを確認するために役立つシステム要件の情報に対する参照を提供します。

Oracle Fusion Middlewareのシステム要件および仕様を参照し、環境がインストールする製品の最小インストール要件を満たしていることを確認します。

要件および仕様のドキュメントには、Oracle Fusion Middlewareの一般的なハードウェアとソフトウェアの要件、ディスク領域とメモリーの最小要件、データベース・スキーマの要件、および必要なシステム・ライブラリおよびパッケージに関する情報が記載されています。

また、Oracle Fusion Middlewareデプロイメントのメモリー要件を見積るための一般的なガイドラインも記載されています。

5.1.2.3 エンタープライズ・デプロイメントに必要な標準的なメモリー、ファイル・ディスクリプタおよびプロセス数

この項では、エンタープライズ・デプロイメントに必要とされる標準的なメモリー、ファイル・ディスクリプタの数、およびオペレーティング・システムのプロセスとタスクの数の詳細について説明します。

次の表は、標準的なOracle WebCenter Portalエンタープライズ・デプロイメントにおける管理サーバーおよび各管理対象サーバー・コンピュータに必要なメモリー、ファイル・ディスクリプタおよびプロセス数をまとめたものです。これらの値はあくまで例にすぎませんが、初期エンタープライズ・デプロイメントに最小限必要なメモリー量の見積りに使用できます。

この項の例は、参照用トポロジに示されている、WCPHOST1で必要な管理対象サーバーおよび他のサービスを構成するための最小限の要件を反映しています。

マシンの調達時には、各ホスト・コンピュータに搭載する必要がある物理メモリー量を判断するときの目安として、概算最大メモリー列の情報を使用してください。

ホスト・コンピュータ・ハードウェアを調達し、オペレーティング・システム要件を確認したら、ソフトウェア構成を調査して、オペレーティング・システムの設定が「ファイル・ディスクリプタ」列に記載されているオープン・ファイル数と「オペレーティング・システムのプロセスおよびタスク数」列に記載されているプロセス数に対応できるように構成されていることを確認します。

詳細は、「UNIXシステムでのオープン・ファイル制限とプロセス数の設定」を参照してください。

管理対象サーバー、ユーティリティまたはサービス

概算最大メモリー

ファイル・ディスクリプタ数

オペレーティング・システムのプロセスおよびタスク数

管理サーバー

3.5 GB

3500

165

WLS_WSM

3.0 GB

2000

130

WLS_Portal

4.0 GB

3100

240

WLS_Portlet

4.0 GB

2200

180

WLS_Collaboration

3.5 GB

1300

35

WLST (ノード・マネージャへの接続)

1.5 GB

910

20

構成ウィザード

1.5 GB

700

20

ノード・マネージャ

1.0 GB

720

15

合計

22.0 GB*

14430

805

*オペレーティング・システムとその他の追加メモリー要件を考慮した概算合計です。

5.1.2.4 エンタープライズ・デプロイメントの標準的なディスク領域要件

この項では、このエンタープライズ・デプロイメントに必要とされる標準的なディスク領域について説明します。

Oracle WebCenter Portal製品を含むOracle Fusion Middleware 12c (12.2.1.1)製品の最新のディスク領域要件は、「Oracle Fusion Middlewareのシステム要件と仕様」を確認してください。

また、次の表は、Oracle WebCenter Portalエンタープライズ・デプロイメントで必要になる標準的なディスク容量をまとめたものです。

この情報と「エンタープライズ・デプロイメント用のファイル・システムの準備」の情報に基づいて、デプロイメントに必要なディスク領域を判断してください。

サーバー

ディスク

データベース

nXm

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

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

WEBHOSTn

10 GB

WCPHOSTn

10 GB*

*共有記憶域Oracleホーム構成の場合、2つのインストールには合計20 GBあれば十分です。

5.1.3 エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件

この項では、オペレーティング・システム要件の詳細について説明します。

このガイドで説明するOracle Fusion Middlewareソフトウェア製品およびコンポーネントは、Oracle Fusion Middlewareのシステム要件と仕様に記載されている様々なオペレーティング・システムおよびプラットフォームで動作保証されています。

注意:

このガイドでは、Oracle Linuxシステムにおけるエンタープライズ・デプロイメント参照用トポロジの実装を中心に取り上げています。

このトポロジは、動作保証済でサポートされている任意のオペレーティング・システムで実装可能ですが、このガイドの例には、多くの場合、Oracle Linux上でbashシェルを使用して実行する必要があるコマンドと構成手順が示されています。

5.2 エンタープライズ・デプロイメント用の必須IPアドレスの予約

エンタープライズ・トポロジをインストールして構成する前に、一連のIPアドレスを取得して予約する必要があります。予約する必要がある一連のIPアドレスは、この項にリストされています。

エンタープライズ・トポロジのインストールおよび構成を開始する前に、次の一連のIPアドレスを取得および予約する必要があります。

- トポロジのために取得した各ホスト・コンピュータの物理IP (IP)アドレス

- 管理サーバーの仮想IP (VIP)アドレス

- サーバー全体の移行に対して構成された各管理対象サーバーの追加VIPアドレス
自動サービス移行をサポートするFusion Middleware 12c製品の場合、管理対象サーバーのVIPは通常は必要ありません。

- 各VIPにマップされる一意の仮想ホスト名。

ネットワーク管理者と協力して、これらの必須VIPが、ご使用のDNSサーバーに定義されていることを確認できます。(非本番環境では、かわりに/etc/hostsファイルを使用してこれらの仮想ホストを定義できます)。

詳細な情報は、次のトピックを参照してください

- 仮想IP (VIP)アドレスとは
この項では、仮想IPアドレスを定義し、その用途について説明します。

- 仮想ホスト名と仮想IPアドレスを使用する理由
特にエンタープライズ・デプロイメントの場合、一連のVIPおよびそれらがマップされている仮想ホスト名を、社内ネットワーク上で予約して有効化することが重要です。

- エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス
この項では、通常のOracle WebCenter Portalエンタープライズ・デプロイメント・トポロジの管理サーバーと各管理対象サーバーに必要な物理IP (IP)および仮想IP (VIP)アドレスについて説明します。

5.2.1 仮想IP (VIP)アドレスとは

この項では、仮想IPアドレスを定義し、その用途について説明します。

仮想IPアドレスは、ホストの主要IPアドレスと同じサブネットに属する、未使用のIPアドレスです。これは、ホストに手動で割り当てられます。コンピュータで障害が発生した場合は、仮想アドレスをトポロジ内の新しいホストに割り当てることができます。このガイドの用途では、仮想IPアドレスはホスト間で再割当て可能なアドレスとして、物理IPアドレスはハードウェア・ホスト・コンピュータに永続的に割り当てられるアドレスとして扱います。

5.2.2 仮想ホスト名と仮想IPアドレスを使用する理由

特にエンタープライズ・デプロイメントの場合、一連のVIPおよびそれらがマップされている仮想ホスト名を、社内ネットワーク上で予約して有効化することが重要です。

ホスト名は、様々なノードを通して伝播される適切な/etc/hostsファイルをかわりに使用して解決できます。

IPアドレスが割り当てられたホスト・コンピュータに障害が発生した場合は、割り当てられた管理対象サーバーの実行を新しいホストが引き継ぐことができるように、このIPアドレスは同じサブネット内の別のホスト・コンピュータに割り当てることができます。

管理サーバーの仮想IPアドレスの再割当ては手動で実行する必要がありますが、管理対象サーバーの仮想IPアドレスの再割当ては、Oracle WebLogic Serverのサーバー全体の移行機能を使用して自動的に実行できます。

サーバー全体の移行を使用する必要があるかどうかは、デプロイする製品およびその製品で自動サービス移行がサポートされているかどうかによって異なります。

5.2.3 エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス

この項では、通常のOracle WebCenter Portalエンタープライズ・デプロイメント・トポロジの管理サーバーと各管理対象サーバーに必要な物理IP (IP)および仮想IP (VIP)アドレスについて説明します。

エンタープライズ・デプロイメントのインストールおよび構成を開始する前に、表5-1のVIPに対応する一連のホスト名およびIPアドレスを予約します。

VIPには任意の一意のホスト名を割り当てることができますが、このガイドでは、この表の推奨ホスト名を使用して各VIPを参照します。

注意:

この項でIPアドレスおよび対応する仮想ホスト名を取得および予約したら、それらのIPアドレスとホスト名の値をエンタープライズ・デプロイメント・ワークブックに記録してください。これらのアドレスは、後で各ホスト・コンピュータでIPアドレスを有効化するときに使用します。

詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください

表5-1 エンタープライズ・デプロイメントに必要な仮想IPアドレスのサマリー

仮想IP

VIPのマップ先

説明

VIP1

ADMINVHN

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

5.3 エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得

エンタープライズ・トポロジのインストールおよび構成を開始する前に、トポロジの実装に必要なソフトウェア・ディストリビューションを見つけてダウンロードする必要があります。

次の表に、取得する必要のあるディストリビューションを示します。

Oracle Fusion Middlewareソフトウェアの入手方法の一般情報は、『Oracle Fusion Middlewareのインストールのプランニング』の製品ディストリビューションの入手に関する項を参照してください。

特定のOracle Fusion Middleware製品の場所とダウンロードに固有の詳細は、OTNのOracle Fusion Middlewareダウンロード、インストール、構成のReadmeファイルを参照してください。

ディストリビューション

インストーラ・ファイル名

説明

Oracle Fusion Middleware 12c (12.2.1.2.0) Infrastructure

fmw_12.2.1.2.0_infrastructure_generic.jar

このディストリビューションをダウンロードしてOracle Fusion Middleware Infrastructureをインストールします。これには、Oracle WebLogic ServerおよびOracle Fusion Middleware製品に必要なJava Required Filesソフトウェアが含まれています。

このディストリビューションによってリポジトリ作成ユーティリティ(RCU)もインストールされます。これは、以前のOracle Fusion Middlewareリリースでは独自のディストリビューションにパッケージされていました。

Oracle HTTP Server 12c (12.2.1.2.0)

fmw_12.2.1.2.0_ohs_linux64.bin

このディストリビューションをダウンロードして、Web層にOracle HTTP Serverソフトウェアをインストールします。

Oracle Fusion Middleware 12c (12.2.1.2.0) WebCenter Portal

fmw_12.2.1.2.0_wcportal_generic.jar

このディストリビューションをダウンロードして、Oracle WebCenter Portalソフトウェアをインストールします。

Oracle Fusion Middleware 12c (12.2.1.2.0) WebCenter Content

fmw_12.2.1.2.0_wccontent_generic.jar

Oracle WebCenter ContentをWebCenter Portalトポロジに追加する場合は、このディストリビューションをダウンロードします。

Oracle Fusion Middleware 12c (12.2.1.2.0) SOA SuiteおよびBusiness Process Management

fmw_12.2.1.2.0_soa_generic.jar

Oracle SOA SuiteをWebCenter Portalトポロジに追加する場合は、このディストリビューションをダウンロードします。

6 エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

ハードウェア・ロード・バランサの構成方法およびファイアウォールでエンタープライズ・デプロイメントに対して開く必要があるポートの構成方法を理解することは重要です。

- ハードウェア・ロード・バランサでの仮想ホストの構成
ハードウェア・ロード・バランサを構成すると、様々な種類のネットワーク・トラフィックや監視において、円滑にリクエストを認識して複数の仮想サーバーと関連ポートにルーティングできるようになります。

- エンタープライズ・デプロイメントのファイアウォールとポートの構成
管理者はOracle Fusion Middlewareの様々な製品およびサービスで使用されるポート番号を理解することが重要です。そうすることで、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにし、エンタープライズ・トポロジのファイアウォールで正しいポートを開くことができます。

親トピック: エンタープライズ・デプロイメントの準備

6.1 ハードウェア・ロード・バランサでの仮想ホストの構成

ハードウェア・ロード・バランサを構成すると、様々な種類のネットワーク・トラフィックや監視において、円滑にリクエストを認識して複数の仮想サーバーと関連ポートにルーティングできるようになります。

次のトピックでは、ハードウェア・ロード・バランサの構成方法について説明し、必要な仮想サーバーのサマリーを提供し、それらの仮想サーバーのための追加手順を示します。

- ハードウェア・ロード・バランサ構成の概要

- ハードウェア・ロード・バランサの構成の一般的な手順

- エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー

- admin.example.comに関する追加手順

- wcp.example.comに関する追加手順

- wcpinternal.example.comに関する追加手順

6.1.1 ハードウェア・ロード・バランサ構成の概要

トポロジのダイアグラムに示すように、リクエストを認識し、様々な種類のネットワーク・トラフィックや監視に対応する複数の仮想サーバーと関連ポートにリクエストをルーティングできるように、ハードウェア・ロード・バランサを構成する必要があります。

ロード・バランシング・デバイスにおける仮想サーバーとは、ロード・バランシングのために複数の物理サーバーを1つのサーバーのように見せかけることができる構成です。仮想サーバーは通常、IPアドレスとサービスによって表され、受信したクライアント・リクエストをサーバー・プール内の各サーバーに配信するために使用されます。

仮想サーバーは、(エンタープライズ・デプロイメントで使用可能な各種サービス用の)適切なホスト・コンピュータおよびポートにトラフィックをルーティングするように構成しておく必要があります。

さらに、サービスが停止したときに特定のサーバーへのトラフィックをできるだけ早く停止できるように、ホスト・コンピュータとポートの可用性を監視するようにロード・バランサを構成する必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

ロード・バランサを構成した後で、同じ名前を持つ一連の仮想ホストを、ロード・バランサに定義した仮想サーバーとして認識するように、Web層のWebサーバー・インスタンスを構成することも可能です。Webサーバーは、ハードウェア・ロード・バランサから受信した各リクエストを、リクエストのヘッダーに記述されているサーバー名に基づいて適切にルーティングできます。詳細は、「管理およびOracle Web Services Manager用のOracle HTTP Serverの構成」を参照してください。

6.1.2 ハードウェア・ロード・バランサの構成の一般的な手順

次の手順では、エンタープライズ・デプロイメントのハードウェア・ロード・バランサを構成する標準的な手順の概要を示します。

特定のロード・バランサの実際の構成手順は、ロード・バランサの特定のタイプによって異なります。また、ロード・バランシングされるプロトコルのタイプによっても違いが生じる場合があります。たとえば、TCP仮想サーバーとHTTP仮想サーバーはプールで異なる種類のモニターを使用します。実際の手順は、ベンダーが提供するドキュメントを参照してください。

1. サーバーのプールを作成します。このプールには、ロード・バランシングの定義に含まれているサーバーとポートのリストが格納されます。
たとえば、Webホスト間のロード・バランシングの場合、ポート7777のWEBHOST1およびWEBHOST2の両ホストにリクエストを送信するサーバーのプールを作成します。

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

3. アプリケーションに対するリクエストを受信するアドレスおよびポートのロード・バランサで必要な仮想サーバーを作成します。
エンタープライズ・デプロイメントに必要な仮想サーバーの完全なリストは、「エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー」を参照してください。

ロード・バランサで各仮想サーバーを定義するときは、次のことを考慮します。

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

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

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

6.1.3 エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー

このトピックでは、エンタープライズ・デプロイメントに必要な仮想サーバーについて詳細に説明します。

次の表は、Oracle WebCenter Portalエンタープライズ・トポロジのハードウェア・ロード・バランサで定義する必要がある仮想サーバーの一覧です。

仮想ホスト

サーバー・プール

プロトコル

SSL終端

外部

admin.example.com:80

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

HTTP

なし

なし

wcp.example.com:443

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

HTTPS

あり

あり

wcpinternal.example.com:80

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

HTTP

なし

なし

wcpinternal.example.com:6300

WCCHOST1.example.com:4444 WCCHOST2.example.com:4444

TCP

いいえ

いいえ

6.1.4 admin.example.comに関する追加手順

この項では、仮想サーバーadmin.example.comに必要な追加手順を示します。

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

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

6.1.5 wcp.example.comに関する追加手順

この項では、仮想サーバー(wcp.example.com)を構成するための追加手順を示します。

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

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

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

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

- この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。
これらのコンテキスト文字列は、リクエストをOracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlにルーティングするため、admin.example.comからシステムへのアクセス時にのみ使用する必要があります。

6.1.6 wcpinternal.example.comに関する追加手順

この項では、仮想サーバー(wcpinternal.example.com)を構成するための追加手順を示します。

この仮想サーバーは、WebCenter PortalおよびWebCenter Contentのサービスの内部起動に使用されます。このURLはインターネットに公開されずに、イントラネットからのみアクセスできます。クライアントからの入力トラフィックは、SSL対応ではありません。2つの仮想サーバーがこのアドレスを異なるポートで使用するハードウェア・ロード・バランサで構成されます。

このアドレスは、次のようにHTTPとRemote Intradoc Client (RIDC)の両方のトラフィックに使用されます。

- HTTP接続は、ポート80のハードウェア・ロード・バランサで受信され、OHSのデフォルト・ポート7777のWEBHOSTサーバーに転送されます。

- RIDC TCP接続は、ポート6300のハードウェア・ロード・バランサで受信され、RIDCのデフォルト・ポート4444のWCCHOSTサーバーに転送されます。

注意:

RIDCサービス・ポート番号(4444など)で単純に受信して転送することに比べて、固有のポートをフロントエンド構成に使用することをお薦めします。

2つのサーバー・プールが次のトポロジをサポートするようにハードウェア・ロード・バランサで構成されます。

1. Webサーバー: 構成: WEBHOST1:7777およびWEBHOST2:7777

2. RIDCサーバー: 構成: WCCHOST1:4444およびWCCHOST2:4444

RIDCトラフィックはロード・バランサのポート6300 (6300は主にマスキング用)を使用しますが、トラフィックは最終的にWebCenterホストのRIDCポート(4444)にルーティングされます。

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

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

- wcp.example.comと同様に、この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

6.2 エンタープライズ・デプロイメントのファイアウォールとポートの構成

管理者はOracle Fusion Middlewareの様々な製品およびサービスで使用されるポート番号を理解することが重要です。そうすることで、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにし、エンタープライズ・トポロジのファイアウォールで正しいポートを開くことができます。

次の表は、トポロジのファイアウォールで開く必要があるポートの一覧です。

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

- FW1は、最も外側のファイアウォールを表します。

- FW2は、Web層とアプリケーション層の間のファイアウォールを表します。

- FW3は、アプリケーション層とデータ層の間のファイアウォールを表します。

表6-1 すべてのFusion Middlewareエンタープライズ・デプロイメントに共通のファイアウォール・ポート

タイプ

ファイアウォール

ポートとポートの範囲

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

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

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

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

FW0

80

HTTP/ロード・バランサ

インバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

FW0

443

HTTPS/ロード・バランサ

インバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

FW1

80

HTTPS/ロード・バランサ

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

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

FW1

443

HTTPS/ロード・バランサ

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

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

コールバックおよびアウトバウンド呼出し

FW1

80

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

コールバックおよびアウトバウンド呼出し

FW1

443

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

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

該当なし

7777

HTTP

該当なし

該当なし

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

FW1

7001

HTTP/t3

インバウンド

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

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

FW1

OHS管理ポート(7779)

それぞれTCPとHTTP

アウトバウンド

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

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

該当なし

該当なし

該当なし

該当なし

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

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

FW1

7001

HTTP/管理サーバーとEnterprise Manager

t3

両方

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

データベース・アクセス

FW2

1521

SQL*Net

両方

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

デプロイメントの一貫性

該当なし

8088

範囲: 8000から8090

該当なし

該当なし

Oracle Unified Directoryアクセス

FW2

389

636 (SSL)

LDAPまたはLDAP/ssl

インバウンド

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

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

Gridlinkに必要。ONSサーバーは各データベース・サーバー上で稼働します。

タイプ

ファイアウォール

ポートとポートの範囲

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

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

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

WSM-PMのアクセス

FW1

7010

範囲: 7010から7999

HTTP/WLS_WSM-PMn

インバウンド

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

ポータル・サーバーへのアクセス

FW1

9001

HTTP / WLS_Portaln

インバウンド

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

ポートレット・サーバーへのアクセス

FW1

9002

HTTP / WLS_Portletn

インバウンド

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

コラボレーション・サーバーへのアクセス

FW1

9003

HTTP / WLS_Collabn

インバウンド

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

RIDC APIリクエスト

FW1

6300

TCP/WLS_WCCn

インバウンド

該当なし

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

エンタープライズ・デプロイメント用のファイル・システムの準備には、ローカルおよび共有記憶域の要件、およびエンタープライズ・トポロジのインストール時および構成時における重要なディレクトリとファイルの場所の参照に使用される用語を理解することが含まれます。

この章では、Oracle Fusion Middlewareエンタープライズ・デプロイメント用にファイル・システムを準備する方法について説明します。

- エンタープライズ・デプロイメント用のファイル・システムの準備の概要
エンタープライズ・デプロイメントの理解、構成および管理が容易になるように記憶域を設定することは重要です。

- エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項
エンタープライズ・デプロイメントをインストールして構成する場合、共有記憶域に関する次のガイドラインを実践することをお薦めします。

- エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解
この項のダイアグラムは、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで推奨されるディレクトリ構造を示しています。

- このガイドで使用するファイル・システムとディレクトリ変数
ファイル・システムのディレクトリおよびこれらのディレクトリの参照に使用するディレクトリ変数を理解することは、エンタープライズ・デプロイメント・トポロジのインストールと構成に不可欠です。

- エンタープライズ・デプロイメント用のディレクトリの作成およびマウントについて
エンタープライズ・デプロイメントで最上位ディレクトリを作成またはマウントする場合、次のベスト・プラクティスを実践することをお薦めします。

- エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー
標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントにおける共有ボリュームおよびその目的を理解することは重要です。

親トピック: エンタープライズ・デプロイメントの準備

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

記憶域は、エンタープライズ・デプロイメントがわかりやすくなり、構成および管理が容易になるように設定することが重要です。

この章では、エンタープライズ・デプロイメント用のファイル・システムを準備するプロセスの概要について説明します。この章の情報に従って記憶域を設定することをお薦めします。この章で定義されている用語は、このガイド内のダイアグラムおよび手順で使用されます。

この章を参照情報として使用すると、インストールおよび構成手順で使用されているディレクトリ変数について理解できます。

その他のディレクトリ・レイアウトも可能であり、サポートされていますが、このガイドで採用するモデルは、可用性を最大化するために設計されており、コンポーネントの最良の独立性と構成の対称性の両方を実現し、バックアップおよび障害時リカバリを容易にします。ドキュメントの残りの部分では、このディレクトリ構造およびディレクトリ用語を使用します。

7.2 エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項

エンタープライズ・デプロイメントをインストールして構成する場合、共有記憶域に関する次のガイドラインを実践することをお薦めします。

この章で詳述する推奨事項を実行する前に、『高可用性ガイド』で共有記憶域の使用に関する推奨事項と一般情報を確認してください。

この章の推奨事項は、『高可用性ガイド』に記載されている概念とガイドラインに基づいています。

表7-1に、確認しておく必要がある項の一覧と、それらの概念がエンタープライズ・デプロイメントにどのように適用されるかを示します。

表7-1 『高可用性ガイド』の共有記憶域に関するリソース

『高可用性ガイド』の項

エンタープライズ・デプロイメントにおける意義

共有記憶域に関する前提条件

共有記憶域向けに最適化された、ディスク形式のガイドラインとハードウェア・デバイス要件について説明します。

バイナリ(Oracleホーム)ディレクトリ用の共有記憶域の使用

複数のホストから使用可能な共有記憶域デバイスにOracleホームを格納する際のオプションについて説明しています。

エンタープライズ・デプロイメントの用途では、別々のストレージ・ボリューム上に格納した冗長Oracleホームを使用することをお薦めします。

別のボリュームがない場合は、共有ディスク上の別のパーティションを使用して、アプリケーション層のホストに冗長Oracleホームを用意してください。

ドメイン構成ファイル用の共有記憶域の使用

ドメイン内の管理サーバーと管理対象サーバーに別々のドメイン・ホームを作成する概念について説明しています。

エンタープライズ・デプロイメントでは、管理サーバーのドメイン・ホームの場所をASERVER_HOME変数で表します。

JMSストアおよびJTAログ用の共有記憶域の要件

エンタープライズ・デプロイメント用のトランザクション・ログとJMSストアの場所を設定する手順について説明しています。

7.3 エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解

この項のダイアグラムは、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントで推奨されるディレクトリ構造を示しています。

ダイアグラムに示す各ディレクトリには、Oracle Fusion Middlewareインストーラによってディスク上にインストールされるバイナリ・ファイル、ドメイン構成プロセスを通じて生成されるドメインごとのファイルの他に、Oracle WebLogic Serverのpackコマンドとunpackコマンドによって様々なホスト・コンピュータに伝播されるドメイン構成ファイルが格納されます。

- 図7-1は、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で共有記憶域デバイスに作成されているディレクトリ構造を示しています。共有記憶域のディレクトリは、アプリケーション層のホスト・コンピュータからアクセス可能です。

- 図7-2は、Oracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で、標準的なアプリケーション層のホスト用のローカル記憶域デバイスに作成されているディレクトリ構造を示しています。特に、管理対象サーバーはアプリケーション層のホスト・コンピュータ用のローカル記憶域デバイスに格納されます。

- 図7-3は、Oracle Fusion Middlewareエンタープライズ・デプロイメントのインストールおよび構成が完了した時点で、標準的なWeb層のホスト用のローカル記憶域デバイスに作成されているディレクトリ構造を示しています。ソフトウェア・バイナリ(Oracleホーム内)は、Web層のホストごとのローカル記憶域デバイスにインストールされます。

該当する場合、ダイアグラムには、このガイドのインストールおよび構成手順でディレクトリ場所を表すために使用する標準変数も記載されています。

図7-1 エンタープライズ・デプロイメントで推奨される共有記憶域ディレクトリ構造

*詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

図7-2 エンタープライズ・デプロイメントで推奨されるアプリケーション層のホスト・コンピュータ向けローカル記憶域ディレクトリ構造

*詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

図7-3 エンタープライズ・デプロイメントで推奨されるWeb層のホスト・コンピュータ向けローカル記憶域ディレクトリ構造

7.4 このガイドで使用するファイル・システムとディレクトリ変数

ファイル・システムのディレクトリおよびこれらのディレクトリの参照に使用するディレクトリ変数を理解することは、エンタープライズ・デプロイメント・トポロジのインストールと構成に不可欠です。

表7-2は、ファイル・システムのディレクトリとアプリケーション層でのそれらのディレクトリの参照に使用されるディレクトリ変数を示しています。表7-3は、ファイル・システムのディレクトリとWeb層でのそれらのディレクトリの参照に使用される変数を示しています。

共有記憶域を使用している場合のこれらのディレクトリのマウントの詳細は、「エンタープライズ・デプロイメント用のディレクトリの作成およびマウント」を参照してください。

このガイド全体を通して、トポロジのインストールおよび構成に関する手順では、ここに示す変数を使用してディレクトリの場所を参照します。

この項にリストされている各ディレクトリに対してオペレーティング・システム変数を定義することもできます。システム変数をご使用のUNIXシェルで定義しておけば、このドキュメントの記載どおりに変数を使用できるので、変数を実環境における実際の値と対応付ける必要がなくなります。

注意:

ストレージ・デバイスを構成して推奨ディレクトリ構造を作成したら、実際のディレクトリ・パスをエンタープライズ・デプロイメント・ワークブックに記録してください。これらのアドレスは、後で各ホスト・コンピュータでIPアドレスを有効化するときに使用します。

詳細は、エンタープライズ・デプロイメント・ワークブックの使用を参照してください。

表7-2 アプリケーション層の主要なディレクトリ変数のサンプル値

ディレクトリ変数

説明

アプリケーション層のサンプル値

ORACLE_BASE

Oracle製品のインストール先であるベース・ディレクトリ。

/u01/oracle

ORACLE_HOME

製品バイナリ用の読取り専用場所。アプリケーション層のホスト・コンピュータの場合は、共有ディスクに格納されます。

Oracleホームは、Oracle Fusion Middleware Infrastructureソフトウェアのインストール時に作成されます。

その後、その他のOracle Fusion Middleware製品を同じOracleホームにインストールできます。

/u01/oracle/products/fmw

ORACLE_COMMON_HOME

共通のユーティリティ、ライブラリおよび他の共有Oracle Fusion Middleware製品を格納する、Oracle Fusion MiddlewareのOracleホーム内のディレクトリ。

/u01/oracle/products/fmw/oracle_common

WL_HOME

Oracle WebLogic Serverソフトウェア・バイナリを格納するOracleホーム内のディレクトリ。

/u01/oracle/products/fmw/wlserver

PROD_DIR

インストールするOracle Fusion Middleware製品ごとの製品ディレクトリ。

/u01/oracle/products/fmw/prod_dir
製品は、エンタープライズ・デプロイメントに応じてsoa、wcc、biまたはその他の値にすることができます。

EM_DIR

Oracle Enterprise Manager Fusion Middleware Controlソフトウェア・バイナリの格納に使用される製品ディレクトリ。

/u01/oracle/products/fmw/em

JAVA_HOME

サポートされているJava Development Kit (JDK)のインストール先。

/u01/oracle/products/jdk

SHARED_CONFIG_DIR

ドメイン構成、キーストア、ランタイム・アーティファクト、アプリケーション・デプロイメントなど、共有環境構成ファイルのための共有親ディレクトリ

/u01/oracle/config

ASERVER_HOME

管理サーバーのドメイン・ホーム。共有ディスクにインストールされます。

/u01/oracle/config/domains/domain_name

この例では、domain_nameをWebLogic Serverドメイン名で置き換えます。

MSERVER_HOME

管理対象サーバーのドメイン・ホーム。unpackコマンドによってアプリケーション層のホストごとのローカル・ディスクに作成されます。

/u02/oracle/config/domains/domain_name

APPLICATION_HOME

アプリケーションのホーム・ディレクトリ。アプリケーション層のすべてのホスト・コンピュータからアクセスできるように、共有ディスクにインストールされます。

/u01/oracle/config/applications
/domain_name

ORACLE_RUNTIME

このディレクトリには、JMSログやTLogなどのOracleランタイム・アーティファクトが含まれます。

通常、このディレクトリは、ドメイン内のすべてのホストからアクセス可能な共有ファイル・システムとして個別にマウントします。

構成ウィザードを実行したり、構成後タスクを実行して、JMSストアまたはtlog永続ストアの場所を特定する場合は、このディレクトリをドメイン名、クラスタ名およびディレクトリの目的で修飾して使用できます。

次に例を示します。

ORACLE_RUNTIME/cluster_name/jms

/u01/oracle/runtime/

NM_HOME

マシン別ノード・マネージャの起動スクリプトおよび構成ファイルによって使用されるディレクトリ。

注意:

このディレクトリは、マシン別ノード・マネージャ構成を使用している場合にのみ必要となります。

詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

/u02/oracle/config/node_manager

DEPLOY_PLAN_HOME

デプロイメント・プランのディレクトリ。アプリケーション・デプロイメント・プラン用のデフォルトの場所として使用されます。

注意:

このディレクトリは、カスタム・アプリケーションをアプリケーション層にデプロイしている場合にのみ必要となります。

/u01/oracle/config/dp

KEYSTORE_HOME

カスタム証明書およびキーストアの共有場所。

/u01/oracle/config/keystores

表7-3 Web層の主要なディレクトリ変数のサンプル値

ディレクトリ変数

説明

Web層のサンプル値

OHS_ORACLE_HOME

Oracle HTTP Server製品バイナリ用の読取り専用場所。Web層のホスト・コンピュータの場合、このディレクトリはローカル・ディスクに格納されます。

Oracleホームは、Oracle HTTP Serverソフトウェアのインストール時に作成されます。

/u02/oracle/products/fmw

ORACLE_COMMON_HOME

共通のユーティリティ、ライブラリおよび他の共有Oracle Fusion Middleware製品を格納する、Oracle HTTP ServerのOracleホーム内のディレクトリ。

/u02/oracle/products/fmw
/oracle_common

WL_HOME

Oracle WebLogic Serverソフトウェア・バイナリを格納するOracleホーム内のディレクトリ。

/u02/oracle/products/fmw/wlserver

PROD_DIR

インストールするOracle Fusion Middleware製品ごとの製品ディレクトリ。

/u02/oracle/products/fmw/ohs

JAVA_HOME

サポートされているJava Development Kit (JDK)のインストール先。

/u02/oracle/products/jdk

OHS_DOMAIN_HOME

Web層の各ホストのローカル・ディスク上にOracle HTTP Serverをインストールする際に作成される、スタンドアロンOracle HTTP Serverドメインのドメイン・ホーム。

/u02/oracle/config/domains/domain_name

OHS_CONFIG_DIR

各Webホスト上にある、編集を行ったOracle HTTP Server構成ファイル(httpd.confやmoduleconf/*.confなど)の場所。

このディレクトリは、OHSステージング・ディレクトリと呼ばれることもあります。ここで行った変更は、後でOHSランタイム・ディレクトリに伝播されます。

詳細は、『Oracle HTTP Server管理者ガイド』のステージング構成ディレクトリとランタイム構成ディレクトリに関する項を参照してください。

/u02/oracle/config/domains
/domain_name/config/fmwconfig
/components/OHS
/instance_name

7.5 エンタープライズ・デプロイメント用のディレクトリの作成およびマウントについて

エンタープライズ・デプロイメントで最上位ディレクトリを作成またはマウントする場合、次のベスト・プラクティスを実践することをお薦めします。

最上位ディレクトリを作成およびマウントするときには、次のベスト・プラクティスに注意してください。

- アプリケーション層については、WCPHOST2にマウントされる別の共有記憶域ボリュームまたは別のパーティションにOracleホーム(ソフトウェア・バイナリの格納先)をインストールします。WCPHOST2上のバイナリへのディレクトリ・パスが、WCPHOST1上のディレクトリ・パスと同一であることを確認してください。
次に例を示します。

/u01/oracle/products/fmw/

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

- このエンタープライズ・デプロイメント・ガイドでは、Oracle Web Tierソフトウェアがローカル・ディスクにインストールされることを想定しています。
Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用している場合、共有ディスクでOracle Web Tierバイナリのインストール(およびOracle HTTP Serverインスタンスの作成)を行うことができます。ただし、これを行う場合、共有ディスクをアプリケーション層に使用する共有ディスクとは別にする必要があり、層を横断する記憶域デバイスへのアクセスに適切なセキュリティ制限を適用することを検討する必要があります。

アプリケーション層サーバー(WCPHOST1およびWCPHOST2)の場合と同様に、両方のコンピュータで同じディレクトリ・パスを使用します。

次に例を示します。

/u02/oracle/products/fmw/

7.6 エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー

標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントにおける共有ボリュームおよびその目的を理解することは重要です。

次の表は、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントにおける共有ボリュームおよびその目的をまとめたものです。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

表7-4 エンタープライズ・デプロイメントの共有記憶域ボリューム

共有記憶域のボリューム

マウント先ホスト

マウント・ディレクトリ

説明および用途

NFSボリューム1

WCPHOST1

WCCHOST1

/u01/oracle/products/

WCPHOST1によって使用される製品バイナリのローカル記憶域。Oracleホーム・ディレクトリおよび製品ディレクトリはここにインストールされます。

NFSボリューム2

WCPHOST2

WCCHOST2

/u01/oracle/products/

WCPHOST2によって使用される製品バイナリのローカル記憶域。Oracleホーム・ディレクトリおよび製品ディレクトリはここにインストールされます。

NFSボリューム3

WCPHOST1 WCPHOST2

WCCHOST1

WCCHOST2

/u01/oracle/config/

すべてのホストにマウントされる管理サーバー・ドメイン構成。最初はWCPHOST1によって使用されますが、任意のホストにフェイルオーバーできます。

NFSボリューム4

WCPHOST1 WCPHOST2

WCCHOST1

WCCHOST2

/u01/oracle/runtime/

すべてのホストにマウントされるランタイム・アーティファクト・ディレクトリであり、必要なJMSログ、ブログ、すべてのクラスタ依存共有ファイルなどのランタイム・アーティファクトが含まれます。

NFSボリューム5

WCPHOST1

/u02/oracle/config/

WCPHOST1によって使用される管理対象サーバー・ドメイン・ディレクトリのローカル記憶域(プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域にある場合)。

NFSボリューム6

WCPHOST2

/u02/oracle/config/

WCPHOST2によって使用される管理対象サーバー・ドメイン・ディレクトリのローカル記憶域(プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域にある場合)。

NFSボリューム7

WEBHOST1

/u02/oracle/

プライベート管理対象サーバーのドメイン・ディレクトリが共有記憶域に配置されている場合の、Oracle HTTP Serverソフトウェア・バイナリ(Oracleホーム)およびWEBHOST1で使用されるドメイン構成ファイル用のローカル記憶域。

NFSボリューム8

WEBHOST2

/u02/oracle/

プライベート管理対象サーバーのドメイン・ディレクトリが共有記憶域に配置されている場合の、Oracle HTTP Serverソフトウェア・バイナリ(Oracleホーム)およびWEBHOST2で使用されるドメイン構成ファイル用のローカル記憶域。

NFSボリューム9

WCCHOST1

/u02/oracle/config/

WCCHOST1によって使用される管理対象サーバー・ドメイン・ディレクトリのローカル記憶域(プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域に配置される場合)。

NFSボリューム10

WCCHOST2

/u02/oracle/config/

WCCHOST2によって使用される管理対象サーバー・ドメイン・ディレクトリのローカル記憶域(プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域に配置される場合)。

8 エンタープライズ・デプロイメント用のホスト・コンピュータの準備

エンタープライズ・デプロイメント・トポロジを構成する前に、各コンピュータまたはサーバーに対して一連のタスクを実行することが重要です。これには、各ホストでのハードウェアおよびオペレーティング・システムの最小要件の確認、オペレーティング・システムのユーザーおよびグループの構成、Unicodeサポートの有効化、ホストへの必要な共有記憶域システムのマウント、および各ホストでの必要な仮想IPアドレスの有効化が含まれます。

この章では、エンタープライズ・デプロイメントをホストする各コンピュータまたはサーバーから実行する必要があるタスクについて説明します。

- 各ホストの最小ハードウェア要件の検証
エンタープライズ・デプロイメントに必要なハードウェアを用意した後、各ホスト・コンピュータが最小システム要件を満たしていることを確認することが重要です。

- Linuxオペレーティング・システムの要件の検証
この項では、エンタープライズ・デプロイメント用の標準的なLinuxオペレーティング・システムの設定について確認できます。

- オペレーティング・システムのユーザーおよびグループの構成
この項では、エンタープライズ・デプロイメントをホストする各コンピュータで定義するユーザーおよびグループのリストを示します。

- Unicodeサポートの有効化
Unicodeの文字を処理できるように、オペレーティング・システムでUnicodeサポートを有効にすることをお薦めします。

- 各ホストへの必要な共有ファイル・システムのマウント
アクセスが必要なすべてのサーバーに共有記憶域をマウントする方法を理解することは重要です。

- 各ホストでの必要な仮想IPアドレスの有効化
エンタープライズ・デプロイメント用にホストを準備するには、各ホストで必要な仮想IPアドレスを有効化する必要があります。使用しているのがOracle Enterprise Linux 5かOracle Enterprise Linux 6かに応じて手順が異なります。

親トピック: エンタープライズ・デプロイメントの準備

8.1 各ホストの最小ハードウェア要件の検証

エンタープライズ・デプロイメントに必要なハードウェアを用意した後、各ホスト・コンピュータが最小システム要件を満たしていることを確認することが重要です。

エンタープライズ・デプロイメントに必要なハードウェアを取得したら、各ホスト・コンピュータにログインし、「エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件」に示すシステム要件を確認します。

Oracle Exalogicなどの仮想サーバー環境にデプロイしている場合、仮想サーバーそれぞれが最小要件を満たしていることを確認します。

十分なローカル・ディスク記憶域があり、共有記憶域が「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されているように構成されていることを確認します。

次のように十分なスワップ領域および一時領域を確保します。

- スワップ領域: システムに500MB以上ある必要があります。

- 一時領域: /tmpに500MB以上の空き領域がある必要があります。

8.2 Linuxオペレーティング・システムの要件の検証

この項では、エンタープライズ・デプロイメント用の標準的なLinuxオペレーティング・システムの設定について確認できます。

ホスト・コンピュータが最小オペレーティング・システム要件を満たしていることを確認するには、動作保証済のオペレーティング・システムがインストールされていることと、そのオペレーティング・システムに必要なパッチがすべて適用されていることを確認してください。

さらに、エンタープライズ・デプロイメント用の標準的なLinuxオペレーティング・システムの設定について、次の項を確認してください。

- Linuxのカーネル・パラメータの設定

- UNIXシステムでのオープン・ファイル制限とプロセス数の設定

- DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認

8.2.1 Linuxのカーネル・パラメータの設定

次に示すkernel-parameterとshell-limitの値は、推奨値のみです。これらの値をチューニングしてシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。

カーネル・パラメータは、トポロジのすべてのノードで表8-1の最小値に設定する必要があります。

次の表の値は、現行のLinuxの推奨値です。Linuxおよびその他のオペレーティング・システムの最新の推奨値は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

データベースをホストにデプロイしている場合、追加のカーネル・パラメータを変更する必要がある場合があります。12c (12.2.1)の『Oracle Grid Infrastructureインストレーション・ガイドfor Linux』のカーネル・パラメータの構成に関する項を参照してください。

表8-1 UNIXのカーネル・パラメータ

パラメータ

値

kernel.sem

256 32000 100 142

kernel.shmmax

4294967295

これらのパラメータを設定するには:

1. rootとしてサインインし、ファイル/etc/sysctl.confのエントリを追加または修正します。

2. ファイルを保存します。

3. 次のコマンドを入力して、変更をアクティブ化します。
/sbin/sysctl -p

8.2.2 UNIXシステムでのオープン・ファイル制限とプロセス数の設定

UNIXオペレーティング・システムでは、Open File Limitは重要なシステム設定です。ホスト・コンピュータ上で動作するソフトウェアのパフォーマンス全体に影響を及ぼす可能性があります。

Oracle Fusion Middlewareエンタープライズ・デプロイメントに適したOpen File Limitの設定のための指針として、「ホスト・コンピュータのハードウェア要件」を参照してください。

注意:

次の例はLinuxオペレーティング・システム用です。オペレーティング・システムのドキュメントを確認して、システムで使用するコマンドを判別します。

詳細は、次の項を参照してください。

- 現在開いているファイル数の表示

- オペレーティング・システムのオープン・ファイルおよびプロセス制限の設定

8.2.2.1 現在開いているファイル数の表示

次のコマンドでオープンになっているファイル数を確認できます。

/usr/sbin/lsof | wc -l

オープン・ファイル制限を確認するには、次のコマンドを使用します。

Cシェル:

limit descriptors

Bash:

ulimit -n

8.2.2.2 オペレーティング・システムのオープン・ファイルおよびプロセス制限の設定

オープン・ファイル制限値を変更する手順は次のとおりです。

1. rootユーザーとしてサインインし、次のファイルを編集します。

/etc/security/limits.conf

2. limits.confファイルに次の行を追加します。(ここに示す値は例にすぎません):

* soft  nofile  4096
* hard  nofile  65536
* soft  nproc   2047
* hard  nproc   16384

nofilesの値はオープン・ファイル制限を表します。nproc値はプロセス制限を表します。

3. 変更内容を保存して、limits.confファイルを閉じます。

4. ホスト・コンピュータを再起動します。

8.2.3 DNSまたはホスト・ファイルでのIPアドレスとホスト名の確認

Oracleソフトウェアのインストールを開始する前に、ホストのIPアドレス、完全修飾ホスト名および短縮名がすべてDNSサーバーに登録されていることを確認します。または、ローカルhostsファイルを使用して、次のようなエントリを追加することもできます。

IP_Address Fully_Qualified_Name Short_Name

次に例を示します。

10.229.188.205  host1.example.com  host1

8.3 オペレーティング・システムのユーザーおよびグループの構成

この項では、エンタープライズ・デプロイメントをホストする各コンピュータで定義するユーザーおよびグループのリストを示します。

グループ

各ノードに次のグループを作成する必要があります。

- oinstall

- dba

ユーザー

各ノードに次のユーザーを作成する必要があります。

- nobody: 権限のないユーザー。

- oracle: Oracleソフトウェアの所有者。別の名前も使用できます。このアカウントのプライマリ・グループはoinstallにする必要があります。このアカウントは、dbaグループにも属している必要があります。

注意:

- グループoinstallは、Oracleソフトウェアが使用する共有記憶域およびローカル記憶域のすべてのファイル・システムに対する書込み権限を持っている必要があります。

- 各グループは、ノードごとに同じグループIDを持っている必要があります。

- 各ユーザーは、ノードごとに同じユーザーIDを持っている必要があります。

8.4 Unicodeサポートの有効化

Unicodeの文字を処理できるように、オペレーティング・システムでUnicodeサポートを有効にすることをお薦めします。

オペレーティング・システムの構成がOracle Fusion Middleware製品でサポートされる文字の動作に影響を与えることがあります。

UNIXオペレーティング・システムでは、LANGとLC_ALLの各環境変数をUTF-8文字セットを使用したロケールに設定し、Unicodeサポートを有効化することを強くお薦めします。これにより、Unicodeのすべての文字が処理できるようになります。たとえば、Oracle WebCenter PortalテクノロジはUnicodeに基づいています。

オペレーティング・システムがUTF-8以外のエンコードを使用するように構成されている場合、Oracle WebCenter Portalコンポーネントが予期しない動作をする可能性があります。たとえば、ASCII以外のファイル名の場合は、ファイルにアクセスできず、エラーが発生する可能性があります。オペレーティング・システムの制約によって発生する問題はサポート対象外となります。

8.5 各ホストへの必要な共有ファイル・システムのマウント

アクセスが必要なすべてのサーバーに共有記憶域をマウントする方法を理解することは重要です。

「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」の説明に従って構成された共有記憶域が、それを使用するホスト上で使用可能になっている必要があります。

エンタープライズ・デプロイメントでは、ハードウェア記憶域ファイラが存在することと、それがデプロイメント用に取得した各ホスト・コンピュータに接続されて使用可能になっていることが前提とされています。

共有記憶域を、アクセスが必要なすべてのサーバーにマウントする必要があります。

各ホストでは、適切な権限をNetwork Attached Storage (NAS)またはStorage Area Network (SAN)内で設定し、共有記憶域への書込みを可能にする必要があります。

共有記憶域のマウントについては、組織のベスト・プラクティスに従ってください。この項では、NFS記憶域を使用してLinuxでこれを行う方法の例を示します。

共有記憶域の場所を作成してマウントし、WCPHOST1とWCPHOST2が2つの別々のボリュームへのバイナリ・インストールである場合に、それらが同じ場所を参照できるようにする必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

次のコマンドを使用して、共有記憶域をNAS記憶域デバイスからLinuxホストにマウントします。別のタイプの記憶域デバイスまたはオペレーティング・システムを使用している場合、これを行う方法の詳細は製造元のドキュメントを参照してください。

注意:

共有記憶域のファイル・システムの作成に使用されるユーザー・アカウントは、これらのファイルに対する読取り、書込みおよび実行権限を持ちます。オペレーティング・システム・グループにおける他のユーザーは、ファイルの読取りや実行は可能ですが、書込み権限はありません。

インストールと構成の権限の詳細は、Oracle Fusion Middlewareインストレーション・プランニング・ガイドのインストレーション・ユーザーの選択に関する項を参照してください。

次の例では、nasfilerは共有記憶域ファイラを表します。これらは単なる例であることに注意してください。通常、これらの共有記憶域場所のマウントは、UNIXシステム上の/etc/fstabsファイルを使用して行う必要があります。これにより、再起動しても、これらのデバイスのマウントが維持されます。詳細は、オペレーティング・システムのドキュメントを参照してください。

1. 「エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー」の説明に従ってマウント・ディレクトリをWCPHOST1に作成してから、共有記憶域をマウントします。次に例を示します。

mount -t nfs nasfiler:VOL1/oracle/products/ /u01/oracle/products/

2. VOL2を使用してWCPHOST2でこの手順を繰り返します。

共有記憶域の構成の検証

構成した共有記憶域にテスト・ファイルを作成し、新しくマウントしたディレクトリでファイルの読取りおよび書込みができることを確認します。

次に例を示します。

$ cd newly mounted directory
$ touch testfile

所有者と権限が正しいことを確認します。

$ ls -l testfile

ファイルを削除します。

$ rm testfile

注意:

共有記憶域には、NASデバイスまたはSANデバイスを使用できます。次は、NASデバイスの記憶域をWCPHOST1から作成する例を示しています。オプションは、具体的な記憶域デバイスに応じて異なる場合があります。

mount -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768 nasfiler:VOL1/Oracle/u01/oracle

使用する環境に適切なオプションについては、ストレージ・ベンダーとマシン管理者に確認してください。

8.6 各ホストでの必要な仮想IPアドレスの有効化

エンタープライズ・デプロイメント用にホストを準備するには、各ホストで必要な仮想IPアドレスを有効化する必要があります。使用しているのがOracle Enterprise Linux 5かOracle Enterprise Linux 6かに応じて手順が異なります。

Oracle Enterprise Linux 5

エンタープライズ・デプロイメント用に各ホストを準備するには、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で説明されている仮想IP (VIP)アドレスを有効化する必要があります。

すでにVIPアドレスおよびホスト名を予約済であり、ネットワーク管理者がそれらを有効化していることを前提とします。その後、適切なホストでVIPを有効化できます。

エンタープライズ・トポロジで使用する仮想IPアドレスは、サーバー全体の移行(選択した管理対象サーバーおよびクラスタの場合)または手動フェイルオーバー(管理サーバーの場合)によって管理されるため、永続化されません。

注意:

WebCenter PortalおよびWebCenter Contentの場合、管理サーバーの手動によるフェイルオーバーのために、WCPHOST1で有効にする必要があるVIPは1つのみです。

各ホストでこのVIPアドレスを有効にするには、次のコマンドをrootとして実行します。

/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 eth0:1 100.200.140.206 netmask 255.255.255.0

ネットワークを有効化し、仮想IPアドレスの新しい場所を登録します。

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

別のノードからpingコマンドを使用して、アドレスが使用可能であることを確認します。次に例を示します。

/bin/ping 100.200.140.206

Oracle Enterprise Linux 6以降

Oracle Enterprise Linux 6以降、"ifconfig"コマンドが廃止され、"ip"コマンドに置き換えられました。

各ホストでこのVIPアドレスを有効にするには、次のコマンドをrootとして実行します。

1. ネットマスクのCIDR表記を特定します。各ネットマスクにはCIDR表記があります。たとえば、255.255.240.0のCIDRは20です。
追加するネットマスクがインタフェースと同じ場合、これを特定する最も簡単な方法は、ネットワーク・カードに割り当てられた既存のIPアドレスを調べることです。このためには次のコマンドを使用できます。

ip addr show dev bond0

出力例:

2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:21:f6:03:85:9f brd ff:ff:ff:ff:ff:ff
int 192.168.20.1/20 brd 10.248.11.255 scope global bond0

この例では、CIDR値はスラッシュ(/)の後の値(つまり、20)です。CIDR値が不明な場合は、ネットワーク管理者に問い合せてください。

2. 次のコマンドを使用して、IPアドレス192.168.20.3、ネット・マスク255.255.240 (CIDR20)をネットワーク・カードbond0に追加します。
ip addr add 192.168.20.3/20 dev bond0:1

3. 定義する仮想IPアドレスごとに、次のコマンドを使用してARPキャッシュを更新します。
arping -b -A -c 3 -I bond0 192.168.20.3

注意:
ifconfigユーティリティの既知の問題により、サーバー移行時に、WebLogic管理対象サーバーの移行元のマシン上ですべてのVIPがネットワーク・インタフェースから削除されます。これは、VIPがネットワーク・インタフェースの:0で有効化されている場合に発生します。この問題を回避するには、:1以降のネットワーク・インタフェースでVIPを有効化してください。

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

エンタープライズ・デプロイメント用のデータベースの準備には、データベースが特定の要件を満たしていることの確認、データベース・サービスの作成、データベースのラージ・オブジェクトに対するSecureFilesの使用、およびデータベース・バックアップ戦略の作成が含まれます。

この章では、データベース要件、データベース・サービスの作成およびデータベースのバックアップ計画に関する情報を提供します。

- エンタープライズ・デプロイメント用のデータベースの準備の概要
Oracle Fusion Middlewareエンタープライズ・デプロイメントの一環として、サポートされているデータベースを構成する方法を理解することは重要です。

- データベース要件について
エンタープライズ・デプロイメント・トポロジを構成する前に、データベースが次の項で説明する要件を満たしていることを確認する必要があります。

- データベース・サービスの作成
複数のOracle Fusion Middleware製品が同じデータベースを共有する場合は、個別の専用のデータベース・サービスに接続するように、各製品を構成する必要があります。

- Oracleデータベースでのラージ・オブジェクト(LOB)に対するSecureFilesの使用
SecureFilesは、Oracle Database 11gリリース1で導入された新しいLOB記憶域アーキテクチャです。Oracle Fusion Middlewareスキーマ(特にOracle SOA Suiteスキーマ)にはSecureFilesの使用をお薦めします。

- データベース・バックアップ戦略について
エンタープライズ・デプロイメントのインストールと構成の主要ポイントでデータベース・バックアップを実行すると、後の構成手順で問題が発生した場合に迅速なリカバリを行うことができます。

親トピック: エンタープライズ・デプロイメントの準備

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

Oracle Fusion Middlewareエンタープライズ・デプロイメントの一環として、サポートされているデータベースを構成する方法を理解することは重要です。

ほとんどのOracle Fusion Middleware製品では、サポートされているデータベースに特定の一連のスキーマがインストールされている必要があります。これらのスキーマは、Oracle Fusion Middlewareのリポジトリ作成ユーティリティ(RCU)を使用してインストールします。

エンタープライズ・デプロイメントでは、Oracle Fusion Middleware製品スキーマに高可用性Real Application Clusters (Oracle RAC)データベースをお薦めします。

9.2 データベース要件について

エンタープライズ・デプロイメント・トポロジを構成する前に、データベースが次の項で説明する要件を満たしていることを確認する必要があります。

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

- その他のデータベース・ソフトウェア要件

- Oracle Textのインストールと検証

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

次の情報を利用して、Oracle Fusion Middlewareの各リリースでサポートされているデータベース、および現在稼働中のOracleデータベースのバージョンを確認してください。

- 動作保証済のデータベースの全リストは、Oracle Fusion Middlewareのサポートされるシステム構成のページを参照してください。

- データベースのリリースを確認するには、PRODUCT_COMPONENT_VERSIONビューに問い合せます。

SQL> SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE
PRODUCT LIKE 'Oracle%';

Oracle Fusion Middlewareでは、データベースがAL32UTF8文字セットに対応している必要があります。データベースの文字セットの選択に関する情報は、データベースのドキュメントを確認してください。

エンタープライズ・デプロイメントでは、Oracle RACデータベースへの接続にGridLinkデータ・ソースを使用することをお薦めします。

注意:

GridLinkデータ・ソースおよびSCANの使用方法の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の「アクティブなGridLinkデータ・ソースの使用方法」を参照してください。

9.2.2 その他のデータベース・ソフトウェア要件

エンタープライズ・トポロジでは、RACデータベースの2つのインスタンスをホストする2つのデータベース・ホスト・コンピュータがデータ層にあります。これらのホストをDBHOST1、DBHOST2と呼びます。

エンタープライズ・トポロジをインストールまたは構成する前に、次のソフトウェアがDBHOST1とDBHOST2にインストール済であり使用可能であることを確認する必要があります。

- Oracle Clusterware
詳細は、Oracle Grid Infrastructureインストレーション・ガイドfor Linuxのクラスタ用Oracle Grid Infrastructureのインストールに関する項を参照してください。

- Oracle Real Application Cluster
詳細は、Oracle Real Application Clustersインストレーション・ガイドfor Linux and UNIXのOracle RACおよびOracle RAC One Nodeのインストールに関する項を参照してください。

- Oracle RACデータベース・インスタンス間の時間同期
サーバー移行で構成された、Fusion Middlewareクラスタ内のサーバーで使用されるデータベース・インスタンスのクロックは同期化する必要があります。

- 自動ストレージ管理(オプション)
詳細は、Oracle Automatic Storage Management管理者ガイドのOracle Automatic Storage Managementの概要に関する項を参照してください。

9.2.3 Oracle Textのインストールと検証

WebCenter Contentエンタープライズ・トポロジをインストールまたは構成する前に、Oracle TextがDBHOST1とDBHOST2にインストール済であり使用可能であることを確認する必要があります。

Oracle Textのインストールの詳細は、『Oracle Databaseインストレーション・ガイドfor Linux』を参照してください。

WebCenter Contentインストールで使用されるデータベースでOracle Textが有効になっていることを確認するには、次のコマンドを実行します。

SQL> select comp_name, status, substr(version,1,10) as version from dba_registry where comp_id = 'CONTEXT';

COMP_NAME STATUS VERSION
----------- ------- -------
Oracle Text VALID 12.1.0.1.0

9.3 データベース・サービスの作成

複数のOracle Fusion Middleware製品が同じデータベースを共有する場合は、個別の専用のデータベース・サービスに接続するように、各製品を構成する必要があります。

注意:

この項に示す手順は、Oracle Database 12c (12.1)リリースを対象としています。これ以外のサポートされているデータベースをご使用の場合は、該当するドキュメント・ライブラリで最新のリリース別の情報を参照してください。

サービスを使用したOracle Databaseへの接続の詳細は、Real Application Clusters管理およびデプロイメント・ガイドの動的データベース・サービスを使用したOracle Databaseへの接続の概要に関する項を参照してください。

また、データベース・サービスはデフォルトのデータベース・サービスとは別のものにしてください。Oracle Database 12cデータベースのデータベース・サービスを作成および管理する完全な手順は、Real Application Clusters管理およびデプロイメント・ガイドの動的データベース・サービスによる自動ワークロード管理の概要に関する項を参照してください。

実行時接続ロード・バランシングでは、ロード・バランシングが有効になっている各サービスのサービス・レベルの目標を使用してOracle RACロード・バランシング・アドバイザを構成する必要があります。

SERVICE_TIMEまたはTHROUGHPUTについて、Oracle RACロード・バランシング・アドバイザを構成できます。接続ロード・バランシングの目標をSHORTに設定します。

srvctlユーティリティを使用してOracle Databaseサービスを作成および変更します。

データベース・サービスを作成および変更する手順は次のとおりです。

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パッケージおよびタイプ・リファレンスのDBMS_SERVICEに関する項を参照してください。

2. サービスをデータベースに追加し、srvctlを使用してインスタンスに割り当てます。

srvctl add service -d wcpdb -s wcpedg.example.com -r wcpdb1,wcpdb2

3. サービスを開始します。

srvctl start service -d wcpdb -s wcpedg.example.com

注意:

SRVCTLを使用したデータベース・サービスの作成および管理の詳細な手順は、Real Application Clusters管理およびデプロイメント・ガイドのSRVCTLを使用したサービスの作成に関する項を参照してください。

4. ロード・バランシング・アドバイザおよびランタイム接続のロード・バランシングにおけるサービス・レベルの適切な目標値が使用されるようにサービスを変更します。

より具体的には、Oracle Database 12cの『Real Application Clusters管理およびデプロイメント・ガイド』のリソースを使用して、サービス・レベルの目標値SERVICE_TIMEおよびTHROUGHPUTを設定します。

- ロード・バランシング・アドバイザの概要

- ロード・バランシング・アドバイザを使用する環境の構成

9.4 Oracleデータベースでのラージ・オブジェクト(LOB)に対するSecureFilesの使用

SecureFilesは、Oracle Database 11gリリース1で導入された新しいLOB記憶域アーキテクチャです。Oracle Fusion Middlewareスキーマ(特にOracle SOA Suiteスキーマ)にはSecureFilesの使用をお薦めします。

Oracle Database 11gリリース1以降、新しいLOB記憶域アーキテクチャであるSecureFilesが導入されました。Oracle Fusion Middlewareスキーマ、特にOracle SOA SuiteスキーマにはSecureFilesの使用をお薦めします。詳細は、Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイドのOracle SecureFiles LOBの使用に関する項を参照してください。

Oracle 12cデータベースでは、SecureFilesを使用するためのデフォルト設定はPREFERREDです。これは、LOBまたは親LOB (LOBがパーティションまたはサブパーティション内にある場合)でBasicFiles LOBが明示的に指定されていなければ、データベースがSecureFiles LOBの作成を試みることを意味します。Oracle Fusion MiddlewareスキーマではBasicFilesを明示的に指定しません。したがって、Oracle 12cデータベースにインストールされている場合、Oracle Fusion MiddlewareのLOBはデフォルトでSecureFilesになります。

Oracle 11gデータベースでは、db_securefileシステム・パラメータによってSecureFiles使用ポリシーが制御されます。このパラメータは動的に変更できます。SecureFilesを使用するには次のオプションがあります。

- PERMITTED: SecureFilesの作成を許可します(これがdb_securefileのデフォルト設定です。デフォルトの格納方式ではBasicFilesが使用されます)

- FORCE: すべての(新規) LOBをSecureFilesとして作成します

- ALWAYS: LOBをSecureFilesとして作成しようと試みますが、作成できない場合(ASSMが無効の場合)はBasicFilesに戻します

この他にも、db_securefileパラメータには次の値があります。

- IGNORE: SecureFilesを作成する試行を無視します

- NEVER: 新しいSecureFilesの作成を許可しません

Oracle 11gデータベースの場合、リポジトリ作成ユーティリティ(RCU)でOracle Fusion Middlewareスキーマを作成する前に、db_securefileパラメータをFORCEに設定することをお薦めします。

SecureFilesセグメントは、表領域を自動セグメント領域管理(ASSM)によって管理する必要があります。つまり、ASSMが無効になっていると、SecureFilesでのLOB作成が失敗します。ただし、Oracle Fusion Middlewareの表領域は、デフォルトではASSMが有効な状態で作成されます。したがって、デフォルトの構成では、Oracle Fusion Middlewareスキーマに対してSecureFilesを有効にするために何かを変更する必要はありません。

9.5 データベース・バックアップ戦略について

エンタープライズ・デプロイメントのインストールと構成の主要ポイントでデータベース・バックアップを実行すると、後の構成手順で問題が発生した場合に迅速なリカバリを行うことができます。

エンタープライズ・デプロイメントのインストールおよび構成の重要な点として、現在の環境をバックアップすることをお薦めします。たとえば、製品ソフトウェアをインストールし、特定のOracle Fusion Middleware製品のスキーマを作成した後で、データベース・バックアップを実行してください。バックアップを実行すれば、後の構成手順で何か問題が発生しても、すばやくリカバリを実行できます。

この目的のために独自のデータベース・バックアップ戦略を使用することも、オペレーティング・システムのツールやRMANを使用して単純にバックアップすることもできます。

特に、Oracle Automatic Storage Managementを使用してデータベースを作成した場合は、Oracle Recovery Managerの使用をお薦めします。可能な場合、オペレーティング・システムのツール(tarなど)を使用してコールド・バックアップも実行できます。

第III部 エンタープライズ・デプロイメントの構成

第III部は、次の章で構成されています。

- エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成
次の各項では、エンタープライズ・デプロイメントの開始点として使用できる初期ドメインのインストールおよび構成方法について説明します。このガイドの後の章では、デプロイしようとしているエンタープライズ・トポロジを構成する各種製品およびコンポーネントを含めることで、この初期ドメインを拡張する方法について説明します。

- エンタープライズ・デプロイメント用のWeb層の構成
2つのOracle HTTP Serverインスタンス(WEBHOST1とWEBHOST2に1つずつ)を含むスタンドアロンのOracle HTTP Serverドメインをインストールおよび構成する方法を理解することは重要です。

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

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

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

- Oracle WebCenter Portalを含めるドメインの拡張
次の各トピックでは、Oracle WebCenter Portalソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

- 同一ドメイン内でのWebCenter PortalワークフローのOracle SOA Suiteとの統合
WebCenter Portalには、ポータル・メンバーシップ通知、ポータル・サブスクリプション・リクエストなどを処理する事前作成されたワークフローがいくつか用意されています。WebCenter Portalワークフローは、Oracle SOA SuiteのコンポーネントとしてインストールされるOracle BPM Worklistに依存します。

10 エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

次の各項では、エンタープライズ・デプロイメントの開始点として使用できる初期ドメインのインストールおよび構成方法について説明します。このガイドの後の章では、デプロイしようとしているエンタープライズ・トポロジを構成する各種製品およびコンポーネントを含めることで、この初期ドメインを拡張する方法について説明します。

- インフラストラクチャ・ドメインの作成時に使用する変数
この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

- 初期インフラストラクチャ・ドメインについて
初期インフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。

- WCCHOST1へのOracle Fusion Middleware Infrastructureのインストール
エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を使用してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

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

- Infrastructureドメインの構成
次の各項では、Fusion Middleware構成ウィザードを使用してWebLogic Serverドメインを作成するための手順を示します。

- WCCHOST1でのドメイン・ディレクトリの構成とサーバーの起動
ドメインを作成してノード・マネージャを構成したら、WCCHOST1で追加のドメイン・ディレクトリを構成し、管理サーバーおよび管理対象サーバーを起動できます。

- WCCHOST2でのドメインの伝播とサーバーの起動
WCCHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、WCCHOST2で次のタスクを実行できます。

- uploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタの管理対象サーバーに対してuploadディレクトリとstageディレクトリを検証および更新します。

- 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング
Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

- Administratorsグループへのwsm-pmロールの追加
新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動したら、エンタープライズ・デプロイメント管理LDAPグループ(WCPAdministrators)をメンバーとしてwsm-pmアプリケーション・ストライプのpolicy.Updaterロールに追加します。

- WebLogicプロキシ・プラグインの構成

上位トピック: 「エンタープライズ・ドメインの構成」

10.1 インフラストラクチャ・ドメインの作成時に使用する変数

この章のタスクを実行する際、この項にリストするディレクトリ変数を使用します。

これらのディレクトリ変数については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- APPLICATION_HOME

- JAVA_HOME

- NM_HOME

さらに、「エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスとホスト名を参照することになります。

- ADMINHOST

- WCCHOST1

- WCCHOST2

- WCPHOST1

- WCPHOST2

- DBHOST1

- DBHOST2

- Oracle RACデータベースのSCANアドレス(DB-SCAN.examle.com)

10.2 初期インフラストラクチャ・ドメインについて

初期インフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。

- インフラストラクチャ・ディストリビューションについて

- ドメインの特徴

10.2.1 インフラストラクチャ・ディストリビューションについて

エンタープライズ・デプロイメントの初期インフラストラクチャ・ドメインの作成には、Oracle Fusion Middleware Infrastructureディストリビューションを使用します。このディストリビューションには、Oracle WebLogic ServerソフトウェアとOracle JRFソフトウェアの両方が含まれています。

Oracle JRFソフトウェアは、Oracle Web Services Manager、Oracle Application Development Framework (Oracle ADF)、Oracle Enterprise Manager Fusion Middleware Control、リポジトリ作成ユーティリティ(RCU)およびOracle Fusion Middleware製品のサポートに必要なその他のライブラリおよびテクノロジで構成されています。

このガイドの後のほうでは、エンタープライズ・デプロイメントに必要なOracle Fusion Middleware製品をサポートするために、そのドメインを拡張します。

詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middleware Infrastructureの理解に関する項を参照してください。

10.2.2 ドメインの特徴

次の表に、作成するドメインの主な特徴を示します。これらの特徴を確認して理解することで、ドメインの構成手順の目的やコンテキストに対する理解が深まります。

これらの特徴の多くについては、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

ドメインの特徴

詳細情報

管理サーバーに別個の仮想IP (VIP)アドレスを使用。

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

ドメイン内の管理サーバーと管理対象サーバーに別個のドメイン・ディレクトリを使用。

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

Oracle Web Services Managerの専用クラスタを含む。

アプリケーション層でのOracle Web Services Managerの使用

ドメインごとのノード・マネージャ構成を使用。

標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

別途インストールされたLDAPベースの認証プロバイダが必要。

OPSSおよび認証ストアと認可ストアへのリクエストの理解

10.3 WCCHOST1へのOracle Fusion Middleware Infrastructureのインストール

エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

- サポートされているJDKのインストール

- WCCHOST1でのインフラストラクチャ・インストーラの起動

- Infrastructureインストール画面のナビゲート

- 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

- ディレクトリ構造のチェック
Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、この項にリストされたディレクトリとサブディレクトリが表示されます。インストールの内容は、インストール中に選択したオプションによって異なります。

10.3.1 サポートされているJDKのインストール

Oracle Fusion Middlewareでは、動作保証されたJava Development Kit (JDK)がシステムにインストールされている必要があります。詳細は、次の各項を参照してください。

- JDKソフトウェアの検索とダウンロード

- JDKソフトウェアのインストール

10.3.1.1 JDKソフトウェアの検索とダウンロード

動作保証されているJDKを調べるには、Oracle Fusion Middlewareのサポートされるシステム構成ページで、ご使用のリリース向けの動作保証ドキュメントを参照してください。

現在のOracle Fusion MiddlewareリリースのOracle JDKを特定したら、Oracle Technology Networkの次の場所からOracle JDKをダウンロードできます。

http://www.oracle.com/technetwork/java/index.html

Java SE JDKのダウンロードに必ず移動してください。

10.3.1.2 JDKソフトウェアのインストール

JDKを次の場所にインストールします。

- アプリケーション層の各ホスト・コンピュータからアクセスできる共有記憶域デバイス/u01/oracle/products/jdkディレクトリにJDKをインストールします。

- Web層の各ホスト・コンピュータのローカル記憶域デバイス
DMZに配置されるWeb層ホスト・コンピュータは、アプリケーション層の共有記憶域に必ずしもアクセスできるとはかぎりません。

JDKソフトウェアの推奨場所の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。

次の例では、JDK 1.8.0_101の最新バージョンをインストールする方法について説明します。

1. ディレクトリを、JDKアーカイブ・ファイルをダウンロードした場所に変更します。
cd download_dir

2. JDKホーム・ディレクトリにアーカイブを解凍してから、次のコマンドを実行します。
tar -xzvf jdk-8u101-linux-x64.tar.gz
ここに記載されたJDKバージョンは、このドキュメントの発行時点のものです。サポートされている最新のJDKについては、Oracle Fusion Middlewareのシステム要件と仕様で現在のOracle Fusion Middlewareリリースを参照してください。

3. JDKディレクトリを、ディレクトリ構造内の推奨される場所に移動します。

例:

mv ./jdk1.8.0_101 /u01/oracle/products/jdk

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

4. ホスト・コンピュータでJavaを実行するためのJAVA_HOMEおよびPATH環境変数を定義します。

例:

export JAVA_HOME=/u01/oracle/products/jdk
export PATH=$JAVA_HOME/bin:$PATH

5. 次のコマンドを実行して、適切なjava実行可能ファイルがそのパスにあり、環境変数が適切に設定されていることを確認します。

java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

10.3.2 WCCHOST1でのインフラストラクチャ・インストーラの起動

インストール・プログラムを起動するには、次の手順を実行します。

1. WCCHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

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

$JAVA_HOME/bin/java -d64 -jar distribution_file_name.jar

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

- JAVA_HOMEを、ご使用のシステムの環境変数または実際のJDKの場所に置き換えます。

- distribution_file_nameを、ディストリビューションJARファイルの実際の名前に置き換えます。
ディストリビューションをOracle Technology Network (OTN)からダウンロードする場合、通常、JARファイルはダウンロード可能なZIPファイル内にパッケージされています。

初期Infrastructureドメインに必要なソフトウェアをインストールする場合は、インストールするディストリビューションはfmw_12.2.1.2.0_infrastructure_generic.jarです。

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

インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明については、「インストール画面のナビゲート」を参照してください。

10.3.3 インフラストラクチャ・インストール画面のナビゲート

インストール・プログラムでは、次の表にリストされている順序で一連の画面が表示されます。

インストール画面についての詳細情報が必要な場合は、画面名をクリックするか、画面上で「ヘルプ」ボタンをクリックしてください。

表10-1 Infrastructureインストール画面のナビゲート

画面

説明

インストール・インベントリの設定

この画面は、UNIXオペレーティング・システムで、このホストに初めてOracle製品をインストールする場合に表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名には、中央インベントリの場所への書込み権限があることを確認してください。

中央インベントリの詳細は、Oracle Universal InstallerによるソフトウェアのインストールでOracle中央インベントリの理解を参照してください。

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

エンタープライズ・デプロイメントのためには、表7-2に示すORACLE_HOME変数の値を入力します。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

このトポロジの場合は、「Fusion Middleware Infrastructure」を選択します。

注意:
このドキュメントのトポロジにサーバーの例は含まれません。例を本番環境にインストールしないことを強くお薦めします。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告またはエラー・メッセージが表示される場合、Oracle Technology Network (OTN)のOracle Fusion Middlewareシステム要件と仕様を参照してください。

セキュリティ・アップデート

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所持していないときに、この手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、その選択を後続のダイアログ・ボックスで確認します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールまたはコマンドライン・インストールの詳細は、『Oracle Universal Installerによるソフトウェアのインストール』の「サイレント・モードでのOracle Universal Installerの使用」を参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

10.3.4 他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

WCCHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、WCCHOST2にもInfrastructureをインストールする必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「WCCHOST1でのインフラストラクチャ・インストーラの起動」と「インフラストラクチャ・インストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。

注意:

以前のリリースでは、推奨エンタープライズ・トポロジに、同じ場所に配置された一連のOracle HTTP Serverインスタンスが含まれていました。これらのリリースでは、Web層ホスト(WEBHOST1とWEBHOST2)でInfrastructureをインストールするための要件がありました。ただし、このリリースでは、エンタープライズ・デプロイメント・トポロジによって、Webサーバーがスタンドアロン・モードでインストールおよび構成されていることが想定されるため、Webサーバーはアプリケーション層ドメインの一部であるとはみなされません。詳細は、「エンタープライズ・デプロイメント用のWeb層の構成」を参照してください

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

Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、この項にリストされたディレクトリとサブディレクトリが表示されます。インストールの内容は、インストール中に選択したオプションによって異なります。

ディレクトリ構造をチェックするには:

1. InfrastructureをインストールしたORACLE_HOMEディレクトリに移動します。

2. 次のコマンドを入力します。
ls --format=single-column

システム上のディレクトリ構造は、次の例に示す構造と一致する必要があります。

cfgtoollogs
coherence
em
install
inventory
OPatch
oracle_common
oraInst.loc
oui
wlserver

インストールの完了後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要ディレクトリに関する項を参照してください。

10.4 データベース・スキーマの作成

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

- メタデータ・サービス(MDS)

- 監査サービス(IAU)

- 監査サービスへの追加(IAU_APPEND)

- 監査サービス・ビューア(IAU_VIEWER)

- OPSS (Oracle Platform Security Services)

- ユーザー・メッセージング・サービス(UMS)

- WebLogicサービス(WLS)

- Common Infrastructure Services (STB)

リポジトリ作成ユーティリティ(RCU)を使用して、スキーマを作成します。このユーティリティは各Oracle Fusion Middleware製品のOracleホームにインストールされています。RCUの詳細とスキーマを作成してデータベースに格納する方法の詳細は、リポジトリ作成ユーティリティによるスキーマの作成でスキーマ作成の準備に関する項を参照してください。

この項の手順に従って、必要なスキーマをインストールします。

- 動作保証されたデータベースのインストールと構成

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

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

10.4.1 動作保証されたデータベースのインストールと構成

動作保証されたデータベースを適切にインストールして構成し、そのデータベースを起動して稼働させておく必要があります。

詳細は、「エンタープライズ・デプロイメント用のデータベースの準備」を参照してください。

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

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

1. サポートされているJDKをインストールした場所を参照するようにJAVA_HOME環境変数を設定します。

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

2. WCCHOST1上の次のディレクトリに移動します。

ORACLE_HOME/oracle_common/bin

3. RCUを起動します。

./rcu

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

Fusion Middleware Infrastructureドメインにスキーマを作成するには、この項の手順に従います。

- タスク1「RCUの概要」

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

- タスク3「データベース資格証明の指定」

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

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

- タスク6「スキーマ作成の実行」

タスク1   RCUの概要

「ようこそ」画面でRCUのバージョン番号を確認します。「次へ」をクリックして開始します。

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

データベースでDBAアクティビティを実行するために必要な権限を持っている場合は、「リポジトリの作成」画面で「システム・ロードおよび製品ロード」を選択します。このドキュメントの手順では、必要な権限があることを想定しています。

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

ヒント:

この画面の選択内容の詳細は、リポジトリ作成ユーティリティによるスキーマの作成でリポジトリの作成に関する項を参照してください。

タスク3   データベース資格証明の指定

「データベース接続の詳細」画面に、データベースに接続するためのRCUに関するデータベース接続の詳細が表示されます。

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

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

ヒント:

この画面の選択内容の詳細は、リポジトリ作成ユーティリティによるスキーマの作成でデータベース接続の詳細に関する項を参照してください。

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

1. Oracle Fusion Middlewareスキーマの識別に使用するカスタム接頭辞を指定します。

注意:
RCUの制限が12文字であっても、WebCenter Portalスキーマを含める際は、カスタム接頭辞を10文字にする必要があります。これは、WebCenter Portalスキーマのフルネームを検証する際にRCUエラーを回避するためです。スキーマ・ユーザー名の最大長は、合計30文字に制限されます。WebCenter Portalスキーマの接尾辞は、最大20文字まで使用します。

カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。このガイドでは、FMW12212という接頭辞を使用します。

ヒント:

ここで入力したカスタム接頭辞を書き留めてください。これは後でドメインの作成時に必要になります。

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

2. 「AS共通スキーマ」を選択します。
「AS共通スキーマ」を選択すると、このセクションのすべてのスキーマが自動的に選択されます。

このセクションのスキーマが自動的に選択されない場合、必要なスキーマを選択してください。

Common Infrastructure Servicesと呼ばれるスキーマも自動的に作成されます。このスキーマはグレー表示されており、選択も選択解除もできません。このスキーマ(STBスキーマ)を使用すると、ドメインの構成中にRCUから情報を取得できます。詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

ヒント:

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

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

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

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

ヒント:

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

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

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。

このガイドでは、残りの画面のデフォルト設定を受け入れるか、RCUでのOracle Fusion Middlewareスキーマの作成方法および必要な表領域の使用方法をカスタマイズします。

RCUとその機能および概念の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』の「リポジトリ作成ユーティリティについて」を参照してください。

「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

10.5 Infrastructureドメインの構成

次の各項では、Fusion Middleware構成ウィザードを使用してWebLogic Serverドメインを作成するための手順を示します。

ドメイン作成に使用可能なその他の方法の詳細は、『構成ウィザードによるWebLogicドメインの作成』のWebLogicドメインの作成、拡張および管理のための追加ツールに関する項を参照してください。

- 構成ウィザードの起動

- Infrastructureドメインを構成するための構成ウィザード画面のナビゲート

10.5.1 構成ウィザードの起動

ドメインの構成を開始するには、WCCHOST1のOracle Fusion Middleware Oracleホームで次のコマンドを実行します。

ORACLE_HOME/oracle_common/common/bin/config.sh

10.5.2 Infrastructureドメインを構成するための構成ウィザード画面のナビゲート

次以降の項で説明する手順を実行して、静的クラスタで使用するトポロジのドメインを作成して構成します。

- 静的クラスタを含めるドメインの作成

10.5.2.1 静的クラスタを含めるドメインの作成

この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。

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

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

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

- タスク3「アプリケーション・ホームの場所の選択」

- タスク4「管理者アカウントの構成」

- タスク5「ドメイン・モードとJDKの指定」

- タスク6「データベース構成タイプの指定」

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

- タスク8「GridLink Oracle RACデータベース接続の詳細の指定」

- タスク9「JDBC接続のテスト」

- タスク10「詳細構成の選択」

- タスク11「管理サーバーのリスニング・アドレスの構成」

- タスク12「ノード・マネージャの構成」

- タスク13「管理対象サーバーの構成」

- タスク14「クラスタの構成」

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

- タスク16「動的サーバーの構成」

- タスク17「クラスタへの管理対象サーバーの関連付け」

- タスク18「Coherenceクラスタの構成」

- タスク19「マシンの作成」

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

- タスク21「仮想ターゲットの作成」

- タスク23「JMSファイル・ストアの構成」

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

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

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

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

「ドメインの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOME変数の値を指定します。

ヒント:

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

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

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

- Oracle Enterprise Manager - 12.2.1.2.0 [em]
このテンプレートを選択すると、次の依存性が自動的に選択されます。

- Oracle JRF - 12.2.1.2.0 [oracle_common]

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

- Oracle WSM Policy Manager - 12.2.1.2.0 [oracle_common]

ヒント:

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

タスク3   アプリケーション・ホームの場所の選択

「アプリケーションの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。

ヒント:

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

タスク4   管理者アカウントの構成

「管理者アカウント」画面では、ドメインに対するデフォルトのWebLogic管理者アカウントにユーザー名とパスワードを指定します。

この画面で指定したユーザー名およびパスワードを書き留めておいてください。これらの資格証明は後でドメインの管理サーバーを起動して接続する際に必要になります。

タスク5   ドメイン・モードとJDKの指定

「ドメイン・モードおよびJDK」画面では、次の操作を実行します。

- 「ドメイン・モード」フィールドで、「本番」を選択します。

- 「JDK」フィールドで「Oracle Hotspot JDK」を選択します。

「本番モード」をこの画面で選択すると、環境で高度なセキュリティが実現され、アプリケーションのデプロイと管理サーバーの起動でユーザー名とパスワードが必要になります。

ヒント:

開発モードと本番モードの違いなど、この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。

本番モードでは、起動アイデンティティ・ファイルを作成することで、管理サーバーの起動時に必要なユーザー名とパスワードの指定を省略できます。詳細は、「boot.propertiesファイルの作成」を参照してください。

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

「RCUデータ」を選択して、この画面に示されるフィールドをアクティブ化します。

「RCUデータ」オプションによってデータベースおよびサービス表(STB)スキーマに接続し、ドメインの構成に必要なスキーマのスキーマ情報を自動的に受け取るように構成ウィザードで指定できます。

注意:

この画面の「手動構成」を選択した場合は、「JDBCコンポーネント・スキーマ」画面でスキーマのパラメータを手動で入力する必要があります。

「RCUデータ」を選択したら、次の表に示すフィールドに入力します。

フィールド

説明

DBMS/サービス

製品スキーマをインストールするOracle RACデータベースのサービス名を入力します。例:

orcl.example.com

必ずOracle RACデータベース内のすべてのインスタンスの識別に使用される共通サービス名を指定してください。ホスト固有のサービス名は使用しないでください。

ホスト名

Enterprise Deployment Workbookに入力したOracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

ポート

データベースがリスニングするポート番号を入力します。例: 1521。

スキーマ所有者

スキーマ・パスワード

データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。

これはRCUの「スキーマ・パスワード」画面でサービス表コンポーネントに指定したスキーマ(「データベース・スキーマの作成」を参照)のユーザー名およびパスワードです。

デフォルトのユーザー名はprefix_STBであり、この場合prefixはRCUで定義したカスタム接頭辞です。

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

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

Successfully Done.

データベースへの接続に成功したら、「次へ」をクリックします。

ヒント:

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

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

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

「JDBCコンポーネント・スキーマ」画面に示される値が、すべてのスキーマに対して適切であることを確認します。

前の画面でRCUデータの取得を選択しているため、スキーマ表は移入済のはずです。その結果、構成ウィザードはこのドメインに必要なすべてのスキーマのデータベース接続値を見つけることができます。

この時点では、これらの値は単一インスタンスのデータベースに接続するように構成されています。ただし、エンタープライズ・デプロイメントの場合、「エンタープライズ・デプロイメント用のデータベースの準備」の説明のように、可用性の高いReal Application Clusters (RAC)データベースを使用する必要があります。

さらに、各コンポーネント・スキーマでアクティブなGridLinkデータ・ソースを使用することをお薦めします。GridLinkデータ・ソースを使用してRACデータベースに接続する利点の詳細は、『高可用性ガイド』の「データベースに関する考慮事項」を参照してください。

データ・ソースをGridLinkに変換する手順は次のとおりです。

1. スキーマ表の最初のヘッダー行にあるチェック・ボックスを選択することですべてのスキーマを選択します。

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

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

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

要素

説明と推奨値

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

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

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

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

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

この画面で情報を指定する方法および適切なSCANアドレスの特定方法の詳細は、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。

また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。

タスク9   JDBC接続のテスト

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

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

ヒント:

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

タスク10   拡張構成の選択

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

- 管理サーバー
これは、管理サーバーのリスニング・アドレスを適切に構成するために必要です。

- ノード・マネージャ
これは、ノード・マネージャを構成するために必要です。

- トポロジ
サーバー・テンプレート、管理対象サーバー、クラスタ、仮想ターゲットおよびCoherenceの設定の追加、削除または変更に必要です。

- ファイル・ストア
これは、JMS永続ストア用に適切な共有記憶域を構成するために必要です。

注意:

構成ウィザードの「拡張構成」画面を使用するときは、次のようにします。

- この画面で前述のオプションのいずれかが使用可能でない場合は、「テンプレート」画面に戻り、このトポロジに必要なテンプレートが選択されていることを確認します。

- 「ドメイン・フロントエンド・ホストのキャプチャ」拡張構成オプションを選択しないでください。後で、ドメインに対してではなく特定のクラスタに対してフロントエンド・ホスト・プロパティを構成します。

タスク11   管理サーバーのリスニング・アドレスの構成

「管理サーバー」画面で、次の手順を実行します。

1. 「サーバー名」フィールドで、デフォルト値(「AdminServer」)を維持します。

2. 「リスニング・アドレス」フィールドに、「エンタープライズ・デプロイメント用のリソースの取得」で取得して「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で有効化したADMINVHNのVIPに対応する仮想ホスト名を入力します。
ADMINVHN仮想ホストを使用する理由の詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

3. 他のフィールドでは、デフォルト値をそのまま使用します。
特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。

タスク12   ノード・マネージャの構成

ノード・マネージャ・タイプとして「ドメインごとのデフォルトの場所」を選択し、ノード・マネージャへの接続に使用するノード・マネージャ資格証明を指定します。

ヒント:

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

ドメインごとおよびホストごとのノード・マネージャの実装の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の複数マシンでのノード・マネージャの構成に関する項を参照してください。

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

「管理対象サーバー」画面で、2台の管理対象サーバーを新規作成します。

1. 「追加」ボタンをクリックして、1台の管理対象サーバーを新規作成します。

2. 「サーバー名」列でWLS_WSM1を指定します。

3. 「リスニング・アドレス」列にWCCHOST1と入力します。
WCCHOST1に対応するホスト名を必ず入力して、IPアドレスは使用しないでください。

4. 「リスニング・ポート」列に7010と入力します。

5. 「サーバー・グループ」ドロップダウン・リストで、JRF-MAN-SVRおよびWSMPM-MAN-SVRを選択します。
これらのサーバー・グループによって、Oracle JRFとOracle Web Services Manager (OWSM)のサービスが、作成中の管理対象サーバーにターゲット設定されます。

サーバー・グループは、定義されたアプリケーション・サービスのグループをそれぞれに定義されたサーバー・グループにマッピングすることで、Fusion Middlewareアプリケーションおよびサービスを1つ以上のサーバーにターゲット設定します。特定のサーバー・グループにマップされた任意のアプリケーション・サービスは、そのグループに割り当てられたすべてのサーバーに自動的にターゲット指定されます。詳細は、『ドメイン・テンプレート・リファレンス』のアプリケーション・サービス・グループ、サーバー・グループおよびアプリケーション・サービス・マッピングに関する項を参照してください。

注意:

Oracle Web ServicesのNonceキャッシュは、WSM-CACHE-SVRサーバー・グループによって自動的に初期化され、ほとんどのアプリケーションに適しています。この初期化は、JRFを実行しているSOA、OSBおよび他のFMWサーバーで自動的に実行され、Coherenceクラスタを作成します。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。Nonceキャッシュは、追加されたWebサービス・アプリケーションを実行中の管理対象サーバーの数によって必然的に拡大します。

拡張キャッシュ構成については、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOracle CoherenceでのNonceのキャッシュに関する項を参照してください。この項では、カスタムWLSサーバーでのNonceキャッシュとWSM-CACHE-SVRサーバー・グループの使用に関する追加のガイダンスを示します。

6. このプロセスを繰り返して、WLS_WSM2という名前の2つ目の管理対象サーバーを作成します。
「リスニング・アドレス」列にWCCHOST2と入力します。「リスニング・ポート」に7010と入力します。最初の管理対象サーバーに適用したものと同じサーバー・グループをWLS_WSM2に適用します。

この手順で推奨する管理対象サーバー名(WLS_WSM1およびWLS_WSM2)はこのドキュメント全体で参照します。別の名前を選択した場合は、必要に応じてそれらの名前に置き換えてください。

ヒント:

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

タスク14   クラスタの構成

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

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

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

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

ヒント:

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

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

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

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

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

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

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

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

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

「サーバーのクラスタへの割当」画面を使用して、WLS_WSM1およびWLS_WSM2を新規クラスタWSM-PM_Clusterに割り当てます。

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

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

- 「WLS_WSM1」を1回クリックして選択し、右矢印をクリックして「クラスタ」ペインの選択されているクラスタ(WSM-PM_Cluster)の下に移動します。
または

- 「WLS_WSM1」をダブルクリックして、クラスタ・ペインの選択されているクラスタ(WSM-PM_Cluster)の下に移動します。

3. これらの手順を繰り返して、WLS_WSM2管理対象サーバーをWSM-PM_Clusterに割り当てます。

ヒント:

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

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

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。

「クラスタ・リスニング・ポート」に9991と入力します。

注意:

Coherenceライセンス情報については、Oracle Fusion Middlewareライセンス情報ユーザー・マニュアルのOracle Coherence製品に関する項を参照してください。

タスク19   マシンの作成

「マシン」画面を使用して、ドメイン内に5つの新規マシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。

1. 「Unixマシン」タブを選択します。

2. 「追加」ボタンをクリックし、5つの新しいUNIXマシンを作成します。
表10-2の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。

3. 「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。
この例に示されているポート番号5556は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。

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

名前

ノード・マネージャのリスニング・アドレス

ノード・マネージャのリスニング・ポート

ADMINHOST

ADMINVHN変数の値を入力します。

5556

WCCHOST1

WCCHOST1ホスト名変数の値。たとえば、WCCHOST1.example.comなどです。

5556

WCCHOST2

WCCHOST2ホスト名変数の値。たとえば、WCCHOST2.example.comなどです。

5556

WCPHOST1

WCPHOST1ホスト名変数の値。たとえば、WCPHOST1.example.comとなります。

5556

WCPHOST2

WCPHOST2ホスト名変数の値。たとえば、WCPHOST2.example.comとなります。

5556

ヒント:

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

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

「サーバーのマシンへの割当」画面を使用して、静的に定義された管理対象を適切なマシンに割り当てます。動的クラスタの一部であるサーバーは、計算済マシン名に自動的に割り当てられます。

「サーバーのマシンへの割当」画面は、管理対象サーバーのクラスタへの割当て画面に似ています。「マシン」列でターゲット・マシンを選択し、左の列でサーバー名を選択した後、右矢印をクリックしてそのサーバーを適切なマシンに割り当てます。

次のように、サーバーを割り当てます。

- AdminServerをADMINHOSTマシンに割り当てます。

- WLS-WSM1管理対象サーバーをWCCHOST1マシンに割り当てます。

- WLS-WSM2管理対象サーバーをWCCHOST2マシンに割り当てます。

ヒント:

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

タスク21   仮想ターゲットの作成

「次へ」をクリックして、続行します。

タスク22   パーティションの作成

「次へ」をクリックして、続行します。

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

Oracle WSM Policy Manager構成テンプレートを使用してドメインを構成する場合、特にエンタープライズ・デプロイメントを構成しているときには、メタデータ・サービス(MDS)のJMSファイル・ストアの適切な場所を選択する必要があります。

「JMSファイル・ストア」画面の「ディレクトリ」列に次の場所を入力します。

ORACLE_RUNTIME/domain_name/WSM-PM_Cluster/jms

注意:
このストアには、非共有記憶域の場所を指定できます。これは、WSMの開発モードでのみ使用されます。本番環境では、これをホストするためにかわりにデータベースが使用されます。

「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ORACLE_RUNTIMEを変数の実際の値に置き換えます。

domain_nameを作成しているドメインの名前に置き換えます。

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

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

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

ドメイン作成は、「作成」をクリックするまでは開始されません。

ヒント:

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

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

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

- ドメインの場所

- 管理サーバーURL

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

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

10.6 WCCHOST1でのドメイン・ディレクトリの構成とサーバーの起動

ドメインを作成してノード・マネージャを構成したら、WCCHOST1で追加のドメイン・ディレクトリを構成し、管理サーバーおよび管理対象サーバーを起動できます。

- WCCHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動
ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動するには、次の手順を使用します。

- boot.propertiesファイルの作成
管理サーバー資格証明を要求されずに管理サーバーを起動したい場合は、boot.propertiesを作成する必要があります。この手順は、エンタープライズ・デプロイメントで必要です。このファイルに入力した資格証明は、管理サーバーの起動時暗号化されます。

- ノード・マネージャを使用した管理サーバーの起動
ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。

- 管理サーバーの検証
構成手順に進む前に、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、管理サーバーが正常に起動したことを確認します。

- Derbyデータベースの無効化

- WCCHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成
エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。これで、WCCHOST1とWCCHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。

- WCCHOST1の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

- WCCHOST1でのWLS_WSM1管理対象サーバーの起動と検証
ノード・マネージャを構成して管理対象サーバー・ドメイン・ディレクトリを作成したら、Oracle Enterprise Manager Fusion Middleware Controlを使用してWCCHOST1でWLS_WSM1管理対象サーバーを起動できます。

10.6.1 WCCHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動

これらの手順を使用して、ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動します。

1. nodemanager.propertiesファイルのリスニング・アドレスが正しく設定されていることを確認します。

a. nodemanager.propertiesファイルを開いて編集します。
ASERVER_HOME/nodemanager/nodemanager.properties

b. ListenAddressプロパティがADMINVHN仮想IPアドレスの値に設定されていることを確認します。

c. QuitEnabledがtrue’に設定されていることを確認します。この行がnodemanager.propertiesファイルに存在しない場合は、次の行を追加します。
QuitEnabled=true

2. 次のディレクトリに変更します。
ASERVER_HOME/bin

3. 次のコマンドを入力して、ノード・マネージャを起動します。
nohup ./startNodeManager.sh ASERVER_HOME/nodemanager/nodemanager.out 2&1 &
ノード・マネージャの追加の構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

10.6.2 boot.propertiesファイルの作成

管理サーバー資格証明を要求されずに管理サーバーを起動したい場合は、boot.propertiesを作成する必要があります。この手順は、エンタープライズ・デプロイメントで必要です。このファイルに入力した資格証明は、管理サーバーの起動時暗号化されます。

管理サーバーのboot.propertiesファイルを作成する手順は次のとおりです。

1. 次のようなディレクトリ構造を作成します。

mkdir -p ASERVER_HOME/servers/AdminServer/security

2. テキスト・エディタで、前述の手順で作成したsecurityディレクトリにboot.propertiesというファイルを作成し、構成ウィザードを実行してドメインを作成したときに定義した、次の管理サーバー資格証明を入力します。

username=adminuser
password=password

注意:

管理サーバーを起動すると、ファイル内のusernameとpasswordのエントリは暗号化されます。

セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を短くします。ファイルを編集した後、できるかぎり速やかにサーバーを起動し、エントリを暗号化してください。

3. ファイルを保存してエディタを閉じます。

10.6.3 ノード・マネージャを使用した管理サーバーの起動

ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。

ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。

1. WebLogic Scripting Tool(WLST)を起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

2. ノード・マネージャ資格証明を使用してノード・マネージャに接続します。

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'ASERVER_HOME')

注意:

このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理者IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

ASERVER_HOME/config/nodemanager

3. 管理サーバーを起動します。

nmStart('AdminServer')

注意:

管理サーバーを起動すると、WebServicesポリシーのためにOracle Web Services Managerに接続しようとします。WSM-PM管理対象サーバーはまだ起動されていないため、管理サーバー・ログには次のメッセージが表示されると予想されます。

<Warning><oracle.wsm.resources.policymanager>
<WSM-02141><Unable to connect to the policy access service due to Oracle WSM policy manager host server being down.>

4. WLSTを終了します。

exit()

10.6.4 管理サーバーの検証

構成手順に進む前に、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、管理サーバーが正常に起動したことを確認します。

Fusion Middleware Controlに移動するには、次のURLを入力し、Oracle WebLogic Server管理者の資格証明を使用してログインします。

ADMINVHN:7001/em

Oracle WebLogic Server管理コンソールに移動するには、次のURLを入力し、同じ管理者資格証明を使用してログインします。

ADMINVHN:7001/console

10.6.5 Derbyデータベースの無効化

管理対象サーバー・ディレクトリを作成して管理対象サーバーを起動する前に、Oracle WebLogic Serverに含まれるファイルベースのデータベースである組込みDerbyデータベースを無効にします。Derbyデータベースは主に開発環境に使用されます。そのため、本番対応のエンタープライズ・デプロイメント環境を構成する場合は無効にする必要があります。そうしないと、管理対象サーバーの起動時にDerbyデータベース・プロセスが自動的に起動されます。

Derbyを無効にするには、次のようにします。

1. Oracleホームの次のディレクトリに移動します。
WL_HOME/common/derby/lib

2. Derberライブラリjarファイル名を変更します。
mv derby.jar disable_derby.jar

3. WCCHOST1とWCCHOST2で個別の共有ファイルシステムを使用している場合は、各ORACLE_HOMEで手順1から2を実行します。

10.6.6 WCCHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成

エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。これで、WCCHOST1とWCCHOST2の両方で、ローカル記憶域にドメインのコピーを作成できるようになりました。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。

サーバーが共有記憶域にログを書き込むことによって発生する潜在的な競合とオーバーヘッドを排除するために、MSERVER_HOMEをローカル記憶域に配置することをお薦めします。また、必要なクラスおよびjarをドメイン・ディレクトリからロードするほうが高速であるため、管理対象サーバーがドメイン・ディレクトリから使用する一時データまたはキャッシュのデータのほうがより迅速に処理されます。

「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のように、管理サーバー・ドメイン・ホームのパスはASERVER_HOME変数によって表され、管理対象サーバー・ドメイン・ホームのパスはMSERVER_HOME変数によって表されます。

管理対象サーバーのドメイン・ディレクトリを作成する手順は次のとおりです。

1. WCCHOST1にサインインし、次のようにpackコマンドを実行してテンプレートを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=/full_path/wcpdomaintemplate.jar
-template_name=wcp_domain_template

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

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

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

SHARED_CONFIG_DIR/domains/template_filename.jar

- wcpdomaintemplate.jarは作成するJARファイルのサンプル名であり、これにはドメイン構成ファイルが含まれます。

- wcp_domain_templateは、テンプレート・ファイルに格納されるテンプレート・データに割り当てられるラベルです。

2. packコマンドで作成したばかりのwcpdomaintemplate.jarファイルの場所を書き留めます。

ヒント:

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

3. まだ作成していない場合は、WCCHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
-overwrite_domain=true \
-template=/full_path/wcpdomaintemplate.jar
-log_priority=DEBUG \
-log=/tmp/unpack.log \
-app_dir=APPLICATION_HOME \

注意:

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

また、ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shというファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンドライン・オプションの指定、追加の環境変数の指定などを行うよう構成できます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

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

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

- full_pathを、テンプレートjarファイルを作成またはコピーした場所の完全なパスで置き換えます。

- wcpdomaintemplate.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートJARファイルの名前です。

ヒント:

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

5. ディレクトリを、新しく作成した管理対象サーバー・ディレクトリに変更して、ドメイン構成ファイルがWCCHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

10.6.7 WCCHOST1の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

管理対象サーバーのドメイン・ディレクトリを作成した後は、2つのドメイン・ホーム・ディレクトリと、それに対応する2つの対応するノード・マネージャ・インスタンスがWCCHOST1上に存在します。1つのノード・マネージャは、管理サーバー・ドメイン・ホームから実行される管理サーバーの制御に使用します。もう1つのノード・マネージャは、管理対象サーバー・ドメイン・ホームから実行される管理対象サーバーの制御に使用します。

2つのノード・マネージャを別々に起動する必要があります。

注意:
管理対象サーバーのMSERVER_HOMEのノード・マネージャは、ドメイン構成が解凍されるたびにリセットされます。ListenAddressは、正しいホスト名ではなくADMINVHNに変更されます。解凍の実行後、ノード・マネージャ・サービスを開始する前にこの値を正しい値に変更する必要があります。

次の手順に従って、管理対象サーバー・ホームからノード・マネージャを更新および起動します。

1. 次の手順を実行して、nodemanager.propertiesファイルのリスニング・アドレスが正しく設定されていることを確認します。

a. 次のディレクトリに変更します。
MSERVER_HOME/nodemanager/

b. nodemanager.propertiesファイルを開いて編集します。

c. ListenAddressプロパティを次のように正しいhostnameに更新します。
WCCHOST1: ListenAddress=WCCHOST1

WCCHOST2: ListenAddress=WCCHOST2

d. ListenPortプロパティを適切なリスニング・ポートの詳細で更新します。

e. QuitEnabledがtrue’に設定されていることを確認します。この行がnodemanager.propertiesファイルに存在しない場合は、次の行を追加します。
QuitEnabled=true

2. 次のディレクトリに変更します。
MSERVER_HOME/bin

3. 次のコマンドを使用してノード・マネージャを起動します。
nohup ./startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

10.6.8 WCCHOST1でのWLS_WSM1管理対象サーバーの起動と検証

ノード・マネージャを構成して管理対象サーバー・ドメイン・ディレクトリを作成したら、Oracle Enterprise Manager Fusion Middleware Controlを使用してWCCHOST1でWLS_WSM1管理対象サーバーを起動できます。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

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

- ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。

- ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

ヒント:

Oracle Enterprise Manager Fusion Middlewareを使用したOracle Fusion Middlewareの管理の詳細は、『Oracle Fusion Middlewareの管理』のOracle Enterprise Manager Fusion Middleware Controlの使用のスタート・ガイドに関する項を参照してください。

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「サーバー」ペインを選択して、ドメイン内の管理対象サーバーを表示します。

4. WLS_WSM1管理対象サーバーのみを選択し、割り当てられたポート番号を書き留めてください。

5. ツールバーで「制御」→「起動」をクリックし、選択したWLS_WSM1管理対象サーバーを起動します。

6. 管理対象サーバーが正しく機能していることを検証するには、ブラウザを開き、適切なポート番号を使用して次のURLを入力します。

WCCHOST1:<port-number>/wsm-pm/

要求に従って、ドメイン管理ユーザー名とパスワードを入力します。

10.7 WCCHOST2でのドメインの伝播とサーバーの起動

WCCHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、WCCHOST2で次のタスクを実行できます。

- WCCHOST2でのドメイン構成の解凍

- WCCHOST2の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

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

10.7.1 WCCHOST2でのドメイン構成の解凍

WCCHOST1で管理サーバーと1つ目のWLS_WSM1管理対象サーバーを実行したので、WCCHOST2でドメインを構成できます。

1. WCCHOST2にログインします。

2. まだ作成していない場合は、WCCHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. WCCHOST2からwcedgdomaintemplate.jarにアクセスできることを確認します。
たとえば、WCCHOST2のために別の共有記憶域ボリュームまたはパーティションを使用している場合は、WCCHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-overwrite_domain=true
-template=/full_path/wcedgdomaintemplate.jar
-log_priority=DEBUG
-log=/tmp/unpack.log
-app_dir=APPLICATION_HOME

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

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

- full_pathを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

- APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

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

5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがWCCHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

10.7.2 WCCHOST2の管理対象サーバー・ドメイン・ディレクトリでのノード・マネージャの起動

ドメイン構成をMSERVER_HOMEに解凍すると、WCCHOST2には、ドメイン・ホーム・ディレクトリ構造と、ドメイン構成の対応するマシンに割り当てられた管理対象サーバーを制御するためのノード・マネージャが存在します。

次の手順に従って、管理対象サーバー・ホームからノード・マネージャを更新および起動します。

1. 次の手順を実行して、nodemanager.propertiesファイルのリスニング・アドレスが正しく設定されていることを確認します。

a. 次のディレクトリに変更します。
MSERVER_HOME/nodemanager/

b. nodemanager.propertiesファイルを開いて編集します。

c. ListenAddressプロパティを次のように正しいhostnameに更新します。
WCCHOST1: ListenAddress=WCCHOST1

WCCHOST2: ListenAddress=WCCHOST2

d. ListenPortプロパティを適切なリスニング・ポートの詳細で更新します。

e. QuitEnabledがtrue’に設定されていることを確認します。この行がnodemanager.propertiesファイルに存在しない場合は、次の行を追加します。
QuitEnabled=true

2. 次のディレクトリに移動します。

MSERVER_HOME/bin

3. 次のコマンドを使用してノード・マネージャを起動します。

nohup ./startNodeManager.sh > $MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

10.7.3 WCCHOST2でのWLS_WSM2管理対象サーバーの起動と検証

「WCCHOST1でのWLS_WSM1管理対象サーバーの起動と検証」の手順を使用して、WCCHOST2上のWLS_WSM2管理対象サーバーを起動して検証します。

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

ドメインを構成し、すべてのホスト上の管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタで管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

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

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

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

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

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

4. クラスタ・タイプの適切なオブジェクトにナビゲートして、それを編集します。

a. 静的クラスタの場合は「サーバー」にナビゲートし、編集する管理対象サーバーの名前をクリックします。

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

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

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

MSERVER_HOME/servers/server_or_template_name/stage

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

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

ASERVER_HOME/servers/AdminServer/upload

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

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

e. 「サーバーのサマリー」と「サーバー・テンプレートのサマリー」のうち、該当する画面に戻ります。

6. 適切なオブジェクトをすべて変更している場合は、「変更のアクティブ化」をクリックします。

7. これらの変更の影響を受ける管理対象サーバーをすべて再起動します。

10.9 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング

Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

次の各項では、Oracle WebLogic Server管理コンソールを使用してエンタープライズ・デプロイメント・ドメイン用の新しい認証プロバイダを作成する方法を説明します。この手順では、サポートされているLDAPディレクトリ(Oracle Unified DirectoryやOracle Internet Directoryなど)をすでにインストールおよび構成していることを想定しています。

- サポートされている認証プロバイダについて

- エンタープライズ・デプロイメントのユーザーおよびグループについて

- 新しい認証プロバイダの作成と新しいユーザーおよびグループのプロビジョニングの前提条件

- LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

- 新しい認証プロバイダの作成

- エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

- 管理グループへの新しい管理ユーザーの追加

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

10.9.1 サポートされている認証プロバイダについて

Oracle Fusion Middlewareでは、様々なLDAP認証プロバイダをサポートしています。詳細は、Oracle Platform Security Servicesによるアプリケーションの保護のアイデンティティ・ストア・タイプおよびWebLogicオーセンティケータに関する項を参照してください。

このガイドの手順では、次のいずれかのプロバイダを使用していることを想定しています。

- Oracle Unified Directory

- Oracle Internet Directory

- Oracle Virtual Directory

注意:

ここに示す手順では、デフォルトで、暗号化されていない接続を使用して、単一のLDAPアイデンティティ・ストアに対する問合せをサポートするようにアイデンティティ・サービス・インスタンスを構成する方法を説明します。

アイデンティティ・プロバイダへの接続をSSLで保護する必要がある場合、正しく機能するには、Enterprise Manager Fusion Middleware Controlでのロール管理に追加のキーストーン構成が必要です。構成の詳細は、support.oracle.comでDoc ID 1670789.1を参照してください。

また、LibOVDを使用して、複数のLDAPアイデンティティ・ストアに問合せを行う仮想アイデンティティ・ストアをサポートするようにサービスを構成できます。

複数LDAP参照に関する詳細は、Oracle Platform Security Servicesによるアプリケーションの保護のアイデンティティ・ストア・サービスの構成に関する項を参照してください。

10.9.2 エンタープライズ・デプロイメントのユーザーおよびグループについて

次の各項では、エンタープライズ・デプロイメント管理ユーザーおよびグループの用途と特性に関する重要な情報を提供します。

- 各ドメインで一意の管理ユーザーの使用について

- ドメイン・コネクタ・ユーザーについて

- 集中LDAPディレクトリへのユーザーの追加について

- Oracle WebCenter Portalの製品固有のロールとグループについて

- このガイドで使用するサンプル・ユーザーとサンプル・ロール

10.9.2.1 各ドメインで一意の管理ユーザーの使用について

集中LDAPユーザー・ストアを使用すると、複数のOracle WebLogic Serverドメインで使用するユーザーおよびグループをプロビジョニングできます。その結果、あるWebLogic管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。

このようなアプローチはお薦めしません。かわりに、Oracle Fusion Middlewareドメインの管理用にプロビジョニングするユーザーおよびグループにディレクトリ・ツリー内で一意の識別名(DN)を割り当てる方法をお薦めします。

たとえば、Oracle WebCenter Portalエンタープライズ・デプロイメント・ドメインをインストールおよび構成する場合は、weblogic_wcpというユーザーとWCPAdministratorsという管理グループを作成します。

10.9.2.2 ドメイン・コネクタ・ユーザーについて

LDAPディレクトリで個別のドメイン・コネクタ・ユーザー(たとえばwcpLDAP)を作成することをお薦めします。このユーザーを使用して、ドメインがユーザー認証の目的でLDAPディレクトリに接続できます。このユーザーは管理ユーザー以外にすることをお薦めします。

標準的なOracle Identity and Access Managementデプロイメントでは、このユーザーはsystemidsコンテナで作成します。このコンテナは、通常ユーザーには表示されないシステム・ユーザーに使用されます。このユーザーをsystemidsコンテナに配置することで、Oracle Identity Managerを持つユーザーがこのユーザーを調整しないようにできます。

10.9.2.3 集中管理型LDAPディレクトリへのユーザーの追加について

集中LDAPディレクトリをエンタープライズ・ドメインのオーセンティケータとして構成した後は、すべての新規ユーザーをデフォルトのWebLogic Serverオーセンティケータではなく新しいオーセンティケータに追加する必要があります。

集中LDAPディレクトリに新規ユーザーを追加する際、WebLogic管理コンソールは使用できません。かわりに、ldapbrowserやJXplorerなどの適切なLDAP変更ツールを使用する必要があります。

複数のオーセンティケータを使用している場合(エンタープライズ・デプロイメントの要件)、ログインや認証は実行できますが、ロール取得は実行できません。ロールは、最初のオーセンティケータからのみ取得できます。他のオーセンティケータを使用してロールを取得する場合は、ドメインの仮想化を有効にする必要があります。

仮想化を有効にする手順は次のとおりです。

1. 次の構成ファイルを探してテキスト・エディタで開きます。

ASERVER_HOME/config/fmwconfig/jps-config.xml

2. 次のセクションを検索します。

<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">

3. serviceInstanceセクションに次の行を追加するか、次のようにvirtualizeプロパティを更新します。

<property name="virtualize" value="true"/>

仮想化プロパティの詳細は、Oracle Platform Security Servicesによるアプリケーションの保護のOPSSシステムおよび構成プロパティに関する項を参照してください。

10.9.2.4 Oracle WebCenter Portalの製品固有のロールとグループについて

Oracle Fusion Middleware製品ごとに、管理および監視のために事前定義された独自のロールおよびグループが実装されます。

その結果、ドメインを拡張して他の製品を追加するときに、これらの製品固有のロールをWCPAdministratorsグループに追加できます。ロールがWCPAdministratorsグループに追加されると、各製品管理者ユーザーは管理タスクを実行するための同じ権限セットを使用してドメインを管理できます。

WCPAdministratorsグループに他のロールを追加する手順については、「エンタープライズ・デプロイメントの共通の構成および管理タスク」を参照してください。

10.9.2.5 このガイドで使用するサンプル・ユーザーとサンプル・ロール

このガイドで使用するサンプルでは、下に示すDNを持つ次の管理ユーザーおよび管理グループをプロビジョニングすることを想定しています。

- 管理ユーザーのDN:

cn=weblogic_wcp,cn=users,dc=example,dc=com

- 管理グループDN:

cn=WCPAdministrators,cn=groups,dc=example,dc=com

- 製品固有のLDAPコネクタ・ユーザー:

cn=wcpLDAP,cn=systemids,dc=example,dc=com
これは、WebLogic管理対象サーバーをLDAP認証プロバイダに接続するときに使用するユーザーです。このユーザーには、ディレクトリに対する読取り権限および書込み権限が必要です。

cn=users,dc=example,dc=com
cn=groups,dc=example,dc=com

注意:

Oracle Unified Directoryを使用する場合、このユーザーに次のグループのメンバーシップが付与され、読取りおよび書込みアクセス権が付与される必要があります。

cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=example,dc=com
cn=orclFAGroupWritePrivilegeGroup,cn=groups,dc=example,dc=com

10.9.3 新しい認証プロバイダの作成と新しいユーザーおよびグループのプロビジョニングの前提条件

新しいLDAP認証プロバイダを作成する前に、関連する構成ファイルをバックアップする必要があります。

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

さらに、次のディレクトリにある管理サーバーのboot.propertiesファイルをバックアップする必要があります。

ASERVER_HOME/servers/AdminServer/security

10.9.4 LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

この例では、集中管理型LDAPディレクトリにwcpLDAPというユーザーを作成する方法を示します。

LDAPプロバイダでユーザーをプロビジョニングするには:

1. 次に示す内容のdomain_user.ldifという名前のldifファイルを作成して保存します。

dn: cn=wcpLDAP,cn=systemids,dc=example,dc=com
changetype: add
orclsamaccountname: wcpLDAP
userpassword: password
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: wcpLDAP@example.com
givenname: wcpLDAP
sn: wcpLDAP
cn: wcpLDAP
uid: wcpLDAP

注意:

Oracle Unified Directoryを使用する場合、次の4つのグループ・メンバーシップをLDIFファイルの最後に追加して適切な読取り/書込み権限を付与します。

dn:
cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=wcpLDAP,cn=systemids,dc=example,dc=com

dn: cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=wcpLDAP,cn=systemids,dc=example,dc=com

dn: cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=wcpLDAP,cn=systemids,dc=example,dc=com

dn: cn=orclFAGroupWritePrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=wcpLDAP,cn=systemids,dc=example,dc=com

2. LDAPディレクトリでユーザーをプロビジョニングします。
たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。

OUD_INSTANCE_HOME/bin/ldapmodify -a \
-h oudhost.example.com
-D "cn=oudadmin" \
-w password \
-p 1389 \
-f domain_user.ldif

Oracle Internet Directoryの場合:

OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \
-p 3060 \
-D cn="orcladmin" \
-w password \
-c \
-v \
-f domain_user.ldif

10.9.5 新しい認証プロバイダの作成

新しいLDAPベースの認証プロバイダを構成する手順は次のとおりです。

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

2. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

3. myrealmというデフォルト・レルム・エントリをクリックします。

4. 「プロバイダ」タブをクリックします。
このレルムに対してDefaultAuthenticatorというプロバイダが構成されていることに注目してください。これは、デフォルトのWebLogic Server認証プロバイダです。

5. 「チェンジ・センター」で「ロックして編集」をクリックします。

6. 「認証プロバイダ」表の下の「新規」ボタンをクリックします。

7. プロバイダの名前を入力します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかの名前を使用します。

- OUDAuthenticator (Oracle Unified Directoryの場合)

- OIDAuthenticator (Oracle Internet Directoryの場合)

- OVDAuthenticator (Oracle Virtual Directoryの場合)

8. 「タイプ」ドロップダウン・リストでオーセンティケータ・タイプを選択します。
資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかのタイプを選択します。

- OracleUnifiedDirectoryAuthenticator (Oracle Unified Directoryの場合)

- OracleInternetDirectoryAuthenticator (Oracle Internet Directoryの場合)

- OracleVirtualDirectoryAuthenticator (Oracle Virtual Directoryの場合)

9. 「OK」をクリックして「プロバイダ」画面に戻ります。

10. 「プロバイダ」画面の表で、新しく作成したオーセンティケータをクリックします。

11. 「制御フラグ」ドロップダウン・メニューで「SUFFICIENT」を選択します。

制御フラグをSUFFICIENTに設定すると、そのオーセンティケータがユーザーを正常に認証できる場合はその認証を受け入れ、それ以上のオーセンティケータを起動しません。

認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。以降のすべてのオーセンティケータの制御フラグもSUFFICIENTに設定されていることを確認してください。特にDefaultAuthenticatorをチェックして、その制御フラグがSUFFICIENTに設定されていることを確認します。

12. 「保存」をクリックして制御フラグの設定を保存します。

13. 「プロバイダ固有」タブをクリックし、次の表に示すように、使用するLDAPサーバーに固有の詳細を入力します。
この手順では、必須フィールドのみを説明しています。このページのすべてのフィールドの詳細は、次のリソースを参照してください。

- 各フィールドの説明を表示するには、「プロバイダ固有」タブの「ヘルプ」をクリックします。

- 「ユーザー・ベースDN」、「名前指定によるユーザー・フィルタ」および「ユーザー名属性」の各フィールドの設定に関する詳細は、『Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』のOracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成に関する項を参照してください。

パラメータ

サンプル値

値の説明

ホスト

例: oud.example.com

LDAPサーバーのサーバーID。

ポート

例: 1689

LDAPサーバーのポート番号。

プリンシパル

例: cn=wcpLDAP, cn=systemids,dc=example,dc=com

LDAPサーバーへの接続に使用されるLDAPユーザーのDN。

資格証明

LDAPパスワードを入力します。

LDAPサーバーへの接続に使用されるパスワード。

SSL有効

未チェック(クリア)

LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。

ユーザー・ベースDN

例: cn=users,dc=example,dc=com

ユーザーが開始時に使用するDNを指定します。

すべてのユーザーのフィルタ

(&(uid=*)(objectclass=person))

すべてのユーザーのフィルタのデフォルトの検索条件のかわりにuid値に基づいてすべてのユーザーを検索します。

LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がuid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」フィールドでそのタイプを変更します。

たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。

(&(cn=*)(objectclass=person)))

名前指定によるユーザー・フィルタ

例:

(&(uid=%u)(objectclass=person))

LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がuid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」の設定で、そのタイプを変更します。

たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。

(&(cn=%u)(objectclass=person)))

ユーザー名属性

例: uid

グループの名前を指定するLDAPユーザー・オブジェクトの属性。

グループ・ベースDN

例: cn=groups,dc=example,dc=com

グループ・ノードを指すDNを指定します。

取得したユーザー名をプリンシパルとして使用する

チェック・ボックスを選択

オンにする必要があります。

GUID属性

entryuuid

OUDにOracleUnifiedDirectoryAuthenticatorが使用される場合、この値にはentryuuidが事前に移入されます。認証プロバイダとしてOracle Unified Directoryを使用している場合はこの値を入力します。

14. 「保存」をクリックして変更を保存します。

15. 右のナビゲーション・ペインで「セキュリティ・レルム」をクリックして、デフォルトのレルム名(myrealm)をクリックし、「プロバイダ」をクリックして「プロバイダ」ページに戻ります。

16. 「並替え」をクリックし、表示されたページを使用して、作成したプロバイダを認証プロバイダのリストの先頭に配置します。

17. 「OK」をクリックします。

18. チェンジ・センターで、変更のアクティブ化 をクリックします。

19. 管理サーバーとすべての管理対象サーバーを再起動します。
管理対象サーバーを停止するには、Fusion Middleware Controlにログインし、ターゲットのナビゲータで管理対象サーバーを選択して、ツールバーで「停止」をクリックします。

ノード・マネージャを使用して管理サーバーを停止および起動する手順は次のとおりです。

a. WLSTを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

b. 構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します。

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'ASERVER_HOME')

c. 管理サーバーを停止します。

nmKill('AdminServer')

d. 管理サーバーを起動します。

nmStart('AdminServer')

e. WLSTを終了します。

exit()

管理対象サーバーを起動するには、Fusion Middleware Controlにログインし、管理対象サーバーを選択して、ツールバーで「起動」をクリックします。

20. 再起動後に、次のログ・ファイルの内容を確認します。

ASERVER_HOME/servers/AdminServer/logs/AdminServer.log

LDAP接続エラーが発生していないことを確認します。たとえば、次のようなエラーを探します。

The LDAP authentication provider named "OUDAuthenticator" failed to make connection to ldap server at ...

ログ・ファイルでこのようなエラーが見つかった場合は、認可プロバイダ接続の詳細をチェックして、それらが適切であることを確認し、管理サーバーの保存と再起動をもう一度試みます。

21. 再起動後、LDAP接続エラーがログ・ファイルに記述されていないことを確認し、LDAPプロバイダ内に存在するユーザーとグループの参照を試みます。
管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ユーザーとグループ」ページに移動します。LDAPプロバイダ構造内に存在するすべてのユーザーおよびグループを表示できるようになります。

10.9.6 エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

この例では、weblogic_wcpというユーザーとWCPAdministratorsというグループを作成する方法を示します。

LDAPプロバイダで管理ユーザーおよび管理グループをプロビジョニングする手順は次のとおりです。

1. 次に示す内容のadmin_user.ldifという名前のldifファイルを作成して保存します。

dn: cn=weblogic_wcp,cn=users,dc=example,dc=com
changetype: add
orclsamaccountname: weblogic_wcp
userpassword: password
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: weblogic_wcp@example.com
givenname: weblogic_wcp
sn: weblogic_wcp
cn: weblogic_wcp
uid: weblogic_wcp

2. LDAPディレクトリでユーザーをプロビジョニングします。
たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。

OUD_INSTANCE_HOME/bin/ldapmodify -a \
-h oudhost.example.com
-D "cn=oudadmin" \
-w password \
-p 1389 \
-f admin_user.ldif

Oracle Internet Directoryの場合:

OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \
-p 3060 \
-D cn="orcladmin" \
-w password \
-c \
-v \
-f admin_user.ldif

3. admin_group.ldifという名前のldifファイルを作成して、次の内容を入力してからこのファイルを保存します。

dn: cn=WCPAdministrators,cn=Groups,dc=example,dc=com
changetype: add
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_wcp,cn=users,dc=example,dc=com
cn: WCPAdministrators
displayname: WCPAdministrators
description: Administrators Group for the Oracle WebCenter Portal Domain

4. LDAPディレクトリでグループをプロビジョニングします。
Oracle Unified Directoryの場合:

OUD_INSTANCE_HOME/bin/ldapmodify -a \
-D "cn=oudadmin" \
-h oudhost.example.com \
-w password \
-p 1380 \
-f admin_group.ldif

Oracle Internet Directoryの場合:

OID_ORACLE_HOME/bin/ldapadd -h oid.example.com \
-p 3060 \
-D cn="orcladmin" \
-w password \
-c \
-v \
-f admin_group.ldif

5. 変更が正常に行われたことを確認します。

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

b. コンソールの左ペインで「セキュリティ・レルム」をクリックします。

c. デフォルト・セキュリティ・レルム(myrealm)をクリックします。

d. 「ユーザーとグループ」タブをクリックします。

e. プロビジョニングした管理者ユーザーおよびグループがページに表示されていることを確認します。

10.9.7 管理グループへの新しい管理ユーザーの追加

Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内でそのグループに管理ロールを割り当てる必要があります。これにより、このグループに属するすべてのユーザーがそのドメインの管理者になることができます。

管理ロールを新しいエンタープライズ・デプロイメント管理グループに割り当てる手順は次のとおりです。

1. 構成ウィザードで指定した管理資格証明を使用してWebLogic管理サーバー・コンソールにログインします。

作成して新しい認証プロバイダに提供した管理ユーザーの資格証明は使用しないでください。

2. 管理コンソールの左ペインで「セキュリティ・レルム」をクリックします。

3. デフォルト・セキュリティ・レルム(myrealm)をクリックします。

4. 「ロールとポリシー」タブをクリックします。

5. 表の「グローバル・ロール」エントリを開き、「ロール」をクリックします。

6. 「管理」ロールをクリックします。

7. 「条件の追加」をクリックします。

8. 「述部リスト」ドロップダウン・メニューで「グループ」を選択し、「次へ」をクリックします。

9. 「グループ引数名」フィールドにWCPAdministratorsと入力して、「追加」をクリックします。

WCPAdministratorsが引数のリスト・ボックスに追加されます。

10. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。

WCPAdministratorsグループが表示されるようになりました。

11. 「保存」をクリックして、WCPAdministratorsグループへの「管理」ロールの追加を終了します。

12. 新しいweblogic_wcpユーザー資格証明を使用してWebLogic管理サーバー・コンソールにログインし、変更が行われたことを確認します。

新しい認証プロバイダでプロビジョニングした新しい管理ユーザーの資格証明を使用してOracle WebLogic Server管理コンソールとFusion Middleware Controlにログインできる場合は、プロバイダは正常に構成されています。

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

新しい管理ユーザーおよびグループを作成したら、LDAPディレクトリで作成した管理ユーザー資格証明を使用して管理サーバーのboot.propertiesファイルを更新する必要があります。

1. WCPHOST1で、次のディレクトリに移動します。

ASERVER_HOME/servers/AdminServer/security

2. 既存のboot.propertiesファイルの名前を変更します。

mv boot.properties boot.properties.backup

3. テキスト・エディタを使用して、セキュリティ・ディレクトリにboot.propertiesというファイルを作成します。

4. 次の行をこのファイルに入力します。

username=weblogic_wcp
password=password

5. ファイルを保存します。

6. 管理サーバーを再起動します。

10.10 Administratorsグループへのwsm-pmロールの追加

新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動したら、エンタープライズ・デプロイメント管理LDAPグループ(WCPAdministrators)をメンバーとしてwsm-pmアプリケーション・ストライプのpolicy.Updaterロールに追加します。

1. Oracle WebLogic Server管理サーバーの資格証明を使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

これらは、最初にドメインを構成し、Oracle WebLogic Server管理ユーザー名(通常weblogic_wcp)とパスワードを作成したときに作成した資格証明です。

2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。

3. 「アプリケーション・ストライプ」ドロップダウン・メニューからwsm-pmアプリケーション・ストライプを選択します。

4. ロール名テキスト・ボックスの隣にある三角形のplayアイコン をクリックし、wsm-pmアプリケーション・ストライプのロール名をすべて検索します。

5. 編集するpolicy.Updater の行を選択します。

6. 「編集」アイコンをクリックして、ロールを編集します。

7. 「アプリケーション・ロールの編集」ページの「追加」アイコンをクリックします。

8. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。

9. 「プリンシパル名」の「次で始まる」フィールドにグループ名WCPAdministratorsを入力し、右矢印をクリックして検索を開始して、エンタープライズ・デプロイメントの管理者グループを検索します。

10. 検索結果で適切な管理者グループを選択し、「OK」をクリックします。

11. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

10.11 WebLogicプロキシ・プラグインの構成

リクエストがOracle HTTP Serverインスタンスを介して正しくルーティングされることを検証するには、構成したクラスタのWebLogic Plug-In Enabledパラメータを前もって設定する必要があります。

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

2. 「ドメイン構造」ペインで「環境」ノードを開きます。

3. 「チェンジ・センター」で「ロックして編集」をクリックします。

4. 「クラスタ」をクリックします。

5. Oracle HTTP Serverからのリクエストをプロキシ設定する、クラスタを選択します。

「構成: 一般」タブが表示されます。

6. 「詳細」セクションまでスクロール・ダウンして、開きます。

7. 「WebLogicプラグインの有効化」を「はい」に設定します。

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

9. 直近のドメイン拡張で複数のクラスタをデプロイした場合は、すべてのクラスタが一貫して更新されるまで、手順4から8を繰り返します。

10. 「チェンジ・センター」の「変更のアクティブ化」をクリックします。

11. この章で変更したすべてのクラスタのすべての管理対象サーバーを再起動します。

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

2つのOracle HTTP Serverインスタンス(WEBHOST1とWEBHOST2に1つずつ)を含むスタンドアロンのOracle HTTP Serverドメインをインストールおよび構成する方法を理解することは重要です。

この章では、Web層の構成およびWeb層ドメインのインストールと構成を行う際に使用される変数について説明します。

- Web層の構成時に使用される変数
Web層の構成中に、この項に示すディレクトリ変数を参照します。

- Web層ドメインについて
エンタープライズ・デプロイメントでは、各Oracle HTTP Serverインスタンスは個別のホストの専用スタンドアロン・ドメインに構成されます。これにより、実行および管理に必要な構成およびリソースを最小限に抑えた簡易な構成が可能になります。

- WEBHOST1へのOracle HTTP Serverのインストール
Oracle HTTP ServerソフトウェアをWeb層にインストールする手順を理解することは重要です。

- WEBHOST1でのWeb層ドメインの作成
最初のWeb層ホストで新しいOracle HTTP Serverスタンドアロン・ドメインを作成する方法を理解することはきわめて重要です。

- WEBHOST2でのWeb層ドメインのインストールおよび構成
WEBHOST1でOracle HTTP ServerをインストールしてWeb層ドメインを構成したら、WEBHOST2でも同じタスクを実行する必要があります。

- WEBHOST1およびWEBHOST2でのノード・マネージャおよびOracle HTTP Serverインスタンスの起動
WEBHOST1およびWEBHOST2でOracle HTTP Serverインスタンスを起動する方法を理解することは重要です。

- アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成
Webサーバー・インスタンスがリクエストをドメイン内のサーバーにルーティングするようにOracle HTTP Server構成ファイルを更新する方法を理解することは重要です。

上位トピック: 「エンタープライズ・ドメインの構成」

11.1 Web層の構成時に使用される変数

Web層の構成中に、この項に示すディレクトリ変数を参照します。

いくつかのディレクトリ変数の値は、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されています。

- OHS_ORACLE_HOME

- OHS_DOMAIN_HOME

さらに、次の仮想IP (VIP)アドレスおよびホスト名を参照することになります。

- ADMINVHN

- WEBHOST1

- WEBHOST2

11.2 Web層ドメインについて

エンタープライズ・デプロイメントでは、各Oracle HTTP Serverインスタンスは、個別のホストおよびその独自のスタンドアロン・ドメインに構成されます。これにより、最小限の構成と最小限のリソースを必要とする単純な構成を実行して管理できます。

Web層のOracle HTTP Serverインスタンスのロールおよび構成の詳細は、「Web層の理解」を参照してください。

11.3 WEBHOST1へのOracle HTTP Serverのインストール

Oracle HTTP ServerソフトウェアをWeb層にインストールする手順を理解することは重要です。

- WEBHOST1でのインストーラの起動

- Oracle HTTP Serverのインストール画面のナビゲート

- Oracle HTTP Serverインストールの確認

11.3.1 WEBHOST1でのインストーラの起動

インストール・プログラムを起動するには、次の手順を実行します。

1. WEBHOST1にログインします。

2. インストール・プログラムをダウンロードしたディレクトリに移動します。

3. 次のコマンドを入力して、インストール・プログラムを起動します。

./fmw_12.2.1.2.0_ohs_linux64.bin

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

11.3.2 Oracle HTTP Serverのインストール画面のナビゲート

次の表は、インストール・プログラムで表示される順序に画面を示しています。

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

表11-1 Oracle HTTP Serverのインストール画面

画面

説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索したり、組織用にすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストール場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

エンタープライズ・デプロイメントのためには、表7-3に示すOHS_ORACLE_HOME変数の値を入力します。

インストール・タイプ

「スタンドアロンHTTPサーバー(WebLogic Serverとは切り離して管理)」を選択します。

このインストール・タイプを使用すると、既存のOracle WebLogic Serverドメインとは切り離してOracle HTTP Serverインスタンスを構成できます。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告またはエラー・メッセージが表示された場合、ホスト・コンピュータおよび必須ソフトウェアが「ホスト・コンピュータのハードウェア要件」および「エンタープライズ・デプロイメント・トポロジのオペレーティング・システム要件」に示すシステム要件および動作保証情報を満たしていることを確認してください。

セキュリティ更新

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所有していないか、またはこの手順をスキップする場合、チェック・ボックスの選択を解除し、フォローアップのダイアログ・ボックスで選択を確認します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールまたはコマンドライン・インストールの詳細は、『Oracle Universal Installerによるソフトウェアのインストール』の「サイレント・モードでのOracle Universal Installerの使用」を参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを閉じます。

11.3.3 Oracle HTTP Serverインストールの確認

Oracle HTTP Serverインストールが正常に完了したことを確認するには、新しいOracleホーム・ディレクトリにインストールされたファイルをリストします。Oracle HTTP Server Oracleホームで、次のディレクトリを確認する必要があります。

ldap
ohs
srvm
has
css
crs
nls
oracore
precomp
rdbms
plsql
jlib
slax
sqlplus
xdk
oracle_common
webgate
bin
wlserver
OPatch
plugins
oui
perl
network
lib
oraInst.loc
install
cfgtoollogs
inventory

11.4 WEBHOST1でのWeb層ドメインの作成

最初のWeb層ホストで新しいOracle HTTP Serverスタンドアロン・ドメインを作成する方法を理解することはきわめて重要です。

- WEBHOST1での構成ウィザードの起動

- Oracle HTTP Serverドメインの構成ウィザード画面のナビゲート

11.4.1 WEBHOST1での構成ウィザードの起動

構成ウィザードを起動するには、次のディレクトリに移動し、次のようにWebLogic Server構成ウィザードを起動します。

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

11.4.2 Oracle HTTP Serverドメインの構成ウィザード画面のナビゲート

Web層ホスト上にOracle HTTP Serverインスタンスのスタンドアロン・ドメインを作成することをお薦めします。

次の項では、新しいスタンドアロンOracle HTTP Serverドメインを作成する方法を説明します。

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

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

- タスク3「Web層ドメインのJDKの選択。」

- タスク4「システム・コンポーネントの構成」

- タスク5「OHSサーバー画面」

- タスク7「構成仕様の確認およびドメインの構成」

- タスク8「ドメイン・ホームのメモ」

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

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

「ドメインの場所」フィールドで、OHS_DOMAIN_HOME変数に割り当てられている値を入力します。

次の点に注意してください。

- 構成ウィザードにより、ここでの指定に従って新しいディレクトリが作成されます。

- WebサーバーにDMZ外部の記憶域デバイスに対する依存関係が発生しないよう、ローカル記憶域にディレクトリを作成します。

注意:

- ドメイン・ホーム・ディレクトリの詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のドメイン・ホーム・ディレクトリに関する項を参照してください。

- この画面のその他のオプションの詳細は、Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成の構成タイプに関する項を参照してください。

- Web層およびDMZの詳細は、「標準的なエンタープライズ・デプロイメントのファイアウォールとゾーンの理解」を参照してください。

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

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

「テンプレート」画面で、Oracle HTTP Server (スタンドアロン) - 12.2.1.2.0 [ohs]を選択します。

ヒント:

この画面のオプションの詳細は、Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成のテンプレートに関する項を参照してください。

タスク3   Web層ドメインのJDKの選択。

Oracle HTTP ServerソフトウェアをインストールしたときにWeb層Oracleホームにインストールされた、Oracle Hotspot JDKを選択します。

タスク4   システム・コンポーネントの構成

「システム・コンポーネント」画面で、1つのOracle HTTP Serverインスタンスを構成します。画面には、デフォルトで1つのインスタンスが定義されています。これは作成の必要がある唯一のインスタンスです。

1. 「システム・コンポーネント」 フィールドのデフォルト・インスタンス名はohs1であることに注意してください。このデフォルト名を使用します。

2. 「コンポーネント・タイプ」フィールドで、「OHS」が選択されていることを確認します。

3. 「再起動間隔秒数」フィールドを使用して、アプリケーションが応答しない場合に、再起動を試行する前に待機する秒数を指定します。

4. 「再起動遅延秒数」フィールドを使用して、再起動を再度試行する前に待機する秒数を指定します。

タスク5   OHSサーバー画面

「OHSサーバー」画面を使用して、ドメイン内のOHSサーバーを構成します。

1. 「システム・コンポーネント」ドロップダウン・メニューから、ohs1を選択します。

2. 「リスニング・アドレス」フィールドにWEBHOST1と入力します。
残りのフィールドはすべて事前に移入されていますが、組織での必要に応じて値を変更できます。この画面のフィールドの詳細は、Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成のOHSサーバーに関する項を参照してください。

3. 「サーバー名」フィールドで、リスニング・アドレスとリスニング・ポートの値を確認します。
正しくは次のようになります。

http://WEBHOST1:7777

タスク6   ノード・マネージャの構成

ノード・マネージャのタイプとして「ドメインごとのデフォルトの場所」を選択して、ノード・マネージャのユーザー名とパスワードを指定します。

注意:

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

詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の複数マシンでのノード・マネージャの構成に関する項を参照してください。

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

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

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

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

ヒント:

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

タスク8   ドメイン・ホームのメモ

「構成に成功しました」画面で、ドメイン・ホームの場所が表示されます。

ここに表示される情報は、サーバーを起動して管理サーバーにアクセスする際に必要となるため、メモしておいてください。

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

11.5 WEBHOST2でのWeb層ドメインのインストールおよび構成

WEBHOST1でOracle HTTP ServerをインストールしてWeb層ドメインを構成したら、WEBHOST2でも同じタスクを実行する必要があります。

1. 「WEBHOST1へのOracle HTTP Serverのインストール」の手順を使用して、WEBHOST2にログインし、Oracle HTTP Serverをインストールします。

2. 「WEBHOST1でのWeb層ドメインの作成」の手順を使用して、WEBHOST2上に新しいスタンドアロン・ドメインを構成します。
WEBHOST2上のインスタンスにohs2という名前を使用して、各例におけるWEBHOST1の出現箇所をすべてWEBHOST2に置き換え、ohs1の出現箇所をすべてohs2に置き換えるようにしてください。

11.6 WEBHOST1およびWEBHOST2でのノード・マネージャおよびOracle HTTP Serverインスタンスの起動

WEBHOST1およびWEBHOST2でOracle HTTP Serverインスタンスを起動する方法を理解することは重要です。

- WEBHOST1およびWEBHOST2でのノード・マネージャの起動

- Oracle HTTP Serverインスタンスの起動

11.6.1 WEBHOST1およびWEBHOST2でのノード・マネージャの起動

Oracle HTTP Serverインスタンスを起動する前に、WEBHOST1およびWEBHOST2でノード・マネージャを起動する必要があります。

1. WEBHOST1にログインし、次のディレクトリに移動します。

OHS_DOMAIN_HOME/bin

2. 出力ファイル例としてnohupおよびnodemanager.outを使用して、次のようにノード・マネージャを起動します。

nohup OHS_DOMAIN_HOME/bin/startNodeManager.sh > OHS_DOMAIN_HOME/nodemanager/nodemanager.out 2>&1 &

3. WEBHOST2にログインし、手順1および2を実行します。

ノード・マネージャのその他の構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの拡張構成に関する項を参照してください。

11.6.2 Oracle HTTP Serverインスタンスの起動

Oracle HTTP Serverインスタンスを起動する手順は次のとおりです。

1. WEBHOST1上の次のディレクトリに移動します。

OHS_DOMAIN_HOME/bin

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

2. 次のコマンドを入力します。

./startComponent.sh ohs1

3. プロンプトが表示されたら、ノード・マネージャのパスワードを入力します。

4. 手順1から3までを繰り返して、ohs2インスタンスをWEBHOST2上で起動します。

詳細は、Oracle HTTP Serverの管理のOracle HTTP Serverインスタンスの起動に関する説明を参照してください。

11.7 アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成

Webサーバー・インスタンスがリクエストをドメイン内のサーバーにルーティングするようにOracle HTTP Server構成ファイルを更新する方法を理解することは重要です。

- エンタープライズ・デプロイメント用のOracle HTTP Server構成について

- 仮想ホスト構成ファイルを追加するためのhttpd.confファイルの変更

- 仮想ホスト構成ファイルの作成

- ロード・バランサでの仮想サーバー構成の検証

- 管理サーバーおよびOracle Web Services Managerへのルーティングの構成

- 管理コンソールおよび管理サーバーへのアクセスの検証

- Oracle Web Services Policy Managerへのアクセスの検証

11.7.1 エンタープライズ・デプロイメント用のOracle HTTP Server構成について

次のトピックでは、エンタープライズ・デプロイメントのOracle HTTP Server構成に必要な変更に関する概要情報を提供します。

- Oracle HTTP Server仮想ホストの目的

- <VirtualHost>ディレクティブのWebLogicClusterパラメータについて

- Oracle HTTP Server構成ファイルの推奨構造

11.7.1.1 Oracle HTTP Server仮想ホストの目的

このガイドの参照用トポロジでは、ハードウェア・ロード・バランサで一連の仮想サーバーを定義することが必要になります。Oracle HTTP Serverインスタンスの構成ファイルに<VirtualHost>ディレクティブを追加して、(ロード・バランサ仮想サーバーにマップされた)固有の仮想ホストへのリクエストを認識するようにOracle HTTP Serverを構成できます。

各Oracle HTTP Server仮想ホストについては、ロード・バランサからOracle HTTP Serverインスタンスを経由してOracle WebLogic Serverドメイン内の該当する管理サーバーまたは管理対象サーバーにリクエストをルーティングする特定のURL (またはコンテキスト文字列)のセットを定義します。

11.7.1.2 <VirtualHost>ディレクティブのWebLogicClusterパラメータについて

Oracle HTTP Serverの<VirtualHost>ディレクティブのキー・パラメータは、Oracle HTTP ServerのWebLogicプロキシ・プラグインの一部であるWebLogicClusterパラメータです。エンタープライズ・デプロイメント用にOracle HTTP Serverを構成する場合は、Oracle HTTP Server構成ファイルにこのパラメータを追加するときに次の情報を考慮してください。

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つ以上を実行しておくことで、クラスタに確実に到達できます。

11.7.1.3 Oracle HTTP Server構成ファイルの推奨構造

httpd.confファイルに複数の仮想ホスト定義を追加するのではなく、デプロイする製品に必要な各仮想サーバーに対してより小さくより具体的な別個の構成ファイルを作成することをお薦めします。そうすることで、すでに大きなhttpd.confファイルに追加のコンテンツを移入するのを回避できます。また、構成の問題のトラブルシューティングが容易になることがあります。

たとえば、通常のOracle Fusion Middleware Infrastructureドメインでは、admin_vh.confという名前の特定の構成ファイルを追加できます。この構成ファイルには、管理サーバー仮想ホスト(ADMINVHN)の仮想ホスト定義が含まれています。

11.7.2 仮想ホスト構成ファイルを追加するためのhttpd.confファイルの変更

次のタスクを実行して、エンタープライズ・トポロジに必要な追加の仮想ホストのhttpd.confファイルを準備します。

1. WEBHOST1にログインします。

2. ドメイン・ディレクトリで最初のOracle HTTP Serverインスタンス(ohs1)のhttpd.confファイルを見つけます。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/

3. 次のようにして、httpd.confファイルが適切に構成されているかどうか確認します。

a. 現在のWEBHOSTnの正しい値で置き換えて次のコマンドを実行し、ServerNameパラメータを検証して正しく設定されていることを確認します。

grep "ServerName http" httpd.conf
ServerName http://WEBHOST1:7777

b. 次のコマンドを実行してmoduleconfサブディレクトリからすべての*.confファイルをインクルードするinclude文があることを確認します。

grep moduleconf httpd.conf
IncludeOptional "moduleconf/*.conf"

c. いずれかの検証で結果が戻されない場合やコメント・アウトされた結果が戻される場合は、httpd.confファイルをテキスト・エディタで開き、適切な場所に必要な変更を加えます。

#
# ServerName gives the name and port that the server uses to identify itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#
# If your host doesn't have a registered DNS name, enter its IP address here.
#
ServerName http://WEBHOST1:7777
#  and at the end of the file:
# Include the admin virtual host (Proxy Virtual Host) related configuration
include "admin.conf"
IncludeOptional "moduleconf/*.conf"

d. httpd.confファイルを保存します。

4. WEBHOST2にログインし、必要に応じて説明でWEBHOST1またはohs1が出現する箇所をWEBHOST2またはohs2に置き換え、httpd.confファイルについて手順2および3を実行します。

11.7.3 仮想ホスト構成ファイルの作成

仮想ホスト構成ファイルを作成する手順は次のとおりです。

注意:
仮想ホスト構成ファイルを作成する前に、「Oracle HTTP Server仮想ホストの目的」の説明に従って、必ずロード・バランサで仮想サーバーを構成しておいてください。

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

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

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

<VirtualHost WEBHOST1:7777>
ServerName admin.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

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

<VirtualHost WEBHOST1:7777>
ServerName wcpinternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

4. ohs1インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力してインスタンスを停止および起動し、プロンプトが表示されたら、ノード・マネージャのパスワードを指定します。

./stopComponent.sh ohs1
./startComponent.sh ohs1

5. admin_vh.confファイルおよびwcpinternal_vh.confファイルを、WEBHOST2上の2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf

6. admin_vh.confファイルおよびwcpinternal_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1の参照からWEBHOST2の参照に変更します。

7. ohs2インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止および起動します。

./stopComponent.sh ohs2
./startComponent.sh ohs2

11.7.4 ロード・バランサでの仮想サーバー構成の検証

ロード・バランサから次のURLにアクセスして、ロード・バランサとOracle HTTP Serverが正しく構成されていることを確認します。これらのURLは、Oracle HTTP Server 12cの初期Webページを示しています。

- http://admin.example.com/index.html

- http://wcpinternal.example.com/index.html

11.7.5 管理サーバーおよびOracle Web Services Managerへのルーティングの構成

Oracle HTTP Serverが管理サーバーと、WLS_WSM管理対象サーバーが含まれているWSM-PM_Clusterにルーティングできるようにするには、一連の<Location>ディレクティブを追加して、WebLogicClusterパラメータをクラスタ内のノードのリストに追加する必要があります。

WebLogicClusterパラメータを設定する手順は次のとおりです。

1. WEBHOST1にログインし、ディレクトリを次の場所に変更します。

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

2. 次のディレクティブをadmin_vh.confファイルの<VirtualHost>タグ内に追加します。

# Admin Server and EM
<Location /console>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

admin_vh.confファイルは、例1「admin_vh.confファイル」のように表示されます。

3. 次のディレクティブをwcpinternal_vh.confファイルの<VirtualHost>タグ内に追加します。

注意:
WebLogic管理対象サーバーに基づいて、ポート番号を適切に設定します。

# WSM-PM
<Location /wsm-pm>
WLSRequest ON
WebLogicCluster WCCHOST1:7010,WCCHOST2:7010
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

wcpinternal_vh.confファイルは、「例2 wcpinternal_vh.confファイル」のように表示されます。

この例のWebLogicClusterパラメータの詳細は、「<VirtualHost>ディレクティブのWebLogicClusterパラメータについて」を参照してください。

4. ohs1インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs1
./startComponent.sh ohs1

5. admin_vh.confファイルおよびwcpinternal_vh.confファイルを、WEBHOST2上の2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/

6. admin_vh.confファイルおよびwcpinternal_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。

7. ohs2インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs2
./startComponent.sh ohs2

例1   admin_vh.confファイル

<VirtualHost WEBHOST1:7777>
ServerName admin.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# Admin Server and EM
<Location /console>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
WLSRequest ON
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>

例2   wcpinternal_vh.confファイル

このファイルの内容:

<VirtualHost WEBHOST1:7777>
ServerName wcpinternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# WSM-PM
<Location /wsm-pm>
WLSRequest ON
WebLogicCluster WCCHOST1:7010,WCCHOST2:7010
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
</VirtualHost>

11.7.6 管理コンソールおよび管理サーバーへのアクセスの検証

この章で行った変更を確認する手順は次のとおりです。

1. 次のハードウェア・ロード・バランサへのURLを使用してOracle WebLogic Server管理コンソールを表示し、Oracle WebLogic Server管理者資格証明を使用してログインします。

http://admin.example.com/console

これによって、ロード・バランサ上のadmin.example.com仮想ホストがWeb層のOracle HTTP Serverインスタンスにリクエストをルーティングでき、さらに、このOracle HTTP ServerインスタンスがOracle WebLogic Server管理コンソールのリクエストをアプリケーション層の管理サーバーにルーティングできることが検証されます。

2. 同様に、類似したURLを使用してFusion Middleware Controlにアクセスできます。

http://admin.example.com/em

11.7.7 Oracle Web Services Policy Managerへのアクセスの検証

Oracle HTTP Server仮想ホストおよび内部URLのロード・バランサが正しく構成されていることを確認するには、同様にWSM-PM構成を確認します。

次のハードウェア・ロード・バランサのURLを使用してOracle Web Services Policy ManagerのWebインタフェースを表示し、Oracle WebLogic Server管理者資格証明を使用してログインします。

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

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

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

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

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

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

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

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

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

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

上位トピック: 「エンタープライズ・ドメインの構成」

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

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

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

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

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

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

- インストールの検証

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

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

1. WCCHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

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

JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.2.0_wccontent_generic.jar

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

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

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

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

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

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

画面

説明

「インストール・インベントリ」画面

Oracle Fusion Middleware Infrastructureソフトウェアをインストールしたときに中央インベントリを作成しなかった場合に、このダイアログ・ボックスが表示されます。

ローカル・インベントリの場所を指すように「インベントリ・ディレクトリ」フィールドを編集して、「OK」をクリックします。

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索するか、組織のためにすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。

前提条件チェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、Oracle Fusion Middleware Infrastructureのインストール計画のシステム環境の検証ロードマップに関する項でいずれかのドキュメントを参照してください。

インストールの概要

この画面を使用して、選択したインストール・オプションを確認します。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

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

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

12.1.4 インストールの検証

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

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

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

- Oracleホームの内容の表示

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

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

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

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

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

/u01/oracle/products/fmw/wccontent
common
plugins
ucm
wccadf

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

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

12.1.4.3 Oracleホームの内容の表示

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

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

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

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

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

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

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

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

1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。

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

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

export JAVA_HOME=/u01/oracle/products/jdk

3. RCUを起動します。

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

./rcu

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

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

タスク1   RCUの概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ヒント:

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

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

ヒント:

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

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

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

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

ヒント:

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

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

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

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

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

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

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

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

次に例を示します。

./sqlplus

SQL*Plus: Release 11.2.0.4.0 Production on Fri Nov 1 08:44:18 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Enter user-name: WCPEDG_OCS
Enter password: ocs_password

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

SQL>

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

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

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

- 構成ウィザードの起動

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

12.3.1 構成ウィザードの起動

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

1. WebLogic Serverコンソールから、このドメイン拡張により変更される管理対象サーバーを停止します。影響を受けない管理対象サーバーはオンラインのままです。

2. 変更するすべての管理対象サーバーについて、管理対象サーバーの停止が完了していることを確認します。

3. すべての管理対象サーバーが安定した状態になったら、管理サーバーを停止します。

4. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

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

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

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

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

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

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

注意:

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

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

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

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

- タスク3「データベース構成タイプの指定」

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

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

- タスク6「JDBC接続のテスト」

- タスク7「拡張構成の選択」

- タスク8「管理対象サーバーの構成」

- タスク9「クラスタの構成」

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

- タスク11「動的サーバーの構成」

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

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

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

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

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

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

- タスク18「ファイル・ストアの構成」

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

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

- タスク21「管理サーバーの起動」

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

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

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

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

ヒント:

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

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

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

- Oracle Universal Content Management - コンテンツ・サーバー - 12.2.1.2.0 [wccontent]
また、初期インフラストラクチャ・ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

- Oracle Enterprise Manager - 12.2.1.2.0 [em]

- Oracle JRF - 12.2.1.2.0 [oracle_common]

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

ヒント:

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

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

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

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

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

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

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

Successfully Done.

ヒント:

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

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

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

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

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

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

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

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

要素

説明と推奨値

「SCAN」、「ホスト名」および「ポート」

「SCAN」チェック・ボックスを選択します。

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

「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

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

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。

タスク6   JDBC接続のテスト

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

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

ヒント:

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

タスク7   拡張構成の選択

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

- トポロジ

- ファイル・ストア

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

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

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

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

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

ヒント:

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

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

サーバー名

リスニング・アドレス

リスニング・ポート

SSLの有効化

SSLリスニング・ポート

サーバー・グループ

WLS_WCC1

WCCHOST1

16200

選択解除

無効

UCM-MGD-SVR

WLS_WCC2

WCCHOST2

16200

選択解除

無効

UCM-MGD-SVR

ヒント:

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

タスク9   クラスタの構成

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

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

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

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

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

注意:

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

ヒント:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ヒント:

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

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

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

注意:

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

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

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

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

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

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

4. この手順をWCCHOST2に対して繰り返します。

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

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

名前

ノード・マネージャのリスニング・アドレス

ノード・マネージャのリスニング・ポート

WCCHOST1

WCCHOST1ホスト名変数の値。たとえば、WCCHOST1.example.comです。

5556

WCCHOST2

WCCHOST2ホスト名変数の値。たとえば、WCCHOST2.example.comです。

5556

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

「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle WebCenter Content管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。

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

ヒント:

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

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

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

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

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

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

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

ORACLE_RUNTIME/domain_name/WCC_Cluster/jms

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

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

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

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

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

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

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

ヒント:

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

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

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

- ドメインの場所

- 管理サーバーURL

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

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

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

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

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

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

- ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

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

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

- uploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

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

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

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

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

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

- GridLinkデータ・ソースの検証

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

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

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

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

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

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

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのコピーを作成します。

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

cd ORACLE_COMMON_HOME/common/bin

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

この例では、次のとおりです。

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

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

SHARED_CONFIG_DIR/domains/template_filename.jar

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

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

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

cd ORACLE_COMMON_HOME/common/bin

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

この例では、次のとおりです。

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

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

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

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

ヒント:

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

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

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

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

cd ORACLE_COMMON_HOME/common/bin

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

この例では、次のとおりです。

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

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

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

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

ヒント:

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

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

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

注意:

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

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

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

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

grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties

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

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

3. 現在のCustomIdentityAliasパラメータ値を確認します。

grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties

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

5. nodemanagerプロセスを再起動します。

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

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

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

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

1. WebLogic Serverコンソールから、WebServices Manager Policy ManagerのWLS_WSMn管理対象サーバーを再起動します。

2. 別のブラウザ・ウィンドウから、URLを正常にロードすることで、WSM-PMアプリケーションが応答していることを確認します。

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

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

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

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

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

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

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

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

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

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

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

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

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

MSERVER_HOME/servers/server_or_template_name/stage

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

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

ASERVER_HOME/servers/AdminServer/upload

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

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

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

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

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

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

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

1. http://admin.example.com/consoleでOracle WebLogic Server管理コンソールにログインします。

2. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_WCC1管理対象サーバーを起動します。

a. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

b. 「サーバー」をクリックします。

c. 「サーバーのサマリー」ページで、「制御」タブを開きます。

d. 「WLS_WCC1」を選択して、「起動」をクリックします。

3. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

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

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

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

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

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

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

2. http://WCCHOST1:16200/csでweblogicユーザー名とパスワードを使用してWLS_WCC1にログインし、構成ページを表示します。
Oracle WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Contentエンタープライズ・デプロイメントの共有ディスクの場所は、ORACLE_RUNTIME/wcpedg_domain/WCC_Clusterです。

3. 「サーバーの構成」ページで次の値を変更します。
「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていることを確認します。

- コンテンツ・サーバーのインスタンス・フォルダ: これをORACLE_RUNTIME/domain_name/WCC_Cluster/cs/に設定します
例:/u01/oracle/runtime/wcpedg_domain/WCC_Cluster/cs/

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

- Webレイアウト・フォルダ: これをORACLE_RUNTIME/domain_name/WCC_Cluster/cs/weblayout/に設定します
例:/u01/oracle/runtime/wcpedg_domain/WCC_Cluster/cs/weblayout/

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

- サーバーのソケット・ポート: 4444

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

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

注意:
内部仮想サーバーおよびプライマリ・インタフェース用のロード・バランサIPアドレスを含め、すべてのエントリにIPアドレスを使用する必要があります。これは、ロード・バランサのネットワーク・アドレス変換構成設定に依存します。

- WebサーバーのHTTP/HTTPSアドレス: wcp.example.com:443

- WebアドレスはHTTPSです: このチェック・ボックスを選択します。

- コンテンツ・サーバーのインスタンス名: WCC_Cluster

- コンテンツ・サーバーのインスタンス・ラベル: WCC_Cluster

- サーバー・インスタンスの説明: WebCenter Contentクラスタ

- 自動採番接頭辞: WCC_Cluster-

4. 終了する場合、「発行」をクリックします。

5. WebLogic Server管理コンソールを使用して、管理対象サーバーを再起動します。

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

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

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

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

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

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

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

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

1. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_WCC2管理対象サーバーを起動します。

a. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

b. 「サーバー」をクリックします。

c. 「サーバーのサマリー」ページで、「制御」タブを開きます。

d. 「WLS_WCC2」,を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

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

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

1. http://WCCHOST2:16200/csでweblogic管理ユーザー名とパスワードを使用してWLS_WCC2にログインし、構成ページを表示します。
Oracle WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Contentエンタープライズ・デプロイメントの共有ディスクの場所は、ORACLE_RUNTIME/WCDomain/WCC_Clusterです。

2. 「サーバーの構成」ページで次の値を変更します。

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

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

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

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

- コンテンツ・サーバーのURL接頭辞: /cs/ (デフォルト値)

「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。

3. 終了する場合、「発行」をクリックします。

4. WebLogic Server管理コンソールを使用して、管理対象サーバーを再起動します。

12.4.10 GridLinkデータ・ソースの検証

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

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

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

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

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

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

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. 作成済のGridLinkデータ・ソース名をクリックします。

4. 「監視」タブをクリックします。

5. 「テスト」タブをクリックし、サーバーの1つを選択して「データ・ソースのテスト」をクリックします。
構成が正しい場合、テストは成功します。

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

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

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

1. 管理コンソールの「ドメイン構造」ツリーで、「サービス」ノードを開いて「データ・ソース」をクリックします。

2. GridLinkデータ・ソースの名前をクリックします。

3. 「監視」タブをクリックします。

4. サーバーの名前(WLS_WCC1)をクリックします。

5. 「ONS」タブをクリックします。

6. 「ONS」タブで、「テスト」タブを選択します。

7. サーバーを選択し、「ONSのテスト」をクリックします。
構成が正しい場合、テストは成功します。ONSのテストが失敗する場合、Oracle RACデータベース・ノードでONSサービスが実行されていることを確認します。

[orcl@WCCDBHOST1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node WCCDBHOST1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node WCCDBHOST2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node WCCDBHOST2

[orcl@WCCDBHOST1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@WCCDBHOST1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: WCCDBHOST1
ONS daemon is running on node: WCCDBHOST2

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

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

テキスト・エディタを使用して、次のオプションを各クラスタ・ノードのMSERVER_HOME/ucm/cs/bin/intradoc.cfgファイルに追加します。

注意:
指定するMSERVER_HOMEディレクトリ・パスは、ローカル管理対象サーバーのドメイン・ホームのパスであり、サーバー間で共有されるランタイム・クラスタ・ディレクトリではありません。

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

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

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

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

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

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

ServiceAllowRetry=true

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

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

1. コンテンツ・サーバー(http://WCCHOST1:16200/cs)にアクセスし、非LDAP WebLogic Serverの管理ユーザー名(たとえば、weblogic)とパスワードを使用してログインします。

2. 「管理」トレイまたはメニューで、「管理サーバー」、「一般構成」の順に選択します。

3. 「一般構成」ページで、「追加の構成変数」ボックスに、次のパラメータを追加します。

ServiceAllowRetry=true

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

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

注意:

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

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

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

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

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

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

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

1. weblogicアカウントを使用してコンテンツ・サーバーにログインします。

2. 「管理」メニューを開き、「資格証明マップ」を選択します。

3. 「マップ識別子」フィールドに、新しい資格証明マップの名前をLDAPAdminsと入力します。

4. 次の行を追加して、LDAPグループを複数の管理ロールにマップします。

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

注意:
アカウントを実装しない場合、前述の例の最後の2行をコメント・アウトします。

5. 「更新」をクリックします。

6. 「管理」→「プロバイダ」に移動します。

7. 既存のJPSプロバイダの「info」リンクをクリックします。

8. 「資格証明マップ」パラメータが、リストされたマップ識別子をまだ持っていないことを確認します。

9. 「編集」ボタンをクリックします。

10. 前述の手順3のマップ識別子の名前を「資格証明マップ」の値として入力します。

11. 「更新」をクリックします。

12. WCCHOST2のコンテンツ・サーバーについて、変更したプロセスを繰り返します。

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

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

13. WCC_Cluster内の管理対象サーバーを再起動します。

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

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

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

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

- WebLogicプロキシ・プラグインの構成

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

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

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

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

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

注意:

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

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

<VirtualHost WEBHOST1:7777>
ServerName https://wcp.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

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

#UCM
<Location /cs>
WebLogicCluster WCCHOST1:16200,WCCHOST2:16200
WLSRequest ON
WLCookieName JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /adfAuthentication>
WebLogicCluster WCCHOST1:16200,WCCHOST2:16200
WLSRequest ON
WLCookieName JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /_ocsh>
WebLogicCluster WCCHOST1:16200,WCCHOST2:16200
WLSRequest ON
WLCookieName JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

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

OHS_DOMAIN_HOME/config/fmwconfig/components/ohs2/moduleconf/

5. wcp_vh.confを編集して、<VirtualHost>ディレクティブ内のWEBHOST1の参照をWEBHOST2の参照に変更します。

6. WEBHOST1とWEBHOST2上のOracle HTTP Serverインスタンスを再起動します。

12.5.2 WebLogicプロキシ・プラグインの構成

リクエストがOracle HTTP Serverインスタンスを介して正しくルーティングされることを検証するには、構成したクラスタのWebLogic Plug-In Enabledパラメータを前もって設定する必要があります。

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

2. 「ドメイン構造」ペインで「環境」ノードを開きます。

3. 「チェンジ・センター」で「ロックして編集」をクリックします。

4. 「クラスタ」をクリックします。

5. Oracle HTTP Serverからのリクエストをプロキシ設定する、クラスタを選択します。

「構成: 一般」タブが表示されます。

6. 「詳細」セクションまでスクロール・ダウンして、開きます。

7. 「WebLogicプラグインの有効化」を「はい」に設定します。

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

9. 直近のドメイン拡張で複数のクラスタをデプロイした場合は、すべてのクラスタが一貫して更新されるまで、手順4から8を繰り返します。

10. 「チェンジ・センター」の「変更のアクティブ化」をクリックします。

11. この章で変更したすべてのクラスタのすべての管理対象サーバーを再起動します。

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

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

- URLの検証

- クラスタ・ノードの検証

12.5.3.1 URLの検証

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

1. WLS_WCC2が稼動している状態で、WebLogic Server管理コンソールを使用してWLS_WCC1を停止します。

2. https://wcp.example.com/csにアクセスし、正しく動作していることを確認します。

3. WebLogic Server管理コンソールからWLS_WCC1を起動します。

4. WebLogic Server管理コンソールでWLS_WCC2を停止します。

5. https://wcp.example.com/csにアクセスし、正しく動作していることを確認します。

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

12.5.3.2 クラスタ・ノードの検証

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

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

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

2. 「管理」の「WCC_Clusterの構成」ページを表示します。

3. ページの「オプションとその他」セクションで、右側の「Javaプロパティ」をクリックします。

4. weblogic.Nameの値を確認します。

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

12.6 WebCenter Portal用のOracle WebCenter Contentの構成

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

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

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

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

- その他のContent Server機能の構成

12.6.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を使用するか、FrameworkFolderインタフェースに移行できます。パフォーマンスを向上させてContent Serverの任意の新機能を使用できるようにするために、FrameworkFoldersインタフェースに移行することをお薦めします。

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

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

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

- Inbound Refineryを使用するためのドメインの拡張
この項では、Inbound Refineryソフトウェアを含めて既存のエンタープライズ・デプロイメント・ドメインを拡張する手順を説明します。

- Inbound Refinery用の構成後タスクおよび検証タスクの実行
Inbound Refineryソフトウェアを含めてドメインを拡張した後、次の構成後タスクと検証タスクを行うことを考慮してください。

- Inbound Refinery管理対象サーバーの構成
Inbound Refinery管理対象サーバーの構成を初期化するには、その管理対象サーバーに一度だけHTTP経由でアクセスする必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound RefineryインスタンスはHTTPサーバーの後方に配置する必要があります。

- Inbound Refinery管理対象サーバーの構成の検証
作成したInbound Refinery管理対象サーバーが正しく構成されているかどうかを確認するには、コンテンツ・サーバーにログインし、変換に有効と認識された拡張子を持つファイルが正しく変換されることを確認して、構成を検証します。

上位トピック: 「エンタープライズ・ドメインの構成」

13.1 Inbound Refineryを使用するためのドメインの拡張

この項では、Inbound Refineryソフトウェアを含めて既存のエンタープライズ・デプロイメント・ドメインを拡張する手順を説明します。

- 構成ウィザードの起動

- ドメインを拡張するために構成ウィザード画面へ移動

13.1.1 構成ウィザードの起動

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

1. WebLogic Serverコンソールから、このドメイン拡張により変更される管理対象サーバーを停止します。影響を受けない管理対象サーバーはオンラインのままです。

2. 変更するすべての管理対象サーバーについて、管理対象サーバーの停止が完了していることを確認します。

3. すべての管理対象サーバーが安定した状態になったら、管理サーバーを停止します。

4. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

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

13.1.2 ドメインを拡張するために構成ウィザード画面へ移動

トポロジのドメインを更新して構成するには、この項の手順に従います。

注意:

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

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

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

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

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

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

ヒント:

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

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

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

- Oracle Universal Content Management - Inbound Refinery - 12.2.1.2.0 [wccontent]
Infrastructureテンプレート、WebCenter PortalテンプレートおよびWebCenter Contentテンプレートは、初期ドメインの作成および更新に使用されたため、すでに選択されています。

ヒント:

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

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

「GridLink Oracle RACコンポーネント・スキーマ」画面で「次へ」をクリックします。

タスク4   JDBC接続のテスト

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

タスク5   拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で次のオプションを選択する必要があります。

トポロジ

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

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

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

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

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

ヒント:

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

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

表13-1 各Oracle Inbound Refineryサーバーで必要な値

サーバー名

リスニング・アドレス

リスニング・ポート

SSLの有効化

SSLリスニング・ポート

サーバー・グループ

WLS_IBR1

WCCHOST1

16250

いいえ

無効

IBR-MGD-SVR

WLS_IBR2

WCCHOST2

16250

いいえ

無効

IBR-MGD-SVR

ヒント:

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

タスク7   クラスタの構成

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

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

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

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

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

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

注意:

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

ヒント:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ヒント:

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

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

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期インフラストラクチャ・メインの作成中に定義されているため、9991のままにします。

注意:

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

タスク12 既存のマシンの検証

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

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

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

「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle Inbound Refinery管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。

WLS_IBR1をWCCHOST1、WLS_IBR2をWCCHOST2に割り当てます。

ヒント:

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

タスク14   仮想ターゲットの確認

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

タスク15   パーティションの確認

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

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

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

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

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

ヒント:

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

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

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

- ドメインの場所

- 管理サーバーURL

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

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

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

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

13.2 Inbound Refinery用の構成後タスクおよび検証タスクの実行

Inbound Refineryソフトウェアを含めてドメインを拡張した後、次の構成後タスクと検証タスクを行うことを考慮してください。

- Inbound Refineryのドメイン構成の更新の伝播

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

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

- uploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

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

13.2.1 Inbound Refineryのドメイン構成の更新の伝搬

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。Inbound Refinery管理対象サーバーにドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのバックアップ・コピーを作成します。

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

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=/full_path/edgdomaintemplateExtIBR.jar
-template_name=edgdomain_templateIBR

この例では、次のとおりです。

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

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

SHARED_CONFIG_DIR/domains/template_filename.jar

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

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

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

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-template=/full_path/edgdomaintemplateExtIBR.jar
-app_dir=APPLICATION_HOME
-overwrite_domain=true

この例では、次のとおりです。

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

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

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

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

ヒント:

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

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

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

full_pathを、テンプレートJARファイルをコピーするディレクトリの完全なパスで置き換えます。

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

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-template=/full_path/edgdomaintemplateExtIBR.jar
-app_dir=APPLICATION_HOME
-overwrite_domain=true

この例では、次のとおりです。

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

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

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

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

ヒント:

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

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

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

注意:

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

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

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

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

grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties

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

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

3. 現在のCustomIdentityAliasパラメータ値を確認します。

grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties

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

5. nodemanagerプロセスを再起動します。

kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

詳細は、「カスタム・キーストアを使用するためのノード・マネージャの構成」を参照してください。

13.2.3 既存の管理対象サーバーの再起動と検証

ドメインが拡張され、すべてのサーバーのMSERVER_HOMEディレクトリに解凍されたので、既存のコンポーネントの管理対象サーバーを再起動します。

1. WebLogic Serverコンソールから、まずWLS_WSMn管理対象サーバーを再起動します。

2. 別のブラウザ・ウィンドウから、URLを正常にロードすることで、WSM-PMアプリケーションが応答していることを確認します。

http://wcpinternal.example.com/wsm-pm/validator

3. 解凍されたMSERVER_HOMEで同一場所に配置されている他の管理対象サーバーをすべて再起動します。これは、必要に応じて、ローリング方式で実行できます。次の手順を続行する前に、必要なサーバーの再起動およびサービスの検証を完了します。

13.2.4 uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

この手順は、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。

管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

3. 「ロックして編集」をクリックします。

4. 使用するクラスタ・タイプに適したオブジェクトに移動して編集します。

a. 静的クラスタの場合、「サーバー」に移動し、編集する管理対象サーバーの名前をクリックします。

5. 編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。

a. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

b. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。

MSERVER_HOME/servers/server_or_template_name/stage

MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。静的クラスタを使用している場合、編集する管理対象サーバーの正しい名前で更新します。

c. 「アップロード・ディレクトリ名」を次の値に更新します。

ASERVER_HOME/servers/AdminServer/upload

ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

d. 「保存」をクリックします。

e. 「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。

6. 該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。

7. これらの変更の影響を受けるすべての管理対象サーバーを再起動します。

13.2.5 Inbound Refinery管理対象サーバーの起動

WCCHOST1でWLS_IBR1管理対象サーバーを起動する手順は次のとおりです。

1. 次のURLでOracle WebLogic Server管理コンソールにweblogic_wcpユーザーとしてログインします。

http://admin.example.com/console

2. 次の手順に従い、管理コンソールを使用してWLS_IBR1管理対象サーバーを起動します。

a. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

b. 「サーバー」をクリックします。

c. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

d. 表の「サーバー」列からWLS_IBR1を選択します。

e. 「起動」をクリックします。

3. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

- サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。

- 「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

4. 前述の手順を繰り返し、WCCHOST2でWLS_IBR2管理対象サーバーを起動します。

13.3 Inbound Refinery管理対象サーバーの構成

Inbound Refinery管理対象サーバーの構成を初期化するには、その管理対象サーバーに一度だけHTTP経由でアクセスする必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound RefineryインスタンスはHTTPサーバーの後方に配置する必要があります。

Inbound Refineryインスタンスへのすべての後続のアクセスは、ソケット・リスナーを介して行われます。このリスナーは、次の項で構成する着信ソケット接続アドレス・セキュリティ・フィルタによって保護されます。

すべてのInbound Refineryインスタンスを使用して各コンテンツ・サーバー・インスタンスを構成することをお薦めします。コンテンツ・サーバーの構成プロセスは、Inbound Refineryインスタンスをプロバイダとして追加することです。また、一部のインストール後の手順をInbound Refineryで実行する必要があります。

次の項では、各Inbound Refineryインスタンスのインストール後の構成手順について説明します。

- Inbound Refineryの設定の構成
Inbound Refinery管理対象サーバーを起動した後、インストール後の構成画面で各サーバーの設定を構成します。

- 資格証明マップ経由のWebCenter Content管理ロールの付与

- フォント・パスの指定

- Inbound Refineryにジョブを送信して変換するためのコンテンツ・サーバーの設定
Oracle WebCenter Content ServerからInbound Refineryにジョブを送信して変換を実施できるようにするには、次の項の説明に従って、Inbound Refinery管理対象サーバーごとに設定タスクを事前に実行する必要があります。

13.3.1 Inbound Refineryの設定の構成

Inbound Refinery管理対象サーバーを起動した後、インストール後の構成画面で各サーバーの設定を構成します。

各Inbound Refineryインスタンスの設定を構成する手順は次のとおりです。

1. Oracle WebCenter Content Inbound Refinery共有フォルダ構成に必要なランタイム・クラスタ・サブディレクトリを作成します。

Oracle WebCenter Content Inbound Refinery構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクに配置されます。Oracle WebCenter Content Inbound Refineryエンタープライズ・デプロイメントの共有ディスクの場所は、ORACLE_RUNTIME/domain_name/IBR_Servers/です。

次のコマンドを実行して、各IBR管理対象サーバーに必要なサブディレクトリを作成します。

mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr1/vault
mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr1/weblayout
mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr1/data/users/profiles
mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr2/vault
mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr2/weblayout
mkdir -p ORACLE_RUNTIME/domain_name/IBR_Servers/ibr2/data/users/profiles

2. 次のURLからInbound Refineryのインストール後の構成画面にアクセスします。Nには1または2を指定します。

http://WCCHOSTN:16250/ibr/

3. 「構成」画面で、「Inbound Refineryのインスタンス識別子: name」を確認します。このインスタンスの構成設定を次のように設定します。各Inbound Refineryインスタンスは、他のインスタンスとは独立し、各マシンに対してローカルです。各インスタンスの構成ディレクトリとしてローカル・ディレクトリを使用します。

- Inbound Refineryのインスタンス・フォルダ: これをORACLE_RUNTIME/domain_name/IBR_Servers/ibrNに設定します。
例: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1

- ネイティブ・ファイル・リポジトリの場所: これをORACLE_RUNTIME/domain_name/IBR_Servers/ibrN/vaultに設定します。
例: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1/vault

- Webレイアウト・フォルダ: これをORACLE_RUNTIME/domain_name/IBR_Servers/ibrN/weblayoutに設定します。
例: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1/weblayout

- ユーザー・プロファイル・フォルダ: これを ORACLE_RUNTIME/domain_name/IBR_Servers/ibrN/data/users/profilesに設定します。
例: /u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibr1/data/users/profiles

- 受信ソケット接続アドレス・セキュリティ・フィルタ:: ローカル・ホストとサーバーIPアドレスのパイプ区切りのリストです。
127.0.0.1|0:0:0:0:0:0:0:1|WCCHOST1-IP|WCCHOST2-IP|WEBHOST1-IP|WEBHOST2-IP

この設定によってコンテンツ・サーバーからアクセスできるようになります。WCCHOST1-IPおよびWCCHOST2-IPの値は、Inbound Refineryにジョブを送信するコンテンツ・サーバーのインスタンスが1つ以上あるマシンのIPアドレスである必要がありますが、必ずしもInbound RefineryのIPアドレスとは限りません。(ただし、このエンタープライズ・デプロイメント・ガイドで使用される参照トポロジでは、これらのIPアドレスは同じです。)

「ソケット接続アドレス・セキュリティ・フィルタを着信中」フィールドの値にはワイルドカードを指定できます(例: 192.0.2.*)。

この値は、後で/u02/oracle/runtime/wcpedg_domain/IBR_Servers/ibrN/config/config.cfgファイルのSocketHostAddressSecurityFilterを設定し、Inbound Refinery管理対象サーバーを再起動すると、変更できます。

http://WCCHOST1:16250/ibr/ではNが1、http://WCCHOST2:16250/ibr/ではNが2

- サーバーのソケット・ポート: 5555のように、使用されていないポート番号を入力します。この値は、トップレベルのサービスを呼び出すためのポートの番号です。
このポート番号は、後でOracle WebCenter Contentの構成時に必要となるため、書き留めておいてください。

このフィールド値を変更すると、/u01/oracle/runtime/wcpedg_domain/IBR_Servers/ibrN/config/config.cfgのIntradocServerPortエントリが変更されます。

http://WCCHOST1:16250/ibr/ではNが1、http://WCCHOST2:16250/ibr/ではNが2

- コンテンツ・サーバーのインスタンス名: Inbound Refineryサーバーのインスタンス名を指定します。
デフォルト値を受け入れることも、より便利な名前に変更することもできます。このサーバー名は、後でOracle WebCenter Contentの構成時に必要となるため、書き留めておいてください。

構成ページの他のすべてのフィールドはそのままにします。

「送信」をクリックすると、次のメッセージが表示されます。

インストール後の構成が完了しました。このノードを再起動してください。

4. WebLogic Server管理コンソールを使用して、Inbound Refinery管理対象サーバーを再起動します。

5. 各Inbound Refineryインスタンスに対して個別のコンテンツ・フォルダ名を使用して、前述の手順を実行します。

13.3.2 資格証明マップ経由のWebCenter Content管理ロールの付与

資格証明マップを構成してWCPAdministrators LDAPグループにContent Server管理ロールを付与する必要があります。

WCPAdministrators LDAPグループは、以前に完了した「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」の項で作成されました。資格証明マップのこの構成により、すべての構成、管理およびメンテナンス・タスクのLDAP管理ユーザーの一貫した利用が保証されます。

資格証明マップを構成し、LDAPベースのWCPAdministratorsグループに必要なロール権限を付与する手順は次のとおりです。

1. weblogicアカウントを使用してWCCHOST1のInbound Refineryサーバーにログインします。

2. 「管理」メニューを開き、「資格証明マップ」を選択します。

3. 「マップ識別子」フィールドに、新しい資格証明マップの名前をLDAPAdminsと入力します。

4. 次の行を追加して、LDAPグループを複数の管理ロールにマップします。

# Assign full set of administration roles to the LDAP WCPAdministrators group
WCPAdministrators, admin
WCPAdministrators, sysmanager
WCPAdministrators, refineryadmin
WCPAdministrators, rmaadmin
WCPAdministrators, pcmadmin
WCPAdministrators, ermadmin
#
# Comment the following if you are not implementing Accounts in Content Server
WCPAdministrators, @#all(RWDA)
WCPAdministrators, @#none(RWDA)

注意:
アカウントを実装しない場合、前述の例の最後の2行をコメント・アウトします。

5. 「更新」をクリックします。

6. 「管理」→「プロバイダ」に移動します。

7. 既存のJPSプロバイダの「info」リンクをクリックします。

8. 「資格証明マップ」パラメータが、リストされたマップ識別子をまだ持っていないことを確認します。

9. 「編集」ボタンをクリックします。

10. 前述の手順3のマップ識別子の名前を「資格証明マップ」の値として入力します。

11. 「更新」をクリックします。

12. WCCHOST2のInbound Refineryサーバーについて、このプロセスを繰り返します。

13. IBR_Serversクラスタ内の管理対象サーバーを再起動します。

14. weblogic_wcp LDAPユーザーを使用して各Inbound Refineryサーバーにログインし、管理メニュー・オプションがユーザー・インタフェースに表示されていることを確認します。

13.3.3 フォント・パスの指定

Inbound Refineryが正常に機能するには、フォント・イメージを生成するために使用されるフォントへのパスを指定する必要があります。デフォルトでは、フォント・パスはInbound Refineryで使用されるJVM内のフォント・ディレクトリ(MW_HOME/jdk160_version/jre/lib/fonts)に設定されます。ただし、デフォルト・ディレクトリに含まれるフォントは限定されているため、レンディションが低下する可能性があります。また、非標準のJVMを使用した場合、デフォルトで指定されているJVMのフォント・パスと異なることがあります。この場合、エラー・メッセージがInbound Refineryとコンテンツ・サーバーの両方から表示されます。これが発生した場合は、変換を正しくレンダリングするために必要なフォントを含むディレクトリにフォント・パスが設定されていることを確認してください。

詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージメント』のフォント・パスの指定に関する項を参照してください。

13.3.4 Inbound Refineryにジョブを送信して変換するためのコンテンツ・サーバーの設定

Oracle WebCenter Content ServerからInbound Refineryにジョブを送信して変換を実施できるようにするには、次の項の説明に従って、Inbound Refinery管理対象サーバーごとに設定タスクを事前に実行する必要があります。

- 送信プロバイダの作成
コンテンツ・サーバーからInbound Refineryにファイルを送信して変換を実施するには、「Inbound Refinery変換ジョブの処理」オプションを事前に選択して、コンテンツ・サーバーから各Inbound Refineryへの送信プロバイダを設定する必要があります。

- コンテンツ・サーバーでのInbound Refinery用のコンポーネントの有効化
変換タイプによっては、コンテンツ・サーバーでヘルパー・コンポーネントを有効にする必要があります。ドキュメント変換にInbound Refineryを使用するコンテンツ・サーバーのインスタンスでは、InboundRefinerySupportコンポーネントを常に有効にする必要があります。新しいコンテンツ・サーバーのインストールではデフォルトで有効になっています。

- 変換するファイル形式の選択
変換のためにInbound Refineryに送信するファイルをコンテンツ・サーバーに指定するには、ファイル形式を選択する必要があります。

13.3.4.1 送信プロバイダの作成

コンテンツ・サーバーからInbound Refineryにファイルを送信して変換を実施するには、「Inbound Refinery変換ジョブの処理」オプションを事前に選択して、コンテンツ・サーバーから各Inbound Refineryへの送信プロバイダを設定する必要があります。

各Inbound Refineryインスタンスの送信プロバイダを作成する手順は次のとおりです。

1. 次のURLからコンテンツ・サーバーにログインします。

http://WCCHOST1:16200/cs/

2. 「管理」トレイまたはメニューを開いて、「プロバイダ」を選択します。

3. 「プロバイダ」ページの「新規プロバイダの作成」表で、「送信」行の「追加」をクリックします。

4. 次の値をフィールドに入力します。

- プロバイダ名: 空白が含まれない短縮名。「インスタンス名」と同じ値を使用することをお薦めします。

- プロバイダの説明: テキスト文字列。

- サーバー・ホスト名: Inbound Refineryインスタンスが実行されているホスト・マシンの名前。たとえば、WCCHOST1など。

- HTTPサーバー・アドレス: Inbound Refineryインスタンスのアドレス。たとえば、WCCHOST1: 16250など。

- サーバー・ポート: 「Inbound Refineryの設定の構成」で指定されている「サーバーのソケット・ポート」フィールドの値。たとえば、5555など。これは、Inbound Refineryconfig.cfgファイルのIntradocServerPort値です。

- インスタンス名: 「Inbound Refineryの設定の構成」で指定されているInbound Refineryのサーバー・インスタンス名。これは、Inbound Refineryconfig.cfgファイルのIDC_Name値です。

- 相対Webルート: Inbound RefineryインスタンスのWebルート。たとえば、/ibr/など

5. 「変換オプション」で、「Inbound Refinery変換ジョブの処理」を選択します。

「Inbound Refineryの読取り専用モード」は選択しないでください。

6. 「追加」をクリックします。

7. WebLogic Server管理コンソールを使用して、Inbound Refinery管理対象サーバーとOracle WebCenter Content Server (WebCenter Content管理対象サーバー)を再起動します。

8. 「プロバイダ」ページに戻り、プロバイダの「接続状態」の値が「良好」であることを確認します。

値が「良好」でない場合は、前述のエントリをすべて正しく入力したことを再確認し、コンテンツ・サーバーとInbound Refineryのインスタンスが相互にpingできることを確認します。

9. 2番目のIBRサーバーに対して手順1～8を実行します。

プロバイダの設定の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のContent ServerとRefineryの通信の構成に関する項を参照してください。

13.3.4.2 コンテンツ・サーバーでのInbound Refinery用のコンポーネントの有効化

変換タイプによっては、コンテンツ・サーバーでヘルパー・コンポーネントを有効にする必要があります。ドキュメント変換にInbound Refineryを使用するコンテンツ・サーバーのインスタンスでは、InboundRefinerySupportコンポーネントを常に有効にする必要があります。新しいコンテンツ・サーバーのインストールではデフォルトで有効になっています。

コンテンツ・サーバーでInbound Refineryコンポーネントを有効にする手順は次のとおりです。

1. 次のURLからコンテンツ・サーバーにログインします。

https://wcp.example.com/cs

2. 「管理」トレイまたはメニューから、「管理サーバー」→「コンポーネント・マネージャ」を選択します。

3. 「コンポーネント・マネージャ」ページで、「Inbound Refinery」を選択し、「Inbound Refinery」で有効にするコンポーネント(XMLConverterSupportなど)を選択したら、「更新」をクリックします。

4. 両方のコンテンツ・サーバーを再起動するために、WebLogic Server管理コンソールを使用してWebCenter Content管理対象サーバーを再起動します。

13.3.4.3 変換するファイル形式の選択

変換のためにInbound Refineryに送信するファイルをコンテンツ・サーバーに指定するには、ファイル形式を選択する必要があります。

変換するファイル形式を選択するには、次の手順を実行します。

1. 次のURLからコンテンツ・サーバーにログインします。

https://wcp.example.com/cs/

2. 「管理」トレイまたはメニューを開いて「リファイナリ管理」、「ファイル形式ウィザード」の順に選択し、「ファイル形式ウィザード」ページを開きます。

このページでは、どのファイル形式をコンテンツ・サーバーにチェックインした場合に、そのファイル形式をInbound Refineryに送信して変換を実施するかを指定します。

3. Microsoft Wordドキュメントのdoc、dot、docxおよびdotxなど、変換が必要なフォーマットを選択します。

4. 「更新」をクリックします。

また、構成マネージャでファイル形式を選択することもできます。構成マネージャでは、ウィザードでは示されないファイル形式など、さらにきめ細かく制御できます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のファイル・タイプの管理に関する項を参照してください。

13.4 Inbound Refinery管理対象サーバーの構成の検証

作成したInbound Refinery管理対象サーバーが正しく構成されているかどうかを確認するには、コンテンツ・サーバーにログインし、変換に有効と認識された拡張子を持つファイルが正しく変換されることを確認して、構成を検証します。

たとえば、変換するフォーマットとしてdocxを選択した場合は、拡張子が.docxのMicrosoft Word文書をPDFフォーマットに変換できます。

チェックインとチェックアウトの手順の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの使用』のドキュメントのアップロードおよびファイルのチェックアウトとダウンロードに関する項を参照してください。

変換プロセスの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のRefineryにジョブを送信するためのコンテンツ・サーバーの構成に関する項を参照してください。

14 Oracle SOA Suiteを含めるドメインの拡張

Oracle SOA Suiteソフトウェアを追加してエンタープライズ・デプロイメント・ドメインを拡張するには、特定のタスクを実行する必要があります。

- Oracle SOA Suiteの構成時に使用される変数
Oracle SOA Suiteを追加してドメインを拡張する際には、この項にリストされているディレクトリ変数を参照します。

- システム・クロックの同期
Oracle SOA Suiteを追加するためにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。これは、各クラスタ内のすべてのホストで同時にdateコマンドを実行することで行えます。

- エンタープライズ・デプロイメント用のソフトウェアのインストール
この項では、エンタープライズ・デプロイメント用のソフトウェアをインストールする手順について説明します。

- Oracle SOA Suiteデータベース・スキーマの作成
Oracle SOA Suiteドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

- Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張
Oracle SOA Suiteソフトウェアを含めて既存のエンタープライズ・デプロイメント・ドメインを拡張するために、次のタスクを実行する必要があります。

- トランザクション・リカバリのためのデフォルトの永続ストアの構成
Oracle WebLogic Serverでは、システムのクラッシュやネットワーク障害からの回復時にトランザクション・ログを使用します。

- ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
SOA Suite管理対象サーバーにドメイン構成を伝播するために次の手順を実行する必要があります。

- ドメイン解凍後のNodeManager構成の更新
ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。

- 既存の管理対象サーバーの再起動と検証
ドメインが拡張され、すべてのサーバーのMSERVER_HOMEディレクトリに解凍されたら、既存のコンポーネントの管理対象サーバーを再起動する必要があります。

- uploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

- WLS_SOA1管理対象サーバーの起動および検証
これでドメインの拡張、管理サーバーの起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle SOA Suite管理対象サーバーを起動できます。

- 管理対象サーバーWLS_SOA2の起動と検証
WLS_SOA1管理対象サーバーの正常な構成と起動を検証したら、WLS_SOA2管理対象サーバーを起動して検証できます。

- トランザクション・ログの場所と作成の検証
WLS_SOA1およびWLS_SOA2が起動して稼働したら、トランザクション・ログ・ディレクトリを確認し、トランザクション・ログが予期したように作成されたことを確認します。

- 拡張したドメインでのOracle HTTP Serverの構成
次の項では、パブリックURLおよび内部URLの両方のリクエストを、エンタープライズ・トポロジ内の正しいクラスタにルーティングするようにOracle HTTP Serverインスタンスを構成する方法について説明します。

- Oracle SOA Suiteの構成後手順
Oracle SOA Suiteをインストールして構成した後、次のような構成後タスクを検討します。

- Oracle SOA Suiteに対する自動サービス移行およびJDBC永続ストアの有効化
Oracle SOA Suiteが高可用性を実現するように構成するには、自動サービス移行でOracle SOA Suite管理対象サーバーを構成します。

上位トピック: 「エンタープライズ・ドメインの構成」

14.1 Oracle SOA Suiteの構成時に使用する変数

Oracle SOA Suiteを追加してドメインを拡張する際、この項にリストするディレクトリ変数を使用します。

いくつかのディレクトリ変数の値は、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されています。

- ORACLE_HOME

- ASERVER_HOME

- MSERVER_HOME

- APPLICATION_HOME

- DEPLOY_PLAN_HOME

- OHS_DOMAIN_HOME

- JAVA_HOME

- ORACLE_RUNTIME

さらに、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で定義されている次の仮想IP (VIP)アドレスを参照することになります。

- ADMINVHN

この章のアクションは、次のホスト・コンピュータで実行します。

- WCPHOST1

- WCPHOST2

- WEBHOST1

- WEBHOST2

- WCCHOST1

- WCCHOST2

14.2 システム・クロックの同期

Oracle SOA Suiteを追加するためにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。これは、各クラスタ内のすべてのホストで同時にdateコマンドを実行することで行えます。

また、そのために使用できるサードパーティおよびオープンソースのユーティリティもあります。

14.3 エンタープライズ・デプロイメント用のソフトウェアのインストール

この項では、エンタープライズ・デプロイメント用のソフトウェアをインストールする手順について説明します。

- WCCHOST1でのOracle SOA Suiteインストーラの起動

- インストール画面への移動

- インストールの検証

- 他のホスト・コンピュータへのOracle SOA Suiteのインストール

14.3.1 WCCHOST1でのOracle SOA Suiteインストーラの起動

インストール・プログラムを起動する手順は次のとおりです。

1. WCCHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.2.0_soa_generic.jar

これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

ソフトウェアをダウンロードして製品の実際のインストーラ・ファイル名を見つける方法の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。

14.3.2 インストール画面への移動

インストール・プログラムでは、次の表にリストされている順序で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面では、使用可能なパッチを探してMy Oracle Supportを自動的に検索するか、組織にすでにダウンロードしたパッチを探してローカル・ディレクトリを自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成用のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

- 「SOA Suite」を選択します

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のシステム環境の検証ロードマップに関する項に記載されているドキュメントのいずれかを参照してください。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

14.3.3 インストールの検証

インストールの完了後、次のタスクを正常に実行することでインストールを検証できます。

- インストール・ログ・ファイルの確認

- ディレクトリ構造のチェック

- Oracleホームの内容の表示

14.3.3.1 インストール・ログ・ファイルの確認

インストール・ログ・ファイルの内容を確認し、何も問題が発生していないことを確認します。ログ・ファイルとその場所の詳細は、『Oracle Universal Installerによるソフトウェアのインストール』のインストール・ログ・ファイルの理解に関する項を参照してください。

14.3.3.2 ディレクトリ構造のチェック

インストールの内容は、インストール中に選択したオプションによって異なります。

Oracle SOA Suiteを追加すると、次のディレクトリおよびサブディレクトリが追加されます。

/u01/oracle/products/fmw/soa

bam
bin
bpm
common
integration
jlib
plugins
readme.txt
reports
soa

インストール後のディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要ディレクトリに関する項を参照してください。

14.3.3.3 Oracleホームの内容の表示

Oracleホームの内容を、viewInventoryスクリプトを使用して表示することもできます。詳細は、Oracle Universal InstallerによるソフトウェアのインストールのOracleホームの内容の表示に関する項を参照してください。

14.3.4 他のホスト・コンピュータへのOracle SOA Suiteのインストール

WCCHOST2上の製品マウント・ポイントとORACLE_HOME用に個別の共有記憶域ボリュームまたはパーティションを構成している場合は、WCCHOST2で製品のインストールを実行する必要もあります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「WCCHOST1でのインフラストラクチャ・インストーラの起動」と「インフラストラクチャ・インストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。

注意:

以前のリリースでは、同一場所に配置されるOracle HTTP Serverインスタンスのセットが推奨エンタープライズ・トポロジに含まれていました。これらのリリースでは、インフラストラクチャをWeb層ホスト(WEBHOST1およびWEBHOST2)にインストールする要件がありました。ただし、このリリースでは、エンタープライズ・デプロイメント・トポロジは、Webサーバーがスタンドアロン・モードでインストールおよび構成されていると仮定するため、Webサーバーがアプリケーション層ドメインの一部とはみなされません。詳細は、「エンタープライズ・デプロイメント用のWeb層の構成」を参照してください

14.4 Oracle SOA Suiteデータベース・スキーマの作成

Oracle SOA Suiteドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

- リポジトリ作成ユーティリティ(RCU)の起動

- スキーマ作成のためのRCU画面のナビゲート

- トランザクション・リカバリ用のSOAスキーマの構成

14.4.1 リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。

2. 対象のシステムで、JAVA_HOME環境変数に、動作保証されたJDKの場所が設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

UNIXオペレーティング・システムの場合:

export JAVA_HOME=/u01/oracle/products/jdk

3. RCUを起動します。

UNIXオペレーティング・システムの場合:

./rcu

14.4.2 スキーマ作成のためのRCU画面のナビゲート

スキーマ作成に必要なタスクは、次のとおりです。

- タスク1「RCUの概要」

- タスク2「スキーマ作成の方法の選択」

- タスク3「データベース接続の詳細の指定」

- タスク4「カスタム接頭辞の指定とスキーマの選択」

- タスク5「スキーマのパスワードの指定」

- タスク6「カスタム変数の指定」

- タスク7「必須スキーマの表領域の検証」

- タスク8「スキーマ作成の実行」

- タスク9「スキーマの作成の検証」

タスク1   RCUの概要

「次へ」をクリックします。

タスク2   スキーマ作成の方法の選択

対象のデータベースに対するDBAアクティビティの実行に必要なパーミッションと権限が付与されている場合は、「システム・ロードおよび製品ロード」を選択します。この手順は、必要な権限が付与されていることを前提としています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。このオプションによってSQLスクリプトが生成され、必要なスキーマを作成するためにデータベース管理者が利用できます。『リポジトリ作成ユーティリティによるスキーマの作成』のシステム・ロードと製品ロードの理解に関する項を参照してください。

タスク3   データベース接続の詳細の指定

RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。

「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

「DBMS/サービス」詳細を入力します。

「スキーマ所有者」および「スキーマ・パスワード」詳細を入力します。

「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

タスク4   カスタム接頭辞の指定とスキーマの選択

「既存の接頭辞の選択」を選択し、初期ドメインを作成したときに使用した接頭辞を選択します。

スキーマのリストから「SOA Suite」スキーマを選択します。これにより、「SOAインフラストラクチャ」が自動的に選択されます。また、次の依存スキーマがInfrastructureとともにすでにインストールされて灰色表示されています。

- 共通インフラストラクチャ・サービス

- ユーザー・メッセージング・サービス

- メタデータ・サービス

- Weblogicサービス

- Oracle Platform Security Services

- 監査サービス

- 監査サービスへの追加

- 監査サービス・ビューア

カスタム接頭辞は、これらのスキーマを論理的にグループ化して、このドメイン内でのみ使用することを目的としています。複数のドメイン間でのスキーマの共有はサポートされていないため、ドメインごとに固有のスキーマのセットを作成する必要があります。

ヒント:

カスタム接頭辞の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のカスタム接頭辞の理解に関する項を参照してください。

マルチドメイン環境のスキーマを構成する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のスキーマの作成計画に関する項を参照してください。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6   カスタム変数の指定

SOAインフラストラクチャ・スキーマのカスタム変数を指定します。

エンタープライズ・デプロイメント・トポロジの場合、Database Profileのカスタム変数としてLARGEを入力し、Oracle Healthcareの使用を予定している場合は、Healthcare Integrationの変数としてYESを入力します。

Oracle Healthcareの使用を予定している場合は、Healthcare Integrationの変数としてYESを入力します。

詳細は、Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成のSOA Suiteスキーマに必要なカスタム変数についてを参照してください。

タスク7   必須スキーマの表領域の検証

「表領域のマップ」画面で情報を確認し、「次へ」をクリックして、デフォルト値を受け入れます。

確認ダイアログ・ボックスで「OK 」をクリックします。

タスク8   スキーマ作成の完了

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

タスク9   スキーマの作成の検証

スキーマが正常に作成されたことと、データベース接続詳細を確認するためには、SQL*Plusまたは別のユーティリティで、SOAINFRAスキーマ名および指定したパスワードを使用してデータベースに接続します。

例:

./sqlplus

SQL*Plus: Release 12.1.0.1.0 Production on Wed Aug 31 05:41:31 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Enter user-name: FMW1221_SOAINFRA
Enter password: soainfra_password

Connected to:
Oracle Database 11g Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

14.4.3 トランザクション・リカバリ用のSOAスキーマの構成

Oracle SOA Suiteスキーマを正常にインストールしたら、この項の手順に従ってトランザクション・リカバリのスキーマを構成します。

この手順では、WebLogic Serverが予期せずに使用不可になった後、進行中のトランザクションをリカバリする際に、Oracle WebLogic Serverトランザクション・マネージャでトランザクション状態の情報を問い合せて該当するコマンド(commitやrollbackなど)を発行できるように適切なデータベース権限を設定します。

これらの権限は、リポジトリ作成ユーティリティでスキーマを作成したときに定義したSOAINFRAスキーマの所有者に付与する必要があります。

トランザクション・リカバリ権限のSOAスキーマを構成する手順は次のとおりです。

1. sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例:

sqlplus "/ as sysdba"

2. 次のコマンドを入力します。

SQL> Grant select on sys.dba_pending_transactions to soa_schema_prefix_soainfra;

Grant succeeded.

SQL> Grant force any transaction to soa_schema_prefix_soainfra;

Grant succeeded.

SQL>

14.5 Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張

Oracle SOA Suiteソフトウェアを含めて既存のエンタープライズ・デプロイメント・ドメインを拡張するために、次のタスクを実行する必要があります。

- 構成ウィザードの起動

- Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

14.5.1 構成ウィザードの起動

構成ウィザードを起動する手順は次のとおりです。

1. WebLogic Serverコンソールで、このドメイン拡張によって変更されるすべての管理対象サーバーを停止します。影響を受けない管理対象サーバーは、オンラインのままにすることができます。

2. いずれかの管理対象サーバーを変更する場合は、管理対象サーバーのシャットダウンが完了していることを確認してください。

3. 管理対象サーバーがすべて安定した状態になったら、管理サーバーを停止します。

4. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

cd ORACLE_HOME/oracle_common/common/bin
./config.sh

14.5.2 Oracle SOA Suiteを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

次以降の項で説明する手順を実行して、静的クラスタで使用するトポロジのドメインを作成して構成します。

- 静的クラスタを含めるドメインの拡張

14.5.2.1 静的クラスタを含めるドメインの拡張

この項で説明する手順を実行して、静的クラスタで使用するトポロジのドメインを作成して構成します。

注意:

この項で説明する手順を使用し、静的クラスタを使用して既存のドメインを拡張することができます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「データベース構成タイプの指定」

- タスク4「JDBCコンポーネント・スキーマ情報の指定」

- タスク5「GridLink Oracle RACデータベース接続の詳細情報の指定」

- タスク6「JDBC接続のテスト」

- タスク7「キーストア」

- タスク8「詳細構成の選択」

- タスク9「管理対象サーバーの構成」

- タスク10「クラスタの構成」

- タスク11「サーバー・テンプレートの割当て」

- タスク12「動的サーバーの構成」

- タスク13「クラスタへの管理対象サーバーの割当て」

- タスク14「Coherenceクラスタの構成」

- タスク15「既存のマシンの検証」

- タスク16「マシンへのサーバーの割当て」

- タスク17「仮想ターゲットの構成」

- タスク18「パーティションの構成」

- タスク19「ファイル・ストアの構成」

- タスク20「構成の仕様の確認とドメインの構成」

- タスク21「ドメイン・ホームと管理サーバーURLのメモ」

- タスク22「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

- Oracle SOA Suite - 12.2.1.2.0 [soa]

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。

タスク3   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。

すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。操作に成功すると、「接続結果ログ」に次の出力が示されます。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解 に関する項を参照してください。

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください。

タスク4   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、表にあるSOAスキーマをすべて選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク5   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素

説明と推奨値

SCAN、ホスト名とポート

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドに、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

データベースがFANイベントを受信して処理できるように、「FANの有効化」チェック・ボックスが選択されていることを確認します。

タスク6   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

この画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテスト関する項を参照してください。

タスク7   キーストア

この画面を使用して、ドメインで使用されるキーストアの詳細を指定します。

標準的なエンタープライズ・デプロイメントの場合、デフォルト値をそのまま使用できます。

詳細は、『構成ウィザードによるWebLogicドメインの作成』のキーストアに関する項を参照してください。

タスク8   拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

- トポロジ
サーバー・テンプレート、管理対象サーバー、クラスタ、仮想ターゲットおよびCoherenceの設定の追加、削除または変更。

- ファイル・ストア

タスク9   管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストにOracle SOA Suite用の新しい管理対象サーバーが表示されます。このサーバーは、タスク2「構成テンプレートの選択」で選択したOracle SOA Suite構成テンプレートによって自動的に作成されました。

次のタスクを実行して、デフォルトのOracle SOA Suite管理対象サーバーを変更して2つ目のOracle SOA Suite管理対象サーバーを作成します。

1. デフォルトのOracle SOA Suite管理対象サーバーの名前をWLS_SOA1に変更します。

2. 「追加」をクリックして新しいOracle SOA Suite管理対象サーバーを作成し、それにWLS_SOA2という名前を付けます。

ヒント:

ここで推奨するサーバー名は、このドキュメント全体で使用します。別の名前を選択する場合は、必要に応じてそれらの名前に置き換えてください。

3. GUID-87AD8F24-E00A-48D4-AC30-56F0CB8CD838.htm#GUID-26CDA9CD-E110-431D-BE23-4AEEFC997B66__GUID-579F94E8-DCA0-486A-B006-5555CCB429F9の情報を使用して、Oracle SOA Suiteの管理対象サーバーごとに残りの列に入力します。

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

サーバー名

リスニング・アドレス

リスニング・ポート

SSLの有効化

SSLリスニング・ポート

サーバー・グループ

WLS_SOA1

WCCHOST1

8001

いいえ

無効

SOA-MGD-SVRS-ONLY

WLS_SOA2

WCCHOST2

8001

いいえ

無効

SOA-MGD-SVRS-ONLY

タスク10   クラスタの構成

このタスクでは、Oracle SOA Suiteソフトウェアのターゲットとすることができる管理対象サーバーのクラスタを作成します。

「クラスタ」画面を使用して、新しいクラスタを作成します。

1. 「追加」ボタンをクリックします。

2. 「クラスタ名」フィールドでSOA_Clusterを指定します。

3. 「動的サーバー・グループ」ドロップダウン・リストで、未指定を選択します。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。

タスク11   サーバー・テンプレートの割当て

「次へ」をクリックして続行します。

タスク12 動的サーバーの構成

静的クラスタとして残そうとするクラスタに対して、動的サーバーのすべてのオプションが無効になっていることを確認します。

1. この画面で、「動的クラスタ」、「計算済リスニング・ポート」、「計算済マシン名」の各チェック・ボックスが選択解除されていることを確認します。

2. 「サーバー・テンプレート」で「未指定」が選択されていることを確認します。

3. 「次へ」をクリックします。

タスク13   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、WLS_SOA1およびWLS_SOA2を新規クラスタSOA_Clusterに割り当てます。

1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではSOA_Cluster)を選択します。

2. 「サーバー」ペインで、次のいずれかの操作を実行して、WLS_SOA1をSOA_Clusterに割り当てます。

- WLS_SOA1管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。

- WLS_SOA1をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。

3. 同じ手順を繰り返して、WLS_SOA2をSOA_Clusterに割り当てます。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のサーバーのクラスタへの割当てに関する項を参照してください。

タスク14   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。

Coherenceライセンス情報については、Oracle Fusion Middlewareライセンス情報ユーザー・マニュアルのOracle Coherence製品に関する項を参照してください。

タスク15 既存のマシンの検証

「次へ」をクリックします。

タスク16   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle SOA Suite管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。

WLS_SOA1をWCCHOST1、WLS_SOA2をWCCHOST2に割り当てます。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のサーバーのマシンへの割当てに関する項を参照してください。

タスク17   仮想ターゲットの構成

「次へ」をクリックして次の画面に進みます。

タスク18   パーティションの構成

「次へ」をクリックして次の画面に進みます。

タスク19   ファイル・ストアの構成

「JMSファイル・ストア」画面で、UMSおよびBPMのファイル・ストアを含む各SOA永続ストアに次のディレクトリを割り当てます。

ORACLE_RUNTIME/domain_name/SOA_Cluster/jms

注意:
管理対象サーバーを起動する前にjmsフォルダを作成します。

この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。SOA_Clusterを、クラスタに割り当てた名前に置き換えます。

タスク20   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックして、ドメインの拡張を実行します。

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成のサマリーに関する項を参照してください。

タスク21   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

いずれの項目も後で必要になるため、メモしておいてください。ドメインの場所は管理サーバーの起動に使用するスクリプトへのアクセスに必要で、管理サーバーURLはWebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlへのアクセスに必要です。

「終了」をクリックして、構成ウィザードを閉じます。

タスク22   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

14.6 トランザクション・リカバリのためのデフォルトの永続ストアの構成

Oracle WebLogic Serverでは、システムのクラッシュやネットワーク障害からの回復時にトランザクション・ログを使用します。

各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。

Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。クラスタ内のすべての管理対象サーバーがこのディレクトリにアクセスできる必要があります。また、このディレクトリは、サーバーを再起動する前にも存在している必要があります。

お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。記憶域エラーが発生した場合に確実に保護するには、記憶域レベルで適切な複製およびバックアップ・メカニズムを設定しておくことが重要です。

この情報は、ファイルベースのトランザクション・ログに適用されます。トランザクション・ログに対して、データベース・ベースの永続ストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用」を参照してください。

- 静的クラスタでのトランザクション・リカバリ用のデフォルト永続ストアの構成

14.6.1 静的クラスタでのトランザクション・リカバリ用のデフォルト永続ストアの構成

静的クラスタ内の各管理対象サーバーにデフォルト永続ストアの場所を設定するには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインします。

ADMINVHN:7001/console

2. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

3. クラスタ内の管理対象サーバーごとに、次を実行します。

a. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。

b. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

c. 「構成」タブで、「サービス」タブをクリックします。

d. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
エンタープライズ・デプロイメントでは、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログにとって中心的な共有場所の役割を果たします。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

例:

ORACLE_RUNTIME/domain_name/cluster_name/tlogs

この例では、ORACLE_RUNTIMEを、ご使用の環境の変数値に置き換えます。domain_nameを、ドメインに割り当てた名前に置き換えます。cluster_nameを、先ほど作成したクラスタ名で置き換えます。

e. 「保存」をクリックします。

4. SOA_Cluster内のすべてのサーバーについて、手順3を実行します。

5. 「変更のアクティブ化」をクリックします。

注意:

構成手順の後半で、トランザクション・ログの場所と作成について検証します。

14.7 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

SOA Suite管理対象サーバーにドメイン構成を伝播するために次の手順を実行する必要があります。

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。SOA Suite管理対象サーバーにドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=/full_path/wcpdomaintemplateExtSOA.jar
-template_name=wcp_domain_template_extension_soa

この例では、次のようになります。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- full_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。ORACLE_HOME以外の共有ボリュームを選択するか、/tmp/に書き込み、そのファイルをサーバー間で手動でコピーすることをお薦めします。
テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。

SHARED_CONFIG_DIR/domains/template_filename.jar

- wcpdomaintemplateExtSOA.jarは、作成するJARファイルのサンプル名です。これには、Oracle HTTP Serverインスタンスの構成ファイルなどのドメイン構成ファイルが含まれます。

- wcp_domain_template_extension_soaは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

3. 次のunpackコマンドをWCCHOST1で実行して、前の手順で作成したテンプレートをMSERVER_HOMEディレクトリに伝播します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-template=/full_path/wcpdomaintemplateExtSOA.jar
-app_dir=APPLICATION_HOME
-overwrite_domain=true

この例では、次のようになります。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- wcpdomaintemplateExtSOA.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

- 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。
上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

- APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

4. パック済のJARファイルへのフルパスが他のサーバーで使用可能な共有ボリューム上にある場合は、この手順をスキップし、それ以外の場合は、次のコマンドをWCCHOST1で実行し、手順1で作成したテンプレート・パックをWCCHOST2、WCPHOST1およびWCPHOST2にコピーします。

scp /full_path/edgdomaintemplateExtSOA.jar oracle@WCCHOST2:/full_path/
scp /full_path/edgdomaintemplateExtSOA.jar oracle@WCPHOST1:/full_path/
scp /full_path/edgdomaintemplateExtSOA.jar oracle@WCPHOST2:/full_path/

5. 次のunpackコマンドを各リモート・ホストで実行して、前の手順でコピーしたドメイン・テンプレートをMSERVER_HOMEディレクトリにデプロイします。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-template=/full_path/wcpdomaintemplateExtSOA.jar
-app_dir=APPLICATION_HOME
-overwrite_domain=true

この例では、次のようになります。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- wcpdomaintemplateExtSOA.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

- 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。
上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

- APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

14.8 ドメイン解凍後のNodeManager構成の更新

ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。

注意:

- ListenAddressは通常、ASERVER_HOME nodemanagerと同じホストに常駐するMSERVER_HOME nodemanager上でリセットされます。このトポロジでは、WCCHOST1です。

- SOAサーバーとハードウェア・ロード・バランサ間のSSL通信を有効にする前のドメイン拡張では、CustomIdentityAliasに関して手順2から4は当てはまらないことがあります。

各ホストのMSERVER_HOME/nodemanager/nodemanager.propertiesファイルについて、次のことを実行します。

1. 正しいListenAddressパラメータ値を確認して、必要な場合は値を再設定します。

grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties

2. 次のコマンドの参照として、ドメイン構成ファイルから構成済アイデンティティ別名のリストを確認します。

grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq

3. 現在のCustomIdentityAliasパラメータ値を確認します。

grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties

4. 必要に応じて、CustomIdentityAliasパラメータ値を、現在のホストに適した正しい別名文字列に再設定します。

5. nodemanagerプロセスを再起動します。

kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

詳細は、「カスタム・キーストアを使用するためのノード・マネージャの構成」を参照してください。

14.9 既存の管理対象サーバーの再起動と検証

ドメインが拡張され、すべてのサーバーのMSERVER_HOMEディレクトリに解凍されたら、既存のコンポーネントの管理対象サーバーを再起動する必要があります。

ドメインが拡張され、すべてのサーバーのMSERVER_HOMEディレクトリに解凍されたので、既存のコンポーネントの管理対象サーバーを再起動します。

1. WebLogic Serverコンソールから、WebServices Manager Policy ManagerのWLS_WSMn管理対象サーバーを再起動します。

2. 別のブラウザ・ウィンドウから、URLを正常にロードすることで、WSM-PMアプリケーションが応答していることを確認します。

http://wcpinternal.example.com/wsm-pm/validator

3. 必要に応じてその他の既存の管理対象サーバーを起動します。他の製品機能は、この段階では不要です。

14.10 uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

この手順は、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。

管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

3. 「ロックして編集」をクリックします。

4. 使用するクラスタ・タイプに適したオブジェクトに移動して編集します。

a. 静的クラスタの場合、「サーバー」に移動し、編集する管理対象サーバーの名前をクリックします。

5. 編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。

a. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

b. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。

MSERVER_HOME/servers/server_or_template_name/stage

MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。静的クラスタを使用している場合、編集する管理対象サーバーの正しい名前で更新します。

c. 「アップロード・ディレクトリ名」を次の値に更新します。

ASERVER_HOME/servers/AdminServer/upload

ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

d. 「保存」をクリックします。

e. 「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。

6. 該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。

7. これらの変更の影響を受けるすべての管理対象サーバーを再起動します。

14.11 WLS_SOA1管理対象サーバーの起動および検証

これでドメインの拡張、管理サーバーの起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle SOA Suite管理対象サーバーを起動できます。

このプロセスには、次の各項で説明する3つのタスクが含まれます。

- WLS_SOA1管理対象サーバーの起動

- AdministratorsグループへのSOAAdminロールの追加

- SOAインフラストラクチャへのログインによる管理対象サーバーの検証

14.11.1 管理対象サーバーWLS_SOA1の起動

WLS_SOA1管理対象サーバーを起動する手順は次のとおりです。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。

4. WLS_SOA1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

注意:

SOAサーバーは、ポリシー・アクセス・サービスに依存して機能します。これは、SOAサーバーが起動する前に、ドメイン内のWSM-PM管理対象サーバーが稼働していてアクセス可能になっている必要があることを意味します。

5. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WLS_SOA1管理対象サーバーが稼働中であることを確認します。

14.11.2 AdministratorsグループへのSOAAdminロールの追加

WLS_SOA1管理対象サーバーのOracle SOA Suite構成を検証する前に、SOAAdmin管理ロールをエンタープライズ・デプロイメント管理グループ(WCPAdministrators)に追加します。

このタスクを実行するには、「エンタープライズ・デプロイメントの管理用のロールの構成」を参照してください。

14.11.3 SOAインフラストラクチャへのログインによる管理対象サーバーの検証

SOAAdminロールをSOA Administratorsグループに追加した後、次のようにWLS_SOA1管理対象サーバーのOracle SOA Suiteソフトウェアの構成を検証できます。

1. Webブラウザを使用して次のURLに移動します。

http://WCCHOST1:8001/soa-infra/

2. エンタープライズ・デプロイメント管理者ユーザー資格証明(weblogic_wcp)を使用してログインします。

次のようなタイトルのWebページが表示されます。

"Welcome to the Oracle SOA Platform on WebLogic"

14.12 管理対象サーバーWLS_SOA2の起動と検証

WLS_SOA1管理対象サーバーの正常な構成と起動を検証したら、WLS_SOA2管理対象サーバーを起動して検証できます。

WLS_SOA2管理対象サーバーを起動して検証するには、WLS_SOA2管理対象サーバーに対して「WLS_SOA1管理対象サーバーの起動および検証」の手順を使用します。

検証URLとしてWebブラウザに次のURLを入力し、エンタープライズ・デプロイメント管理者ユーザー資格証明(weblogic_soa)を使用してログインします。

http://WCCHOST2:8001/soa-infra/

14.13 トランザクション・ログの場所と作成の検証

WLS_SOA1およびWLS_SOA2が起動して稼働したら、トランザクション・ログ・ディレクトリを確認し、トランザクション・ログが予期したように作成されたことを確認します。

確認するには、「トランザクション・リカバリ用のデフォルト永続ストアの構成」で実行した手順に基づいて、次のコマンドを実行します。

ls -al ORACLE_RUNTIME/domain_name/cluster_name/tlogs

- _WLS_WLS_SOA1000000.DAT

- _WLS_WLS_SOA2000000.DAT

14.14 拡張したドメイン用のOracle HTTP Serverの構成

次の項では、パブリックURLおよび内部URLの両方のリクエストを、エンタープライズ・トポロジ内の正しクラスタにルーティングするようにOracle HTTP Serverインスタンスを構成する方法について説明します。

- Oracle WebCenter Portalエンタープライズ・デプロイメントにおけるSOAのためのOracle HTTP Serverの構成

- WebLogicプロキシ・プラグインの構成

- ロード・バランサを使用したOracle SOA Suite URLの検証

14.14.1 Oracle WebCenter Portalエンタープライズ・デプロイメントにおけるSOAのためのOracle HTTP Serverの構成

ワークフロー機能のためにSOAをWebCenter Portalと統合する場合、SOA Suiteリソースへの内部アクセスとエンドユーザー・アクセスの両方を構成する必要があります。

次の手順を使用して、リクエストをOracle SOA Suiteクラスタに正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成します。この手順では、「アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成」で説明されているOracle HTTP Server構成タスクが実行済であることを想定しています。

リクエストがOracle SOA Suiteクラスタに正しくルーティングされるように仮想ホスト構成ファイルを構成します。

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/

2. wcpinternal_vh.confファイルを編集し、次のディレクティブを<VirtualHost>タグ内に追加します。

注意:

/workflowのURLエントリは省略可能です。これは、Oracle ADFタスク・フォームと関連付けられたワークフロー・タスク用です。/workflowのURL自体は、フォームに応じた別の値とすることができます。

# soa-infra
<Location /soa-infra>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Worklist
<Location /integration>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Workflow
<Location /workflow>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# SOA composer application
<Location /soa/composer>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /frevvo>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
</VirtualHost>

3. wcp_vh.confファイルを編集し、次のディレクティブを<VirtualHost>タグ内に追加します。

注意:

/workflowのURLエントリは省略可能です。これは、Oracle ADFタスク・フォームと関連付けられたワークフロー・タスク用です。/workflowのURL自体は、フォームに応じた別の値とすることができます。

# soa-infra
<Location /soa-infra>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA composer application
<Location /soa/composer>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /frevvo>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

4. wcpinternal_vh.confファイルおよびwcp_vh.confファイルを、2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/ohs2/moduleconf/

5. wcpinternal_vh.confおよびwcp_vh.confを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。

6. 両方のOracle HTTP Serverを再起動します。

例14-1 wcpinternal_vh.confファイルの内容の例

注意:
次のサンプル構成ファイルの内容には、SOA SuiteおよびOracle WebServices Managerのリソースのみが含まれます。これまでの章で構成してきた他の製品のリソースは、ここには表示されません。

<VirtualHost WEBHOST1:7777>
ServerName http://wcpinternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# WSM-PM
<Location /wsm-pm>
WebLogicCluster WCPHOST1:7010,WCPHOST2:7010
WLSRequest ON
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

#soa-infra
<Location /soa-infra>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Worklist
<Location /integration>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Workflow
<Location /workflow>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# SOA composer application
<Location /soa/composer>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /frevvo>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>
</VirtualHost>

例14-2 wcp_vh.confファイルの内容の例

<VirtualHost WEBHOST1:7777>
ServerName http://wcp.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# WSM-PM
<Location /wsm-pm>
WebLogicCluster WCPHOST1:7010,WCPHOST2:7010
WLSRequest ON
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#soa-infra
<Location /soa-infra>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA composer application
<Location /soa/composer>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /frevvo>
WLSRequest ON
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

14.14.2 WebLogicプロキシ・プラグインの構成

リクエストがOracle HTTP Serverインスタンスを介して正しくルーティングされたことを検証するには、先ほど構成したクラスタに対して「WebLogicプラグインの有効化」パラメータを設定しておく必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「チェンジ・センター」で「ロックして編集」をクリックします。

4. 「クラスタ」をクリックします。

5. Oracle HTTP Serverからのリクエストのプロキシ先とするクラスタを選択します。

「構成: 一般」タブが表示されます。

6. 「詳細」セクションまでスクロール・ダウンして、開きます。

7. 「WebLogicプラグインの有効化」を「はい」に設定します。

8. 「保存」をクリックします。

9. 直近のドメイン拡張で複数のクラスタをデプロイした場合は、すべてのクラスタが一貫して更新されるまで、手順4から8を繰り返します。

10. 「チェンジ・センター」の「変更のアクティブ化」をクリックします。

11. この章で変更したすべてのクラスタのすべての管理対象サーバーを再起動します。

14.14.3 ロード・バランサを使用したOracle SOA Suite URLの検証

Oracle HTTP Server仮想ホストの構成を検証し、ハードウェア・ロード・バランサがOracle HTTP Serverインスタンスを経由してアプリケーション層にリクエストをルーティングできることを確認する手順は次のとおりです。

1. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

2. 次のURLにアクセスできることを確認します。

- https://wcp.example.com:443/soa-infra

- https://wcp.example.com:443/integration/worklistapp

- https://wcp.example.com:443/sdpmessaging/userprefs-ui

- https://wcp.example.com:443/soa/composer

14.15 Oracle SOA Suiteの構成後手順

Oracle SOA Suiteをインストールして構成した後、次のような構成後タスクを検討します。

- SOAサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

- SOAクラスタ内の同期/非同期相互作用に関する考慮事項

- 適切なタスク表示のためのワークフロー・フロント・エンド・アドレスの更新
デフォルトのTo-Doタスクとカスタム・タスクの詳細でフロントエンド・ロード・バランサを使用してタスク表示URLが作成されるように、適切なURLでOracle Workflowを構成する必要があります。

14.15.1 SOAサーバーとハードウェア・ロード・バランサ間のSSL通信の有効化

Oracle SOA Suiteを含めてドメインを拡張した後、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認する必要もあります。

これにより、SOAコンポジット・アプリケーションとWebサービスが、フロントエンドのセキュアURLとのコールバックやその他の通信を起動できるようになります。

詳細は、「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」を参照してください。

14.15.2 SOAクラスタ内の同期/非同期相互作用に関する考慮事項

SOAクラスタでは、次のシナリオはサポートされていません。

- mid-process receiveを持つ同期BPELプロセス

- 非同期サービスをコールする同期BPELプロセス。

- 同期プロセスからのコールバック。

14.15.3 適切なタスク表示のためのワークフロー・フロント・エンド・アドレスの更新

デフォルトのTo-Doタスクとカスタム・タスクの詳細でフロントエンド・ロード・バランサを使用してタスク表示URLが作成されるように、適切なURLでOracle Workflowを構成する必要があります。

このプロセスは、1度完了するとすべてのSOAサーバーで有効になります。

適切なURLを構成する手順は次のとおりです。

1. 「boot.propertiesファイルの更新およびシステムの再起動」で指定したユーザー名とパスワードを使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 「WebLogicドメイン」ドロップダウン・メニューから、「システムMBeanブラウザ」を選択します。

3. 「MBean」ナビゲーションで、「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: WLS_SOA1」→「WorkflowConfig」→「human-workflow」の順に開きます。

4. FusionAppsFrontendHostUrlフィールドに、次のとおり入力します。

*=https://wcp.example.com:443

5. 「適用」をクリックします。

14.16 Oracle SOA Suiteに対する自動サービス移行およびJDBC永続ストアの有効化

Oracle SOA Suiteが高可用性を実現するように構成するには、自動サービス移行でOracle SOA Suite管理対象サーバーを構成します。

自動サービス移行の有効化の詳細は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

可用性を高めるために、データベース内にトランザクション・ログ・ストアとJMSストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用」を参照してください。

15 Oracle WebCenter Portalを含めるドメインの拡張

次の各トピックでは、Oracle WebCenter Portalソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

- WebCenter Portalのためのドメイン拡張時に使用する変数

- エンタープライズ・デプロイメント用のソフトウェアのインストール
この項では、エンタープライズ・デプロイメント用のソフトウェアをインストールする手順を説明します。

- Oracle WebCenter Portalデータベース・スキーマの作成

- Oracle WebCenter Portalを含めるエンタープライズ・デプロイメント・ドメインの拡張

- ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

- ドメイン解凍後のsetDomainEnv.shへのカスタマイズのリストア
すでにASERVER_HOMEおよびMSERVER_HOME内のsetDomainEnv.shファイルにカスタマイズを加えていた場合、このようなカスタマイズはドメイン拡張後に再度行う必要があります。

- ドメイン解凍後のNodeManager構成の更新
ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。

- 既存の管理対象サーバーの再起動と検証

- uploadおよびstageディレクトリの絶対パスへの変更
ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

- WCPHOST1でのノード・マネージャの起動
WCPHOST1で拡張済のドメインを解凍したら、WCPHOST1の管理対象サーバー・ディレクトリからノード・マネージャを起動できます。

- WCPHOST2でのノード・マネージャの起動
ドメイン構成をWCPHOST2に伝播したら、MSERVER_HOMEドメイン・ディレクトリのノード・マネージャを起動できます。

- WC_Portal1、WC_Portlet1、WC_Collaboration1管理対象サーバーの起動と検証

- 分析の構成

- REST APIの構成
この項では、REST APIの構成手順について説明します。

- 拡張したドメインでのOracle HTTP Serverの構成
次の項では、パブリックURLおよび内部URLの両方のリクエストを、エンタープライズ・トポロジ内の正しいクラスタにルーティングするようにOracle HTTP Serverインスタンスを構成する方法について説明します。

- 外部サービス用のWebCenter Portalの構成

上位トピック: 「エンタープライズ・ドメインの構成」

15.1 WebCenter Portalのためのドメイン拡張時に使用する変数

この章のタスクを実行する際には、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されている次のディレクトリ変数を参照します。

- ORACLE_HOME

- ASERVER_HOME

- APPLICATION_HOME

- DEPLOY_HOME

- OHS_CONFIG_DIR

- JAVA_HOME

さらに、「エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスとホスト名を参照することになります。

- ADMINVHN

- WCPHOST1

- WCPHOST2

- DBHOST1

- DBHOST2

- Oracle RACデータベースのSCANアドレス(DB-SCAN.examle.com)

15.2 エンタープライズ・デプロイメント用のソフトウェアのインストール

この項では、エンタープライズ・デプロイメント用のソフトウェアをインストールする手順を説明します。

- WCCHOST1でのOracle WebCenter Portalインストーラの起動

- インストール画面への移動

- 他のホスト・コンピュータでのOracle WebCenter Portalのインストール

15.2.1 WCCHOST1でのOracle WebCenter Portalインストーラの起動

インストール・プログラムを起動する手順は次のとおりです。

1. WCCHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.2.0_wcportal_generic.jar

これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

ソフトウェアをダウンロードして製品の実際のインストーラ・ファイル名を見つける方法の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。

15.2.2 インストール画面への移動

インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索するか、組織のためにすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストール場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成用のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

「WebCenter Portal」を選択して「次へ」をクリックします。

注意:

- WebCenter Portalワークリストの統合では、SOA Suiteによって提供されるBPELサービスが同じWeb層、SSOおよびアイデンティティ・ストアを共有する必要があります。

- このエンタープライズ・デプロイメント・ガイドでは、SOA Suiteは同じWebLogic Serverドメインにインストールおよび構成され、Web層、SSOおよびディレクトリ構成に組み込まれます。

- SOA Suiteのインストール先のORACLE_HOMEが同じであろうと別であろうと、WebCenter Portal SOAコンポジット・オプションが別のインストールとして必要です。そのインストールの詳細は、「Oracle WebCenter Portal SOAコンポジットのインストール」を参照してください。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、次のいずれかのドキュメントのOracle Fusion Middleware Infrastructureのインストール計画のシステム環境の検証ロードマップに関する項を参照してください。

セキュリティ更新

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所持していないときに、この手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、その選択を後続のダイアログ・ボックスで確認します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

15.2.3 他のホスト・コンピュータでのOracle WebCenter Portalのインストール

EDG共有記憶域の推奨事項に従った場合、製品インストール用の別の共有記憶域ボリュームがWCPHOST2上にあり、WCPHOST2上にソフトウェアをインストールする必要もあります。詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

15.3 Oracle WebCenter Portalデータベース・スキーマの作成

Oracle WebCenter Portalドメインを構成する前に、このリリースのOracle Fusion Middlewareで使用する動作保証されたデータベースに必要なスキーマをインストールする必要があります。

次の各トピックでは、必要なスキーマのインストール方法について説明します。

- リポジトリ作成ユーティリティ(RCU)の起動

- スキーマ作成のためのRCU画面のナビゲート

15.3.1 リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

1. 対象のシステムで、ORACLE_HOME/oracle_common/binディレクトリに移動します。

2. 対象のシステムで、JAVA_HOME環境変数に、動作保証されたJDKの場所が設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

UNIXオペレーティング・システムの場合:

export JAVA_HOME=/u01/oracle/products/jdk

3. RCUを起動します。

UNIXオペレーティング・システムの場合:

./rcu

15.3.2 スキーマ作成のためのRCU画面のナビゲート

スキーマ作成に必要なタスクは、次のとおりです。

タスク1   RCUの概要

「次へ」をクリックします。

タスク2   スキーマ作成の方法の選択

対象のデータベースに対するDBAアクティビティの実行に必要なパーミッションと権限が付与されている場合は、「システム・ロードおよび製品ロード」を選択します。この手順は、必要な権限が付与されていることを前提としています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。これによってSQLスクリプトが生成され、これをデータベース管理者が利用できます。リポジトリ作成ユーティリティを使用したスキーマの作成のシステム・ロードおよび製品ロードの理解に関する項を参照してください。

タスク3   データベース接続の詳細の指定

RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。

「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

「DBMS/サービス」詳細を入力します。

「スキーマ所有者」および「スキーマ・パスワード」詳細を入力します。

「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

タスク4   カスタム接頭辞の指定とスキーマの選択

「既存の接頭辞の選択」を選択し、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で初期ドメインを作成したときに使用した接頭辞を選択します。

スキーマのリストから「WebCenter Portal」を選択します。これにより、必要なWebCenter Portalスキーマが自動的に選択されます。また、次の依存スキーマがインフラストラクチャとともにすでにインストールされており、グレー表示されます。

- Metadata Services

- 監査サービス

- 監査サービス・アペンド

- 監査サービス・ビューア

- Oracle Platform Security Services

- ユーザー・メッセージング・サービス

カスタム接頭辞は、これらのスキーマを論理的にグループ化して、このドメイン内でのみ使用することを目的としています。複数のドメイン間でのスキーマの共有はサポートされていないため、ドメインごとに固有のスキーマのセットを作成する必要があります。

ヒント:

カスタム接頭辞の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のカスタム接頭辞の理解に関する項を参照してください。

マルチドメイン環境でスキーマを編成する方法の詳細は、リポジトリ作成ユーティリティを使用したスキーマの作成のスキーマ作成の計画に関する項を参照してください。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。

ヒント:

この画面で設定するパスワードは、メモしておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6   カスタム変数の指定

エンタープライズ・デプロイメントの場合は、分析データをパーティション化できるように"Y"と入力することをお薦めします。

この機能は、月ごとに分析データをパーティション化します。パーティション化された環境でデータをパージするには、単に不要となった月ベースのパーティションを削除することをお薦めします。

分析データのパーティション化の詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle WebCenter Portalの分析データのパーティション化に関する項を参照してください。

タスク7   必須スキーマの表領域の検証

「表領域のマップ」画面で情報を確認し、「次へ」をクリックして、デフォルト値を受け入れます。

確認ダイアログ・ボックスで「OK」をクリックします。

タスク8   スキーマ作成の完了

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

タスク9   スキーマの作成の検証

スキーマが正常に作成されたことと、データベース接続詳細を確認するためには、SQL*Plusまたは別のユーティリティで、WCPINFRAスキーマ名および指定したパスワードを使用してデータベースに接続します。

次に例を示します。

./sqlplus

SQL*Plus: Release 11.2.0.4.0 Production on Fri Nov 1 08:44:18 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Enter user-name: FMW1221_WEBCENTER
Enter password: wcpinfra_password

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

15.4 Oracle WebCenter Portalを含めるエンタープライズ・デプロイメント・ドメインの拡張

この項では、Oracle WebCenter Portalソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張する手順を説明します。

ドメインの拡張には、次の操作が含まれます。

- 構成ウィザードの起動

- WebCenter Portalを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

15.4.1 構成ウィザードの起動

構成ウィザードを起動する手順は次のとおりです。

1. WebLogic Serverコンソールで、このドメイン拡張によって変更されるすべての管理対象サーバーを停止します。影響を受けない管理対象サーバーは、オンラインのままにすることができます。

2. 変更するすべての管理対象サーバーについて、管理対象サーバーの停止が完了していることを確認します。

3. すべての管理対象サーバーが安定した状態になったら、管理サーバーを停止します。

4. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

cd ORACLE_HOME/oracle_common/common/bin
./config.sh

15.4.2 WebCenter Portalを含めるドメイン拡張を行うための構成ウィザード画面のナビゲート

次以降の項で説明する手順を実行して、静的クラスタで使用するトポロジのドメインを作成して構成します。

- 静的クラスタを含めるドメインの拡張

15.4.2.1 静的クラスタを含めるドメインの拡張

この項に示す手順に従って、静的クラスタを含めてトポロジのドメインを作成および構成します。

注意:

この項で説明する手順と同じ手順を使用して、静的クラスタを含めて既存のドメインを拡張できます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

- タスク1「ドメイン・タイプとドメイン・ホームの場所の選択」

- タスク2「構成テンプレートの選択」

- タスク3「カスタム・データ・ソース用のGridLink Oracle RACデータベース接続の詳細情報の指定」

- タスク4「カスタム・データ・ソース用のJDBC接続のテスト」

- タスク5「データベース構成タイプの指定」

- タスク6「JDBCコンポーネント・スキーマ情報の指定」

- タスク7「GridLink Oracle RACデータベース接続の詳細情報の指定」

- タスク8「JDBC接続のテスト」

- タスク9「詳細構成の選択」

- タスク10「管理対象サーバーの構成」

- タスク11「クラスタの構成」

- タスク12「サーバー・テンプレートの割当て」

- タスク13「動的サーバーの構成」

- タスク14「クラスタへの管理対象サーバーの割当て」

- タスク15「Coherenceクラスタの構成」

- タスク16「既存のマシンの検証」

- タスク17「マシンへのサーバーの割当て」

- タスク18「仮想ターゲットの構成」

- タスク19「パーティションの構成」

- タスク20「デプロイメント・ターゲット指定」

- タスク21「サービス・ターゲット指定」

- タスク22「構成仕様の確認およびドメインの構成」

- タスク23「ドメイン・ホームと管理サーバーのURLの書込み」

- タスク24「管理サーバーの起動」

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

- Oracle WebCenter Portal – 12.2.1 [wcportal]

- Oracle WebCenter Pagelet Producer – 12.2.1 [wcportal]

- Oracle WebCenter Portlet Producers - 12.2.1 [wcportal]

- Oracle WebCenter Discussion Server - 12.2.1 [wcportal]

- Oracle WebCenter Analytics Collector - 12.2.1 [wcportal]

また、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されています。

- Oracle Enterprise Manager - 12.2.1.0 [em]

- Oracle WSM Policy Manager - 12.2.1.0 [oracle_common]

- Oracle JRF - 12.2.1.0 [oracle_common]

- WebLogic Coherenceクラスタの拡張 - 12.2.1.0 [wlserver]

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「テンプレート」に関する項を参照してください。

Task 3   カスタム・データ・ソース用のGridLink Oracle RACデータベース接続の詳細情報の指定

構成ウィザード以外でドメインにデータ・ソースが追加されている場合、構成ウィザードでは追加のタスクが必要です。このタスクと次のタスクは、「Oracle SOA Suiteを含めるドメインの拡張」の最後で「リース用のGridLinkデータ・ソースの作成」と「エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用」が完了している場合に表示されます。

次のデータ・ソース用のGridLinkデータ・ソース構成の詳細情報を確認します。

- リース

- TLOG

- JMS

注意:
これらのデータ・ソースの名前は、実行時にカスタマイズされていて、この例と一致しないことがあります。

これらのデータ・ソースの値が完全には表示されない場合、タスク6「JDBCコンポーネント・スキーマ情報の指定」で詳細を確認してください。

Task 4   カスタム・データ・ソース用のJDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードによるWebLogicドメインの作成のテスト・コンポーネント・スキーマに関する項を参照してください

タスク5   データベース構成タイプの指定

「データベース構成タイプ」画面で、「RCUデータ」を選択します。

Infrastructureドメインに必要なFusion Middlewareスキーマを参照するためのドメインをすでに構成済であるため、すべてのフィールドが事前移入されています。

すべてのフィールドにおける資格証明が、Oracle Fusion Middleware Infrastructureの構成中に指定したものと同じであることを確認します。

データベース接続情報の確認が完了した後で、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示しています。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解 に関する項を参照してください。

この画面に示されるその他のオプションの詳細は、構成ウィザードによるWebLogicドメインの作成のデータソースのデフォルトを参照してください。

タスク6   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面で、表にあるWebCenter Portalスキーマをすべて選択します。

スキーマを選択すると、ページ上のフィールドがアクティブ化され、データベース接続フィールドに自動的に値が移入されます。

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク7   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

表15-1 RACデータベースおよびコンポーネント・スキーマに接続するための情報

要素

説明と推奨値

「SCAN」、「ホスト名」および「ポート」

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

「FANの有効化」チェック・ボックスを選択して、FANイベントを受信および処理できるようにします。

タスク8   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードによるWebLogicドメインの作成のテスト・コンポーネント・スキーマに関する項を参照してください

タスク9   拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

- トポロジ

- デプロイメントとサービス

タスク10   管理対象サーバーの構成

「管理対象サーバー」画面で、Oracle WebCenter Portal、Oracle WebCenter PortletおよびOracle WebCenter Collaboration用の新しい管理対象サーバーが以前に作成された他の管理対象サーバーとともにサーバーのリストに表示されます。これらのサーバーは、構成ウィザード・セッションで前に選択したOracle WebCenter Portal構成テンプレートによって自動的に作成されます。

次のタスクを実行して、デフォルトの管理対象サーバーを変更し、サーバー・タイプごとに2つ目の管理対象サーバーを作成します。

1. WC_Portalを選択して、名前をWC_Portal1に変更します。

2. 「クローン」を選択して別の管理対象サーバーを作成します。新しいサーバーの名前をWC_Portal2に変更します。

3. 前述の2つの手順を繰り返し、編集してWC_Portlet1、WC_Portlet2、WC_Collaboration1およびWC_Collaboration2を作成します。

ヒント:

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

表15-2 新しい管理対象サーバーのプロパティ

サーバー名

リスニング・アドレス

リスニング・ポート

SSLの有効化

SSLリスニング・ポート

サーバー・グループ

WC_Portal1

WCPHOST1

9001

しない

無効

WebCenter Portal管理対象サーバー

WebCenter Portal分析管理対象サーバー

WC_Portal2

WCPHOST2

9001

しない

無効

WebCenter Portal管理対象サーバー

WebCenter Portal分析管理対象サーバー

WC_Portlet1

WCPHOST1

9002

しない

無効

WebCenter Portalページレット・プロデューサ管理対象サーバー

WebCenter Portalポートレット・プロデューサ管理対象サーバー

WC_Portlet2

WCPHOST2

9002

しない

無効

WebCenter Portalページレット・プロデューサ管理対象サーバー

WebCenter Portalポートレット・プロデューサ管理対象サーバー

WC_Collaboration1

WCPHOST1

9003

しない

無効

WebCenter Portalディスカッション管理対象サーバー

WC_Collaboration2

WCPHOST2

9003

しない

無効

WebCenter Portalディスカッション管理対象サーバー

タスク11   クラスタの構成

「クラスタの構成」画面で、新しいクラスタを3つ追加します。

- Portal_Cluster

- Portlet_Cluster

- Collab_Cluster

3つのクラスタ全部について、「クラスタ・アドレス」、「フロントエンド・ホスト」および「ポート」をデフォルト値のままにします。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストかマルチキャストかを選択する際の考慮事項に関する項を参照してください。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「クラスタ」に関する項を参照してください。

タスク12   サーバー・テンプレートの割当て

「次へ」をクリックして次の画面に進みます。

タスク13   動的サーバーの構成

静的なクラスタとして維持するクラスタに対して、すべての動的サーバー・オプションが無効になっていることを確認します。

1. この画面の「動的クラスタ」、「計算済リスニング・ポート」および「計算済マシン名」チェック・ボックスの選択が解除されていることを確認します。

2. 「サーバー・テンプレート」で「未指定」が選択されていることを確認します。

3. 「次へ」をクリックします。

タスク14   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、管理対象サーバーをそれぞれのクラスタに割り当てます。

1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではPortal_Cluster)を選択します。

2. 「サーバー」ペインで、次のいずれかを実行して、WC_Portal1をPortal_Clusterに割り当てます。

- WC_Portal1管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。

- WC_Portal1をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。

3. 同じ手順を繰り返して、WC_Portal2をPortal_Clusterに割り当てます。

4. 手順1-3を繰り返して、WC_Portlet1およびWC_Portlet2をPortlet_Clusterに割り当てます。

5. 手順1-3を繰り返して、WC_Collaboration1およびWC_Collaboration2をCollaboration_Clusterに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

タスク15   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期Infrastructureドメインの作成中に定義されているため、9991のままにします。

注意:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle Coherence製品に関する項を参照してください。

タスク16 既存のマシンの検証

「Unixマシン」タブで、初期インフラストラクチャ・ドメインの作成時に作成したマシンの名前を確認します。

「次へ」をクリックします。

タスク17   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、作成したばかりの管理対象サーバーをドメイン内の対応するマシンに割り当てます。

WC_Portal1、WC_Portlet1、WC_Collaboration1をWCPHOST1に割り当てます。

WC_Portal2、WC_Portlet2、WC_Collaboration2をWCPHOST2に割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

タスク18   仮想ターゲットの構成

「次へ」をクリックして次の画面に進みます。

タスク19   パーティションの構成

「次へ」をクリックして次の画面に進みます。

タスク20   デプロイメント・ターゲット指定

別のクラスタにデプロイされたOracle Web Services Manager Policy Managerでは、ポータル、コラボレーションおよびポートレットのクラスタに対するWSM-PMアプリケーションのデフォルトのターゲット指定を削除する必要があります。

「ターゲット」パネルでPortal_Cluster、Collaboration_ClusterおよびPortlet_Clusterのそれぞれについて、次のようにします。

「アプリケーション」フォルダ内のwsm-pmアプリケーション・エントリを選択し、左矢印ボタンをクリックしてターゲット・リストから削除します。

タスク21   サービス・ターゲット指定

別のクラスタにデプロイされたOracle Web Services Manager Policy Managerでは、ポータル、コラボレーションおよびポートレットのクラスタに対するWSM-PMサービス・リソースのデフォルトのターゲット指定を削除できます。

「ターゲット」パネルでPortal_Cluster、Collaboration_ClusterおよびPortlet_Clusterのそれぞれについて、次のようにします。

次の2つのリソースをターゲット・リストから選択して削除します。

- mds-owsm

- WSM起動クラス

タスク22   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックして、ドメインの拡張を実行します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク23   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、ノード・マネージャと管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク24   管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

15.5 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

Oracle WebCenter Portalインスタンスを含めることでドメインを拡張し、WCPHOST1上の管理サーバーを起動したら、そのドメイン変更をドメイン・ディレクトリとマシンに伝播する必要があります。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=/full_path/wcpdomaintemplateExtWCP.jar
-template_name=wcpdomain_templateExtWCP

この例では、次のとおりです。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- full_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。ORACLE_HOME以外の共有ボリュームを選択するか、/tmp/に書き込み、そのファイルをサーバー間で手動でコピーすることをお薦めします。
テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。

SHARED_CONFIG_DIR/domains/template_filename.jar

- wcpdomaintemplateExtWCP.jarは、作成するJARファイルのサンプル名です。これには、Oracle HTTP Serverインスタンスの構成ファイルなどのドメイン構成ファイルが含まれます。

- wcpdomain_templateExtWCPは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

3. 次のunpackコマンドをWCCHOST1で実行して、前の手順で作成したテンプレートをMSERVER_HOMEディレクトリに伝播します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-template=/full_path/wcpdomaintemplateExtWCP.jar
-app_dir=APPLICATION_HOME
-overwrite_domain=true

この例では、次のとおりです。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- wcpdomaintemplateExtWCP.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

- 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。
上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

- APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

4. パック済のJARファイルへのフルパスが他のサーバーで使用可能な共有ボリューム上にある場合は、この手順をスキップし、それ以外の場合は、次のコマンドをWCCHOST1で実行し、手順1で作成したテンプレート・パックをWCCHOST2、WCPHOST1およびWCPHOST2にコピーします。

scp /full_path/wcpdomaintemplateExtWCP.jar oracle@WCCHOST2:/full_path/
scp /full_path/wcpdomaintemplateExtWCP.jar oracle@WCPHOST1:/full_path/
scp /full_path/wcpdomaintemplateExtWCP.jar oracle@WCPHOST2:/full_path/

5. 次のunpackコマンドをWCCHOST2、WCPHOST1およびWCPHOST2で実行して、前の手順でコピーしたドメイン・テンプレートをローカルMSERVER_HOMEドメイン・ディレクトリにデプロイします。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-template=/full_path/wcpdomaintemplateExtWCP.jar
-app_dir=APPLICATION_HOME
-overwrite_domain=true

この例では、次のとおりです。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- wcpdomaintemplateExtWCP.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

- 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。
上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

- APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

15.6 ドメイン解凍後のsetDomainEnv.shへのカスタマイズのリストア

すでにASERVER_HOMEおよびMSERVER_HOME内のsetDomainEnv.shファイルにカスタマイズを加えていた場合、このようなカスタマイズはドメイン拡張後に再度行う必要があります。

NodeManagerまたはWebLogic Serverインスタンスの起動前に、カスタマイズがすべてリストアされていることを確認します。
WCPHOST1の場合:

1. ASERVER_HOME/bin/setDomainEnv.shを確認して更新します。

2. MSERVER_HOME/bin/setDomainEnv.shを確認して更新します。

3. MSERVER_HOME/bin/setDomainEnv.shを他のホスト(WCPHOST2、WCCHOST1、WCCHOST2など)にコピーします。

注意:
ASERVER_HOMEおよびMSERVER_HOMEのsetDomainEnv.sh構成ファイルに格納されているパラメータ値には、固有差があります。同じファイルを両方の場所にコピーすることはできないため、別々に編集する必要があります。MSERVER_HOME/bin/setDomainEnv.shは、環境全体で変らずコピーできます。

15.7 ドメイン解凍後のNodeManager構成の更新

ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。

注意:

- ListenAddressは通常、ASERVER_HOME nodemanagerと同じホストに常駐するMSERVER_HOME nodemanager上でリセットされます。このトポロジでは、WCCHOST1です。

- SOAサーバーとハードウェア・ロード・バランサ間のSSL通信を有効にする前のドメイン拡張では、CustomIdentityAliasに関して手順2から4は当てはまらないことがあります。

各ホストのMSERVER_HOME/nodemanager/nodemanager.propertiesファイルについて、次のことを実行します。

1. 正しいListenAddressパラメータ値を確認して、必要な場合は値を再設定します。

grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties

2. 次のコマンドの参照として、ドメイン構成ファイルから構成済アイデンティティ別名のリストを確認します。

grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq

3. 現在のCustomIdentityAliasパラメータ値を確認します。

grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties

4. 必要に応じて、CustomIdentityAliasパラメータ値を、現在のホストに適した正しい別名文字列に再設定します。

5. nodemanagerプロセスを再起動します。

kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

詳細は、「カスタム・キーストアを使用するためのノード・マネージャの構成」を参照してください。

15.8 既存の管理対象サーバーの再起動と検証

ドメインが拡張され、すべてのサーバーのMSERVER_HOMEディレクトリに解凍されたので、既存のコンポーネントの管理対象サーバーを再起動します。

1. WebLogic Serverコンソールから、WebServices Manager Policy ManagerのWLS_WSMn管理対象サーバーを再起動します。

2. 別のブラウザ・ウィンドウから、URLを正常にロードすることで、WSM-PMアプリケーションが応答していることを確認します。

http://wcpinternal.example.com/wsm-pm/validator

3. 続行する前に、その他すべての既存の管理対象サーバーを再起動します。これは、アプリケーションの停止を回避するために必要に応じてローリング方式で実行できます。

15.9 uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

この手順は、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。

管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

3. 「ロックして編集」をクリックします。

4. 使用するクラスタ・タイプに適したオブジェクトに移動して編集します。

a. 静的クラスタの場合、「サーバー」に移動し、編集する管理対象サーバーの名前をクリックします。

5. 編集する新しい管理対象サーバーまたはサーバー・テンプレートごとに、次の手順を実行します。

a. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

b. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。

MSERVER_HOME/servers/server_or_template_name/stage

MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。静的クラスタを使用している場合、編集する管理対象サーバーの正しい名前で更新します。

c. 「アップロード・ディレクトリ名」を次の値に更新します。

ASERVER_HOME/servers/AdminServer/upload

ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

d. 「保存」をクリックします。

e. 「サーバーのサマリー」または「サーバー・テンプレートのサマリー」画面(該当する方)に戻ります。

6. 該当するすべてのオブジェクトを変更したら、「変更のアクティブ化」をクリックします。

7. これらの変更の影響を受けるすべての管理対象サーバーを再起動します。

15.10 WCPHOST1でのノード・マネージャの起動

WCPHOST1で拡張済のドメインを解凍したら、WCPHOST1の管理対象サーバー・ディレクトリからノード・マネージャを起動できます。

1. WCPHOST1上の次のディレクトリに移動します。
MSERVER_HOME/bin

2. 次のコマンドを使用してノード・マネージャを起動します。

nohup ./startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

15.11 WCPHOST2でのノード・マネージャの起動

ドメイン構成をWCPHOST2に伝播したら、MSERVER_HOMEドメイン・ディレクトリのノード・マネージャを起動できます。

1. WCPHOST2にまだログインしていない場合は、ログインします。

2. ディレクトリを次の場所に変更します。

MSERVER_HOME/bin

3. 次のコマンドを使用してWCPHOST2でノード・マネージャを起動します。

nohup ./startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

ノード・マネージャの追加の構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

15.12 WC_Portal1、WC_Portlet1、WC_Collaboration1管理対象サーバーの起動と検証

これでドメインの拡張、管理サーバーの再起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle WebCenter Portalサーバーを起動できます。

このプロセスは、次の3つのタスクで構成されます。

- WCPHOST1での管理対象サーバーの起動

- WCPHOST1でのWebCenter Portalの検証

- ポータル管理者グループへのWCPAdminロールの追加

- WCPHOST2での管理対象サーバーの起動と検証

15.12.1 WCPHOST1での管理対象サーバーの起動

WC_Portal1管理対象サーバーを起動する手順は次のとおりです。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

2. 管理サーバー資格証明を使用してFusion Middleware Controlにログインします。

3. 「ターゲット・ナビゲーション」ペインで、ドメインを開き、ドメイン内の管理対象サーバーを表示します。

4. WC_Portal1管理対象サーバーのみを選択し、Oracle WebLogic Serverツールバーで「起動」をクリックします。

注意:

WebCenter Portalサーバーは、ポリシー・アクセス・サービスに依存して機能します。これは、WebCenter Portalサーバーの起動前にドメイン内のWSM-PM管理対象サーバーが起動し、稼働していて、アクセスできる必要があることを意味します。

5. 起動操作が完了したら、「ドメイン」ホーム・ページに移動し、WC_Portal1管理対象サーバーが起動し、稼働していることを確認します。

6. 前述の手順を繰り返して、WCPHOST1でWC_Portlet1およびWC_Collaboration1管理対象サーバーを起動します。

15.12.2 WCPHOST1でのWebCenter Portalの検証

WCPHOST1でポータル、ポートレットおよびコラボレーションの管理対象サーバーを起動したら、次のアプリケーションURLを使用してWebアプリケーションが応答することを検証します。

- http://WCPHOST1:9001/webcenter

- http://WCPHOST1:9001/webcenterhelp

- http://WCPHOST1:9001/rss

- http://WCPHOST1:9001/rest/api/resourceIndex

- http://WCPHOST1:9002/pagelets/welcome

- http://WCPHOST1:9002/portalTools

- http://WCPHOST1:9002/wsrp-tools/info

- http://WCPHOST1:9003/owc_discussions

注意:
必要に応じて、weblogic_wcpとして認証します。

15.12.3 ポータル管理者グループへのWCPAdminロールの追加

WC_Portal1管理対象サーバーでOracle WebCenter Portalの構成を検証する前に、WebCenter Portal管理者ロールをWCPAdministrators LDAPグループに付与します。

このタスクを実行するには、「Oracle WebCenter Portal製品の管理用のロールの構成」を参照してください。

- WLSTを使用したWebCenter Portal管理者ロールの付与

- Fusion Middleware Controlを使用したWebCenter Portal管理者ロールの付与
この項では、WebCenter Portalの管理者ロールをデフォルトのweblogicアカウント以外のユーザー・アカウントに付与する方法を説明します。

- WLSTを使用したWebCenter Discussions管理者ロールの付与

15.12.3.1 WLSTを使用したWebCenter Portal管理者ロールの付与

WLSTを使用してWebCenter Portal管理者ロールを付与する手順は次のとおりです。

1. LDAPストアでWCPAdministratorsという名前のグループを作成します。

このグループは、WebCenter Portalで管理者ロールに割り当てられます。

ユーザーの作成方法の詳細は、「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」および「管理グループへの新しい管理ユーザーの追加」を参照してください。

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のWCPAdministratorsグループにWebCenter Portal管理者アプリケーション・ロールを付与します。

grantAppRole(appStripe="webcenter", appRoleName="s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator", principalClass="weblogic.security.principal.WLSGroupImpl", principalName="WCPAdministrators")

WCPAdministratorsは、前に作成したポータル管理グループの名前です。

5. WC_Portal1管理対象サーバーを再起動します。

shutdown('WC_Portal1', block='true', force='true')
start('WC_Portal1', block='true')

6. 新しいアカウントをテストするには、新しいアカウント名を使用してWebCenter Portalにログインします。

ブラウザでhttp://WCPHOST1:9001/webcenterを使用して、WebCenter Portalを開きます。ログイン後、「管理」リンクが表示されて、すべての管理操作を実行できるようになります。

15.12.3.2 Fusion Middleware Controlを使用したWebCenter Portal管理者ロールの付与

この項では、デフォルトのweblogicアカウント以外のユーザー・アカウントにWebCenter PortalのAdministratorロールを付与する方法を説明します。

Fusion Middleware Controlを使用してWebCenter Portalの管理者ロールを付与する手順は、次のとおりです。

1. Oracle WebLogic Server管理サーバーの資格証明を使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

これらは、最初にドメインを構成し、Oracle WebLogic Server管理ユーザー名(通常weblogic_wcp)とパスワードを作成したときに作成した資格証明です。

2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。

3. WebCenter Portalの管理者ロールを検索します。

a. 検索フォームの「ロール名」オプションを「次で始まる」から「が次を含む」に変更します。

b. 「が次を含む」オプションの横のテキスト・ボックスに、#Administratorと入力して「アプリケーション・ロールの検索」アイコンをクリックします。.

4. 戻された行をクリックして管理者ロールを選択します。

5. 「編集」アイコンをクリックして「アプリケーション・ロールの編集」ビューを開きます。

6. 「追加」アイコンをクリックします
メンバーを追加するためのフォームが表示されます。

7. 検索タイプを「アプリケーション・ロール」から「グループ」に変更します。

8. 「検索」機能を使用して、「エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング」で作成したWCPAdministrators LDAPグループを検索します。

9. WCPAdministratorsグループの検索結果の適切な行をクリックして選択します。

10. 「OK」をクリックして、選択したグループをロールに追加します。

11. 「アプリケーション・ロールの編集」ページで、更新されたメンバー・リストに新しく追加したグループが含まれていることを確認します。

12. 「OK」クリックしてアプリケーション・ロールに対する変更を保存します。

13. WC_Portal1管理対象サーバーを再起動します。
WCPAdministratorsグループのメンバーとしてWebCenter Portalにログインすると、「管理」リンクが表示されて、すべての管理操作を実行できます。

15.12.3.3 WLSTを使用したWebCenter Discussions管理者ロールの付与

WCPAdministrators LDAPクループにはWebCenter Portal Discussionsサービスの管理ロールを付与する必要もあります。ここで示すWLSTコマンドを使用して、LDAPグループにそのロールの付与を適用します。

1. 次のように、WebCenter Portal Oracleホーム・ディレクトリに移動してWLSTスクリプトを起動します。

(Unix) ORACLE_COMMON_HOME/common/bin/wlst.sh
(Windows) ORACLE_COMMON_HOME/common/bin/wlst.cmd

2. 次のコマンドを使用して、ターゲット・ドメインの管理サーバーに接続します。

wls:/offline>connect("user_name","password", "ADMINVHN:7001")

3. addDiscussionsServerAdminコマンドを使用して、WCPAdministrators LDAPグループにDiscussions管理者権限を付与します。

addDiscussionsServerAdmin(appName='owc_discussions', server='WC_Collaboration1', name='WCPAdministrators', type='GROUP')

WCPAdministratorsは、前に作成したポータル管理グループの名前です。

4. WLSTからWC_Collaboration1管理対象サーバーを再起動します。

shutdown('WC_Collaboration1', block='true', force='true')
start('WC_Collaboration1', block='true')

5. 新しいアカウントをテストするには、アカウント名weblogic_wcpを使用してWebCenter Discussions管理にログインします。ブラウザでhttp://WCPHOST1:9003/owc_discussions/adminを使用して、WebCenter Discussions管理アプリケーションを開きます。ログインできる場合、付与は成功しました。

15.12.4 WCPHOST2での管理対象サーバーの起動と検証

WCPHOST1で正常な構成を検証して管理対象サーバーを起動したら、「WC_Portal1、WC_Portlet1、WC_Collaboration1管理対象サーバーの起動と検証」の手順を使用して、WCPHOST2で新しい管理対象サーバーを起動して検証できます。

検証URLとしてWebブラウザに次のURLを入力し、エンタープライズ・デプロイメント管理ユーザー(weblogic_wcp)を使用してログインします。

http://WCPHOST2:9001/webcenter

WCPHOST2でポータル、ポートレットおよびコラボレーションの管理対象サーバーを起動したら、次のアプリケーションURLを使用してWebアプリケーションが応答することを検証します。

- http://WCPHOST2:9001/webcenter

- http://WCPHOST2:9001/webcenterhelp

- http://WCPHOST2:9001/rss

- http://WCPHOST2:9001/rest/api/resourceIndex

- http://WCPHOST2:9002/pagelets/welcome

- http://WCPHOST2:9002/portalTools

- http://WCPHOST2:9002/wsrp-tools/info

- http://WCPHOST2:9003/owc_discussions

注意:
必要に応じて、weblogic_wcpとして認証します。

15.13 分析の構成

分析コレクタは、デフォルトでローカルのWebCenter Portalアプリケーションと1対1の関係で通信できるよう構成されています(コレクタはlocalhostをリスニングします)。分析コレクタの追加構成は、手動による従来のクラスタの構成で、Portal_ClusterがWCPHOSTごとに複数の管理対象サーバーを含めて垂直方向にスケールアップする場合にのみ必要です。

ただし、localhostにイベント・メッセージを送信するよう、WebCenter Portalアプリケーションを構成する必要があります。

注意:
クラスタ化された分析コレクタでは、WebCenter Portalのイベントの収集はサポートしていません。
ホストごとに複数のポータル管理対象サーバーをスケールアップする場合、分析コレクタのポートの競合を回避するための追加構成が必要です。その場合、コレクタの最大ポート値の構成の詳細は、『Oracle WebCenter Portalの管理』の分析コレクタ設定の構成に関する項を参照してください。

ポータル・ランタイム構成では、単一ポートによる単一のアクティブな分析コレクタ・サービス登録のみをサポートします。ポータル登録と一致するポートを使用してホストごとに起動されたコレクタのみがデータを収集します。そのコレクタまたは管理対象サーバーが停止すると、そのホストの残りのポータル・サーバーのいずれについても分析イベント収集は発生しません。

- WebCenter Portalのデフォルトの分析接続の登録
WebCenter Portalアプリケーションを分析コレクタに接続します。

- スケールアップに対応するための分析の構成
ポータル管理対象サーバーを、ホストごとに1つ以上の管理対象サーバーにスケールアップする場合、追加の構成および管理プロセスが分析に必要となることがあります。スケールアップ操作は、従来の静的クラスタの場合、手動になることもあります。

15.13.1 WebCenter Portalのデフォルトの分析接続の登録

WebCenter Portalアプリケーションを分析コレクタに接続します。

WebCenter Portalアプリケーションを分析コレクタに接続するには、次の手順を実行します。

1. 次のように、weblogic_wcpユーザーとしてWLSTを使用してドメインの管理サーバーに接続します。

ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")

2. WebCenter Portalアプリケーションと分析コレクタの間に接続を作成し、それをデフォルトの接続にします(default=1)

注意:

この項で示すコマンドは、接続に対して特定のサーバー名がリストされていても、WebCenterクラスタ化アプリケーションに対して1回のみ実行する必要があります。この構成が設定されると、すべてのサーバーに適用されます。

次に例を示します。

createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="Collector31314", collectorPort=31314, isEnabled=1, default=1, isUnicast=1, collectorHost="localhost", timeout=30)

『WebLogic Scripting Toolコマンド・リファレンス』のcreateAnalyticsCollectorConnectionに関する項も参照してください。

3. 変更を確認します。

listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1")

『WebLogic Scripting Toolコマンド・リファレンス』のlistDefaultAnalyticsCollectorConnectionに関する項も参照してください。

15.13.2 スケールアップに対応するための分析の構成

ポータル管理対象サーバーを、ホストごとに1つ以上の管理対象サーバーにスケールアップする場合、追加の構成および管理プロセスが分析に必要となることがあります。スケールアップ操作は、従来の静的クラスタの場合、手動になることもあります。

次のシナリオでは、スケールアップに対応するために、2つの追加構成に対処する必要があります。

1. 複数のコレクタ・サービスが単一ホストで稼働し、個別のポートでリスニングできるように分析コレクタのポート範囲を設定する必要があります。

2. 追加コレクタ用のWebCenter Portal登録を追加する必要があります。デフォルト・ポートの分析コレクタが使用できない場合に、これらの登録を素早くアクティブにしてポータル・サーバーを再起動できます。その場合、ポータル・サーバーでは、更新された登録済ポートを使用しようとします。

信頼できる分析の高可用性に関する要件は、次のとおりです。

- ポータル内のデフォルトおよびアクティブな登録で指定されたポートでリスニングする分析コレクタ・プロセスがあること。

- すべてのWCPHOSTで構成された分析コレクタのポート範囲内にある各ポートで使用可能な分析コレクタ・プロセスがあること。

- すべてのWCPHOSTに同一番号のスケールアップされたポータル管理対象サーバーがあること。ない場合、ポータル・サーバーによっては選択した登録用のローカルホストの現在デフォルトまたは使用可能なポートでコレクタが見つからないことがあります。

- 分析コレクタのポート範囲の構成
分析コレクタ設定は環境全体にわたるもので、サーバー単位にカスタマイズすることはできません。maxPortパラメータは、複数のポータル・インスタンスでホストごとに固有のポートを使用するために、defaultPortより上の有効範囲を指定します。コレクタ・プロセスがデフォルト・ポートにバインドできない場合、maxPort値に達するまで、すべてのポート番号を試行します。使用可能なポートがない場合、ポータル管理対象サーバーは適切に起動できません。

- WebCenter Portalでの分析コレクタの追加登録
構成した分析コレクタのポート範囲内のポートごとに、固有の接続名および分析コレクタ構成で割り当てたポート範囲に基づいたポートを指定して、デフォルト以外のコレクタを追加登録します。

- ポータルのデフォルト分析登録のフェイルオーバー
現在デフォルトの分析コレクタ・インスタンスがある管理対象サーバーについてポータル管理対象サーバー障害が発生した場合、ポータルのデフォルト分析登録を更新して、できるだけ早くポータル・サーバーを再起動する必要があります。

15.13.2.1 分析コレクタのポート範囲の構成

分析コレクタ設定は環境全体にわたるもので、サーバー単位にカスタマイズすることはできません。maxPortパラメータは、複数のポータル・インスタンスでホストごとに固有のポートを使用するために、defaultPortより上の有効範囲を指定します。コレクタ・プロセスがデフォルト・ポートにバインドできない場合、maxPort値に達するまで、すべてのポート番号を試行します。使用可能なポートがない場合、ポータル管理対象サーバーは適切に起動できません。

分析のmaxPort値を更新するには、ドメインの管理サーバーに接続する際に次のWLSTメソッドを使用します。

1. 次のように、WLSTを使用してドメインの管理サーバーに接続します。

ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")

2. 次のWLSTコマンドを使用して、現行の分析コレクタ構成をリストします。

listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')

コレクタ・デフォルト・ポートおよびコレクタ最大ポートの割当てに注目してください。追加設定なしの状態では、同じポート番号です。

次に例を示します。

Collector Hostname  =  localhost
Collector Default Port  =  31314
Collector Maximum Port  =  31314
Broadcast Type  =  Multicast
Collector Heartbeat Frequency  =  10
Cluster Enabled?  =  0
Cluster Name  =

3. 必要な新しいコレクタ最大ポート番号を計算します。

これは、決定したポータル管理対象サーバーの数(環境でWCPHOSTnとして割り当てたマシン数の偶数倍まで切り上げる必要があります)に基づきます。この倍数は、WCPHOSTごとのポータル管理対象サーバーの数です。この倍数から1を減算して分析コレクタのデフォルト・ポート番号に加算し、分析コレクタのmaxPortパラメータ値を計算します。

注意:

可用性の高い環境での安定した分析メトリック収集のために、すべてのWCPHOSTマシンには、いかなる場合でも変らない一連のポートで稼働する同数のコレクタが必要です。

シナリオ例1:

- 環境の要件/ファクト:

- SLAでは、ホスト障害時のパフォーマンス低下(サーバーの減少)を考慮します。

- スケーラビリティ/パフォーマンスに必要なポータル管理対象サーバーの数: 5

- 購入したWCPHOSTマシンの数: 2

- WCPHOSTごとのメモリー/CPUリソース制限: 3つのポータル管理対象サーバー・インスタンス

- 分析コレクタのデフォルト・ポートは変りません(31314)

- ポータルおよび分析コレクタは同じ管理対象サーバー(WCP 12.2.1追加設定なしのトポロジ)にデプロイされます

- 分析:

- WCPHOSTごとに3つの管理対象サーバーとなるよう、ポータル・サーバーを均一にスケール変更する必要があります。

- 分析コレクタのmaxPort: 31316
デフォルト・ポート + ホストごとのポータル・サーバー数 - 1 = (31314+3-1)

シナリオ例2:

- 環境の要件/ファクト:

- SLAでは、ホスト障害時のパフォーマンス低下(サーバーの減少)を考慮しません。

- スケーラビリティ/パフォーマンスに必要なポータル管理対象サーバーの数: 5

- 購入したWCPHOSTマシンの数: 2

- WCPHOSTごとのメモリー/CPUリソース制限: 5つのポータル管理対象サーバー・インスタンス

- 分析コレクタのデフォルト・ポートは変りません(31314)

- ポータルおよび分析コレクタは同じ管理対象サーバー(WCP 12.2.1追加設定なしのトポロジ)にデプロイされます

- 分析:

- WCPHOSTごとに5つの管理対象サーバーとなるよう、ポータル・サーバーを均一にスケール変更する必要があります。

- 分析コレクタのmaxPort: 31318
デフォルト・ポート + ホストごとのポータル・サーバー数 - 1 = (31314+5-1)

4. コレクタ構成設定を更新してmaxPort値を設定します。

maxPort値は、コレクタ・デフォルト・ポート以上の増分されたポート番号です。

注意:
この項で示すコマンドは、接続に対して特定のサーバー名がリストされていても、WebCenterクラスタ化アプリケーションに対して1回のみ実行する必要があります。この構成が設定されると、すべてのサーバーに適用されます。

次に例を示します。

setAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1', maxPort=31316)

『WebLogic Scripting Toolコマンド・リファレンス』のcreateAnalyticsCollectorConnectionに関する項も参照してください。

5. listAnalyticsCollectorConfig() WLSTメソッドを使用してコレクタ最大ポート値に対する変更を確認します。
次に例を示します。

listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')

Collector Hostname  =  localhost
Collector Default Port  =  31314
Collector Maximum Port  =  31316
Broadcast Type  =  Multicast
Collector Heartbeat Frequency  =  10
Cluster Enabled?  =  0
Cluster Name  =

『WebLogic Scripting Toolコマンド・リファレンス』のlistDefaultAnalyticsCollectorConnectionに関する項も参照してください。

6. 「WebCenter Portalでの分析コレクタの追加登録」を実行したら、ポータル・サーバーを再起動します。

15.13.2.2 WebCenter Portalでの分析コレクタの追加登録

構成した分析コレクタのポート範囲内のポートごとに、固有の接続名および分析コレクタ構成で割り当てたポート範囲に基づいたポートを指定して、デフォルト以外のコレクタを追加登録します。

次に例を示します。

createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="NAME", collectorPort=PORTNUMBER, isEnabled=1, default=0, isUnicast=1, collectorHost="localhost", timeout=30)

手順は次のとおりです。

1. 次のように、WLSTを使用してドメインの管理サーバーに接続します。

ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")

2. 次のWLSTコマンドを使用して、現行の分析コレクタ構成をリストします。

listAnalyticsCollectorConfig(appName='analytics-collector', server='WC_Portal1')

次に例を示します。

Collector Hostname  =  localhost
Collector Default Port  =  31314
Collector Maximum Port  =  31316
Broadcast Type  =  Multicast
Collector Heartbeat Frequency  =  10
Cluster Enabled?  =  0
Cluster Name  =

注意:
デフォルト・ポートから最大ポートまでの範囲内にある(最大ポート番号を含む)すべてのポート番号について、次の手順を繰り返す必要があります。デフォルト・ポートの登録は先に完了しておく必要があります。

3. WLSTから、デフォルト・ポートより上のポート番号から最大ポート番号までのポートごとに登録を追加します。各登録のconnectionName値とcollectorPort値を変更します。

次に例を示します。

createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="collector31315", collectorPort=31315, isEnabled=1, default=0, isUnicast=1, collectorHost="localhost", timeout=30)

createAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1", connectionName="collector31316", collectorPort=31316, isEnabled=1, default=0, isUnicast=1, collectorHost="localhost", timeout=30)

4. WLSTを使用して、すべての分析登録について詳細をリストして確認します。

listAnalyticsCollectorConnections(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31315
------------------
Cluster Name / Host Name: localhost
Port: 31315
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31316
------------------
Cluster Name / Host Name: localhost
Port: 31316
Timeout: 30
Unicast: true
Enabled: true

5. WLSTを使用して、デフォルトの(現在アクティブな)分析登録について詳細をリストします。
次に例を示します。

listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true

注意:
この例では、ポート: 31314 (デフォルト・ポート)を示しています。複数の登録が作成されていますが、ポータルの分析登録は代替接続/ポートにまだフェイルオーバーされていません。マシンごとに起動される最初のポータル管理対象サーバーには、デフォルト・ポートでリスニングしている分析コレクタがあります。

6. すべてのWC_Portaln管理対象サーバーを再起動して、変更を有効にします。これは、同時に実行することも、ローリング方式で実行することも可能です。

例 - 同時:

shutdown('Portal_Cluster', 'Cluster', force='true', block='true')
start('Portal_Cluster',  'Cluster', block='true')

例 - ローリング方式(停止なし):

shutdown('WC_Portal1', force='true', block='true')
start('WC_Portal1', block='true')

shutdown('WC_Portal2', force='true', block='true')
start('WC_Portal2', block='true')

15.13.2.3 ポータルのデフォルト分析登録のフェイルオーバー

現在デフォルトの分析コレクタ・インスタンスがある管理対象サーバーについてポータル管理対象サーバー障害が発生した場合、ポータルのデフォルト分析登録を更新して、できるだけ早くポータル・サーバーを再起動する必要があります。

そうなるまで、そのマシンの残りのポータル・インスタンスに対する分析収集は、デフォルト・ポートのコレクタとやり取りして分析メトリックを記録することができません。同時にデフォルトでありアクティブである登録は1つのみです。

デフォルト分析登録のフェイルオーバーは手動プロセスです。変更は環境全体にわたるものですが、各ポータル・サーバー・インスタンスの再起動時にのみ有効になります。

デフォルト分析登録を変更するには、次の手順を実行します。

1. 次のように、WLSTを使用してドメインの管理サーバーに接続します。

ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "t3://ADMINVHN:7001")

2. WLSTを使用して、デフォルトの(現在アクティブな)分析登録について詳細をリストします。

listDefaultAnalyticsCollectorConnection(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true

3. WLSTによって使用可能な分析登録をリストし、別のコレクタ名を選択してデフォルトとして設定します。

listAnalyticsCollectorConnections(appName="webcenter", server="WC_Portal1")

------------------
Collector31314
------------------
Cluster Name / Host Name: localhost
Port: 31314
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31315
------------------
Cluster Name / Host Name: localhost
Port: 31315
Timeout: 30
Unicast: true
Enabled: true
------------------
Collector31316
------------------
Cluster Name / Host Name: localhost
Port: 31316
Timeout: 30
Unicast: true
Enabled: true

4. WLSTを使用して、デフォルト分析登録を更新します。

setDefaultAnalyticsCollectorConnection(appName="webcenter", name="Collector31315")

5. すべてのWC_Portaln管理対象サーバーを再起動して、変更を有効にします。これは、同時に実行することも、ローリング方式で実行することも可能です。

例 - 同時:

shutdown('Portal_Cluster', 'Cluster', force='true', block='true')
start('Portal_Cluster', 'Cluster', block='true')

例 - ローリング方式(停止なし):

shutdown('WC_Portal1', force='true', block='true')
start('WC_Portal1', block='true')

shutdown('WC_Portal2', force='true', block='true')
start('WC_Portal2', block='true')

15.14 REST APIの構成

この項では、REST APIの構成手順について説明します。

WebCenter Portal REST APIを使用する場合、この項で説明するコマンドを実行してサーバー側の資格証明ストア構成を確認します。
これらの資格証明エントリは、WebCenter Portalのドメイン拡張の一環としてすでに構成されている必要があります。

RESTセキュリティ・トークンが正しく機能できるようにする、資格証明ストア内のシード・エントリを確認するには、次のWLSTコマンドを実行します。

注意:
資格証明マップがすでに存在する場合は、JPS-01007例外メッセージが戻されます。これにより、構成を確認します。

1. 次のように、コマンドラインのOracle WebLogic Scripting Tool (WLST)を使用して管理サーバーに接続します。

ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('weblogic_admin_username','weblogic_admin_pwd','t3://ADMINVHN:7001')

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.15 拡張したドメイン用のOracle HTTP Serverの構成

次の項では、パブリックURLおよび内部URLの両方のリクエストを、エンタープライズ・トポロジ内の正しクラスタにルーティングするようにOracle HTTP Serverインスタンスを構成する方法について説明します。

- Oracle WebCenter Portalクラスタ用のOracle HTTP Serverの構成

- WebLogicプロキシ・プラグインの構成

- ロード・バランサによるOracle WebCenter Portalパブリック・サービスURLの検証

- 内部WebCenterサービス用のHTTPサーバーの構成

- ロード・バランサによるOracle WebCenter Portal内部サービスURLの検証

15.15.1 Oracle WebCenter Portalクラスタ用のOracle HTTP Serverの構成

Oracle WebCenter Portalクラスタにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、wcp.example.com仮想サーバーのパラメータを作成して定義するOracle HTTP Server構成ファイルを追加作成します。

この手順では、「アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成」で説明されているOracle HTTP Server構成タスクが実行済であることを想定しています。

リクエストが正しくルーティングされるように仮想ホスト構成ファイルを作成する手順は次のとおりです。

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(OHS1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/

2. wcp_vh.confファイルを編集し、次のディレクティブをファイルの終わり近く、最終行の<VirtualHost>のすぐ上に追加します。

# WebCenter Portal Application (previously called Spaces)
<Location /webcenter>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /webcenterhelp>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /rss>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /rest>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Discussions
<Location /owc_discussions>
WLSRequest ON
WebLogicCluster WCPHOST1:9003,WCPHOST2:9003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /portalTools>
WLSRequest ON
WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /wsrp-tools>
WLSRequest ON
WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

</VirtualHost>

3. wcp_vh.confファイルをWEBHOST2上の2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

scp OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/wcp_vh.conf \
WEBHOST2:/OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/wcp_vh.conf

4. WEBHOST2にログインし、ディレクトリを2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/

5. wcp_vh.confを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。

6. 両方のOracle HTTP Serverを再起動します。

15.15.2 WebLogicプロキシ・プラグインの構成

リクエストがOracle HTTP Serverインスタンスを介して正しくルーティングされることを検証するには、構成したクラスタのWebLogic Plug-In Enabledパラメータを前もって設定する必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ペインで「環境」ノードを開きます。

3. 「チェンジ・センター」で「ロックして編集」をクリックします。

4. 「クラスタ」をクリックします。

5. Oracle HTTP Serverからのリクエストをプロキシ設定する、クラスタを選択します。

「構成: 一般」タブが表示されます。

6. 「詳細」セクションまでスクロール・ダウンして、開きます。

7. 「WebLogicプラグインの有効化」を「はい」に設定します。

8. 「保存」をクリックします。

9. 直近のドメイン拡張で複数のクラスタをデプロイした場合は、すべてのクラスタが一貫して更新されるまで、手順4から8を繰り返します。

10. 「チェンジ・センター」の「変更のアクティブ化」をクリックします。

11. この章で変更したすべてのクラスタのすべての管理対象サーバーを再起動します。

15.15.3 ロード・バランサによるOracle WebCenter Portalパブリック・サービスURLの検証

Oracle HTTP Server仮想ホストの構成を検証し、ハードウェア・ロード・バランサがOracle HTTP Serverインスタンスを経由してアプリケーション層にパブリック・サービス・リクエストをルーティングできることを確認する手順は次のとおりです。

1. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

2. 次のURLにアクセスできることを確認します。

- 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/portalTools

- https://wcp.example.com/wsrp-tools/info

- https://wcp.example.com/owc_discussions

15.15.4 内部WebCenterサービス用のHTTPサーバーの構成

内部Oracle WebCenterサービスにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、既存のwcpinternal_vh.confファイルを編集します。

この手順では、「アプリケーション層にリクエストをルーティングするためのOracle HTTP Serverの構成」で説明されているOracle HTTP Server構成タスクが実行済であることを想定しています。

リクエストが正しくルーティングされるように仮想ホスト構成ファイルを編集する手順は次のとおりです。

1. WEBHOST1にログインし、ディレクトリを最初のOracle HTTP Serverインスタンス(ohs1)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/

2. wcpinternal_vh.confファイルを編集し、次のディレクティブをファイルの終わり近く、最終行の<VirtualHost>のすぐ上に追加します。

# WebCenter Portal Application Services

<Location /webcenter>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /webcenterhelp>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /rss>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /rsscrawl>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /sesUserAuth>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /rest>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Discussions
<Location /owc_discussions>
WLSRequest ON
WebLogicCluster WCPHOST1:9003,WCPHOST2:9003
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Portlets
<Location /pagelets>
WLSRequest ON
WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /portalTools>
WLSRequest ON
WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /wsrp-tools>
WLSRequest ON
WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Collector
<Location /collector>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

</VirtualHost>

3. wcpinternal_vh.confファイルをWEBHOST2上の2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

scp OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/wcpinternal_vh.conf \
WEBHOST2:/OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/wcpinternal_vh.conf

4. WEBHOST2にログインし、ディレクトリを2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリに変更します。

cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/

5. wcpinternal_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1の参照からWEBHOST2の参照に変更します。

6. 両方のOracle HTTP Serverを再起動します。

15.15.5 ロード・バランサによるOracle WebCenter Portal内部サービスURLの検証

Oracle HTTP Server仮想ホストの構成を検証し、ハードウェア・ロード・バランサがOracle HTTP Serverインスタンスを経由してアプリケーション層に内部サービス・リクエストをルーティングできることを確認する手順は次のとおりです。

1. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

2. 次のURLにアクセスできることを確認します。

- http://wcpinternal.example.com/rss

- http://wcpinternal.example.com/rest/api/resourceIndex

- http://wcpinternal.example.com/pagelets

- http://wcpinternal.example.com/portalTools

- http://wcpinternal.example.com/wsrp-tools

- http://wcpinternal.example.com/owc_discussions

- http://wcpinternal.example.com/collector

15.16 外部サービス用のWebCenter Portalの構成

この項では、Fusion Middleware ControlまたはWLSTコマンドを使用して、WebCenter Portalアプリケーション用に外部のツールおよびサービスを構成する方法を説明します。多くの外部サービスでは、WebCenter Portalアプリケーションとバックエンド・サーバー間に接続を設定する必要があります。

- WebCenter Portal、ディスカッションおよびポートレット・プロデューサ・アプリケーション用デフォルトWebサービス・ポリシーの構成

- ディスカッション・サーバーの接続の構成

- コンテンツ・サーバーの接続の構成
Oracle WebCenter Portalは、ファイルのアップロード、ファイルとフォルダの作成と管理、ファイルのチェックアウト、バージョン管理を含む、コンテンツ管理とストレージ機能をサポートします。

- ポートレット・プロデューサの登録

- ページレット・プロデューサの登録

- 検索サービスの構成

- SMTPメール・サーバー用のOracle WebCenter Portal通知の構成

15.16.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_Portal1、WC_Portal2、WC_Collaboration1、WC_Collaboration2、WC_Portlet1およびWC_Portlet2管理対象サーバーが起動し、稼働していることを確認します。

2. 次のWebLogic Scripting Toolを起動します。

WCPHOST1> ORACLE_COMMON_HOME/common/bin/wlst.sh

3. 管理者として管理サーバーに接続します。

次に例を示します。

connect("weblogic_wcp","admin password","t3://ADMINVHN:7001")

詳細は、Oracle Fusion Middleware 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)

注意:

このトピックの例では、ご使用の環境のドメイン名および管理対象サーバー名を使用してアプリケーション・パスを構成します。次の例では、ドメイン名wcedgを使用しています。

a. デフォルトのOWSMセキュリティ・ポリシーをクラスタ内の各サーバー(WC_Collaboration1とWC_Collaboration2)上のディスカッションWebサービスにアタッチするには、次のWLSTコマンドを実行し、指定の箇所に正しいドメイン名を代入します。

attachWebServicePolicy(application='/domain_name/WC_Collaboration1/owc_discussions', moduleName='owc_discussions', moduleType='web', serviceName='OWCDiscussionsServiceAuthenticated', subjectName='OWCDiscussionsServiceAuthenticated', policyURI='oracle/wss10_saml_token_service_policy')

b. デフォルトのOWSMセキュリティ・ポリシーをクラスタ内の各サーバー(WC_Portlet1とWC_Portlet2)上のWSRPツール・プロデューサのWebサービス・エンド・ポイントにアタッチするには、次のWLSTコマンドを実行します。

attachWebServicePolicy(application='/domain_name/WC_Portlet1/wsrp-tools', moduleName='wsrp-tools', moduleType='web', serviceName='WSRP_v2_Service', subjectName='WSRP_v2_Markup_Service', policyURI='oracle/wss10_saml_token_service_policy')

5. WC_Portal1、WC_Portal2、WC_Collaboration1、WC_Collaboration2、WC_Portlet1およびWC_Portlet2管理対象サーバーを再起動します。

15.16.2 ディスカッション・サーバーの接続の構成

WebCenter Portalでディスカッションまたはお知らせを提供するには、アプリケーションをディスカッション・サーバーに接続する必要があります。WebCenter Portalエンタープライズ・デプロイメントで接続を構成するには、次の値が必要です。

- ディスカッション・サーバーのURL: http://wcpinternal.example.com/owc_discussions

- ディスカッション管理ユーザー: LDAPのWebCenter Portalの管理ユーザー名(weblogic_wcpなど)

- ディスカッション管理パスワード: WebCenter Portalの管理ユーザー・パスワード

- 認証されたユーザーのWebサービス・ポリシーURI: WSS 1.0 SAMLトークン・クライアント・ポリシー

ディスカッション・サーバーには、Fusion Middleware ControlまたはWLSTコマンドを使用して接続できます。

詳細は、『Oracle WebCenter Portalの管理』のお知らせおよびディスカッションの管理に関する項を参照してください。

- Fusion Middleware Controlを使用したディスカッション・サーバーの接続の作成

- WLSTを使用したディスカッション・サーバーの接続の作成
Fusion Middleware Controlではなくコマンドラインを使用する場合は、WebLogic Scripting Toolを使用してWebCenter Portalアプリケーションをディスカッション・サーバーに接続できます。

15.16.2.1 Fusion Middleware Controlを使用したディスカッション・サーバーの接続の作成

ディスカッション・サーバーにFusion Middleware Controlを使用してWebCenter Portalアプリケーションを接続するには、次の手順を実行します。

1. アプリケーションがデプロイされている管理対象サーバーが最低1つは起動し、稼働していることを確認します。

たとえば、WC_Portal管理対象サーバーのいずれかを確認します。

2. 次のURLでEnterprise Manager Fusion Middleware Controlコンソールにログオンします。

http://ADMINVHN:7001/em

3. WebCenter Portalアプリケーションのホーム・ページに移動します。

たとえば、WebCenter Portalアプリケーションのホーム・ページに移動するには、「ターゲット・ナビゲーション」を開き、「WebCenter」→「ポータル」→「サーバー」→WebCenter Portal (WC_Portal1)の順に選択します。

4. WebCenter Portalのドロップダウン・メニューから、「設定」→「サービス構成」を選択します。

5. 「ディスカッションおよびお知らせ」をクリックし、「追加」をクリックします。

6. 「ディスカッションおよびお知らせ接続の追加」画面で、次のように設定します。

- 接続名: DFConnection

- アクティブな接続: 接続を有効にする場合は、このチェック・ボックスを選択します。

- サーバーURL: http://wcpinternal.example.com/owc_discussions

- 管理者ユーザー名: LDAPのWebCenter Portalの管理ユーザー名(weblogic_wcなど)

- 認証されたユーザーのWebサービス・ポリシーURI: 「WSS 1.0 SAMLトークン・クライアント・ポリシー」(oracle/wss10_saml_token_client_policy)を選択します。

7. 「OK」をクリックして設定を保存します。

8. アプリケーションがデプロイされている管理対象サーバーを再起動します。

WebCenter Portalアプリケーションの場合、Portal_Cluster内の管理対象サーバーをすべて再起動します。

15.16.2.2 WLSTを使用したディスカッション・サーバーの接続の作成

Fusion Middleware Controlではなくコマンドラインを使用する場合は、WebLogic Scripting Toolを使用してWebCenter Portalアプリケーションをディスカッション・サーバーに接続できます。

1. 次のWebLogic Scripting Toolを起動します。

WCPHOST1> ORACLE_COMMON_HOME/common/bin/wlst.sh

2. WLSTで、管理者として接続します。

次に例を示します。

connect("weblogic_wcp","admin password","ADMINVHN:7001")

3. createDiscussionForumConnectionコマンドを使用し、ディスカッション・サーバーに接続します。

次に例を示します。

createDiscussionForumConnection(appName="webcenter",name="DFConnection",
url="http://wcpinternal.example.com/owc_discussions",
adminUser="weblogic_wcp",default=1,policyURIForAuthAccess="oracle/wss10_saml_token_client_policy",server="WC_Portal1")

webcenterはWC_Portal1にデプロイされたWebCenter Portalアプリケーションの名前であり、weblogic_wcはディスカッション・サーバーの管理ユーザーの名前です。

詳細は、『WebCenter WLSTコマンド・リファレンス』のcreateDiscussionForumConnectionに関する項を参照してください。

4. アプリケーションがデプロイされている管理対象サーバーを再起動します。

WebCenter Portalアプリケーションの場合、Portal_Cluster内の管理対象サーバーをすべて再起動します。

15.16.3 コンテンツ・サーバーの接続の構成

Oracle WebCenter Portalは、ファイルのアップロード、ファイルとフォルダの作成と管理、ファイルのチェックアウト、バージョン管理を含む、コンテンツ管理とストレージ機能をサポートします。

WebCenter Portalでコンテンツ統合を提供するには、WebCenter Content Serverの接続を1つ以上構成し、それをデフォルト接続(アクティブまたはプライマリ接続と呼ばれることもあります)としてマークする必要があります。要件の詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalのインストールと構成』のOracle WebCenter Content Serverの要件に関する項を参照してください。

WebCenter Portal Content Managerコンポーネント・ファイルのアップロードに対して高可用性を保証するには、追加構成が必要です。

- WebCenter PortalアプリケーションへのOracle WebCenter Contentの登録
Oracle WebCenter Content ServerをWebCenter Portalアプリケーションに登録する手順を示します。

- 高可用性のためのWebCenter Portal Content Manager MBeanの構成
WebCenter Portal Content Managerのコンポーネントおよびタスク・フローでは、WebCenter ContentリモートUI (RUI) APIを使用してコンテンツ統合機能を提供します。これらのライブラリはPortalのインストールに直接組み込まれる一方で、特定のMBean構成設定を高可用性アーキテクチャ内のフェイルセーフ・ランタイム用に変更する必要があります。

15.16.3.1 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」→「ポータル」→「サーバー」→WebCenter Portal (WC_Portal1)の順に開きます。

注意:
複数のWebCenter Portalエントリが表示されます(WebLogic管理対象サーバーごとに1つ)。いずれかを選択します。この項でのアプリケーション登録は、ポータル全体に適用されます。

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ソケットが使用されます。

クライアントIPアドレスは、Content Serverで許可されたアドレスのリストに追加する必要があります。この場合、クライアントはOracle WebCenter Portalを実行しているマシンです。

- サーバー・ホスト

/csへのリクエストで利用可能なすべてのコンテンツ・サーバー・ノードを使用できるように、ここにはロード・バランサのアドレス(wcpinternal.example.com)を入力します。

ロード・バランサで構成された仮想ホストのIPアドレスとロード・バランサのSelf-IPをContent Serverの着信ソケット接続アドレス・セキュリティ・フィルタに追加する必要があります。

注意:

まだ実行していない場合、WebCenter Contentトラフィックをルーティングする方法のルールを、次のようにロード・バランサに追加します。

(LBR)10.110.10.135:6300 -> 10.110.10.23:4444 (WCCHOST1) & 10.110.10.24:4444 (WCCHOST2)

- サーバー・ポート

Content Serverがリスニングするポート6300を入力します。

- 接続タイムアウト(ミリ秒)

接続タイムアウト・メッセージを発行するまで、Content Serverへのログインを許可する時間の長さ(ミリ秒)を指定します。タイムアウトが設定されていない場合、ログイン操作の時間制限はありません。環境に応じた適切なタイムアウトを選択します。たとえば、60000です。

- 接続タイムアウト

「アイデンティティ伝播」を選択します。このエンタープライズ・デプロイメントでは、Content ServerとWebCenter Portalアプリケーションは、ユーザーの認証に同じアイデンティティ・ストアを使用します。

- Webコンテキスト・ルート

Content ServerのWebサーバー・コンテキスト・ルートとして/csを入力します。

- 管理者ユーザー名

このOracle Content Serverインスタンスに対する管理者権限を持つユーザー名を入力します。このユーザーは、プロファイルに基づくコンテンツ・タイプ情報のフェッチおよびWebCenter Portalキャッシュ無効化のためのドキュメント変更の追跡に使用されます。デフォルトはsysadminです。

- 管理者のパスワード

空のままにします。「管理者のパスワード」の値は、socketTypeをwebに設定した場合のみ必要です。

8. 「OK」をクリックして、この接続を保存します。

9. 新しい(アクティブな)接続の使用を開始するには、WebCenter Portalアプリケーションがデプロイされている管理対象サーバーを再起動する必要があります。

15.16.3.2 高可用性のためのWebCenter Portal Content Manager MBeanの構成

WebCenter Portal Content Managerのコンポーネントおよびタスク・フローでは、WebCenter ContentリモートUI (RUI) APIを使用してコンテンツ統合機能を提供します。これらのライブラリはPortalのインストールに直接組み込まれる一方で、特定のMBean構成設定を高可用性アーキテクチャ内のフェイルセーフ・ランタイム用に変更する必要があります。

ポータル・アプリケーションのADFConfig:WccAdfConfigurationおよびADFConfig:ADFcConfigアプリケーション定義MBeanについて、次の属性を変更して検証します。

- ADFConfig:ADFcConfig:

- AdfScopeHaSupport

- ADFConfig:WccAdfConfiguration:

- ClusterCompatible

- TemporayDirectory

高可用性環境でポータルがクラスタ化される場合、指定されたアップロード一時ディレクトリを全ポータル・ノードの共有ディスク・ボリューム上にある共通のディレクトリ場所に構成する必要があります。

1. ORACLE_RUNTIME共有ボリュームに、Portal Content Managerのコンポーネント・アップロード場所固有のフォルダを作成します。

mkdir -p ORACLE_RUNTIME/DOMAIN_NAME/Portal_Cluster/wccAdfUpload

たとえば、次のようにします。

mkdir -p /u01/oracle/runtime/wcedg/Portal_Cluster/wccAdfUpload

2. Fusion Middleware Controlにweblogic_wcpとしてログインします。

3. 「WebLogicドメイン」メニューから「システムMBeanブラウザ」を選択します。

4. 「アプリケーション定義のMBean」で、WccAdfConfiguration属性に移動します(oracle.adf.share.config→「サーバー: WC_Portal1」→「アプリケーション: webcenter」→ADFConfig→ADFConfig→ADFConfig→WccAdfConfiguration)。

注意:
このMBean値は、任意のポータル・サーバー・インスタンスから1回のみ設定する必要があり、すべてのインスタンスに適用されます。

5. ClusterCompatible属性の値がtrueであることを確認します。

6. 「一時ディレクトリ」属性を前述の共有ストレージで作成したディレクトリに設定します。

「一時ディレクトリ」属性には、WCPHOST1とWCPHOST2の両方がこのディレクトリ下に格納されたアップロード・ファイルにアクセスできるように、ディレクトリを設定する必要があります。

たとえば、次のようにします。

/u01/oracle/runtime/wcedg/Portal_Cluster/wccAdfUpload

7. 「適用」をクリックします。

8. 次の確認メッセージを待機します。

Attributes "TemporaryDirectory" have been updated successfully.

9. 同じ「アプリケーション定義のMBean」パスで、ADFcConfiguration Beanをクリックします。

10. 「アプリケーション定義のMBean」で、ADFcConfiguration属性に移動します(oracle.adf.share.config→「サーバー: WC_Portal1」→「アプリケーション: webcenter」→ADFConfig→ADFConfig→ADFConfig→ADFcConfiguration)。

11. AdfScopeHASupport属性の値がtrueに設定されていることを確認し、必要に応じて更新します。

12. 値を更新した場合は、「適用」をクリックしてページ上部に確認メッセージが表示されることを確認します。

13. 2レベル上のadf-config MBeanに移動して、保存操作を起動します。oracle.adf.share.config→「サーバー: WC_Portal1」→「アプリケーション: webcenter」→ADFConfig→ADFConfigの順にクリックします。

14. 「操作」タブをクリックします。

15. 「操作」タブ・ビューの「名前」列の「保存」リンクをクリックします。

16. 「操作: 保存」ページで、「起動」をクリックして、前回の保存操作以降に行われたすべてのMBeanの変更をコミットします。

17. ページ上部に確認メッセージが表示されることを確認し、「戻り」をクリックします。

18. ポータル・クラスタ内のすべての管理対象サーバーを再起動します。

15.16.4 ポートレット・プロデューサの登録

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コマンドを使用して登録できます。

- Fusion Middleware Controlを使用したすぐに使用できるポートレット・プロデューサの登録

- WLSTを使用したすぐに使用できるポートレット・プロデューサの登録

15.16.4.1 Fusion Middleware Controlを使用したすぐに使用できるポートレット・プロデューサの登録

Fusion Middleware Controlを使用してポートレット・プロデューサを登録する方法の詳細は、『Oracle WebCenter Portalの管理』の「ポートレット・プロデューサの管理」を参照してください。

15.16.4.2 WLSTを使用したすぐに使用できるポートレット・プロデューサの登録

WLSTを使用し、すぐに使用できるポートレット・プロデューサを登録するには、次の手順を実行します。

1. 次のWebLogic Scripting Toolを起動します。

WCPHOST1> ORACLE_HOME/oracle_common/common/bin/wlst.sh

2. WLSTで、管理者として接続します。

次に例を示します。

connect("weblogic_wcp","admin password","t3://ADMINVHN:7001",server="WC_Portal1")

3. すぐに使用できる3つのWSRPおよびPDK-Javaプロデューサをすべて登録します。

次に例を示します。

registerOOTBProducers(producerHost='wcpinternal.example.com',producerPort=80, appName='webcenter', server='WC_Portal1')

webcenterは、WC_Portal1にデプロイされたWebCenter Portalアプリケーションの名前です。

『WebCenter WLSTコマンド・リファレンス』のregisterOOTBProducersに関する項も参照してください。

15.16.5 ページレット・プロデューサの登録

WSRP、Oracle JPDKポートレットおよびOpenSocialガジェットをWebCenter Portalでページレットとして公開するには、ページレット・プロデューサを登録する必要があります。WebCenter Portalエンタープライズ・デプロイメントでは、必要なページレット・プロデューサのURLは次のとおりです。

http://wcpinternal.example.com/pagelets

ページレット・プロデューサは、Fusion Middleware ControlまたはWLSTコマンドを使用して登録できます。

- Fusion Middleware Controlを使用したページレット・プロデューサの登録

- WLSTを使用したページレット・プロデューサの登録

15.16.5.1 Fusion Middleware Controlを使用したページレット・プロデューサの登録

Fusion Middleware Controlを使用してページレット・プロデューサを登録するには:

1. Fusion Middleware Controlにweblogic_wcpとしてログインし、WebCenter Portalのホーム・ページに移動します。

注意:

Enterprise Manager Fusion Middleware ControlでWebCenterリソースを管理する場合、リモートLDAPオーセンティケータ(weblogic_wcpなど)で作成されたWebCenter固有の管理ユーザーを使用することをお薦めします。詳細は、エンタープライズ・デプロイメントの管理用のロールの構成を参照してください。

詳細は、『Oracle WebCenter Portalの管理』のWebCenter Portalのホームページへの移動に関する項を参照してください。

2. 「WebCenter Portal」メニューから、「プロデューサの登録」を選択します。

3. 次の表に示すように、ページレット・プロデューサの接続詳細を入力します。

フィールド

説明

接続名

このページレット・プロデューサのインスタンスをアプリケーション内で識別するための一意の名前。名前は、すべてのWebCenter Portal接続タイプにおいて一意である必要があります。ここで指定した名前は、「UIコンポーネント」→「ページレット・プロデューサ」フォルダにあるコンポーザに表示されます(デフォルト)。

プロデューサ・タイプ

「ページレット・プロデューサ」を選択します。

サーバーURL

ページレット・プロデューサへのURL。URLには、完全修飾ドメイン名を含める必要があります。次の構文を使用します。

<protocol>://<host_name>:<port_number>/pagelets/

次に例を示します。

http://wcpinternal.example.com/pagelets/

ページレットにセキュアなデータが含まれている場合、登録するURLでhttpsプロトコルを使用する必要があります。次に例を示します。

https://wcp.example.com/pagelets/

コンテキスト・ルートは、必要に応じて/pagelets/から変更できます。詳細は、『Oracle WebCenter Portalの管理』のページレット・プロデューサの別のコンテキストへの再デプロイに関する項を参照してください。

注意: WebCenter Portalでは、ページレット・プロデューサのURLがOAMによって保護されている場合、ページレット・カタログへのURLを除外する(アクセス制御なしで直接マップする)必要があります。そうしないと、RESTを使用した場合にカタログが空白になります。ページレット・カタログのURLは、http://<host_name>:<port_number>/ pagelets/api/v2/ensemble/pageletsです

4. 「OK」をクリックします。新しいプロデューサが接続表に表示されます。

15.16.5.2 WLSTを使用したページレット・プロデューサの登録

WLSTを使用し、すぐに使用できるページレット・プロデューサを登録する手順は次のとおりです。

1. 次のWebLogic Scripting Toolを起動します。
WCPHOST1> ORACLE_COMMON_HOME/common/bin/wlst.sh

2. WLSTで、管理者として接続します。
たとえば、次のようにします。

connect("weblogic_wcp","admin password","t3://ADMINVHN:7001",server="WC_Portal1")

3. 次のコマンドを入力して、ページレット・プロデューサを登録します。
registerPageletProducer(appName='webcenter', name='PageletProducer', url='http://wcpinternal.example.com/pagelets', server='WC_Portal1')

コマンドの構文と例は、WebCenter WLSTコマンド・リファレンスのregisterPageletProducerに関する項を参照してください。

WLSTを使用して、現在の接続詳細を表示または編集することもできます。

WLSTコマンドの実行方法の詳細は、『Oracle WebCenter Portalの管理』のOracle WebLogic Scripting Tool (WLST)コマンドの実行に関する項を参照してください。

15.16.6 検索サービスの構成

『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebCenter Portalの管理』のOracle SES接続の設定に関する項の説明のとおり、WebCenter PortalアプリケーションとOracle Secure Enterprise Searchの間には接続が存在します。

次に示すように、新しいURLがいずれも、wcinternal_vh.confファイルのwcpinternal.example.comホストに追加されていることを確認します。

<Location /rsscrawl>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /sesUserAuth>
WLSRequest ON
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

15.16.7 SMTPメール・サーバー用のOracle WebCenter Portal通知の構成

WebCenter Portalエンタープライズ・デプロイメントで、メールを使用して通知を送信することにした場合、企業のメール・サーバーへの接続を構成し、送信されたメールが正しく表示されるように固有のパラメータをいくつか指定する必要があります。

メール・サーバーおよびビジネス要件について不足なく構成するには、このタスクを完了する前に、必須およびオプションの構成とパラメータに関する詳細を『Oracle WebCenter Portalの管理』の「メールの管理」で確認してください。

メール・サーバーは、Fusion Middleware ControlまたはWLSTコマンドを使用して登録できます。

- Fusion Middleware Controlを使用したメール・サーバーの登録

- WLSTを使用したメール・サーバーの登録

15.16.7.1 Fusion Middleware Controlを使用したメール・サーバーの登録

Fusion Middleware Controlを使用してメール・サーバーを登録する方法の詳細は、『Oracle WebCenter Portalの管理』のFusion Middleware Controlを使用したメール・サーバーの登録に関する項を参照してください。

15.16.7.2 WLSTを使用したメール・サーバーの登録

WLSTコマンドのcreateMailConnectionを使用して、メール・サーバーの接続を作成します。

1. 次のWebLogic Scripting Toolを起動します。

ORACLE_HOME/oracle_common/common/bin/wlst.sh

2. 管理サーバーに接続します。

次に例を示します。

connect('weblogic_wcp','admin password','t3://ADMINVHN:7001')

3. メール・サーバー用の外部アプリケーション接続を登録します。

createMailExtAppConnection(appName='webcenter', name='CorpMailServer', displayName='Corporate Mail Server', server='WC_Portal1')

4. メール・サーバー接続を登録します。

createMailConnection(appName='webcenter', name='NotificationSharedConn', smtpHost='mail.example.com', smtpPort=25, smtpSecured=0,
timeout=10, default=1,appId='CorpMailServer', server='WC_Portal1')

注意:

配信リストを通知する機能など、その他の機能は使用可能であり、メール・サーバーおよびビジネス・ニーズよっては必須になることもあります。詳細は、『Oracle WebCenter Portalの管理』のメールの管理に関する項を参照してください。

5. 必須のメール・サーバー接続プロパティを設定します。

これらのプロパティは、特定のメール・アドレスが外部アプリケーションとメール・サーバーで同じであることを保証します。これらのプロパティはメール接続に追加され、メールで「送信元」、「表示名」および「返信先」の各フィールドに使用されます。

次に例を示します。

setMailConnectionProperty(appName='webcenter', name='NotificationSharedConn', key='mail.user.emailAddress', value='john.doe@example.com')

setMailConnectionProperty(appName='webcenter', name='NotificationSharedConn', key='mail.user.displayName', value='John Doe')

setMailConnectionProperty(appName='webcenter', name='NotificationSharedConn', key='mail.user.replyToAddress', value='feedback@example.com')

6. Exchange 2007についてのみ、汎用配信リストを作成します。そのためには、mail.exchange.dl.group.typeプロパティの値を2 (デフォルト値)から8に更新する必要があります。

次のように、mail.exchange.dl.group.typeメール・プロパティに値8を指定します。

setMailServiceProperty(appName='webcenter', property='mail.exchange.dl.group.type', value='8')

アプリケーションで、要求時にユーザーID情報をメール送信する機能を備えた自己登録ページを用意している場合、ここで選択した外部アプリケーションに対してパブリック資格証明が構成されていることを確認してください。パブリック資格証明が定義されていない場合、要求時にユーザーにメールが送信されません。WebCenter Portalでは、デフォルトの自己登録ページでこの機能を提供しています。

7. ポータル・クラスタを再起動します。

shutdown('Portal_Cluster', 'Cluster',force='true',block='true')
start('Portal_Cluster', 'Cluster',block='true')

16 同一ドメイン内でのWebCenter PortalワークフローのOracle SOA Suiteとの統合

WebCenter Portalには、ポータル・メンバーシップ通知、ポータル・サブスクリプション・リクエストなどを処理する事前作成されたワークフローがいくつか用意されています。WebCenter Portalワークフローは、Oracle SOA SuiteのコンポーネントとしてインストールされるOracle BPM Worklistに依存します。

WebCenter Portalワークリストの統合では、SOA Suiteによって提供されるBPELサービスが同じWeb層、SSOおよびアイデンティティ・ストアをポータルと共有する必要があります。このエンタープライズ・デプロイメント・ガイドでは、SOA Suiteは同じWebLogic Serverドメインにインストールおよび構成され、Web層、SSOおよびディレクトリ構成に組み込まれます。

必要に応じて、SOA Suiteを別のWebLogic Serverドメインにデプロイできますが、Portalワークフローの統合タスク・フローが正しく機能するには、共有されるWeb層、SSOおよびアイデンティティ・ストアの要件を満たす必要があります。

Oracle BPM Worklistの機能の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の「Oracle BPM Worklistの使用」を参照してください。

WebCenter PortalでWebCenter Portalワークフローの機能を有効にするために実行する必要があるタスクは次のとおりです。

注意:
BPMプロセス・ポータル・リソース・カタログを使用してBPM機能をポータル・ページに統合するには、このガイドに記載されていない追加手順が必要です。詳細は、BPM機能のWebCenter Portalへの統合に関する項を参照してください。

- インストールのバックアップ
再構成してPortalワークフローのSOA Suiteとの統合を組み込む前に、環境をバックアップします。

- Oracle SOA Suiteのインストール

- Oracle WebCenter Portal SOAコンポジットのインストール
WebCenter Portalでワークフローを使用するには、SOA Suiteのインストール後にポータル・インストーラを使用してWebCenter Portal SOAコンポジットをインストールする必要があります。

- WebCenter Portalワークフローをデプロイするためのドメインの拡張
WebCenter Portalワークフローは、Oracle SOAクラスタにデプロイされます。Oracle SOAがインストールされているドメインをテンプレートoracle.wc_composite_template.jarで拡張する必要があります。

- ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

- ドメイン解凍後のsetDomainEnv.shへのカスタマイズのリストア
すでにASERVER_HOMEおよびMSERVER_HOME内のsetDomainEnv.shファイルにカスタマイズを加えていた場合、このようなカスタマイズはドメイン拡張後に再度行う必要があります。

- ドメイン解凍後のNodeManager構成の更新
ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。

- ドメインの起動およびWebCenter Portal SOAコンポジットのためのドメイン拡張の検証
ドメイン全体を起動し、Enterprise Managerを使用してPortal SOAコンポジットおよびWebCenterワークリスト詳細アプリケーションのデプロイメントを検証します。

- Oracle SOAおよびWebCenter PortalのためのWS-Securityの構成
Oracle WebCenter PortalにデプロイされるWebCenter Portal Webサービスにより、WebCenter PortalとSOAサーバー間の通信が容易になります。このWebサービスのコールを保護する必要があります。

- アプリケーション・ロールの確認
SOA Suiteを含めてWebCenter Portalを構成する前に、SOAAdminおよびBPMWorkflowAdminのアプリケーション・ロールを理解して確認します。

- BPELサーバーへの接続の作成
WebCenter Portalでは、BPELサーバーを使用して内部ワークフロー(ワークリスト、メンバーシップ通知、サブスクリプション・リクエストなど)をホストします。BPELサービスは、SOA管理対象サーバーで構成されます。WebCenter Portalのワークフロー機能を有効にするには、BPELサービスへの接続が必要です。

- BPELサーバーへの接続の検証
BPELサーバーへの接続を作成したら、その接続を検証して正しく機能していることを確認します。

- 電子メールで送信するためのWebCenter Portalワークフロー通知の構成
WebCenter Portalでは、SOAワークフローと統合されるヒューマン・ワークフロー(人間による操作が必要)を使用できます。SOAサーバーは電子メールを構成し、通知をユーザーの受信箱に配信できます。ユーザーは通知を承認または却下できます。

- WebCenter PortalでのOracle BPM Worklistアプリケーションのテスト
WebCenter Portalの招待およびメンバーシップのワークフローと電子メール通知のテストは、エンドユーザー・アカウントを使用して実行でき、テスト・ケースを設定するために特定のポータル・ランタイム構成が必要です。

上位トピック: 「エンタープライズ・ドメインの構成」

16.1 インストールのバックアップ

再構成してPortalワークフローのSOA Suiteとの統合を組み込む前に、環境をバックアップします。

これは、この章の実行中に問題が発生した場合に即時リストアするという特別な目的のクイック・バックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。

環境をバックアップする手順は次のとおりです。

1. 管理対象サーバー、管理サーバー、ノード・マネージャの順にドメイン・リソースを停止します。

2. データベースをバックアップします。データベースの全体バックアップ(ホットまたはコールド)をお薦めします。

3. この章のトラブルシューティングに役立つように、また(必要に応じて)バックアップ・サイズを減らすためにWebLogic Serverのログを消去します。

cd ASERVER_HOME
find ./servers/AdminServer/logs -type f ! -size 0c -print -exec rm -f {} \+
cd MSERVER_HOME
find ./servers/*/logs -type f ! -size 0c -print -exec rm -f {} \+

4. 管理サーバーのドメイン・ディレクトリをバックアップします。

cd ASERVER_HOME
cd ..
tar -czf ./ASVR-domain_name.chapter16.1.tgz ./domain_name

5. アプリケーション・ディレクトリをバックアップします。

cd APPLICATION_HOME
cd ..
tar -czf ./APP-domain_name.chapter16.1.tgz ./domain_name

6. ASERVER_HOMEおよびMSERVER_HOMEのノード・マネージャを再起動します。

cd ASERVER_HOME/bin
nohup ./startNodeManager.sh > ASERVER_HOME/nodemanager/nodemanager.out 2>&1 &
cd MSERVER_HOME/bin
nohup ./startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

16.2 Oracle SOA Suiteのインストール

ワークフローをサポートする場合、WebCenter PortalはBPELサーバー(Oracle SOA Suiteに付属)を必要とします。Oracle SOA Suiteをこのドメインの一部としてインストールする方法の詳細は、「Oracle SOA Suiteを含めるドメインの拡張」を参照してください。

16.3 Oracle WebCenter Portal SOAコンポジットのインストール

WebCenter Portalでワークフローを使用するには、SOA Suiteのインストール後にポータル・インストーラを使用してWebCenter Portal SOAコンポジットをインストールする必要があります。

初期インストール時に、「Oracle WebCenter Portalを含めるドメインの拡張」には、Portal SOAコンポジットを選択するオプションが記載されていました。このオプションを選択した場合は、この項をスキップして「WebCenter Portalワークフローをデプロイするためのドメインの拡張」に進みます。

WebCenter Portal SOAコンポジットのインストール手順:

1. 共有ORACLE_HOMEごとに再度WebCenter Portalインストーラを実行し、「インストール・タイプ」に「WebCenter Portal SOAコンポジット」を選択します。

2. WebCenter Portalコンポジット・アーカイブがインストールされたことを確認します。

- WCCHOST1でのOracle WebCenter Portalインストーラの起動

- インストール画面への移動

- インストールしたファイルの確認

- WCCHOST2でのインストールの実行

16.3.1 WCCHOST1でのOracle WebCenter Portalインストーラの起動

インストール・プログラムを起動する手順は次のとおりです。

1. WCCHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. 次の例に示すとおり、ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行し、インストール・プログラムを起動します。

JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.2.0_wcportal_generic.jar

これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

ソフトウェアをダウンロードして製品の実際のインストーラ・ファイル名を見つける方法の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。

16.3.2 インストール画面への移動

インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。

インストール画面に関して詳細な情報が必要な場合は、画面名をクリックしてください。

画面

説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索するか、組織のためにすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストール場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

WebCenter PortalのSOAコンポジットをインストールするには、次を選択します。

- WebCenter Portal SOAコンポジット

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、次のいずれかのドキュメントのOracle Fusion Middleware Infrastructureのインストール計画のシステム環境の検証ロードマップに関する項を参照してください。

セキュリティ更新

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所持していないときに、この手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、その選択を後続のダイアログ・ボックスで確認します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを確認します。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

16.3.3 インストールしたファイルの確認

インストールが完了したら、WebCenter Portal SOAコンポジットおよびワークリスト詳細アプリケーションのアーカイブが、次のようにORACLE_HOME内の正しいディレクトリ構造に書き込まれていることを確認します。

ls ORACLE_HOME/wcportal/common/soa-composite/wcp/sca_CommunityWorkflows.jar
ls ORACLE_HOME/wcportal/webcenter/applications/WebCenterWorklistDetailApp.ear

注意:
12.2.1.0.0一般公開リリースでは、デプロイ・パスにタイポがあります。ディレクトリ・パスおよびファイル名を注意深く確認してください。

16.3.4 WCCHOST2でのインストールの実行

固有のORACLE_HOMEが格納されている共有ファイル・システムごとにもう一度インストールを繰り返す必要があります。「エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー」を参照してください。

16.4 WebCenter Portalワークフローをデプロイするためのドメインの拡張

WebCenter Portalワークフローは、Oracle SOAクラスタにデプロイされます。Oracle SOAがインストールされているドメインをテンプレートoracle.wc_composite_template.jarで拡張する必要があります。

構成ウィザードを実行する際に、ドメインのAdminServerと、選択したコンポーネント/テンプレートによって変更される管理対象サーバーを停止する必要があります。その他の影響を受けない管理対象サーバーはすべて実行中のままでもかまいません。
その場合、WSM-PM_Clusterを除くすべてのクラスタがこのドメイン拡張によって変更されます。この項では、WSM-PM_Cluster内の管理対象サーバーを含め、すべての管理対象サーバーを停止することをお薦めします。これにより、後で停止して再起動する必要がなくなります。

ドメインを拡張する手順は次のとおりです。

1. EM、WLSコンソールまたはWLSTから、すべての管理対象サーバーを停止します。

2. 拡張するドメインのAdminServerを停止します。

3. 次のコマンドを実行して構成ウィザードを起動します。

ORACLE_HOME/oracle_common/common/bin/config.sh

4. 「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

/u01/oracle/config/domains/domain_name/

5. 「テンプレート」画面で、次のいずれかの方法でテンプレートを選択します。

- 「製品テンプレートを使用してドメインを更新」を選択し、次を選択します。
Oracle WebCenter Portal Composites - 12.2.1.2.0 [wcportal]

- 「カスタム・テンプレートを使用してドメインを更新」を選択して次のパスを「テンプレートの場所」フィールドに指定します。
ORACLE_HOME/wcportal/common/templates/wls/oracle.wc_composite_template.jar

oracle.wc_composite_template.jarテンプレートにより、次のものが自動的にデプロイされます。

- 招待やメッセージを表示するADFアプリケーション、WebCenterWorklistDetailApp.ear。

- WebCenter Portalのメンバーシップ・メカニズムを管理するBPELコンポジット、sca_CommunityWorkflows.jar。

6. 確認して「次へ」をクリックし、「拡張構成」ビューが表示されるまで最初のいくつかの画面を進みます。

7. 「拡張構成」画面で、「デプロイメントとサービス」を選択し、「次へ」をクリックします。

8. デプロイメント・ターゲット指定。

Oracle Web Services Manager Policy Managerが別のクラスタにデプロイされている場合、ポータル、コラボレーション、ポートレット、Inbound Refinery、コンテンツおよびSOAクラスタに対するWSM-PMアプリケーションのデフォルトのターゲット指定を削除する必要があります。

「ターゲット」パネルのPortal_Cluster、Collab_Cluster、Portlet_ClusterおよびSOA_Clusterのそれぞれについて、「アプリケーション」フォルダ内のwsm-pmアプリケーション・エントリを選択し、左矢印をクリックしてターゲット・リストから削除します。

注意:
SOAクラスタの作成時にSOA-MGD-SERVERS-ONLYサーバー・グループを使用した場合、wsm-pmアプリケーションはデフォルトでターゲット指定されません。その場合、SOA_Clusterには、削除するwsm-pmデプロイメントがありません。

9. サービス・ターゲット指定。

Oracle Web Services Manager Policy Managerが別のクラスタにデプロイされている場合、ポータル、コラボレーション、ポートレット、Inbound Refinery、コンテンツおよびSOAクラスタに対するWSM-PMサービス・リソースのデフォルトのターゲット指定を削除する必要があります。

「ターゲット」パネルのPortal_Cluster、Collab_Cluster、Portlet_ClusterおよびSOA_Clusterのそれぞれについて、次のリソースを選択してターゲット・リストから削除します。

- mds-owsm

- WSM起動クラス

10. 構成の指定内容の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更する必要がある場合、「戻る」をクリックするか、目的の画面をナビゲーション・ペインで選択して、前の画面に戻ることができます。

「更新」をクリックして、ドメインの拡張を実行します。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

11. 管理サーバーを起動します。

管理サーバーを起動してログインし、クラスタ・ビューとサーバー・ビューを確認して、ドメインに対する変更が適用されていることを確認します。

16.5 ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

ドメイン構成を伝播するには、次の手順を実行します。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=/full_path/wcpdomaintemplateExtComposites.jar
-template_name=wcp_domain_template_extension_composites

この例では、次のとおりです。

- ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

- full_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートjarファイルをコピーまたは解凍する場合は、この場所を参照する必要があります。ORACLE_HOME以外の共有ボリュームを選択するか、/tmp/に書き込み、そのファイルをサーバー間で手動でコピーすることをお薦めします。
テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。

SHARED_CONFIG_DIR/domains/template_filename.jar

- wcpdomaintemplateExtComposites.jarは、作成するJARファイルのサンプル名です。これには、Oracle HTTP Serverインスタンスの構成ファイルなどのドメイン構成ファイルが含まれます。

- wcp_domain_template_extension_compositesは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

3. 次のunpackコマンドをWCCHOST1で実行して、前の手順で作成したテンプレートをMSERVER_HOMEディレクトリに伝播します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-template=/full_path/wcpdomaintemplateExtComposites.jar
-app_dir=APPLICATION_HOME
-overwrite_domain=true

この例では、次のとおりです。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- wcpdomaintemplateExtComposites.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

- 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。
上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

- APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

4. パック済のJARファイルへのフルパスが他のサーバーで使用可能な共有ボリューム上にある場合は、この手順をスキップし、それ以外の場合は、次のコマンドをWCCHOST1で実行し、手順1で作成したテンプレート・パックをWCCHOST2、WCPHOST1およびWCPHOST2にコピーします。

scp /full_path/wcpdomaintemplateExtComposites.jar oracle@WCCHOST2:/full_path/
scp /full_path/wcpdomaintemplateExtComposites.jar oracle@WCPHOST1:/full_path/
scp /full_path/wcpdomaintemplateExtComposites.jar oracle@WCPHOST2:/full_path/

5. 次のunpackコマンドを各リモート・ホストで実行して、前の手順でコピーしたドメイン・テンプレートをMSERVER_HOMEディレクトリにデプロイします。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-template=/full_path/wcpdomaintemplateExtComposites.jar
-app_dir=APPLICATION_HOME
-overwrite_domain=true

この例では、次のとおりです。

- MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

- wcpdomaintemplateExtComposites.jarは、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。

- 管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍する場合は、-overwrite_domain=true引数が必要です。
上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

- APPLICATION_HOMEを、ローカル記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。

ヒント:

packおよびunpackコマンドの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成のPackおよびUnpackコマンドの概要に関する項を参照してください。

16.6 ドメイン解凍後のsetDomainEnv.shへのカスタマイズのリストア

すでにASERVER_HOMEおよびMSERVER_HOME内のsetDomainEnv.shファイルにカスタマイズを加えていた場合、このようなカスタマイズはドメイン拡張後に再度行う必要があります。

NodeManagerまたはWebLogic Serverインスタンスの起動前に、カスタマイズがすべてリストアされていることを確認します。
WCPHOST1の場合:

1. ASERVER_HOME/bin/setDomainEnv.shを確認して更新します。

2. MSERVER_HOME/bin/setDomainEnv.shを確認して更新します。

3. MSERVER_HOME/bin/setDomainEnv.shを他のホスト(WCPHOST2、WCCHOST1、WCCHOST2など)にコピーします。

注意:
ASERVER_HOMEおよびMSERVER_HOMEのsetDomainEnv.sh構成ファイルに格納されているパラメータ値には、固有差があります。同じファイルを両方の場所にコピーすることはできないため、別々に編集する必要があります。MSERVER_HOME/bin/setDomainEnv.shは、環境全体で変らずコピーできます。

16.7 ドメイン解凍後のNodeManager構成の更新

ドメインの拡張時に、MSERVER_HOMEのnodemanager.propertiesファイルがASERVER_HOMEのnodemanager.propertiesファイルの一部の値で上書きされることがあります。具体的には、ListenAddressまたはCustomIdentityAlias (あるいはその両方)の値がリセットされる場合があります。

注意:

- ListenAddressは通常、ASERVER_HOME nodemanagerと同じホストに常駐するMSERVER_HOME nodemanager上でリセットされます。このトポロジでは、WCCHOST1です。

- SOAサーバーとハードウェア・ロード・バランサ間のSSL通信を有効にする前のドメイン拡張では、CustomIdentityAliasに関して手順2から4は当てはまらないことがあります。

各ホストのMSERVER_HOME/nodemanager/nodemanager.propertiesファイルについて、次のことを実行します。

1. 正しいListenAddressパラメータ値を確認して、必要な場合は値を再設定します。

grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties

2. 次のコマンドの参照として、ドメイン構成ファイルから構成済アイデンティティ別名のリストを確認します。

grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq

3. 現在のCustomIdentityAliasパラメータ値を確認します。

grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties

4. 必要に応じて、CustomIdentityAliasパラメータ値を、現在のホストに適した正しい別名文字列に再設定します。

5. nodemanagerプロセスを再起動します。

kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

詳細は、「カスタム・キーストアを使用するためのノード・マネージャの構成」を参照してください。

16.8 ドメインの起動およびWebCenter Portal SOAコンポジットのためのドメイン拡張の検証

ドメイン全体を起動し、Enterprise Managerを使用してPortal SOAコンポジットおよびWebCenterワークリスト詳細アプリケーションのデプロイメントを検証します。

- ノード・マネージャを使用した管理サーバーの起動
ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。

- すべての管理対象サーバーの起動と稼働の確認
直近のドメイン拡張で作成または変更した管理対象サーバーを今度は起動する必要があります。ドメイン拡張時に稼働したままだった管理対象サーバーが稼働していることを確認する必要があります。

- WebCenter Portal SOAコンポジットのデプロイメントの確認

16.8.1 ノード・マネージャを使用した管理サーバーの起動

ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。

ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。

1. WebLogic Scripting Tool (WLST)を起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

2. ノード・マネージャ資格証明を使用してノード・マネージャに接続します。

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
'ADMINVHN','5556','domain_name',
'ASERVER_HOME')

注意:

このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理者IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

ASERVER_HOME/config/nodemanager

3. 管理サーバーを起動します。

nmStart('AdminServer')

注意:

管理サーバーを起動すると、WebServicesポリシーを取得するためにOracle Web Services Managerに接続しようとします。WSM-PM管理対象サーバーはまだ起動されていないため、次のメッセージが管理サーバー・ログに出力されます。

<Warning><oracle.wsm.resources.policymanager>
<WSM-02141><Unable to connect to the policy access service due to Oracle WSM policy manager host server being down.>

4. WLSTを終了します。

exit()

16.8.2 すべての管理対象サーバーの起動と稼働の確認

直近のドメイン拡張で作成または変更した管理対象サーバーを今度は起動する必要があります。ドメイン拡張時に稼働したままだった管理対象サーバーが稼働していることを確認する必要があります。

表16-1 管理対象サーバー

クラスタ

管理対象サーバー

初期状態

操作

WSM-PM_Cluster

WLS_WSMn

SHUTDOWN

すべての管理対象サーバーを起動して確認します。

SOA_Cluster

WLS_SOAn

SHUTDOWN

すべての管理対象サーバーを起動して確認します。

IBR_Servers

WLS_IBRn

SHUTDOWN

すべての管理対象サーバーを起動して確認します。

WCC_Cluster

WLS_WCCn

SHUTDOWN

すべての管理対象サーバーを起動して確認します。

Portlet_Cluster

WC_Portletn

SHUTDOWN

すべての管理対象サーバーを起動して確認します。

Collab_Cluster

WC_Collaborationn

SHUTDOWN

すべての管理対象サーバーを起動して確認します。

Portal_Cluster

WC_Portaln

SHUTDOWN

すべての管理対象サーバーを起動して確認します。

16.8.3 WebCenter Portal SOAコンポジットのデプロイメントの確認

WebCenter Portal SOAコンポジットを含めてドメインを拡張すると、2つのデプロイメントが追加されます。これらには、エンタープライズ・アプリケーション・アーカイブとSOAコンポジット・アーカイブが1つずつ含まれます。これらのリソースは、このドメイン拡張を続行する前に、正常にデプロイして検証する必要があります。SOAコンポジットは、ワークフローに含まれるヒューマン・タスクのアプリケーションに依存します。それらは、異なるプロセスを使用して別々にデプロイされます。

- WebCenterWorklistDetailApp.ear - ORACLE_HOME/wcportal/webcenter/applicationsにある標準のJava EE Webアプリケーション

- sca_CommunityWorkflows.jar - ORACLE_HOME/wcportal/common/soa-composite/wcpにあるSOAコンポジット

この項では、検証プロセスとデプロイメント・プロセスの両方について説明します。

- WebCenter Portal SOAコンポジットおよびアプリケーションのデプロイメントの確認

- SOA_ClusterへのWebCenterWorklistDetailAppアプリケーションのデプロイ

- SOAサービスへのCommunityWorkflows SOAコンポジットのデプロイ

16.8.3.1 WebCenter Portal SOAコンポジットおよびアプリケーションのデプロイメントの確認

WebCenterWorklistDetailApp.earアプリケーション・デプロイメントを検証する手順は次のとおりです。

1. weblogic_wcp管理ユーザーとしてEnterprise Managerに接続します。

2. WebCenterWorklistDetailAppアプリケーションが「ターゲット・ナビゲーション」→「アプリケーション・デプロイメント」に表示されていることを確認します。アプリケーション・リンクが表示されていない場合は、「SOA_ClusterへのWebCenterWorklistDetailAppアプリケーションのデプロイ」を参照してください。

3. WebCenterWorklistDetailAppアプリケーションが表示されている場合は、リンクをクリックして「サマリー」ビューで「状態」に「アクティブ」と表示され、「状態」が「OK」であることを確認します。また、SOA_Clusterが「デプロイメント」ビューの「ターゲット」列に表示されていることを確認します。
WebCenterWorklistDetailAppで「ターゲット」列にSOA_Clusterが表示されていない場合は、次の手順を実行します。

a. 「ドメイン・アプリケーション・デプロイメント」ドロップダウン・メニューから、「管理」→「ターゲット」の順に選択します。

b. 右上隅のロック・アイコンから、「ロックして編集」を選択します。

c. 「WebCenterWorklistDetailApp EAR」を選択して、「ターゲットの変更」をクリックします。

d. ポップアップ・ウィンドウで、「SOA_Cluster」を選択してから「このクラスタ内のすべての構成済サーバー」オプションを選択します。

e. 「OK」をクリックします。変更が完了したら、確認メッセージが表示されます。

f. 情報パネルに次のメッセージが表示された場合は、「新規デプロイメント・プランの作成」をクリックします。
情報: 構成変更はデプロイメント・プランに保存されます。このアプリケーションには現在デプロイメント・プランがありません。構成変更を保存するために、まずこのアプリケーションの新規デプロイメント・プランを作成する必要があります。

g. 別のコマンド・シェルで、DEPLOY_PLAN_HOMEフォルダにWebCenterWorklistDetailAppの共有デプロイメント・プラン・フォルダを作成します。「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。
mkdir -p DEPLOY_PLAN_HOME/WebCenterWorklistDetailApp

h. 「デプロイ・プランの保存」ダイアログで、新しいアプリケーション固有のデプロイメント・プラン・フォルダのフルパスとファイル名plan.xmlを入力するか、参照します。
/u01/oracle/config/dp/WebCenterWorklistDetailApp/plan.xml

i. 「デプロイ・プランの保存」ボタンをクリックします。

j. 右上隅のロック・アイコンから、「変更のアクティブ化」を選択します。

注意:
「変更のアクティブ化」が選択できない場合、ロック・アイコンの真下にある日付の横のリロード・アイコンをクリックします。

k. SOA_Cluster内の管理対象サーバーを再起動します。

4. 「ターゲット・ナビゲーション」パネルを開き、「WebLogicドメイン」→「domain-name」→「SOA_Cluster」に移動します。

5. 「WebLogicクラスタ」ドロップダウン・メニューから「デプロイメント」を選択します。

6. WebCenterWorklistDetailAppが緑の上向き矢印ステータスと「アクティブ」状態とともに表示されていることを確認します。
WebCenterWorklistDetailAppがSOA_Clusterにデプロイされていない場合、すべての検証手順の完了後にデプロイメントを実行します。「SOA_ClusterへのWebCenterWorklistDetailAppアプリケーションのデプロイ」を参照してください。

sca_CommunityWorkflows.jar SOAコンポジット・デプロイメントを検証する手順は次のとおりです。

1. 「ターゲット・ナビゲーション」パネルを開き、「SOA」→「soa-infra (WLS_SOA1)」サービスに移動します。

2. 「デプロイ済コンポジット」タブをクリックします。

3. CommunitWorkflows [12.2.1.2.0]コンポジットが緑の上向き矢印のステータスとともに表示されていることを確認します。
「SOAサービスへのCommunityWorkflows SOAコンポジットのデプロイ」を参照してください。

16.8.3.2 SOA_ClusterへのWebCenterWorklistDetailAppアプリケーションのデプロイ

WebCenterWorklistDetailAppアプリケーションをデプロイする必要がある場合は、次の手順を実行します。

1. weblogic_wcp管理ユーザーとしてEnterprise Managerに接続します。

2. 「ターゲット・ナビゲーション」パネルを開き、「WebLogicドメイン」→「domain-name」→「SOA_Cluster」に移動します。

3. 「WebLogicクラスタ」ドロップダウン・メニューから「デプロイメント」を選択します。

4. WebCenterWorklistDetailAppが表示されていないことを確認します。

5. 「デプロイメント」ドロップダウン・メニューから「デプロイ」を選択します。

6. 適切なデプロイメント・スコープを選択します。追加設定なしの構成の場合、適切なスコープはglobalです。

7. 「Enterprise Managerが稼働しているサーバーのアーカイブ。」を選択します。

8. ORACLE_HOME/wcportal/webcenter/applications/WebCenterWorklistDetailApp.earと入力します。

9. 「デプロイ構成が行われるとき、新規デプロイ・プランを作成します。」を選択します。

10. 「このアーカイブまたは展開済ディレクトリをアプリケーションとしてデプロイします」を選択します。

11. 「次へ」をクリックします。

12. 「ターゲットの選択」ビューで、「SOA_Cluster」のみが選択され、「このクラスタ内のすべての構成済サーバー」オプションが選択されていることを確認します。

13. 「アプリケーション属性」ビューで、配布オプションのみを「アプリケーションのインストールと起動(すべてのリクエストの処理)」に変更します。その他のアプリケーション属性は変更しないでください。

14. 「デプロイ」をクリックします。残りのアプリケーション・デプロイメント構成を変更する必要はありません。

15. 表示される「処理中: デプロイ」モーダル・ダイアログ・ボックスに示される進行状況のメッセージを監視し、完了するまで待ちます。

16. ダイアログ・ボックスが「正常にデプロイされました」メッセージで更新されるのを監視します。

17. ダイアログ・ボックスを閉じます。

18. 新しいアプリケーション・デプロイメントが緑の上向き矢印ステータスと「アクティブ」状態とともに表示されていることを確認します。

エンタープライズ・アプリケーション・アーカイブのデプロイ方法の詳細は、『Oracle Fusion Middlewareの管理』のFusion Middleware Controlを使用したJava EEアプリケーションのデプロイに関する項を参照してください。

16.8.3.3 SOAサービスへのCommunityWorkflows SOAコンポジットのデプロイ

CommunityWorkflows SOAコンポジットをデプロイする必要がある場合は、次の手順を実行します。

1. weblogic_wcp管理ユーザーとしてEnterprise Managerに接続します。

2. 「ターゲット・ナビゲーション」パネルを開き、「SOA」→「soa-infra (WLS_SOA1)」サービスに移動します。

3. 「デプロイ済コンポジット」タブをクリックします。

4. CommunityWorkflowsコンポジットが「稼働中」および「アクティブ」と表示されていることを確認します。表示されていない場合やリストに「コンポジットが見つかりません」と表示される場合は、このデプロイメント手順を続行します。ステータスが「停止中」の場合は、CommunityWorkflowsコンポジットを起動します。

5. 「デプロイ」をクリックします。

6. 「Enterprise Managerが稼働しているサーバーのアーカイブ。」を選択します。

7. ORACLE_HOME/wcportal/common/soa-composite/wcp/sca_CommunityWorkflows.jarと入力します。

8. 「外部構成プランは必要ありません。」を選択します。

9. 「次へ」をクリックします。

10. デプロイメント・ターゲットが/Domain_< domain_name >/< domain_name >/SOA_Clusterであることを確認します。

11. 適切なSOAフォルダを選択します。追加設定なしの構成の場合、選択する適切なフォルダはdefaultです。

12. 「次へ」をクリックします。

13. 今回初めてコンポジットをデプロイするため、「デフォルト・リビジョンとしてデプロイ」が選択されていることを確認します。

14. 「デプロイ」をクリックします。

15. 表示される「処理中: デプロイ」モーダル・ダイアログ・ボックスに示される進行状況のメッセージを監視し、完了するまで待ちます。

16. ダイアログ・ボックスが「正常にデプロイされました」メッセージで更新されるのを監視します。

17. ダイアログ・ボックスを閉じます。

18. 今度は、Enterprise ManagerにCommunityWorkflows[12.2.1.2.0] SOAコンポジットのダッシュボード・ビューがいくつかのコンポーネントおよびサービスとともに表示されていることを確認します。

コンポジットのデプロイ方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAコンポジット・アプリケーションのデプロイに関する項を参照してください。

16.9 Oracle SOAおよびWebCenter PortalのためのWS-Securityの構成

Oracle WebCenter PortalにデプロイされるWebCenter Portal Webサービスにより、WebCenter PortalとSOAサーバー間の通信が容易になります。このWebサービスのコールを保護する必要があります。

注意:
この構成で使用される主要な別名およびその他のプロパティ値の一部は、特にデプロイされる製品で必要となります。このプロセスは、同一ドメイン内のOracle SOAおよびWebCenter Portalと組み合せたトポロジ専用に調整されています。記載されている説明を超えてこのプロセスをカスタマイズしないでください。
2ドメイン・トポロジの構成の詳細は、『Oracle WebCenter Portalのインストールと構成』のOracle SOAとWebCenter Portal - WS-Security構成に関する項を参照してください。

使用するWebCenter PortalおよびSOA Suite BPEL Server用のセキュリティ・アプリケーション・ストライプとキーストアを作成して、WS-Securityを設定します。Oracle Fusion Middleware 12cでは、Enterprise ManagerまたはWLSTコマンドによって構成されたキーストア・セキュリティ・サービス(KSS)を使用してこのようなキーストアを実装します。

詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のメッセージ保護に関するキーストアの構成に関する項を参照してください。

KSSコマンドの構文情報および参照情報は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のOPSSキーストア・サービス・コマンドに関する項を参照してください。

- WLSTによるWebCenter Portalキーストアの作成

16.9.1 WLSTによるWebCenter Portalキーストアの作成

新しいWebCenter Portalキーストアを作成するには、次の手順を実行します。

1. WLSTを起動し、管理サーバーに管理LDAPユーザーとして接続します。

ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_wcp", "weblogic_admin_pwd", "t3://ADMINVHN:7001")

2. 次のWLSTコマンドを使用して、OPSSサービス・コマンド・オブジェクトを取得します。

svc = getOpssService(name='KeyStoreService')

3. 次のWLSTコマンドを使用して、キーストアを作成します。

svc.createKeyStore(appStripe='WCPortalStripe', name='producer', password='password', permission=true)

説明:

- appstripe - キーストア・ストライプ名。キーストア内に作成されたキーおよび証明書はアプリケーション・ストライプまたは製品内に存在し、ドメイン内の各ストライプには一意の名前が付けられます

- keystore_name - 作成しているキーストアの名前。通常、保護するコンポーネントまたはエンドポイントを特定しやすい名前を使用します。

- password - このキーストアに使用するパスワードを入力します。

- permission — 権限とパスワードの両方によって保護する場合はfalse (キーストアを権限のみで保護する場合はtrue)

4. 適切なパスワードを指定し、ドメイン名、組織、場所(市区町村)、都道府県および国を適切に設定して、この新規作成したキーストアの鍵ペアを生成します。

svc.generateKeyPair(appStripe='WCPortalStripe', name='producer', password='password', dn='CN=Producer, OU=WCPortalServices, OU=domain_name, O=MyOrganization, L=MyTown, ST=MyState, C=US', keysize='2048', alias='producer', keypassword='keypassword')

説明:

- appstripe - キーストア・ストライプ名。キーストア内に作成されたキーおよび証明書はアプリケーション・ストライプまたは製品内に存在し、ドメイン内の各ストライプには一意の名前が付けられます

- keystore_name - 作成しているキーストアの名前。通常、保護するコンポーネントまたはエンドポイントを特定しやすい名前を使用します。

- password - キーストアを作成したときに定義したパスワード。

- dn - 識別名。階層ネーミング構造内で鍵ペアを一意に識別したり、編成するのに使用されます。DNのOU=domain_name、O=MyOrg、L=MyTown、ST=MyState、C=USの各部分を更新し、環境および組織と適切に一致させます。

- keysize - 暗号化鍵のビット数。2048以上にする必要があります。

- alias - 公開鍵の別名

- keypassword - 作成している新しい公開鍵のパスワードを入力します。

5. プロデューサ証明書(コンシューマによって使用される)をエクスポートします。

svc.exportKeyStoreCertificate(appStripe='WCPortalStripe', name='producer', password='password', alias='producer', type='TrustedCertificate',filepath='KEYSTORE_HOME/ksscert_wcportalproducer.crt')

説明:

- appstripe - キーストア・ストライプ名。キーストア内に作成されたキーおよび証明書はアプリケーション・ストライプまたは製品内に存在し、ドメイン内の各ストライプには一意の名前が付けられます

- name - キーストア名

- password - キーストア・パスワード

- alias - 公開鍵の別名

- keypassword - 新しい公開鍵のパスワード

- filepath - 証明書パス

6. コンシューマWebサービスで使用するためにプロデューサによってエクスポートされた証明書をインポートします。

svc.importKeyStoreCertificate(appStripe='WCPortalStripe', name='producer', password='password', alias='webcenter_spaces_ws', keypassword='keypassword', type='TrustedCertificate', filepath='KEYSTORE_HOME/ksscert_wcportalproducer.crt')

説明:

- password - キーストア・パスワード

- keypassword - 新しい公開鍵のパスワード

- filepath - 証明書パス

注意:

importKeyStoreCertificateコマンドの別名は、常にwebcenter_spaces_wsに設定する必要があります。この別名を変更しないでください。変更すると、Webサービスの通信は失敗します。この別名は、Webサービスのポリシー・セキュリティのデフォルト構成で使用されます。

7. プロデューサ・ストライプを登録します。

configureWSMKeystore('/WLS/domain_name','KSS', 'kss://WCPortalStripe/producer', signAlias='producer', cryptAlias='producer', signAliasPassword='password', cryptAliasPassword='password')

説明:

- domain_name - WebCenter Portalドメインの名前。Web Services Managerのコンテキストを指定する場合、接頭辞"/WLS/"が必要です。

- KSS - キーストア・タイプ

- kss://WCPortalStripe/producer - キーストアの場所。キーストアで作成された鍵および証明書はアプリケーション・ストライプまたは製品にあり、ドメイン内の各ストライプには固有の名前が付けられています。

- signAlias - 署名鍵の別名。この値は、キーストアの値(この場合は'producer')に一致する必要があります。

- cryptAlias - 暗号化鍵の別名。ここで指定する値は、キーストアの値(この場合は'producer')に一致する必要があります。

- signAliasPassword - 前に構成したsignAliasに指定した証明書のパスワード

- cryptAliasPassword - 前に構成したcryptAliasに指定した証明書のパスワード

注意:
KSSキーストア・タイプを使用する場合、configureWSMKeystore()コマンドが、パスワードを必要としないことを示す警告を発行することがあります。この特殊なケースでは、サービスでメッセージ保護を要求するポリシーを使用している場合、パスワードは必須です。そうでないと、サービスでは証明書を使用して暗号化および復号化が適切にできません。例で示すように、必ずパスワードのパラメータを挿入してください。

詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWLSTを使用したOWSMキーストアの構成に関する項を参照してください。

8. WCPortalStripeストライプで新規作成されたproducerキーストアにキーストア権限を付与します。

grantPermission(permClass="oracle.security.jps.service.keystore.KeyStoreAccessPermission", permTarget="stripeName=WCPortalStripe,keystoreName=producer,alias=*", permActions="read")

注意:

permTarget値のStripeName値およびkeystoreName値は、これまでの手順で使用した値に一致する必要があります。このコマンドに、その他の変更は必要ありません。

16.10 アプリケーション・ロールの確認

SOA Suiteを含めてWebCenter Portalを構成する前に、SOAAdminおよびBPMWorkflowAdminのアプリケーション・ロールを理解して確認します。

次のように、SOAAdminおよびBPMWorkflowAdminアプリケーション・ロールのメンバーシップをリストできます。

ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('weblogic_wcp','password', 't3://ADMINVHN:7001')
listAppRoleMembers(appStripe="soa-infra", appRoleName="SOAAdmin")
listAppRoleMembers(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin")

アプリケーション・ロールからユーザーまたはグループのメンバーシップを取り消すには、次のWLSTの例を検討してください。

revokeAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="weblogic.security.principal.WLSUserImpl", principalName="weblogic")
revokeAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="weblogic.security.principal.WLSGroupImpl", principalName="Administrators")

特にユーザー・メンバーシップをアプリケーション・ロールに付与するには、次の例に従います。

grantAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="weblogic.security.principal.WLSUserImpl", principalName="weblogic_wcp")

エンタープライズ・デプロイメント環境でのLDAPグループの構成では、weblogic_wcpユーザー固有のアクセス権を付与する必要はありません。WCPAdministratorsグループは、すでにSOAAdminアプリケーション・ロールの一部であり、メンバーシップをBPMWorkflowAdminアプリケーション・ロールに継承しています。

エンタープライズ・デプロイメント用にリモートLDAPサーバーを構成する方法の詳細は、「新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング」を参照してください。

SOAアプリケーション・ロールの構成の詳細は、「エンタープライズ・デプロイメントの管理用のロールの構成」を参照してください。

16.11 BPELサーバーへの接続の作成

WebCenter Portalでは、BPELサーバーを使用して内部ワークフロー(ワークリスト、メンバーシップ通知、サブスクリプション・リクエストなど)をホストします。BPELサービスは、SOA管理対象サーバーで構成されます。WebCenter Portalのワークフロー機能を有効にするには、BPELサービスへの接続が必要です。

注意:

WebCenter Portalワークフローは、WebCenter Portalを使用するように構成されたSOA管理対象サーバーにデプロイする必要があります。『Oracle WebCenter Portalのインストールおよび構成』のWebCenter Portalワークフローのバックエンド要件に関する項も参照してください。

ワークリストの通知用接続を構成する手順は次のとおりです。

1. Fusion Middleware Control,にログインし、WebCenter Portalのホームページに移動します。

『Oracle WebCenter Portalの管理』のWebCenter Portalのホームページへの移動に関する項を参照してください。

2. 「WebCenterポータル」メニューで、「設定」、「アプリケーション構成」の順に選択します。

3. BPEL SOAP URLフィールドで、ロード・バランシングされた内部URLを指定します。

次に例を示します。

http://wcp-internal.example.com:80

4. 「リンクURL」フィールドで、環境のロード・バランシングされたパブリック・フロントエンドURLを指定します。

次に例を示します。

https://wcp.example.com:443

5. 「WebCenterポータル・ワークフローの有効化」を選択します。

6. 「適用」をクリックします。

7. Portal_Clusterを再起動して、この変更を有効にします。

『Oracle WebCenter Portalの管理』のWebCenter Portalアプリケーション・デプロイメントのための管理対象サーバーの起動および停止に関する項を参照してください。

16.12 BPELサーバーへの接続の検証

BPELサーバーへの接続を作成したら、その接続を検証して正しく機能していることを確認します。

WLSTコマンドlistWorklistConnectionsを使用して、構成した接続を表示して接続の詳細を検証してください。

getSpacesWorkflowConnectionName()を使用してアクティブなワークフロー接続の名前を確認します。

次に例を示します。

listWorklistConnections(appName='webcenter', server='WC_Portal1', verbose=1)
getSpacesWorkflowConnectionName(appName='webcenter', server='WC_Portal1')

表示されたURLプロパティ値を使用して有効なワークリスト・アプリケーションURLを構築し、ブラウザを使用してアクセスを検証します。表示されたURLプロパティ値の末尾にパス/integration/worklistappを追加し、テストに適したURLを生成します。

16.13 電子メールで送信するためのWebCenter Portalワークフロー通知の構成

WebCenter Portalでは、SOAワークフローと統合されるヒューマン・ワークフロー(人間による操作が必要)を使用できます。SOAサーバーは電子メールを構成し、通知をユーザーの受信箱に配信できます。ユーザーは通知を承認または却下できます。

このトピックでは、電子メール通知を有効にし、メール・サーバー詳細を設定することで、WebCenter Portalワークフロー通知を電子メールによって送信する方法について簡単に説明します。フル機能には、発信と着信の両方の電子メール・アドレスまたはポータル・ワークフロー通知専用で処理に応じるメールボックスが必要です。説明の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のヒューマン・ワークフロー通知プロパティの構成に関する項を参照してください。

1. weblogic_wcp管理ユーザーとしてEnterprise Manager Fusion Middleware Controlに接続します。

2. 「ターゲット・ナビゲーション」パネルを開き、「SOA」→「soa-infra (WLS_SOA1)」サービスに移動します。

3. 「SOAインフラストラクチャ」ドロップダウン・メニューから、「SOA管理」→「ワークフロー・プロパティ」の順に選択します。

4. 「通知モード」を「電子メール」に設定します。

5. 「通知サービス」に正しい電子メール・アドレスを指定します。

6. 「適用」をクリックし、求められたら確認します。変更が適用されたことを確認する戻りメッセージを確認します。

7. 「「メッセージング・ドライバ」ページに移動」リンクをクリックします。

8. 「関連ドライバ」セクションで、「ユーザー・メッセージング電子メール・ドライバ」の「ドライバの構成」アイコンをクリックします。

9. 電子メール・ドライバがまだ存在しない場合は、「作成」をクリックして構成します。

通知用の電子メール・ドライバを構成する方法の詳細は、『Oracle Managed File Transferの使用』の通知のための電子メール・ドライバの構成に関する項を参照してください。

10. 必要な電子メール・ドライバの構成がすべて完了したら、「テスト」をクリックして、「成功」テスト・ステータスを確認します。

11. 「適用」をクリックして電子メール・ドライバ構成を保存します。

12. 新しいUMSドライバ構成が「電子メール・ドライバ・プロパティ」表ビューに表示されていることを確認します。

13. SOAクラスタを再起動します。WebCenter Portalの場合、構成または再起動は不要です。

16.14 WebCenter PortalでのOracle BPM Worklistアプリケーションのテスト

WebCenter Portalの招待およびメンバーシップのワークフローと電子メール通知のテストは、エンドユーザー・アカウントを使用して実行でき、テスト・ケースを設定するために特定のポータル・ランタイム構成が必要です。

追加のログイン・プロンプトが表示されないようにWebCenter PortalからBPELワークリスト・タスクの詳細にアクセスするには、WebCenter PortalサーバーとOracle SOA SuiteサーバーでOracle Single Sign-Onサーバーを共有するように構成する必要があります。このテストは、「エンタープライズ・デプロイメント用のシングル・サインオンの構成」の手順を完了すると、さらに簡単に検証できます。

詳細は、『Oracle WebCenter Portalの管理』のWebCenter Portalワークフローの構成ロードマップのタスク7を参照してください。

第IV部 エンタープライズ・デプロイメントの共通の構成および管理手順

標準的なエンタープライズ・デプロイメントに推奨される、特定の構成および管理手順があります。

次のトピックでは、標準的なエンタープライズ・デプロイメントに必要な構成および管理手順について説明します。

- エンタープライズ・デプロイメントの共通の構成および管理手順
この項では、エンタープライズ・デプロイメント環境で実行する必要性が見込まれる構成および管理タスクについて説明します。

- エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用
Oracle WebLogic Serverの移行フレームワークは、サーバー全体の移行とサービスの移行をサポートしています。次の各項では、Oracle Fusion Middlewareエンタープライズ・トポロジでのこれらの機能の使用方法について説明します。

- エンタープライズ・デプロイメント用のシングル・サインオンの構成
Oracle Access Managerを使用してシングル・サインオンを有効にするには、Oracle HTTP Server WebGateを構成する必要があります。

17 エンタープライズ・デプロイメントの共通の構成および管理タスク

この項では、エンタープライズ・デプロイメント環境で実行する必要性が見込まれる構成および管理タスクについて説明します。

- 管理サーバーの手動フェイルオーバーの確認
ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。次の各項で、WCCHOST1およびWCCHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する手順について説明します。

- 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化
中間層とハードウェア・ロード・バランサ間のSSL通信を有効化する方法を理解することは重要です。

- エンタープライズ・デプロイメントの管理用のロールの構成
単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理するには、特定の管理ロールまたはグループを必要とする製品を理解することに加え、製品固有の管理ロールをエンタープライズ・デプロイメント管理グループに追加する方法を理解することが必要です。

- エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用
この項では、トランザクション・ログ(TLOG)およびJMSにJDBC永続ストアを使用する方法のガイドライン、およびサポートされているデータベースで永続ストアを構成する手順について説明します。

- エンタープライズ・デプロイメントのバックアップとリカバリの実行
Oracle WebCenter Portalエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするために、次に示すガイドラインに従うことをお薦めします。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

17.1 管理サーバーの手動フェイルオーバーの確認

ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のホストにフェイルオーバーできます。次の各項で、WCCHOST1およびWCCHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する手順について説明します。

前提条件:

- 管理サーバーを、localhostまたは任意のアドレスではなく、ADMINVHN上でリスニングするように構成します。
ADMINVHN仮想IPアドレスの詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

- この手順では、管理サーバーのドメイン・ホーム(ASERVER_HOME)が両方のホスト・コンピュータにマウントされていることを前提にしています。これにより、管理サーバーのドメイン構成ファイルと永続ストアが、共有記憶域デバイスに保存されるようになります。

- 管理サーバーはWCCHOST1からWCCHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。

- WCCHOST1: 100.200.140.165

- WCCHOST2: 100.200.140.205

- ADMINVHN: 100.200.140.206。これは管理サーバーを実行している仮想IPであり、仮想サブインタフェース(eth0:1など)に割り当てられており、WCCHOST1またはWCCHOST2からアクセスできます。

- Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、WCPHOST2にインストールされています。
具体的には、両方のホスト・コンピュータは、まったく同じパスを使用してOracleホームのバイナリ・ファイルを参照します。

ここでは、管理サーバーのフェイルオーバー手順のテストを実行する方法を詳しく説明します。

- 別のホストへの管理サーバーのフェイルオーバー
次の手順は、管理サーバーを異なるノード(WCCHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。

- Oracle HTTP Serverを介したWCCHOST2上の管理サーバーへのアクセスの検証
管理サーバーの手動フェイルオーバーを実行したら、標準管理URLを使用して管理サーバーにアクセスできることを確認することが重要です。

- WCCHOST1への管理サーバーのフェイルバック
手動管理サーバーフェイルオーバーをテストし、フェイルオーバー後に管理URLにアクセスできることを検証したら、管理サーバーを元のホストに移行して戻すことができます。

17.1.1 別のホストへの管理サーバーのフェイルオーバー

次の手順は、管理サーバーを別のノード(WCCHOST2)にフェイルオーバーする方法を示します。フェイルオーバー後でも、管理サーバーは引き続き同じOracle WebLogic Serverマシン(物理マシンではなく論理マシン)を使用することに注意してください。

この手順では、エンタープライズ・トポロジに対してドメインごとのノード・マネージャを構成していることが前提となります。詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください

管理サーバーを別のホストにフェイルオーバーするには:

1. 管理サーバーを停止します。

2. 管理サーバー・ドメイン・ディレクトリ(ASERVER_HOME)のノード・マネージャを停止します。

3. ADMINVHN仮想IPアドレスを第2ホストに移行します。

a. WCCHOST1上で次のコマンドをroot権限で実行します(ここでは、X:YがADMINVHNで現在使用されているインタフェースになります)。

/sbin/ifconfig ethX:Y down

b. WCCHOST2で次のコマンドをルートとして実行します。

/sbin/ifconfig <interface:index> ADMINVHN netmask <netmask>

注意:
索引はBIHOST2のBI Server 2の索引とは異なります。

次に例を示します。

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、WCPHOST2で使用可能なネットワーク構成と一致している必要があります。

4. 次の例のように、arpingを使用してルーティング表を更新します。

/sbin/arping -q -U -c 3 -I eth0 100.200.140.206

5. WCCHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。

6. WCCHOST2上で管理サーバーを起動します。

7. 次の方法でWCCHOST2上の管理サーバーにアクセスできることをテストします。

a. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。

http://ADMINVHN:7001/console

b. 次のURLを使用して、Fusion Middleware Controlのコンポーネントにアクセスできることを確認し、そのステータスを検証します。

http://ADMINVHN:7001/em

17.1.2 Oracle HTTP Serverを介したWCCHOST2上の管理サーバーへのアクセスの検証

管理サーバーの手動フェイルオーバーを実行したら、標準管理URLを使用して管理サーバーにアクセスできることを確認することが重要です。

ロード・バランサから、次のURLにアクセスして、管理サーバーがWCPHOST2で稼働しているときにアクセスできることを確認します。

- http://admin.example.com/console
このURLによって、WebLogic Server管理コンソールが表示されます。

- http://admin.example.com/em
このURLによって、Oracle Enterprise Manager Fusion Middleware Controlが表示されます。

17.1.3 WCCHOST1への管理サーバーのフェイルバック

管理サーバーの手動フェイルオーバーをテストして、フェイルオーバー後に管理URLにアクセスできることを検証した後、管理サーバーをその元のホストに移行できます。

1. 管理サーバーを停止します。

2. WCCHOST2上の管理サーバー・ドメイン・ホームのノード・マネージャを停止します。

3. WCPHOST2で次のコマンドをrootとして実行します。

/sbin/ifconfig ethZ:N down

4. WCCHOST1で次のコマンドをルートとして実行します。

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクおよびインタフェースがWCCHOST1の使用可能なネットワーク構成と一致することを確認します

5. WCCHOST1上でarpingを使用して、ルーティング表を更新します。

/sbin/arping -q -U -c 3 -I ethX 100.200.140.206

6. WCCHOST1上の管理サーバー・ドメイン・ホームのノード・マネージャを起動します。

7. WCPHOST1上で管理サーバーを起動します。

8. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。

http://ADMINVHN:7001/console

9. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。

http://ADMINVHN:7001/em

17.2 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化

中間層とハードウェア・ロード・バランサ間のSSL通信を有効化する方法を理解することは重要です。

注意:

次の手順は、ハードウェア・ロード・バランサにSSLが構成されており、その結果システムのフロント・エンド・アドレスが保護されている場合に使用できます。

- 中間層とロード・バランサ間のSSL通信が必要になるとき

- utils.CertGenユーティリティを使用した自己署名証明書の作成

- utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

- Keytoolユーティリティを使用した信頼キーストアの作成

- トラスト・ストアへのロード・バランサ証明書のインポート

- Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

- カスタム・キーストアを使用するためのノード・マネージャの構成

- カスタム・キーストアを使用するためのWebLogic Serverの構成

- SSLエンドポイントを使用したコンポジットのテスト

17.2.1 中間層とロード・バランサ間のSSL通信が必要になるとき

エンタープライズ・デプロイメントには、中間層で実行されているソフトウェアが、ハードウェア・ロード・バランサのフロントエンドSSLアドレスにアクセスしなければならないシナリオがあります。このシナリオでは、ロード・バランサと起動サーバー間で、適切なSSLハンドシェイクが行われる必要があります。中間層の管理サーバーと管理対象サーバーが適切なSSL構成を使用して起動されていない場合は、このハンドシェイクを実行できません。

17.2.2 utils.CertGenユーティリティを使用した自己署名証明書の作成

この項では、WCCHOST1に自己署名証明書を作成する手順を説明します。これらの証明書は、ネットワーク名またはホストの別名を使用して作成します。

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。Oracleでは、別の目的で使用される証明書(HTTP呼び出し用に設定されたSSLなど)には中央または共有のストアを使用することをお薦めしています。詳細は、エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解に記載されているKEYSTORE_HOMEの場所のファイルシステム仕様に関する内容を参照してください。

かわりに信頼できるCA証明書を使用する方法は、『Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』のアイデンティティとトラストの構成に関する情報を参照してください。

パスワードについて

このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。

自己署名証明書を作成する手順は次のとおりです。

1. 次のコマンドを実行して一時的に環境を設定します。 WL_HOME/server/bin/setWLSEnv.shスクリプト:

. WL_HOME/server/bin/setWLSEnv.sh

現在のシェル内のシェル・スクリプトをソースにするために、スクリプト名の前にはドット(.)とスペース( )が付いています。

2. CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

3. 「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されているとおりに共有構成ディレクトリ・フォルダが作成され、共有記憶域に適切にマウントされていることを検証します。

たとえば、次のコマンドを使用して、共有構成ディレクトリが各ホストで使用可能であることを検証します。

df -h | grep -B1 SHARED_CONFIG_DIR

SHARED_CONFIG_DIRを、共有構成ディレクトリの実際のパスで置き換えます。

ディレクトリのリスト作成を実行し、ホストで使用可能かどうかを確認することもできます。

ls -al SHARED_CONFIG_DIR

4. キーストア・ホーム・フォルダ構造がまだない場合は、作成します。

次に例を示します。

cd SHARED_CONFIG_DIR
mkdir keystores
chown oracle:oinstall keystores
chmod 750 keystores
export KEYSTORE_HOME=SHARED_CONFIG_DIR/keystores

5. ディレクトリをキーストア・ホームに変更します。

cd KEYSTORE_HOME

6. utils.CertGenツールを実行して、各ノード上のサーバーによって使用される物理ホスト名と仮想ホスト名の両方の証明書を作成します。

注意:

utils.CertGenツールを実行して、管理対象サーバーを実行するその他すべてのホストの証明書を作成する必要があります。

構文:

java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]

例:

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

7. システムで使用される残りのすべてのホスト(たとえばWCPHOST2)について、前述の手順を繰り返します。

17.2.3 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

この項では、WCCHOST1.example.comでアイデンティティ・キーストアを作成する方法について説明します。

前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、すべてのホストおよびADMINVHNに対して前に作成した証明書と秘密鍵が新しいアイデンティティ・ストアにインポートされます。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

注意:

アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。

1. ADMINVHNおよびWCCHOST1の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

構文:

java utils.ImportPrivateKey
-certfile cert_file
-keyfile private_key_file
[-keyfilepass private_key_password]
-keystore keystore
-storepass storepass
[-storetype storetype]
-alias alias
[-keypass keypass]

注意:

デフォルトのkeystore_typeはjksです。

例:

java utils.ImportPrivateKey\
-certfile KEYSTORE_HOME/ADMINVHN.example.com_cert.pem\
-keyfile KEYSTORE_HOME/ADMINVHN.example.com_key.pem\
-keyfilepass password\
-keystore appIdentityKeyStore.jks\
-storepass password\
-alias ADMINVHN\
-keypass password

java utils.ImportPrivateKey\
-certfile KEYSTORE_HOME/WCPHOST1.example.com_cert.pem\
-keyfile KEYSTORE_HOME/WCPHOST1.example.com_key.pem\
-keyfilepass password\
-keystore appIdentityKeyStore.jks\
-storepass password\
-alias WCCHOST1\
-keypass password

2. 残りのホスト固有の証明書とキーの各組合(WCCHOST2、WCPHOST1、WCPHOST2など)について、java importPrivateKeyコマンドを繰り返します。

注意:
インポートする証明書とキーの各組合せに対して一意の別名を使用してください。

17.2.4 Keytoolユーティリティを使用した信頼キーストアの作成

WCCHOST1.example.comに信頼キーストアを作成する手順は次のとおりです。

1. 新しい信頼キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。

標準のJava信頼キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアのCA証明書を、証明書のあるディレクトリにコピーします。次に例を示します。

cp WL_HOME/server/lib/cacerts KEYSTORE_HOME/appTrustKeyStore.jks

2. keytoolユーティリティを使用して、デフォルトのパスワードを変更します。

標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは、常に次のように変更することをお薦めします。

keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password

次に例を示します。

keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit

3. keytoolユーティリティを使用してCA証明書をappTrustKeyStoreにインポートします。

CA証明書CertGenCA.derは、utils.CertGenツールによって生成されるすべての証明書の署名に使用され、WL_HOME/server/libディレクトリに置かれています。

次の構文を使用して、証明書をインポートします。

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

17.2.5 トラスト・ストアへのロード・バランサ証明書のインポート

SSLハンドシェイクが適切に行われるには、ロード・バランサの証明書をWLSサーバーのトラスト・ストアに追加する必要があります。追加するには、次の手順を実行します。

1. ブラウザでSSLのサイトにアクセスします(これにより、サーバーの証明書がブラウザのリポジトリに追加されます)。

2. ブラウザの証明書管理ツールから、証明書を、サーバーのファイル・システムにある(wcp.example.com.crtのようなファイル名を持つ)ファイルにエクスポートします。

3. keytoolを使用して、ロード・バランサの証明書をトラスト・ストアにインポートします。

次に例を示します。

keytool -import -file /oracle/certificates/wcp.example.com.crt -v -keystore appTrustKeyStore.jks -alias WCPLBR

17.2.6 Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

setDomainEnv.shスクリプトは、Oracle WebLogic Serverによって提供され、ドメイン内の管理サーバーと管理対象サーバーの起動に使用されます。各サーバーが更新済のトラスト・ストアにアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリのsetDomainEnv.shスクリプトを次のように編集します。

1. WCCHOST1にログインして、テキスト・エディタで次のファイルを開きます。

ASERVER_HOME/bin/setDomainEnv.sh

2. 既存のDemoTrustStoreエントリへの参照を、次のエントリに置き換えます。

注意:

EXTRA_JAVA_PROPERTIESのすべての値をファイル内に1行で記述し、その後の新規行にexportコマンドを記述する必要があります。

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dsoa.archives.dir=${SOA_ORACLE_HOME}/soa -Djavax.net.ssl.trustStore=/u01/oracle/certs/appTrustKeyStore.jks"
export EXTRA_JAVA_PROPERTIES

3. WCCHOST2、WCPHOST1およびWCPHOST2のMSERVER_HOME/binディレクトリにあるsetDomainEnv.shファイルに、同じ変更を行います。

注意:

setDomainEnv.shファイルは、ASERVER_HOME/binとMSERVER_HOME/binとの間でコピーすることはできません。これは、これら2つのドメイン・ホームの場所のファイルに違いがあるためです。MSERVER_HOME/bin/setDomainEnv.shは、ホスト間でコピーできます。

WebLogic Serverは、ドメインの拡張ごとにsetDomainEnv.shファイルを自動的に上書きします。また、一部のパッチによって、このファイルが置き換えることもあります。この種の保守操作が終わるたびに、setDomainEnv.shへのカスタマイズを検証してください。

17.2.7 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成するには、すべてのノード内のASERVER_HOME/nodemanagerディレクトリとMSERVER_HOME/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には必ず正しい値を使用してください。たとえば、utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成の手順に従って、WCCHOST1 MSERVER_HOMEでは別名WCCHOST1を使用し、WCCHOST1上のASERVER_HOMEでは別名ADMINVHNを使用します。

Example for WCCHOST1:
KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=KEYSTORE_HOME/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=WCCHOST1
CustomIdentityPrivateKeyPassPhrase=password

「WCCHOST1でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリは暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイルのエントリが暗号化されていない状態になる時間は最小限に抑えてください。ファイルを編集した後、できるだけ速やかにノード・マネージャを再起動し、エントリを暗号化します。

注意:
この構成の実行後、ドメインを拡張するたびにCustomIdentityAliasを修正する必要があります。解凍操作によって、ドメイン構成が書き込まれるときにCustomIdentityAliasが管理サーバーの値に置き換えられます。

17.2.8 カスタム・キーストアを使用するためのWebLogic Serverの構成

Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。SSL上のフロント・エンドLBRへのアクセスが必要な管理サーバーおよび管理対象サーバーに対して、この手順を実行します。

IDキーストアおよび信頼キーストアを構成するには:

1. 管理コンソールにログインして「ロックして編集」をクリックします。

2. 左ペインで「環境」を開き、「サーバー」を選択します。

3. IDキーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。

4. 「構成」を選択して、「キーストア」を選択します。

5. 「キーストア」フィールドで、「変更」をクリックし、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法を選択して、「保存」をクリックします。

6. 「ID」セクションで、アイデンティティ・キーストアの属性を定義します。

- カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。

KEYSTORE_HOME/appIdentityKeyStore.jks

- カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

- カスタム・アイデンティティ・キーストアのパスフレーズ: 「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します
この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアで、キーストアに書き込むためにはパスワードが必須です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

7. 「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。

- カスタム信頼キーストア: トラスト・キーストアの完全修飾パスを入力します。

KEYSTORE_HOME/appTrustKeyStore.jks

- カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

- カスタム信頼キーストアのパスフレーズ: 「keytoolユーティリティを使用した信頼キーストアの作成」で、新規パスワードとして指定したパスワード。
前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。

8. 「保存」をクリックします。

9. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

10. 「ロックして編集」をクリックします。

11. 「構成」をクリックし、「SSL」をクリックします。

12. 「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。

「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で作成したキーストアのパスワードを入力します

13. 「保存」をクリックします。

14. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

15. 管理サーバーを再起動します。

16. キーストアが更新された管理対象サーバーを再起動します。

注意:

管理コンソール/ノード・マネージャを使用してサーバーを再起動できるということは、ノード・マネージャ、管理サーバー、および管理対象サーバー間の通信が正常であるということです。

17.2.9 SSLエンドポイントを使用したコンポジットのテスト

SSLが有効になると、Oracle Enterprise Manager FMW Controlから、SSL上のコンポジット・エンドポイントを検証できます。SSLエンドポイントをテストするには、次の手順に従います。

1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。

http://ADMINVHN:7001/em

この例では、次のようになります。

- ADMINVHNを、「エンタープライズ・デプロイメント用のソフトウェア・ディストリビューションの特定と取得」でADMINVHN仮想IPアドレスに割り当てたホスト名に置き換えます。

- ポート7001は、管理サーバー・コンソールおよびFusion Middleware Controlで一般的に使用されるポートです。ただし、ドメインを作成したときに構成ウィザードのセッションの終わりに表示された実際のURLを使用する必要があります。

2. 管理ユーザー資格証明を使用してFusion Middleware Controlにログインします。

3. 左側にあるツリーで、「SOA」を開き、「soa-infra」(WLS_SOA1)をクリックします。

4. 「デプロイ済コンポジット」ナビゲーション・タブ・リンクをクリックします。

5. 「コンポジット」をクリックしてコンポジットのダッシュボード・ビューを開きます。

WebCenter Portal Community Workflowsコンポジットをテストするには、「コミュニティ・ワークフロー[12.2.1.x.0]」を選択します。

6. 「テスト」ボタンをクリックし、ドロップダウンからサービスの1つを選択します。

WebCenter Portal Community Workflowsコンポジットの招待Webサービス・エンドポイントをテストするには、「招待」を選択します。

7. WSDLまたはWADLアドレスで、URIリソース・パスおよび問合せ文字列は元のまま、ベースURL (http://WCCHOST1:8001)をフロントエンド・ロードバランサのベースURL(https://wcp.example.com:443)で置き換えます。

例: https://wcp.example.com:443/soa-infra/services/default/CommunityWorkflows/Invitation?WSDL

8. 「WSDLまたはWADLの解析」をクリックします。

9. 表示されるエンドポイントURLがSSLであり、エラーが戻されないこと確認します。

10. コンポジットをテストします。Webサービスのレスポンスが期待どおりであれば、管理サーバーとロード・バランサ間のSSL通信は正常に構成されています。

WebCenter Portal Community WorkflowsのWebサービス・エンドポイントへの有効なリクエストの発行には、いくつかのパラメータ値をSOAPペイロードで構成する必要があります。これらの値は、テスト・ポータルの前提条件となる構成と、使用可能なLDAPテスト・ユーザーに必要な属性によって、実装ごとに異なります。このレベルの規範的なテストは、WebCenter Portal用のエンタープライズ・デプロイメント・ガイドの対象範囲を超えており、読者の任意となります。詳細は、「WebCenter PortalでのOracle BPM Worklistアプリケーションのテスト」を参照してください。

17.3 エンタープライズ・デプロイメントの管理用のロールの構成

単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理するには、特定の管理ロールまたはグループを必要とする製品を理解することに加え、製品固有の管理ロールをエンタープライズ・デプロイメント管理グループに追加する方法を理解することが必要です。

各エンタープライズ・デプロイメントは複数の製品で構成されています。製品の一部には、各製品への管理アクセスの制御に使用される、特定の管理ユーザー、ロールまたはグループが存在します。

ただし、複数の製品で構成されているエンタープライズ・デプロイメントでは、単一のLDAPベースの認可プロバイダと、単一の管理ユーザーおよびグループを使用して、デプロイメントのあらゆる側面に対するアクセスを制御できます。認可プロバイダの作成と、エンタープライズ・デプロイメントの管理ユーザーおよびグループのプロビジョニングの詳細は、「新しいLDAPオーセンティケータの作成と新しいエンタープライズ・デプロイメント管理者ユーザーおよびグループのプロビジョニング」を参照してください。

単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理できるようにするには、特定の管理ロールまたはグループを必要とする製品を理解すること、単一の共通エンタープライズ・デプロイメントの管理グループに特定の製品管理ロールを追加する方法を知ること、さらに必要な場合は、必須の製品固有の管理グループにエンタープライズ・デプロイメントの管理ユーザーを追加する方法を知ることが必要になります。

詳細な情報は、次のトピックを参照してください

- 特定の管理ロールを持つ製品のサマリー

- エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加

17.3.1 特定の管理ロールを持つ製品のサマリー

次の表に、エンタープライズ・デプロイメントの管理グループ(WCPAdministrators)に追加する必要のある特定の管理ロールを持つ、Fusion Middleware製品のリストを示します(この管理グループは、エンタープライズ・デプロイメントのLDAP認可プロバイダで定義したものです)。

次の表の情報と「エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加」の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。

製品

アプリケーション・ストライプ

割り当てられる管理ロール

Oracle Web Services Manager。

wsm-pm

policy.updater

WebCenter Portal

webcenter

s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator

SOAインフラストラクチャ

soa-infra

SOAAdmin

17.3.2 エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加

製品固有の管理ロールを必要とする製品では、次の手順を使用して、その管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。

1. Oracle WebLogic Server管理サーバーの資格証明を使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

これらは、最初にドメインを構成し、Oracle WebLogic Server管理ユーザー名(通常weblogic_wcp)とパスワードを作成したときに作成した資格証明です。

2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。

3. 製品固有のアプリケーション・ロールごとに、「アプリケーション・ストライプ」ドロップダウン・メニューから対応するアプリケーション・ストライプを選択します。

4. 「アプリケーション・ロールの検索」アイコンをクリックして、ドメインで利用できるすべてのアプリケーション・ロールを表示します。

5. エンタープライズ・デプロイメントの管理グループに追加するアプリケーション・ロールの行を選択します。

6. 「編集」アイコンをクリックして、ロールを編集します。

7. 「アプリケーション・ロールの編集」ページの「追加」アイコンをクリックします。

8. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。

9. エンタープライズ・デプロイメント管理者グループを検索します。グループ名(WCPAdministratorsなど)を「プリンシパル名が次で始まる」フィールドに入力し、右矢印をクリックして検索を開始します。

10. 検索結果で管理者グループを選択して「OK」をクリックします。

11. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

17.4 エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用

この項では、トランザクション・ログ(TLOG)およびJMSにJDBC永続ストアを使用する方法のガイドライン、およびサポートされているデータベースで永続ストアを構成する手順について説明します。

- TLOGおよびJMSのJDBC永続ストアについて
Oracle Fusion MiddlewareではOracle WebLogic Serverトランザクション・ログ(TLOG)とJMSに対して、データベース・ベースとファイル・ベース両方の永続ストアをサポートしています。お使いの環境の永続ストア戦略を決定する前に、各方法の長所と短所を検討してください。

- JMS永続ストアとTLOGを使用する製品およびコンポーネント

- TLOGおよびJMS永続ストアのパフォーマンスへの影響
トランザクション・ログのストレージ方法およびJMS永続ストアを選択する際の考慮事項の1つとして、パフォーマンスへの影響があげられます。この項では、TLOGおよびJMSにJDBC永続ストアを使用する場合のパフォーマンスへの影響を明らかにするのに役立つ、ガイドラインや詳細をいくつか示します。

- TLOG用のJDBC永続ストア構成のロードマップ
次のトピックでは、トランザクション・ログのためにデータベースベースの永続ストアを構成する方法を説明します。

- JMSに対するJDBC永続ストアの構成のロードマップ
次の項では、JMSにデータベース・ベースの永続ストアを構成する方法について説明します。

- TLOG用のユーザーおよび表領域の作成
トランザクション・ログにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

- JMS用のユーザーおよび表領域の作成
JMSにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

- TLOGおよびJMSストアのGridLinkデータ・ソースの作成
JMSおよびTLOGにデータベース・ベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。

- 管理対象サーバーへのTLOG JDBCストアの割当て
データベースでユーザーと表領域を作成し、データ・ソースを作成したら、必要な各管理対象サーバーにTLOG永続ストアを割り当てることができます。

- JDBC JMSストアの作成
JMS永続ストアのユーザーと表領域をデータベースに作成し、JMS永続ストアのデータ・ソースを作成した後で、管理コンソールを使用してストアを作成できます。

- JMSサーバーへのJMS JDBCストアの割当て
データベースでJMS表領域とユーザーを作成し、JMSデータ・ソースを作成し、JMSストアを作成したら、必要な各JMSサーバーにJMS永続ストアを割り当てることができます。

- JMS JDBCストアに必要な表の作成
JMSにJDBC永続ストアを使用する最後の手順は、必要なJDBCストア表を作成することです。このタスクは、ドメインで管理対象サーバーを再起動する前に実行します。

17.4.1 JMSおよびTLOGのためのJDBC永続ストアについて

Oracle Fusion MiddlewareではOracle WebLogic Serverトランザクション・ログ(TLOG)とJMSに対して、データベース・ベースとファイル・ベース両方の永続ストアをサポートしています。お使いの環境の永続ストア戦略を決定する前に、各方法の長所と短所を検討してください。

注意:

選択するストレージ方法に関係なく、トランザクションの整合性および一貫性を確保するために、JMSとTLOGの両方に同じタイプのストアを使用することをお薦めします。

TLOGおよびJMSデータをOracleデータベースに格納する場合、データベースの複製機能と高可用性機能を利用できます。たとえば、OracleData Guardを使用してサイト間の同期を簡易化できます。これは、Oracle Fusion Middlewareを障害回復構成でデプロイする場合に特に重要です。

また、TLOGおよびJMSデータをデータベースに格納すると、そのデータについて共有記憶域内の特定の場所を指定する必要がありません。ただし、エンタープライズ・デプロイメントの他の観点からも共有記憶域が必要であることに注意してください。たとえば、管理サーバー構成(管理サーバーのフェイルオーバーをサポート)、デプロイメント・プラン、およびアダプタ・アーティファクト(ファイル/FTPアダプタの制御ファイルおよび処理済ファイル)でも必要です。

TLOGおよびJMSストアを共有記憶域デバイスに格納する場合、適切な複製およびバックアップ戦略を使用してデータ損失ゼロを保証することで、このデータを保護できます。また、システム・パフォーマンスも向上する可能性があります。ただし、ファイル・システム保護は常に、Oracle Databaseによって提供される保護よりも弱くなります。

データベースベースのTLOGおよびJMSストアの使用によるパフォーマンスへの潜在的な影響の詳細は、「TLOGおよびJMS永続ストアのパフォーマンスへの影響」を参照してください。

17.4.2 JMS永続ストアとTLOGを使用する製品およびコンポーネント

永続ストアを利用するFMW製品およびコンポーネントを決定するには、WebLogic Serverコンソールの「ドメイン構造」ナビゲーションで、ドメイン名 > 「サービス」 > 「永続ストアを使用します。リストには、ストアの名前、ストア・タイプ(通常はFileStore)、ターゲットの管理対象サーバー、およびターゲットを移行可能かどうかが示されます。

移行可能ターゲットを含む永続ストアは、JDBC永続ストアの使用を検討するのに適した候補です。リストされている中でMDSに関連するストアについてはこの章では扱わず、考慮されません。

通常、Oracle WebCenter ContentおよびOracle SOAが含まれるOracle WebCenter Portal環境の場合、各クラスタ内のWLS_WCCnおよびWLS_SOAnの管理対象サーバーがJMSおよびTLOGSのデータ・ソースと新しいJDBC永続ストアのターゲットとなります。

17.4.3 TLOGおよびJMS永続ストアのパフォーマンスへの影響

トランザクション・ログのストレージ方法およびJMS永続ストアを選択する際の考慮事項の1つとして、パフォーマンスへの影響があげられます。この項では、TLOGおよびJMSにJDBC永続ストアを使用する場合のパフォーマンスへの影響を明らかにするのに役立つ、ガイドラインや詳細をいくつか示します。

トランザクション・ログとJMSストアのパフォーマンスへの影響

トランザクション・ログの場合、ログは本質的に一時的であるため、JDBCストアの使用による影響は比較的小さくて済みます。通常、システム内の他のデータベース操作と比較した場合、影響はほとんどありません。

一方、JMSデータベース・ストアは、アプリケーションでのJMS使用率が高い場合にパフォーマンスに大きな影響を及ぼすことがあります。

パフォーマンスに影響を与える要素

カスタム宛先にJMS DBストアを使用する場合、複数の要素がパフォーマンスに影響を与えます。主なものは、次のとおりです。

- 関与するカスタム宛先とそのタイプ

- 永続化されるペイロード

- SOAシステムの同時実行性(宛先のコンシューマおよびプロデューサ)

上述のいずれかの影響に応じて、次の領域に様々な設定を構成し、パフォーマンスを向上させることができます。

- JMS表に使用されるデータ型のタイプ(RAWの使用対LOBの使用)

- JMS表のセグメント定義(索引および表レベルでのパーティション)

JMSトピックの影響

システムでトピックが集中的に使用されている場合、同時実行性が高まるにつれて、Oracle RACデータベースのパフォーマンス低下はキューの場合よりも大きくなります。OracleがJMSに対して実施したテストでは、様々なペイロード・サイズおよび様々な同時実行性での平均パフォーマンス低下率は、キューの場合は30%未満でした。トピックの場合、影響は40%を超えていました。データベース・ストアを使用するかどうかを決定する際、リカバリの観点からこれらの宛先の重要性を検討してください。

データ型およびペイロード・サイズの影響

ペイロードにRAWデータ型を使用するかSecureFiles LOBデータ型を使用するかを選択する場合、永続化されるペイロードのサイズを考慮してください。たとえば、ペイロード・サイズの範囲が100bから20kの場合、SecureFiles LOBデータ型で必要とされるデータベース時間の量はRAWデータ型よりも若干多くなります。

具体的に言うと、ペイロード・サイズが約4kに達すると、SecureFilesはより多くのデータベース時間を必要とするようになります。これは、4kでは書込みが行外になるためです。約20kのペイロード・サイズで、SecureFilesデータはより効率的になり始めます。ペイロード・サイズが20kを超えると、RAWデータ型に設定されたペイロードのデータベース時間は悪化します。

SecureFilesのもう1つの利点は、500kを超えた時点からペイロードが増加してもデータベース時間が安定化し始める点です。すなわち、その時点で、(SecureFilesにとって)データが500k、1MBまたは2MBのいずれのペイロードを格納しているかは関係なくなります。書込みが非同期化され、すべてのケースで競合が同じになるためです。

ペイロード・サイズが50kに達するまで、キューのスループットに対する同時実行性(プロデューサおよびコンシューマ)の影響はRAWでもSecureFilesでも同じです。ペイロードが小さい場合、同時実行性が変化してもその影響はほぼ同じですが、RAWの方がスケーラビリティがやや優れています。ペイロードが50kを超える場合、SecureFilesの方がスケーラビリティが優れています。

同時実行性、ワーカー・スレッド、データベースのパーティション化の影響

永続ストアに定義された同時実行性とワーカー・スレッドは、索引レベルおよびグローバル・キャッシュ・レベルでRACデータベースの競合の原因になることがあります。1つの単一サーバーで複数のワーカー・スレッドを有効にする場合、または複数のOracle WebLogic Serverクラスタを使用する場合、リバース索引を使用することで様々なことを改善できます。ただし、Oracle Databaseのパーティション化オプションを使用できる場合、かわりにグローバル・ハッシュ・パーティション索引を使用する必要があります。これにより、索引の競合およびグローバル・キャッシュ・バッファ待機が減少し、アプリケーションのレスポンス時間が改善されます。パーティション化はどのケースでも適切に機能しますが、リバース索引で大幅な改善が認められない場合もあります。

17.4.4 TLOG用のJDBC永続ストア構成のロードマップ

ここでは、トランザクション・ログ用にデータベースベースの永続ストアを構成する方法を説明します。

1. TLOGのユーザーと表領域の作成

2. TLOGおよびJMSストアのGridLinkデータ・ソースの作成

3. 管理対象サーバーへのTLOG JDBCストアの割当て

17.4.5 JMS用のJDBC永続ストア構成のロードマップ

次の項では、JMSにデータベース・ベースの永続ストアを構成する方法について説明します。

1. JMSのユーザーと表領域の作成

2. TLOGおよびJMSストアのGridLinkデータ・ソースの作成

3. JDBC JMSストアの作成

4. JMSサーバーへのJMS JDBCストアの割当て

5. JMS JDBCストアで必要な表の作成

17.4.6 TLOGのユーザーと表領域の作成

トランザクション・ログにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

1. tlogsという表領域を作成します。

たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace tlogs
logging datafile 'path-to-data-file-or-+asmvolume'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. TLOGSという名前のユーザーを作成し、そのユーザーにtlogs表領域を割り当てます。

次に例を示します。

SQL> create user TLOGS identified by password;

SQL> grant create table to TLOGS;

SQL> grant create session to TLOGS;

SQL> alter user TLOGS default tablespace tlogs;

SQL> alter user TLOGS quota unlimited on tlogs;

17.4.7 JMSのユーザーと表領域の作成

JMSにデータベース・ベースの永続ストアを作成する前に、サポートされているデータベースでユーザーと表領域を作成する必要があります。

1. jmsという表領域を作成します。

たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace jms
logging datafile 'path-to-data-file-or-+asmvolume'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. JMSという名前のユーザーを作成し、そのユーザーにjms表領域を割り当てます。

例:

SQL> create user JMS identified by password;

SQL> grant create table to JMS;

SQL> grant create session to JMS;

SQL> alter user JMS default tablespace jms;

SQL> alter user JMS quota unlimited on jms;

17.4.8 TLOGおよびJMSストアのGridLinkデータ・ソースの作成

JMSおよびTLOGにデータベース・ベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。

エンタープライズ・デプロイメントでは、TLOGおよびJMSストアにGridLinkデータ・ソースを使用する必要があります。GridLinkデータ・ソースを作成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

- 「名前」フィールドに、データ・ソースの論理名を入力します。
TLOGストアの場合はTLOGを入力し、JMSストアの場合はJMSを入力します。

- JNDIの名前を入力します。
TLOGストアの場合はjdbc/tlogsを入力し、JMSストアの場合はjdbc/jmsを入力します。

- 「データベース・ドライバ」には、Oracle Driver (Thin) for GridLink Connections Versions: Anyを選択します。

- 「次へ」をクリックします。

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスを選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。次に例を示します。
wcpedg.example.com

- ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。次に例を示します。

db-scan.example.com:1521

「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。

SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せると、確認できます。

SQL>show parameter remote_listener;

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string      db-scan.example.com

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例:

dbhost1-vip.mycompany.com (port 1521)

および

dbhost2-vip.mycompany.com (1521)

- データベース・ユーザー名: 次を入力します。
TLOGストアの場合はTLOG、JMS永続ストアの場合はJMSと入力します。

- パスワード: データベースでユーザーを作成した際に使用したパスワードを入力します。

- パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

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イベントに登録し、それらのイベントを処理できるようにします。

- ここにも、次のように、SCANアドレス: RACデータベースのONSリモート・ポート、データベースから報告されたONSリモート・ポートを入力し、「追加」をクリックします。

[orcl@db-scan1 ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

- 「次へ」をクリックします。

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.example.com (port 6200)

および

custdbhost2.example.com (6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

接続が成功したときに表示される通知の一例を示します。

Connection test for db-scan.example.com:6200 succeeded.

「次へ」をクリックします。

11. 「ターゲットの選択」ページで、永続ストアを使用するクラスタを選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

14. 手順4から13を繰り返して、JMSファイル・ストア用のGridLinkデータ・ソースを作成します。

17.4.9 管理対象サーバーへのTLOG JDBCストアの割当て

データベースでユーザーと表領域を作成し、データ・ソースを作成したら、必要な各管理対象サーバーにTLOG永続ストアを割り当てることができます。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ツリーで「環境」を展開し、「サーバー」を展開します。

4. TLOGストアを使用する管理対象サーバーの名前をクリックします。

5. 「構成」>「サービス」 タブを選択します。

6. 「トランザクション・ログ・ストア」で、「タイプ」メニューから「JDBC」を選択します。

7. 「データ・ソース」メニューで、TLOG永続ストアに作成したデータ・ソースを選択します。

8. 「接頭辞名」フィールドで、構成された各JDBC TLOGストアに一意のJDBC TLOGストア名を生成するための接頭辞名を指定します。

9. 「保存」をクリックします。

10. クラスタ内の追加の管理対象サーバーごとに、手順3から7を繰り返します。

11. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

17.4.10 JDBC JMSストアの作成

データベースでJMS永続ストア・ユーザーと表領域を作成し、JMS永続ストアのデータ・ソースを作成したら、管理コンソールを使用してストアを作成できます。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を開き、「永続ストア」を選択します。

4. 「新規」をクリックしてから「JDBCストア」をクリックします。

5. 使用している永続化するJMSサーバーに容易に結び付けられる永続ストア名を入力します。

6. インストールとクラスタを修飾する一意の接頭辞を指定し、JMS永続ストアに作成したデータ・ソースに関連付けます。

7. ストアをJTAサービスをホストするエンティティにターゲット指定します。
サービス移行を使用するサーバーの場合、これはJVMサーバーが所属する移行可能ターゲットになります。

8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

17.4.11 JMSサーバーへのJMS JDBCストアの割当て

データベースでJMS表領域とユーザーを作成し、JMSデータ・ソースを作成し、JMSストアを作成したら、必要な各JMSサーバーにJMS永続ストアを割り当てることができます。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ツリーで、「サービス」、「メッセージング」、「JMSサーバー」の順に展開します。

4. 永続ストアを使用するJMSサーバーの名前をクリックします。

5. 「永続ストア」メニューで、前に作成したJMS永続ストアを選択します。

6. 「保存」をクリックします。

7. クラスタ内の追加のJMSサーバーごとに、手順3から6を繰り返します。

8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

17.4.12 JMS JDBCストアで必要な表の作成

JMSにJDBC永続ストアを使用する最後の手順は、必要なJDBCストア表を作成することです。このタスクは、ドメインで管理対象サーバーを再起動する前に実行します。

1. TLOGおよびJMS永続ストアのパフォーマンスへの影響に関する項の情報を確認し、環境に適した表機能を決定します。

このリリースで提供されるOracle DBスキーマ定義は3つあり、前の手順で確認用に抽出されています。基本の定義には、索引用のパーティションがないRAWデータ型が含まれます。2つ目のスキーマではblobデータ型を使用し、3つ目ではblobデータ型およびセキュア・ファイルを使用します。

2. 共有記憶域でカスタムDDLファイルにドメイン固有の名前の付いたフォルダ構造を作成します。すべてのサーバーで使用できるようにORACLE_RUNTIME共有ボリュームが推奨されます。

例:

mkdir -p ORACLE_RUNTIME/domain_name/ddl

3. 要件分析に基づいて新しい共有DDLフォルダにjms_custom.ddlファイルを作成します。
たとえば、セキュア・ファイルとハッシュ・パーティション化の両方を使用する最適化されたスキーマ定義を実装するには、次の内容のjms_custom.ddlファイルを作成します。

CREATE TABLE $TABLE (
id     int  not null,
type   int  not null,
handle int  not null,
record blob not null,
PRIMARY KEY (ID) USING INDEX GLOBAL PARTITION BY HASH (ID) PARTITIONS 8)
LOB (RECORD) STORE AS SECUREFILE (ENABLE STORAGE IN ROW);

この例を、索引パーティションなしでRAWデータ型が使用される、JMSストアのデフォルトのスキーマ定義と比較することができます。

パーティションの数は2の累乗にする必要があります。これにより、各パーティションがほぼ同じサイズになります。推奨されるパーティションの数は、表または索引の予想増加率によって異なります。データベース管理者(DBA)に一定期間における表の増加率を分析させて、それに応じて表を調整する必要があります。詳細は、Oracle Database VLDBおよびパーティショニング・ガイドのパーティション化の概念に関する項を参照してください。

4. 管理コンソールを使用して、前に作成した既存のJDBCストアを編集します。JMSデータのために使用される表を作成します。

a. Oracle WebLogic Server管理コンソールにログインします。

b. 「チェンジ・センター」で、「ロックして編集」をクリックします。

c. 「ドメイン構造」ツリーで「サービス」、「永続ストア」の順に開きます。

d. 前に作成した永続ストアをクリックします。

e. 「詳細」オプションで、DDLファイルからの表の作成」フィールドにORACLE_RUNTIME/domain_name/ddl/jms_custom.ddlを入力します。

f. 「保存」をクリックします。

g. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

5. 管理対象サーバーを再起動します。

17.5 エンタープライズ・デプロイメントのバックアップとリカバリの実行

Oracle WebCenter Portalエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするために、次に示すガイドラインに従うことをお薦めします。

注意:

ここで示されている一部の静的およびランタイム・アーティファクトは、Network Attached Storage (NAS)からホストされます。可能な場合は、これらのボリュームをアプリケーション・サーバーではなく直接NASファイラからバックアップおよびリカバリします。

Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。

- 環境のバックアップ

- 環境のリカバリ

表17-1に、典型的なOracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示します。

表17-1 Oracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト

タイプ

ホスト

層

データベースOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

WCCHOST1およびWCCHOST2 (またはNASファイラ)

アプリケーション層

インストール関連ファイル

WEBHOST1、WEHOST2および共有記憶域

N/A

表17-2に、典型的なOracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である実行時アーティファクトを示します。

表17-2 Oracle WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である実行時アーティファクト

タイプ

ホスト

層

管理サーバーのドメイン・ホーム(ASERVER_HOME)

WCCHOST1 (またはNASファイラ)

アプリケーション層

アプリケーション・ホーム(APPLICATION_HOME)

WCCHOST1 (またはNASファイラ)

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

スクリプトとカスタマイズ

ホスト当たり

アプリケーション層

デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME)

WCCHOST1 (またはNASファイラ)

アプリケーション層

OHS構成ディレクトリ

WEBHOST1およびWEBHOST2

Web層

18 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

Oracle WebLogic Serverの移行フレームワークでは、サーバー全体の移行とサービスの移行をサポートしています。次の各項では、Oracle Fusion Middlewareエンタープライズ・トポロジでのこれらの機能の使用方法について説明します。

- エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について
Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。

- リース用のGridLinkデータ・ソースの作成
サーバー全体の移行および自動サービス移行では、リーシング表のデータ・ソースが必要です。リーシング表は、リポジトリ作成ユーティリティ(RCU)によって、Oracle WebLogic Serverスキーマの一部として自動的に作成される表領域です。

- エンタープライズ・デプロイメント用のサーバー全体の移行の構成
サーバー全体の移行または自動サービス移行用にドメインを準備した後、クラスタ内の特定の管理対象サーバーに対してサーバー全体の移行を構成できます。

- エンタープライズ・デプロイメント内での自動サービス移行の構成
エンタープライズ・デプロイメント内の特定のサービスに対して自動サービス移行を構成することが必要になる場合があります。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

18.1 エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について

Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。

- サーバー全体の移行とサービスの移行の違いの理解

- エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

- サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

18.1.1 サーバー全体の移行とサービスの移行の違いの理解

Oracle WebLogic Serverの移行フレームワークでは、次の2つの種類の自動移行をサポートしています。

- サーバー全体の移行。障害発生時に、管理対象サーバー・インスタンスが別の物理システムに移行されます。
サーバー全体の移行では、別の物理マシン上で、サーバー・インスタンスとそのすべてのサービスが自動的に再起動されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。

このためには、サーバーはリスニング・アドレスとして浮動IPを使用する必要があり、必要なリソース(トランザクション・ログとJMS永続ストア)が候補マシンで利用できなければなりません。

詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。

- サービスの移行。特定のサービスが、クラスタ内の別の管理対象サーバーに移行されます。
サービスの移行を理解するには、固定サービスを理解することが重要です。

WebLogic Serverクラスタでは、ほとんどのサブシステム・サービスがクラスタ内のすべてのサーバー・インスタンスで均一にホストされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMS関連サービスやJTAトランザクション・リカバリ・サービス、ユーザー定義のシングルトン・サービスなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにホストされます。WebLogic Serverの移行フレームワークは、これらのサービスに対して、フェイルオーバーではなく、サービスの移行による障害回復をサポートしています。

詳細は、『Oracle WebLogic Serverクラスタの管理』のサービスの移行フレームワークの理解に関する項を参照してください。

18.1.2 エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

サーバーまたはサービスが別のシステムで再起動されるときは、必要なリソース(サービス・データ、ログなど)が元のシステムとフェイルオーバー・システムの両方で利用できなければなりません。利用できなければ、サービスは、同じ操作をフェイルオーバー・システムで正常に再開できません。

このような理由から、サーバー全体の移行とサービスの移行の両方で、クラスタのすべてのメンバーが、同一のトランザクションとJMS永続ストア(ファイルベースかデータベースベースかを問わない)にアクセスできる必要があります。

これが、エンタープライズ・デプロイメントで共有記憶域が重要となる、もう1つの理由です。共有記憶域を適切に構成すると、手動フェイルオーバー(管理サーバーのフェイルオーバー)または自動フェイルオーバー(サーバー全体の移行またはサービスの移行)が発生したときに、元のマシンとフェイルオーバー・マシンの両方が、サービスを変更しなくても、確実に同一のファイル・ストアにアクセスできるようになります。

自動サービス移行の場合、固定サービスの再開が必要になったときは、フェイルオーバー前に固定サービスによって使用されていたJMSとJTAのログにアクセスできる必要があります。

サーバー全体の移行の場合、共有記憶域のほかに、仮想IPアドレス(VIP)の入手と割当ても必要になります。管理対象サーバーが別のマシンにフェイルオーバーされると、VIPは新しいマシンに自動的に再割り当てされます。

サービスの移行には、VIPは必要ありません。

18.1.3 サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

次の表に、移行機能の使用が役立つFMW製品およびコンポーネントと、このリリースでのベストプラクティス推奨をまとめます。移行可能と記載されたコンポーネントでは、サーバー全体の移行または自動サービス移行を使用できます。

この表は、推奨されるベスト・プラクティスを示していることに注意してください。サーバー全体の移行または自動サーバー移行をサポートするコンポーネントでこれらの機能を使用できなくなるわけではありません。

コンポーネント

サーバー全体の移行(WSM)

自動サービス移行(ASM)

Oracle Web Services Manager(OWSM)

いいえ

いいえ

Oracle WebCenter Portal

いいえ

いいえ

Oracle WebCenter Portalのポートレットおよびページレット・プロデューサ

いいえ

いいえ

Oracle WebCenter Content

はい

はい(推奨)

Oracle WebCenter Inbound Refinery

いいえ

いいえ

Oracle SOA Suite

はい

はい(推奨)

Oracle Enterprise Scheduler

いいえ

いいえ

18.2 リース用のGridLinkデータ・ソースの作成

サーバー全体の移行および自動サービス移行では、リーシング表のデータ・ソースが必要です。リーシング表は、リポジトリ作成ユーティリティ(RCU)によって、Oracle WebLogic Serverスキーマの一部として自動的に作成される表領域です。

エンタープライズ・デプロイメントでは、GridLinkのデータ・ソースを作成する必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

- 「名前」フィールドに、データ・ソースの論理名を入力します。たとえば、Leasingと入力します。

- JNDIの名前を入力します。たとえば、jdbc/leasingです。

- 「データベース・ドライバ」には、Oracle Driver (Thin) for GridLink Connections Versions: Anyを選択します。

- 「次」をクリックします。

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスを選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。次に例を示します。
wcpedg.example.com

- ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。次に例を示します。

db-scan.example.com:1521

「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。

SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せると、確認できます。

SQL>show parameter remote_listener;

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string      db-scan.example.com

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例:

dbhost1-vip.mycompany.com (port 1521)

および

dbhost2-vip.mycompany.com (1521)

Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- データベース・ユーザー名: 次のように入力します。

FMW1221_WLS_RUNTIME

この例では、FMW1221は、初期Enterprise Managerドメインを構成する準備をしたときに、スキーマの作成で使用した接頭辞です。

前のバージョンのOracle Fusion Middlewareでは、移行リース表のユーザーおよび表領域を手動で作成する必要がありました。Fusion Middleware 12c (12.2.1)では、リポジトリ作成ユーティリティ(RCU)でWLSスキーマを作成すると、リーシング表が自動的に作成されます。

- パスワード: RCUでWLSスキーマを作成したときに使用したパスワードを入力します。

- パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

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イベントに登録し、それらのイベントを処理できるようにします。

- 「ONSホストとポート」フィールドにSCANアドレスを入力して、「追加」、「追加」の順にクリックします。
この値は、RACデータベースのONSホストおよびONSリモート・ポートである必要があります。データベースのONSリモート・ポートを検索するために、データベース・ホストで次のコマンドを使用できます。

[orcl@db-scan1 ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

- 「次」をクリックします。

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.example.com (port 6200)

および

custdbhost2.example.com (6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

接続が成功したときに表示される通知の一例を示します。

Connection test for db-scan.example.com:6200 succeeded.

「次」をクリックします。

11. 「ターゲットの選択」ページで、サーバー全体の移行または自動サービス移行を構成するクラスタを選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 「変更のアクティブ化」をクリックします。

18.3 エンタープライズ・デプロイメントでのサーバー全体の移行の構成

サーバー全体の移行または自動サービス移行用にドメインを準備した後、クラスタ内の特定の管理対象サーバーに対してサーバー全体の移行を構成できます。

- ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

- wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定

- サーバー移行ターゲットの構成

- サーバー全体の移行のテスト

18.3.1 ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

この項では、サーバーが実行されている2つのノード上のノード・マネージャのプロパティ・ファイルを編集します。

1. 次のファイルを探してテキスト・エディタで開きます。

MSERVER_HOME/nodemanager/nodmeanager.properties

2. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。

これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

3. 次のプロパティをnodemanager.propertiesファイルに追加して、サーバー移行が正常に動作するようにします。

- 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フラグを使用するかどうかを指定します。

4. ノード・マネージャを再起動します。

5. これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力は次のようになります。

...
SecureListener=true
LogCount=1
eth0=*,NetMask=255.255.255.0
...

18.3.2 wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定

この項では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。このスクリプトは、移行中に、IPアドレスをマシンからマシンに転送するために使用します。通常スーパーユーザーのみが利用可能なifconfigの実行が可能でなければなりません。

wlsifconfig.shスクリプトの詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の自動移行の構成に関する項を参照してください。

wlsifconfig.shスクリプトを実行するためにシステムを準備する手順は、次の項を参照してください。

- wlsifconfig.shスクリプトのPATH環境変数の設定

- wlsifconfig.shスクリプトに対する権限の付与

18.3.2.1 wlsifconfig.shスクリプトのPATH環境変数の設定

次の表に記載されているコマンドは、各ホスト・コンピュータのPATH環境変数に必ず含めてください。

ファイル

ディレクトリの場所

wlsifconfig.sh

MSERVER_HOME/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

MSERVER_HOME/nodemanager

18.3.2.2 wlsifconfig.shスクリプトに対する権限の付与

パスワードによる制限を設けずにsudo権限をオペレーティング・システム・ユーザー(oracleなど)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

注意:

セキュリティ上の理由から、sudoを、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。

この必須の構成タスクを実行するためのsudo権限とsystem権限については、必要に応じてシステム管理者に問い合せてください。

/etc/sudoers内の次のエントリ例では、ifconfigとarpingを実行するために、oracleに対してsudo実行権限を付与しています。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

18.3.3 サーバー移行ターゲットの構成

クラスタ内の移行を構成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

3. 移行を構成するクラスタを、表の「名前」列でクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「移行基盤」に「データベース」を選択します。「自動移行に使用するデータ・ソース」としてドロップダウン・リストからリースを選択します。

7. 「移行可能サーバーの候補マシン」の「使用可能」フィールドでクラスタ内の管理対象サーバーを選択し、右矢印をクリックして「選択済み」に移動します。

8. 「リース用のGridLinkデータ・ソースの作成」で作成したリーシング・データ・ソースを選択します。

9. 「保存」をクリックします。

10. サーバー移行の候補となるマシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。

a. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

b. 移行を構成するサーバーを選択します。

c. 「移行」タブをクリックします。

d. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

アプリケーションとリソースのターゲット設定の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

e. 「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。
この手順では、現在のホストを使用できない場合に管理対象サーバーのフェイルオーバー先となるホストを識別します。たとえば、HOST1の管理対象サーバーの場合はHOST2を選択し、HOST2の管理対象サーバーの場合はHOST1を選択します。

ヒント:

「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。

11. 「変更のアクティブ化」をクリックします。

12. 管理サーバーと、サーバー移行が構成されたサーバーを再起動します。

18.3.4 サーバー全体の移行のテスト

この項の手順を実行して、サーバー全体の自動移行が適切に機能していることを確認します。

ノード1からテストする手順は次のとおりです。

1. 管理対象サーバーのプロセスを停止します。

kill -9 pid

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

ps -ef | grep WLS_SOA1

2. ノード・マネージャのコンソール(killコマンドを実行したターミナル・ウィンドウ)を確認します。管理対象サーバーの浮動IPが無効になっていることを示すメッセージが表示されているはずです。

3. ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャがサーバーを再起動し、サーバーが「実行中」状態になる前に、関連するプロセスを再度強制終了します。
サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

必要な再起動回数は、次の構成ファイルのRestartMaxパラメータで設定されます。

MSERVER_HOME/servers/WLS_SOA1/data/nodemanager/startup.properties

デフォルト値はRestartMax=2です。

ノード2からテストする手順は次のとおりです。

1. ローカルのノード・マネージャのコンソールを確認します。ノード1で最後に管理対象サーバーの再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、管理対象サーバーの浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。

2. 同じIPアドレスを使用して、製品URLにアクセスします。URLが正常な場合は、移行が成功したことを示します。

管理コンソールからの検証

Oracle WebLogic Server管理コンソールを使用して、移行を検証することもできます。

1. 管理コンソールにログインします。

2. 左側のコンソールで、「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。

「移行の状態」の表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後、そのサーバーを元のマシンにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

18.4 エンタープライズ・デプロイメントでの自動サービス移行の構成

エンタープライズ・デプロイメント内の特定のサービスに対して自動サービス移行を構成することが必要になる場合があります。

- エンタープライズ・デプロイメント・クラスタのリーシング・メカニズムとデータ・ソースの設定

- クラスタ内の管理対象サーバーの移行設定の変更

- サービス移行ポリシーの選択について

- クラスタ内の各管理対象サーバーのサービス移行ポリシーの設定

- 自動サービス移行の検証

- 自動サービス移行後のサービスのフェイルバック

18.4.1 エンタープライズ・デプロイメント・クラスタでのリース・メカニズムとデータ・ソースの設定

自動サービス移行を構成する前に、自動サービス移行機能によって使用されるリーシング・メカニズムおよびデータ・ソースを確認する必要があります。

注意:

次の手順は、「リース用のGridLinkデータ・ソースの作成」の説明に従ってリーシング・データ・ソースを作成していることを前提としています。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
「クラスタのサマリー」ページが表示されます。

4. 表の「名前」列で、移行を構成するクラスタをクリックします。

5. 「移行」タブをクリックします。

6. 「移行基盤」ドロップダウン・メニューで「データベース」が選択されていることを確認します。

7. 「自動移行に使用するデータ・ソース」ドロップダウン・メニューから、「リース用のGridLinkデータ・ソースの作成」で作成したリーシング・データ・ソースを選択します。

8. 「保存」をクリックします。

9. 変更をアクティブ化します。

10. 管理対象サーバーを再起動します。

18.4.2 クラスタ内の管理対象サーバーの移行設定の変更

クラスタのリーシング・メカニズムとデータ・ソースを設定した後に、サービス移行に対して構成する管理対象サーバーのJTAの自動移行を有効にすることができます。このトピックは、エンタープライズ・デプロイメントの一部としてJTAサービスをデプロイしている場合にのみ適用されます。

クラスタ内の管理対象サーバーの移行設定を変更する手順は次のとおりです。

1. 管理コンソールにログインしていない場合は、ログインして、「ロックして編集」をクリックします。

2. 「ドメイン構造」ペインの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。

3. 表の「名前」列で、変更するサーバーの名前をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

4. 「移行」タブをクリックします。

5. 「JTA移行ポリシー」ドロップダウン・メニューから「障害リカバリ」を選択します。

6. ページの「JTA候補サーバー」セクションで、「使用可能」リスト・ボックスの管理対象サーバーを選択し、「移動」ボタンをクリックして、「選択済み」リスト・ボックスに移動します。

7. このページの「JMSサービスの候補サーバー」セクションで、「使用可能」リスト・ボックスの管理対象サーバーを選択し、移動ボタンをクリックして、「選択済み」リスト・ボックスに移します。

8. 「保存」をクリックします。

9. すべての管理対象サーバーと管理サーバーを再起動します。

18.4.3 サービス移行ポリシーの選択について

自動サービス移行を構成する場合は、クラスタごとにサービス移行ポリシーを選択します。このトピックでは、サービス移行ポリシーを選択する際のガイドラインと考慮事項を説明します。

たとえば、シングルトンを実行するか、またはパス・サービスを使用する製品やコンポーネントには、必ず1回の自動移行ポリシーが役立ちます。このポリシーでは、候補サーバーのリストにある管理対象サーバーが1つ以上動作している場合、この移行可能ターゲットでホストされるサービスは、サーバーが失敗するか管理者によって(正常または強制的に)シャットダウンされた場合に、クラスタ内のいずれかの場所でアクティブ化されます。これにより、起動時に複数の同種サービスが1つのサーバーに存在する場合があります。

このポリシーを使用する場合は、クラスタの起動を監視して、各サーバーで実行されているサーバーを識別する必要があります。その後、必要に応じて手動のフェイルバックを実行して、バランスの取れた構成にシステムを配置できます。

その他のFusion Middlewareコンポーネントには、障害回復サービスの自動移行ポリシーの方が適しています。

これらのガイドラインに基づいて、Oracle WebCenter Contentエンタープライズ・デプロイメントでクラスタに対して「障害回復サービスの自動移行」を使用する必要があります。

詳細は、『Oracle WebLogic Serverクラスタの管理』の手動および自動サービス移行のポリシーに関する項を参照してください。

18.4.4 クラスタ内の各管理対象サーバーでのサービス移行ポリシーの設定

クラスタ内の各サーバーの移行設定を変更した後、WebLogic管理コンソールを使用して、サービスを識別し、クラスタ内の各管理対象サーバーの移行ポリシーを設定できます。

1. 管理コンソールにログインしていない場合は、ログインして、「ロックして編集」をクリックします。

2. 「ドメイン構造」ペインで、「環境」、「クラスタ」、「移行可能なターゲット」の順に展開します。

3. クラスタで最初の管理対象サーバーの名前をクリックします。

4. 「移行」タブをクリックします。

5. 「サービス移行ポリシー」ドロップダウン・メニューからクラスタ用の適切なポリシーを選択します。
詳細は、「サービス移行ポリシーの選択について」を参照してください。

6. 「保存」をクリックします。

7. クラスタ内の追加の管理対象サーバーごとに手順2から6を繰り返します。

8. 変更をアクティブ化します。

9. クラスタ内の管理対象サーバーを再起動します。

18.4.5 自動サービス移行の検証

クラスタおよび管理対象サーバーの自動サービス移行を構成した後に、次のように構成を検証します。

1. 管理コンソールにログインしていない場合は、ログインします。

2. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に選択します。

3. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に開きます。

4. 「移行可能なターゲット」をクリックします。

5. 「制御」タブをクリックします。
コンソールに移行可能なターゲットおよびその現在のホスト・サーバーのリストが表示されます。

6. 「移行可能なターゲット」表で、移行可能なターゲットのいずれか1つの行を選択します。

7. 「現在のホスト・サーバー」列の値に注意してください。

8. オペレーティング・システムのコマンドラインを使用して、最初の管理対象サーバーを停止します。

次のコマンドを使用して、管理対象サーバー・プロセスを終了し、クラッシュ・シナリオをシミュレートします。

kill -9 pid

この例では、pidを、管理対象サーバーのプロセスID (PID)に置き換えます。次のUNIXコマンドを実行すると、PIDを確認できます。

ps -ef | grep managed_server_name

プロセスを強制終了した後に、管理対象サーバーが、最初にプロセスを強制終了した後に自動的に起動するよう構成されている場合があります。この場合、再度kill –9コマンドを使用して、2番目のプロセスを強制終了する必要があります。

9. ノード・マネージャが動作しているターミナル・ウィンドウ(コンソール)を確認します。

選択した管理対象サーバーでエラーが発生したことを示すメッセージが表示されます。次のようなメッセージが表示されます。

<INFO> <domain_name> <server_name>
<The server 'server_name' with process id 4668 is no longer alive; waiting for the process to die.>
<INFO> <domain_name> <server_name>
<Server failed during startup. It may be retried according to the auto restart configuration.>
<INFO> <domain_name> <server_name>
<Server failed but will not be restarted because the maximum number of restart attempts has been exceeded.>

10. Oracle WebLogic Server管理コンソールに戻り、移行可能なターゲットの表をリフレッシュし、移行可能なターゲットがクラスタ内の残りの実行中の管理対象サーバーに転送されていることを確認します。

- 強制終了したプロセスの現在のホスト・サーバーが更新され、別のホストに移行されたことが表示されていることを確認します。

- プロセスの「最後の移行のステータス」列の値が「成功」であることを確認します。

11. 現在サービスをホストしている管理対象サーバーのログ・ファイルを開いて確認し、JTAエラーまたはJMSエラーを探します。

注意:

JMSテストの場合は、宛先からメッセージ数を取得し、移行可能ターゲットにスタック・メッセージがないことを確認することをお薦めします。

たとえば、共通分散宛先(UDD)の場合は次のとおりです。

a. 管理コンソールのJMSサブデプロイメント・モジュールにアクセスします。
「ドメイン構造」ペインで、「サービス」、「メッセージング」、「JMSモジュール」の順に選択します。

b. 「JMSモジュール」をクリックします。

c. 「リソースのサマリー」表で宛先をクリックし、「宛先」->「モニタリング」を選択して「メッセージ総数」と「保留メッセージ数」を取得します

d. 「モニタリング」タブを選択し、「宛先」表の「メッセージ総数」と「保留メッセージ数」の値を確認します。

18.4.6 自動サービス移行後のサービスのフェイルバック

自動サービス移行が発生した場合、Oracle WebLogic Serverでは、サーバーがオンラインに戻りクラスタに再度参加するときに、サービスが元のサーバーにフェイルバックすることはサポートされません。

そのため、フェイルオーバー中に、自動サービス移行によって特定のJMSサービスがバックアップ・サーバーに移行されたあとは、元のサーバーがオンラインに戻っても、サービスが元のサーバーに移行されることはありません。かわりに、サービスを元のサーバーに手動で移行する必要があります。

サービスを元のサーバーにフェイルバックするには、次の手順を実行します。

1. まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

2. 「ドメイン構造」ツリーで、「環境」、「クラスタ」の順に開き、「移行可能なターゲット」を選択します。

3. 1つ以上の移行可能なターゲットを一度に移行するには、「移行可能なターゲットのサマリー」ページで次を実行します。

a. 「制御」タブをクリックします。

b. チェック・ボックスを使用して、移行する1つまたは複数の移行可能なターゲットを選択します。

c. 「移行」をクリックします。

d. 「新しいホスト・サーバー」ドロップダウンを使用して、元の管理対象サーバーを選択します。

e. 「OK」をクリックします。
JMS関連サービスを移行するためのリクエストが発行され、構成編集ロックが解除されます。「移行可能なターゲット」表の「最後の移行のステータス」列に、リクエストされた移行が成功したのか、失敗したのかが示されます。

4. 特定の移行可能なターゲットを移行するには、「移行可能なターゲットの概要」ページで、次の手順を実行します。

a. 移行する移行可能なターゲットを選択します。

b. 「制御」タブをクリックします。

c. 再度、移行する移行可能なターゲットを選択します。

d. 「移行」をクリックします。

e. 「新しいホスト・サーバー」ドロップダウンを使用して、移行可能なターゲットのための新しいサーバーを選択します。

f. 「OK」をクリックします。

19 エンタープライズ・デプロイメント用のシングル・サインオンの構成

Oracle Access Managerでシングル・サインオンを有効化するには、Oracle HTTP Server WebGateを構成する必要があります。

- Oracle HTTP Server WebGateについて
Oracle HTTP Server WebGateは、HTTPリクエストをインターセプトし、それを認証および認可のために既存のOracle Access Managerインスタンスに転送するWebサーバー・プラグインです。

- Oracle HTTP Server Webgateの構成の一般的な前提条件
Oracle HTTP Server WebGateを構成可能にするには、Oracle Access Managerの認定バージョンをインストールおよび構成しておく必要があります。

- OHS 12c Webgateの構成に関するエンタープライズ・デプロイメントの前提条件
Oracle HTTP Server Webgateを構成してエンタープライズ・デプロイメントでシングル・サインオンを有効化する場合、この項で説明されている前提条件を考慮してください。

- エンタープライズ・デプロイメント用のOracle HTTP Server 12c WebGateの構成
WEBHOST1とWEBHOST2の両方でOracle HTTP Server 12c WebGate for Oracle Access Managerを構成するには、次の手順を実行する必要があります。

- Oracle Access ManagerへのOracle HTTP Server WebGateの登録
Oracle Access Manager管理コンソールを使用すると、Oracle Access ManagerにWebGateエージェントを登録できます。

- WebLogic Server認証プロバイダの設定
WebLogic Server認証プロバイダを設定するには、構成ファイルをバックアップし、Oracle Access Manager IDアサーション・プロバイダを設定し、プロバイダの順序を設定します。

- Oracle Access Managerを使用したOracle ADFおよびOPSSセキュリティの構成
一部のOracle Fusion Middleware管理コンソールでは、Oracle Access Managerシングル・サインオン(SSO)と統合可能なOracle Application Development Framework (Oracle ADF)セキュリティが使用されます。これらのアプリケーションでは、ユーザー認証にOracle Platform Security Services (OPSS) SSOを利用できますが、最初にドメインレベルのjps-config.xmlファイルを構成して、これらの機能を有効化する必要があります。

- 追加のシングル・サインオン構成

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

19.1 Oracle HTTP Server Webgateについて

Oracle HTTP Server WebGateは、HTTPリクエストをインターセプトし、それを認証および認可のために既存のOracle Access Managerインスタンスに転送するプラグインです。

Oracle Fusion Middleware 12cでは、WebGateソフトウェアはOracle HTTP Server 12cソフトウェア・インストールの一部としてインストールされます。

WebGateの詳細は、『Oracle Access Management管理者ガイド』のOAM 11gエージェントの登録と管理に関する項を参照してください。

19.2 Oracle HTTP Server Webgateの構成の一般的な前提条件

Oracle HTTP Server WebGateを構成するには、動作保証されたバージョンのOracle Access Managerをインストールして構成しておく必要があります。

このドキュメントの公開時点では、サポートされるOracle Access Managerバージョンは11gリリース2 (11.1.2.2)および11gリリース2 (11.1.2.3)です。最新の情報は、Oracle Fusion Middlewareのサポートされるシステム構成ページで、ご使用のリリース向けの動作保証情報のドキュメントを参照してください。

注意:

本番環境の場合は、エンタープライズ・デプロイメントをホストしているマシンではなく、専用の環境にOracle Access Managerをインストールすることを強くお薦めします。

Oracle Access Managerの詳細は、Oracleヘルプ・センターのMiddlewareドキュメントにある最新のOracle Identity and Access Managementドキュメントを参照してください。

19.3 OHS 12c WebGateを構成するためのエンタープライズ・デプロイメントの前提条件

Oracle HTTP Server Webgateを構成してエンタープライズ・デプロイメントでシングル・サインオンを有効化する場合、この項で説明されている前提条件を考慮してください。

- Oracle Access Managerをセキュアな高可用性本番環境の一部としてデプロイすることをお薦めします。エンタープライズ環境でのOracle Access Managerのデプロイの詳細は、ご使用のOracle Identity and Access Managementのバージョンのエンタープライズ・デプロイメント・ガイドを参照してください。

- WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlに対するシングル・サインオンを有効にするには、Oracle Access Managerが使用している(Oracle Internet DirectoryやOracle Unified Directoryなど)ディレクトリ・サービスに中心的なLDAPプロビジョニング管理ユーザーを追加する必要があります。LDAPディレクトリに追加する必要のあるユーザーとグループの詳細は、「新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング」の手順に従ってください。

19.4 エンタープライズ・デプロイメントでのOracle HTTP Server 12c WebGateの構成

WEBHOST1とWEBHOST2の両方でOracle HTTP Server 12c WebGate for Oracle Access Managerを構成するには、次の手順を実行する必要があります。

次の手順では、OHS_ORACLE_HOMEやOHS_CONFIG_DIRなどのディレクトリ変数を、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されている値で置き換えます。

1. Web層ドメインに対して完全バックアップを実行します。

2. ディレクトリを、Oracle HTTP Server Oracleホームの次の場所に変更します。
cd OHS_ORACLE_HOME/webgate/ohs/tools/deployWebGate/

3. 次のコマンドを実行して、WebGateインスタンス・ディレクトリを作成し、OHSインスタンスでのWebGateロギングを有効にします。

./deployWebGateInstance.sh -w OHS_CONFIG_DIR -oh OHS_ORACLE_HOME

4. deployWebGateInstanceコマンドによってwebgateディレクトリとサブディレクトリが作成されたことを確認します。

ls -lat OHS_CONFIG_DIR/webgate/
total 16
drwxr-x---+ 8 orcl oinstall 20 Oct  2 07:14 ..
drwxr-xr-x+ 4 orcl oinstall  4 Oct  2 07:14 .
drwxr-xr-x+ 3 orcl oinstall  3 Oct  2 07:14 tools
drwxr-xr-x+ 3 orcl oinstall  4 Oct  2 07:14 config

5. 次のコマンドを実行し、LD_LIBRARY_PATH環境変数にOHS_ORACLE_HOME/libディレクトリ・パスが含まれるようにします。
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:OHS_ORACLE_HOME/lib

6. ディレクトリを次のディレクトリに変更します。
OHS_ORACLE_HOME/webgate/ohs/tools/setup/InstallTools

7. 次のコマンドをInstallToolsディレクトリから実行します。
./EditHttpConf -w OHS_CONFIG_DIR -oh OHS_ORACLE_HOME -o output_file_name

注意:

-oh OHS_ORACLE_HOMEおよび-o output_file_nameパラメータはオプションです。

このコマンドは、次の内容を実行します。

- Oracle HTTP Server Oracleホームのapache_webgate.templateファイルをOracle HTTP Serverの構成ディレクトリの新しいwebgate.confファイルにコピーします。

- httpd.confファイルに1行追加して更新し、webgate.confが含まれるようにします。

- WebGate構成ファイルを生成します。このファイルのデフォルト名はwebgate.confですが、コマンドに対して-o output_file_name引数を使用することにより、カスタム名を使用できます。

19.5 Oracle Access ManagerでのOracle HTTP Server WebGateの登録

Oracle Access Manager管理コンソールを使用すると、Oracle Access ManagerにWebGateエージェントを登録できます。

詳細は、『Oracle Access Management管理者ガイド』のコンソールを使用したOAMエージェントの登録に関する項を参照してください。

- RREGインバンドおよびアウトオブバンド・モードについて

- OAM11gRequest.xmlファイルの標準プロパティの更新

- エンタープライズ・デプロイメント用の保護されたリソース、パブリック・リソースおよび除外されたリソースの更新

- RREGツールの実行

- RREGによって生成されるファイルおよびアーティファクト

- 生成済のアーティファクトのOracle HTTP Server WebGateインスタンスの場所へのコピー

- Oracle HTTP ServerインスタンスでのMD5証明書の署名の有効化

- Oracle HTTP Serverインスタンスの再起動

19.5.1 RREGインバンドおよびアウトオブバンド・モードについて

RREGツールは、インバンドとアウトオブバンドという2つのモードのいずれか1つで実行できます。

Oracle Access Managerサーバーにアクセスして、Oracle Access Manager Oracleホームから自分でRREGツールを実行する権限がある場合は、インバンド・モードを使用します。RREGツールの実行後に、生成されたアーティファクトとファイルをWebサーバーの構成ディレクトリにコピーできます。

Oracle Access Managerサーバーに対する権限またはアクセス権がない場合は、アウトオブバンド・モードを使用します。たとえば、一部の組織では、Oracle Access Managerサーバー管理者のみが、サーバー・ディレクトリにアクセスしてサーバーでの管理タスクを実行する権限を持ちます。アウトオブバンド・モードでは、プロセスは次のように機能します。

1. Oracle Access Managerサーバー管理者からRREGアーカイブ・ファイル(RREG.tar.gz)のコピーが提供されます。

2. サーバー管理者によって提供されたRREG.tar.gzファイルを展開します。
次に例を示します。

gunzip RREG.tar.gz

tar -xvf RREG.tar

RREGアーカイブを解凍した後、次の場所にエージェントを登録するためのツールを見つけることができます。

RREG_HOME/bin/oamreg.sh

この例では、RREG_Homeは、RREGアーカイブの内容を展開したディレクトリです。

3. 「OAM11gRequest.xmlファイルの標準プロパティの更新」の手順を使用して、OAM11GRequest.xmlファイルを更新し、完了したOAM11GRequest.xmlファイルをOracle Access Managerサーバー管理者に送信します。

4. その後、Oracle Access Managerサーバー管理者は、「アウトオブバンド・モードでのRREGツールの実行」の手順を使用して、RREGツールを実行し、AgentID_response.xmlファイルを生成します。

5. Oracle Access Managerサーバー管理者から、AgentID_response.xmlファイルが送信されます。

6. 「アウトオブバンド・モードでのRREGツールの実行」の手順を使用して、クライアント・システムで、AgentID_response.xmlファイルでRREGツールを実行し、必要なアーティファクトとファイルを生成します。

19.5.2 OAM11gRequest.xmlファイルでの標準プロパティの更新

WebGateエージェントをOracle Access Managerに登録するには、OAM11gRequest.xmlファイルで必要なプロパティを更新しておく必要があります。

注意:

提供されたXMLファイルのほとんどのパラメータにデフォルト値を使用する場合は、リストされていないすべてのフィールドにデフォルト値が使用される簡略バージョン(OAM11gRequest_short.xml)を使用できます。

注意:
プライマリ・サーバー・リストでは、OAMサーバーのデフォルト名はOAM_SERVER1およびOAM_SERVER2と示されます。サーバー名が環境で変更された場合、リストでこれらの名前が変更されます。

このタスクを実行するには、次のようにします。

1. インバンド・モードを使用している場合は、いずれかのOAMサーバー上の次の場所にディレクトリを変更します。

OAM_ORACLE_HOME/oam/server/rreg/input

アウトオブバンド・モードを使用している場合、WEBHOST1サーバー上でRREGアーカイブを解凍した場所にディレクトリを変更します。

2. 環境に固有の名前を使用して、OAM11GRequest.xmlファイル・テンプレートのコピーを作成します。
cp OAM11GRequest.xml OAM11GRequest_edg.xml

3. ファイルにリストされているプロパティを確認し、OAM11GRequest.xmlファイルのコピーを更新して、プロパティが環境に固有のホスト名およびその他の値を参照するようにします。

OAM11gRequest.xml プロパティ

設定内容

serverAddress

Oracle Access Managerドメイン内の管理サーバーのホストおよびポート。

agentName

エージェントのカスタム名。通常、シングル・サインオン用に構成しているFusion Middleware製品を識別する名前を使用します。

applicationDomain

シングル・サインオン用に構成しているWeb層ホストおよびFMWコンポーネントを識別する値。

security

Oracle Access Managementサーバーで構成されたセキュリティ・モードに設定する必要があります。これは、オープン、簡易、証明書の3つのモードのいずれかです。

注意:

エンタープライズ・デプロイメントでは、認証および認可トラフィックの暗号化にカスタム・セキュリティ証明書を実装する追加の要件が存在する場合を除き、簡易モードを使用することをお薦めします。

オープン・モードではOracle Access Managerサーバーとの間のトラフィックが暗号化されないため、ほとんどの場合でオープン・モードを使用しないでください。

証明書モードの使用方法やOracle Access Managerでサポートされるセキュリティ・モード全般については、『Oracle Access Management管理者ガイド』のOAMサーバーとWebGateの間のセキュア通信に関する項 を参照してください。

cachePragmaHeader

private

cacheControlHeader

private

ipValidation

0

<ipValidation>0<ipValidation>

ipValidationExceptions

フロントエンドのロード・バランサのIPアドレス。次に例を示します。

<ipValidationExceptions>
<ipAddress>130.35.165.42</ipAddress>
</ipValidation>

agentBaseUrl

Oracle HTTP 12c WebGatesがインストールされたWEBHOSTnマシンの前にあるフロントエンド・ロード・バランサVIPのホストおよびポートを使用した完全修飾URL。

次に例を示します。

<agentBaseUrl>
https://wcp.example.com:443
</agentBaseUrl>

virtualHost

agentBaseUrlよりも保護を強化する場合(管理VIPのSSO保護など)、trueに設定します。

hostPortVariationsList

WebGateによって保護されるロード・バランサURLごとに、hostPortVariationのホストおよびポート要素を追加します。

次に例を示します。

<hostPortVariationsList>
<hostPortVariations>
<host>wcpinternal.example.com</host>
<port>80</port>
</hostPortVariations>
<hostPortVariations>
<host>admin.example.com</host>
<port>80</port>
</hostPortVariations>

19.5.3 エンタープライズ・デプロイメント用の保護されたリソース、パブリック・リソースおよび除外されたリソースの更新

シングル・サインオン用にOracle Fusion Middleware環境を設定する場合は、Oracle Access Managerでシングル・サインオンによって保護する一連のURLを識別します。これらは、OAM11gRequest.xmlファイルの特定のセクションを使用して識別します。URLを識別する手順は次のとおりです。

1. コピーしたOAM11GRequest_edg.xmlファイルがまだ編集用に開かれていない場合は、ファイルを探してテキスト・エディタで開きます。

詳細は、次を参照してください。

- OAM11gRequest.xmlファイルの標準プロパティの更新

2. ファイルのサンプル・エントリを削除して、次の例に示されているようにファイルの適切なセクションに保護リソース、パブリック・リソースおよび除外リソースのリストを入力します。

注意:

Oracle Access Manager 11gリリース2 (11.1.2.2)以降を使用している場合は、以前のバージョンのOracle Access Managerとの下位互換性のためにワイルドカード構文(.../*)を使用したエントリがこの例に含まれていることに注意してください。

<protectedResourcesList>
<!-- FMW/WLS Common Infrastruture Protected Resources-->
<resource>/console/.../*</resource>
<resource>/console</resource>
<resource>/consolehelp/.../*</resource>
<resource>/consolehelp</resource>
<resource>/em/.../*</resource>
<resource>/em</resource>
<!-- WebCenter Portal Protected Resources -->
<resource>/owc_discussions/admin/.../*</resource>
<resource>/owc_discussions/login!default.jspa</resource>
<resource>/owc_discussions/login!withredirect.jspa</resource>
<resource>/owc_discussions/login.jspa</resource>
<resource>/pagelets/admin/.../*</resource>
<resource>/rest/api</resource>
<resource>/rest/api/activities/.../*</resource>
<resource>/rest/api/activities</resource>
<resource>/rest/api/catalog/.../*</resource>
<resource>/rest/api/catalog</resource>
<resource>/rest/api/discussions/.../*</resource>
<resource>/rest/api/discussions</resource>
<resource>/rest/api/feedback/.../*</resource>
<resource>/rest/api/feedback</resource>
<resource>/rest/api/messageBoards/.../*</resource>
<resource>/rest/api/messageBoards</resource>
<resource>/rest/api/navigations/.../*</resource>
<resource>/rest/api/navigations</resource>
<resource>/rest/api/people/.../*</resource>
<resource>/rest/api/people</resource>
<resource>/rest/api/preferences/general/.../*</resource>
<resource>/rest/api/preferences/general</resource>
<resource>/rest/api/resourceIndex</resource>
<resource>/rest/api/searchcollection/.../*</resource>
<resource>/rest/api/searchcollection</resource>
<resource>/rest/api/searchresults/.../*</resource>
<resource>/rest/api/searchresults</resource>
<resource>/rest/api/spaces/.../*</resource>
<resource>/rest/api/spaces</resource>
<resource>/rest/api/taggeditems/.../*</resource>
<resource>/rest/api/taggeditems</resource>
<resource>/rest/api/taggingusers/.../*</resource>
<resource>/rest/api/taggingusers</resource>
<resource>/rest/api/tags/.../*</resource>
<resource>/rest/api/tags</resource>
<resource>/rest/api/v1/resourceIndex</resource>
<resource>/rest/api/who/.../*</resource>
<resource>/rest/api/who</resource>
<resource>/rsscrawl/.../*</resource>
<resource>/rsscrawl</resource>
<resource>/rss/rssservlet</resource>
<resource>/services-producer/adfAuthentication</resource>
<resource>/sesUserAuth/.../*</resource>
<resource>/sesUserAuth</resource>
<resource>/webcenter/adfAuthentication</resource>
<!-- WebCenter Content Protected Resources -->
<resource>/adfAuthentication</resource>
<resource>/cs/groups/.../*</resource>
<resource>/cs/groups</resource>
<resource>/cs/idcplg/.../*</resource>
<resource>/cs/idcplg</resource>
<resource>/dc-client/adfAuthentication</resource>
<resource>/dc-console/adfAuthentication</resource>
<resource>/ibr/adfAuthentication</resource>
<resource>/imaging/faces/.../*</resource>
<resource>/imaging/faces</resource>
<resource>/wcc/adfAuthentication</resource>
<!-- SOA Protected Resources -->
<resource>/DefaultToDoTaskFlow/.../*</resource>
<resource>/DefaultToDoTaskFlow</resource>
<resource>/EssHealthCheck/.../*</resource>
<resource>/EssHealthCheck</resource>
<resource>/b2bconsole/.../*</resource>
<resource>/b2bconsole</resource>
<resource>/ess/.../*</resource>
<resource>/ess</resource>
<resource>/inspection.wsil</resource>
<resource>/integration/worklistapp/.../*</resource>
<resource>/integration/worklistapp</resource>
<resource>/sdpmessaging/userprefs-ui/.../*</resource>
<resource>/sdpmessaging/userprefs-ui</resource>
<resource>/soa-/composer/.../*</resource>
<resource>/soa/composer/.../*</resource>
<resource>/soa/composer</resource>
<resource>/soa/composer</resource>
<resource>/soa-infra/cluster/info/.../*</resource>
<resource>/soa-infra/cluster/info</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</resource>
<resource>/workflow/DefaultToDoTaskFlow/.../*</resource>
<resource>/workflow/DefaultToDoTaskFlow</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist/.../*</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist</resource>
<!-- SOA Portal Taskflow Protected Resources (For WCP/SOA integrated systems only) -->
<resource>/workflow/WebCenterWorklistDetail/faces/adf.task-flow/…/*</resource>
<resource>/workflow/WebCenterWorklistDetail/faces/adf.task-flow</resource>
</protectedResourcesList>
<publicResourcesList>
<!-- WebCenter Portal Public Resources-->
<resource>/owc_discussions/.../*</resource>
<resource>/owc_discussions</resource>
<resource>/pagelets</resource>
<resource>/pagelets/welcome</resource>
<resource>/rss/.../*</resource>
<resource>/rss</resource>
<resource>/services-producer</resource>
<resource>/webcenterhelp/.../*</resource>
<resource>/webcenterhelp</resource>
<resource>/webcenter/.../*</resource>
<resource>/webcenter</resource>
<resource>/webcenterhelp</resource>
<resource>/wsrp-tools</resource>
<!-- WebCenter Content Public Resources -->
<resource>/_ocsh/.../*</resource>
<resource>/_ocsh</resource>
<resource>/_dav/.../*</resource>
<resource>/_dav</resource>
<resource>/cs/.../*</resource>
<resource>/cs</resource>
<resource>/dc-console/.../*</resource>
<resource>/dc-console</resource>
<resource>/ibr/.../*</resource>
<resource>/ibr</resource>
<resource>/imaging/.../*</resource>
<resource>/imaging</resource>
<resource>/wcc/.../*</resource>
<resource>/wcc</resource>
<!-- SOA Public Resources (For SOA systems only) -->
<resource>/soa-infra/directWSDL</resource>
<!-- SOA Portal Taskflow Public Resources (For WCP/SOA integrated systems only) -->
<resource>/workflow/WebCenterWorklistDetail/…/*</resource>
<resource>/workflow/WebCenterWorklistDetail</resource>
</publicResourcesList>
<excludedResourcesList>
<resource>/favicon.ico</resource>
<!-- FMW/WLS Common Infrastruture Excluded Resources -->
<resource>/wsm-pm/.../*</resource>
<resource>/wsm-pm</resource>
<!-- WebCenter Portal Excluded Resources-->
<resource>/collector/.../*</resource>
<resource>/collector</resource>
<resource>/owc_discussions/OWCDiscussionsServiceAuthenticated</resource>
<resource>/owc_discussions/OWCDiscussionsServiceAuthenticated/.../*</resource>
<resource>/owc_discussions/OWCDiscussionsServicePublic</resource>
<resource>/owc_discussions/OWCDiscussionsServicePublic/.../*</resource>
<resource>/pagelets/api/v2/ensemble/pagelets</resource>
<resource>/pagelets/api/v2/ensemble/pagelets/.../*</resource>
<resource>/pagelets/ensemblestatic/.../*</resource>
<resource>/pagelets/ensemblestatic</resource>
<resource>/portalTools/.../*</resource>
<resource>/portalTools</resource>
<resource>/rest/api/cmis/.../*</resource>
<resource>/rest/api/cmis/</resource>
<resource>/rsscrawl</resource>
<resource>/rsscrawl/.../*</resource>
<resource>/sesUserAuth</resource>
<resource>/sesUserAuth/.../*</resource>
<resource>/webcenter/SpacesWebService</resource>
<resource>/webcenter/SpacesWebService/.../*</resource>
<resource>/wsrp-tools/portlets/.../*</resource>
<resource>/wsrp-tools/portlets</resource>
<!-- WebCenter Content Excluded Resources -->
<resource>/axf-ws</resource>
<resource>/axf-ws/.../*</resource>
<resource>/cs/common/idcapplet.jar</resource>
<resource>/cs/images</resource>
<resource>/cs/images/.../*</resource>
<resource>/dc-client</resource>
<resource>/dc-client/.../*</resource>
<resource>/idcnativews</resource>
<resource>/idcnativews/.../*</resource>
<resource>/imaging/lib</resource>
<resource>/imaging/lib/.../*</resource>
<resource>/imaging/ws</resource>
<resource>/imaging/ws/.../*</resource>
<!-- SOA Portal Taskflow Excluded Resources (For WCP/SOA integrated systems only) -->
<resource>/soa-infra/services/default/CommunityWorkflows/**</resource>
<resource>/soa-infra/services/default/CommunityWorkflows*</resource>
<!-- SOA Excluded Resources (For SOA systems only) -->
<resource>/b2b/services</resource>
<resource>/b2b/services/.../*</resource>
<resource>/integration/services</resource>
<resource>/integration/services/.../*</resource>
<resource>/soa-infra/services</resource>
<resource>/soa-infra/services/.../*</resource>
<resource>/ucs/messaging/webservice</resource>
<resource>/ucs/messaging/webservice/.../*</resource>
</excludedResourcesList>

3. OAM11GRequest_edg.xmlファイルを保存し、閉じます。

19.5.4 RREGツールの実行

次のトピックでは、RREGツールを実行してOracle Access ManagerにOracle HTTP Server WebGateを登録する方法について説明します。

- インバンド・モードでのRREGツールの実行

- アウトオブバンド・モードでのRREGツールの実行

19.5.4.1 RREGツールのインバンド・モードでの実行

RREGツールをインバンド・モードで実行する手順は次のとおりです。

1. RREGホーム・ディレクトリに移動します。
インバンド・モードを使用している場合、RREGディレクトリはOracle Access Manager Oracleホーム内にあります。

OAM_ORACLE_HOME/oam/server/rreg

アウトオブバンド・モードを使用している場合、RREGホーム・ディレクトリは、RREGアーカイブを解凍した場所になります。

2. RREGホーム・ディレクトリで、binディレクトリに移動します。

cd RREG_HOME/bin/

3. ファイルを実行できるように、oamreg.shコマンドの権限を設定します。

chmod +x oamreg.sh

4. 次のコマンドを実行します。

./oamreg.sh inband RREG_HOME/input/OAM11GRequest_edg.xml

この例の説明は、次のとおりです。

- 編集されたOAM11GRequest.xmlファイルがRREG_HOME/inputディレクトリに配置されていることが前提となります。

- このコマンドの出力は、次のディレクトリに保存されます。

RREG_HOME/output/

次の例はRREGセッションのサンプルです。

Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: /u01/oracle/products/fmw/iam_home/oam/server/rreg/client/rreg/input/OAM11GRequest_edg.xml
Enter admin username:weblogic_idm
Username: weblogic_idm
Enter admin password:
Do you want to enter a Webgate password?(y/n):
n
Do you want to import an URIs file?(y/n):
n

----------------------------------------
Request summary:
OAM11G Agent Name:WCC1221_EDG_AGENT
URL String:null
Registering in Mode:inband
Your registration request is being sent to the Admin server at: http://host1.example.com:7001
----------------------------------------

Jul 08, 2015 7:18:13 PM oracle.security.jps.util.JpsUtil disableAudit
INFO: JpsUtil: isAuditDisabled set to true
Jul 08, 2015 7:18:14 PM oracle.security.jps.util.JpsUtil disableAudit
INFO: JpsUtil: isAuditDisabled set to true
Inband registration process completed successfully! Output artifacts are created in the output folder.

19.5.4.2 RREGツールのアウトオブバンド・モードでの実行

WEBHOSTサーバーでRREGツールをアウトオブバンド・モードで実行するために、管理者は次のコマンドを使用します。

RREG_HOME/bin/oamreg.sh outofband input/OAM11GRequest.xml

この例の説明は、次のとおりです。

- RREG_HOMEを、サーバーでRREGアーカイブ・ファイルが解凍された場所で置き換えます。

- 編集されたOAM11GRequest.xmlファイルは、RREG_HOME/inputディレクトリに配置されています。

- RREGツールでは、このコマンドの出力(AgentID_response.xmlファイル)が次のディレクトリに保存されます。

RREG_HOME/output/

Oracle Access Managerサーバー管理者は、AgentID_response.xmlをOAM11GRequest.xmlファイルを提供したユーザーに送信できます。

Webサーバーのクライアント・マシンでRREGツールをアウトオブバンド・モードで実行するには、次のコマンドを使用します。

RREG_HOME/bin/oamreg.sh outofband input/AgentID_response.xml

この例の説明は、次のとおりです。

- RREG_HOMEを、クライアント・システムでRREGアーカイブ・ファイルを解凍した場所で置き換えます。

- Oracle Access Managerサーバー管理者から提供されたAgentID_response.xmlファイルは、RREG_HOME/inputディレクトリにあります。

- RREGツールでは、このコマンドの出力(WebGateソフトウェアの登録に必要なアーティファクトとファイル)がクライアント・マシンの次のディレクトリに保存されます。

RREG_HOME/output/

19.5.5 RREGによって生成されるファイルおよびアーティファクト

RREGツールによって生成されるファイルは、WebGateとOracle Access Managerサーバーの間の通信に使用しているセキュリティ・レベルによって異なります。サポートされるセキュリティ・レベルの詳細は、『Oracle Access Management管理者ガイド』のOAMサーバーとWebGate間の通信のセキュア設定に関する項を参照してください。

この項のRREG_HOMEは、RREGツールを実行したディレクトリのパスで置き換える必要があることに注意してください。これは通常、Oracle Access Managerサーバーの次のディレクトリまたはRREGアーカイブを解凍したディレクトリになります(アウトオブバンド・モードを使用している場合)。

OAM_ORACLE_HOME/oam/server/rreg/client

次の表は、Oracle Access Managerのセキュリティ・レベルにかかわらず、RREGツールによって常に生成されるアーティファクトを示しています。

ファイル

場所

cwallet.sso

- RREG_HOME/output/Agent_ID/ - WebGate 11g (11.1.2.3)の場合。

- RREG_HOME/output/Agent_ID/wallet - WebGate 11g (11.1.2.2)およびOHS 12cの場合。

ObAccessClient.xml

RREG_HOME/output/Agent_ID/

次の表は、Oracle Access ManagerにSIMPLEまたはCERTセキュリティ・レベルを使用している場合に作成される追加ファイルを示しています。

ファイル

場所

aaa_key.pem

RREG_HOME/output/Agent_ID/

aaa_cert.pem

RREG_HOME/output/Agent_ID/

password.xml

RREG_HOME/output/Agent_ID/

password.xmlファイルには、SSLで使用される秘密鍵を暗号化するための不明瞭化されたグローバル・パスフレーズが含まれます。このパスフレーズは、サーバーで使用されているパスフレーズと異なるものを使用できます。

RREGによって生成されたファイルを使用して証明書リクエストを生成し、サードパーティの認証局に署名を求めることができます。既存の証明書をインストールするには、既存のaaa_cert.pemおよびaaa_chain.pemファイルをpassword.xmlおよびaaa_key.pemと合せて使用する必要があります。

19.5.6 生成済アーティファクトのOracle HTTP Server WebGateインスタンスの場所へのコピー

RREGツールによって必要なアーティファクトが生成された後で、RREG_Home/output/agent_IDディレクトリからWeb層ホスト上のOracle HTTP Server構成ディレクトリに、アーティファクトを手動でコピーします。

Oracle HTTP Server構成ディレクトリのファイルの場所は、Oracle Access Managerセキュリティ・モード設定(OPEN、SIMPLEまたはCERT)によって異なります。

次の表に、Oracle Access Managerのセキュリティ・モード設定に基づいて、生成されたアーティファクトごとにOracle HTTP Server構成ディレクトリの必須の場所を示します。存在しない場合はディレクトリの作成が必要になることがあります。たとえば、walletディレクトリが構成ディレクトリに存在しない場合があります。

注意:

エンタープライズ・デプロイメントでは、認証および認可トラフィックの暗号化にカスタム・セキュリティ証明書を実装する追加の要件が存在する場合を除き、簡易モードを使用することをお薦めします。オープン・モードまたは証明書モードの使用方法の詳細は、利便性のため、ここで説明します。

オープン・モードではOracle Access Managerサーバーとの間のトラフィックが暗号化されないため、オープン・モードを使用しないでください。

証明書モードの使用方法やOracle Access Managerでサポートされるセキュリティ・モード全般については、『Oracle Access Management管理者ガイド』のOAMサーバーとWebGateの間のセキュア通信に関する項 を参照してください。

ファイル

OPENモードを使用する場合の場所

SIMPLEモードを使用する場合の場所

CERTモードを使用する場合の場所

wallet/cwallet.sso

OHS_CONFIG_DIR/webgate/config/wallet

OHS_CONFIG_DIR/webgate/config/wallet/

注意:
デフォルトでは、ウォレット・フォルダは使用できません。OHS_CONFIG_DIR/webgate/config/の下にwalletフォルダを作成します。

OHS_CONFIG_DIR/webgate/config/wallet/

ObAccessClient.xml

OHS_CONFIG_DIR/webgate/config

OHS_CONFIG_DIR/webgate/config/

OHS_CONFIG_DIR/webgate/config/

password.xml

N/A

OHS_CONFIG_DIR/webgate/config/

OHS_CONFIG_DIR/webgate/config/

aaa_key.pem

N/A

OHS_CONFIG_DIR/webgate/config/simple/

OHS_CONFIG_DIR/webgate/config/

aaa_cert.pem

N/A

OHS_CONFIG_DIR/webgate/config/simple/

OHS_CONFIG_DIR/webgate/config/

注意:
ObAccessClient.xmlをWEBHOST1およびWEBHOST2に再デプロイする必要がある場合は、サーバーからObAccessClient.xmlのキャッシュ・コピーを削除します。WEBHOST1のキャッシュの場所は次のとおりです。

OHS_DOMAIN_HOME/servers/ohs1/cache/

WEBHOST2上の2番目のOracle HTTP Serverインスタンスでも同様の手順を実行する必要があります。

OHS_DOMAIN_HOME/servers/ohs2/cache/

19.5.7 Oracle HTTP ServerインスタンスでのMD5証明書の署名の有効化

Oracle Access Managementサーバーの一部のリリースでは、適切にアップグレードまたはパッチ適用されていない場合にMD5署名を使用することで簡易モードのセキュリティ証明書を実装します。Webゲートを簡易セキュリティ・モードで使用することで、Oracle HTTP Server 12.2.1.2.0以降をポリシーの強制ポイントとして構成する場合、MD5署名のサポートを手動で有効にする必要があります。

各OHSインスタンスでMD5証明書の署名を有効にするには、次の手順を実行します。

1. WEBHOST1で、OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1フォルダに移動します。

2. ohs.plugins.nodemanager.propertiesファイルを開き、次の行を追加してファイルを保存します。

environment.ORACLE_SSL_ALLOW_MD5_CERT_SIGNATURES = 1

3. WEBHOSTnサーバーの他のすべてのインスタンスについて、手順1および2を繰り返します。
たとえば、WEBHOST2のohs2インスタンスです。

注意:
変更は、次のトピックでインスタンスを再起動すると有効になります。

19.5.8 Oracle HTTP Serverインスタンスの再起動

Oracle HTTP Serverインスタンスの再起動の詳細は、『Oracle HTTP Server管理者ガイド』のWLSTを使用したOracle HTTP Serverインスタンスの再起動に関する項を参照してください。

WebLogic ServerドメインにOracle HTTP Serverを構成した場合、Oracle Fusion Middleware Controlを使用してOracle HTTP Serverインスタンスを再起動することもできます。詳細は、『Oracle HTTP Server管理者ガイド』のFusion Middleware Controlを使用してOracle HTTP Serverインスタンスを再起動することに関する項を参照してください。

19.6 WebLogic Server認証プロバイダの設定

WebLogic Server認証プロバイダを設定するには、構成ファイルをバックアップし、Oracle Access Manager IDアサーション・プロバイダを設定し、プロバイダの順序を設定します。

次の項では、「新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング」の手順に従って、LDAPオーセンティケータがすでに構成されていると想定します。LDAPオーセンティケータをまだ作成していない場合は、この項の作業を進める前に作成しておいてください。

- 構成ファイルのバックアップ

- Oracle Access Manager IDアサーション・プロバイダの設定

- デフォルト・オーセンティケータの更新およびプロバイダの順序の設定

19.6.1 構成ファイルのバックアップ

まず、次の関連する構成ファイルをバックアップする必要があります。

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

管理サーバーのboot.propertiesファイルもバックアップします。

ASERVER_HOME/servers/AdminServer/security/boot.properties

19.6.2 Oracle Access Manager IDアサーション・プロバイダの設定

Oracle WebLogic Server管理コンソールを使用してOracle Access Manager IDアサーション・プロバイダを設定します。

Oracle Access Manager IDアサーション・プロバイダを設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

4. myrealmというデフォルト・レルム・エントリをクリックします。

5. 「プロバイダ」タブをクリックします。

6. 「新規」をクリックし、ドロップダウン・メニューからアサータ・タイプ「OAMIdentityAsserter」を選択します。

7. アサータに名前(OAM ID Asserterなど)を付け、「OK」をクリックします。

8. 新しく追加したアサータをクリックし、Oracle Access Manager IDアサーション・プロバイダの構成画面を確認します。

9. 制御フラグを「必須」に設定します。

10. 選択タイプで、デフォルトで選択されていない場合は「ObSSOCookie」および「OAM_REMOTE_USER」オプションを選択します。

11. 「保存」をクリックして設定を保存します。

12. 「変更のアクティブ化」をクリックして変更を伝播します。

19.6.3 デフォルト・オーセンティケータの更新およびプロバイダ順序の設定

WebLogic Server管理コンソールを使用してIDアサーション・プロバイダと認証プロバイダを設定します。

デフォルト・オーセンティケータを更新し、プロバイダの順序の設定するには、次のようにします。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 左側のナビゲーションから、「セキュリティ・レルム」を選択します。

4. myrealmというデフォルト・レルム・エントリをクリックします。

5. 「プロバイダ」タブをクリックします。

6. プロバイダの表で、DefaultAuthenticatorをクリックします。

7. 「制御フラグ」をSUFFICIENTに設定します。

8. 「保存」をクリックして設定を保存します。

9. ナビゲーション・ブレッドクラムから、「プロバイダ」をクリックして、プロバイダのリストに戻ります。

10. 「並替え」をクリックします。

11. プロバイダをソートして、OAMアイデンティティ・アサーション・プロバイダが最初で、DefaultAuthenticatorプロバイダが最後になるようにします。

表19-1 ソート順序

ソート順序

プロバイダ

制御フラグ

1

OAMIdentityAsserter

REQUIRED

2

LDAP認証プロバイダ

SUFFICIENT

3

DefaultAuthenticator

SUFFICIENT

4

信頼サービスIDアサータ

N/A

5

DefaultIdentityAsserter

N/A

12. 「OK」をクリックします。

13. 「変更のアクティブ化」をクリックして変更を伝播します。

14. 必要に応じて、管理サーバー、管理対象サーバーおよびシステム・コンポーネントを再起動します。

19.7 Oracle Access Managerを使用したOracle ADFおよびOPSSセキュリティの構成

一部のOracle Fusion Middleware管理コンソールでは、Oracle Access Managerシングル・サインオン(SSO)と統合可能なOracle Application Development Framework (Oracle ADF)セキュリティが使用されます。これらのアプリケーションでは、ユーザー認証にOracle Platform Security Services (OPSS) SSOを利用できますが、最初にドメインレベルのjps-config.xmlファイルを構成して、これらの機能を有効化する必要があります。

ドメインレベルのjps-config.xmlファイルは、Oracle Fusion Middlewareドメインの作成後に次の場所に配置されます。

DOMAIN_HOME/config/fmwconfig/jps-config.xml

注意:

ドメインレベルのjps-config.xmlを、カスタム・アプリケーションとともにデプロイされるjps-config.xmlと混同しないでください。

OPSS構成を更新してOracle Access ManagerにSSOアクションを委任する手順は次のとおりです。

1. 次のディレクトリに変更します。

cd ORACLE_COMMON_HOME/common/bin

2. WebLogic Server Scripting Tool (WLST)を起動します。

./wlst.sh

3. 次のWLSTコマンドを使用して管理サーバーに接続します。

connect(‘admin_user’,’admin_password’,’admin_url’)

次に例を示します。

connect(‘weblogic_soa’,’mypassword’,’t3://ADMINVHN:7001’)

4. 次のように、addOAMSSOProviderコマンドを実行します。

addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", logouturi="/oamsso/logout.html")

次の表は、addOAMSSOProviderコマンドにおける各引数の予想される値を定義しています。

引数

定義

loginuri

ログイン・ページのURIを指定します

注意:
ADFセキュリティが有効なアプリケーションの場合、"/context-root/adfAuthentication"を'loginuri'パラメータに指定する必要があります。

例:

/${app.context}/adfAuthentication

注意:
${app.context}は、表示されているとおりに入力する必要があります。実行時に、アプリケーションによって変数が適切に置き換えられます。

手順を示します。

a. たとえば、ユーザーがOPSSの認証ポリシーで保護されているリソースにアクセスします。

b. ユーザーがまだ認証されていない場合、ADFはユーザーを'loginuri'で設定したURIにリダイレクトします。

c. Access Managerには'loginuri'の値を保護するポリシー(たとえば、"/context-root/adfAuthentication")が存在する必要があります。

d. ADFがこのURIにリダイレクトすると、Access Managerにより「ログイン」ページが表示されます(このURI用のAccess Managerで構成された認証スキームにより異なる)。

logouturi

ログアウト・ページのURIを指定します

注意:

- ADFセキュリティが有効なアプリケーションの場合、Oracle Access Management管理者ガイドの11g WebGateが関連するセッションの集中ログアウトの構成に関する項にあるログアウト・ガイドラインに基づいて、logouturiを構成する必要があります。

- WebGate 11gを使用している場合、logouturiの値は11g WebGateの管理者から検索される必要があります。

- WebGate 10gを使用している場合、logouturiの値は/oamsso/logout.htmlにする必要があります。

autologinuri

自動ログイン・ページのURIを指定します。これはオプションのパラメータです。

5. 管理サーバーから切断します。

disconnect()

6. 管理サーバーとすべての管理対象サーバーを再起動します。

19.8 追加のシングル・サインオン構成

次の項で説明する構成は、サイトのセキュリティを強化するために必要であるか、または役に立ちます。

- SSO用のWebCenter Portalの構成

- SSO用のディスカッション・サーバーの構成

- WebCenter Portal RESTインタフェース用のOAMポリシーの構成
WebCenter Portal REST APIは、Oracle Access ManagerのステートレスなBasic認証スキーム用に構成する必要があります。

- 外部リーダーを使用したRSSフィード用のOAMの構成

- OAM 11g用のWebLogic Server管理コンソールとEnterprise Managerの構成

- SSO用のSecure Enterprise Searchの構成

- SSO用のContent Serverの構成

- 接続フィルタを使用したアクセスの制限

- ポートレット・プロデューサと追加コンポーネントの構成

19.8.1 SSO用のWebCenter Portalの構成

WebCenter PortalアプリケーションをSSO用に構成するには、EXTRA_JAVA_PROPERTIESに設定を追加します。

アプリケーションがSSOモードに構成されており、特別な処理が必要であることをWebCenter PortalとADFに伝えるシステム・プロパティがあります。このモードでは、次のシステム・プロパティが必要とされます。

フィールド

値

説明

oracle.webcenter.spaces.osso

true

このフラグはSSOが使用されていることをWebCenter Portalに告げるため、デフォルトのランディング・ページにログイン・フォームは表示されなくなります。そのかわりにログイン・リンクが表示され、ユーザーはこれをクリックしてSSO認証を呼び出すことができます。

このプロパティを設定するには、次のようにします。

1. WCPHOST1のASERVER_HOME/binフォルダにあるsetUserOverrides.shスクリプトを編集します。-Doracle.webcenter.spaces.osso=true Javaプロパティ名/値ペアをEXTRA_JAVA_PROPERTIES変数値の最後に、次の例のようなエントリを使用して追加します。

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Doracle.webcenter.spaces.osso=true"
export EXTRA_JAVA_PROPERTIES

2. このファイルをWCPHOST1、WCPHOST2、WCCHOST1およびWCCHOST2のMSERVER_HOME/binにコピーします。

3. WebLogic ServerコンソールまたはWLSTから、Portal_Clusterの管理対象サーバーを再起動します。

19.8.2 SSO用のディスカッション・サーバーの構成

この項では、シングル・サインオン用のディスカッション・サーバーを構成する方法を説明します。

注意:

SSOの構成後は、ディスカッション・サーバーへの直接のログインはサポートされません。ログインはOracle HTTP Server URLを通して行う必要があります。

SSO用のディスカッション・サーバーを設定する手順は次のとおりです。

1. ディスカッション・サーバー管理コンソールにログインします。

http://host:port/owc_discussions/admin

hostおよびportは、WC_Collaboration管理対象サーバーのホストIDとポート番号です。

2. 「システム・プロパティ」ページを開き、owc_discussions.sso.modeプロパティを編集(存在している場合)または追加します(値をtrueに設定します)。

3. URLのプロトコル部分を含めずにフロントエンド・ロード・バランサのパブリックURLを値に設定して、jiveURLプロパティを編集または追加します。次に例を示します。

jiveURL = wcp.example.com/owc_discussions

jiveURLプロパティは、電子メールのフォーラムへのリンクを構築する際に使用されます。

注意:

WebCenter Portalでディスカッションおよびフォーラム用に登録したWebCenter接続は、このフロントエンド・ロード・バランサのパブリックURLを指している必要があります。

4. WebLogic ServerコンソールまたはWLSTから、Collab_Clusterの管理対象サーバーを再起動します。

19.8.3 WebCenter Portal RESTインタフェース用のOAMポリシーの構成

WebCenter Portal REST APIは、Oracle Access ManagerのステートレスなBasic認証スキーム用に構成する必要があります。

新しい認証スキームを設定するには、次の手順を実行します。

1. OAM管理コンソールを開きます。

2. アプリケーション・ドメインの「認証ポリシー」ビューに移動します。

たとえば、「起動パッド」→「Access Manager」の「アプリケーション・ドメイン」リンク→検索→自分のアプリケーション・ドメイン→「認証ポリシー」タブの順に移動します。

3. 「保護されたリソース・ポリシー」認証ポリシー(認可ではなく)を選択します。

4. リソースURLでリソース・リストをソートし、/restリソースURLの行を探します。

5. 個別に、保護されたリソース・ポリシーから/rest/...関連の各リソースの対応付けを削除します。

6. 「適用」をクリックして、保護されたリソース・ポリシーのビュー・タブを閉じます。

7. 「パブリック・リソース・ポリシー」認証ポリシー(認可ではなく)を選択します。

8. リソースURLでリソース・リストをソートし、/restリソースURLの行を探します。

9. 個別に、パブリック・リソース・ポリシーから/rest/...関連の各リソースの対応付けを削除します。

10. 「適用」をクリックして、パブリック・リソース・ポリシーのビュー・タブを閉じます。

11. 「認証ポリシー」ビューで、「作成」をクリックします。

12. 次の属性値を入力します。

表19-2 属性値

属性

値

名前

WebCenter RESTポリシー

説明

一部のURIへのアクセスを保護する保護されたセッションレスのBasic認証スキーム。

認証スキーム

BasicSessionlessScheme

成功URL

<空>

失敗URL

<空>

13. 「リソース」タブで、「追加」をクリックします。

14. 「リソースの追加」ダイアログ・ボックスで、/restリソースURLを検索します。

15. 戻された/restで始まる行をすべて(ただし/rest/api/cmisリスースURLを除く)選択し、「選択済の追加」をクリックします。

注意:

- /rest/api/cmisリソースは、保護レベル「除外」で構成する必要があります。

- [Shift]キーを使用して行の範囲を選択し、必要に応じてスクロールして完全なリストを選択する必要があります。

16. 戻された/restで始まる行をすべて選択し、「選択済の追加」をクリックします。

注意:
[Shift]キーを使用して行の範囲を選択し、必要に応じてスクロールして完全なリストを選択する必要があります。

17. 前の手順で選択したリソースが新しいWebCenter RESTポリシーのリソース表に表示されていることを確認します。

18. 「適用」をクリックします。レスポンスまたは拡張ルールを構成しないでください。

19.8.4 外部リーダーを使用したRSSフィード用のOAMの構成

デフォルトでは、WebCenter Portal RSSフィードはSSOによって保護されています。ただし、保護されたままの状態では、それらは外部リーダーでうまく機能しません。外部リーダーを使用したアクセスが重要な場合は、その外部リーダーが処理できるWebLogic ServerのBASIC認証によってRSSサーブレットの認証が処理されるように、WebCenter Portal RSSリソースをOAMポリシーから除外することをお薦めします。

OAM 11gのRSSフィードを非保護にする手順は次のとおりです。

1. OAM管理コンソールを開きます。

2. アプリケーション・ドメインの「リソース」ビューに移動します。

たとえば、次のようにします。

「起動パッド」→「Access Manager」の「アプリケーション・ドメイン」リンク→検索→自分のアプリケーション・ドメイン→「リソース」タブ

3. 「リソース」ビューで、リソース・タイプのHTTPとリソースURLのrssでフィルタ処理して検索フォームを使用します。

次のリソースURLとともに結果が表示されます。

/rss/**
/rss*
/rss/.../*
/rss/rssservlet/**
/rss/rssservlet*
/rsscrawl/**
/rsscrawl*
/rsscrawl/.../*

注意:
使用中のOracle Access Managerのリリースによって、これらのリソースURLの構文は若干異なることがあります。

4. 各リソースについて、リソース行を選択して「編集」をクリックします。

5. この6つのリソースそれぞれに割り当てられた保護レベルを確認して更新します。現在「保護」になっているリソースは、「除外」に変更する必要があります。

パブリック・リソース(/rss*など)は、必要に応じて「除外」に変更することも、「パブリック」のままにすることもできます。

保護レベルが「除外」に設定されると、リソースの認証ポリシーと認可ポリシーが削除されることに注意してください。

注意:
パブリック保護レベルは、認証されていないか、ユーザーに表示されるSSO以外の認証モデルを必要とする、ユーザーに表示されるパブリック・サーバー・エンドポイントに対するリクエストのOracle Access Manager監査ロギングを提供します。パブリック・リソースの監査専用トランザクションには、Oracle Access Managerによって認証または認可されていないリクエストについてシステムに課せられる追加のワークロードが含まれます。パブリック・リソース・リクエストの監査に関する追加のワークロードは、リクエスト率およびインフラストラクチャの容量に左右されます。「除外」保護レベルを使用すると、除外されたリソースに対するリクエストはOracle Access Managerによってログに記録されたりレポートされないため、このオーバーヘッドは回避されます。

19.8.5 OAM 11g用のWebLogic Server管理コンソールとEnterprise Managerの構成

この項では、WebLogic Server管理コンソールとEnterprise ManagerのためにオプションでOAM 11gシングル・サインオンをセットアップする方法を説明します。

注意:

- Enterprise ManagerとWebLogic Server管理コンソールに対してOAM SSOをセットアップすると、OAM SSOアクセスが構成されている同じユーザー・セットでシングル・サインオン・アクセスが可能になります。Web層を外部ユーザーがOAMを通じてアクセスできるようにする一方、管理者にEnterprise ManagerとWebLogic Server管理コンソールに直接ログインさせるときは、この追加の構成手順を実行する必要がない場合もあります。

- OAMポリシー・リソース保護は、この章の「エンタープライズ・デプロイメント用の保護されたリソース、パブリック・リソースおよび除外されたリソースの更新」で完了している場合があります。それでも、管理SSOログアウトのリライト・ルールを完了する必要があることに注意してください。その構成を戻す場合は、この項の手順に従って保護レベルを「保護」から「パブリック」に変更します。

WebLogic Server管理コンソールとEnterprise Managerに対してOAM 11g SSOをセットアップする手順は次のとおりです。

1. ブラウザを使用して、OAMコンソールにログインします。

http://host:port/oamconsole

2. 「起動パッド」で、「Access Manager」ブロックにある「アプリケーション・ドメイン」リンクを選択します。
「ポリシー・マネージャ」ペインが表示されます。

3. WebGateエージェントの登録時の名前を使用して、作成したアプリケーション・ドメインを見つけます。

4. 「リソース」ノードを展開して、「作成」をクリックします。
リソース・ページが表示されます。

5. セキュリティ保護が必要なリソースを追加します。各リソースについて、次のようにします。

a. 「リソース・タイプ」としてhttpを選択します。

b. WebGateエージェントの登録時に作成したホスト識別子を選択します。

c. 「リソースURL」に、WebLogic Server管理コンソールのリソースURL(/console)またはEnterprise ManagerのリソースURL(/em)を入力します。

d. リソースの「説明」を入力し、「適用」をクリックします。

e. 「保護レベル」をProtectedに設定します。

6. 「認証ポリシー」→「保護されたリソース・ポリシー」に移動して、新しく作成されたリソースを追加します。

7. 「認可ポリシー」→「保護されたリソース・ポリシー」についても同じことを行います。

8. WEBHOST1およびWEBHOST2で、admin_vh.confファイルを更新し、RewriteRuleを追加してWLSコンソールに対してSSOログアウトを有効にします。

<VirtualHost WEBHOST1:7777>
ServerName admin.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# SSO logout redirection for WLS Console
RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end_url=/console" [R]

</VirtualHost>

9. 変更を有効にするために、Oracle HTTP Serverを再起動します。
これで、次のリンクでWebLogic Server管理コンソールとEnterprise Managerにアクセスできるようになります。

http://admin.example.com/console
http://admin.example.com/em

OAMのSSOログイン・フォームのプロンプトが表示されます。

19.8.6 SSO用のSecure Enterprise Searchの構成

WebCenter PortalとSESに定義された対応する認証エンド・ポイントが使用するWebCenter Portalデータとリポジトリをクロールするために定義されるクロール・ソースは、適切に認証されるようにWeb層のOracle HTTP Serverポートを通してルーティングする必要があります(認証方式は引き続きBASICおよびレルムjazn.comになります)。

SES接続の構成の詳細は、『Oracle WebCenter Portalの管理』のOracle SES接続の設定に関する項を参照してください。

19.8.7 SSO用のContent Serverの構成

SSOが機能したら、Content Serverへのポータル接続を更新してWebコンテキスト・ルート・パスを設定する必要があります。このパラメータを設定することで、SSOが構成されていることをドキュメント・ライブラリに伝達します。SSOが設定され機能するまで、webContextRoot値は設定しないでください。

1. ディレクトリを次のディレクトリに変更します。

cd ORACLE_COMMON_HOME/common/bin

2. WebLogic Server Scripting Tool (WLST)を起動します。

./wlst.sh

3. 次のWLSTコマンドを使用して管理サーバーに接続します。

connect(‘admin_user’,’admin_password’,’admin_url’)

次に例を示します。

connect(‘weblogic_wcp’,’mypassword’,’t3://ADMINVHN:7001’)

4. 使用可能なコンテンツ・サーバー接続をリストし、次のコマンドで使用する正しい接続名を特定します。

listContentServerConnections(appName='webcenter', server='WC_Portal1')

5. nameパラメータに正しい値を代入して、次のようにPortalのコンテンツ・サーバー接続にwebContextRoot値を設定します。

setContentServerConnection(appName='webcenter', server='WC_Portal1', name='nameFromStep4', webContextRoot='/cs')

6. WLSTセッションからPortalクラスタ管理対象サーバーを再起動します。

shutdown('Portal_Cluster', 'Cluster', block='true', force='true')
start('Portal_Cluster', 'Cluster')

7. WLSTを終了します。

exit()

19.8.8 接続フィルタを使用したアクセスの制限

ユーザーが適切に認証されるように、Web層OHSポートを通してのみWebCenter Portalおよび関連するコンポーネントへのアクセスを許可するには、次の手順に従います。

1. WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ペインで、構成するドメインを選択します(例: webcenter)。

3. 「セキュリティ」タブを開き、「フィルタ」サブタブを開きます。

セキュリティ・フィルタの設定ペインが表示されます。

4. 「接続ロガーの有効化」を選択して、受け入れられたメッセージのログを有効にします。

接続ロガーは、成功した接続と接続データをサーバーにログします。この情報を使用して、サーバー接続に関する問題をデバッグできます。

5. 「接続フィルタ」フィールドに、ドメインで使用する接続フィルタ・クラスを指定します。

- デフォルトの接続フィルタを構成するには、weblogic.security.net.ConnectionFilterImplと指定します。

- カスタム接続フィルタを構成するには、ネットワーク接続フィルタを実装するクラスを指定します。このクラスはWebLogic ServerのCLASSPATHにも指定されていることが必要です。

6. 「接続フィルタ・ルール」フィールドに、接続フィルタ・ルールの構文を入力します。

注意:
Web層、ロード・バランサ、エンド・ユーザー・アクセス・ポイントおよび残りのドメイン管理対象サーバーが含まれるホストのIP/サブネットを必ず追加します。そうしないと、管理サーバーにアクセスしようとしたときに403エラーが発生します。

次に例を示します。

<webtier IP>/0 * * allow
0.0.0.0/0  *  *  deny

これは、ローカル・ホストからの全トラフィックを許可し、他のIPアドレスからの全トラフィックを拒否するように指定しています。もちろん、環境に適切なネットワーク・フィルタを作成する必要があります。接続フィルタの作成の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のカスタム接続フィルタの開発に関する項を参照してください。

7. 「保存」をクリックして、変更をアクティブ化します。

8. すべての管理対象サーバーと管理サーバーを再起動します。

9. WebLogic Serverへのすべての直接トラフィックが、次へのナビゲートを試行することでブロックされることを検証します。

http://wcp.example.com/webcenter

これによって次のエラーが生成されます。

「サーバーがこのリクエストを処理できません:[ソケット:000445]接続が拒否され、フィルタがソケットをブロックしました、weblogic.security.net.FilterException: [セキュリティ:090220]rule 3」

ただし、OHSポートを通してWebCenter Portalにアクセスすることは今でも可能です。

http://wcp.example.com/webcenter

19.8.9 ポートレット・プロデューサと追加コンポーネントの構成

OHSを通してルーティングされるようにポートレット・プロデューサ・アプリケーションをセットアップした場合は、登録用のプロデューサURLを指定する際に必ずOHSホストおよびポートを使用してください。これは、wsrp-toolsのようなデフォルトのプロデューサ、サービス・プロデューサ、ページレット・プロデューサおよび明示的に構成した他のプロデューサに適用されます。

登録用のプロデューサURLを指定する際に、必ず内部ロード・バランサURL (http://wcp-internal.example.com/...など)を使用てください。これは、wsrp-toolsのようなデフォルトのプロデューサ、サービス・プロデューサ、ページレット・プロデューサおよび明示的に構成した他のプロデューサに適用されます。

A Oracle RACでのマルチ・データ・ソースの使用

新しいOracle RACアプリケーションを構築する際には、GridLinkデータ・ソースを使用することをお薦めします。ただし、GridLinkデータ・ソースをサポートしないレガシー・アプリケーションとデータベースを使用している場合、この付録の次の情報を参照します。

この付録では、マルチ・データ・ソースとOracle RACについて説明し、エンタープライズ・デプロイメント用にマルチ・データ・ソースを構成する手順について説明します。

- マルチ・データ・ソースとOracle RACについて
マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。

- エンタープライズ・デプロイメントでマルチ・データ・ソースを構成するための標準的な手順
ドメインの構成時にデータ・ソースを構成する必要があります。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLink用の説明を、この項で説明されている指示に置き換えてください。

A.1 マルチ・データ・ソースとOracle RACについて

マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。

通常、このようなマルチ・データ・ソースへの接続リクエストはすべて、リストの先頭のデータ・ソースによって処理されます。データベース接続テストが失敗して接続を置き換えられなかった場合、またはデータ・ソースが中断された場合は、リストの次のデータ・ソースから順番に接続が検索されます。

Oracle RACを使用したマルチ・データ・ソースの構成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

A.2 エンタープライズ・デプロイメントでマルチ・データ・ソースを構成するための標準的な手順

ドメインの構成時にデータ・ソースを構成する必要があります。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLink用の説明を、この項で説明されている指示に置き換えてください。

たとえば、エンタープライズ・デプロイメント参照トポロジに最初の管理ドメインを構成する場合、構成ウィザードを使用してドメインの特性およびデータ・ソースを定義します。

このエンタープライズ・デプロイメント・ガイド内のトポロジの構成手順には、Oracle RACでGridLinkデータ・ソースを定義するための具体的な手順が含まれています。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLink用の説明を次のように置き換えてください。

1. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

a. 適切なスキーマを選択します。

b. コンポーネント・スキーマのRAC構成については、「RACマルチ・データ・ソースへ変換」を選択します。

c. リポジトリ作成ユーティリティを実行した際、次のデータ・ソースがスキーマの接頭辞とともに表示されることを確認してください。

d. 「次」をクリックします。

2. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面が表示されます(図A-1)。

図A-1 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

この画面で、次の手順を実行します。

a. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。

- サービス名: データベースのサービス名を入力します。

- ユーザー名: スキーマの完全なユーザー名(接頭辞を含む)を入力します。

- パスワード: スキーマへのアクセスに使用するパスワードを入力します。

b. ホスト名、インスタンス名およびポートを入力します。

c. 「追加」をクリックします。

d. この手順をOracle RACインスタンスごとに実行します。

e. 「次」をクリックします。

3. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

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 Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、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)を参照してください。