Oracle® Fusion Middleware

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

リリース12.2.1

E70049-02(原本部品番号:E52296-04)

2016年2月

エンタープライズ・デプロイメントで、Oracle Fusion Middlewareコンポーネントをインストールおよび構成する方法について説明します。

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

E70049-02

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

原本著者: Lingaraj Nayak (MAAエンジニア)、Chakravarthy Tenneti (ライター)、Vrushali Sawant (品質管理)

協力著者: Mohan Kumar Doddaramaiah (QA)、Ashwani Raj (QA)、Peter LaQuerre (ライター)

協力者: Robert Abbe、Mei Hong、Muthukumar Subramaniam、Brian Bergstrom、Bonnie Vaughan、Yiqun Gao

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

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

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

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 Mod_WL_OHSについて

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

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

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

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

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

- 2.2.6 データ層について

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

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

- 3.2 WebCenter Contentエンタープライズ・トポロジのダイアグラムの理解

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

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

- 3.3 WebCenter Contentエンタープライズ・トポロジの実装のフロー・チャートとロードマップ

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

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

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

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

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

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

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

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

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

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

- 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 wcc.example.comに関する追加手順

- 6.1.6 wccinternal.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 エンタープライズ・デプロイメントの準備における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 インフラストラクチャ・インストール画面のナビゲート

- 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 管理サーバー・ドメインの構成

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

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

- 10.6 管理サーバーの起動

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

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

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

- 10.6.4 管理サーバーの検証

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Web層ドメインの構成ウィザード画面のナビゲート

- 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 Oracle HTTP Server構成ファイルの推奨構造

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

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

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

- 11.7.5 管理サーバーへのルーティングの構成

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

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

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

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

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

- 12.1.1 インストール・プログラムの起動

- 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.4 WebCenter Content用の構成後タスクおよび検証タスクの実行

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

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

- 12.4.1.2 WCCHOST1での拡張済ドメインの圧縮

- 12.4.1.3 WCCHOST1上の管理対象サーバー・ドメイン・ホームでのドメインの解凍

- 12.4.1.4 WCCHOST2でのドメインの解凍

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

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

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

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

- 12.4.6 WCCHOST2でのノード・マネージャの起動

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

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

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

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

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

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

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

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

- 12.5 WebCenter Contentユーザー・インタフェース用のコンテンツ・サーバーの構成

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

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

- 12.6.2 コンテンツ・サーバーの管理アプレットのアクセスの有効化

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

- 12.6.3.1 URLの検証

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

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

- 13.1 Oracle SOA Suiteを含めるドメインの拡張時に使用される変数

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

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

- 13.3.1 WCCHOST1でのインストーラの起動

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

- 13.3.3 インストールの検証

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

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

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

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

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

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

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

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

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

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

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

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

- 13.7.1 WCCHOST1での拡張済ドメインの圧縮

- 13.7.2 WCCHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

- 13.7.3 WCCHOST2でのドメインの解凍

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

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

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

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

- 13.9 SOAクラスタのフロントエンド・ホストおよびポートの設定

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

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

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

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

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

- 13.12.3 ロード・バランサを介したOracle WebCenter Content URLの検証

- 13.13 Oracle SOA Suiteの構成後手順

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

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

- 13.14 Oracle SOA Suiteでの自動サービス移行とJDBC永続ストアの有効化

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

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

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

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

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

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

- 14.3.1 WLS_IBR1およびWLS_IBR2へのドメイン構成の伝播

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

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

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

- 14.4.1 Inbound Refineryの設定の構成

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

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

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

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

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

15 Captureを追加するためのドメインの拡張

- 15.1 Captureを追加するためのドメインの拡張の概要

- 15.2 Captureを使用するためのドメインの拡張

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

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

- 15.3 WLS_CPT1およびWLS_CPT2へのドメイン構成の伝播

- 15.4 Captureクラスタ用のOracle HTTP Serverの構成

- 15.4.1 WLS_CPT管理対象サーバー用のOracle HTTP Serverの構成

- 15.4.2 CaptureクラスタでのフロントエンドHTTPホストおよびポートの設定

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

16 WebCenter Contentユーザー・インタフェースを追加するためのドメインの拡張

- 16.1 WebCenter Contentユーザー・インタフェースのためのドメインの拡張

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

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

- 16.2 WLS_WCCUI1およびWLS_WCCUI2へのドメイン構成の伝播

- 16.3 MBeanを使用したシステム・レベルの設定の変更

- 16.4 WebCenter Contentユーザー・インタフェース・クラスタと使用するOracle HTTP Serverの構成

- 16.4.1 WLS_WCCUI管理対象サーバー用のOracle HTTP Serverの構成

- 16.4.2 WebCenter Contentユーザー・インタフェース・クラスタのフロントエンドHTTPホストおよびポートの設定

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

- 16.5 ワークフロー構成の完了

第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 TLOGおよびJMS永続ストアのパフォーマンスへの影響

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

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

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

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

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

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

- 17.4.9 JDBC JMSストアの作成

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

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

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

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

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 Webgateについて

- 19.2 Oracle HTTP Server 12c Webgateを構成するための一般的な前提条件

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

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

- 19.5 Oracle Access ManagerでのOracle HTTP Server 12c WebGateの登録

- 19.5.1 RREGツールの場所と準備

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

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

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

- 19.5.5 RREGツールの実行

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

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

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

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

- 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セキュリティの構成

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 Fusion Middlewareエンタープライズ・デプロイメントの概念を説明します。

- 標準的なエンタープライズ・デプロイメントの理解
この章では、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントの全般的な特徴について説明します。ここで説明する概念は、どの製品固有のエンタープライズ・デプロイメントにも適用できます。

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

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

この章では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 Contentの場合は次を参照してください。

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

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

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

この章では、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントの全般的な特徴について説明します。ここで説明する概念は、どの製品固有のエンタープライズ・デプロイメントにも適用できます。

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

- 標準的なエンタープライズ・デプロイメントのダイアグラム
この項では、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントについて説明します。

- 標準的なエンタープライズ・デプロイメント・トポロジ・ダイアグラムの理解
この項では、標準的なエンタープライズ・トポロジ・ダイアグラムについて詳しく説明します。

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

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

この項では、Web層、アプリケーション層およびデータ層を含む標準的なエンタープライズ・デプロイメントについて説明します。

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

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

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

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

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

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

この項では、標準的なエンタープライズ・トポロジ・ダイアグラムについて詳しく説明します。

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

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

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

- Web層の理解

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

- データ層について

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

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

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

- データ層。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 標準的なロード・バランサの仮想サーバー名のサマリー

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

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

- productinternal.example.com: この仮想サーバー名は、内部通信専用です。
ロード・バランサは、そのネットワーク・アドレス変換(NAT)機能を使用して、アプリケーション層コンポーネントからこのURLへの内部通信をすべてルーティングします。この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サーバーが含まれます。標準的なエンタープライズ・デプロイメントでは、2つ以上の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 Fusion Middleware 12c以降、Oracle HTTP Serverソフトウェアは2つの方法のいずれか(既存の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.3 Mod_WL_OHSについて

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

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

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

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

次の各項で、詳細を説明します。

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

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

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

- 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 Fusion Middleware 12c以降では、ドメインごとのノード・マネージャまたはホストごとのノード・マネージャのいずれかを使用できます。次の項では、典型的なエンタープライズ・デプロイメントでのノード・マネージャ構成の影響について詳しく説明します。

注意:

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

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

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

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

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

もう1つのメリットは、ドメインごとのノード・マネージャでは、各ドメインに作成されるデモ・アイデンティティ・ストアに基づいて、ノード・マネージャとサーバーとの通信にデフォルトでSSL構成が提供されることです。

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

ホストごとのノード・マネージャ構成では、1つのノード・マネージャ・インスタンスを起動し、1つのホスト上の管理サーバーとすべての管理対象サーバーを制御します(これらが異なるドメインに存在していても関係ありません)。これにより、管理サーバー・ホストでのフットプリントとリソース使用率が低下します。これは複数のドメインが同じマシンに同時に存在している場合に顕著です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.5.4 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 Platform Security Servicesによるアプリケーションの保護』の次の項を参照してください。

- 認証の基本に関する項

- OPSSポリシー・モデル

2.2.6 データ層について

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

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

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

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

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

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

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

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

- WebCenter Contentエンタープライズ・トポロジのダイアグラム
この項では、プライマリOracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのダイアグラムを示します。

- WebCenter Contentエンタープライズ・トポロジのダイアグラムの理解
この項では、WebCenter Contentトポロジに固有の要素に関する情報を示します。

- WebCenter Contentエンタープライズ・トポロジの実装のフロー・チャートとロードマップ
次の項は、エンタープライズ・トポロジをインストールおよび構成するために実行する必要がある大まかな手順を要約しています。

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

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

この項では、プライマリOracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのダイアグラムを示します。

3.2 WebCenter Contentエンタープライズ・トポロジのダイアグラムの理解

この項では、WebCenter Contentトポロジに固有の要素に関する情報を示します。

Oracle WebCenter Contentトポロジのほとんどの要素は、オラクル社が推奨するベスト・プラクティスに準拠したエンタープライズ・トポロジの標準機能に相当します。これらの要素については、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

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

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

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

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

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

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

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

- wcc.example.com: この仮想サーバー名はすべての受信トラフィックに使用されます。ランタイムOracle WebCenter ContentコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして動作します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。

wcc.example.com:443

- wccinternal.example.com: この仮想サーバー名は、アプリケーション層のコンポーネント間の内部通信専用であり、インターネットには公開されません。
クライアントからこのURLへのトラフィックは、SSL対応ではありません。クライアントは次のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。

wccinternal.example.com:80

このURLは、コンポジットのモデリングの際、または適切なEnterprise Manager MBeanによる実行時に、内部サービスの起動に使用するURLとしても設定できます。

この仮想サーバー名も、ランタイムOracle WebCenter Contentコンポーネントへのすべての内部Remote Intradoc Client (RIDC) TCPトラフィックのアクセス・ポイントとして動作します。ImagingやCaptureなどのアプリケーションは、RIDC接続用のアドレスucminternal.example.com:6300を使用してこのサービスにアクセスします。またリクエストは、WCCHOST1およびWCCHOST2上のポート4444に転送されます。

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

このガイドの後半では、次の作業の実行方法を示します。

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

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

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

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

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

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

クラスタ

管理対象サーバー

Oracle WebCenter Contentクラスタ

WLS_WCC1、WLS_WCC2

Oracle SOA Suiteクラスタ

WLS_SOA1、WLS_SOA2

Oracle Inbound Refineryクラスタ

WLS_IBR1、WLS_IBR2

Oracle WebCenter Enterprise Captureクラスタ

WLS_CPT1、WLS_CPT2

WebCenter Contentユーザー・インタフェース・クラスタ

WLS_WCCUI1、WLS_WCCUI2

3.3 WebCenter Contentエンタープライズ・トポロジの実装のフロー・チャートとロードマップ

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

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

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

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

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

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

このガイドでは、作動しているWebCenter Contentドメインを拡張して追加機能を含める方法を説明します。

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

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

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

図3-1 エンタープライズ・トポロジ構成手順のフロー・チャート

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

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

フロー・チャート手順

詳細情報

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次の手順はフロー・チャートに示した手順に対応しています。

フロー・チャート手順

詳細情報

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

エンタープライズ・デプロイメントの初期管理サーバー・ドメインの作成

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

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

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

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

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

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

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

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

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

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

WebCenter Contentユーザー・インタフェースを追加するドメインの拡張

WebCenter Contentユーザー・インタフェースを追加するためのドメインの拡張

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

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

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

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

- エンタープライズ・デプロイメント・ワークブックの使用
この章では、エンタープライズ・デプロイメント・ワークブックの概要を示します。ワークブックを使用して組織のエンタープライズ・デプロイメントを計画する方法について説明します。

- エンタープライズ・デプロイメント用のリソースの取得
Oracle WebCenter Content参照用トポロジの構成を開始する前に、次の手順を使用して必要なハードウェア、ソフトウェアおよびネットワーク設定を用意します。

- エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備
この章では、エンタープライズ・デプロイメント用にネットワークを構成する方法について説明します。

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

- エンタープライズ・デプロイメント用のホスト・コンピュータの準備
必要な共有記憶域システムをホストにマウントする方法や、各ホストで必要な仮想IPアドレスを有効化する方法について説明します。

- エンタープライズ・デプロイメント用のデータベースの準備
この章では、Oracle WebCenter Contentエンタープライズ・デプロイメント用のデータベースの準備手順について説明します。

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

この章では、エンタープライズ・デプロイメント・ワークブックの概要を示します。ワークブックを使用して組織のエンタープライズ・デプロイメントを計画する方法について説明します。

この章では、エンタープライズ・デプロイメント・ワークブックの概要を示し、ユースケースやエンタープライズ・デプロイメント・ワークブックを使用する対象者に関する情報を説明します。

- エンタープライズ・デプロイメント・ワークブックの概要
この項では、エンタープライズ・デプロイメント・ワークブックについて簡単に紹介します。

- ワークブックの標準的なユース・ケース
この項では、エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースに関連するロールとタスクを示します。

- Oracle WebCenter Contentエンタープライズ・デプロイメント・ワークブックの使用
この項では、エンタープライズ・デプロイメント・ワークブックの使用について詳しく説明します。

- エンタープライズ・デプロイメント・ワークブックの使用対象者
エンタープライズ・デプロイメント・ワークブックの情報はカテゴリごとに分かれています。組織構成およびチームで規定されているロールに応じて、ワークブックの詳細を記入する組織内の特定の個人を割り当てることができます。同様に、カテゴリごとの情報を、各カテゴリのリソースの計画、取得または設定を担当する個人またはチームに割り当てることができます。

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

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

この項では、エンタープライズ・デプロイメント・ワークブックについて簡単に紹介します。

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

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

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

- 実装前の包括的な計画

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

- 実装時の一貫性

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

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

この項では、エンタープライズ・デプロイメント・ワークブックの標準的なユース・ケースに関連するロールとタスクを示します。

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

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

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

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

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

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

この項では、エンタープライズ・デプロイメント・ワークブックの使用について詳しく説明します。

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

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

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

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

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

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

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

- スタート・タブの使用

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

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

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

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

4.3.2.1 スタート・タブの使用

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

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

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

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

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

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

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

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

簡単に参照できるように、各ホストの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 Content参照用トポロジの構成を開始する前に、次の手順を使用して必要なハードウェア、ソフトウェアおよびネットワーク設定を用意します。

この賞では、必須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リクエストをルーティングする機能。これは、Minimum Lower Layer Protocol (MLLP) over TCPを使用するOracle SOA Suite for healthcare integrationの要件です。

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

この項では、エンタープライズ・デプロイメント・トポロジをサポートするように構成されるホスト・コンピュータの取得に役立つ情報を提供します。

内容は次のとおりです。

- エンタープライズ・デプロイメントのホスト・コンピュータに関する一般的な考慮事項
この項では、エンタープライズ・デプロイメント・ホスト・コンピュータで必要な一般的考慮事項について説明します。

- Oracle Fusion Middlewareのシステム要件の確認
この項では、環境が必要最小要件に適合していることの確認を助けるシステム要件情報への参照を提供します。

- エンタープライズ・デプロイメントに必要な、一般的なメモリー、ファイル・ディスクリプタおよびプロセス
この項では、エンタープライズ・デプロイメントに必要な、一般的なメモリー、ファイル・ディスクリプタの数およびオペレーティング・システムのプロセスとタスク詳細について説明します。

- エンタープライズ・デプロイメントの標準的なディスク領域要件
この項では、このエンタープライズ・デプロイメントに通常必要なディスク容量について説明します。

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

この項では、エンタープライズ・デプロイメント・ホスト・コンピュータで必要な一般的考慮事項について説明します。

Oracle Fusion Middlewareエンタープライズ・デプロイメントを構成するプロセスを開始する前に、適切なキャパシティ・プランニングを実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。これらの要件は、アプリケーションごと、あるいは使用しているカスタムOracle WebCenter Contentシステムごとに異なります。

この章で提供する情報は、ホスト・コンピュータ要件を判断するために役立つ一般的なガイドラインおよび情報です。これにより、個別の本番環境に対するキャパシティ・プランニングを実行する必要がなくなるわけではありません。

注意:

この項でホスト・コンピュータを取得し確保したら、ホスト名とシステム特性をエンタープライズ・デプロイメント・ワークブックに記録してください。これらのアドレスは、後で各ホスト・コンピュータでIPアドレスを有効化するときに使用します。

詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください

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

この項では、環境が必要最小要件に適合していることの確認を助けるシステム要件情報への参照を提供します。

Oracle Fusion Middlewareのシステム要件および仕様を参照し、環境がインストールする製品の最小インストール要件を満たしていることを確認します。

要件および仕様のドキュメントには、Oracle Fusion Middlewareの一般的なハードウェアとソフトウェアの要件、ディスク領域とメモリーの最小要件、データベース・スキーマの要件、および必要なシステム・ライブラリおよびパッケージに関する情報が記載されています。

また、Oracle Fusion Middlewareデプロイメントのメモリー要件を見積るための一般的なガイドラインも記載されています。

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

この項では、エンタープライズ・デプロイメントに必要な、一般的なメモリー、ファイル・ディスクリプタの数およびオペレーティング・システムのプロセスとタスク詳細について説明します。

次の表は、標準的なOracle WebCenter Contentエンタープライズ・デプロイメントにおける管理サーバーおよび各管理対象サーバー・コンピュータに必要なメモリー、ファイル・ディスクリプタおよびプロセス数をまとめたものです。これらの値はあくまで例にすぎませんが、初期エンタープライズ・デプロイメントに最小限必要なメモリー量の見積りに使用できます。

この項の例は、参照用トポロジに示されている、WCCHOST1で必要な管理対象サーバーおよび他のサービスを構成するための最小限の要件を反映しています。

マシンの調達時には、各ホスト・コンピュータに搭載する必要がある物理メモリー量を判断するときの目安として、「概算最大メモリー」列の情報を使用してください。

ホスト・コンピュータ・ハードウェアを調達し、オペレーティング・システム要件を確認したら、ソフトウェア構成を調査して、オペレーティング・システムの設定が「ファイル・ディスクリプタ」列に記載されているオープン・ファイル数と「オペレーティング・システムのプロセスおよびタスク数」列に記載されているプロセス数に対応できるように構成されていることを確認します。

詳細は、「UNIXシステムでのオープン・ファイル制限とプロセス数の設定」を参照してください。

管理対象サーバー、ユーティリティまたはサービス

概算最大メモリー

ファイル・ディスクリプタ数

オペレーティング・システムのプロセスおよびタスク数

管理サーバー

3.5GB

3500

165

WLS_WCC

4.0GB

3100

240

WLS_WCCUI

4.0GB

3100

100

WLS_CPT

3.0GB

1300

100

WLS_IBR

3.0GB

1300

100

WLS_SOA

4.0GB

3100

240

WLST (ノード・マネージャへの接続)

1.5GB

910

20

構成ウィザード

1.5GB

700

20

ノード・マネージャ

1.0GB

720

15

合計

11.5GB*

未定

未定

* オペレーティング・システムとその他の追加メモリー要件を考慮した概算合計。

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

この項では、このエンタープライズ・デプロイメントに通常必要なディスク容量について説明します。

Oracle WebCenter Content製品を含むOracle Fusion Middleware 12c (12.2.1)製品の最新のディスク領域要件は、「Oracle Fusion Middlewareのシステム要件と仕様」を確認してください。

また、次の表は、Oracle WebCenter Contentエンタープライズ・デプロイメントで必要になる標準的なディスク容量をまとめています。

この情報と「エンタープライズ・デプロイメント用のファイル・システムの準備」の情報に基づいて、デプロイメントに必要なディスク領域を判断してください。

サーバー

ディスク

データベース

nXm

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

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

WEBHOSTn

10GB

WCCHOSTn

20GB*

* 共有記憶域のOracleホーム構成では、2つのインストールは合計20GBになるため十分です。

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

この項では、オペレーティング・システム要件の詳細を説明します。

このガイドで説明するOracle Fusion Middlewareソフトウェア製品およびコンポーネントは、Oracle Fusion Middlewareシステム要件と仕様に記載されている様々なオペレーティング・システムおよびプラットフォームで動作保証されています。

注意:

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

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

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

この項には、インストールおよび構成の前に取得して予約する必要がある一連のIPアドレスをリストしています。

エンタープライズ・トポロジのインストールおよび構成を開始する前に、次の一連のIPアドレスを取得および予約する必要があります。

- トポロジのために取得した各ホスト・コンピュータの物理IP (IP)アドレス

- 管理サーバーの仮想IP (VIP)アドレス

- サーバー全体の移行を行うように構成された各管理対象サーバーの追加VIPアドレス
自動サービス移行をサポートするFusion Middleware 12c製品の場合、管理対象サーバーのVIPは通常は必要ありません。

- 各VIPにマップされる一意の仮想ホスト名。

ネットワーク管理者と協力して、これらの必須VIPが、ご使用のDNSサーバーに定義されていることを確認できます。(非本番環境では、かわりに/etc/hostsファイルを使用してこれらの仮想ホストを定義できます)。

詳細な情報は、次のトピックを参照してください

- 仮想IP (VIP)アドレスとは
この項では仮想IPアドレスを定義し、その目的を説明します。

- 仮想ホスト名と仮想IPアドレスを使用する理由
特にエンタープライズ・デプロイメントの場合、一連のVIPおよびそれらがマップされている仮想ホスト名を、社内ネットワーク上で予約して有効化することが重要です。

- エンタープライズ・トポロジによって必要とされる物理および仮想IPアドレス
この項では、通常のOracle WebCenter Contentエンタープライズ・デプロイメント・トポロジの管理サーバーと各管理対象サーバーに必要な物理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 Contentエンタープライズ・デプロイメント・トポロジの管理サーバーと各管理対象サーバーに必要な物理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.0.0) Infrastructure

このディストリビューションをダウンロードしてOracle Fusion Middleware Infrastructureをインストールします。これには、Oracle WebLogic ServerおよびOracle Fusion Middleware製品に必要なJava Required Filesソフトウェアが含まれています。

このディストリビューションによってリポジトリ作成ユーティリティ(RCU)もインストールされます。これは、以前のOracle Fusion Middlewareリリースでは独自のディストリビューションにパッケージされていました。

Oracle HTTP Server 12c (12.2.1.0.0)

このディストリビューションをダウンロードして、Oracle HTTP ServerソフトウェアをWeb層にインストールします。

Oracle Fusion Middleware 12c (12.2.1.0.0) WebCenter Content

このディストリビューションをダウンロードしてOracle WebCenter Contentをインストールします。

Oracle Fusion Middleware 12c (12.2.1.0.0) SOA Suite

Oracle WebCenter Contentエンタープライズ・トポロジの一部としてOracle SOA Suiteをインストールおよび構成する場合は、このディストリビューションをダウンロードします。

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

この章では、エンタープライズ・デプロイメント用にネットワークを構成する方法について説明します。

- ハードウェア・ロード・バランサでの仮想ホストの構成
この項では、エンタープライズ・デプロイメントのハードウェア・ロード・バランサの構成方法について説明します。

- エンタープライズ・デプロイメントのファイアウォールとポートの構成
この項では、エンタープライズ・デプロイメントでファイアウォール上に開く必要があるポートをリストします。

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

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

この項では、エンタープライズ・デプロイメントのハードウェア・ロード・バランサの構成方法について説明します。

次の項では、ハードウェア・ロード・バランサを構成する方法を説明し、必要な仮想サーバーのサマリーを示し、これらの仮想サーバーに関する追加情報を提供します。

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

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

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

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

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

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

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

トポロジのダイアグラムに示すように、リクエストを認識し、様々な種類のネットワーク・トラフィックや監視に対応する複数の仮想サーバーと関連ポートにリクエストをルーティングできるように、ハードウェア・ロード・バランサを構成する必要があります。

ロード・バランシング・デバイスにおける仮想サーバーとは、ロード・バランシングのために複数の物理サーバーを1つのサーバーのように見せかけることができる構成です。仮想サーバーは通常、IPアドレスとサービスによって表され、受信したクライアント・リクエストをサーバー・プール内の各サーバーに配信するために使用されます。

仮想サーバーは、(エンタープライズ・デプロイメントで使用可能な各種サービス用の)適切なホスト・コンピュータおよびポートにトラフィックをルーティングするように構成しておく必要があります。

さらに、サービスが停止したときに特定のサーバーへのトラフィックをできるだけ早く停止できるように、ホスト・コンピュータとポートの可用性を監視するようにロード・バランサを構成する必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

ロード・バランサを構成した後で、同じ名前を持つ一連の仮想ホストを、ロード・バランサに定義した仮想サーバーとして認識するように、Web層のWebサーバー・インスタンスを構成することも可能です。Webサーバーは、ハードウェア・ロード・バランサから受信した各リクエストを、リクエストのヘッダーに記述されているサーバー名に基づいて適切にルーティングできます。詳細は、「管理およびOracle Web Services Manager用のOracle HTTP Serverの構成」を参照してください。

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

次に、エンタープライズ・デプロイメントのハードウェア・ロード・バランサを構成するための標準的な手順を説明します。

実際に特定のロード・バランサを構成する手順は、ロード・バランサのタイプによって異なることに注意してください。実際の手順は、ベンダーが提供するドキュメントを参照してください。

1. サーバーのプールを作成します。このプールには、ロード・バランシングの定義に含まれているサーバーとポートのリストが格納されます。
たとえば、Webホスト間のロード・バランシングの場合、ポート7777のWEBHOST1およびWEBHOST2の両ホストにリクエストを送信するサーバーのプールを作成します。

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

3. アプリケーションのリクエストを受信するアドレスとポートのために、ロード・バランサ上に必須仮想サーバーを作成します。
エンタープライズ・デプロイメントで必要な仮想サーバーの一覧は、「エンタープライズ・デプロイメントに必要な仮想サーバーのサマリー」を参照してください。

ロード・バランサで各仮想サーバーを定義するときは、次のことを考慮します。

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

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

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

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

この項では、エンタープライズ・デプロイメントに必要な仮想サーバーの詳細を提供します。

次の表は、Oracle WebCenter Contentエンタープライズ・トポロジのハードウェア・ロード・バランサで定義する必要がある仮想サーバーの一覧です。

仮想ホスト

サーバー・プール

プロトコル

SSL終端

外部

admin.example.com:80

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

HTTP

いいえ

いいえ

wcc.example.com:443

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

HTTPS

はい

はい

wccinternal.example.com:80

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

HTTP

いいえ

いいえ

wccinternal.example.com:6300

WCCHOST1.example.com:4444 WCCHOST2.example.com:4444

TCP

いいえ

いいえ

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

この項では、仮想サーバー(admin.example.com)に必要な追加情報を提供します。

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

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

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

アドレスwcc.example.comは、ランタイムOracle WebCenter ContentコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLへのトラフィックが構成されます。クライアントは、HTTP用のアドレスwcc.example.com:443を使用してこのサービスにアクセスします。ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

- ANYをプロトコルとして指定します(B2BではHTTPでないプロトコルが必要)。

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

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

- この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。
これらのコンテキスト文字列は、リクエストをOracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlにルーティングするため、admin.example.comからシステムへのアクセス時にのみ使用する必要があります。

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

アドレスwccinternal.example.comは、WebCenter ContentおよびSOAサービスの内部起動に使用される仮想サーバー名です。このURLはインターネットに公開されずに、イントラネットからのみアクセスできます。クライアントからの入力トラフィックは、SSL対応ではありません。

このアドレスは、次のように異なるポートを使用するHTTPとRemote Intradoc Client (RIDC)両方のトラフィックで使用されます。

- HTTPトラフィックはポート7777と80を介してルーティングされます。

- RIDCトラフィックはTCP上でポート6300と4400を介してルーティングされます。

HTTPトラフィックはWeb層ホスト・プール(WEBHOST1およびWEBHOST2)に送られます。

エンドユーザーRIDCトラフィック(WebCenter Content ADF UIからなど)は、WebCenter Contentホスト・プール(WCCHOST1およびWCCHOST2)に直接送られます。RIDCトラフィックはロード・バランサのポート6300 (6300は主にマスキング用)を使用しますが、トラフィックは最終的にWebCenterホストのRIDCポート(4444)にルーティングされます。

Oracle SOA Suiteシステムでは、内部サービスの起動に使用するURLと同様に、コンポジットのモデリングの際またはFusion Middleware Controlを介した適切なMBeanによる実行時に、ユーザーはこのURLを設定できます。このURLは、Oracle SOA SuiteからWebCenter Contentコンポーネントへの任意のサービス・コールバックに使用できます。クライアントはwccinternal.example.com:80のアドレスを使用してこのサービスにアクセスし、リクエストはWEBHOST1とWEBHOST2のポート7777に転送されます。

ハードウェア・ロード・バランサでこの仮想サーバーを構成する場合:

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

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

- wcc.example.comと同様に、この仮想サーバーの/consoleと/emへのアクセスを除外するルールを作成します。

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

この項では、エンタープライズ・デプロイメントでファイアウォール上に開く必要があるポートをリストします。

管理者として、Oracle Fusion Middlewareの様々な製品とサービスで使用されるポート番号を把握する必要があります。こうして、1つのホストで2つのサービスが同じポート番号を使用しないようにし、エンタープライズ・トポロジのファイアウォールで適切なポートを開くようにします。

次の表は、トポロジのファイアウォールで開く必要があるポートの一覧です。

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

- FW0は、最も外側のファイアウォールを表します。

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

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

すべての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に使用されるプロセス・モデルのタイプとデータベース・コンテンツによって異なります。

デプロイメント用Coherence

該当なし

8088

範囲: 8000 - 8090

該当なし

該当なし

Oracle Unified Directoryへのアクセス

FW2

389

636 (SSL)

LDAPまたはLDAP/ssl

インバウンド

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

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

Gridlinkに必要。ONSサーバーは各データベース・サーバー上で稼働します。

Oracle WebCenter Contentエンタープライズ・デプロイメント固有のファイアウォール・ポート

タイプ

ファイアウォール

ポートとポートの範囲

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

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

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

Oracle SOA SuiteおよびWSMサーバーへのアクセス

FW1

8001

範囲: 8000 - 8080

HTTP/WLS_SOAn

インバウンド

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

Oracle WebCenter Contentへのアクセス

FW1

16200

HTTP/WLS_WCCn

インバウンド

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

RIDC APIリクエスト

FW1

6300

TCP/WLS_WCCn

インバウンド

該当なし

Oracle WebCenter Enterprise Captureへのアクセス

FW1

16400

HTTP/WLS_CPTn

インバウンド

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

SOA_Clusterメンバー間の通信

該当なし

8001

TCP/IPユニキャスト

該当なし

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

WCC_Clusterメンバー間の通信

該当なし

16200

TCP/IPユニキャスト

該当なし

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

CPT_Clusterメンバー間の通信

該当なし

16400

TCP/IPユニキャスト

該当なし

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

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

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

この章では、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

このディレクトリにはOracle実行時アーティファクトが含まれます(JMSログやTLOGなど)。

通常、このディレクトリはドメイン内のすべてのホストからアクセスできる個別の共有ファイル・システムとしてマウントします。

構成ウィザードを実行するか構成後のタスクを実行する際に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

スタンドアロンOracle HTTP Serverドメインのドメイン・ホーム。各Web層ホストのローカル・ディスクに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 エンタープライズ・デプロイメントのディレクトリの作成とマウントについて

この項では、エンタープライズ・デプロイメントに最上位のディレクトリを作成またはマウントする場合に従うべき、ベスト・プラクティスをリストします。

最上位ディレクトリを作成およびマウントするときには、次のベスト・プラクティスに注意してください。

- アプリケーション層については、WCCHOST2にマウントされる別の共有記憶域ボリュームまたは別のパーティションにOracleホーム(ソフトウェア・バイナリの格納先)をインストールします。WCCHOST2上のバイナリへのディレクトリ・パスが、WCCHOST1上のディレクトリ・パスと同一であることを確認してください。
次に例を示します。

/u01/oracle/products/fmw/

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

- このエンタープライズ・デプロイメント・ガイドでは、Oracle Web層ソフトウェアがローカル・ディスクにインストールされると想定しています。
Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用するとき、Oracle Web層バイナリを共有ディスクにインストールできます(Oracle HTTP Serverインスタンスを作成できます)。ただし、その場合、この共有ディスクはアプリケーション層で使用される共有ディスクとは別にする必要があります。また、層をまたがる記憶域デバイスのアクセスについて適切なセキュリティ制限を検討する必要があります。

アプリケーション層サーバー(WCCHOST1およびWCCHOST2)の場合と同様に、両方のコンピュータで同じディレクトリ・パスを使用します。

次に例を示します。

/u02/oracle/products/fmw/

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

この項では、エンタープライズ・デプロイメントに必要な共有記憶域ボリュームの概要を示します。

次の表に、標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントの共有ボリュームとその用途をまとめます。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

共有記憶域のボリューム

マウントされるホスト

マウント・ディレクトリ

説明および用途

NFSボリューム1

WCCHOST1

/u01/oracle/products/

WCCHOST1によって使用される製品バイナリのローカル記憶域。Oracleホーム・ディレクトリおよび製品ディレクトリはここにインストールされます。

NFSボリューム2

WCCHOST2

/u01/oracle/products/

WCCHOST2によって使用される製品バイナリのローカル記憶域。Oracleホーム・ディレクトリおよび製品ディレクトリはここにインストールされます。

NFSボリューム3

WCCHOST1 WCCHOST2

/u01/oracle/config/

すべてのホストにマウントされる管理サーバー・ドメイン構成。最初はWCCHOST1によって使用され、任意のホストにフェイルオーバーできます。

NFSボリューム4

WCCHOST1 WCCHOST2

/u01/oracle/runtime/

すべてのホストにマウントされる実行時アーティファクト・ディレクトリ。実行時アーティファクト(JMSログ、ブログおよび必要なクラスタ依存共有ファイル)が含まれます。

NFSボリューム5

WCCHOST1

/u02/oracle/config/

WCCHOST1によって使用される管理対象サーバー・ドメイン・ディレクトリのローカル記憶域(プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域に配置される場合)。

NFSボリューム6

WCCHOST2

/u02/oracle/config/

WCCHOST2によって使用される管理対象サーバー・ドメイン・ディレクトリのローカル記憶域(プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域に配置される場合)。

NFSボリューム7

WEBHOST1

/u02/oracle/

WEBHOST1によって使用されるOracle HTTP Serverソフトウェア・バイナリ(Oracleホーム)およびドメイン構成ファイルのローカル記憶域(プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域に配置される場合)。

NFSボリューム8

WEBHOST2

/u02/oracle/

WEBHOST2によって使用されるOracle HTTP Serverソフトウェア・バイナリ(Oracleホーム)およびドメイン構成ファイルのローカル記憶域(プライベート管理対象サーバー・ドメイン・ディレクトリが共有記憶域に配置される場合)。

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

必要な共有記憶域システムをホストにマウントする方法や、各ホストで必要な仮想IPアドレスを有効化する方法について説明します。

この章では、エンタープライズ・デプロイメントをホストする各コンピュータまたはサーバーから実行する必要があるタスクについて説明します。

- 各ホストのために最小限のハードウェア要求の検証
この項では、各ホストの最小ハードウェア要件に関する情報を提供します。

- Linuxオペレーティング・システムの要件の検証
エンタープライズ・デプロイメントの標準的なLinuxオペレーティング・システム設定についてはこの項を確認してください。

- オペレーティング・システムのユーザーおよびグループの構成
この項では、エンタープライズ・デプロイメントをホストする各コンピュータで定義するユーザーおよびグループのリストを示します。

- Unicodeサポートの有効化
この項では、Unicodeのサポートの有効化について説明します。

- 各ホストへの必要な共有ファイル・システムのマウント
この項では、各ホストで必要な共有ファイル・システムのマウントについて説明します。

- 各ホストでの必要な仮想IPアドレスの有効化
この項では、必要な仮想IPアドレスを各ホスト上で有効化するための情報を提供します。

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

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

この項では、各ホストの最小ハードウェア要件について説明します。

エンタープライズ・デプロイメントに必要なハードウェアを取得したら、各ホスト・コンピュータにログインし、「エンタープライズ・デプロイメント・トポロジ用のハードウェアおよびソフトウェアの要件」に示すシステム要件を確認します。

Oracle Exalogicなどの仮想サーバー環境にデプロイしている場合、仮想サーバーそれぞれが最小要件を満たしていることを確認します。

十分なローカル・ディスク記憶域と共有記憶域が「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されているように構成されていることを確認します。

具体的には次のように十分なスワップ領域および一時領域を確保します。

- スワップ領域: システムに500MB以上ある必要があります。

- 一時領域: /tmpに500MB以上の空き領域がある必要があります。

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

エンタープライズ・デプロイメントの標準的なLinuxオペレーティング・システム設定についてはこの項を確認してください。

ホスト・コンピュータが最小オペレーティング・システム要件を満たしていることを確認するには、動作保証済のオペレーティング・システムがインストールされていることと、そのオペレーティング・システムに必要なパッチがすべて適用されていることを確認してください。

さらに、エンタープライズ・デプロイメント用の一般的なLinuxオペレーティング・システムの設定について、次の項を確認してください。

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

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

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

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

後で示すkernel-parameterおよびshell-limitの値のみが推奨値です。これらの値をチューニングしてシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。

カーネル・パラメータは、トポロジのすべてのノードで表の最小値以上の値に設定する必要があります。

次の表の値は、現行のLinuxの推奨値です。Linuxおよびその他のオペレーティング・システムの最新の推奨値は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

データベースをホストにデプロイしている場合、追加のカーネル・パラメータを変更する必要がある場合があります。ご使用のプラットフォームの12c (12.2.1) Oracle Grid Infrastructureインストレーション・ガイドを参照してください。

表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のサポートの有効化について説明します。

オペレーティング・システムの構成がOracle Fusion Middleware製品でサポートされる文字の動作に影響を与えることがあります。

UNIXオペレーティング・システムでは、LANGとLC_ALLの各環境変数をUTF-8文字セットを使用したロケールに設定し、Unicodeサポートを有効化することを強くお薦めします。これにより、Unicodeのすべての文字が処理できるようになります。たとえば、Oracle WebCenter ContentテクノロジはUnicodeに基づいています。

オペレーティング・システムがUTF-8以外のエンコードを使用するように構成されている場合、Oracle WebCenter Contentコンポーネントが予期しない動作をする可能性があります。たとえば、ASCII以外のファイル名の場合は、ファイルにアクセスできず、エラーが発生する可能性があります。オペレーティング・システムの制約によって発生する問題はサポート対象外となります。

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

この項では、各ホストで必要な共有ファイル・システムのマウントについて説明します。

「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」の説明に従って構成された共有記憶域が、それを使用するホスト上で使用可能になっている必要があります。

エンタープライズ・デプロイメントでは、ハードウェア記憶域ファイラが存在することと、それがデプロイメント用に取得した各ホスト・コンピュータに接続されて使用可能になっていることが前提とされています。

共有記憶域を、アクセスが必要なすべてのサーバーにマウントする必要があります。

各ホストでは、適切な権限をNetwork Attached Storage (NAS)またはStorage Area Network (SAN)内で設定し、共有記憶域への書込みを可能にする必要があります。

共有記憶域のマウントについては、組織のベスト・プラクティスに従ってください。この項では、NFS記憶域を使用してLinuxでこれを行う方法の例を示します。

共有記憶域の場所を作成してマウントし、WCCHOST1とWCCHOST2が2つの別々のボリュームへのバイナリ・インストールである場合に、それらが同じ場所を参照できるようにする必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

次のコマンドを使用して、共有記憶域をNAS記憶域デバイスからLinuxホストにマウントします。別のタイプの記憶域デバイスまたはオペレーティング・システムを使用している場合、これを行う方法の詳細は製造元のドキュメントを参照してください。

注意:

共有記憶域のファイル・システムの作成に使用されるユーザー・アカウントは、これらのファイルに対する読取り、書込みおよび実行権限を持ちます。オペレーティング・システム・グループにおける他のユーザーは、ファイルの読取りや実行は可能ですが、書込み権限はありません。

インストールと構成の権限の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストレーション・ユーザーの選択に関する項を参照してください。

次の例では、nasfilerは共有記憶域ファイラを表します。これらは単なる例であることに注意してください。通常、これらの共有記憶域場所のマウントは、UNIXシステム上の/etc/fstabsファイルを使用して行う必要があります。これにより、再起動しても、これらのデバイスのマウントが維持されます。詳細は、オペレーティング・システムのドキュメントを参照してください。

1. 「エンタープライズ・デプロイメントの共有記憶ボリュームのサマリー」の説明に従ってマウント・ディレクトリをWCCHOST1に作成してから、共有記憶域をマウントします。次に例を示します。

mount -t nfs nasfiler:VOL1/oracle/products/ /u01/oracle/products/

2. VOL2を使用してWCCHOST2でこの手順を繰り返します。

共有記憶域の構成の検証

構成した共有記憶域にテスト・ファイルを作成し、新しくマウントしたディレクトリでファイルの読取りおよび書込みができることを確認します。

次に例を示します。

$ cd newly mounted directory
$ touch testfile

所有者と権限が正しいことを確認します。

$ ls -l testfile

ファイルを削除します。

$ rm testfile

注意:

共有記憶域には、NASデバイスまたはSANデバイスを使用できます。次は、NASデバイスの記憶域をWCCHOST1から作成する例を示しています。オプションは、具体的な記憶域デバイスに応じて異なる場合があります。

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アドレスを各ホスト上で有効化するための情報を提供します。

エンタープライズ・デプロイメント用に各ホストを準備するには、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で説明されている仮想IP (VIP)アドレスを有効化する必要があります。

すでにVIPアドレスおよびホスト名を予約済であり、ネットワーク管理者がそれらを有効化していることを前提とします。次に、適切なホストでVIPを有効化できます。

エンタープライズ・トポロジで使用する仮想IPアドレスは、サーバー全体の移行(選択した管理対象サーバーおよびクラスタの場合)または手動フェイルオーバー(管理サーバーの場合)によって管理されるため、永続化されません。

各ホストでこの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

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

この章では、Oracle WebCenter Contentエンタープライズ・デプロイメント用のデータベースの準備手順について説明します。

この章では、データベースの要件、データベースの作成方法およびデータベースのバックアップ戦略について説明します。

- エンタープライズ・デプロイメント用のデータベースの準備の概要
この項では、Oracle Fusion Middlewareエンタープライズ・デプロイメントの一環として、サポートされているデータベースを構成する方法について説明します。

- データベース要件について
データベースが次の各項に記載されている要件を満たしていることを確認します。

- データベース・サービスの作成
複数のOracle Fusion Middleware製品で同一データベースを共有する場合は、各製品を個別の専用データベース・サービスに接続するように構成します。

- Oracleデータベースでのラージ・オブジェクト(LOB)に対するSecureFilesの使用
Oracle Database 11gリリース1以降、新しいLOB記憶域アーキテクチャであるSecureFilesが導入されました。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インストレーション・ガイド(Linux版)を参照してください。

- Oracle Real Application Cluster
詳細は、Oracle Real Application Clustersインストレーション・ガイド(LinuxおよびUNIX版)を参照してください。

- Oracle RACデータベース・インスタンス間の時間同期
サーバー移行で構成された、Fusion Middlewareクラスタ内のサーバーで使用されているデータベース・インスタンスのクロックは、同期化されている必要があります。

- 自動ストレージ管理(オプション)
詳細は、『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 => 'wccedg.example.com',
NETWORK_NAME => 'wccedg.example.com'
);

注意:

Oracle RACデータベースのサービス名には小文字を使用し、続けてドメイン名を指定します。次に例を示します。

wccedg.example.com

注意:

EXECUTE DBMS_SERVICEコマンドを1行で入力します。

DBMS_SERVICEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプのリファレンスを参照してください。

2. サービスをデータベースに追加し、srvctlを使用してインスタンスに割り当てます。

srvctl add service -d wccdb -s wccedg.example.com -r wccdb1,wccdb2

3. サービスを開始します。

srvctl start service -d wccdb -s wccedg.example.com

注意:

SRVCTLを使用したデータベース・サービスの作成および管理の完全な手順については、『Real Application Clusters管理およびデプロイメント・ガイド』のSRVCTLでのサービスの作成に関する項を参照してください。

4. 実行時接続のロード・バランシングについてロード・バランシング・アドバイザと適切なサービスレベル目標を使用するようにサービスを変更します。

具体的には、Oracle Database 12cの『Real Application Clusters管理およびデプロイメント・ガイド』で次の手順を使用して、SERVICE_TIMEおよびTHROUGHPUTサービスレベル目標を設定します。

- ロード・バランシング・アドバイザの概要に関する項

- ロード・バランシング・アドバイザを使用する環境の構成に関する項

9.4 Oracleデータベースでのラージ・オブジェクト(LOB)に対する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上に1つ、WEBHOST2上に1つ)を含むスタンドアロンOracle HTTP Serverドメインのインストールおよび構成方法を説明します。

- Oracle WebCenter Contentを追加するためのドメインの拡張
この章では、Oracle WebCenter Contentソフトウェアを使用してエンタープライズ・デプロイメント・ドメインを拡張する方法を説明します。

- Oracle SOA Suiteを含めるドメインの拡張
ここでは、Oracle SOA Suiteソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

- Inbound Refineryを追加するためのドメインの拡張
ここでは、エンタープライズ・デプロイメント・ドメインを拡張してInbound Refineryソフトウェアを含める方法を説明します。

- Captureを追加するためのドメインの拡張
この章では、Oracle WebCenter Enterprise Captureソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

- WebCenter Contentユーザー・インタフェースを追加するためのドメインの拡張
この章では、Oracle WebCenter Contentユーザー・インタフェース・ソフトウェアを含めてエンタープライズ・デプロイメント・ドメインを拡張する方法を説明します。

10 エンタープライズ・デプロイメントの初期管理サーバー・ドメインの作成

この章では、エンタープライズ・デプロイメントの開始点として使用できる初期ドメインのインストールおよび構成方法について説明します。このガイドの後の章では、デプロイしようとしているエンタープライズ・トポロジを構成する各種製品およびコンポーネントを含めることで、この初期ドメインを拡張する方法について説明します。

この章では、管理ドメインの作成、データベース・スキーマの作成、および管理サーバー・ドメインの構成で使用する変数について説明します。

- 管理ドメインの作成時に使用する変数
この章のタスクを実行すると、この項で示すディレクトリ変数を参照することになります。

- 初期管理ドメインの理解
Oracle Fusion Middlewareインフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。

- エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール
エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

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

- 管理サーバー・ドメインの構成
この項では、構成ウィザードを使用してWebLogicドメインを作成するための指示について説明します。

- 管理サーバーの起動
ドメインを作成したら、WCCHOST1上で次のタスクを実行できます。

- 新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング
Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

上位トピック: 「エンタープライズ・ドメインの構成」

10.1 管理ドメインの作成時に使用する変数

この章のタスクを実行すると、この項で示すディレクトリ変数を参照することになります。

ディレクトリ変数は、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されています。

- ORACLE_HOME

- APPLICATION_HOME

- JAVA_HOME

さらに、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」で定義されている次の仮想IP (VIP)アドレスとホスト名を参照することになります。

- ADMINVHN

- WCCHOST1

- WCCHOST2

- DBHOST1

- DBHOST2

- Oracle RACデータベースのSCANアドレス(DB-SCAN.example.com)

10.2 初期管理ドメインの理解

Oracle Fusion Middlewareインフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。

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

- 初期管理ドメインの特徴

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 (Fusion Middleware Control)、リポジトリ作成ユーティリティ(RCU)およびOracle Fusion Middleware製品のサポートに必要なその他のライブラリおよびテクノロジで構成されています。

このガイドの後のほうでは、エンタープライズ・デプロイメントに必要なOracle Fusion Middleware製品をサポートするために、そのドメインを拡張します。

詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middleware Infrastructureの理解に関する項を参照してください。

10.2.2 初期管理ドメインの特徴

次の表に、初期管理ドメインの主な特徴を示します。これらの特徴を確認して理解することで、ドメインの構成手順の目的やコンテキストに対する理解が深まります。

これらの特徴の多くは、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

ドメインの特徴

詳細情報

管理サーバーのみを含む。管理対象サーバーがドメインに追加されるのは、後でOracle Fusion Middleware製品を含むように初期ドメインを拡張するとき。

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

管理サーバーに別個の仮想IP (VIP)アドレスを使用。

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

ドメインごとのノード・マネージャ構成を使用。

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

別途インストールされたLDAPベースの認証プロバイダが必要。

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

10.3 エンタープライズ・デプロイメントの準備におけるOracle Fusion Middleware Infrastructureのインストール

エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

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

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

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

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

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

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を次の場所にインストールします。

- アプリケーション層の各ホスト・コンピュータからアクセスできる共有記憶域デバイス

- Web層の各ホスト・コンピュータのローカル記憶域デバイス
DMZに配置されるWeb層ホスト・コンピュータは、アプリケーション層の共有記憶域に必ずしもアクセスできるとはかぎりません。

JDKソフトウェアの推奨場所の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。

次の例では、JDK 1.8の最新バージョンをインストールする方法について説明します。

1. ディレクトリを、JDKアーカイブ・ファイルをダウンロードした場所に変更します。

2. アーカイブをJDKホーム・ディレクトリに解凍して、次のコマンドを実行します。

cd download_dir
tar -xzvf jdk-8u51-linux-x64.tar.gz

ここに示すJDKバージョンはこのドキュメントの公開時点のものであることに注意してください。サポートされる最新のJDKは、最新Oracle Fusion Middlewareリリースの「Oracle Fusion Middlewareのシステム要件と仕様」を参照してください。

3. JDKディレクトリをディレクトリ構造内の推奨の場所に移動します。

次に例を示します。

mv ./jdk1.8.0_51 /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_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, 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.0.0_infrastructure.jarです。

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

インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラムの説明については、「インストール画面への移動」を参照してください。

10.3.3 インフラストラクチャ・インストール画面のナビゲート

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

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

画面

説明

インストール・インベントリの設定

この画面は、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ホームに適用する必要がある1つ以上のアプリケーション・パッチが見つかった場合。

この画面には、自動更新機能で見つかったパッチがリストされます。1つ以上のパッチを選択し、「次へ」をクリックして、選択したパッチをOracleホームに適用します。

インストールの概要

この画面を使用して、選択したインストール・オプションを確認します。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールやコマンド行インストールの詳細は、『Oracle Universal Installerによるソフトウェアのインストール』でサイレント・モードにおけるOracle Universal Installerの使用方法に関する項を参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

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

WCCHOST2用に別の共有記憶域ボリュームまたはパーティションを構成している場合は、WCCHOST2にもInfrastructureをインストールする必要があります。

詳細は、「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「WCCHOST1でのインフラストラクチャ・インストーラの起動」と「インフラストラクチャ・インストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。

注意:

以前のリリースでは、同一場所に配置されるOracle HTTP Serverインスタンスのセットが推奨エンタープライズ・トポロジに含まれていました。これらのリリースでは、インフラストラクチャをWeb層ホスト(WEBHOST1およびWEBHOST2)にインストールする要件がありました。ただし、このリリースでは、エンタープライズ・デプロイメント・トポロジは、Webサーバーがスタンドアロン・モードでインストールおよび構成されていると仮定するため、Webサーバーがアプリケーション層ドメインの一部とはみなされません。詳細は、「エンタープライズ・デプロイメント用のWeb層の構成」を参照してください

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

Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、次のディレクトリとサブディレクトリが表示されます。インストールの内容は、インストール中に選択したオプションによって異なります。

ディレクトリ構造をチェックする手順は次のとおりです。

1. ディレクトリをORACLE_HOMEディレクトリに変更します。

2. 次のコマンドを入力します。
ls -l

システムのディレクトリ構造は、次の例に示す構造と一致する必要があります。

/u01/oracle/products/fmw/

cfgtoollogs
coherence
em
install
inventory
OPatch
oracle_common
oraInst.loc
oui
root.sh
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スキーマの識別に使用するカスタム接頭辞を指定します。
カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。このガイドでは、FMW1221という接頭辞を使用します。

ヒント:

ここで入力したカスタム接頭辞を書き留めてください。これは後でドメインの作成時に必要になります。

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

2. 「AS共通スキーマ」を選択します。
「AS共通スキーマ」を選択すると、このセクションのすべてのスキーマが自動的に選択されます。

Common Infrastructure Servicesと呼ばれるスキーマも自動的に作成されます。このスキーマはグレー表示されており、選択も選択解除もできません。このスキーマ(STBスキーマ)を使用すると、ドメインの構成中にRCUから情報を取得できます。詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

ヒント:

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

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

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

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

ヒント:

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

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

RCU画面の残りの部分を先に進めて、スキーマ作成を完了します。

このガイドでは、残りの画面のデフォルト設定を受け入れるか、RCUでのOracle Fusion Middlewareスキーマの作成方法および必要な表領域の使用方法をカスタマイズします。

RCUおよびその機能と概念については、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

「完了サマリー」画面に到達したら、「閉じる」をクリックしてRCUを終了します。

10.5 管理サーバー・ドメインの構成

この項では、構成ウィザードを使用してWebLogicドメインを作成するための指示について説明します。

ドメイン作成に使用可能なその他の方法の詳細は、構成ウィザードを使用したWebLogicドメインの作成のWebLogicドメインの作成、拡張および管理のための追加ツールに関する項を参照してください。

- 構成ウィザードの起動

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

10.5.1 構成ウィザードの起動

ドメインの構成を開始するには、Oracle Fusion Middleware Oracleホームで次のコマンドを実行します。

ORACLE_HOME/oracle_common/common/bin/config.sh

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

この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。

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

「構成タイプ」画面で、新規ドメインを作成を選択します。

「ドメインの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOME変数の値を指定します。

ヒント:

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

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

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

- Oracle Enterprise Manager - 12.2.1.0 [em]
このテンプレートを選択すると、次の依存性が自動的に選択されます。

- Oracle JRF - 12.2.1.0 [oracle_common]

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

ヒント:

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

タスク3    アプリケーション・ホームの場所の選択

「アプリケーションの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。

ヒント:

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

タスク4    管理者アカウントの構成

「管理者アカウント」画面では、ドメインに対するデフォルトのWebLogic管理者アカウントにユーザー名とパスワードを指定します。

この画面で指定したユーザー名およびパスワードを書き留めておいてください。これらの資格証明は後でドメインの管理サーバーを起動して接続する際に必要になります。

タスク5    ドメイン・モードとJDKの指定

「ドメイン・モードおよびJDK」画面では、次の操作を実行します。

- 「ドメイン・モード」フィールドで、「本番」を選択します。

- 「JDK」フィールドでOracle Hotspot JDKを選択します。

「本番モード」をこの画面で選択すると、環境で高度なセキュリティが実現され、アプリケーションのデプロイと管理サーバーの起動でユーザー名とパスワードが必要になります。

ヒント:

開発モードと本番モードの違いなど、この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。

本番モードでは、起動アイデンティティ・ファイルを作成することで、管理サーバーの起動時に必要なユーザー名とパスワードの指定を省略できます。詳細は、「boot.propertiesファイルの作成」を参照してください。

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

「RCUデータ」を選択して、この画面に示されるフィールドをアクティブ化します。

「RCUデータ」オプションによってデータベースおよびサービス表(STB)スキーマに接続し、ドメインの構成に必要なスキーマのスキーマ情報を自動的に受け取るように構成ウィザードで指定できます。

注意:

この画面の「手動構成」を選択した場合は、「JDBCコンポーネント・スキーマ」画面でスキーマのパラメータを手動で入力する必要があります。

「RCUデータ」を選択したら、次の表に示すフィールドに入力します。図10-1 のサンプルの「データベース構成タイプ」画面の部分的なスクリーン・ショットを参照してください。

フィールド

説明

DBMS/サービス

製品スキーマをインストールするOracle RACデータベースのサービス名を入力します。次に例を示します。

orcl.example.com

必ずOracle RACデータベース内のすべてのインスタンスの識別に使用される共通サービス名を指定してください。ホスト固有のサービス名は使用しないでください。

ホスト名

Enterprise Deployment Workbookに入力したOracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

ポート

データベースがリスニングするポート番号を入力します。たとえば、1521などです。

スキーマ所有者

スキーマ・パスワード

データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。

これはRCUの「スキーマ・パスワード」画面でサービス表コンポーネントに指定したスキーマ(「データベース・スキーマの作成」を参照)のユーザー名およびパスワードです。

デフォルトのユーザー名はprefix_STBであり、この場合prefixはRCUで定義したカスタム接頭辞です。

図10-1 エンタープライズ・デプロイメントのデータベース構成タイプの設定

データベース接続情報の指定が完了したら、「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コンポーネント・スキーマ」画面で、表10-1と図10-2に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

表10-1 「GridLink Oracle RACコンポーネント・スキーマ」画面で選択したフィールドの推奨値

要素

説明と推奨値

「SCAN」、「ホスト名」および「ポート」

「SCAN」チェック・ボックスを選択します。

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

「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)。

「ONSホスト」と「ポート」

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

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

「FANの有効化」チェック・ボックスを選択して、FANイベントを受信および処理できるようにします。

図10-2 「GridLink Oracle RACコンポーネント・スキーマ」画面のサンプル値

この画面で情報を指定する方法の詳細および適切なSCANアドレスの特定方法については、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。

また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。

タスク9    JDBC接続のテスト

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

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

ヒント:

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

タスク10    拡張構成の選択

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

- 管理サーバー
これは、管理サーバーのリスニング・アドレスを適切に構成するために必要です。

- ノード・マネージャ
これは、ノード・マネージャを構成するために必要です。

- 管理対象サーバー、クラスタおよびCoherence
これは、管理対象サーバーとクラスタの構成で必要ですが、マシンを構成して管理対象サーバーをマシンにターゲット指定するためにも必要です。

注意:

構成ウィザードの「拡張構成」画面を使用するときは、次のようにします。

- この画面で前述のオプションのいずれかが使用可能でない場合は、「テンプレート」画面に戻り、このトポロジに必要なテンプレートが選択されていることを確認します。

- 「ドメイン・フロントエンド・ホストのキャプチャ」拡張構成オプションを選択しないでください。後で、ドメインに対してではなく特定のクラスタに対してフロントエンド・ホスト・プロパティを構成します。

タスク11    管理サーバーのリスニング・アドレスの構成

「管理サーバー」画面で、次の手順を実行します。

1. 「サーバー名」フィールドで、デフォルト値(AdminServer)を維持します。

2. 「リスニング・アドレス」フィールドに、「エンタープライズ・デプロイメント用のリソースの取得」で取得し、「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で有効化したADMINVHNのVIPに対応する仮想ホスト名を入力します。
ADMINVHN仮想ホストを使用する理由の詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

3. 他のフィールドでは、デフォルト値をそのまま使用します。
特に、管理サーバーにサーバー・グループが割り当てられていないことを確認してください。

タスク12    ノード・マネージャの構成

ノード・マネージャ・タイプとして「ドメインごとのデフォルトの場所」を選択し、ノード・マネージャへの接続に使用するノード・マネージャ資格証明を指定します。

ヒント:

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

ドメインごとのノード・マネージャおよびホストごとのノード・マネージャの実装の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

その他の情報は、『Oracle WebLogic Serverノード・マネージャの管理』の複数マシンでのノード・マネージャの構成に関する項を参照してください。

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

初期管理サーバー・ドメインには管理対象サーバーはありません。「次へ」をクリックして次の画面に進みます。

タスク14    クラスタの構成

初期管理サーバー・ドメインにはクラスタはありません。「次へ」をクリックして次の画面に進みます。

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

初期管理サーバー・ドメインにはクラスタはありません。「次へ」をクリックして次の画面に進みます。

タスク16    マシンの作成

「マシン」画面を使用して、ドメイン内に新しいマシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。

1. 「Unixマシン」タブを選択します。

2. 「追加」ボタンをクリックして新しいUnixマシンを作成します。
表10-2の値を使用して、新しいマシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。

3. 「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。
この例に示されているポート番号5556は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。

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

名前

ノード・マネージャのリスニング・アドレス

ノード・マネージャのリスニング・ポート

ADMINHOST

ADMINVHN変数の値を入力します。

5556

ヒント:

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

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

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

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

ドメイン作成は、「作成」をクリックするまでは開始されません。

ヒント:

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

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

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

- ドメインの場所

- 管理サーバーURL

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

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

10.6 管理サーバーの起動

ドメインを作成したら、WCCHOST1上で次のタスクを実行できます。

- WCCHOST1上の管理サーバー・ドメイン・ホームでのノード・マネージャの起動
ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動するには、次の手順を使用します。

- boot.propertiesファイルの作成
ノード・マネージャ資格証明を要求されずにノード・マネージャを起動したい場合は、boot.propertiesを作成する必要があります。この手順は、エンタープライズ・デプロイメントでは必須です。このファイルに入力した資格証明は、管理サーバーの起動時に暗号化されます。

- ノード・マネージャを使用した管理サーバーの起動
ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ノード・マネージャを使用して、管理サーバーとドメイン内のすべての管理対象サーバーを起動および停止します。

- 管理サーバーの検証
構成手順に進む前に、管理サーバーが正常に起動して実行されていることを検証するために、管理サーバーにインストールおよび構成されているOracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlへのアクセス権があることを確認します。

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

ASERVER_HOMEドメイン・ディレクトリのドメインごとのノード・マネージャを起動するには、次の手順を使用します。

1. nodemanager.propertiesファイルのリスニング・アドレスが正しく設定されていることを確認します。

a. テキスト・エディタを使用して次のファイルを開きます。

ASERVER_HOME/nodemanager/nodemanager.properties

b. ListenAddressプロパティがADMINVHN仮想IPアドレスの値に設定されていることを確認します。

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. WebLogic Server管理コンソールで定義したノード・マネージャ資格証明を使用してノード・マネージャに接続します。

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

Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

次の各項では、Oracle WebLogic Server管理コンソールを使用してエンタープライズ・デプロイメント・ドメイン用の新しい認証プロバイダを作成する方法を説明します。この手順では、サポートされているLDAPディレクトリ(Oracle Unified DirectoryやOracle Internet Directoryなど)をすでにインストールおよび構成していることを想定しています。

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

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

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

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

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

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

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

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

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

Oracle Fusion Middlewareでは、様々なLDAP認証プロバイダをサポートしています。詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・タイプおよびWebLogicオーセンティケータに関する項を参照してください。

このガイドの手順では、次のいずれかのプロバイダを使用していることを想定しています。

- Oracle Unified Directory

- Oracle Internet Directory

- Oracle Virtual Directory

注意:

ここに示す手順では、デフォルトで単一のLDAPアイデンティティ・ストアに対する問合せをサポートするようにアイデンティティ・サービス・インスタンスを構成する方法を説明します。

ただし、LibOVDを使用して、複数のLDAPアイデンティティ・ストアに問合せを行う仮想アイデンティティ・ストアをサポートするようにサービスを構成できます。

複数LDAP参照に関する詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・サービスの構成に関する項を参照してください。

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

次の各項では、エンタープライズ・デプロイメント管理ユーザーおよび管理グループの用途と特性に関する重要な情報を提供します。

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

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

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

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

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

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

集中LDAPユーザー・ストアを使用すると、複数のOracle WebLogic Serverドメインで使用するユーザーおよびグループをプロビジョニングできます。その結果、あるWebLogic管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。

このようなアプローチはお薦めしません。かわりに、Oracle Fusion Middlewareドメインの管理用にプロビジョニングするユーザーおよびグループにディレクトリ・ツリー内で一意の識別名(DN)を割り当てる方法をお薦めします。

たとえば、Oracle WebCenter Contentエンタープライズ・デプロイメント・ドメインをインストールおよび構成する場合は、weblogic_wccというユーザーとWCCAdministratorsという管理グループを作成します。

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

LDAPディレクトリで個別のドメイン・コネクタ・ユーザー(たとえばwccLDAP)を作成することをお薦めします。このユーザーを使用して、ドメインがユーザー認証の目的でLDAPディレクトリに接続できます。このユーザーは管理ユーザー以外にすることをお薦めします。

標準的なOracle Identity and Access Managementデプロイメントでは、このユーザーをsystemidsコンテナに作成します。このコンテナは、ユーザーに対して通常は表示されないシステム・ユーザーのために使用されます。ユーザーをsystemidsコンテナに含めることで、Oracle Identity Managerを持つユーザーがこのユーザーを調整しなくなります。

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

エンタープライズ・ドメインのオーセンティケータになるように集中管理型LDAPディレクトリを構成した後、デフォルトのWebLogic Serverオーセンティケータではなく新しいオーセンティケータにすべての新規ユーザーを追加する必要があります。

新規ユーザーを集中管理型LDAPディレクトリに追加する際にはWebLogic管理コンソールは使用できません。かわりに、適切なLDAP変更ツール(ldapbrowserまたはJXplorerなど)を使用する必要があります。

複数のオーセンティケータを使用している場合(エンタープライズ・デプロイメントの要件)、ログインと認証は機能しますが、ロールの取得は機能しません。ロールは最初のオーセンティケータのみで取得されます。その他のオーセンティケータを使用してロールを取得しようとする場合は、ドメインの仮想化を有効にする必要があります。

仮想化を有効にする手順は次のとおりです。

1. 次の構成ファイルを探してテキスト・エディタで開きます。

DOMAIN_HOME/config/fmwconfig/jps-config.xml

2. 次のようにプロパティを追加または更新します。

<property name="virtualize" value="true"/>

virtualizeプロパティの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のOPSSシステムおよび構成プロパティに関する項を参照してください。

10.7.2.4 Oracle WebCenter Contentの製品固有のロールとグループについて

各Oracle Fusion Middleware製品は、管理と監視のために独自の事前定義済ロールおよびグループを実装します。

その結果、ドメインを拡張して他の製品を追加するときに、これらの製品固有のロールをWCCAdministratorsグループに割り当てることができます。ロールがWCCAdministratorsグループに追加されると、各製品管理者ユーザーは管理タスクを実行するための同じ権限セットを使用してドメインを管理できます。

WCCAdministratorsグループに他のロールを追加する手順については、「エンタープライズ・デプロイメントの共通の構成および管理タスク」を参照してください。

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

このガイドで使用するサンプルでは、下に示すDNを持つ次の管理ユーザーおよび管理グループをプロビジョニングすることを想定しています。

- 管理ユーザーのDN:

cn=weblogic_wcc,cn=users,dc=example,dc=com

- 管理グループのDN:

cn=WCCAdministrators,cn=groups,dc=example,dc=com

- 製品固有のLDAPコネクタ・ユーザー:

cn=wccLDAP,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.7.3 新しい認証プロバイダの作成と新しいユーザーおよびグループのプロビジョニングの前提条件

新しいLDAP認証プロバイダを作成する前に、関連する構成ファイルをバックアップする必要があります。

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

さらに、次のディレクトリにある管理サーバーのboot.propertiesファイルをバックアップする必要があります。

DOMAIN_HOME/servers/AdminServer/security

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

この例では、集中管理型LDAPディレクトリにwccLDAPというユーザーを作成する方法を示します。

LDAPプロバイダでユーザーをプロビジョニングする手順は次のとおりです。

1. 次に示す内容を指定してdomain_user.ldifという名前のldifファイルを作成し、保存します。

dn: cn=wccLDAP,cn=systemids,dc=example,dc=com
changetype: add
orclsamaccountname: wccLDAP
userpassword: password
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: wccLDAP@example.com
givenname: wccLDAP
sn: wccLDAP
cn: wccLDAP
uid: wccLDAP

注意:

Oracle Unified Directoryを使用する場合、LDIFファイルの末尾に次の4つのグループ・メンバーシップを追加して、適切な読取り/書込み権限を付与します。

dn:
cn=orclFAUserReadPrivilegeGroup,cn=groups,dc=us,dc=oracle,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=wccLDAP,cn=systemids,dc=us,dc=oracle,dc=com

dn: cn=orclFAGroupReadPrivilegeGroup,cn=groups,dc=us,dc=oracle,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=wccLDAP,cn=systemids,dc=us,dc=oracle,dc=com

dn: cn=orclFAUserWritePrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=wccLDAP,cn=systemids,dc=example,dc=com

dn: cn=orclFAGroupWritePrivilegeGroup,cn=groups,dc=example,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=wccLDAP,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.7.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セキュリティの管理』のOracle Internet DirectoryおよびOracle Virtual Directory認証プロバイダでのユーザーおよびグループの構成に関する項を参照してください。

パラメータ

値の例

値の説明

ホスト

例: oud.example.com

LDAPサーバーのサーバーID。

ポート

例: 1689

LDAPサーバーのポート番号。

プリンシパル

例: cn=wccLDAP, 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

OracleUnifiedDirectoryAuthenticatorがOUDで使用されるとき、この値にはentryuuidが事前に移入されます。認証プロバイダとしてOracle Unified Directoryを使用している場合はこの値を確認します。

14. 「保存」をクリックして変更を保存します。

15. 右のナビゲーション・ペインで「セキュリティ・レルム」をクリックして、デフォルトのレルム名(myrealm)をクリックし、「プロバイダ」をクリックして「プロバイダ」ページに戻ります。

16. 「並替え」をクリックし、表示されたページを使用して、作成したプロバイダを認証プロバイダのリストの先頭に配置します。

17. 「OK」をクリックします。

18. チェンジ・センターで、変更のアクティブ化 をクリックします。

19. 管理サーバーを再起動します。
ノード・マネージャを使用して管理サーバーを停止および起動する手順は次のとおりです。

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()

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.7.6 エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

この例では、weblogic_wccというユーザーとWCCAdministratorsというグループを作成する方法を示します。

LDAPプロバイダで管理ユーザーおよび管理グループをプロビジョニングする手順は次のとおりです。

1. 次に示す内容のadmin_user.ldifという名前のldifファイルを作成して保存します。

dn: cn=weblogic_wcc,cn=users,dc=example,dc=com
changetype: add
orclsamaccountname: weblogic_wcc
userpassword: password
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: weblogic_wcc@example.com
givenname: weblogic_wcc
sn: weblogic_wcc
cn: weblogic_wcc
uid: weblogic_wcc

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=WCCAdministrators,cn=Groups,dc=example,dc=com
displayname: WCCAdministrators
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_wcc,cn=users,dc=example,dc=com
cn: WCCAdministrators
uniquemember: cn=wccLDAP, cn=systemids, dc=example, dc=com
cn: WCCAdministrators
description: Administrators Group for the Oracle WebCenter Content Domain

4. LDAPディレクトリでグループをプロビジョニングします。
Oracle Unified Directoryの場合:

OUD_INSTANCE_HOME/bin/ldapmodify -a \
-D "cn=oudadmin" \
-h oudhost.example.com \
-w password \
-p 3060 \
-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.7.7 管理グループへの新しい管理ユーザーの追加

Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内でそのグループに管理ロールを割り当てる必要があります。これにより、このグループに属するすべてのユーザーがそのドメインの管理者になることができます。

管理ロールを新しいエンタープライズ・デプロイメント管理グループに割り当てる手順は次のとおりです。

1. 構成ウィザードで指定した管理資格証明を使用してWebLogic管理サーバー・コンソールにログインします。

作成して新しい認証プロバイダに提供した管理ユーザーの資格証明は使用しないでください。

2. 管理コンソールの左ペインで「セキュリティ・レルム」をクリックします。

3. デフォルト・セキュリティ・レルム(myrealm)をクリックします。

4. 「ロールとポリシー」タブをクリックします。

5. 表の「グローバル・ロール」エントリを開き、「ロール」をクリックします。

6. 「管理」ロールをクリックします。

7. 「条件の追加」ボタンをクリックします。

8. 「述部リスト」ドロップダウン・メニューで「グループ」を選択し、「次へ」をクリックします。

9. 「グループ引数名」フィールドにWCCAdministratorsと入力して、「追加」をクリックします。

WCCAdministratorsが引数のリスト・ボックスに追加されます。

10. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。

WCCAdministratorsグループが表示されるようになりました。

11. 「保存」をクリックして、WCCAdministratorsグループへの「管理」ロールの追加を終了します。

12. 新しいweblogic_wccユーザー資格証明を使用してWebLogic管理サーバー・コンソールにログインし、変更が行われたことを確認します。

新しい認証プロバイダでプロビジョニングした新しい管理ユーザーの資格証明を使用してOracle WebLogic Server管理コンソールとFusion Middleware Controlにログインできる場合は、プロバイダは正常に構成されています。

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

新しい管理ユーザーおよびグループを作成したら、LDAPディレクトリで作成した管理ユーザー資格証明を使用して管理サーバーのboot.propertiesファイルを更新する必要があります。

1. WCCHOST1で、次のディレクトリに移動します。

ASERVER_HOME/servers/AdminServer/security

2. 既存のboot.propertiesファイルの名前を変更します。

mv boot.properties boot.properties.backup

3. テキスト・エディタを使用して、セキュリティ・ディレクトリにboot.propertiesというファイルを作成します。

4. 次の行をこのファイルに入力します。

username=weblogic_wcc
password=password

5. ファイルを保存します。

6. 管理サーバーを再起動します。

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

この章では、2つのOracle HTTP Serverインスタンス(WEBHOST1上に1つ、WEBHOST2上に1つ)を含むスタンドアロンOracle HTTP Serverドメインのインストールおよび構成方法を説明します。

この章では、Web層の構成とWeb層ドメインのインストールおよび構成の際に使用される変数について説明します。

- Web層の構成時に使用される変数
この章のタスクを実行すると、この項で示すディレクトリ変数を参照することになります。

- Web層ドメインについて
エンタープライズ・デプロイメントでは、各Oracle HTTP Serverインスタンスは個別のホストの専用スタンドアロン・ドメインに構成されます。これにより、最小限の構成と最小限のリソースを必要とする単純な構成を実行して管理できます。

- WEBHOST1へのOracle HTTP Serverのインストール
次の項では、Web層にOracle HTTP Serverソフトウェアをインストールする方法について説明します。

- 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層の構成時に使用される変数

この章のタスクを実行すると、この項で示すディレクトリ変数を参照することになります。

いくつかのディレクトリ変数の値は、「このガイドで使用するファイル・システムとディレクトリ変数」で定義されています。

- 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のインストール

次の項では、Web層にOracle HTTP Serverソフトウェアをインストールする方法について説明します。

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

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

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

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

インストール・プログラムを起動するには、次の手順を実行します。

1. WEBHOST1にログインします。

2. インストール・プログラムをダウンロードしたディレクトリに移動します。

3. 次のコマンドを入力して、インストール・プログラムを起動します。

./fmw_12.2.1.0.0_ohs_linux64.bin

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

11.3.2 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ホームには次のディレクトリが表示されるはずです。

bin
cfgtoollogs
crs
css
has
install
inventory
jlib
ldap
lib
network
nls
ohs
OPatch
oracle_common
oracore
oraInst.loc
oui
perl
plsql
plugins
precomp
rdbms
root.sh
slax
sqlplus
srvm
webgate
wlserver
xdk

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

次の項では、Web層ホストで新しいOracle HTTP Serverスタンドアロン・ドメインを作成する方法について説明します。

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

- Web層ドメインの構成ウィザード画面のナビゲート

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

構成ウィザードを開始するには、次のディレクトリに移動して、次のようにWebLogic Server構成ウィザードを起動します。

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

11.4.2 Web層ドメインの構成ウィザード画面のナビゲート

各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.0 [ohs]を選択します。

ヒント:

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

タスク3    Web層ドメインのJDKの選択。

Oracle Hotspot JDKを選択します。これは、Oracle HTTP ServerソフトウェアをインストールしたときにWeb層のOracleホームにインストールされています。

タスク4 システム・コンポーネントの追加

「システム・コンポーネント」画面で、1つのOracle HTTP Serverインスタンスを作成します。この画面ではデフォルトで1つのインスタンスが定義されています。

1. 「システム・コンポーネント」フィールドのデフォルト・インスタンス名はohs1であることに注意してください。このデフォルト名を使用します。

2. 「コンポーネント・タイプ」フィールドではOHSが選択されていることを確認します。

3. 「再起動間隔秒数」フィールドを使用して、アプリケーションが応答しない場合に、再起動を試行する前に待機する秒数を指定します。

4. 「再起動遅延秒数」フィールドを使用して、再起動を再度試行する前に待機する秒数を指定します。

タスク5    OHSサーバー画面

「OHSサーバー」画面を使用して、ドメイン内のOHSサーバーを構成します。

1. 「システム・コンポーネント」ドロップダウン・メニューから、ohs1を選択します。

2. 「リスニング・アドレス」フィールドにWEBHOST1と入力します。
残りのフィールドはすべて事前に移入されていますが、組織での必要に応じて値を変更できます。この画面のフィールドの詳細は、『構成ウィザードによるWebLogicドメインの作成』のOHSサーバーに関する項を参照してください。

3. 「サーバー名」フィールドで、リスニング・アドレスとリスニング・ポートの値を確認します。
正しくは次のようになります。

WEBHOST1:7777

タスク6    ノード・マネージャの構成

「ノード・マネージャ・タイプ」に「ドメインごとのデフォルトの場所」を選択し、ノード・マネージャ資格証明を指定します。

注意:

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

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

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

「構成のサマリー」画面には、拡張しようとする構成情報の詳細が含まれます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

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

ドメイン作成は、「作成」をクリックするまでは開始されません。

ヒント:

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

タスク8    ドメイン・ホームのメモ

「構成に成功しました」画面で、更新されたドメイン・ホームの場所が表示されます。

ここに表示される情報をメモしておいてください。サーバーの起動や管理サーバーへのアクセスで必要になります。

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

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

WEBHOST1でOracle HTTP ServerをインストールしてWeb層ドメインを構成したら、同じタスクをWEBHOST2でも実行する必要があります。

1. WEBHOST2にログインし、「WEBHOST1でのOracle HTTP Serverのインストール」の手順を使用して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までを繰り返して、WEBHOST2でohs2を起動します。

詳細は、『Oracle HTTP Serverの管理』のOracle HTTP Serverインスタンスの起動に関する項を参照してください。

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

次の項では、Webサーバー・インスタンスがリクエストをドメインのサーバーにルーティングするように、Oracle HTTP Server構成ファイルを更新する方法について説明します。

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

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

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

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

- 管理サーバーへのルーティングの構成

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

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

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

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

次の各項では、エンタープライズ・デプロイメントのOracle HTTP Server構成に必要な変更に関する概要情報を提供します。

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

- 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 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. コメント# Use name-based virtual hostingの後、コメント# VirtualHost exampleの前に、次のようにNameVirtualHostエントリを作成します。

NameVirtualHost WEBHOST1:7777

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

b. httpd.confにmoduleconfサブディレクトリのすべての*.confファイルをインクルードするINCLUDE文があることを確認します。

IncludeOptional "moduleconf/*.conf"

この文により、各コンポーネントに対して個別に仮想ホスト・ファイルを作成することが可能になり、仮想ホスト定義の更新、維持およびスケール・アウトが容易になります。

4. httpd.confファイルを保存します。

5. WEBHOST2にログインし、手順2から4までを実行してohs2インスタンスのhttpd.confファイルを更新します。
WEBHOST2では、すべてのWEBHOST1をWEBHOST2、すべてのohs1をohs2で置き換えます。

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. wccinternal_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost WEBHOST1:7777>
ServerName wccinternal.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ファイルおよびwccinternal_vh.confファイルを、WEBHOST2上の2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf

6. admin_vh.confファイルおよびwccinternal_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://wccinternal.example.com/index.html

11.7.5 管理サーバーへのルーティングの構成

Oracle HTTP Serverから管理サーバーにルーティングできるようにするには、一連の<Location>ディレクティブをOracle HTTP Server admin_vh.conf構成ファイルに追加する必要があります。

1. WEBHOST1にログインし、ディレクトリを次の場所に変更します。

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

2. 次のディレクティブをadmin_vh.confファイルの<VirtualHost>タグ内に追加します。

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

admin_vh.confファイルは、例11-1のように表示されます。

3. ohs1インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs1
./startComponent.sh ohs1

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

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf/

5. admin_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1の参照をWEBHOST2の参照に変更します。

6. ohs2インスタンスを再起動します。

a. ディレクトリを次の場所に変更します。

cd OHS_DOMAIN_HOME/bin

b. 次のコマンドを入力し、インスタンスを停止して起動します。

./stopComponent.sh ohs2
./startComponent.sh ohs2

例11-1 admin_vh.confファイルの内容の例

<VirtualHost WEBHOST1:7777>
ServerName admin.example.com:7777
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>

11.7.6 WebLogic Serverプラグイン有効化フラグの有効化

セキュリティのため、またロード・バランサがSSLリクエストを終了するため(Oracle HTTP ServerはリクエストをWebLogic Serverに非SSLとしてルーティングします)、ロード・バランサにSSLを構成した場合、そのドメインに対しWebLogic Serverプラグイン有効化フラグをオンにする必要があります。WebLogic Serverプラグイン有効化フラグを有効にする手順は次のとおりです。

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

2. 左側のナビゲーション・ツリーでドメイン名をクリックします。

3. 「Webアプリケーション」タブを開きます。

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

5. 「WebLogicプラグインの有効化」チェック・ボックスを選択します。

6. 変更を保存してアクティブ化します。

7. 管理サーバーを再起動します(管理コンソールが特に要求しない場合でも再起動してください)。

a. Oracle WebLogic Scripting Tool (WLST)を起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

b. WLSTシェル内で、nmConnectコマンドとノード・マネージャの資格証明を使用してノード・マネージャに接続し(ノード・マネージャが稼動していることを確認しておきます)、nmStartを使用してノード・マネージャを起動します。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCHOST1","5556", "domain_name","ASERVER_HOME")

wls:/nm/domain_namenmStart("AdminServer")

値node_admin_userおよびnode_admin_passwordは、ノード・マネージャの資格証明です。

c. 管理コンソールまたは次のようにWLST nmKillコマンドを使用して管理サーバーを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

d. nmStartを使用して管理サーバーを起動します。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCHOST1","5556", "domain_name","ASERVER_HOME")

wls:/nm/domain_namenmStart("AdminServer")

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

ロード・バランサを使用してWebLogic Server管理コンソールにアクセスする際には、管理サーバーのフロントエンドURLを変更し、適切なロード・バランサ・アドレスにユーザーのWebブラウザをリダイレクトする必要があります。

WebLogic Server管理コンソール・アプリケーションでは、コンソールを使用して、ポート、チャネル、セキュリティに対する変更を追跡します。コンソールを使用して行われた変更をアクティブ化するとき、コンソールは現在のリスニング・アドレス、ポートおよびプロトコルを検証します。このリスニング・アドレス、ポートおよびプロトコルがまだ有効の場合、コンソールはHTTPリクエストをリダイレクトし、ホストとポートの情報を管理サーバーのリスニング・アドレスとポートに置き換えます。

管理サーバーのフロントエンドURLを変更する手順は次のとおりです。

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

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

3. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 「サーバーのサマリー」ページで、表の「名前」列にある「管理サーバー」をクリックします。

6. 管理サーバーの設定ページで「プロトコル」タブをクリックします。

7. 「HTTP」タブをクリックします。

8. 「フロントエンド・ホスト」フィールドをadmin.example.comに設定し、「フロントエンドHTTPポート」フィールドを80に設定します(admin URLにHTTPSを使用する場合は適宜変更します)。

9. 変更を保存してアクティブ化します。

10. 管理サーバーを再起動して、フロントエンド・ホスト・ディレクティブに対する変更を有効にします。

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

この章で行った変更を確認する手順は次のとおりです。

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

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

この章では、Oracle 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ユーザー・インタフェース用のコンテンツ・サーバーの構成
WebCenter Contentユーザー・インタフェースを使用する予定である場合(コンテンツ・サーバーのネイティブ・ユーザー・インタフェースに加えて)、コンテンツ・サーバーのパラメータを有効にする必要があります。

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

上位トピック: 「エンタープライズ・ドメインの構成」

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

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

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

- インストール・プログラムの起動

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

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

- インストールの検証

12.1.1 インストール・プログラムの起動

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

1. WCCHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

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

JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.0.0_wccontent_generic.jar

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

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

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

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

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

画面

説明

「インストール・インベントリ」画面

Oracle Fusion Middleware Infrastructureソフトウェアをインストールしたときに中央インベントリを作成しなかった場合に、このダイアログ・ボックスが表示されます。

ローカル・インベントリの場所を指すように「インベントリ・ディレクトリ」フィールドを編集して、「OK」をクリックします。

ようこそ

製品のインストーラの紹介画面です。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。

前提条件チェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、Oracle Fusion Middleware Infrastructureのインストール計画のシステム環境の検証ロードマップに関する項でいずれかのドキュメントを参照してください。

セキュリティ・アップデートの指定

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所持していないときに、この手順を省略してもかまわない場合は、チェック・ボックスの選択を解除して、その選択を後続のダイアログ・ボックスで確認します。

インストールの概要

この画面を使用して、選択したインストール・オプションを確認します。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが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 - 完了

- Oracle WebCenter Enterprise Capture

- 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: WCCEDG_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 構成ウィザードの起動

注意:

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

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

1. ドメインを拡張する前に、ドメインを完全に停止します。WebLogic Serverコンソールから、すべての管理対象サーバーを停止して検証し、続いて管理サーバーを停止します。

詳細は、「WCCHOST1での構成ウィザードの起動」で、ノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

2. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

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

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

この項の手順に従って、トポロジのドメインを拡張します。

注意:

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

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

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

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

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

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

ヒント:

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

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

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

- Oracle Universal Content Management - コンテンツ・サーバー - 12.2.1 [wccontent]
また、初期インフラストラクチャ・ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

- Oracle Enterprise Manager - 12.2.1.0 [em]

- Oracle JRF - 12.2.1.0 [oracle_common]

- WebLogic Coherenceクラスタの拡張 - 12.2.1.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    拡張構成の選択

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

- 管理対象サーバー、クラスタおよびCoherence

- JMSファイル・ストア

タスク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ソフトウェアのターゲットにすることができる管理対象サーバーのクラスタを作成します。

クラスタの「フロントエンド・ホスト」プロパティも設定します。これにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上のwcc.example.comにリダイレクトするようになります。

wcc.example.com仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

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

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

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

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

注意:

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

ヒント:

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

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

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

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

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

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

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

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

ヒント:

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

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

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期インフラストラクチャ・ドメインの作成中に定義されているため、9991のままにします。

注意:

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

タスク12    WebCenter Content Serverのマシン

「マシン」画面を使用して、2つの新しいマシンを追加します。

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

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

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

4. この手順をWCCHOST2に対して繰り返します。

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

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

名前

ノード・マネージャのリスニング・アドレス

ノード・マネージャのリスニング・ポート

WCCHOST1

WCCHOST1ホスト名変数の値。たとえば、WCCHOST1.example.comです。

5556

WCCHOST2

WCCHOST2ホスト名変数の値。たとえば、WCCHOST2.example.comです。

5556

ADMINHOST

ADMINVHN変数の値を入力します。

5556

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

「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle WebCenter Content管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。

ADMINVHNをADMINHOSTに割り当てます。

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

ヒント:

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

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

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

ORACLE_RUNTIME/domain_name/WCC_Cluster/jms

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

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

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

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

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

「更新」をクリックするまで、ドメインの拡張は開始されません。

ヒント:

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

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

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

- ドメインの場所

- 管理サーバーURL

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

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

タスク17    管理サーバーの再起動

管理サーバーを再起動して、ドメインに行った変更が適用されたことを確認します。

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

ドメイン・ディレクトリに拡張したものの伝播、ノード・マネージャの起動、管理対象サーバー上へのコンテンツ・サーバーの構成などの、構成後タスクおよび検証タスクを実行します。

次の項では、WebCenter Content用の構成後タスクと検証タスクを実行する方法について説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

Oracle Contentを含めることでドメインを拡張し、WCCHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリおよびマシンに伝播できます。

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

- WCCHOST1での拡張済ドメインの圧縮

- WCCHOST1上の管理対象サーバー・ドメイン・ホームでのドメインの解凍

- WCCHOST2でのドメインの解凍

12.4.1.1 Derbyデータベースの無効化

管理対象サーバー・ディレクトリを作成して、管理対象サーバーを起動する前に、組込みDerbyデータベース(Oracle WebLogic Serverに含まれているファイルベースのデータベース)を無効にします。Derbyデータベースは、主に開発環境で使用されます。結果として、本番として使用可能なエンタープライズ・デプロイメント環境を構成する場合、それを無効にする必要があります。そうしないと、管理対象サーバーを起動するときに、Derbyデータベース・プロセスが自動的に開始されます。

Derbyデータベースを無効にする手順は次のとおりです。

1. Oracleホームの次のディレクトリに移動します。
WL_HOME/common/derby/lib

2. Derberライブラリjarファイルの名前を変更します。
mv derby.jar disable_derby.jar

12.4.1.2 WCCHOST1での拡張済ドメインの圧縮

次の手順を使用して、ドメイン構成情報(現時点ではOracle HTTP Serverインスタンスに関する構成情報も含まれる)を含むテンプレートJARファイルを作成します。

1. WCCHOST1にログインし、次のようにpackコマンドを実行してテンプレートJARファイルを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=edgdomaintemplateExtWCC.jar
-template_name=edgdomaintemplateExtWCC

この例では、次のとおりです。

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

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

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

2. packコマンドで作成したばかりのedgdomaintemplateExtWCC.jarファイルの場所を書き留めます。

デフォルトでは、パック・テンプレート・ファイルは、packコマンドを実行した現在のディレクトリに作成されます。この例では、ORACLE_COMMON_HOME/common/binディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。

ヒント:

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

12.4.1.3 WCCHOST1上の管理対象サーバー・ドメイン・ホームでのドメインの解凍

更新したドメイン構成情報を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播する手順は次のとおりです。

1. WCCHOST1にログインしていない場合は、ログインします。

2. まだ作成していない場合は、WCCHOST1に管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME  \
-template=edgdomaintemplateExtWCC.jar \
-overwrite_domain=true \
-app_dir=APPLICATION_HOME \

この例では、次のとおりです。

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

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

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

- APPLICATION_HOMEを、共有記憶域上のそのドメインのapplicationsディレクトリの完全なパスに置き換えます。

ヒント:

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

4. 新しく作成したMSERVER_HOMEディレクトリにディレクトリを変更して、ドメイン構成ファイルが「WCCHOST1上の管理対象サーバー・ドメイン・ホームでのドメインの解凍」共有記憶域デバイスの適切な場所にコピーされていることを確認します。

12.4.1.4 WCCHOST2でのドメインの解凍

ドメイン・テンプレートJARを作成したら、unpackコマンドを使用してドメイン構成を他のホストに伝播できます。ドメイン・テンプレートJARファイルを解凍する手順は次のとおりです。

1. WCCHOST2にログインします。

2. まだ作成していない場合は、WCCHOST2に管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. WCCHOST2がドメイン・テンプレートJARファイルにアクセスできるようにします。
たとえば、WCCHOST2のために別の共有記憶域ボリュームまたはパーティションを使用している場合は、WCCHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
-template=edgdomaintemplateExtWCC.jar \
-app_dir=APPLICATION_HOME \
-overwrite_domain=true

この例では、次のとおりです。

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

- edgdomaintemplateExtWCC.jarは、packコマンドを実行してドメインを圧縮したときに作成したテンプレートのディレクトリ・パスおよび名前です。
WCCHOST2に別の共有記憶域ボリュームまたはパーティション(および冗長Oracleホーム)を使用している場合は、WCCHOST2にマウントされているボリュームまたはパーティションに、まずテンプレートをコピーする必要があります。

- APPLICATION_HOMEを、共有記憶域上のそのドメインのapplicationsディレクトリの完全なパスに置き換えます。

ヒント:

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

5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがWCCHOST2の適切な場所にコピーされていることを確認します。

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

管理対象サーバーのドメイン・ディレクトリを作成した後は、2つのドメイン・ホーム・ディレクトリと、それに対応する2つの対応するノード・マネージャ・インスタンスがWCCHOST1上に存在します。1つのノード・マネージャは、管理サーバー・ドメイン・ホームから実行される管理サーバーの制御に使用します。もう1つのノード・マネージャは、管理対象サーバー・ドメイン・ホームから実行される管理対象サーバーの制御に使用します。

2つのノード・マネージャを別々に起動する必要があります。

次の手順に従って、管理対象サーバー・ホームからノード・マネージャを起動します。

1. 次のディレクトリに移動します。
MSERVER_HOME/bin

2. 次のコマンドを使用してノード・マネージャを起動します。

nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &

追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

12.4.3 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.4 WLS_WCC1管理対象サーバー上のコンテンツ・サーバーの構成

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

1. http://WCCHOST1:16200/csでweblogic_wcc管理ユーザー名とパスワードを使用してWLS_WCC1にログインし、構成ページを表示します。
Oracle WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Contentエンタープライズ・デプロイメントの共有ディスクの場所は、RUNTIME_HOME/WCDomain/WCC_Clusterです。

2. 「サーバーの構成」ページで次の値を変更します。
「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていることを確認します。

- コンテンツ・サーバーのインスタンス・フォルダ: これを/u01/oracle/runtime/WCDomain/WCC_Cluster/csに設定します。
構成を保存する前に、このディレクトリが存在しているか作成済であることを確認してください。

- ネイティブ・ファイル・リポジトリの場所: これを/u01/oracle/runtime/WCDomain/WCC_Cluster/cs/vaultに設定します。
構成を保存する前に、このディレクトリが存在しているか作成済であることを確認してください。

- Webレイアウト・フォルダ: これを/u01/oracle/runtime/WCDomain/WCC_Cluster/cs/weblayoutに設定します。
構成を保存する前に、このディレクトリが存在しているか作成済であることを確認してください。

- ユーザー・プロファイル・フォルダ: これを/u01/oracle/runtime/WCDomain/WCC_Cluster/cs/data/users/profilesに設定します。
構成を保存する前に、このディレクトリが存在しているか作成済であることを確認してください。

- サーバーのソケット・ポート: 4444

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

127.0.0.1|WCCHOST1-IP|WCCHOST2-IP|WEBHOST1-IP|WEBHOST2-IP|wccinternal.example.com|load-balancer-host-name

- WebサーバーのHTTP/HTTPSアドレス: wcc.example.com:443

- WebアドレスはHTTPSです: このチェック・ボックスを選択します。

- コンテンツ・サーバーのインスタンス名: WCC_Cluster

- コンテンツ・サーバーのインスタンス・ラベル: WCC_Cluster

- サーバー・インスタンスの説明: WebCenter Contentクラスタ

- 自動採番接頭辞: WCC_Cluster-

3. 完了したら「送信」をクリックし、WebLogic Server管理コンソールを使用して管理対象サーバーを再起動します。

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

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

これを行うには、次のコマンドを(すべて1行で)使用して、このファイルをWCCHOST1のASERVER_HOME/config/fmwconfigにコピーします。

scp -p \
WCCHOST1:/MSERVER_HOME/config/fmwconfig/cwallet.sso \
WCPHOST1:/ASERVER_HOME/config/fmwconfig/cwallet.sso

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

12.4.6 WCCHOST2でのノード・マネージャの起動

ドメイン構成をWCCHOST2に伝播したら、次のようにMSERVER_HOMEドメイン・ディレクトリのノード・マネージャを起動できます。

1. ディレクトリを、WCCHOST2の次のディレクトリに変更します。

MSERVER_HOME/bin

2. 次のコマンドを使用してノード・マネージャを起動します。

nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &

ノード・マネージャの追加の構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

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

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

1. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_WCC2管理対象サーバーを起動します。

a. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

b. 「サーバー」をクリックします。

c. 「サーバーのサマリー」ページで、「制御」タブを開きます。

d. 「WLS_WCC2」,を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

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

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

1. http://WCCHOST2:16200/csでOracle WebLogic Serverの管理ユーザー名とパスワードを使用して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. 完了したら「送信」をクリックし、WebLogic Server管理コンソールを使用して管理対象サーバーを再起動します。

12.4.9 GridLinkデータ・ソースの検証

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

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

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

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

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

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

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. 作成済のGridLinkデータ・ソース名をクリックします。

4. 「監視」タブをクリックします。

5. 「テスト」タブをクリックし、サーバーの1つを選択して「データ・ソースのテスト」をクリックします。
構成が正しい場合、テストは成功します。

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

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

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

1. 管理コンソールの「ドメイン構造」ツリーで、「サービス」ノードを開いて「データ・ソース」をクリックします。

2. GridLinkデータ・ソースの名前をクリックします。

3. 「監視」タブをクリックします。

4. サーバーの名前(WLS_WCC1)をクリックします。

5. 「ONS」→「テスト」タブをクリックします。

6. サーバーを選択し、「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

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

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

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

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

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

この変更は、「Oracle WebCenter Contentのサービス再試行の構成」で説明される手順の最後に、すべてのWebCenter Content管理対象サーバーを再起動させてから有効になります。

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

12.4.11 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ファイルに含まれます。このファイルは次の場所にあります。

DOMAIN_HOME/cluster_name/cs/config/config.cfg

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

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

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

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

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

1. weblogicアカウントを使用してコンテンツ・サーバーにログインします。

2. 「管理」メニューを開き、「資格証明マップ」を選択します。

3. 「マップ識別子」フィールドに、新しい資格証明マップの名前をLDAPAdminsと入力します。

4. 次の行を追加して、LDAPグループを複数の管理ロールにマップします。

# Assign full set of administration roles to the LDAP WCCAdministrators group
WCCAdministrators, admin
WCCAdministrators, sysmanager
WCCAdministrators, refineryadmin
WCCAdministrators, rmaadmin
WCCAdministrators, pcmadmin
WCCAdministrators, ermadmin
#
# Uncomment the following if implementing Accounts in Content Server
WCCAdministrators, @#all(RWDA)
WCCAdministrators, @#none(RWDA)

注意:
Content Serverにアカウントを実装する場合、上の例の末尾2行をコメント解除します。

5. 「更新」をクリックします。

6. 「管理」→「プロバイダ」に移動します。

7. 既存のJPSプロバイダの「info」リンクをクリックします。

8. 「資格証明マップ」パラメータが、リストされたマップ識別子をまだ持っていないことを確認します。

9. 「編集」ボタンをクリックします。

10. 前述の手順3のマップ識別子の名前を「資格証明マップ」の値として入力します。

11. 「更新」をクリックします。

12. WCC_Cluster内の管理対象サーバーを再起動します。

12.5 WebCenter Contentユーザー・インタフェース用のコンテンツ・サーバーの構成

WebCenter Contentユーザー・インタフェースを使用する予定である場合(コンテンツ・サーバーのネイティブ・ユーザー・インタフェースに加えて)、コンテンツ・サーバーのパラメータを有効にする必要があります。

「管理」トレイまたはメニューで、「管理サーバー」を選択します。「コンポーネント・マネージャ」を選択し、次のパラメータを有効にします。

- AutoSuggestConfig

- DynamicConverter

- FrameworkFolders

さらに、WebCenter Contentユーザー・インタフェースとコンテンツ・サーバー間の通信用にRemote Intradoc Client (RIDC)を設定する必要があります。

WebCenter Contentユーザー・インタフェースのフォルダおよび検索用に、次のコンテンツ・サーバーのパラメータも設定できます。WebCenter Contentユーザー・インタフェースのフォルダおよび検索用に、コンテンツ・サーバーのパラメータを設定する手順は次のとおりです。

1. 「管理」メニューから「管理サーバー」を選択します。

2. 「一般構成」を選択します。

3. 「一般構成」ページで、「追加の構成変数」タブに、次のパラメータを追加します。

- FoldersIndexParentFolderValues=true

- FldEnforceFolderFileNameUniqueness=true

- FldEnforceCaseInsensitiveNameUniqueness=true

- SearchIndexerEngineName=OracleTextSearchまたはSearchIndexerEngineName=DATABASE.METADATA
いずれかの値を選択 - OracleTextSearchまたはDATABASE.METADATA。

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

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

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

- コンテンツ・サーバーの管理アプレットのアクセスの有効化

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

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

Oracle WebCenter Contentクラスタにリクエストを正しくルーティングするようにWeb層のOracle HTTP Serverインスタンスを構成するには、次の手順を使用して、wcc.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. wcc_vh.confファイルを作成し、次のディレクティブを追加します。

<VirtualHost WEBHOST1:7777>
ServerName https://wccinternal.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

3. <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. wcc_vh.confファイルを2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/ohs2/moduleconf/

5. wcc_vh.confを編集して、<VirtualHost>ディレクティブ内のWEBHOST1の参照をWEBHOST2の参照に変更します。

6. WEBHOST1とWEBHOST2上のOracle HTTP Serverインスタンスを再起動します。

12.6.2 コンテンツ・サーバーの管理アプレットのアクセスの有効化

SSL終了がエンタープライズ・デプロイメントの参照トポロジに対してOracle Web層に構成されているため、コンテンツ・サーバーの管理アプレットにアクセスできるようにするには、WebLogicプラグインはWebCenter Content管理対象サーバーごとに有効にする必要があります。コンテンツ・サーバーの管理アプレットのアクセスを有効にする手順は次のとおりです。

1. http://host.domain:port/consoleでWebLogic Server管理コンソールにログインします。次に例を示します。

http://ADMINVHN:7001/console

2. 「環境」タブで、「サーバー」をクリックします。

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

4. 「構成」タブの「一般」タブをクリックし、「詳細」セクションに移動します。

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

6. 「WebLogicプラグインの有効化」ドロップダウン・メニューで「はい」を選択します。

7. 「保存」ボタンをクリックして、変更内容を保存します。

8. 「変更のアクティブ化」をクリックします。

9. 管理コンソールからWLS_WCC1管理対象サーバーを再起動します。

10. WLS_WCC2管理対象サーバーに対して前述の手順を繰り返します。

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

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

- URLの検証

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

12.6.3.1 URLの検証

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

1. WLS_WCC2が稼動している状態で、WebLogic Server管理コンソールを使用してWLS_WCC1を停止します。

2. https://wcc.example.com/csにアクセスし、正しく動作していることを確認します。

3. WebLogic Server管理コンソールからWLS_WCC1を起動します。

4. WebLogic Server管理コンソールでWLS_WCC2を停止します。

5. https://wcc.example.com/csにアクセスし、正しく動作していることを確認します。

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

12.6.3.2 クラスタ・ノードの検証

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

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

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

2. 「管理」の「WCC_Clusterの構成」ページを表示します。

3. ページの「オプションとその他」セクションで、右側の「Javaプロパティ」をクリックします。

4. weblogic.Nameの値を確認します。

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

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

ここでは、Oracle SOA Suiteソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

- Oracle SOA Suiteを含めるドメインの拡張時に使用される変数
この章のタスクを実行すると、この項で示すディレクトリ変数を参照することになります。

- システム・クロックの同期
Oracle SOA Suiteを含むようにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。これは、各クラスタ内のホストで可能なかぎり同時にdateコマンドを実行することで行えます。

- エンタープライズ・デプロイメント用のソフトウェアのインストール
次の各項では、エンタープライズ・デプロイメント用のソフトウェアのインストール方法を説明します。

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

- Oracle SOA Suiteを含めるエンタープライズ・デプロイメント・ドメインの拡張
この項では、Oracle SOA Suiteソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張する手順について説明します。

- トランザクション・リカバリ用のデフォルト永続ストアの構成
各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、各管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

- ドメイン・ディレクトリおよびマシンへの拡張済ドメインの伝播
Oracle WebCenter Contentインスタンスを含めることでドメインを拡張し、WCCHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリとマシンに伝播する必要があります。

- WLS_SOA1管理対象サーバーの起動と検証
これでドメインの拡張、管理サーバーの再起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle SOA Suiteサーバーを起動できます。

- SOAクラスタのフロントエンド・ホストおよびポートの設定
Oracle SOA SuiteサーバーをホスティングするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。これは、ドメインのプロパティを指定するときに、構成ウィザードで行うことができます。ただし、SOAクラスタをWebCenter Contentエンタープライズ・ドメインの一部として追加している場合は、SOA管理対象サーバーを確認した後でこのタスクを実行することをお薦めします。

- 管理対象サーバーWLS_SOA2の起動と検証
正常な構成とWLS_SOA1管理対象サーバーの起動を検証したら、WLS_SOA2管理対象サーバーを起動して検証できます。

- トランザクション・ログの場所と作成の検証
WLS_SOA1およびWLS_SOA2が起動していて稼働中になった後、トランザクション・ログ・ディレクトリおよびトランザクション・ログが、想定のとおりに作成されたことを確認します。

- 拡張したドメインでのOracle HTTP Serverの構成
次の項では、パブリックURLおよび内部URLの両方のリクエストを、エンタープライズ・トポロジ内の正しいWebcenter PortalクラスタにルーティングするようにOracle HTTP Serverインスタンスを構成する方法について説明します。

- Oracle SOA Suiteの構成後手順
Oracle SOA SuiteとOracle Business Process Managementをインストールして構成した後、次のような構成後タスクを検討します。

- Oracle SOA Suiteでの自動サービス移行とJDBC永続ストアの有効化
Oracle SOA Suiteが高可用性を実現するように構成するには、自動サービス移行に対応するようにOracle SOA Suite管理対象サーバーを構成します。

上位トピック: 「エンタープライズ・ドメインの構成」

13.1 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

この章のアクションは、次のホスト・コンピュータで実行します。

- WCCHOST1

- WCCHOST2

- WEBHOST1

- WEBHOST2

13.2 システム・クロックの同期

Oracle SOA Suiteを含むようにドメインを拡張する前に、各ホスト・コンピュータのシステム・クロックが同期していることを確認します。これは、各クラスタ内のホストで可能なかぎり同時にdateコマンドを実行することで行えます。

また、そのために使用できるサードパーティおよびオープンソースのユーティリティもあります。

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

次の各項では、エンタープライズ・デプロイメント用のソフトウェアのインストール方法を説明します。

- WCCHOST1でのインストーラの起動

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

- インストールの検証

13.3.1 WCCHOST1でのインストーラの起動

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

1. WCCHOST1にログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

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

JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.0.0_product.jar

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

ソフトウェアをダウンロードして、ご使用の製品に対応する実際のインストーラ・ファイル名を探す方法の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」を参照してください。

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

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

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

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

画面

説明

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチをMy Oracle Supportで自動的に検索するか、組織のためにすでにダウンロードしたパッチをローカル・ディレクトリで自動的に検索します。

インストールの場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

Oracle Fusion Middlewareディレクトリ構造の詳細は、Oracle Fusion Middlewareのインストールのプランニングでインストールと構成のディレクトリの選択に関する項を参照してください。

インストール・タイプ

この画面を使用してインストールのタイプと、それに従ってインストールされる製品および機能を選択します。

- 「SOA Suite」を選択します

注意: このドキュメントのトポロジにはサンプルは含まれません。本番環境にはサンプルをインストールしないことを強くお薦めします。

前提条件チェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告メッセージまたはエラー・メッセージが表示された場合は、Oracle Fusion Middleware Infrastructureのインストール計画のシステム環境の検証ロードマップに関する項でいずれかのドキュメントを参照してください。

インストールの概要

この画面を使用して、選択したインストール・オプションを確認します。

「インストール」をクリックしてインストールを開始します。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

進捗バーが100%完了になった後で、「次へ」をクリックします。

インストール完了

この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

13.3.3 インストールの検証

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

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

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

- Oracleホームの内容の表示

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

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

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

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

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

/u01/oracle/products/fmw/soa

aiafp
bam
bin
bpm
common
integration
jlib
plugins
readme.txt
reports
soa

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

13.3.3.3 Oracleホームの内容の表示

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

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

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

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

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

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

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

13.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

13.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インフラストラクチャ」が選択されます。また、次の依存スキーマがインフラストラクチャとともにすでにインストールされており、グレー表示されます。

- Metadata Services

- 監査サービス

- 監査サービスへの追加

- 監査サービス・ビューア

- Oracle Platform Security Services

- ユーザー・メッセージング・サービス

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

ヒント:

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

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

ヒント:

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

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

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

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

ヒント:

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

タスク6    カスタム変数の指定

SOAインフラストラクチャ・スキーマのカスタム変数を指定します。

エンタープライズ・デプロイメント・トポロジの場合、「データベース・プロファイル」カスタム変数としてMEDIUMを入力し、Healthcare Integration変数としてNOを入力します。

詳細は、『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』のSOA Suiteスキーマに必要なカスタム変数に関する項を参照してください。

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

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

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

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

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

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

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

次に例を示します。

./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_SOAINFRA
Enter password: soainfra_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>

13.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>

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

この項では、Oracle SOA Suiteソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張する手順について説明します。

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

- 構成ウィザードの起動

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

13.5.1 構成ウィザードの起動

注意:

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

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

1. ドメインを拡張する前に、ドメインを完全に停止します。WebLogic Serverコンソールから、すべての管理対象サーバーを停止して検証し、続いて管理サーバーを停止します。

詳細は、「WCCHOST1での構成ウィザードの起動」で、ノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

2. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

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

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

この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。

注意:

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

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

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

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

- タスク3「データベース構成タイプの指定」

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

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

- タスク6「JDBC接続のテスト」

- タスク8「詳細構成の選択」

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

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

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

- タスク12「Coherenceクラスタの構成」

- タスク13「既存のマシンの検証」

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

- タスク15「JMSファイル・ストアの構成」

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

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

- タスク18「管理サーバーの起動」

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

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

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

MSERVER_HOME変数の値(管理対象サーバー・ドメイン・ディレクトリの場所を表す)を入力しないでください。

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

ヒント:

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

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

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

- Oracle SOA Suite - 12.2.1.0 [soa]
初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

- 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]

また、WebCenter Contentをすでに構成しているため、次のテンプレートも選択する必要があります。

- Oracle Universal Content Management - コンテンツ・サーバー - 12.2.1 [wccontent]

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用した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)アドレスを入力します。

「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

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

「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

FANの有効化

「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。

タスク6    JDBC接続のテスト

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

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

ヒント:

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

タスク7    キーストア

この画面を使用して、新しいドメインで使用されるキーストアの詳細を指定します。

標準的なエンタープライズ・デプロイメントの場合は、デフォルト値を残すことができます。

詳細は、『構成ウィザードによるWebLogicドメインの作成』のキーストアに関する項を参照してください。

タスク8    拡張構成の選択

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

- 管理対象サーバー、クラスタおよびCoherence

- JMSファイル・ストア

タスク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. 次の表の情報を使用して、各Oracle SOA Suite管理対象サーバーの残りの列を入力します。

ヒント:

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

サーバー名

リスニング・アドレス

リスニング・ポート

SSLの有効化

SSLリスニング・ポート

サーバー・グループ

WLS_SOA1

WCCHOST1

8001

いいえ

無効

SOA-MGD-SVRS-ONLY、WSMPM-MAN-SVR、WSM-CACHE-SVR、JRF-MAN_SVR

WLS_SOA2

WCCHOST2

8001

いいえ

無効

SOA-MGD-SVRS-ONLY、WSMPM-MAN-SVR、WSM-CACHE-SVR、JRF-MAN_SVR

タスク10    クラスタの構成

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

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

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

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

注意:

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

ヒント:

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

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

「サーバーのクラスタへの割当」画面を使用して、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ドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

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

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期インフラストラクチャ・メインの作成中に定義されているため、9991のままにします。

注意:

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

タスク13 既存のマシンの検証

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

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

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

「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle SOA Suite管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。

WLS_SOA1をWCCHOST1、WLS_SOA2をWCCHOST2に割り当てます。

ヒント:

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

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

「JMSファイル・ストア」画面で、UMSおよびBPMのファイル・ストアを含む各SOA永続ストアに次のディレクトリを割り当てます。

ORACLE_RUNTIME/domain_name/SOA_cluster/jms

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

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

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

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

「更新」をクリックするまで、ドメインの作成は開始されません。

ヒント:

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

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

「構成に成功しました」画面に、構成したドメインに関する次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

どちらの項目も後で必要になるためメモしてください。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、管理サーバーのURLはWebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlへのアクセスで必要になります。

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

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

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

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

各管理対象サーバーでは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納するトランザクション・ログを使用します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、各管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。クラスタ内のすべての管理対象サーバーがこのディレクトリにアクセスできる必要があります。また、このディレクトリは、サーバーを再起動する前にも存在している必要があります。

お薦めする場所は、デュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)です。記憶域で障害が発生した場合に確実に保護できるように、記憶域レベルで適切なレプリケーションとバックアップのメカニズムを設定することが重要です。

この情報はファイルベースのトランザクション・ログに該当します。また、トランザクション・ログのためにデータベースベースの永続ストアを構成することもできます。詳細は、「エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用」を参照してください。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

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

ADMINVHN:7001/console

2. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

3. クラスタ内の管理対象サーバーごとに次の手順を実行します。

a. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。

b. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

c. 「構成」タブで、「サービス」タブをクリックします。

d. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
エンタープライズ・デプロイメントでは、ORACLE_RUNTIMEディレクトリの場所を使用します。このサブディレクトリは、クラスタのトランザクション・ログにとって中心的な共有場所の役割を果たします。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

次に例を示します。

ORACLE_RUNTIME/domain_name/cluster_name/tlogs

作成したクラスタの名前でcluster_nameを置き換えます。

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

4. 「保存」をクリックして、「変更のアクティブ化」をクリックします。

注意:

構成手順の後半で、トランザクション・ログの場所と作成について検証します。

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

Oracle WebCenter Contentインスタンスを含めることでドメインを拡張し、WCCHOST1上の管理サーバーを再起動したら、そのドメイン変更をドメイン・ディレクトリとマシンに伝播する必要があります。

表13-1 は、変更をすべてのドメイン・ディレクトリとマシンに伝播するために必要な手順をまとめたものです。

更新済ドメインをWEBHOST1およびWEBHOST2マシンに伝播する必要はありません。それらのホスト・コンピュータ上のOracle HTTP Serverインスタンスに対する変更はないためです。

表13-1 ドメイン変更をドメイン・ディレクトリおよびマシンに伝播するために必要なタスクのサマリー

タスク

説明

詳細情報

WCCHOST1での拡張済ドメインの圧縮

packコマンドを使用して、新しいOracle SOA Suite管理対象サーバー構成が含まれる新しいテンプレートJARファイルを作成します。

ドメインを圧縮する際には、soadomaintemplateExtSOA.jarというテンプレートJARファイルを作成します。

WCCHOST1での拡張済ドメインの圧縮

WCCHOST1の管理対象サーバー・ディレクトリでのドメインの解凍

WCCHOST1のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

WCCHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

WCCHOST2でのドメインの解凍

WCCHOST2のローカル記憶域上の管理対象サーバー・ディレクトリにテンプレートJARファイルを解凍します。

WCCHOST2でのドメインの解凍

- WCCHOST1での拡張済ドメインの圧縮

- WCCHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

- WCCHOST2でのドメインの解凍

13.7.1 WCCHOST1での拡張済ドメインの圧縮

次の手順を使用して、ドメイン構成情報が含まれるテンプレートJARファイルを作成します。

1. WCCHOST1にログインし、次のようにpackコマンドを実行してテンプレートJARファイルを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true
-domain=ASERVER_HOME
-template=full_path/wccdomaintemplate.jar
-template_name=wcc_domain_template

この例では、次のとおりです。

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

- full_pathを、テンプレートJARファイルを保存するディレクトリの完全なパスで置き換えます。

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

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

2. packコマンドで作成したばかりのテンプレートJARファイルの場所を書き留めます。

ヒント:

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

13.7.2 WCCHOST1の管理対象サーバー・ドメイン・ディレクトリでのドメインの解凍

更新したドメイン構成情報を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播する手順は次のとおりです。

1. WCCHOST1にログインしていない場合は、ログインします。

2. まだ作成していない場合は、WCCHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME  \
-template=full_path/soadomaintemplateExtSOA.jar \
-overwrite_domain=true \
-app_dir=APPLICATION_HOME

この例では、次のとおりです。

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

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

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

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

ヒント:

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

4. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがWCCHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

13.7.3 WCCHOST2でのドメインの解凍

この手順では、以前に作成したファイルを、WCCHOST1とWCCHOST2の両方からアクセスできる場所(たとえば、共有記憶域ファイラ上のASERVER_HOMEディレクトリなど)にコピー済であることを想定しています。

1. WCCHOST2にログインします。

2. まだ作成していない場合は、WCCHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。

「このガイドで使用するファイル・システムとディレクトリ変数」の例をガイドとして使用します。

3. WCCHOST2がwccdomaintemplate.jarにアクセスできるようにします。
たとえば、WCCHOST2のために別の共有記憶域ボリュームまたはパーティションを使用している場合は、WCCHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。

4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME
-overwrite_domain=true
-template=complete_path/wccdomaintemplate.jar
-log_priority=DEBUG
-log=/tmp/unpack.log
-app_dir=APPLICATION_HOME

この例では、次のとおりです。

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

- packコマンドを実行して共有記憶域デバイス上でドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名で、complete_path/wccdomaintemplate.jarを置き換えます。

- APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

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

5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがWCCHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

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

これでドメインの拡張、管理サーバーの再起動、およびドメインの他のホストへの伝播を完了したので、新しく構成したOracle SOA Suite管理対象サーバーを起動できます。

このプロセスには、次の各項で説明する3つのタスクが含まれます。

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

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

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

13.8.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管理対象サーバーが稼働中であることを確認します。

13.8.2 AdministratorsグループへのSOAAdminロールの追加

WLS_SOA1管理対象サーバーのOracle SOA Suite構成を検証する前に、SOAAdmin管理ロールをエンタープライズ・デプロイメント管理グループ(WCCAdministrators)に追加します。

このタスクを実行するには、「Oracle SOA Suite製品の管理のためのロールの構成」を参照してください。

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

SOAAdminロールをSOA Administratorsグループに追加した後、次のようにWLS_SOA1管理対象サーバーのOracle SOA Suiteソフトウェアの構成を検証できます。

1. Webブラウザを使用して次のURLに移動します。

http://WCCHOST1:8001/soa-infra/

2. エンタープライズ・デプロイメント管理者ユーザー資格証明(weblogic_soa)を使用してログインします。

次のようなタイトルのWebページが表示されます。

"Welcome to the Oracle SOA Platform on WebLogic"

13.9 SOAクラスタのフロントエンド・ホストおよびポートの設定

Oracle SOA SuiteサーバーをホスティングするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。これは、ドメインのプロパティを指定するときに、構成ウィザードで行うことができます。ただし、SOAクラスタをWebCenter Contentエンタープライズ・ドメインの一部として追加している場合は、SOA管理対象サーバーを確認した後でこのタスクを実行することをお薦めします。

Weblogic Server管理コンソールでフロントエンド・ホストおよびポートを設定する手順は次のとおりです。

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

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」パネルで、「環境」を開き、「クラスタ」をクリックします。

4. 「クラスタ」ページで「SOA_Cluster」をクリックし、「HTTP」タブを選択します。

5. 次の値を設定します。

- フロントエンド・ホスト: wccinternal.example.com

- フロントエンドHTTPポート: 80

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

7. 「変更のアクティブ化」をクリックします。

8. WLS_SOA1管理対象サーバーを再起動します。

(オプション)この手順の結果をここで入力します。

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

正常な構成とWLS_SOA1管理対象サーバーの起動を検証したら、WLS_SOA2管理対象サーバーを起動して検証できます。

WLS_SOA2管理対象サーバーを起動および検証するには、WLS_SOA2管理対象サーバーに対して「WLS_SOA1管理対象サーバーの起動と検証」の手順を使用します。

検証URLとしてWebブラウザに次のURLを入力し、エンタープライズ・デプロイメント管理者ユーザー資格証明(weblogic_soa)を使用してログインします。

http://WCCHOST2:8001/soa-infra/

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

WLS_SOA1およびWLS_SOA2が起動していて稼働中になった後、トランザクション・ログ・ディレクトリおよびトランザクション・ログが、想定のとおりに作成されたことを確認します。

確認するには、「トランザクション・リカバリ用のデフォルト永続ストアの構成」で実行した手順に基づいて、次のコマンドを実行します。

ORACLE_RUNTIME/SOA_Cluster/tlogs

- _WLS_WLS_SOA1000000.DAT

- _WLS_WLS_SOA2000000.DAT

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

次の項では、パブリックURLおよび内部URLの両方のリクエストを、エンタープライズ・トポロジ内の正しいWebcenter PortalクラスタにルーティングするようにOracle HTTP Serverインスタンスを構成する方法について説明します。

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

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

- ロード・バランサを介したOracle WebCenter Content URLの検証

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

次の手順を使用して、リクエストを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. wccinternal_vh.confファイルを編集し、次のディレクティブを追加します。

<VirtualHost WEBHOST1:7777>
ServerName http://wccinternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

3. <VirtualHost>タグ内に、次のディレクティブを追加します。

注意:

/workflowのURLエントリは省略可能です。これは、Oracle ADFタスク・フォームと関連付けられたワークフロー・タスク用です。/workflowのURL自体は、フォームに応じた別の値とすることができます。

# WSM-PM
<Location /wsm-pm>
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
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 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. wccinternal_vh.confファイルを2つ目のOracle HTTP Serverインスタンス(ohs2)の構成ディレクトリにコピーします。

OHS_DOMAIN_HOME/config/fmwconfig/components/ohs2/moduleconf/

5. wccinternal_vh.confファイルを編集して、<VirtualHost>ディレクティブ内のWEBHOST1への参照をWEBHOST2への参照に変更します。

6. 両方のOracle HTTP Serverを再起動します。

例13-1 wccinternal_vh.confファイルの内容の例

<VirtualHost WEBHOST1:7777>
ServerName http://wccinternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# WSM-PM
<Location /wsm-pm>
WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
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 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 SWCCHOST1: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>

注意:

システムで内部呼出しを使用する場合は、soainternal仮想ホストに適切なロケーションを追加してください。

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

リクエストがOracle HTTP Serverインスタンスを介して正しくルーティングされることを検証するには、構成したクラスタのWebLogic Plug-In Enabledパラメータを前もって設定する必要があります。

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

2. 「ドメイン構造」ペインで「環境」ノードを開きます。

3. 「クラスタ」をクリックします。

4. Oracle HTTP Serverからのリクエストをプロキシ設定する、クラスタを選択します。

「構成: 一般」タブが表示されます。

5. 「詳細」セクションまでスクロール・ダウンして、開きます。

6. 「チェンジ・センター」で「ロックして編集」をクリックします。

7. 「WebLogicプラグインの有効化」を「はい」に設定します。

8. 「保存」をクリックし、「変更のアクティブ化」をクリックします。

9. 「チェンジ・センター」の「変更のアクティブ化」をクリックします。

13.12.3 ロード・バランサを介したOracle WebCenter Content URLの検証

Oracle HTTP Server仮想ホストの構成を検証し、ハードウェア・ロード・バランサがOracle HTTP Serverインスタンスを経由してアプリケーション層にリクエストをルーティングできることを確認する手順は次のとおりです。

1. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

2. 次のURLにアクセスできることを確認します。

- http://wccinternal.example.com/soa-infra

- http://wccinternal.example.com/integration/worklistapp

- http://wccinternal.example.com/sdpmessaging/userprefs-ui

- http://wccinternal.example.com/soa/composer

- http://wccinternal.example.com/wsm-pm

13.13 Oracle SOA Suiteの構成後手順

Oracle SOA SuiteとOracle Business Process Managementをインストールして構成した後、次のような構成後タスクを検討します。

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

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

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

Oracle SOA Suiteを含めてドメインを拡張した後、管理サーバーと管理対象サーバーがハードウェア・ロード・バランサのフロントエンドのSSL URLにアクセスできることを確認する必要もあります。

これにより、SOAコンポジット・アプリケーションとWebサービスが、フロントエンドのセキュアURLとのコールバックやその他の通信を起動できるようになります。

詳細は、「中間層とハードウェア・ロード・バランサ間のSSL通信の有効化」を参照してください。

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

SOAクラスタでは、次のシナリオはサポートされていません。

- mid-process receiveを持つ同期BPELプロセス

- 非同期サービスをコールする同期BPELプロセス。

- 同期プロセスからのコールバック。

13.14 Oracle SOA Suiteでの自動サービス移行とJDBC永続ストアの有効化

Oracle SOA Suiteが高可用性を実現するように構成するには、自動サービス移行に対応するようにOracle SOA Suite管理対象サーバーを構成します。

自動サービス移行の有効化の詳細は、「エンタープライズ・デプロイメントでの自動サービス移行の構成」を参照してください。

可用性をさらに高めるために、トランザクション・ログ・ストアおよびJMSストアをデータベースに構成することもできます。詳細は、「エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用」を参照してください。

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

ここでは、エンタープライズ・デプロイメント・ドメインを拡張してInbound Refineryソフトウェアを含める方法を説明します。

- Inbound Refineryを追加するためのドメインの拡張の概要
Inbound Refineryは、Oracle WebCenter Content Serverがドキュメント変換を行う際に必要になります。この項では、Inbound Refineryの概要を説明します。

- Inbound Refineryを使用するためのドメインの拡張
この項では、Inbound Refineryソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張する手順について説明します。

- Inbound Refinery用の構成後タスクおよび検証タスクの実行
この項では、Inbound Refinery用の構成後タスクと検証タスクを実行する方法について説明します。

- Inbound Refinery管理対象サーバーの構成
Inbound Refinery管理対象サーバーの構成を初期化するには、その管理対象サーバーに一度だけHTTP経由でアクセスする必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound RefineryインスタンスはHTTPサーバーの後方に配置する必要があります。

- Inbound Refinery管理対象サーバーの構成の検証
作成したInbound Refinery管理対象サーバーが正しく構成されているかどうかを確認するには、コンテンツ・サーバーにログインし、変換に有効と認識された拡張子を持つファイルが正しく変換されることを確認して、構成を検証します。

上位トピック: 「エンタープライズ・ドメインの構成」

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

Inbound Refineryは、Oracle WebCenter Content Serverがドキュメント変換を行う際に必要になります。この項では、Inbound Refineryの概要を説明します。

実際のInbound Refinery管理対象サーバーの数は、要件によって異なります。可用性の理由から、少なくとも2つのInbound Refinery管理対象サーバーを別々のマシン上にインストールおよび構成することをお薦めします。参照用Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジにおいて、Inbound RefineryはContent Serverと同一のマシンに構成されます。

このエンタープライズ・デプロイメント・トポロジにInbound Refineryを追加してドメインを拡張するためのプロセスで複数の管理対象サーバーを作成しても、各Inbound Refineryインスタンスは完全に独立しています。Inbound Refineryはクラスタでは実行されません。

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

この項では、Inbound Refineryソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張する手順について説明します。

- 構成ウィザードの起動

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

14.2.1 構成ウィザードの起動

注意:

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

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

1. ドメインを拡張する前に、ドメインを完全に停止します。WebLogic Serverコンソールから、すべての管理対象サーバーを停止して検証し、続いて管理サーバーを停止します。

詳細は、「WCCHOST1での構成ウィザードの起動」で、ノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

2. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

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

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

トポロジのドメインを更新して構成するには、この項の手順に従います。

注意:

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

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

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

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

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

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

ヒント:

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

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

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

- Oracle Universal Content Management - Inbound Refineryサーバー - 12.2.1 [wccontent]
初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

- 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ドメインの作成の「テンプレート」に関する項を参照してください。

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

「GridLink Oracle RACコンポーネント・スキーマ」画面で「次へ」をクリックします。

タスク4    JDBC接続のテスト

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

タスク5    拡張構成の選択

トポロジのドメイン構成を完了するには、「拡張構成」画面で次のオプションを選択する必要があります。

- 管理対象サーバー、クラスタ、およびマシン

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

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

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

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

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

ヒント:

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

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

表14-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を指定します。

注意:

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

ヒント:

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

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

「サーバーのクラスタへの割当」画面を使用して、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ドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

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

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期インフラストラクチャ・メインの作成中に定義されているため、9991のままにします。

注意:

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

タスク10 既存のマシンの検証

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

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

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

「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle Inbound Refinery管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。

WLS_IBR1をWCCHOST1、WLS_IBR2をWCCHOST2に割り当てます。

ヒント:

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

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

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

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

「更新」をクリックするまで、ドメインの作成は開始されません。

ヒント:

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

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

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

- ドメインの場所

- 管理サーバーURL

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

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

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

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

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

この項では、Inbound Refinery用の構成後タスクと検証タスクを実行する方法について説明します。

- WLS_IBR1およびWLS_IBR2へのドメイン構成の伝播

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

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

14.3.1 WLS_IBR1およびWLS_IBR2へのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。Inbound Refinery管理対象サーバーにドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateIBR.jar -template_name=edgdomain_templateIBR

3. 次のunpackコマンドをWCCHOST1で実行して、前の手順で作成したテンプレートをWLS_IBR1ドメイン・ディレクトリに伝幡します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateIBR.jar -app_dir=APPLICATION_HOME -overwrite_domain=true

4. 次のコマンドをWCCHOST1で実行し、手順1で作成したテンプレート・パックをWCCHOST2にコピーします。

scp edgdomaintemplateIBR.jar oracle@WCCHOST2:ORACLE_COMMON_HOME/common/bin

5. unpackコマンドをWCCHOST2で実行して、伝播されたテンプレートをWLS_IBR1ドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateIBR.jar -app_dir=APPLICATION_HOME -overwrite_domain=true

6. ここまでの変更を有効にするために管理サーバーを再起動します。まずnmKillコマンドまたは管理コンソールで管理サーバーを停止し、次にnmStartコマンドで起動します。weblogicユーザーの資格証明を使用して管理コンソールにログインします。

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

次の手順に従って、管理対象サーバー・ホームからノード・マネージャを起動します。

1. WCCHOST1で、次のディレクトリに移動します。

MSERVER_HOME/bin

2. 次のコマンドを使用してノード・マネージャを起動します。

nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &

3. WCCHOST2の次のディレクトリに移動して、前の手順を繰り返します。

MSERVER_HOME/bin

追加ノード・マネージャの構成オプションの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

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

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

1. http://admin.example.com:7001/consoleでOracle WebLogic Server管理コンソールにログインします。

2. 次の手順に従い、管理コンソールを使用してWLS_IBR1管理対象サーバーを起動します。

a. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

b. 「サーバー」をクリックします。

c. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

d. 表の「サーバー」列からWLS_IBR1を選択します。

e. 「起動」をクリックします。

3. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

- サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。

- 「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。

4. 前述の手順を繰り返し、WCCHOST2でWLS_IBR2管理対象サーバーを起動します。

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

Inbound Refinery管理対象サーバーの構成を初期化するには、その管理対象サーバーに一度だけHTTP経由でアクセスする必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound RefineryインスタンスはHTTPサーバーの後方に配置する必要があります。

Inbound Refineryインスタンスへのすべての後続のアクセスは、ソケット・リスナーを介して行われます。このリスナーは、次の項で構成する着信ソケット接続アドレス・セキュリティ・フィルタによって保護されます。

すべてのInbound Refineryインスタンスを使用して各コンテンツ・サーバー・インスタンスを構成することをお薦めします。コンテンツ・サーバーの構成プロセスは、Inbound Refineryインスタンスをプロバイダとして追加することです。また、一部のインストール後の手順をInbound Refineryで実行する必要があります。

次の項では、各Inbound Refineryインスタンスのインストール後の構成手順について説明します。

- Inbound Refineryの設定の構成
Inbound Refinery管理対象サーバーを起動したら、インストール後の構成画面で各サーバーの設定を構成します。

- Inbound Refineryにジョブを送信して変換するためのコンテンツ・サーバーの設定
Oracle WebCenter Content ServerからInbound Refineryにジョブを送信して変換を実施できるようにするには、次の項の説明に従って、Inbound Refinery管理対象サーバーごとに設定タスクを事前に実行する必要があります。

14.4.1 Inbound Refineryの設定の構成

Inbound Refinery管理対象サーバーを起動したら、インストール後の構成画面で各サーバーの設定を構成します。

各Inbound Refineryインスタンスの設定を構成する手順は次のとおりです。

1. 次のURLからInbound Refineryのインストール後の構成画面にアクセスします。Nには1または2を指定します。

http://WCCHOSTN:16250/ibr/

2. 「構成」画面で、「Inbound Refineryのインスタンス識別子: name」を確認します。このインスタンスの構成設定を次のように設定します。各Inbound Refineryインスタンスは、他のインスタンスとは独立し、各マシンに対してローカルです。各インスタンスの構成ディレクトリとしてローカル・ディレクトリを使用します。

- Inbound Refineryのインスタンス・フォルダ: /u01/oracle/config/domains/wccedg_domain/IBR_Servers/ibrN/
http://WCCHOST1:16250/ibr/ではNが1、http://WCCHOST2:16250/ibr/ではNが2

ディレクトリ・パスは各ローカル・マシンに存在する必要があり、構成を保存する前にディレクトリが作成されている必要があります。

- ネイティブ・ファイル・リポジトリの場所: /u01/oracle/config/domains/wccedg_domain/IBR_Servers/ibrN/vault
http://WCCHOST1:16250/ibr/ではNが1、http://WCCHOST2:16250/ibr/ではNが2

- Webレイアウト・フォルダ: /u01/oracle/config/domains/wccedg_domain/IBR_Servers/ibrN/weblayout
http://WCCHOST1:16250/ibr/ではNが1、http://WCCHOST2:16250/ibr/ではNが2

- ユーザー・プロファイル・フォルダ: /u01/oracle/config/domains/wccedg_domain/IBR_Servers/ibrN/data/users/profiles/
http://WCCHOST1:16250/ibr/ではNが1、http://WCCHOST2:16250/ibr/ではNが2

- 受信ソケット接続アドレス・セキュリティ・フィルタ: 次に示すような、ローカル・ホストとサーバーIPアドレスのパイプ区切り一覧です。
127.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/config/domains/wccedg_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の構成時に必要となるため、書き留めておいてください。

このフィールドの値を変更すると、 /u02/oracle/config/domains/wccedg_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の構成時に必要となるため、書き留めておいてください。

構成ページの他のすべてのフィールドはそのままにします。

「送信」をクリックすると、次のメッセージが表示されます。

インストール後の構成が完了しました。このノードを再起動してください。

3. WebLogic Server管理コンソールを使用して、Inbound Refinery管理対象サーバーを再起動します。

4. 各Inbound Refineryインスタンスに対して個別のコンテンツ・フォルダ名を使用して、前述の手順を実行します。

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

Oracle WebCenter Content ServerからInbound Refineryにジョブを送信して変換を実施できるようにするには、次の項の説明に従って、Inbound Refinery管理対象サーバーごとに設定タスクを事前に実行する必要があります。

- 送信プロバイダの作成
コンテンツ・サーバーからInbound Refineryにファイルを送信して変換を実施するには、「Inbound Refinery変換ジョブの処理」オプションを事前に選択して、コンテンツ・サーバーから各Inbound Refineryへの送信プロバイダを設定する必要があります。

- コンテンツ・サーバーでのInbound Refinery用のコンポーネントの有効化
変換タイプによっては、コンテンツ・サーバーでヘルパー・コンポーネントを有効にする必要があります。ドキュメント変換にInbound Refineryを使用するコンテンツ・サーバーのインスタンスでは、InboundRefinerySupportコンポーネントを常に有効にする必要があります。新しいコンテンツ・サーバーのインストールではデフォルトで有効になっています。

- 変換するファイル形式の選択
変換のためにInbound Refineryに送信するファイルをコンテンツ・サーバーに指定するには、ファイル形式を選択する必要があります。

14.4.2.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できることを確認します。

プロバイダの設定の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のContent ServerとRefineryの通信の構成に関する項を参照してください。

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

変換タイプによっては、コンテンツ・サーバーでヘルパー・コンポーネントを有効にする必要があります。ドキュメント変換にInbound Refineryを使用するコンテンツ・サーバーのインスタンスでは、InboundRefinerySupportコンポーネントを常に有効にする必要があります。新しいコンテンツ・サーバーのインストールではデフォルトで有効になっています。

コンテンツ・サーバーでInbound Refineryコンポーネントを有効にする手順は次のとおりです。

1. 次のURLからコンテンツ・サーバーにログインします。

https://wcc.example.com/cs/

2. 「管理」トレイまたはメニューから、「管理サーバー」→「コンポーネント・マネージャ」を選択します。

3. 「コンポーネント・マネージャ」ページで、「Inbound Refinery」を選択し、「Inbound Refinery」で有効にするコンポーネント(XMLConverterSupportなど)を選択したら、「更新」をクリックします。

4. 両方のコンテンツ・サーバーを再起動するために、WebLogic Server管理コンソールを使用してWebCenter Content管理対象サーバーを再起動します。

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

変換のためにInbound Refineryに送信するファイルをコンテンツ・サーバーに指定するには、ファイル形式を選択する必要があります。

変換するファイル形式を選択するには、次の手順を実行します。

1. 次のURLからコンテンツ・サーバーにログインします。

https://wcc.example.com/cs/

2. 「管理」トレイまたはメニューを開いて「リファイナリ管理」、「ファイル形式ウィザード」の順に選択し、「ファイル形式ウィザード」ページを開きます。

このページでは、どのファイル形式をコンテンツ・サーバーにチェックインした場合に、そのファイル形式をInbound Refineryに送信して変換を実施するかを指定します。

3. Microsoft Wordドキュメントのdoc、dot、docxおよびdotxなど、変換が必要なフォーマットを選択します。

4. 「更新」をクリックします。

また、構成マネージャでファイル形式を選択することもできます。構成マネージャでは、ウィザードでは示されないファイル形式など、さらにきめ細かく制御できます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のファイル・タイプの管理に関する項を参照してください。

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

作成したInbound Refinery管理対象サーバーが正しく構成されているかどうかを確認するには、コンテンツ・サーバーにログインし、変換に有効と認識された拡張子を持つファイルが正しく変換されることを確認して、構成を検証します。

たとえば、変換するフォーマットとしてdocxを選択した場合は、拡張子が.docxのMicrosoft Word文書をPDFフォーマットに変換できます。

チェックインとチェックアウトの手順の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの使用』のドキュメントのアップロードおよびファイルのチェックアウトとダウンロードに関する項を参照してください。

変換プロセスの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のRefineryにジョブを送信するためのコンテンツ・サーバーの構成に関する項を参照してください。

15 Captureを追加するためのドメインの拡張

この章では、Oracle WebCenter Enterprise Captureソフトウェアを含めることでエンタープライズ・デプロイメント・ドメインを拡張する方法について説明します。

- Captureを追加するためのドメインの拡張の概要
Oracle WebCenter Enterprise Captureでは、ペーパー・ドキュメントと電子ドキュメントの両方を取り込むことができる1つのシステムを組織に提供します。この項では、Oracle WebCenter Enterprise Captureについて簡単に説明します。

- Captureを使用するためのドメインの拡張
この項では、Captureソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張する手順について説明します。

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

- Captureクラスタ用のOracle HTTP Serverの構成
WLS_CPT1およびWLS_CPT2管理対象サーバーを含むCPT_ClusterにOracle HTTP Serverをルーティングするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

上位トピック: 「エンタープライズ・ドメインの構成」

15.1 Captureを追加するためのドメインの拡張の概要

Oracle WebCenter Enterprise Captureでは、ペーパー・ドキュメントと電子ドキュメントの両方を取り込むことができる1つのシステムを組織に提供します。この項では、Oracle WebCenter Enterprise Captureについて簡単に説明します。

Captureでは、大規模で本番レベルのスキャナを使用できるユーザーフレンドリなWebインタフェースにより、集中管理されたイメージと分散したイメージの両方の取込みをサポートしています。業界標準のTWAINスキャン・インタフェースがサポートされているため、業界をリードする様々なドキュメント・イメージ・スキャナを使用して、ペーパー・ドキュメントのデジタル化が可能になります。既存の電子ドキュメントは、ユーザーが容易に取り込むことができます。また、電子メール・サーバーまたはネットワーク・フォルダをモニターできるインポート・プロセスを介して自動的に取り込むこともできます。ドキュメントは取込み後、バー・コード認識技術による自動化プロセスまたは手動で、メタデータを適用することにより編成され索引付けされます。処理終了後、ドキュメントはコンテンツ管理システムにコミットされます。Captureは、完全にOracle WebCenter Contentと統合されており、非常に重要なビジネス・コンテンツの取込み、保存、管理および取得を可能にする1つのシステムを組織に提供します。

15.2 Captureを使用するためのドメインの拡張

この項では、Captureソフトウェアを含めることで既存のエンタープライズ・デプロイメント・ドメインを拡張する手順について説明します。

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

- 構成ウィザードの起動

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

15.2.1 構成ウィザードの起動

注意:

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

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

1. ドメインを拡張する前に、ドメインを完全に停止します。WebLogic Serverコンソールから、すべての管理対象サーバーを停止して検証し、続いて管理サーバーを停止します。

詳細は、「WCCHOST1での構成ウィザードの起動」で、ノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

2. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

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

15.2.2 ドメインを拡張するために構成ウィザード画面へ移動

この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。

注意:

この項で説明する手順を使用して、既存のドメインを拡張することもできます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

タスク1    ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメントの初期管理サーバー・ドメインの作成」や、WebCenter Content、SOAおよびInbound Refineryでドメインを拡張する際に作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2    構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

- Oracle WebCenter Enterprise Capture - 12.2.1 [wccapture]
また、初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。これらのテンプレートはCaptureの実行には必要ありません。これらはエンタープライズ・デプロイメント構成の一部としてすでに選択されています。

- Oracle Universal Content Management - コンテンツ・サーバー - 12.2.1 [wccontent]

- Oracle SOA Suite - 12.2.1 [soa]

- Oracle Universal Content Management - Inbound Refinery - 12.2.1 [wccontent]

- 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ドメインの作成の「テンプレート」に関する項を参照してください。

タスク3    JDBCコンポーネント・スキーマ情報の指定

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク4    GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で次のタスクを実行します。

1. 「SCAN」チェック・ボックスを選択します。

2. 「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

3. 「SCANポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)。

4. 「ONSホスト」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

5. 「ONSポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

「次へ」をクリックします。

タスク5    JDBC接続のテスト

「次へ」をクリックして続行します。

タスク6    拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

- 管理対象サーバー、クラスタ、およびマシン

- JMSファイル・ストア

タスク7    管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストに新しい管理対象サーバーが表示されます。

次のタスクを実行して、デフォルトの管理対象サーバーを変更して2つ目の管理対象サーバーを作成します。

1. デフォルトの管理対象サーバーの名前をWLS_CPT1に変更します。

2. 「追加」をクリックして新しい管理対象サーバーを作成し、そのサーバーにWLS_CPT2と名前を付けます。

ヒント:

ここで推奨するサーバー名は、このドキュメント全体で使用します。別の名前を選択する場合は、必要に応じてそれらの名前に置き換えてください。

3. 次の表の情報を使用して、各Capture管理対象サーバーの残りの列を入力します。

ヒント:

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

表15-1 各Captureサーバーで必要な値

サーバー名

リスニング・アドレス

リスニング・ポート

SSLの有効化

SSLリスニング・ポート

サーバー・グループ

WLS_CPT1

WCCHOST1

16400

いいえ

無効

JRF-MAN-SVR CAPTURE-MGD-SVR WSM-PM-SVR

WLS_CPT2

WCCHOST2

16400

いいえ

無効

JRF-MAN-SVR CAPTURE-MGD-SVR WSM-PM-SVR

タスク8    クラスタの構成

このタスクでは、Captureソフトウェアのターゲットにすることができる管理対象サーバーのクラスタを作成します。

クラスタの「フロントエンド・ホスト」プロパティも設定します。これにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上のwcc.example.comにリダイレクトするようになります。

wcc.example.com仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

「クラスタ」画面を使用して、新しいクラスタを作成します。

1. 「追加」ボタンをクリックします。

2. 「クラスタ名」フィールドでCPT_Clusterを指定します。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストまたはマルチキャストを選択する際の考慮事項に関する項を参照してください。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「クラスタ」に関する項を参照してください。

タスク9    クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、WLS_CPT1およびWLS_CPT2を新規クラスタCPT_Clusterに割り当てます。

1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではCPT_Cluster)を選択します。

2. 「サーバー」ペインで、次のいずれかの操作を実行して、WLS_CPT1をCPT_Clusterに割り当てます。

- WLS_CPT1管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。

- WLS_CPT1をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。

3. 同じ手順を繰り返して、WLS_CPT2をCPT_Clusterに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

タスク10    Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期インフラストラクチャ・ドメインの作成中に定義されているため、0のままにします。Oracle Enterprise CaptureはCoherenceクラスタを使用しません。この手順はドメイン拡張プロセスの一部です。

注意:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報』のOracle Coherenceに関する項を参照してください。

タスク11 既存のマシンの検証

「Unixマシン」タブで、初期インフラストラクチャ・ドメインの作成時に作成したマシンの名前を確認します。

「次へ」をクリックします。

タスク12    マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、作成したばかりのCapture管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。

WLS_CPT1をWCCHOST1、WLS_CPT2をWCCHOST2に割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

タスク13 JMSファイル・ストアの構成

「JMSファイル・ストア」画面で、UMSおよびBPMのファイル・ストアを含む各WCC永続ストアに次のディレクトリを割り当てます。

ORACLE_RUNTIME/CPT_Cluster/jms

この例では、ASERVER_HOMEを、ご使用の環境の変数値に置き換えます。CPT_Clusterを、クラスタに割り当てた名前に置き換えます。

タスク14    構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックするまで、ドメインの作成は開始されません。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク15    ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、ノード・マネージャと管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク16    管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

15.3 WLS_CPT1およびWLS_CPT2へのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

Capture管理対象サーバーへのドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateCPT.jar -template_name=edgdomain_templateCPT

3. 次のunpackコマンドをWCCHOST1で実行して、前の手順で作成したテンプレートをWLS_CPT1ドメイン・ディレクトリに伝幡します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateCPT.jar -app_dir=APPLICATION_HOME -overwrite_domain=true

4. 次のコマンドをWCCHOST1で実行し、手順1で作成したテンプレート・パックをWCCHOST2にコピーします。

scp edgdomaintemplateCPT.jar oracle@WCCHOST2:ORACLE_COMMON_HOME/common/bin

5. unpackコマンドをWCCHOST2で実行して、伝播されたテンプレートをWLS_CPT2ドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateCPT.jar -app_dir=APPLICATION_HOME -overwrite_domain=true

6. ここまでの変更を有効にするために管理サーバーを再起動します。まずnmKillコマンドまたは管理コンソールで管理サーバーを停止し、次にnmStartコマンドで起動します。再起動の前に、管理コンソールを使用してドメイン内のすべての管理対象サーバーを停止します。続いて再起動後に、それらの管理対象サーバーを起動します。weblogicユーザーの資格証明を使用して管理コンソールにログインします。

15.4 Captureクラスタ用のOracle HTTP Serverの構成

WLS_CPT1およびWLS_CPT2管理対象サーバーを含むCPT_ClusterにOracle HTTP Serverをルーティングするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

この項には次のトピックが含まれます

- WLS_CPT管理対象サーバー用のOracle HTTP Serverの構成

- CaptureクラスタでのフロントエンドHTTPホストおよびポートの設定

- ロード・バランサを介したアクセスの検証

15.4.1 WLS_CPT管理対象サーバー用のOracle HTTP Serverの構成

WLS_CPT管理対象サーバー用にOracle HTTP Serverを構成する手順は次のとおりです。

1. WEBHOST1およびWEBHOST2上の各Webサーバーで、ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/wcc_vh.confおよびORACLE_INSTANCE/config/OHS/ohs2/moduleconf/wcc_vh.confファイルに次の行を追加します。

#DC-Console
<Location /dc-console>
WebLogicCluster WCCHOST1:16400,WCCHOST2:16400
WLSRequest ON
WLCookieName JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#DC-Client
<Location /dc-client>
WebLogicCluster WCCHOST1:16400,WCCHOST2VHN316400
WLSRequest ON
WLCookieName JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

2. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

./stopComponent.sh ohsn
./startComponent.sh ohsn

WEBHOST1ではohs1 (n=1)を使用し、WEBHOST2ではohs2 (n=2)を使用します。

15.4.2 CaptureクラスタでのフロントエンドHTTPホストおよびポートの設定

CaptureクラスタのフロントエンドHTTPホストとポートを設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」セクションに移動して、「ロックして編集」をクリックします。

3. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

4. 「クラスタ」をクリックします。

5. 「クラスタのサマリー」ページで、「CPT_Cluster」を選択します。

6. 「HTTP」タブを開きます。

7. 次の値を設定します。

- フロントエンド・ホスト: wcc.example.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80

8. 「保存」をクリックします。

9. 管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

10. サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効にします。

15.4.3 ロード・バランサを介したアクセスの検証

URLを検証し、HTTP ServerからCPT_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。URLを検証する手順は次のとおりです。

1. WLS_CPT2が稼動している状態で、WebLogic Server管理コンソールからWLS_CPT1を停止します。

2. https://wcc.example.com/dc-consoleにアクセスし、正しく動作していることを確認します。(Captureサーバーが停止しているため、レポートやデータは取得できません。)

3. WebLogic Server管理コンソールからWLS_CPT1を起動します。

4. WebLogic Server管理コンソールでWLS_CPT2を停止します。

5. https://wcc.example.com/dc-consoleにアクセスし、正しく動作していることを確認します。

6. WebLogic Server管理コンソールからWLS_CPT2を起動します。

16 WebCenter Contentユーザー・インタフェースを追加するためのドメインの拡張

この章では、Oracle WebCenter Contentユーザー・インタフェース・ソフトウェアを含めてエンタープライズ・デプロイメント・ドメインを拡張する方法を説明します。

この章では、MBeanを使用したシステム・レベルの設定変更や、WebCenter Contentユーザー・インタフェース・クラスタを含めるhttpサーバーの構成について説明します。

- WebCenter Contentユーザー・インタフェースのためのドメインの拡張
この項では、Oracle WebCenter Contentユーザー・インタフェース・ソフトウェアを追加するために既存のエンタープライズ・デプロイメント・ドメインを拡張する手順を説明します。

- WLS_WCCUI1およびWLS_WCCUI2へのドメイン構成の伝播
起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

- MBeanを使用したシステム・レベルの設定の変更
高可用性を保証するために、Fusion Middleware Controlの「システム構成」ページを使用して、WebCenter Contentユーザー・インタフェースのシステム・レベルの構成設定を変更できます。このページの設定によってWebCenter Contentユーザー・インタフェースのMBeanがドメイン用に構成されます。

- WebCenter Contentユーザー・インタフェース・クラスタと使用するOracle HTTP Serverの構成
WebCenter Contentユーザー・インタフェース・クラスタを使用してOracle HTTP Serverを構成し、クラスタのフロントエンドHTTPホストおよびポートを設定し、ロード・バランサを介してアクセスを検証します。

- ワークフロー構成の完了
WebCenter Contentユーザー・インタフェースのワークフロー構成を完了するには、管理対象サーバーを再起動し、構成を確認する必要があります。UseDatabaseWfInQueue構成変数により、WebCenter Contentユーザー・インタフェースは、ユーザーに割り当てられたワークフローにフィルタを適用できるようになります。EmailNotificationType構成変数では、ワークフローとサブスクリプションが異なるコンテンツ・サーバー・ユーザー・インタフェースに含まれる場合に、通知電子メール内のリンクがポイントする先を指定します。この構成変数のデフォルト値は、NativeWebUIです。

上位トピック: 「エンタープライズ・ドメインの構成」

16.1 WebCenter Contentユーザー・インタフェースのためのドメインの拡張

この項では、Oracle WebCenter Contentユーザー・インタフェース・ソフトウェアを追加するために既存のエンタープライズ・デプロイメント・ドメインを拡張する手順を説明します。

ドメインの拡張には、次のタスクが含まれます。

- 構成ウィザードの起動

- ドメインを拡張するために構成ウィザード画面へ移動

16.1.1 構成ウィザードの起動

注意:

ドメインで起動スクリプトに直接カスタマイズを追加した場合、それらのカスタマイズは構成ウィザードによって上書きされます。ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverrides.shという名前のファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のJavaコマンド行オプションの指定、追加の環境変数の指定などを行うように構成できます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

構成ウィザードを起動する手順は次のとおりです。

1. ドメインを拡張する前に、ドメインを完全に停止します。WebLogic Serverコンソールから、すべての管理対象サーバーを停止して検証し、続いて管理サーバーを停止します。

詳細は、「WCCHOST1での構成ウィザードの起動」で、ノード・マネージャを使用して管理サーバーを停止する手順を参照してください。

2. 次のディレクトリに移動し、WebLogic Server構成ウィザードを起動します。

cd ORACLE_HOME/oracle_common/common/bin
./config.sh

16.1.2 ドメインを拡張するために構成ウィザード画面へ移動

この項で説明する手順を実行して、目的のトポロジのドメインを作成して構成します。

注意:

この項で説明する手順を使用して、既存のドメインを拡張することもできます。この手順の説明では要件が満たされない場合は、その要件に応じた選択を行うか、サポート・ドキュメントで追加の詳細を参照してください。

ドメインを作成して構成するためのタスクは次のとおりです。

タスク1    ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「既存ドメインの更新」を選択します。

「ドメインの場所」フィールドで、ASERVER_HOME変数の値を選択します。これは、「エンタープライズ・デプロイメントの初期管理サーバー・ドメインの作成」で作成した管理サーバー・ドメイン・ホームの完全なパスを表します。

ディレクトリの場所の変数の詳細は、「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

ヒント:

この画面に示されるその他のオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「構成タイプ」に関する項を参照してください。

タスク2    構成テンプレートの選択

「テンプレート」画面で「製品テンプレートを使用してドメインを更新」が選択されていることを確認した後に、次のテンプレートを選択します。

- Oracle WebCenter Content - Web UI - 12.2.1 [wccontent]
また、初期ドメインを作成するために使用したため、次の追加のテンプレートもすでに選択されているはずです。

- Oracle Universal Content Management - コンテンツ・サーバー - 12.2.1 [wccontent]

- Oracle SOA Suite - 12.2.1 [soa]

- Oracle Universal Content Management - Inbound Refinery - 12.2.1 [wccontent]

- Oracle WebCenter Enterprise Capture - 12.2.1 [wccapture]

- 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ドメインの作成の「テンプレート」に関する項を参照してください。

タスク3    JDBCデータ・ソース情報の指定

「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク4    GridLink Oracle RACデータ・ソース詳細の指定

「GridLink Oracle RACデータ・ソース」画面で次のタスクを実行します。

「SCAN」、「ホスト名」および「ポート」のセクションで次の手順を実行します。

1. 「SCAN」チェック・ボックスを選択します。

2. 「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

3. 「ポート」フィールドには、データベースのSCANリスニング・ポートを入力します(1521など)。

「ONSホストとポート」セクション:

1. 「ONSポート」フィールドには、Oracle RACデータベースのSCANアドレスを入力します。

2. 「ポート」フィールドには、ONSリモート・ポートを入力します(通常は6200)。

「次へ」をクリックします。

タスク5    JDBC接続のテスト

「次へ」をクリックして続行します。

タスク6    wccadfConnectUserの資格証明の指定

「資格証明」画面で、WebLogicのユーザー名(weblogic_wcc以外)とパスワードを入力します。

「次へ」をクリックして続行します。

タスク7    拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

- 管理対象サーバー、クラスタ、およびマシン

タスク8    管理対象サーバーの構成

「管理対象サーバー」画面で、サーバーのリストに新しい管理対象サーバーが表示されます。

次のタスクを実行して、デフォルトの管理対象サーバーを変更して2つ目の管理対象サーバーを作成します。

1. デフォルトの管理対象サーバーの名前をWLS_WCCUI1に変更します。

2. 「追加」をクリックして新しい管理対象サーバーを作成し、そのサーバーにWLS_WCCUI2と名前を付けます。

ヒント:

ここで推奨するサーバー名は、このドキュメント全体で使用します。別の名前を選択する場合は、必要に応じてそれらの名前に置き換えてください。

3. 次の表を使用して、各Oracle WebCenter Contentユーザー・インタフェース管理対象サーバーの残りの列を入力します。

ヒント:

「管理対象サーバー」画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

サーバー名

リスニング・アドレス

リスニング・ポート

SSLの有効化

SSLリスニング・ポート

サーバー・グループ

WLS_WCCUI1

WCCHOST1

16225

いいえ

無効

UCM-ADF-MGD-SVR

WLS_WCCUI2

WCCHOST2

16225

いいえ

無効

UCM-ADF-MGD-SVR

タスク9    クラスタの構成

このタスクでは、Oracle WebCenter Contentソフトウェアのターゲットにすることができる管理対象サーバーのクラスタを作成します。

クラスタの「フロントエンド・ホスト」プロパティも設定します。これにより、WebLogic Serverは必要に応じてWebサービス・コールバックやその他のリダイレクトを、各リクエストのHOSTヘッダーにあるアドレスではなく、ロード・バランサ上のwcc.example.comにリダイレクトするようになります。

wcc.example.com仮想サーバー・アドレスの詳細は、「ハードウェア・ロード・バランサでの仮想ホストの構成」を参照してください。

「クラスタ」画面を使用して、新しいクラスタを作成します。

1. 「追加」ボタンをクリックします。

2. 「クラスタ名」フィールドでWCCUI_Clusterを指定します。

注意:

デフォルトでは、クラスタ内のサーバー・インスタンスは、ユニキャストを使用して相互に通信します。マルチキャストを使用するようにクラスタの通信を変更する場合は、『Oracle WebLogic Serverクラスタの管理』のユニキャストまたはマルチキャストを選択する際の考慮事項に関する項を参照してください。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「クラスタ」に関する項を参照してください。

タスク10    クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、WLS_WCCUI1およびWLS_WCCUI2を新規クラスタWCCUI_Clusterに割り当てます。

1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではWCCUI_Cluster)を選択します。

2. 「サーバー」ペインで、次のいずれかの操作を実行して、WLS_WCCUI1をWCCUI_Clusterに割り当てます。

- WLS_WCCUI1管理対象サーバーを1回クリックして選択し、右矢印をクリックして「クラスタ」ペインで選択されているクラスタの下に移動します。

- WLS_WCCUI1をダブルクリックして、クラスタ・ペインで選択されているクラスタの下に移動します。

3. 同じ手順を繰り返して、WLS_WCCUI2をWCCUI_Clusterに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのクラスタへの割当」に関する項を参照してください。

タスク11    Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。ポート番号値は、初期インフラストラクチャ・ドメインの作成中に定義されているため、0のままにします。

注意:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報』のOracle Coherenceに関する項を参照してください。

タスク12 既存のマシンの検証

「Unixマシン」タブで、初期インフラストラクチャ・ドメインの作成時に作成したマシンの名前を確認します。

「次へ」をクリックします。

タスク13    マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、作成したばかりのOracle WebCenter Contentユーザー・インタフェース管理対象サーバーを、ドメイン内の対応するマシンに割り当てます。

WLS_WCCUI1をWCCHOST1、WLS_WCCUI2をWCCHOST2に割り当てます。

ヒント:

この画面に示されるオプションの詳細は、構成ウィザードを使用したWebLogicドメインの作成の「サーバーのマシンへの割当」に関する項を参照してください。

タスク14    構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで任意の画面に戻れます。

「更新」をクリックするまで、ドメインの作成は開始されません。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク15    ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

- ドメインの場所

- 管理サーバーURL

どちらの項目も後で必要になるため、メモしておく必要があります。ドメインの場所は、ノード・マネージャと管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。また、URLは管理サーバーへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

タスク16    管理サーバーの起動

管理サーバーを起動して、ドメインに行った変更が適用されたことを確認します。

16.2 WLS_WCCUI1およびWLS_WCCUI2へのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

WebCenter Contentユーザー・インタフェース管理対象サーバーにドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのapplicationsディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateWCCUI.jar -template_name=edgdomain_templateWCCUI

3. 次のunpackコマンドをWCCHOST1で実行して、前の手順で作成したテンプレートをWLS_WCCUI1ドメイン・ディレクトリに伝幡します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateWCCUI.jar -app_dir=APPLICATION_HOME -overwrite_domain=true

4. 次のコマンドをWCCHOST1で実行し、手順1で作成したテンプレート・パックをWCCHOST2にコピーします。

scp edgdomaintemplateWCCUI.jar oracle@WCCHOST2:ORACLE_COMMON_HOME/common/bin

5. unpackコマンドをWCCHOST2で実行して、伝播されたテンプレートをWLS_WCCUI2ドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateWCCUI.jar -app_dir=APPLICATION_HOME -overwrite_domain=true

6. ここまでの変更を有効にするために管理サーバーを再起動します。まずnmKillコマンドまたは管理コンソールで管理サーバーを停止し、次にnmStartコマンドで起動します。再起動の前に、管理コンソールを使用してドメイン内のすべての管理対象サーバーを停止します。続いて再起動後に、それらの管理対象サーバーを起動します。weblogicユーザーの資格証明を使用して管理コンソールにログインします。

16.3 MBeanを使用したシステム・レベルの設定の変更

高可用性を保証するために、Fusion Middleware Controlの「システム構成」ページを使用して、WebCenter Contentユーザー・インタフェースのシステム・レベルの構成設定を変更できます。このページの設定によってWebCenter Contentユーザー・インタフェースのMBeanがドメイン用に構成されます。

システム・レベルの設定をFusion Middleware Controlで変更する方法の詳細は、Oracle Fusion Middleware Oracle WebCenter Captureの管理のシステム構成設定の変更に関する項を参照してください。

1. 次のパラメータを変更します。

- AdfScopeHaSupport = true

- ClusterCompatible = true

- TemporayDirectory=/u01/oracle/config/domains/WCCDomain/WCCUI_Cluster/tempdir

- PropConnectionUrl=idc://wccinternal.example.com:6300

2. 「適用」をクリックします。

3. 「ADF構成」をクリックします。

4. この「構成」画面で「操作」タブをクリックします。

5. 保存と呼出しをクリックして構成を保存します。

16.4 WebCenter Contentユーザー・インタフェース・クラスタと使用するOracle HTTP Serverの構成

WebCenter Contentユーザー・インタフェース・クラスタを使用してOracle HTTP Serverを構成し、クラスタのフロントエンドHTTPホストおよびポートを設定し、ロード・バランサを介してアクセスを検証します。

このセクションでは、次のタスクについて説明します。

- WLS_WCCUI管理対象サーバー用のOracle HTTP Serverの構成

- WebCenter Contentユーザー・インタフェース・クラスタのフロントエンドHTTPホストおよびポートの設定

- ロード・バランサを介したアクセスの検証

16.4.1 WLS_WCCUI管理対象サーバー用のOracle HTTP Serverの構成

WLS_WCCUI管理対象サーバー用にOracle HTTP Serverを構成する手順は次のとおりです。

1. WEBHOST1およびWEBHOST2上の各Webサーバーで、ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/wcc_vh.confおよびORACLE_INSTANCE/config/OHS/ohs2/moduleconf/wcc_vh.confファイルに次の行を追加します。

# ADF UI
<Location /wcc>
WebLogicCluster WCCHOST1:16225,WCCHOST2:16225
WLSRequest ON
WLCookieName WCC-ADF-JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

2. 両方のOracle HTTP Serverを再起動します

16.4.2 WebCenter Contentユーザー・インタフェース・クラスタのフロントエンドHTTPホストおよびポートの設定

CaptureクラスタのフロントエンドHTTPホストとポートを設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」セクションに移動して、「ロックして編集」をクリックします。

3. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

4. 「クラスタ」をクリックします。

5. 「クラスタのサマリー」ページで、「WCCUI_Cluster」を選択します。

6. 「HTTP」タブを開きます。

7. 次の値を設定します。

- フロントエンド・ホスト: wcc.example.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80

8. 「保存」をクリックします。

9. 管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

10. サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効にします。

16.4.3 ロード・バランサを介したアクセスの検証

URLを検証して、HTTPサーバーからWCCUI_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。URLを検証する手順は次のとおりです。

1. WLS_WCCUI2が稼動している状態で、WebLogic Server管理コンソールからWLS_WCCUI1を停止します。

2. http://wcc.example.com/wccにアクセスし、正しく動作していることを確認します。(Captureサーバーが停止しているため、レポートやデータは取得できません。)

3. WebLogic Server管理コンソールからWLS_WCCUI1を起動します。

4. WebLogic Server管理コンソールでWLS_WCCUI2を停止します。

5. http://wcc.example.com/wccにアクセスし、正しく動作していることを確認します。

クラスタ・ノードを検証できます。このクラスタ・ノードは、ロード・バランサを介してトラフィック・バランシングが行われ、再びWeb層を介してトラフィック・バランシングが行われた後で転送されるクラスタ・ノードです。

16.5 ワークフロー構成の完了

WebCenter Contentユーザー・インタフェースのワークフロー構成を完了するには、管理対象サーバーを再起動し、構成を確認する必要があります。UseDatabaseWfInQueue構成変数により、WebCenter Contentユーザー・インタフェースは、ユーザーに割り当てられたワークフローにフィルタを適用できるようになります。EmailNotificationType構成変数では、ワークフローとサブスクリプションが異なるコンテンツ・サーバー・ユーザー・インタフェースに含まれる場合に、通知電子メール内のリンクがポイントする先を指定します。この構成変数のデフォルト値は、NativeWebUIです。

ワークフロー構成を完了するには:

1. WCCHOST1/ucm/cs/config/config.cfgファイルに、次のどちらかに設定されたEmailNotificationType変数が含まれていることを確認します。

- WebCenter Contentユーザー・インタフェースのみをポイントするリンクを含む電子メールを生成する場合は、config.cfg内でEmailNotificationType=ContentUIを設定します。

- WebCenter Contentユーザー・インタフェースとネイティブの11gユーザー・インタフェースの両方をポイントするリンクを含む電子メールを生成する場合は、config.cfg内でEmailNotificationType=ContentUI,NativeWebUIを設定します。

2. WebLogic Serverの管理コンソールを使用して、コンテンツ・サーバーの管理対象サーバーを再起動します。

3. 再起動後にコンテンツ・サーバーのホーム・ページに表示される、Click to complete workflow setupという警告をクリックします。

コンテンツ・サーバーから返される、「キュー内のワークフローの設定が成功しました。」という成功メッセージを確認します。

4. WebCenter Contentユーザー・インタフェース・ドメインにWebLogic Serverの管理コンソールを使用して、WebCenter Contentユーザー・インタフェースの管理対象サーバーを再起動します。

ワークフローの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のワークフローの管理に関する項を参照してください。

第IV部 エンタープライズ・デプロイメントの共通の構成および管理手順

次の項では、標準的なエンタープライズ・デプロイメントに必須または推奨される構成および管理手順について説明します。

- エンタープライズ・デプロイメントの共通の構成および管理タスク
ここでは、エンタープライズ・デプロイメント環境で実行する必要性が高い構成および管理タスクについて説明します。

- エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用
ここでは、Oracle WebLogic Server全体の移行およびOracle WebLogic Server自動サービス移行について説明します。また、これらの機能をOracle Fusion Middlewareエンタープライズ・トポロジで使用する方法についても説明します。

- エンタープライズ・デプロイメント用のシングル・サインオンの構成
この章では、Oracle HTTP Server WebGateを構成して、Oracle Access Managerのシングル・サインオンを有効にする方法を説明します。

17 エンタープライズ・デプロイメントの共通の構成および管理タスク

ここでは、エンタープライズ・デプロイメント環境で実行する必要性が高い、構成および管理タスクについて説明します。

- 管理サーバーの手動フェイルオーバーの確認
ホスト・コンピュータで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。次に、WCCHOST1およびWCCHOST2からの管理サーバーのフェイルオーバーおよびフェイルバックを検証する方法を示します。

- 中間層とハードウェア・ロード・バランサ間のSSL通信の有効化
この項では、中間層とハードウェア・ロード・バランサ間のSSL通信を有効にする方法を説明します。

- エンタープライズ・デプロイメントの管理用のロールの構成
この項では、特定の管理ロールを持つ製品の概要を提供して、エンタープライズ・デプロイメント管理グループに製品固有の管理ロールを追加する手順を説明します。

- エンタープライズ・デプロイメントでのTLOGおよびJMSのためのJDBC永続ストアの使用
次のトピックは、どのようなときにトランザクション・ログ(TLOGs)およびJMSにJDBC永続ストアを使用するかのガイドラインを提供します。サポートされるデータベースに永続ストアを構成するために使用できる手順も説明します。

- エンタープライズ・デプロイメントのバックアップとリカバリの実行
この項では、Oracle WebCenter Contentエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするためのガイドラインを示します。

- uploadおよびstageディレクトリの絶対パスへの変更
ドメインを作成し、管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

上位トピック: 「エンタープライズ・デプロイメントの共通の構成および管理手順」

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であり、ethX:Yに割り当てられており、WCCHOST1およびWCCHOST2からアクセスできます。

- Oracle WebLogic ServerとOracle Fusion Middlewareのコンポーネントが、このガイドの個々の構成の章で示すように、WCCHOST2にインストールされています。
具体的には、両方のホスト・コンピュータは、まったく同じパスを使用して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>

次に例を示します。

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、WCCHOST2で使用可能なネットワーク構成と一致している必要があります。

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にアクセスして、管理サーバーがWCCHOST2で実行しているときにアクセスできることを確認します。

- 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. WCCHOST2で次のコマンドをルートとして実行します。

/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. WCCHOST1上で管理サーバーを起動します。

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に自己署名証明書を作成する手順を説明します。これらの証明書は、ネットワーク名またはホストの別名を使用して作成します。

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、WCCHOST2では、WCCHOST1の証明書用に作成されたcertディレクトリを使用します。

かわりに信頼できるCA証明書を使用する方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する情報を参照してください。

パスワードについて

このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。

自己署名証明書を作成する手順は次のとおりです。

1. 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

5. キーストア・ホームにディレクトリを変更します。

cd KEYSTORE_HOME

6. 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 WCCHOST1.example.com_cert \
WCCHOST1.example.com_key domestic WCCHOST1.example.com

17.2.3 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

この項では、WCCHOST1.example.comでアイデンティティ・キーストアを作成する方法について説明します。

前の項では、証明書とキーを作成して、それを共有記憶域に配置しました。この項では、WCCHOST1と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/WCCHOST1.example.com_cert.pem
-keyfile KEYSTORE_HOME/WCCHOST1.example.com_key.pem
-keyfilepass password
-keystore appIdentityKeyStore.jks
-storepass password
-alias WCCHOST1
-keypass password

2. システムで使用される残りのすべてのホスト(たとえばWCCHOST2)で前述の手順を繰り返します。

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. ブラウザの証明書管理ツールから、証明書を、サーバーのファイル・システム上のファイル(ファイル名wcc.example.comなど)にエクスポートします。

3. keytoolを使用して、ロード・バランサの証明書をトラスト・ストアにインポートします。

keytool -import -file wcc.example.com -v -keystore appTrustKeyStore.jks

17.2.6 Oracle WebLogic Server起動スクリプトへの更新済トラスト・ストアの追加

各サーバーが更新済のトラスト・ストアにアクセスできるようにするには、エンタープライズ・デプロイメント内の各ドメイン・ホーム・ディレクトリのsetDomainEnv.shスクリプトを次のように編集します。

1. WCCHOST1にログインして、テキスト・エディタで次のファイルを開きます。

ASERVER_HOME/bin/setDomainEnv.sh

2. 既存のDemoTrustStoreエントリへの参照を、appTrustKeyStore.jksファイルの場所で置き換えます。

EXTRA_JAVA_PROPERTIESのすべての値をファイル内に1行で記述し、その後の新規行にexportコマンドを記述する必要があります。次に例を示します。

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
-Djavax.net.ssl.trustStore=KEYSTORE_HOME/appTrustKeyStore.jks..."
export EXTRA_JAVA_PROPERTIES

3. WCCHOST1およびWCCHOST2のMSERVER_HOME/binディレクトリにあるsetDomainEnv.shファイルに、同じ変更を行います。

あるいは、setUserOverrides.shファイルを使用して、これらのオプションを配置できます。この方法では、ドメインのスクリプトが構成ウィザードによって拡張されたり、解凍操作によって更新されたりする場合にも、これらのオプションは上書きされません。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。

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には必ず正しい値を使用してください。たとえば、WCCHOST1では、「keytoolユーティリティを使用した信頼キーストアの作成」の手順に従って、appIdentity2を使用します

(appIdentity2 mapped to the WCCHOST1 listen address).
Example for Node 1:
KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=KEYSTORE_HOME/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentity1
CustomIdentityPrivateKeyPassPhrase=password

「WCCHOST1でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリは暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイルのエントリが暗号化されていない状態になる時間は最小限に抑えてください。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

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ユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します

13. 「保存」をクリックします。

14. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

15. 変更を適用したサーバーを再起動します。管理コンソール/ノード・マネージャを使用してサーバーを再起動できるということは、ノード・マネージャ、管理サーバー、および管理対象サーバー間の通信が正常であるということです。

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_SOAn)をクリックして、コンポジットがデプロイされたパーティションを選択します。

4. コンポジットを選択します。

5. 右側のペインで、「テスト」タブをクリックします。

6. WSDLまたはWADLアドレスで、http://wcc.example.com:80をwcc.example.comに置き換えます。

7. 「WSDLまたはWADLの解析」をクリックします。

8. 表示されるエンドポイントURLがSSLであることを確認します。

9. コンポジットをテストします。Webサービスのレスポンスが期待どおりであれば、管理サーバーとロード・バランサ間のSSL通信は正常に構成されています。

17.3 エンタープライズ・デプロイメントの管理用ロールの構成

この項では、特定の管理ロールを持つ製品の概要を提供して、エンタープライズ・デプロイメント管理グループに製品固有の管理ロールを追加する手順を説明します。

各エンタープライズ・デプロイメントは複数の製品で構成されます。製品の一部には、各製品への管理アクセスの制御に使用される、特定の管理ユーザー、ロールまたはグループが存在します。

ただし、複数の製品で構成されているエンタープライズ・デプロイメントでは、単一のLDAPベースの認可プロバイダと、単一の管理ユーザーおよびグループを使用して、デプロイメントのあらゆる側面に対するアクセスを制御できます。認可プロバイダの作成と、エンタープライズ・デプロイメントの管理ユーザーおよびグループのプロビジョニングの詳細は、「新規LDAP認可プロバイダの作成およびエンタープライズ・デプロイメントの新しいユーザーとグループのプロビジョニング」を参照してください。

単一のエンタープライズ・デプロイメント・ドメイン内で各製品を効率的に管理できるようにするには、特定の管理ロールまたはグループを必要とする製品を理解すること、単一の共通エンタープライズ・デプロイメントの管理グループに特定の製品管理ロールを追加する方法を知ること、さらに必要な場合は、必須の製品固有の管理グループにエンタープライズ・デプロイメントの管理ユーザーを追加する方法を知ることが必要になります。

詳細な情報は、次のトピックを参照してください

- 特定の管理ロールを持つ製品のサマリー

- エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加

17.3.1 特定の管理ロールを持つ製品のサマリー

次の表に、エンタープライズ・デプロイメントの管理グループ(WCCAdministrators)に追加する必要のある特定の管理ロールを持つ、Fusion Middleware製品のリストを示します(この管理グループは、エンタープライズ・デプロイメントのLDAP認可プロバイダで定義したものです)。

次の表にある情報と「エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加」の手順を使用して、必要な管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。

製品

アプリケーション・ストライプ

割り当てる管理ロール

Oracle Web Services Manager。

wsm-pm

policy.updater

SOAインフラストラクチャ

soa-infra

SOAAdmin

17.3.2 エンタープライズ・デプロイメントの管理グループへの製品固有の管理ロールの追加

製品固有の管理ロールを必要とする製品では、次の手順を使用して、その管理ロールをエンタープライズ・デプロイメントの管理グループに追加します。

1. Oracle WebLogic Server管理サーバーの資格証明を使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

これらは、最初にドメインを構成し、Oracle WebLogic Server管理ユーザー名(通常weblogic_wcc)とパスワードを作成したときに作成した資格証明です。

2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。

3. 製品固有のアプリケーション・ロールごとに、「アプリケーション・ストライプ」ドロップダウン・メニューから対応するアプリケーション・ストライプを選択します。

4. 「アプリケーション・ロールの検索」アイコンをクリックして、ドメインで利用できるすべてのアプリケーション・ロールを表示します。

5. エンタープライズ・デプロイメントの管理グループに追加するアプリケーション・ロールの行を選択します。

6. 「編集」アイコンをクリックして、ロールを編集します。

7. 「アプリケーション・ロールの編集」ページの「追加」アイコンをクリックします。

8. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。

9. エンタープライズ・デプロイメント管理者グループを検索します。グループ名(WCCAdministratorsなど)を「プリンシパル名が次で始まる」フィールドに入力し、右矢印をクリックして検索を開始します。

10. 検索結果で管理者グループを選択し、「OK」をクリックします。

11. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

17.4 エンタープライズ・デプロイメントのTLOGおよびJMSでのJDBC永続ストアの使用

ここでは、トランザクション・ログ(TLOG)とJMSのためにJDBC永続ストアをいつ使用するかについてガイドラインを示します。サポートされるデータベースに永続ストアを構成するために使用できる手順も説明します。

- JMSおよびTLOGのためのJDBC永続ストアについて
Oracle Fusion Middlewareは、Oracle WebLogic Serverトランザクション・ログ(TLOG)およびJMSのために、データベースベースとファイルベース両方の永続ストアをサポートします。環境の永続ストア戦略を決定する前に、各アプローチのメリットとデメリットを検討してください。

- TLOGおよびJMS永続ストアのパフォーマンスへの影響
トランザクション・ログとJMSの永続ストアの格納方法を選択する際の重要な考慮事項の1つは、パフォーマンスに対する潜在的な影響です。ここでは、TLOGおよびJMSのJDBC永続ストアの使用によるパフォーマンスの影響を判別するために役立つガイドラインと詳細情報を説明します。

- TLOG用のJDBC永続ストア構成のロードマップ
次のトピックでは、JMSのためにデータベースベースの永続ストアを構成する方法を説明します。

- JMS用のJDBC永続ストア構成のロードマップ
次のトピックでは、JMSのためにデータベースベースの永続ストアを構成する方法を説明します。

- TLOGのユーザーと表領域の作成
トランザクション・ログのデータベースベース永続ストアを作成する前に、サポートされるデータベースでユーザーと表領域を作成する必要があります。

- JMSのユーザーと表領域の作成
JMSのデータベースベース永続ストアを作成する前に、サポートされるデータベースでユーザーと表領域を作成する必要があります。

- TLOGおよびJMSストアのGridLinkデータ・ソースの作成
JMSおよびTLOGにデータベースベースの永続ストアを構成する前に、TLOG永続ストアとJMS永続ストアにそれぞれ1つずつ、2つのデータ・ソースを作成する必要があります。

- 管理対象サーバーへのTLOG JDBCストアの割当て
データベースで表領域とユーザーを作成して、データ・ソースを作成した後で、TLOG永続ストアを必須の管理対象サーバーそれぞれに割り当てることができます。

- JMSが格納するJDBCの作成
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で同じタイプのストアを使用することをお薦めします。

OracleデータベースでTLOGおよびJMSデータを格納すると、データベースのレプリケーションや高可用性の機能を利用できます。たとえば、OracleData Guardを使用してサイト間の同期を簡略化できます。これは、障害時リカバリ構成にOracle Fusion Middlewareをデプロイしている場合に特に重要です。

また、TLOGおよびJMSデータをデータベースに格納すると、そのデータについて共有記憶域内の特定の場所を指定する必要がありません。ただし、エンタープライズ・デプロイメントの他の観点からも共有記憶域が必要であることに注意してください。たとえば、管理サーバー構成(管理サーバーのフェイルオーバーをサポート)、デプロイメント・プラン、およびアダプタ・アーティファクト(ファイル/FTPアダプタの制御ファイルおよび処理済ファイル)でも必要です。

TLOGおよびJMSストアを共有記憶域デバイスに格納する場合は、適切なレプリケーションおよびバックアップ戦略を使用してデータを保護し、データ損失ゼロを保証できます。また、システム・パフォーマンスを潜在的に向上することができます。ただし、ファイル・システムの保護機能はOracle Databaseによって提供される保護機能ほど優れていません。

データベースベースのTLOGおよびJMSストアの使用によるパフォーマンスへの潜在的な影響の詳細は、「TLOGおよびJMS永続ストアのパフォーマンスへの影響」を参照してください。

17.4.2 TLOGおよびJMS永続ストアのパフォーマンスへの影響

トランザクション・ログとJMSの永続ストアの格納方法を選択する際の重要な考慮事項の1つは、パフォーマンスに対する潜在的な影響です。ここでは、TLOGおよびJMSのJDBC永続ストアの使用によるパフォーマンスの影響を判別するために役立つガイドラインと詳細情報を説明します。

トランザクション・ログおよびJMSストアのパフォーマンスへの影響

トランザクション・ログの場合、ログの性質から非常に一過性が高いため、JDBCストア使用の影響は相対的にわずかです。一般的に、システムの他のデータベース操作と比べると影響は最小です。

一方、JMSデータベース・ストアは、アプリケーションでのJMS使用率が高い場合にパフォーマンスに大きな影響を及ぼすことがあります。

パフォーマンスに影響する要因

JMS DBストアをカスタム宛先で使用するとき、システムのパフォーマンスに影響する要因は複数あります。主なものを次に示します。

- 関連するカスタム宛先とそのタイプ

- 永続化するペイロード

- SOAシステムでの同時実行性(宛先のコンシューマに対するプロデューサ)

前述のそれぞれの影響の程度に応じて、パフォーマンスを改善するために次に関して様々な設定を構成できます。

- JMS表で使用されるデータ型(RAWまたはLOBの使用)

- JMS表のセグメント定義(索引および表レベルのパーティション)

JMSトピックの影響

ご使用のシステムがトピックを集中的に使用すると、同時実行性が高くなるにつれて、Oracle RACデータベースでのパフォーマンス低下はキューの場合よりも大きくなります。JMSを使用するOracleで行ったテストでは、様々なペイロード・サイズと様々な同時実行性での平均パフォーマンス低下はキューの場合は30%未満でした。トピックの場合、影響は40%を超えました。データベース・ストアを使用するかどうかを決めるときには、リカバリの観点からこのような宛先の重要性を検討してください。

データ型とペイロード・サイズの影響

ペイロードで使用するためにRAWデータ型またはSecureFiles LOBデータ型を選択するときは、永続化するペイロードのサイズを考慮します。たとえば、ペイロード・サイズが100バイトから20KBまでの場合、SecureFiles LOBで必要なデータベース時間はRAWデータ型の場合よりも少し長くなります。

具体的には、ペイロード・サイズが約4KBになると、SecureFilesで必要なデータベース時間が長くなります。4KBになると書込みが行の外に移動するためです。ペイロード・サイズが約20KBになると、SecureFilesデータの効率がよくなります。ペイロード・サイズが20KBを超えると、RAWデータ型に設定されたペイロードではデータベース時間が長くなります。

SecureFilesのもう1つの利点は、ペイロードが500KB以上に増加すると、発生するデータベース時間が安定することです。つまり、その時点で、データによって格納されるペイロードが500KB、1MBまたは2MBであるかは(SecureFilesにとって)関係ありません。書込みは非同期で行われ、競合はすべてのケースで同一であるためです。

キューのスループットに対する同時実行性(プロデューサとコンシューマ)の影響は、ペイロード・サイズが50KBになるまではRAWとSecureFilesで似ています。ペイロードが小さい場合は、同時実行性を変更しても影響は実質的に同じです(RAWのスケーラビリティが少し上回ります)。ペイロードが50KBを超えると、SecureFilesのスケーラビリティが高くなります。

同時実行性、ワーカー・スレッドおよびデータベース・パーティション化の影響

永続ストアに定義された同時実行性とワーカー・スレッドによって、RACデータベースの索引およびグローバル・キャッシュ・レベルで競合が発生することがあります。1つのサーバーで複数のワーカー・スレッドを有効にするときに逆索引を使用する、または複数のOracle WebLogic Serverクラスタを使用すると、逆索引を使用すると状況が改善する可能性があります。ただし、Oracle Databaseのパーティション化オプションが使用可能な場合は、索引のグローバル・ハッシュ・パーティションをかわりに使用してください。こうすると、索引の競合とグローバル・キャッシュ・バッファの待機が減少し、それによってアプリケーションのレスポンス時間が短縮されます。パーティション化はどのケースでも効果がありますが、逆索引を使用しても大きく改善されないことがあります。

17.4.3 TLOG用のJDBC永続ストア構成のロードマップ

ここでは、JMSのためにデータベースベースの永続ストアを構成する方法を説明します。

1. TLOGのユーザーと表領域の作成

2. TLOGおよびJMSストアのGridLinkデータ・ソースの作成

3. 管理対象サーバーへのTLOG JDBCストアの割当て

17.4.4 JMS用のJDBC永続ストア構成のロードマップ

ここでは、JMSのためにデータベースベースの永続ストアを構成する方法を説明します。

1. JMSのユーザーと表領域の作成

2. TLOGおよびJMSストアのGridLinkデータ・ソースの作成

3. JDBC JMSストアの作成

4. JMSサーバーへのJMS JDBCストアの割当て

5. JMS JDBCストアで必要な表の作成

17.4.5 TLOGのユーザーと表領域の作成

トランザクション・ログのデータベースベース永続ストアを作成する前に、サポートされるデータベースでユーザーと表領域を作成する必要があります。

1. tlogsという表領域を作成します。

たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace tlogs
logging datafile 'DB_HOME/oradata/orcl/tlogs.dbf'
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.6 JMSのユーザーと表領域の作成

JMSのデータベースベース永続ストアを作成する前に、サポートされるデータベースでユーザーと表領域を作成する必要があります。

1. jmsという表領域を作成します。

たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace jms
logging datafile 'DB_HOME/oradata/orcl/jms.dbf'
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 TLOG quota unlimited on jms;

17.4.7 TLOGおよびJMSストアのGridLinkデータ・ソースの作成

JMSおよびTLOGのためのデータベースベース永続ストアを構成する前に、2つのデータ・ソース(TLOG永続ストアのために1つ、JMS永続ストアのために1つ)を作成する必要があります。

エンタープライズ・デプロイメントでは、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のサービス名を入力します。次に例を示します。
wccedg.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=wccedg.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. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

17.4.8 管理対象サーバーへの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.9 JDBC JMSストアの作成

JMS永続ストアのユーザーと表領域をデータベースに作成し、JMS永続ストアのデータ・ソースを作成した後で、管理コンソールを使用してストアを作成できます。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を展開し、「永続ストア」を選択します。

4. 「新規」をクリックし、「JDBCストア」をクリックします。

5. 永続ストアを使用するJMSサーバーとすぐに関連付けることができる永続ストア名を入力します。

6. インストールとクラスタを修飾する一意の接頭辞を指定し、JMS永続ストアのために作成したデータ・ソースに関連付けます。

7. JTAサービスをホストするエンティティをストアの対象として設定します。
サービス移行を使用するサーバーの場合、これはサーバーが所属するクラスタになります。

8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

17.4.10 JMSサーバーへのJMS JDBCストアの割当て

データベースでJMSの表領域とユーザーを作成し、JMSデータ・ソースを作成し、JDBCストアを作成した後で、JMS永続ストアを必須のJMSサーバーそれぞれに割り当てることができます。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします。

3. 「ドメイン構造」ツリーで、「環境」、「メッセージング」、「JMSサーバー」の順に展開します。

4. 永続ストアを使用するように設定するJMSサーバーの名前をクリックします。

5. 「永続ストア」メニューで、前に作成したJMS永続ストアを選択します。

6. 「保存」をクリックします。

7. クラスタの他のJMSサーバーそれぞれについて、手順3から6までを繰り返します。

8. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

17.4.11 JMS JDBCストアで必要な表の作成

JMSのためのJDBC永続ストアを使用する最後の手順は、必要なJDBCストア表の作成です。このタスクを実行してから、ドメインの管理対象サーバーを再起動します。

1. JDKで用意されているJARユーティリティを使用すると、次のコマンドでDDLファイルを/weblogic/store/io/jdbc/ddlディレクトリに抽出できます。

jar xf com.bea.core.store.jdbc_1.0.0.0.jar /weblogic/store/io/jdbc/ddl

注意:

weblogic/store/io/jdbc/ddlパラメータを省略すると、jarファイル全体が抽出されます。

2. 「TLOGおよびJMS永続ストアのパフォーマンスへの影響」の情報を確認し、それに応じてDDLファイルを編集します。

たとえば、最適化されたスキーマ定義でセキュア・ファイルとハッシュ・パーティション化の両方を使用している場合、ORACLE_RUNTIMEディレクトリ(またはすべてのサーバーからアクセス可能な共有記憶域上の他のディレクトリ)に次の内容を含む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);

この例をJMSストアのデフォルト・スキーマ定義と比較してください。デフォルトのスキーマ定義では、RAWデータ型が使用され、索引のパーティションはありません。

パーティション数は2の累乗にする必要があることに注意してください。こうすることで、各パーティションのサイズが同程度になります。推奨するパーティション数は、表または索引サイズの増大をどのように予期するかによって変わります。時間経過に伴う表サイズの増大の分析と、それに応じた表の調整を、データベース管理者(DBA)に依頼する必要があります。詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

3. 管理コンソールを使用して、前に作成した既存のJDBSストアを編集します。JMSデータのために使用される表を作成します。

a. Oracle WebLogic Server管理コンソールにログインします。

b. 「チェンジ・センター」で「ロックして編集」をクリックします。

c. 「ドメイン構造」ツリーで、「サービス」、「永続ストア」を順に展開します。

d. 前に作成した永続ストアをクリックします。

e. 「詳細」オプションで、DDLファイルからの表の作成」フィールドにORACLE_RUNTIME/jms_custom.ddlを入力します。

f. 「保存」をクリックします。

g. 管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

4. 管理対象サーバーを再起動します。

17.5 エンタープライズ・デプロイメントのバックアップとリカバリの実行

この項では、Oracle WebCenter Contentエンタープライズ・デプロイメントの必要なディレクトリと構成データを確実にバックアップするためのガイドラインを示します。

注意:

この項で示す静的アーティファクトと実行時アーティファクトの一部は、Network Attached Storage (NAS)でホストされています。可能であれば、これらのボリュームをアプリケーション・サーバーからではなくNASファイラから直接バックアップおよびリカバリします。

Oracle Fusion Middleware製品のバックアップとリカバリの一般情報は、『Oracle Fusion Middlewareの管理』の次の項を参照してください。

- 「環境のバックアップ」

- 環境のリカバリに関する項

表17-1に、典型的なOracle WebCenter Contentエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示します。

表17-1 Oracle WebCenter Contentエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト

タイプ

ホスト

層

データベースOracleホーム

DBHOST1およびDBHOST2

データ層

Oracle Fusion Middleware Oracleホーム

WEBHOST1およびWEBHOST2

Web層

Oracle Fusion Middleware Oracleホーム

WCCHOST1およびWCCHOST2

アプリケーション層

インストール関連ファイル

WEBHOST1、WEHOST2および共有記憶域

該当なし

表17-2に、典型的なOracle WebCenter Contentエンタープライズ・デプロイメントのバックアップ対象である実行時アーティファクトを示します。

表17-2 Oracle WebCenter Contentエンタープライズ・デプロイメントのバックアップ対象である実行時アーティファクト

タイプ

ホスト

層

管理サーバーのドメイン・ホーム(ASERVER_HOME)

WCCHOST1およびWCCHOST2

アプリケーション層

アプリケーション・ホーム(APPLICATION_HOME)

WCCHOST1およびWCCHOST2

アプリケーション層

Oracle RACデータベース

DBHOST1およびDBHOST2

データ層

スクリプトとカスタマイズ

WCCHOST1およびWCCHOST2

アプリケーション層

デプロイメント・プラン・ホーム(DEPLOY_PLAN_HOME)

WCCHOST1およびWCCHOST2

アプリケーション層

17.6 uploadおよびstageディレクトリの絶対パスへの変更

ドメインを作成し、管理対象サーバーのドメイン・ディレクトリにそのドメインを解凍した後、管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。

この手順は、リモート・デプロイメントの実行時の潜在的な問題の回避とステージ・モードが必要なデプロイメントのために必要です。

管理対象サーバー・ドメイン・ホーム・ディレクトリ内のすべての管理対象サーバーについてこれらのディレクトリ・パスを更新する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のナビゲーション・ツリーで、「ドメイン」→「環境」を開きます。

3. 「ロックして編集」をクリックします。

4. 「サーバー」をクリックします。

5. 管理対象サーバー・ドメイン・ホーム・ディレクトリ内の各管理対象サーバーについて次の操作を実行します。

a. 管理対象サーバーの名前をクリックします。

b. 「構成」タブをクリックし、「デプロイメント」タブをクリックします。

c. 「ステージング・ディレクトリ名」が次のように設定されていることを確認します。

MSERVER_HOME/servers/server_name/stage

MSERVER_HOMEをMSERVER_HOMEディレクトリのディレクトリ・パスに置き換え、server_nameを編集しているサーバーの名前に置き換えます。

管理サーバーのステージング・ディレクトリを構成する予定がある場合、プロパティを次のように設定する必要があります。

ASERVER_HOME/servers/AdminServer/stage

d. 「アップロード・ディレクトリ名」を次の値に更新します。

ASERVER_HOME/servers/AdminServer/upload

ASERVER_HOMEをASERVER_HOMEディレクトリのディレクトリ・パスに置き換えます。

e. 「保存」をクリックします。

f. 「サーバーのサマリー」画面に戻ります。

6. 各管理対象サーバーについてこれらの値を変更したら、「変更のアクティブ化」をクリックします。

7. すべての管理対象サーバーを再起動します。

18 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

ここでは、Oracle WebLogic Server全体の移行および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 サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

次の表は、サーバー全体の移行を構成する必要のある製品とコンポーネント、および自動サービス移行を構成する必要のある製品をまとめたものです。

この表で示すのは、推奨するベスト・プラクティスであることに注意してください。対応するコンポーネントでのサーバー全体の移行または自動サービス移行の使用を禁止するものではありません。

コンポーネント

サーバー全体の移行(WSM)

自動サービス移行(ASM)

Oracle WebCenter Content

いいえ

はい

Oracle SOA Suite

いいえ

はい

Oracle Enterprise Capture

いいえ

はい

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のサービス名を入力します。次に例を示します。
wccedg.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=wccedg.example.com))) succeeded.

「次へ」をクリックします。

9. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- SCANアドレスを「ONSホストとポート」フィールドに入力して「追加」をクリックし、さらに「追加」をクリックします。
この値には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スクリプトに対する権限の付与

オペレーティング・システム・ユーザー(oracle)にパスワード制限のないsudo権限を付与し、さらに/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_WCC1

2. ノード・マネージャのコンソール(killコマンドを実行したターミナル・ウィンドウ)を確認します。管理対象サーバーの浮動IPが無効になっていることを示すメッセージが表示されているはずです。

3. ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャがサーバーを再起動し、サーバーが「実行中」状態になる前に、関連するプロセスを再度強制終了します。
サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

必要な再起動回数は、次の構成ファイルのRestartMaxパラメータで設定されます。

MSERVER_HOME/servers/WLS_WCC1/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. 変更をアクティブ化します。

18.4.2 クラスタ内の管理対象サーバーの移行設定の変更

クラスタのリース・メカニズムとデータ・ソースを設定したら、サービス移行を構成する管理対象サーバーについて自動JTA移行を有効化できます。このトピックが適用されるのは、JTAサービスをエンタープライズ・デプロイメントの一部としてデプロイしている場合のみです。

たとえば、このタスクはOracle WebCenter Contentエンタープライズ・デプロイメントでは必要ありません。

各クラスタの管理対象サーバーについて移行設定を変更するには、次の手順を実行します。

1. まだ行っていない場合は、管理コンソールにログインして「ロックして編集」をクリックします。

2. 「ドメイン構造」ペインの「環境」ノードを開き、「サーバー」をクリックします。
「サーバーのサマリー」ページが表示されます。

3. 表の「名前」列で、変更するサーバーの名前をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

4. 「移行」タブをクリックします。

5. 「JTA移行ポリシー」ドロップダウン・メニューで「障害リカバリ」を選択します。

6. このページの「JTA候補サーバー」セクションで、「使用可能」リスト・ボックスの管理対象サーバーを選択し、移動ボタンをクリックして、「選択済み」リスト・ボックスに移します。

7. このページのJMS候補サーバー・セクションで、「使用可能」リスト・ボックスの管理対象サーバーを選択し、移動ボタンをクリックして、「選択済み」リスト・ボックスに移します。

8. 「保存」をクリックします。

18.4.3 サービス移行ポリシーの選択について

自動サービス移行を構成するとき、クラスタごとにサービス移行ポリシーを選択します。ここでは、サービス移行ポリシーを選択する際のガイドラインと考慮事項を説明します。

たとえば、シングルトンを実行したりパス・サービスを使用したりする製品またはコンポーネントは、「必ず1回のサービスを自動移行」ポリシーのメリットがあります。このポリシーでは、候補サーバーのリストにある管理ターゲット・サーバーが1つ以上動作しているとき、この移行可能ターゲットでホストされるサービスは、サーバーが失敗するか管理者によって(正常または強制的に)シャットダウンされた場合に、クラスタ内のいずれかの場所でアクティブ化されます。このために、起動時に1つのサーバーで複数の同じサービスが起動してしまうことがあります。

このポリシーを使用するときは、クラスタの起動を監視して、各サーバーでどのサーバーが実行しているかを識別する必要があります。その後、必要に応じて手動フェイルバックを実行して、システムの構成のバランスを調整できます。

他のFusion Middlewareコンポーネントの方が「障害回復サービスの自動移行」ポリシーに適しています。このポリシーでは、移行可能ターゲットのユーザー優先サーバー(UPS)が起動している場合にのみ、移行可能ターゲットでホストされているサービスが起動します。

これらのガイドラインに基づいて、Oracle WebCenter Contentエンタープライズ・デプロイメントでクラスタに対して「障害回復サービスの自動移行」を使用する必要があります。

詳細は、『Oracle WebLogic Serverクラスタの管理』の手動および自動サービス移行のポリシーに関する項を参照してください。

18.4.4 クラスタ内の各管理対象サーバーでのサービス移行ポリシーの設定

クラスタの各サーバーの移行設定を変更した後、WebLogic管理コンソールを使用して、クラスタの各管理対象サーバーで、サービスを識別して移行ポリシーを設定できます。

1. まだ行っていない場合は、管理コンソールにログインして「ロックして編集」をクリックします。

2. 「ドメイン構造」ペインで、「環境」と「クラスタ」を順に展開し、「移行可能なターゲット」を選択します。

3. クラスタ内の最初の管理対象サーバーの名前をクリックします。

4. 「移行」タブをクリックします。

5. 「サービス移行ポリシー」ドロップダウン・メニューで、クラスタの適切なポリシーを選択します。
詳細は、「サービス移行ポリシーの選択について」を参照してください。

6. このページの「控えの候補サーバー」セクションで、「使用可能」リスト・ボックスの両方の管理対象サーバーを選択し、それらを「選択済み」リスト・ボックスに移動します。

7. 「保存」をクリックします。

8. クラスタの他の管理対象サーバーそれぞれについて、手順2から6までを繰り返します。

9. 変更をアクティブ化します。

10. クラスタの管理対象サーバーを再起動します。

18.4.5 管理対象サーバーの再起動と自動サービス移行の検証

クラスタと管理対象サーバーの自動サービス移行を構成した後で、次のように構成を検証します。

1. まだログインしていない場合は、管理コンソールにログインします。

2. 「ドメイン構造」ペインで、「環境」、「クラスタ」を順に選択し、自動サービス移行を構成したばかりのクラスタを再起動します。

3. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に開きます。

4. 「移行可能なターゲット」をクリックします。

5. 「制御」タブをクリックします。
コンソールには、移行可能なターゲットと現在のホスティング・サーバーのリストが表示されます。

6. 「移行可能なターゲット」表で、いずれかの移行可能なターゲットの行を選択します。

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 so attempting to restart (restart count = 1)>.

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 HTTP Server WebGateを構成して、Oracle Access Managerのシングル・サインオンを有効にする方法を説明します。

- Oracle HTTP Server WebGateについて
Oracle HTTP Server WebGateは、HTTPリクエストをインターセプトし、それを認証および認可のために既存のOracle Access Managerインスタンスに転送するWebサーバー・プラグインです。

- Oracle HTTP Server 12c Webgateの構成の一般的な前提条件
Oracle HTTP Server 12c 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 12c 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インスタンスに転送するWebサーバー・プラグインです。

Oracle Fusion Middleware 12cでは、WebGateソフトウェアはOracle HTTP Server 12cソフトウェア・インストールの一部としてインストールされます。

WebGateの詳細は、『Oracle Access Management管理者ガイド』のOAM 11gエージェントの登録と管理に関する項を参照してください。

19.2 Oracle HTTP Server 12c WebGateを構成するための一般的な前提条件

Oracle HTTP Server 12c 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 Help Centerの「Middlewareドキュメント」にあるOracle Identity and Access Managementの最新ドキュメントを参照してください。

19.3 OHS 12c WebGateを構成するためのエンタープライズ・デプロイメントの前提条件

Oracle HTTP Server WebGateを構成して、エンタープライズ・デプロイメントのシングル・サインオンを有効にする場合は、この項に示す前提条件を検討してください。

- Oracle Access Managerをセキュアな高可用性本番環境の一部としてデプロイすることをお薦めします。エンタープライズ環境にOracle Access Managerをデプロイする方法の詳細は、ご使用バージョンに対応する『Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

- WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlでシングル・サインオンを有効にするには、集中管理型LDAPでプロビジョニングされた管理ユーザーをOracle Access Managerが使用しているディレクトリ・サービス(たとえば、Oracle Internet DirectoryまたはOracle Unified Directory)に追加する必要があります。LDAPディレクトリに追加する必須ユーザーおよびグループの詳細は、「新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング」の手順を参照してください。

19.4 エンタープライズ・デプロイメントでのOracle HTTP Server 12c WebGateの構成

次の手順を実行して、WEBHOST1とWEBHOST2の両方でOracle Access Manager用のOracle HTTP Server 12c WebGateを構成します。

次の手順では、ディレクトリ変数(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. webgateディレクトリおよびサブディレクトリがdeployWebGateInstanceコマンドによって作成されたことを確認します。

ls -lart OHS_CONFIG_DIR/webgate/
total 6
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

このコマンドは次の処理を実行します。

- Oracle HTTP Server Oracleホームのapache_webgate.templateファイルを、Oracle HTTP Server構成ディレクトリの新しいwebgate.confファイルにコピーします。

- httpd.confファイルを更新して、webgate.confを含むように1行を追加します。

- WebGate構成ファイルを生成します。ファイルのデフォルト名はwebgate.confですが、コマンドでoutput_file引数を使用するとカスタム名を使用できます。

19.5 Oracle Access ManagerでのOracle HTTP Server 12c WebGateの登録

Oracle Access Manager管理コンソールを使用すると、Oracle Access ManagerにWebGateエージェントを登録できます。

詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のコンソールを使用したOAMエージェントの登録に関する項を参照してください。

詳細は、以下のトピックを参照してください。

- RREGツールの場所と準備

- RREGのインバンドおよびアウトオブバンド・モードについて

- OAM11gRequest.xmlファイルの標準プロパティの更新

- エンタープライズ・デプロイメントの保護リソース、パブリック・リソースおよび除外リソースの更新

- RREGツールの実行

- RREGによって生成されるファイルおよびアーティファクト

- 生成済アーティファクトのOracle HTTP Server WebGateインスタンスの場所へのコピー

- Oracle HTTP Serverインスタンスの再起動

19.5.1 RREGツールの場所と準備

RREGツールを設定するには、次の手順を実行します。

1. アプリケーション層でOracle Access Managerホストの1つにログインします。

2. Oracle Access Manager Oracleホームの次のディレクトリに、ディレクトリを変更します。
OAM_ORACLE_HOME/oam/server/rreg/client

この例では、OAM_ORACLE_HOMEはOracle Access ManagerソフトウェアがインストールされたシステムのOracleホームです。

注意:
Oracle Access Managerサーバーに対する権限またはアクセス権がない場合は、アウトオブバンド・モードを使用して必要なファイルを生成し、WebGateをOracle Access Managerに登録できます。詳細は、「RREGのインバンドおよびアウトオブバンド・モードについて」を参照してください。

3. oamreg.shファイルを開き、次の環境変数を次のようにファイルに設定します。

- OAM_REG_HOMEを、RREGアーカイブの内容を展開したディレクトリへの絶対パスに設定します。
JDK_HOMEを、サポート対象のJDKがインストールされているマシン上のディレクトリへの絶対パスに設定します。

19.5.2 RREGのインバンドおよびアウトオブバンド・モードについて

RREGツールはインバンドとアウトバンドのいずれかのモードで実行できます。

Oracle Access Managerサーバーにアクセスする権限があり、Oracle Access Manager Oracleホームから自分でRREGツールを実行するときは、インバンド・モードを使用します。RREGツールを実行した後で、生成されたアーティファクトとファイルをWebサーバー構成ディレクトリにコピーできます。

アウトオブバンド・モードを使用するのは、Oracle Access Managerサーバーに対する権限またはアクセス権がない場合です。たとえば、組織によっては、Oracle Access Managerサーバー管理者のみが、サーバーのディレクトリにアクセスして、サーバーで管理タスクを実行する権限を持ちます。アウトオブバンド・モードではプロセスが次のように処理されます。

1. Oracle Access Managerサーバー管理者からRREGアーカイブ・ファイルのコピー(RREG.tar.gz)が提供されます(サーバー管理者は「RREGツールの場所と準備」で説明されている場所でこれを見つけることができます)。

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.3 OAM11gRequest.xmlファイルの標準プロパティの更新

WebGateエージェントをOracle Access Managerに登録するには、OAM11gRequest.xmlファイルでいくつかの必須プロパティを更新する必要があります。

注意:

提供されたXMLファイルのほとんどのパラメータに関してデフォルト値の使用を計画している場合は、短いバージョンを使用できます(OAM11gRequest_short.xmlでは、指定されていないすべてのフィールドでデフォルト値が使用されます)。

このタスクを実行するには、次のようにします。

1. インバンド・モードを使用している場合、ディレクトリ内の次の場所にディレクトリを変更します。

OAM_ORACLE_HOME/oam/server/rreg/client

アウトオブバンド・モードを使用している場合、RREGアーカイブを解凍した場所にディレクトリを変更します。

2. OAM11gRequest.xmlファイル・テンプレートのコピーを作成します。

3. ファイルにリストされたプロパティを確認して、OAM11gRequest.xmlファイルのコピーを更新します。これで、プロパティが環境固有のホスト名および他の値を参照するようになります。

OAM11gRequest.xmlプロパティ

設定内容

serverAddress

Oracle Access Managerドメインの管理サーバーのホストとポート。

agentName

エージェントの任意のカスタム名。通常は、シングル・サインオンを構成しているFusion Middleware製品を示す名前を使用します。

applicationDomain

シングル・サインオンの構成を行っているWeb層ホストとFMWコンポーネントを識別する値。

security

Oracle Access Managerサーバーのセキュリティ・モード(オープン、簡易または証明書モード)。

エンタープライズ・デプロイメントでは、認証および認可トラフィックの暗号化用のカスタム・セキュリティ証明書を実装する追加の要件が存在しないかぎり、簡易モードをお薦めします。

オープン・モードでは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 Server 12c WebGateがインストールされているマシンのホストとポート。

19.5.4 エンタープライズ・デプロイメントの保護リソース、パブリック・リソースおよび除外リソースの更新

Oracle Fusion Middleware環境でシングル・サインオンを設定するとき、Oracle Access Managerでシングル・サインオンによって保護する一連のURLを指定します。これらを指定するには、OAM11gRequest.xmlファイルの特定のセクションを使用します。URLを指定するには、次の手順に従います。

1. 編集するOAM11gRequest.xmlファイルをまだ開いていない場合は、ファイルを探してテキスト・エディタで開きます。

詳細は、次を参照してください。

- RREGツールの場所と準備

- OAM11gRequest.xmlファイルの標準プロパティの更新

2. ファイルのサンプル・エントリを削除してから、次の例に示すように、保護リソース、パブリック・リソースおよび除外リソースをファイルの該当するセクションに入力します。

注意:

Oracle Access Manager 11gリリース2 (11.1.2.2)以上を使用している場合、ワイルド・カード構文を含むエントリ(.../*)は以前のバージョンのOracle Access Managerに対する下位互換性のために含まれていることに注意してください。

<protectedResourcesList>
<resource>/adfAuthentication</resource>
<resource>/ibr/adfAuthentication</resource>
<resource>/imaging/faces</resource>
<resource>/em</resource>
<resource>/console</resource>
<resource>/DefaultToDoTaskFlow</resource>
<resource>/sdpmessaging/userprefs-ui</resource>
<resource>/integration/worklistapp</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist</resource>
<resource>/soa/composer</resource>
<resource>/soa-infra/deployer</resource>
<resource>/soa-infra/events/edn-db-log</resource>
<resource>/soa-infra/cluster/info</resource>
<resource>/soa-infra</resource>
<resource>/dc-console/adfAuthentication</resource>
<resource>/dc-client/adfAuthentication</resource>
<resource>/wcc/adfAuthentication</resource>
</protectedResourcesList>
<publicResourcesList>
<resource>/cs</resource>
<resource>/_ocsh</resource>
<resource>/_dav</resource>
<resource>/imaging</resource>
<resource>/soa-infra/directWSDL</resource>
<resource>/dc-console</resource>
<resource>/wcc</resource>
</publicResourcesList>
<excludedResourcesList>
<resource>/wsm-pm</resource>
<resource>/soa-infra/services</resource>
<resource>/ucs/messaging/webservice</resource>
<resource>/imaging/ws</resource>
<resource>/idcnativews</resource>
<resource>/imaging/lib</resource>
<resource>/cs/common/idcapplet.jar</resource>
<resource>/cs/images</resource>
<resource>/dc-client</resource>
<resource>/axf-ws</resource>
</excludedResourcesList>

3. OAM11GRequest.xmlファイルを保存して閉じます。

19.5.5 RREGツールの実行

ここでは、RREGツールを実行してOracle HTTP Server WebGateをOracle Access Managerに登録するための情報を説明します。

- RREGツールをインバンド・モードで実行

- RREGツールをアウトオブバンド・モードで実行

19.5.5.1 RREGツールをインバンド・モードで実行

RREGツールをインバンド・モードで実行する手順は次のとおりです。

1. ディレクトリをRREGホーム・ディレクトリに変更します。
インバンド・モードを使用している場合、RREGディレクトリはOracle Access Manager Oracleホーム内にあります。

OAM_ORACLE_HOME/oam/server/rreg/client

アウトオブバンド・モードを使用している場合、RREGホーム・ディレクトリはRREGアーカイブを解凍した場所です。

2. RREGホーム・ディレクトリ内のbinディレクトリにディレクトリを変更します。

cd RREG_HOME/bin/

3. ファイルを実行できるようにoamreg.shコマンドの権限を設定します。

chmod +x oamreg.sh

4. 次のコマンドを実行します。

./oamreg.sh inband input/OAM11GRequest.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/OAM11GWCCDomainRequest.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.5.2 RREGツールをアウトオブバンド・モードで実行

Oracle Access ManagerサーバーでRREGツールをアウトオブバンド・モードで実行するために、Oracle Access Managerサーバー管理者は次のコマンドを使用します。

RREG_HOME/bin/oamreg.sh outofband input/OAM11GRequest.xml

この例では、次のとおりです。

- RREGアーカイブ・ファイルが解凍されたサーバー上の場所でRREG_HOMEを置き換えます。

- 編集済のOAM11GRequest.xmlファイルはRREG_HOME/inputディレクトリにあります。

- RREGツールは、このコマンドの出力(AgentID_response.xmlファイル)を次のディレクトリに保存します。

RREG_HOME/output/

この後で、Oracle Access Managerサーバー管理者は、OAM11GRequest.xmlファイルを提供したユーザーにAgentID_response.xmlを送信できます。

Webサーバー・クライアント・マシンでRREGツールをアウトオブバンド・モードで実行するには、次のコマンドを使用します。

RREG_HOME/bin/oamreg.sh outofband input/AgentID_response.xml

この例では、次のとおりです。

- RREGアーカイブ・ファイルを解凍したクライアント・システム上の場所でRREG_HOMEを置き換えます。

- AgentID_response.xmlファイル(Oracle Access Managerサーバー管理者が提供)は、 RREG_HOME/inputディレクトリにあります。

- RREGツールは、このコマンドの出力(WebGateソフトウェアを登録するために必要なアーティファクトとファイル)をクライアント・マシンの次のディレクトリに保存します。

RREG_HOME/output/

19.5.6 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/

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.7 生成済アーティファクトの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構成ディレクトリの必須の場所を示します。場合によっては、存在していないディレクトリを作成する必要があります。たとえば、ウォレット・ディレクトリは構成ディレクトリ内に存在していないことがあります。

注意:

エンタープライズ・デプロイメントでは、認証および認可トラフィックの暗号化用のカスタム・セキュリティ証明書を実装する追加の要件が存在しないかぎり、簡易モードをお薦めします。オープン・モードまたは証明書モードの使用に関する情報も便宜上ここに示します。

オープン・モードでは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/

ObAccessClient.xml

OHS_CONFIG_DIR/webgate/config

OHS_CONFIG_DIR/webgate/config/

OHS_CONFIG_DIR/webgate/config/

password.xml

該当なし

OHS_CONFIG_DIR/webgate/config/

OHS_CONFIG_DIR/webgate/config/

aaa_key.pem

該当なし

OHS_CONFIG_DIR/webgate/config/simple/

OHS_CONFIG_DIR/webgate/config/

aaa_cert.pem

該当なし

OHS_CONFIG_DIR/webgate/config/simple/

OHS_CONFIG_DIR/webgate/config/

注意:
ObAccessClient.xmlを新しいディレクトリにコピーするとき、WEBHOST1上にある最初のOracle HTTP Serverのロケーション・キャッシュから古いObAccessClient.xmlファイルを削除する必要があります。

OHS_DOMAIN_HOME/servers/ohs1/cache/config/

WEBHOST2上の2番目のOracle HTTP Serverインスタンスでも同様の手順を実行する必要があります。

OHS_DOMAIN_HOME/servers/ohs2/cache/config/

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」の2つのオプションを選択します。

11. 「保存」をクリックして設定を保存します。

12. 「変更のアクティブ化」をクリックして変更を伝播します。

13. 管理サーバーおよび管理対象サーバーを再起動します。

19.6.3 プロバイダの順序の設定

WebLogic Server管理コンソールを使用してIDアサーション・プロバイダと認証プロバイダを設定します。

プロバイダの順序を設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 左のナビゲーション・バーにある「セキュリティ・レルム」をクリックします。

4. myrealmというデフォルト・レルム・エントリをクリックします。

5. 「プロバイダ」タブをクリックします。

6. 各認証プロバイダの制御フラグが次のように設定されていることを確認することによって、Oracle Access Manager IDアサーション・プロバイダ、LDAP認証プロバイダおよびデフォルト認証プロバイダを並べ替えます。

- Oracle Access Manager IDアサーション・プロバイダ: REQUIRED

- LDAP認証プロバイダ: SUFFICIENT

- デフォルト認証プロバイダ(DefaultAuthenticator): SUFFICIENT

7. 「OK」をクリックします。

8. 「変更のアクティブ化」をクリックして変更を伝播します。

9. 管理サーバー、管理対象サーバーおよびシステム・コンポーネントを再起動します。

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’,’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

手順を示します。

a. たとえば、ユーザーがOPSSの認証ポリシーで保護されているリソースにアクセスします。

b. ユーザーがまだ認証されていない場合、ADFはユーザーを'loginuri'で設定したURIにリダイレクトします。

c. Access Managerにはloginuriの値を保護するポリシー、たとえば、"/<context-root/adfAuthenticationが存在する必要があります。

d. ADFがこのURIにリダイレクトすると、Access Managerにより「ログイン」ページが表示されます(このURI用のAccess Managerで構成された認証スキームにより異なる)。

logouturi

ログアウト・ページのURIを指定します

注意:

- ADFセキュリティが有効なアプリケーションの場合、logouturiをログアウト・ガイドラインに基づいて構成する必要があります。『Oracle Access Management管理者ガイド』の11g WebGateを使用するセッションでの集中管理型ログアウトの構成に関する項を参照してください。

- WebGate 11gを使用する場合、11g WebGateの管理者がlogouturiの値を検索する必要があります。

- WebGate 10gを使用する場合、logouturiの値は/oamsso/logout.htmlにする必要があります。

autologinuri

自動ログイン・ページのURIを指定します。これはオプションのパラメータです。

5. 管理サーバーとの接続を切断します。

disconnect()

6. 管理サーバーとすべての管理対象サーバーを再起動します。

A Oracle RACでのマルチ・データ・ソースの使用

新しいOracle RACアプリケーションを構築する際には、GridLinkデータ・ソースを使用することをお薦めします。ただし、GridLinkデータ・ソースをサポートしないレガシー・アプリケーションとデータベースを使用している場合、この付録の次の情報を参照します。

ここでは、マルチ・データ・ソースやOracle RACの詳細、およびエンタープライズ・デプロイメントでマルチ・データ・ソースを構成するための手順について説明します。

- マルチ・データ・ソースとOracle RACについて
マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。

- エンタープライズ・デプロイメント・トポロジでマルチ・データ・ソースを構成するための標準的な手順
データ・ソースはドメインの構成時に構成します。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLinkの手順をこの項で示す手順に置き換えます。

A.1 マルチ・データ・ソースとOracle RACについて

マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。

通常、このようなマルチ・データ・ソースへの接続リクエストはすべて、リストの先頭のデータ・ソースによって処理されます。データベース接続テストが失敗して接続を置き換えられなかった場合、またはデータ・ソースが中断された場合は、リストの次のデータ・ソースから順番に接続が検索されます。

Oracle RACを使用したマルチ・データ・ソースの構成の詳細は、『Oracle Fusion Middleware 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データ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, 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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork 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を参照してください。