Oracle® Fusion Middleware

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

11g リリース1 (11.1.1)

B66703-08(原本部品番号:E15483-14)

2015年8月

Oracle WebCenter Contentコンポーネントのエンタープライズ・デプロイメントへのインストールおよび構成方法を説明するインストール実行者向けのドキュメントです。Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのベスト・プラクティスの詳細な計画を示しています。

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

B66703-08

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

原本著者:  Bonnie Vaughan (ライター)、Lingaraj Nayak (協力エンジニア)

原本協力著者: Ron van de Crommert、Joe Paul

原本協力者:  Izeta Delic、Mohan Doddaramaiah

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

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

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

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

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

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

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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

このガイドにおける新機能と変更された機能

- リリース11g (11.1.1.9)の新機能と変更された機能

- リリース11g (11.1.1.8)の新機能と変更された機能

- 11g リリース1 (11.1.1)に関するこのドキュメントにおけるその他の大きな変更

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

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

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

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

- 1.1.3 Oracle Web層ノードについて

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

- 1.1.5 データ層について

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

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

- 1.3 クロックの同期

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

- 1.5 ポリシー・ストアとしてのLDAP認証プロバイダについて

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

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

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

- 1.6.3 エンタープライズ・デプロイメントへの増分、モジュラ・アプローチ

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

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

- 2.2 Oracle WebCenter Contentについて

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

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

- 2.4.1 組込みセキュリティ

- 2.4.2 高可用性

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

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

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

- 3.2.1 admin.example.com

- 3.2.2 wcc.example.com

- 3.2.3 wccinternal.example.com

- 3.2.4 ucminternal.example.com

- 3.3 ロード・バランサ

- 3.3.1 ロード・バランサの要件について

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

- 3.4 IPアドレスおよび仮想IPアドレス

- 3.5 ファイアウォールとポート

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

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

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

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

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

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

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

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

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

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

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

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

- 4.4.3 参照トポロジでのディレクトリの場所

- 4.4.3.1 Oracle WebCenter Contentドメインのディレクトリの場所

- 4.4.3.2 WebCenter Contentユーザー・インタフェース・ドメインのディレクトリの場所

- 4.5 共有記憶域の構成

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

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

- 5.2 データベース要件

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

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

- 5.2.3 初期化パラメータ

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

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

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

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

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

6 エンタープライズ・デプロイメント用のサーバーの準備

- 6.1 サーバーの準備の概要

- 6.2 サーバーおよびオペレーティング・システムの検証

- 6.3 最小ハードウェア要件の達成

- 6.4 オペレーティング・システム要件の達成

- 6.4.1 UNIXまたはLinuxシステムでのカーネル・パラメータの構成

- 6.4.2 UNIXまたはLinuxシステムでのオープン・ファイル制限の設定

- 6.4.3 UNIXまたはLinuxシステムでのシェル制限の設定

- 6.4.4 UNIXまたはLinuxシステムでのローカルHostsファイルの構成

- 6.5 Unicodeサポートの有効化

- 6.6 仮想IPアドレスの有効化

- 6.6.1 有効化する仮想IPアドレスの決定

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

- 6.7 ユーザーおよびグループの構成

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

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

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

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

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

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

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

- 7.3.1 Middlewareホーム・ディレクトリの作成

- 7.3.2 MiddlewareホームへのOracle JRockitのインストール

- 7.3.3 Oracle WebLogic Serverのインストール

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

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

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

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

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

- 8.1 ドメイン作成の概要

- 8.2 WCCHOST1でのVIP1の有効化

- 8.3 WCCHOST1での構成ウィザードを使用したドメインの作成

- 8.4 ドメインでの構成後タスクおよび検証タスクの実行

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

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

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

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

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

- 8.4.6 WCCHOST2のMiddlewareホームへのドメイン・レジストリ・ファイルのコピー

- 8.5 Oracle DatabaseのOPSSセキュリティ・ストアとドメインの再関連付け

- 8.5.1 ドメインとデータベース・ベースのOPSSセキュリティ・ストアの再関連付けの準備

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

- 8.5.1.2 Oracle DatabaseでのOPSSスキーマの確認

- 8.5.2 ファイルベースOPSSセキュリティ・ストアとデータベース・ベースOPSSセキュリティ・ストアの再関連付け

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

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

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

- 9.1 Oracle Web層構成の概要

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

- 9.3 インストールの検証

- 9.4 Oracle HTTP Serverでのロード・バランサの構成

- 9.5 仮想ホストの定義

- 9.5.1 *_vh.confファイルの作成による<VirtualHost>ディレクティブの定義

- 9.5.2 構成の検証

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

- 9.6.1 管理サーバー用のOracle HTTP Serverの構成

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

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

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

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

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

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

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

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

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

- 10.4.2 WLS_WCC1およびWLS_WCC2へのドメイン構成の伝播

- 10.4.3 WLS_WCC1管理対象サーバーの起動とコンテンツ・サーバーの構成

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

- 10.4.5 WLS_WCC2管理対象サーバーの起動とコンテンツ・サーバーの構成

- 10.4.6 WebCenter ContentのGridLinkデータ・ソースの検証

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

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

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

- 10.6 WebCenter Contentクラスタと使用するOracle HTTP Serverの構成

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

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

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

- 10.7 WLS_WCC管理対象サーバーのノード・マネージャの構成

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

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

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

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

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

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

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

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

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

- 11.5.1 Inbound Refineryの設定の構成

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

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

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

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

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

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

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

- 11.7 WLS_IBR管理対象サーバー用のノード・マネージャの構成

12 Oracle SOA Suiteコンポーネントを追加するためのドメインの拡張

- 12.1 Oracle SOA Suiteコンポーネントを追加するためのドメインの拡張の概要

- 12.2 WCCHOST1でのVIP2およびWCCHOST2でのVIP3の有効化

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

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

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

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

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

- 12.6 Oracle SOA Suite用の構成後タスクおよび検証タスクの実行

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

- 12.6.2 WLS_SOA1およびWLS_SOA2へのドメイン構成の伝播

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

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

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

- 12.7 Oracle Web Services Manager用のJavaオブジェクト・キャッシュの構成

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

- 12.8.1 WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成

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

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

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

- 12.10 WLS_SOA管理対象サーバー用のノード・マネージャの構成

- 12.11 WLS_SOA管理対象サーバー用のサーバー移行の構成

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

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

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

- 13.2 WCCHOST1でのVIP4およびWCCHOST2でのVIP5の有効化

- 13.3 Imagingを使用したドメインの拡張

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

- 13.5 Imaging用の構成後タスクおよび検証タスクの実行

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

- 13.5.2 WLS_IMG1およびWLS_IMG2へのドメイン構成の伝播

- 13.5.3 Imaging用のJMS永続ストアの構成

- 13.5.4 Imaging管理対象サーバーの起動

- 13.5.5 ImagingのGridLinkデータ・ソースの検証

- 13.5.6 Imagingビューア・キャッシュのデプロイメントの検証

- 13.5.7 Imaging用のシステムMBeanの構成

- 13.5.8 Oracle WebCenter ContentにおけるImaging機能セットの有効化

- 13.5.9 Imagingビューア・キャッシュの構成

- 13.5.10 キャッシュされたドキュメントの暗号化

- 13.5.11 Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加

- 13.5.12 コンテンツ・サーバーへの接続の作成

- 13.5.13 BPEL CSF資格証明の構成

- 13.5.14 ワークフロー接続の構成

- 13.6 Imagingクラスタと使用するOracle HTTP Serverの構成

- 13.6.1 WLS_IMG管理対象サーバー用のOracle HTTP Serverの構成

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

- 13.7 WLS_IMG管理対象サーバーのノード・マネージャの構成

- 13.8 WLS_IMG管理対象サーバー用のサーバー移行の構成

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

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

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

- 14.2 WCCHOST1でのVIP6およびWCCHOST2でのVIP7の有効化

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

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

- 14.5 Capture用の構成後タスクおよび検証タスクの実行

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

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

- 14.5.3 Captureの初期構成の実行

- 14.5.3.1 Captureの初期構成の実行について

- 14.5.3.2 Capture管理対象サーバーの起動

- 14.5.3.3 キャプチャ・ユーザーへのロールの割当て

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

- 14.5.4 CaptureのGridLinkデータ・ソースの検証

- 14.5.5 Capture用のJMS永続ストアの構成

- 14.5.6 Oracle WebCenter Contentで許可されたホストのリストに対するCaptureサーバーのリスニング・アドレスの追加

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

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

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

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

- 14.7 WLS_CPT管理対象サーバー用のノード・マネージャの構成

- 14.8 WLS_CPT管理対象サーバー用のサーバー移行の構成

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

15 WebCenter Contentユーザー・インタフェースのインストールおよび構成

- 15.1 WebCenter Contentユーザー・インタフェースのインストールおよび構成について

- 15.2 WebCenter Contentユーザー・インタフェースのインストールおよび構成の準備

- 15.2.1 WebCenter Contentユーザー・インタフェース・コンポーネントの有効化

- 15.2.2 Remote Intradoc Client (RIDC)の設定

- 15.2.3 追加のコンテンツ・サーバーのパラメータの設定

- 15.2.4 フルテキスト検索の有効化

- 15.2.5 サムネイルおよびWeb表示可能レンディションの生成

- 15.2.6 コンテンツ・サーバーでの拡張機能の構成

- 15.3 11.1.1.6.0 MiddlewareホームとOracle ADF 11.1.2のインストール

- 15.4 WebCenter Contentユーザー・インタフェース・アプリケーションのインストール

- 15.5 WebCenter Contentユーザー・インタフェース・アプリケーションの新しいドメインへのデプロイ

- 15.5.1 MDSリポジトリの登録

- 15.5.2 WCCUIHOST1での構成ウィザードを使用したドメインの作成

- 15.5.3 ドメインでの構成後タスクおよび検証タスクの実行

- 15.5.3.1 Oracle ADF共有ライブラリのSherman Update 2へのアップグレード

- 15.5.3.2 WCCUIHOST1での管理サーバー用boot.propertiesの作成

- 15.5.3.3 WCCUIHOST1でのノード・マネージャの起動

- 15.5.3.4 WCCUIHOST1での管理サーバーの起動

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

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

- 15.5.3.7 WCCUIHOST2のMiddlewareホームへのドメイン・レジストリ・ファイルのコピー

- 15.5.4 WCCUI管理対象サーバーのMDSへの登録およびメタデータ・パーティションの作成

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

- 15.5.6 WebCenter Contentユーザー・インタフェースとコンテンツ・サーバーの関連付け

- 15.6 管理者ユーザーの構成

- 15.7 WebCenter Contentユーザー・インタフェースへのアクセス

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

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

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

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

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

- 16.1 ノード・マネージャの設定の概要

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

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

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

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

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

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

- 16.3.5 カスタム・キーストアを使用するための管理対象サーバーの構成

- 16.3.6 管理対象サーバーのホスト名検証設定の変更

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

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

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

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

- 17.3 管理コンソールを使用したleasingのGridLinkデータ・ソースの作成

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

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

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

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

18 Oracle Identity Managementとの統合

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

- 18.2 アイデンティティ・ストアと外部LDAP認証プロバイダの再関連付け

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

- 18.2.2 LDAP認証プロバイダの作成

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

- 18.2.4 LDAPアイデンティティ・ストアへのWebLogic Server管理者の移動

- 18.2.4.1 LDAPディレクトリへの管理ユーザーと管理グループのプロビジョニング

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

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

- 18.2.5 新しいアイデンティティ・ストアのImagingセキュリティの再設定

- 18.2.5.1 WLSTを使用してImagingセキュリティ表でGUID値をリフレッシュ

- 18.2.5.2 Fusion Middleware Controlを使用してImagingセキュリティ表のGUID値をリフレッシュ

- 18.2.6 Enterprise Captureロールを持つシステム管理者のLDAPへの追加

- 18.3 Oracle Access Manager 11gとの統合

- 18.3.1 Oracle Access Managerの統合の概要

- 18.3.2 Oracle Access Managerの前提条件

- 18.3.3 Webゲート・エージェントの登録

- 18.3.3.1 RREGツールの解凍および使用

- 18.3.3.2 Oracle Access Manager 11gリクエスト・ファイルの更新

- 18.3.3.3 oamregツールの実行

- 18.3.3.4 基本認証スキームを使用するためのinspection.wsilリソースの変更

- 18.3.3.5 Cookieを使用しない基本スキームをサポートするためのOracle Access Manager 11g Server構成の更新

- 18.3.4 Webゲートの設定

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

- 18.3.4.2 Webゲートのインストール

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

- 18.3.5 OAM Webゲート登録から生成されたファイルおよびアーティファクトのWebゲート・インスタンスの場所へのコピー

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

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

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

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

- 18.4 ロード・バランサおよびSSOを介したアクセスの検証

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

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

- 19.1 Oracle WebCenter Contentトポロジの管理の概要

- 19.2 Imagingの入力ファイルを最適化する戦略の定義

- 19.3 Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジ内でのコンポジットおよびアーティファクトのデプロイ

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

- 19.5 Oracle WebCenter Content: ImagingのUMSドライバの構成

- 19.6 Oracle WebCenter Contentトポロジのスケール・アップ

- 19.6.1 WebCenter Contentのスケール・アップ手順

- 19.6.2 Oracle WebCenter Content: Imagingのスケール・アップ手順

- 19.6.3 Oracle WebCenter Enterprise Captureのスケール・アップ手順

- 19.6.4 Oracle SOA Suiteのスケール・アップ手順

- 19.7 Oracle WebCenter Contentトポロジのスケール・アウト

- 19.7.1 WebCenter Contentのスケール・アウト手順

- 19.7.2 Oracle WebCenter Content: Imagingのスケール・アウト手順

- 19.7.3 Oracle WebCenter Enterprise Captureのスケール・アウト手順

- 19.7.4 Oracle SOA Suiteのスケール・アウト手順

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

- 19.8.1 前提条件および手順

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

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

- 19.9 Oracle WebCenter Contentエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行

- 19.10 Oracle DatabaseでのOPSSセキュリティ・ストアの保持

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

- 19.12 Oracle WebCenter ContentとImagingサービスで使用するOracle Web Service Managerのセキュリティ・ポリシーの構成

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

- 19.13.1 soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する

- 19.13.2 デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)

- 19.13.3 データベース内の最大プロセス数に達したために、WebCenter Contentサーバー、Oracle SOA SuiteサーバーまたはImagingサーバーの起動に失敗する

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

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

- 19.13.6 サーバー移行後にSOAサーバー、ImagingサーバーまたはCaptureサーバーがフェイルオーバーしない

- 19.13.7 サーバー移行後にSOAサーバー、ImagingサーバーまたはCaptureサーバーにブラウザからアクセスできない

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

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

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

- 19.13.11 構成されたJOCポートがすでに使用中

- 19.13.12 CredentialAccessPermissionsを使用することで、Oracle WebCenter Content: Imagingが資格証明ストアから資格証明を読み取ることが可能になる

- 19.13.13 Oracle WebCenter Content: ImagingからOracle WebCenter Contentに情報量の多いドキュメントをアップロードする際のパフォーマンスを向上させる

- 19.13.14 管理対象サーバーのメモリー不足の問題

- 19.13.15 Oracle WebCenter Content管理対象サーバーのマスター・パスワードを再生成する

- 19.13.16 WebLogic Server管理コンソールからログアウトしても、ユーザー・セッションが終了しない

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

- 19.13.18 ファイルのキャッシュとロック

- 19.13.19 リモートでデプロイされたアプリケーションで使用するアップロード・ディレクトリおよびステージ・ディレクトリの変更

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

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

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

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

- B.1 WebCenter Content管理対象サーバーで使用するアプリケーションとリソース

- B.2 Inbound Refinery管理対象サーバーで使用するアプリケーションとリソース

- B.3 Oracle SOA Suite管理対象サーバーで使用するアプリケーションとリソース

- B.4 Imaging管理対象サーバーで使用するアプリケーションとリソース

- B.5 Capture管理対象サーバーで使用するアプリケーションとリソース

- B.6 管理サーバーで使用するアプリケーションとリソース

索引

図一覧

- 1-1 Oracle WebCenter Contentの参照用トポロジ

- 1-2 Oracle WebCenter Contentユーザー・インタフェースの参照トポロジ

- 1-3 Oracle WebCenter Contentエンタープライズ・デプロイメント・プロセス

- 3-1 管理サーバーと管理対象サーバーにマップされるIPアドレスと仮想IPアドレス

- 図4-1 製品バイナリおよびASERVERドメイン・ディレクトリのファイル・レイアウト(共有記憶域)

- 4-2 MSERVERドメイン・ディレクトリのファイル・レイアウト

- 4-3 ローカル記憶域のWeb層インスタンス・ディレクトリのファイル・レイアウト

- 図4-4 WebCenter Contentユーザー・インタフェースの製品バイナリおよびASERVERドメイン・ディレクトリのファイル・レイアウト(共有記憶域)

- 4-5 WebCenter Contentユーザー・インタフェースのMSERVERドメイン・ディレクトリのファイル・レイアウト

- 5-1 「データベース接続の詳細」画面

- 5-2 「コンポーネントの選択」画面

- 5-3 「スキーマ・パスワード」画面

- 7-1 インストール・ウィザードの「インストール場所の指定」画面

- 8-1 「ドメイン・ソースの選択」画面

- 8-2 OPSSの「JDBCコンポーネント・スキーマの構成」画面

- 8-3 OPSSの「GridLink RACコンポーネント・スキーマの構成」画面

- 8-4 OPSSの「JDBCコンポーネント・スキーマのテスト」画面

- 8-5 Oracle Databaseセキュリティ・プロバイダ

- 10-1 WebCenter Contentの「拡張ソースの選択」画面

- 10-2 WebCenter Contentの「JDBCコンポーネント・スキーマの構成」画面

- 10-3 WebCenter Contentの「GridLink RACコンポーネント・スキーマの構成」画面

- 10-4 WebCenter Contentの「JDBCコンポーネント・スキーマのテスト」画面

- 10-5 WebCenter Contentの「管理対象サーバーの構成」画面

- 10-6 WebCenter Contentの「クラスタの構成」画面

- 10-7 WebCenter Contentの「サーバーのマシンへの割当」画面

- 10-8 サービスのWebCenter Contentクラスタへのターゲット設定

- 10-9 WebCenter ContentのGridLinkデータ・ソースのテスト

- 10-10 WebCenter ContentのONS構成のテスト

- 11-1 Inbound Refineryの「拡張ソースの選択」画面

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

- 11-3 Inbound Refineryサーバーのサーバー・グループへの割当て

- 11-4 Inbound Refineryサーバーのマシンへの割当て

- 11-5 サービスのInbound Refineryへのターゲット設定

- 12-1 Oracle SOA Suiteの「拡張ソースの選択」画面

- 12-2 Oracle SOA Suiteの「JDBCコンポーネント・スキーマの構成」画面

- 12-3 Oracle SOA Suiteの「GridLink RACコンポーネント・スキーマの構成」画面

- 12-4 Oracle SOA Suiteの「JDBCコンポーネント・スキーマのテスト」画面

- 12-5 サービスのSOAクラスタへのターゲット設定

- 12-6 SOAクラスタのJMSファイル・ストア

- 12-7 管理コンソールの「サーバーの起動」タブを使用したホスト名の設定

- 12-8 Oracle SOA SuiteのGridLinkデータ・ソースのテスト

- 12-9 Oracle SOA SuiteのONS構成のテスト

- 13-1 Imagingの「拡張ソースの選択」画面

- 13-2 Imagingの「JDBCコンポーネント・スキーマの構成」画面

- 13-3 Imagingの「GridLink RACコンポーネント・スキーマの構成」画面

- 13-4 Imagingの「JDBCコンポーネント・スキーマのテスト」画面

- 13-5 デプロイメントのImagingクラスタへのターゲット設定

- 13-6 ImagingのGridLinkデータ・ソースのテスト

- 13-7 ImagingのONS構成のテスト

- 13-8 システムMBeanブラウザ

- 14-1 Captureの「拡張ソースの選択」画面

- 14-2 Captureの「JDBCコンポーネント・スキーマの構成」画面

- 14-3 Captureの「GridLink RACコンポーネント・スキーマの構成」画面

- 14-4 Captureの「JDBCコンポーネント・スキーマのテスト」画面

- 14-5 サービスのCaptureクラスタへのターゲット設定

- 14-6 Captureのアプリケーション・ロール

- 14-7 CaptureのGridLinkデータ・ソースのテスト

- 14-8 CaptureのONS構成のテスト

- 15-1 WebCenter Contentユーザー・インタフェースの「ドメイン・ソースの選択」

- 15-2 WLS_WCCUI管理対象サーバーの構成画面

- 15-3 WCCUI_Clusterの「クラスタの構成」画面

- 15-4 管理対象サーバーのWCCUI_Clusterへの割当て

- 15-5 WCCUIホストの「マシンの構成」画面

- 15-6 WCCUIサーバーのマシンへの割当て

- 15-7 「WCCUIDomain」ページの「WebLogicドメイン」メニュー

- 15-8 「メタデータ・リポジトリ」ページ

- 15-9 MDSリポジトリの登録

- 15-10 リポジトリのWCCUI_Clusterへのターゲット設定

- 17-1 管理コンソールの「移行ステータス」画面

- A-1 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

表一覧

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

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

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

- 3-1 仮想IPアドレスにマップされる仮想ホスト

- 3-2 使用されるポート

- 4-1 Oracle WebCenter Contentドメインにあるアプリケーション層のディレクトリ変数

- 4-2 Oracle Web層のディレクトリ変数

- 4-3 WebCenter Contentユーザー・インタフェース・ドメインにあるアプリケーション層のディレクトリ変数

- 4-4 Oracle WebCenter Contentドメインの共有記憶域の内

- 4-5 WebCenter Contentユーザー・インタフェース・ドメインの共有記憶域の内容

- 5-1 データベースとスキーマ間のマッピング

- 5-2 必要な初期化パラメータ

- 5-3 Oracle WebCenter ContentトポロジのRCUコンポーネント

- 6-1 ホスト・マシン

- 6-2 UNIXのカーネル・パラメータ

- 6-3 ドメインの仮想ホスト

- 7-1 ホストにインストールするソフトウェアまたは各ホストからアクセスできる必要があるソフトウェア

- 8-1 WebLogic Serverドメインの作成手順

- 8-2 ドメインの仮想ホスト

- 8-3 管理サーバー用のマシン

- 10-1 WebCenter Contentを含むドメインの拡張手順

- 10-2 WebCenter Contentの管理対象サーバー

- 10-3 WebCenter Contentのクラスタ構成

- 10-4 WebCenter Contentのマシン

- 11-1 Inbound Refineryを使用するためのドメインの拡張手順

- 11-2 Inbound Refineryの管理対象サーバー

- 11-3 Inbound Refineryサーバーの管理用の構成

- 12-1 Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張手順

- 12-2 Oracle SOA Suiteの管理対象サーバー

- 12-3 Oracle SOA Suiteのクラスタ構成

- 13-1 Imagingを含むドメインの拡張手順

- 13-2 Imagingの管理対象サーバー

- 13-3 Imagingのクラスタ構成

- 13-4 マシンおよびノード・マネージャのリスニング・アドレス

- 14-1 Captureを使用するためのドメインの拡張手順

- 14-2 Captureの管理対象サーバー

- 14-3 Captureのクラスタ構成

- 14-4 マシンおよびノード・マネージャのリスニング・アドレス

- 16-1 ノード・マネージャの設定手順

- 17-1 サーバー移行構成の手順

- 17-2 PATH環境変数に必要なファイル

- 18-1 Oracle Identity Management 11gとの統合手順

- 18-2 LinuxおよびSolarisシステムのGCCサードパーティ製ライブラリのバージョン

- 19-1 Oracle WebCenter Contentトポロジを管理するためのタスク

- 19-2 Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト

- 19-3 Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト

はじめに

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

対象読者

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

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

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

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

関連ドキュメント

このガイドでは詳細は、次のOracle Fusion Middlewareドキュメントを参照しています。

- Oracle WebCenter Enterprise Captureの管理

- Oracle WebCenter Contentの管理

- Oracle Fusion Middleware Oracle WebCenter Content: Imagingの管理

- 管理者ガイド

- Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

- Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド

- Oracle Platform Security Servicesによるアプリケーションの保護

- Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理

- Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成

- Oracle Fusion Middleware Oracle WebCenter Content: Imagingの開発

- Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド

- Oracle Fusion Middleware高可用性ガイド

- Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド

- Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド

- Oracle Fusion Middlewareインストレーション・プランニング・ガイド

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

- Oracle Fusion Middleware Oracle WebCenter Contentの管理

- Oracle Fusion Middleware Oracle Identity Managementリファレンス

- Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド

- Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド

- Oracle Fusion Middleware Oracle WebCenter Contentの使用方法

- Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用ガイド

また、このガイドでは詳細は、次のドキュメントも参照しています。

- Oracle Coherence開発者ガイド

- Oracle Database管理者ガイド

- Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド

- 『Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解』

- 『Oracle Grid Infrastructureインストレーション・ガイド』

- Oracle Real Application Clusters管理およびデプロイメント・ガイド

- Oracle Real Application Clustersインストレーション・ガイド for Linux and UNIX Systems

- Oracle Universal InstallerおよびOpatchユーザーズ・ガイド

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

このガイドにおける新機能と変更された機能

次のトピックでは、Oracle WebCenter Contentの新機能と変更された機能について、およびこのガイドに記載されるその他の重要な変更について、詳細情報への相互参照とともに紹介します。

リリース11g (11.1.1.9)の新機能と変更された機能

この項では、Oracle WebCenter Content 11g (11.1.1.9)の次の新機能と変更された機能について説明します。

- WebCenter Contentユーザー・インタフェースおよびネイティブ11gユーザー・インタフェースの設定方法に関する情報が追加されました。Oracle WebCenter Content Server用のこのインタフェースは、Oracle Application Development Framework (Oracle ADF)に基づいています。第15章「WebCenter Contentユーザー・インタフェースのインストールおよび構成」を参照してください。

- 現在、ポリシーおよび資格証明を含めセキュリティ・アーティファクトに望ましいタイプのセキュリティ・ストアは、Oracle Database 11g Release 2 (11.2.0.1以降)では、Oracle Internet Directoryではなく、Oracle Platform Security Services (OPSS)です。かわりに、Oracle Internet Directoryまたは別のLightweight Directory Application Protocol (LDAP)プロバイダを使用できます。第8章「エンタープライズ・デプロイメント用のドメインの作成」を参照してください。

- Oracle WebCenter CaptureはOracle WebCenter Enterprise Captureに再ブランディングされました。

リリース11g (11.1.1.8)の新機能と変更された機能

この項では、Oracle WebCenter Content 11g (11.1.1.8)の次の新機能と変更された機能について説明します。

- Oracle WebCenter Enterprise Capture。集中環境または分散環境の企業においてスケーラブルなドキュメント・キャプチャを提供し、新しい管理対象サーバーを使用してOracle WebCenter Contentドメインを拡張します。
Captureについては次の項を参照してください。

- 第2.2項「Oracle WebCenter Contentについて」

- 第3.4項「IPアドレスおよび仮想IPアドレス」

- 第4.5項「共有記憶域の構成」

- 第5.4項「データベース・スキーマの作成」

- 第7.3.4.1項「Oracle WebCenter Contentのインストール」

- 第10.7項「WLS_WCC管理対象サーバー用のノード・マネージャの構成」

- 第14章「Captureを追加するためのドメインの拡張」

- 第17.6項「サーバー移行ターゲットの構成」

- 第18.4項「ロード・バランサおよびSSOを介したアクセスの検証」

- 第19.6.3項「Oracle WebCenter Enterprise Captureのスケール・アップ手順」

- 第19.7.3項「Oracle WebCenter Enterprise Captureのスケール・アウト手順」

- 第19.9項「Oracle WebCenter Contentエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」

- 第11.5.4.2項「コンテンツ・サーバーでのInbound Refinery用のコンポーネントの有効化」

- 付録B.5「Capture管理対象サーバーで使用するアプリケーションとリソース」

- Oracle WebCenter Content Serverにおける管理サーバー・インタフェースの変更。次の項を参照してください。

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

- 第10.4.8項「Oracle WebCenter Contentのサービス再試行の構成」

- 第13.5.8項「Oracle WebCenter ContentにおけるImaging機能セットの有効化」

11g リリース1 (11.1.1)に関するこのドキュメントにおけるその他の大きな変更

11gリリース1 (11.1.1)について、このガイドの構成が変更され、内容が更新されています。

- トポロジの変更によりSOAHOST1ホストおよびSOAHOST2ホストが除外されました。Oracle SOA Suite管理対象サーバーは他の管理対象サーバーと同じ2つのホスト・マシン(WCCHOST1およびWCCHOST2)にインストールされ、構成されます。第1.1項「エンタープライズ・デプロイメントの参照用トポロジの概要」を参照してください。

- Oracle WebCenter Contentにより焦点を合せるために、管理対象サーバーを使用したドメインの拡張順序が変更されました。第1.6項「参照用トポロジのインストールおよび構成のロードマップ」を参照してください。

- 外部LDAPプロバイダへのポリシー・ストアとアイデンティティ・ストアの再関連付けが新しい章(すべてのドメイン拡張の前)に移りました。第8章「エンタープライズ・デプロイメント用のドメインの作成」を参照してください。

- 他の製品のOracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドと一貫性を保つために、一部の章が改訂されました。第3章「エンタープライズ・デプロイメント用のネットワークの準備」および第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」を参照してください。

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

この章では、このガイドで使用するエンタープライズ・デプロイメントの参照用トポロジについて具体的に説明します。インストールおよび構成のロードマップによって、実行する必要のあるタスクに対応する章を参照できます。この章を利用することで、Oracle WebCenter Contentエンタープライズ・デプロイメントの計画を立案できます。

この章には次の項が含まれます:

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

- 第1.2項「Linuxシステムにおけるエンタープライズ・デプロイメントのハードウェア要件」

- 第1.3項「クロックの同期」

- 第1.4項「インストールするソフトウェア・コンポーネント」

- 第1.5項「ポリシー・ストアとしてのLDAP認証プロバイダについて」

- 第1.6項「参照用トポロジのインストールおよび構成のロードマップ」

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

図1-1のダイアグラムは、このガイドで使用するエンタープライズ・デプロイメントの参照用トポロジを示しています。このダイアグラムと次の項の情報を使用して、エンタープライズ・デプロイメント・トポロジを計画します。

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

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

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

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

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

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

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

このガイドは、図1-1で示すように、Oracle WebCenter ContentおよびOracle SOA SuiteとOracle Access Managerを併用して参照用エンタープライズ・トポロジを構成する手順について説明します。

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

図1-1「Oracle WebCenter Contentの参照用トポロジ」

注意:
Oracle SOA Suiteは、エンタープライズ・デプロイメント・トポロジにOracle WebCenter Content: Imagingを追加する場合にのみ必要になります。

WebCenter Contentユーザー・インタフェースのドメインは、より新しいバージョンのOracle Application Development Framework (Oracle ADF)テクノロジ・スタック(11.1.2.4.0)を使用するため、独自のMiddlewareホームが必要です。2つのMiddlewareホームおよびドメインは、同じホストまたは別のホスト上に存在できます。図1-2に、Oracle WebCenter Contentユーザー・インタフェースの参照トポロジを示します。

図1-2 Oracle WebCenter Contentユーザー・インタフェースの参照トポロジ

1.1.2 Oracle Identity Managementの統合について

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

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

1.1.3 Oracle Web層ノードについて

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

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

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

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

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

ロード・バランサの要件

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

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

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

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

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

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

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

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

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

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

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

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

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

アプリケーション層のノードはDMZセキュア・ゾーンにあります。この層では、2つのノード(WCCHOST1とWCCHOST2)でOracle WebLogic Serverを実行し、これらのOracle WebLogic Serverは、WebCenter Content、Oracle WebCenter Content: Imaging (AXF for BPELおよびAXF for BPMを含む)、Oracle WebCenter Enterprise Capture、Oracle WebCenter Content: Inbound Refinery、およびOracle SOA Suiteのコンポーネント(Oracle BPEL Process Managerなど)を実行する管理対象サーバーとともに構成します。管理対象サーバーは、アクティブ/アクティブで構成されます(Inbound Refineryは除く)。

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

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

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

1.1.5 データ層について

データ層のノードは、最もセキュアなネットワーク・ゾーン(イントラネット)に配置されます。この層では、Oracle Real Application Clusters (RAC)データベースが、ノードWCCDBHOST1およびWCCDBHOST2で実行されます。このデータベースには、Oracle SOA SuiteおよびOracle WebCenter Contentコンポーネントに必要なスキーマが含まれています。アプリケーション層で実行されるOracle WebCenter ContentおよびOracle SOA Suiteコンポーネントがこのデータベースにアクセスします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サーバー

ディスク

メモリー

TMPディレクトリ

スワップ

データベース

nXm

n = ディスクの数、少なくとも4 (1つのディスクとしてストライプされます)
m = ディスクのサイズ(最低30 GB)

6から8GB

デフォルト

デフォルト

WEBHOSTn

10GB

4GB

デフォルト

デフォルト

WCCHOSTn

20GB

10GB

デフォルト

デフォルト

注意:

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

- WebCenter Content、ImagingおよびInbound Refineryの管理対象サーバーでは、各管理対象サーバーが実行するJava仮想マシン(JVM)に割り当てられたヒープのサイズを少なくとも1 GB (1024MB)に増加する必要があります。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』の管理対象サーバーのJava VMヒープ・サイズの増加に関する項を参照してください。

1.3 クロックの同期

クラスタに参加しているすべてのサーバーのクロックは、ジョブやアダプタが適切に機能できるように1秒以内の誤差で同期される必要があります。これを実現するには、ネットワーク・タイム・サーバーを1つ使用して、各サーバーがそのネットワーク・タイム・サーバーを参照するようにします。

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

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

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

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

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

コンポーネント

詳細

Oracle Database 11g

Oracle Database 11g (11.1.0.7以降、Standard EditionまたはEnterprise Edition)、AL32UTF8文字セットの使用

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

Repository Creation Utility (RCU)

Oracle Fusion Middlewareリポジトリ作成ユーティリティ11g (11.1.1.9)

Oracle WebLogic Server

Oracle WebLogic Server (10.3.6)

Oracle HTTP Server (OHS)

Oracle Web Tier 11g (11.1.1.7)

Oracle WebCenter Content

Oracle WebCenter Content 11g (11.1.1.9)

Oracle SOA Suite

Oracle SOA Suite 11g (11.1.1.7)

Oracle Access Manager Webゲート

Oracle Access Manager 11gの場合、WebGate 11g (11.1.1.2以降)

Oracle Internet Directory

Oracle Identity and Access Management 11g (11.1.1.5以降)

1.5 ポリシー・ストアとしてのLDAP認証プロバイダについて

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

Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジでは、管理サーバーや管理対象サーバーで異なるドメイン・ホームを使用します(第4.4項「各種ディレクトリの推奨場所」を参照)。これに伴い、また統合性や一貫性を考慮し、Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジでは、LDAPサーバーをポリシー・ストアとして使用する必要があります。LDAP認証プロバイダをポリシー・ストアに使用してOracle WebCenter Contentエンタープライズ・デプロイメントを構成するには、第8章「エンタープライズ・デプロイメント用のドメインの作成」の手順を実行します。

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

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

このドキュメントでは、oracleは、エンタープライズ・デプロイメントの参照トポロジをインストールおよび構成するためのオペレーティング・システムのユーザーIDです。

次の項では、Oracle WebCenter Contentの参照用トポロジをインストールおよび構成する際のロードマップについて説明します。

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

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

- 第1.6.3項「エンタープライズ・デプロイメントへの増分、モジュラ・アプローチ」

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

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

図1-3 Oracle WebCenter Contentエンタープライズ・デプロイメント・プロセス

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

表1-3は、図1-3に示すOracle WebCenter Contentのエンタープライズ・デプロイメント・プロセスのフロー・チャートの各手順について説明しています。また、この表では、このプロセスにおける各手順の詳細への参照先が示されています。

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

手順

説明

詳細

トポロジおよび要件の確認

Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジに関する情報とその設定に必要な要件について、この章の前の項を確認します。

第1章「エンタープライズ・デプロイメント参照用トポロジの紹介」

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

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

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

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

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

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

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

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

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

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

エンタープライズ・デプロイメント用のサーバーを準備するには、サーバーおよびオペレーティング・システムでハードウェアおよびオペレーティング・システムの最小要件が満たされていること、Unicodeサポートと仮想IPアドレスが有効になっていること、共有記憶域がホストにマウントされていること、ユーザーとグループが構成されていることを確認する必要があります。

第6章「エンタープライズ・デプロイメント用のサーバーの準備」

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

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

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

Oracle Web層の構成

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

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

ドメインの作成

Fusion Middleware構成ウィザードを実行してドメインを作成します。

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

セキュリティ・ストアとOPSSデータベース・ベース・セキュリティ・ストアの再関連付け

Oracle Databaseでドメインのデフォルト・ファイルベース・セキュリティ・ストアをOPSSデータベース・ベース・セキュリティ・ストアに再関連付けします。セキュリティ・ストアにはセキュリティ・アーティファクト(ポリシー、資格証明およびキーなど)が含まれます。

第8章「Oracle DatabaseのOPSSセキュリティ・ストアとドメインの再関連付け」

WebCenter Contentによるドメインの拡張

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

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

IBRによるドメインの拡張(オプション)

Fusion Middleware構成ウィザードを実行し、Inbound Refineryを構成して、既存のWebLogic Serverドメインを拡張します。

第11項「Inbound Refineryを追加するためのドメインの拡張」

SOAによるドメインの拡張(オプション)

既存のWebLogic ServerドメインをImagingで拡張するには、まずFusion Middleware構成ウィザードを実行してOracle SOA Suiteを構成し、そのドメインを拡張します。

第12章「Oracle SOA Suiteコンポーネントを追加するためのドメインの拡張」

Imagingによるドメインの拡張(オプション)

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

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

Captureによるドメインの拡張(オプション)

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

第14章「Captureを追加するためのドメインの拡張」

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

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

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

WebCenter Contentユーザー・インタフェースのインストールおよび構成(オプション)

Oracle ADFに基づいて、Oracle WebCenter Content管理対象サーバーにOracle WebCenter Content ServerのWebCenter Contentユーザー・インタフェースをインストールおよび構成します。

第15項「WebCenter Contentユーザー・インタフェースのインストールと構成について」

サーバー移行の構成(オプション)

管理対象サーバーWLS_IMGn、WLS_CPTnおよびWLS_SOAnに対してサーバー移行を構成します。管理対象サーバーWLS_IMG1、WLS_CPT1およびWLS_SOA1は、障害発生時にWCCHOST2上で再起動されるように構成されます。管理対象サーバーWLS_IMG2、WLS_CPT2およびWLS_SOA2は、障害発生時にWCCHOST1上で再起動されるように構成されます。

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

OAMおよびIDMとの統合(オプション)

シングル・サインオン(SSO)を使用する場合は、Oracle WebCenter Contentエンタープライズ・デプロイメントをOracle Access Manager 11gと統合できます。

第18項「Oracle Identity Managementとの統合」

1.6.3 エンタープライズ・デプロイメントへの増分、モジュラ・アプローチ

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

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

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

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

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

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

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

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

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

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

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

この章には次の項が含まれます:

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

- 第2.2項「Oracle WebCenter Contentについて」

- 第2.3項「エンタープライズ・デプロイメントの用語」

- 第2.4項「Oracle推奨事項のメリット」

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

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

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

- 様々な業務のサービス・レベル合意(SLA)を考慮して、高可用性ベスト・プラクティスをできるだけ広範囲に適用できるようにします。

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

- 様々な構成を対象として広範囲なパフォーマンス影響調査の結果を利用し、ビジネス・ニーズに応じて実行およびスケールできるように高可用性アーキテクチャが最適に構成されます。

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

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

高可用性の実現の詳細は、Oracle Technology NetworkのOracle MAAベスト・プラクティスのページ(http://www.oracle.com/technetwork/database/features/availability/maa-best-practices-155366.html)を参照してください。

注意:
このドキュメントではLinux環境におけるエンタープライズ・デプロイメントを中心に説明していますが、エンタープライズ・デプロイメントは、UNIX環境やWindows環境でも実現できます。

2.2 Oracle WebCenter Contentについて

Oracle WebCenter Contentスイート(以前のOracle Enterprise Content Management SuiteまたはOracle ECM)では、ビジネス環境に合せた適切な情報へのシームレスなアクセスを実現する統合コンテンツ管理を利用できます。この手段として、文章や画像、豊富なメディア・ファイルを管理するとともに、Oracle Application Extension Framework (AXF)を介して、エンタープライズ・アプリケーションとの環境統合を実現するための戦略的なコンテンツ・インフラストラクチャを組織によって実装できます。

Oracle WebCenter Contentの主なメリットは次のとおりです。

- コストの削減: プリント代、輸送費、保管費、維持費を減らします。

- 効率化: 唯一の正しい情報源、事業プロセスの合理化、より完全かつ高速な情報へのアクセスを実現します。

- リスクの軽減: 統一性と監査機能の向上、ビジネス・ポリシーおよびビジネス・ルールの遵守、コンテンツの確実な保護、ブランド管理の強化を実現します。

- 価値の創造: ビジネスの敏捷性を向上させるほか、クロスセリングとアップセリングの向上やチャネルの確保、顧客関係の向上によって売上を最適化します。

このガイドの参照用エンタープライズ・デプロイメント・トポロジには、Oracle WebCenter Contentの次の機能セットが含まれています。

- Oracle WebCenter Content

- Oracle WebCenter Content: Inbound Refinery

- Oracle WebCenter Content: Imaging

- Oracle WebCenter Enterprise Capture

Oracle WebCenter Content

WebCenter Content(以前のOracle Universal Content ManagementまたはOracle UCM)にはOracle WebCenter Content Serverが含まれています。WebCenter Contentが提供する統一リポジトリを使用すると、構造化されていないコンテンツを格納し、そのコンテンツをビジネス・ユーザーに配信できます。この配信は適切なフォーマットで行われ、またビジネス・ユーザーの業務に親和性の高いアプリケーションのコンテキスト内で行われます。

コンテンツ・サーバーがデフォルトで使用するネイティブの11gユーザー・インタフェース以外にも、WebCenter Contentユーザー・インタフェースを使用してコンテンツ・サーバーを構成できます。WebCenter Contentユーザー・インタフェースの詳細は、第15章「WebCenter Contentユーザー・インタフェースのインストールおよび構成」を参照してください。

Oracle WebCenter Content: Imaging

Imaging(以前のOracle Imaging and Process ManagementまたはOracle I/PM)は、最も包括的で、統合された、コスト・パフォーマンスの高いイメージング・プラットフォームで、エンタープライズ・ビジネス・プロセス内でのドキュメント・イメージをエンドツーエンドで管理できます。高機能なデータ・キャプチャにはOracle WebCenter Forms Recognitionを、LOBの編成やプロセス・コラボレーションにはAXFを、またイメージのキャプチャにはOracle WebCenter Enterprise Captureを活用します。また、イメージの注釈付けとマークアップ、ルーティングと承認の自動化などの機能を提供するほか、エンタープライズ用アプリケーションをサポートするスケーラブルなリポジトリを提供します。組織では、Imagingを使用して、Oracleやサード・パーティのエンタープライズ・アプリケーション内でビジネス・プロセスを迅速に自動化できます。

Oracle WebCenter Content: Inbound Refinery

Inbound Refineryは、ドキュメント、デジタル・イメージ、動画などの電子アセット用のファイル変換を管理する変換サーバーです。変換機能の他に、Inbound Refineryでは、ドキュメントとイメージに対するサムネイル機能、ビデオのストーリーボード作成機能、デジタル・イメージからEXIFデータを抽出して使用する機能、およびAdobe PhotoshopやAdobe Illustratorなどのプログラムから生成された電子ファイルからXMPデータを抽出して使用する機能があります。組織では、Inbound Refineryを使用して、Oracle WebCenter Content Serverに格納されているコンテンツ項目を変換できます。

Oracle WebCenter Enterprise Capture

Captureは、集中型企業環境にも分散型企業環境にも適した拡張性の高いドキュメント・キャプチャを提供します。Oracle WebCenter Content: ImagingおよびOracle WebCenter Contentと完全に統合されているため、きわめて重要なビジネス・コンテンツのキャプチャ、保存、管理、取得が1つのシステムで可能になります。

Oracle WebCenter Enterprise Captureには、インターネットや企業内のイントラネットを利用してリモート・ロケーションで実行可能なスキャン機能やオプションの索引付け機能があります。Captureでイメージをスキャンすると、ローカル・マシンにイメージがコピーされます。そのイメージのバッチを解放するまでは、ローカル・マシンでイメージを表示できます。その後、それらのイメージはサーバーに移動します。バッチのスキャン後、必要に応じた方法でドキュメントを編成します。ドキュメントはCaptureにインポート可能です。スキャナからドキュメントをインポートし、他のソースからアイテムを追加したら、索引を追加します。

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

このエンタープライズ・デプロイメント・ガイドで使用される用語は次のとおりです。

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

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

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

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

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

- Middlewareホーム: Middlewareホームは、Oracle WebLogic Serverホーム、および場合によっては1つ以上のOracleホームで構成されています。ミドルウェア・ホームは、ローカル・ファイル・システムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。

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

- Oracle共通ホーム: Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files (JRF)に必要なバイナリおよびライブラリ・ファイルが格納されるOracleホームです。

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

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

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

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

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

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

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

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

- AdminServerドメイン・ホーム

- JMS

- Tlogs(該当する場合)

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

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

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

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

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

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

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

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

2.4 Oracle推奨事項のメリット

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

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

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

- 第2.4.2項「高可用性」

2.4.1 組込みセキュリティ

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

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

- 外部クライアントからの通信は、必ずロード・バランシング・ルーター(LBR)を経由します。

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

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

- 一度に2つのファイアウォールをまたがる直接的な通信は禁止されています。

- あるファイアウォール・ゾーンで開始された通信は、次のファイアウォール・ゾーンで必ず終了します。

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

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

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

2.4.2 高可用性

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

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

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

この章には次の項が含まれます:

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

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

- 第3.3項「ロード・バランサ」

- 第3.4項「IPアドレスおよび仮想IPアドレス」

- 第3.5項「ファイアウォールとポート」

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

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

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

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

- 第3.2.1項「admin.example.com」

- 第3.2.項「wcc.example.com」

- 第3.2.3項「wccinternal.example.com」

- 第3.2.4項「ucminternal.example.com」

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

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

3.2.1 admin.example.com

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

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

3.2.2 wcc.example.com

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

3.2.3 wccinternal.example.com

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

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

3.2.4 ucminternal.example.com

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

追加のIPアドレスを持つのではなく、ucminternal.example.com:6300のかわりにwccinternal.example.com:6300を使用できます。分かりやすくするために、このガイドの参照トポロジでは別個のIPアドレスが示されています。

3.3 ロード・バランサ

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

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

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

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

3.3.1 ロード・バランサの要件について

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

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

- ポート変換の構成。

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

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

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

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

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

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

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

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

- SSLの高速化: この機能は必須です。

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

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

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

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

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

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

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

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

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

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

2. WCCHOSTnノードにTCP/IP監視を構成してノードの障害を検出します。

- 監視はハーフ・オープン・タイプのTCP接続にする必要があります。

- 監視はOracle WebCenter Content Serverのポート4444で5秒おきにノードをpingする必要があります(タイムアウト値は16秒)。

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

4. 同様に、サーバーのプールを作成し、手順2で作成したTCP/IP監視をこのプールに割り当てます。これによりRIDCリクエストがホストWCCHOST1およびWCCHOST2のポート4444に転送されます。

5. 特定のホストおよびサービスが使用可能かどうかを判断し、手順3で示されたサーバーのプールに割り当てるルールを作成します。

6. ロード・バランサにadmin.example.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

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

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

- ポート80でこの仮想サーバーを構成します。ポート80で受信するHTTPリクエストはすべて、HTTPノードのポート7777にリダイレクトされる必要があります。

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

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

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

- 手順3で作成したプールを仮想サーバーに割り当てます。

7. ロード・バランサにwccinternal.example.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

- Oracle WebCenter Contentの内部アドレスを仮想サーバーのアドレス(wccinternal.example.com)として使用します。このアドレスは一般的に外部化されません。

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

- ポート80でこの仮想サーバーを構成します。ポート80で受信するHTTPリクエストはすべて、HTTPノードのポート7777にリダイレクトされる必要があります。

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

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

- 手順3で作成したプールを仮想サーバーに割り当てます。

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

8. ロード・バランサにucminternal.example.com:6300の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

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

- TCP/IPをプロトコルとして指定します。

- ポート6300でこの仮想サーバーを構成します。ポート6300で受信するRIDCリクエストはすべて、コンテンツ・サーバーのノードのポート4444にリダイレクトされる必要があります。

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

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

- 手順3で作成した、RIDCリクエスト用のプールを仮想サーバーに割り当てます。

第9.5項「仮想ホストの定義」のとおりに仮想ホストを構成すると、仮想ホスト名アドレスへのアクセスが可能になります。アクセスできない場合は、その手順が正しく完了していることを確認します。

3.4 IPアドレスおよび仮想IPアドレス

図3-1に示すように、異なる物理IPアドレスと仮想IPアドレスでリスニングするように、管理サーバーと管理対象サーバーを構成してください。図に示すように、各IPアドレスと仮想IPアドレスは、使用するOracle WebLogic Serverに割り当てられます。VIP1に障害が発生すると、手動で管理サーバーがWCCHOST2で再起動します。Oracle SOA SuiteとImagingを使用するように構成している場合、Oracle WebLogic Serverの移行機能によって、WLS_SOA1はVIP2を使用してWCCHOST1からWCCHOST2に、WLS_SOA2はVIP3を使用してWCCHOST2からWCCHOST1にそれぞれフェイルオーバーします。また、サーバー移行によって、WLS_IMG1はVIP4を使用してWCCHOST1からWCCHOST2に、WLS_IMG2はVIP5を使用してWCCHOST2からWCCHOST1にそれぞれフェイルオーバーします。同様に、WLS_CPT1とWLS_CPT2はそれぞれVIP6とVIP7を使用してフェイルオーバーします。

WebLogic Serverの移行機能の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

(仮想ではない)物理IPアドレスが、各ノードに固定的に割り当てられます。IP1はWCCHOST1の物理IPアドレスで、WLS_WCC1サーバーによりリスニング・アドレスとして使用されます。IP2はWCCHOST2の物理IPアドレスで、WLS_WCC2サーバーによりリスニング・アドレスとして使用されます。

仮想IPアドレスdb-scan.example.comは、GridLinkデータ・ソースのデータベースOracle Single Client Access Name (SCAN)のアドレスです。

図3-1 管理サーバーと管理対象サーバーにマップされるIPアドレスと仮想IPアドレス

表3-1に、仮想IPアドレスがマップされる各種仮想ホストの説明を示します。

表3-1 仮想IPアドレスにマップされる仮想ホスト

仮想IPアドレス

仮想ホスト名

説明

VIP1

ADMINVHN

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

VIP2

WCCHOST1VHN1

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

VIP3

WCCHOST2VHN1

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

VIP4

WCCHOST1VHN2

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

VIP5

WCCHOST2VHN2

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

VIP6

WCCHOST1VHN3

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

VIP7

WCCHOST2VHN3

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

db-scan.example.com

db-scan.example.comは、GridLinkデータ・ソースのデータベースOracle Single Client Access Name (SCAN)のアドレスです。

3.5 ファイアウォールとポート

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

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

表3-2には、Oracle WebCenter Contentトポロジで使用されるポートの一覧が記載されているほか、トポロジのファイアウォール上で開く必要のあるポートも記載されています。

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

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

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

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

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

タイプ

ファイアウォール

ポートとポート範囲

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

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

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

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

FW0

80

HTTP/ロード・バランサ

インバウンド

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

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

FW0

443

HTTPS/ロード・バランサ

インバウンド

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

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

FW1

80

HTTP/ロード・バランサ

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

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

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

FW1

443

HTTPS/ロード・バランサ

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

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

コールバックおよびアウトバウンド呼出し

FW1

80

HTTP/ロード・バランサ

アウトバウンド

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

コールバックおよびアウトバウンド呼出し

FW1

443

HTTPS/ロード・バランサ

アウトバウンド

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

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

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

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

n/a

7777

HTTP

n/a

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

Remote Intradoc Client (RIDC)へのロード・バランサ

FW1

6300

TCP/IPユニキャスト

n/a

永続的に接続されます。

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

FW1

7001

HTTP/t3

インバウンド

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

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

FW1

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

それぞれTCPとHTTP

アウトバウンド

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

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

FW1

8001

範囲:
8000から8080

HTTP / WLS_SOAn

インバウンドおよびアウトバウンド

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

Oracle WebCenter Contentへのアクセス

FW1

16200

HTTP / WLS_WCCn

インバウンド

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

Oracle WebCenter Content: Imagingへのアクセス

FW1

16000

HTTP / WLS_IMGn

インバウンド

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

Oracle WebCenter Enterprise Captureへのアクセス

FW1

16400

HTTP / WLS_CPTn

インバウンド

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

Oracle WebCenter ContentへのImagingによる接続

FW1

6300

TCP/IPユニキャスト

n/a

永続的に接続されます。コンテンツ・サーバーのタイムアウトを構成できます。

SOA_Clusterメンバー間の通信

n/a

8001

TCP/IPユニキャスト

n/a

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

WCC_Clusterメンバー間の通信

n/a

16200

TCP/IPユニキャスト

n/a

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

IMG_Clusterメンバー間の通信

n/a

16000

TCP/IPユニキャスト

n/a

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

CPT_Clusterメンバー間の通信

n/a

16400

TCP/IPユニキャスト

n/a

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

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

n/a

n/a

n/a

n/a

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

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

FW1

7001

HTTP / 管理サーバーおよびOracle Enterprise Manager Fusion Middleware Control

t3

両方

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

ノード・マネージャ

n/a

5556

TCP/IP

n/a

n/a

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

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

FW1

5575
(Oracle Access Manager 11g)

OAP

インバウンド

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

データベースへのアクセス

FW2

1521

SQL*Net

両方

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

デプロイメントの一貫性

n/a

8088

範囲:
8000から8090

n/a

n/a

Oracle Internet Directoryのアクセス

FW2

389

LDAP

インバウンド

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

Oracle Internet Directoryのアクセス

FW2

636

LDAP SSL

インバウンド

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

OWSM用JOC

n/a

9991

範囲:
9988から9998

TCP/IP

n/a

n/a

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

n/a

16250

16250

HTTP / WLS_IBRn

n/a

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

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

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

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

この章には次の項が含まれます:

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

- 第4.2項「ディレクトリとディレクトリ環境変数の用語」

- 第4.3項「ディレクトリ構造と構成」

- 第4.4項「各種ディレクトリの推奨場所」

- 第4.5項「共有記憶域の構成」

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

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

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

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

この項では、Oracle WebCenter Contentエンタープライズ・デプロイメントを構成するためにこのガイドで使用されるディレクトリ環境変数について説明します。Oracle WebCenter Contentには2つの異なるドメイン設定があります。1つはOracle WebCenter Contentドメイン用で、もう1つはWebCenter Contentユーザー・インタフェースのドメイン用です。2つのドメインはファイルシステム・レイアウトが異なっています。

表4-1に、このガイド全体でアプリケーション層のディレクトリを表すディレクトリ変数を示します。

表4-1 Oracle WebCenter Contentドメインにあるアプリケーション層のディレクトリ変数

ディレクトリ変数

説明

参照トポロジのアプリケーション層のディレクトリ

ORACLE_BASE

Oracle Fusion Middleware製品のインストール・ファイルおよび構成ファイルへのディレクトリ・パス。

/u01/oracle

または

/u02/oracle

MW_HOME

Oracle Fusion Middleware製品がインストールされる、Middlewareホームへのディレクトリ・パス。Middlewareホームには、WebLogic Serverホーム(WL_HOME)、Oracle共通ホーム(ORACLE_COMMON_HOME)、オプションで、JDKホーム(JAVA_HOME)、およびOracle Fusion Middlewareコンポーネントと製品用に1つ以上のOracleホーム(Oracle WebCenter Content (WCC_ORACLE_HOME)を含む)が含まれています。

Middlewareホームは、ローカル・ファイル・システム上、またはネットワーク・ファイル・システム(NFS)経由でアクセス可能なリモートの共有ディスク上に配置できます。

/u01/oracle/products/fmw_home

WL_HOME

WebLogic Serverホームへのディレクトリ・パス。これには、Oracle WebLogic Serverにインストールされたファイルが含まれています。

/u01/oracle/products/fmw_home/wlserver_10.3

WCC_ORACLE_HOME

Oracle WebCenter ContentがインストールされているOracleホームへのディレクトリ・パス。

/u01/oracle/products/fmw_home/wcc_home

SOA_ORACLE_HOME

Oracle SOA SuiteがインストールされているOracleホームへのディレクトリ・パス。

/u01/oracle/products/fmw_home/soa

ORACLE_COMMON_HOME

ドメインのOracle共通フォームへのディレクトリ・パス。これには、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Java Required Files (JRF)に必要なバイナリ・ファイルとライブラリ・ファイルが含まれています。

/u01/oracle/products/fmw_home/oracle_common

JAVA_HOME

Oracle JRockitまたは別のJDKがインストールされている場所です。

/u01/oracle/products/fmw_home/JRockit_version

ASERVER_HOME

WebLogic Server管理サーバーのドメイン構成のプライマリ・ロケーションへのディレクトリ・パス。ドメイン情報および構成アーティファクトが格納されています。各種のOracle WebLogic Serverは、同じノード内にある場合でも異なるドメイン・ディレクトリを使用できます。

/u01/oracle/config/domains/WCCDomain

MSERVER_HOME

WebLogic Server管理対象サーバーのドメイン構成のプライマリ・ロケーションへのディレクトリ・パス。ドメイン情報および構成アーティファクトが格納されています。各種のOracle WebLogic Serverは、同じノード内にある場合でも異なるドメイン・ディレクトリを使用できます。

管理対象サーバーの起動および停止に使用されるドメイン構成のコピーです。

/u02/oracle/config/domains/WCCDomain

APPLICATION_HOME

各ノードに対してローカルな管理サーバーおよび管理対象サーバーのアプリケーション・ディレクトリの場所へのディレクトリ・パス。

/u01/oracle/config/applications/WCCDomain

表4-2に、このガイド全体でOracle Web層のディレクトリを表すディレクトリ変数を示します。

表4-2 Oracle Web層のディレクトリ変数

ディレクトリ変数

説明

Oracle Web層のサンプル値

WT_ORACLE_HOME

Oracle Web層のOracleホームへのディレクトリ・パス。これには、Oracle Web層のインストールに必要なバイナリ・ファイルおよびライブラリ・ファイルが含まれています。

/u02/oracle/products/fmw_home/web_home

ORACLE_INSTANCE

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

/u02/oracle/config/web1

または

/u02/oracle/config/web2

WEBGATE_ORACLE_HOME

Webゲート・インストールへのディレクトリ・パス。

/u02/oracle/products/fmw_home/WebGate_home

表4-3に、このガイド全体でWebCenter Contentユーザー・インタフェース・ドメインのアプリケーション層のディレクトリを表すディレクトリ変数を示します。

表4-3 WebCenter Contentユーザー・インタフェース・ドメインにあるアプリケーション層のディレクトリ変数

ディレクトリ変数

説明

アプリケーション層のサンプル値

WCCUI_MW_HOME

Oracle Fusion Middleware製品がインストールされる、Middlewareホームへのディレクトリ・パス。Middlewareホームには、WebLogic Serverホーム(WCCUI_WL_HOME)、Oracle共通ホーム(WCCUI_ORACLE_COMMON_HOME)、オプションで、JDKホーム(WCCUI_JAVA_HOME)、およびOracle Fusion Middlewareコンポーネントと製品用に1つ以上のOracleホームが含まれています(WebCenter Contentユーザー・インタフェースを含む)。

Middlewareホームは、ローカル・ファイル・システム上、またはネットワーク・ファイル・システム(NFS)経由でアクセス可能なリモートの共有ディスク上に配置できます。

/u01/oracle/products/fmw_home

WCCUI_WL_HOME

WebLogic Serverホームへのディレクトリ・パス。これには、Oracle WebLogic Serverにインストールされたファイルが含まれています。

/u01/oracle/products/fmw_home/wlserver_10.3

WCCUI_ORACLE_COMMON_HOME

ドメインのOracle共通フォームへのディレクトリ・パス。これには、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Java Required Files (JRF)に必要なバイナリ・ファイルとライブラリ・ファイルが含まれています。

/u01/oracle/products/fmw_home/oracle_common

WCCUI_JAVA_HOME

Oracle JRockitまたは別のJDKがインストールされている場所です。値

/u01/oracle/products/fmw_home/JRockit_version

WCCUI_ASERVER_HOME

WebLogic Server管理サーバーのドメイン構成のプライマリ・ロケーションへのディレクトリ・パス。ドメイン情報および構成アーティファクトが格納されています。各種のOracle WebLogic Serverは、同じノード内にある場合でも異なるドメイン・ディレクトリを使用できます。

/u01/oracle/config/domains/WCCUIDomain

WCCUI_MSERVER_HOME

WebLogic Server管理対象サーバーのドメイン構成のプライマリ・ロケーションへのディレクトリ・パス。ドメイン情報および構成アーティファクトが格納されています。各種のOracle WebLogic Serverは、同じノード内にある場合でも異なるドメイン・ディレクトリを使用できます。

管理対象サーバーの起動および停止に使用されるドメイン構成のコピーです。

/u02/oracle/config/domains/WCCUIDomain

WCCUI_APPLICATION_HOME

各ノードに対してローカルな管理サーバーおよび管理対象サーバーのアプリケーション・ディレクトリの場所へのディレクトリ・パス。

/u01/oracle/config/applications/WCCUIDomain

ヒント:
この項で説明している場所には、ショートカットとして環境変数を使用し、ディレクトリに簡単に移動できます。たとえば、$MW_HOMEと呼ばれる環境変数を使用すると、/u01/oracle/products/fmw_home (すなわち、ディレクトリ・パスでMW_HOMEで表される、Middlewareホームの推奨の場所)を参照できます。

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

次の図および表に、推奨ディレクトリ構造と共有記憶域を示します。

図4-1に、管理サーバー・ドメイン・ディレクトリのディレクトリ構造を示します。

図4-1 製品バイナリおよびASERVERドメイン・ディレクトリのファイル・レイアウト(共有記憶域)

図4-2に、管理対象サーバー・ドメイン・ディレクトリのディレクトリ構造を示します。

図4-2 MSERVERドメイン・ディレクトリのファイル・レイアウト

図4-3に、Web層のディレクトリ構造を示します。

図4-3 ローカル記憶域のWeb層インスタンス・ディレクトリのファイル・レイアウト

図4-4に、WebCenter Contentユーザー・インタフェースの管理サーバー・ドメイン・ディレクトリのディレクトリ構造を示します。

図4-4 WebCenter Contentユーザー・インタフェースの製品バイナリおよびASERVERドメイン・ディレクトリのファイル・レイアウト(共有記憶域)

図4-5に、WebCenter Contentユーザー・インタフェースの管理対象サーバー・ドメイン・ディレクトリのディレクトリ構造を示します。

図4-5 WebCenter Contentユーザー・インタフェースのMSERVERドメイン・ディレクトリのファイル・レイアウト

表4-4は、記憶域を共有するOracle WebCenter ContentおよびOracle SOA Suiteの管理対象サーバーを含むOracle WebLogic Serverドメインのディレクトリ構造を要約しています。

表4-4 Oracle WebCenter Contentドメインの共有記憶域の内容

WebLogic Server

データのタイプ

共有記憶域のボリューム

マウント・ポイント

ファイルおよび
サブディレクトリ

マウント・ホスト

WCCHOST1上で実行される管理サーバーおよびすべての管理対象サーバー

FMW製品のインストール

VOL1a

/u01/oracle/products

このボリュームはWCCHOST1のローカル記憶域としてマウントされます。VOL1aには、WCCHOST1で実行されるWebLogic Serverが使用するインストール済バイナリ・ファイルおよびサブディレクトリがすべて含まれています。

WCCHOST1

WCCHOST2上で実行される管理サーバーおよびすべての管理対象サーバー

FMW製品のインストール

VOL1b

/u01/oracle/products

このボリュームはWCCHOST2のローカル記憶域としてマウントされます。VOL1bには、WCCHOST2で実行されるWebLogic Serverが使用するインストール済バイナリ・ファイルおよびサブディレクトリがすべて含まれています。

WCCHOST2

管理サーバー

ドメイン
構成

VOL1c

/u01/oracle/config

この共有ボリュームは、管理サーバー・ドメイン構成およびクラスタ関連のサブディレクトリに使用されます。(WCCHOST1およびWCCHOST2がVOL1cをマウントしています。)

WCCHOST1
WCCHOST2

WLS_WCC1、WLS_IBR1、WLS_SOA1、WLS_IMG1、WLS_CPT1

ドメイン構成

VOL1d

/u02/oracle

このボリュームはOraInventoryおよび管理対象サーバー・ドメイン構成のローカル記憶域としてマウントされます。WCCHOST1がVOL1dをマウントしています。

WCCHOST1

WLS_WCC2、WLS_IBR2、WLS_SOA2、WLS_IMG2、WLS_CPT2

ドメイン構成

VOL1e

/u02/oracle

このボリュームはOraInventoryおよび管理対象サーバー・ドメイン構成のローカル記憶域としてマウントされます。WCCHOST2がVOL1eをマウントしています。

WCCHOST2

Oracle Web Tier

Web層
インストールおよび
構成

VOL1f

/u02/oracle

このボリュームはOHSインストールのローカル記憶域にマウントされます。WCCHOST1がVOL1fをマウントしています。

WEBHOST1

Oracle Web Tier

Web層インストールおよび
構成

VOL1g

/u02/oracle

このボリュームはOHSインストールのローカル記憶域にマウントされます。WCCHOST2がVOL1gをマウントしています。

WEBHOST2

表4-5は、WebCenter Contentユーザー・インタフェースを含むOracle WebLogic Serverドメインのディレクトリ構造を要約しています。

表4-5 WebCenter Contentユーザー・インタフェース・ドメインの共有記憶域の内容

WebLogic Server

データのタイプ

共有記憶域のボリューム

マウント・ポイント

ファイルおよび
サブディレクトリ

マウント・ホスト

WCCUIHOST1上で実行される管理サーバーおよびすべての管理対象サーバー

FMW製品のインストール

VOL2a

u01/oracle/products

このボリュームはWCCUIHOST1のローカル記憶域としてマウントされます。VOL2aには、WCCUIHOST1で実行されるWebLogic Serverが使用するインストール済バイナリ・ファイルおよびサブディレクトリがすべて含まれています。(WCCUIHOST1がVOL2aをマウントしています。)

WCCUIHOST1

WCCUIHOST2上で実行される管理サーバーおよびすべての管理対象サーバー

FMW製品のインストール

VOL2b

u01/oracle/products

このボリュームはWCCUIHOST2のローカル記憶域としてマウントされます。VOL2bには、WCCUIHOST2で実行されるWebLogic Serverが使用するインストール済バイナリ・ファイルおよびサブディレクトリがすべて含まれています。(WCCUIHOST2がVOL2bをマウントしています。)

WCCUIHOST2

管理サーバー

ドメイン
構成

VOL2c

u01/oracle/config

この共有ボリュームは、管理サーバー・ドメイン構成に使用されます。(WCCUIHOST1およびWCCUIHOST2がVOL2cをマウントしています。)

WCCUIHOST1

WCCUIHOST2

WLS_WCCUI1

ドメイン構成

VOL2d

/u02/oracle

このボリュームはOraInventoryおよび管理対象サーバー・ドメイン構成のローカル記憶域としてマウントされます。(WCCUIHOST1がVOL2dをマウントしています。)

WCCUIHOST1

WLS_WCCUI2

ドメイン構成

VOL2e

/u02/oracle

このボリュームはOraInventoryおよび管理対象サーバー・ドメイン構成のローカル記憶域としてマウントされます。(WCCHOST2がVOL2eをマウントしています。)

WCCUIHOST2

4.4 各種ディレクトリの推奨場所

次の各項では、エンタープライズ・デプロイメント・トポロジで共有記憶域を使用するための基本的な推奨事項についていくつか説明します。

- 第4.4.1項「バイナリ(Oracleホーム)・ディレクトリ用の共有記憶域に関する推奨事項」

- 第4.4.2項「ドメイン構成ファイル用の共有記憶域に関する推奨事項」

- 第4.4.3項「参照トポロジでのディレクトリの場所」

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

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

- 第4.4.1.1項「バイナリ(Oracleホーム)・ディレクトリについて」

- 第4.4.1.2項「複数のドメインによる単一のOracleホームの共有について」

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

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

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

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

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

Oracle Fusion Middleware Oracleホームの構造と内容の詳細は、Oracle Fusion Middlewareコンセプトを参照してください。

4.4.1.2 複数のドメインによる単一のOracleホームの共有について

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

注意:
管理対象サーバーのドメイン・ディレクトリは、ローカルまたは共有記憶域に配置できます。WebCenter Content管理対象サーバーやInbound Refinery管理対象サーバーで共有記憶域を使用する場合、各管理対象サーバーはノード固有のファイルを使用するため、これらのサーバーで別々のボリュームを使用する必要があります。

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

ホストのoraInventoryを更新して、Middlewareホームを共有記憶域に追加するには、次のコマンドを使用します。

MW_HOME/oui/bin/attachHome.sh

エンタープライズ・デプロイメントのOracle WebCenter Contentの参照トポロジで、MW_HOMEは/u01/oracle/products/fmw_homeディレクトリです。

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

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

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

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

一方のMiddlewareホームが破損または使用不可になっても、影響を受けるのは半分のサーバーのみです。さらに保護を強化するために、これらのボリュームでディスクをミラー化することをお薦めします。

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

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

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

- 第4.4.2.1項「Oracle WebLogic Server管理サーバーおよび管理対象サーバーのドメイン構成ファイルについて」

- 第4.4.2.2項「管理サーバーおよび管理対象サーバーのドメイン構成ファイル用の共有記憶域の要件」

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

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

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

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

4.4.2.2 管理サーバーおよび管理対象サーバーのドメイン構成ファイル用の共有記憶域の要件

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

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

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

- もう一方のコピーは管理対象サーバーの構成ファイル用です。
管理対象サーバーのドメイン・ディレクトリは、ローカルまたは共有記憶域に配置できます。WebCenter Content管理対象サーバーやInbound Refinery管理対象サーバーで共有記憶域を使用する場合、次に示すように、各管理対象サーバーはノード固有のファイルを使用するため、これらのサーバーで別々のボリュームを使用する必要があります。

- WebCenter Contentでは、MSERVER_HOME/ucm/cs/bin/intradoc.cfgを使用します。
参照トポロジで、MSERVER_HOMEは/u02/oracle/config/domains/WCCDomainディレクトリです。

- Inbound Refineryでは、MSERVER_HOME/ucm/ibr/bin/intradoc.cfgを使用します。

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

よって、デプロイメントではストレージ・システムの要件があればそれに適合させる必要があります。ストレージ・システムには、複数のマシンで同じ共有ボリュームのマウントが容易になるような構成オプションを提供するものもあります。

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

4.4.3 参照トポロジでのディレクトリの場所

前述の前提条件に基づいて、次に示す各項目では推奨ディレクトリについて説明します。共有記憶域の場所が直接指定されている場合は必ず、そのディレクトリでは共有記憶域が必要とされることを意味します。ローカル・ディスクが使用されたり共有記憶域がオプションの場合、マウント指定では「共有記憶域を使用している場合」の語句で修飾されます。

共有記憶域は記憶域デバイスの共有(ボリューム)上のパスです。共有記憶域の場所は例であり、指定されたマウント・ポイントが使用されているかぎり変更できます。共有記憶域デバイスでは整合性と単純化のためこの構造をお薦めします。

4.4.3.1 Oracle WebCenter Contentドメインのディレクトリの場所

Oracle WebCenter Contentドメインのディレクトリには、次のファイルシステムの場所をお薦めします。

- Middlewareホーム(MW_HOME)

/u01/oracle/products/fmw_home

注意:
共有記憶域に利用できるボリュームが1つしかない場合に、誤ってファイルを削除しないように、あるいはパッチを適用できるように、別のディレクトリを使用して冗長に構成することができます。2つのMiddlewareホームを利用可能にできます。たとえば、/u01/oracle/products/fmw_home1ディレクトリおよび/u01/oracle/products/fmw_home2ディレクトリです。これらのMiddlewareホームは、すべてのノードで同じマウント・ポイントにマウントされます。

- WebLogic Serverホーム(WL_HOME)

/u01/oracle/products/fmw_home/wlserver_10.3

- Oracle WebCenter Content Oracleホーム(WCC_ORACLE_HOME)

/u01/oracle/products/fmw_home/wcc_home

- Oracle共通ホーム(ORACLE_COMMON_HOME)

/u01/oracle/products/fmw_home/oracle_common

- 管理サーバーのドメイン・ディレクトリ(ASERVER_HOME)

/u01/oracle/config/domains/WCCDomain

Fusion Middleware構成ウィザードではWCCDomainディレクトリを追加します。

- 管理対象サーバーのドメイン・ディレクトリ(MSERVER_HOME)

/u02/oracle/config/domains/WCCDomain

Fusion Middleware構成ウィザードではWCCDomainディレクトリを追加します。

- JMSファイルベースのストアおよびtlogを含む、すべてのコンポーネントのクラスタ関連ファイルの場所
すべてのコンポーネントのクラスタ関連のファイルおよびInbound Refineryファイルは、両方のホストにマウントした一方の共有記憶域にあります。各クラスタのサブディレクトリおよびInbound Refineryサーバーのサブディレクトリは、次のように、ASERVER_HOMEの下に作成されます。

/u01/oracle/config/domains/WCCDomain/WCC_Cluster
/u01/oracle/config/domains/WCCDomain/SOA_Cluster
/u01/oracle/config/domains/WCCDomain/IMG_Cluster
/u01/oracle/config/domains/WCCDomain/CPT_Cluster
/u01/oracle/config/domains/WCCDomain/IBR_Servers

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

- 管理サーバーおよび管理対象サーバーのアプリケーション・ディレクトリの場所

/u01/oracle/config/applications/WCCDomain

注意:
このディレクトリは、Oracle WebCenter Contentエンタープライズ・デプロイメント環境ではローカルになります。intradoc.cfgなどのドメイン内のいくつかのファイルは、各ノードに固有なため、Oracle WebCenter Content Serverの管理対象サーバーではドメイン・ディレクトリを共有できません。

- Web層のOracleホーム(WT_ORACLE_HOME)

/u02/oracle/products/fmw_home/web_home

注意:
Web層のインストールは通常、WEBHOSTnノードのローカル記憶域で実行されます。共有記憶域を使用する場合は、層を横断する記憶域デバイスへのアクセスには、適切なセキュリティ制限をかける必要があります。

- Oracle HTTP Server Oracleインスタンス(OHS_ORACLE_INSTANCE)

/u02/oracle/products/fmw_home/ohs_instance_name

4.4.3.2 WebCenter Contentユーザー・インタフェース・ドメインのディレクトリの場所

WebCenter Contentユーザー・インタフェース・ドメインのディレクトリには、次のファイルシステムの場所をお薦めします。

- WebCenter Contentユーザー・インタフェースのMiddlewareホーム(WCCUI_MW_HOME)

/u01/oracle/products/WCCUI_MW_HOME

- WebCenter Contentユーザー・インタフェースのWebLogic Serverホーム(WCCUI_WL_HOME)

/u01/oracle/products/WCCUI_MW_HOME/wlserver_10.3

- WebCenter Contentユーザー・インタフェースのOracleホーム(WCCUI_ORACLE_HOME)

/u01/oracle/products/WCCUI_MW_HOME/wccui_home

- WebCenter Contentユーザー・インタフェースのOracle共通ホーム(WCCUI_ORACLE_COMMON_HOME)

/u01/oracle/products/WCCUI_MW_HOME/oracle_common

- 管理サーバーのWebCenter Contentユーザー・インタフェースのドメイン・ディレクトリ (WCCUI_ASERVER_HOME)

/u01/oracle/config/domains/WCCUIDomain

Fusion Middleware構成ウィザードではWCCUIDomainディレクトリを追加します。

- 管理対象サーバーのドメイン・ディレクトリ(WCCUI_MSERVER_HOME)

/u02/oracle/config/domains/WCCUIDomain

Fusion Middleware構成ウィザードではWCCUIDomainディレクトリを追加します。

- JMSファイルベースのストアおよびtlogを含む、すべてのコンポーネントのクラスタ関連ファイルの場所
すべてのコンポーネントのクラスタ関連のファイルは、両方のホストにマウントした一方の共有記憶域にあります。次のように、WebCenter Contentユーザー・インタフェース・クラスタのサブディレクトリはWCCUI_ASERVER_HOMEに作成されます。

/u01/oracle/config/domains/WCCUIDomain/WCCUI_Cluster

- WebCenter Contentユーザー・インタフェース・ドメインにある管理サーバーおよび管理対象サーバーのアプリケーション・ディレクトリの場所

/u01/oracle/config/applications/WCCUIDomain

4.5 共有記憶域の構成

次のコマンドを使用して共有記憶域の場所を作成しマウントすることで、WCCHOST1およびWCCHOST2からは別々の2つのボリュームのバイナリ・インストールが同じ場所に見えます。

注意:
共有記憶域のファイル・システムの作成に使用されるユーザーIDは、これらのファイルに対する読取り、書込みおよび実行権限を持ちます。オペレーティング・システム・グループにおける他のユーザーは、ファイルの読取りや実行は可能ですが、書込み権限はありません。インストールと構成の権限に関する詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストールと構成の権限およびユーザーに関する項を参照してください。

コマンドでnasfilerは共有記憶域ファイラです。

WCCHOST1から:

mount nasfiler:/export/wcc_edg/vol1a /u01/oracle/products/fmw_home -t nfs

WCCHOST2から:

mount nasfiler:/export/wcc_edg/vol2a /u01/oracle/products/fmw_home -t nfs

共有ストレージの構成の検証

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

例:

cd newly_mounted_directory
touch testfile

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

ls -l testfile

ファイルを削除します。

rm testfile

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

この章では、Oracle WebCenter Contentエンタープライズ・デプロイメント用のデータベースの準備手順について説明します。この手順には、データベースの初期設定、メタデータ・リポジトリのロードおよびデータベースのバックアップが含まれます。

この章には次の項が含まれます:

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

- 第5.2項「データベース要件」

- 第5.3項「データベース・サービスの作成」

- 第5.4項「データベース・スキーマの作成」

- 第5.5項「データベースのバックアップ」

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

Oracle WebCenter Contentエンタープライズ・トポロジでは、データベースにOracle Fusion Middlewareリポジトリが含まれています。これは、Oracle SOA SuiteコンポーネントやOracle WebCenter Contentコンポーネントなど、Oracle Fusion Middlewareの各種コンポーネントによって使用されるスキーマを集めたものです。このデータベースは、Oracle Identity Managementデータベースとは別になっています。これは、Oracle Internet DirectoryやDIPなどのコンポーネントによってOracle Identity Managementのエンタープライズ・デプロイメントで使用されます。

Oracle Fusion Middlewareコンポーネントを構成するには、まずOracle Fusion Middlewareリポジトリをインストールする必要があります。リポジトリ作成ユーティリティ(RCU)を使用して既存のデータベースにOracle Fusion Middlewareメタデータ・リポジトリをインストールします。RCUは、RCUディストリビューション、または表1-2に記載された場所から入手できます。エンタープライズ・トポロジでは、Oracle Real Application Clusters (RAC)データベースを強くお薦めします。

Oracle SOA Suiteコンポーネントを構成すると、メタデータ・リポジトリを含むデータベースへの接続情報を入力するようにFusion Middleware構成ウィザードで求められます。

5.2 データベース要件

Oracle WebCenter Contentの参照トポロジには、Oracle Database 11gをお薦めします。表5-1に、データベース・スキーマのサマリーを示します。どのデータベースを使用するかは、実装しているトポロジによって異なります。

表5-1 データベースとスキーマ間のマッピング

データベース名

データベース・ホスト

サービス名

データベースのスキーマ

wccdb.example.com

WCCDBHOST1
WCCDBHOST2

wccedg.example.com

WCC_MDS
WCC_IAU
WCC_OPSS
WCC_OCS
WCC_IPM
WCC_CAPTURE
WCC_SOAINFRA
WCC_ORASDPM

Oracle Metadata Services (MDS)リポジトリは、一部のOracle Fusion Middlewareコンポーネントのメタデータを含む特定のリポジトリのタイプです、ユーザーの組織で開発したカスタムJava EEアプリケーションを含むこともできます。

メタデータ・リポジトリをデータベースにロードする前に、次の各項で説明されている要件をデータベースが満たしていることを確認してください。

- 第5.2.1項「データベース・ホストの要件」

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

- 第5.2.3項「初期化パラメータ」

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

データ層内のホストWCCDBHOST1およびWCCDBHOST2には、次の要件があります。

- Oracle Clusterware
Linux用11gリリース1 (11.1)については、『Oracle Grid Infrastructureインストーレーション・ガイド』を参照してください。

- Oracle Real Application Cluster
Linux用11gリリース1 (11.1)の場合、『Oracle Real Application Clustersインストレーション・ガイドfor Linux and UNIX』を参照してください。

- 自動ストレージ管理(オプション)
ASMでは、ノードが全体としてインストールされます。データベースのOracleホームとは別のOracleホームにインストールすることをお薦めします。このオプションはrunInstallerにあります。「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択し、個別のASMホームを作成します。

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

Oracle WebCenter Contentでは、サポートされているデータベースおよびスキーマが存在することが要求されます。使用するデータベースが認証されていること、または認証済のすべてのデータベースを確認するには、「Oracle Fusion Middlewareのサポートされるシステム構成」ページにあるOracle Fusion Middleware 11g リリース1 (11.1.1.x)の製品エリアを参照してください。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

データベースのリリースをチェックするには、次のようにPRODUCT_COMPONENT_VERSIONビューに問い合せます。

SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE PRODUCT LIKE 'Oracle%';

注意:

- Oracle WebCenter Contentでは、メタデータ(11g)の格納に使用するデータベースにAL32UTF8文字セットのサポートが必要です。データベースの文字セットの選択に関する情報は、データベースのドキュメントを確認してください。

- Oracle WebCenter Contentエンタープライズ・デプロイメントでは、GridLinkデータ・ソースを使用してOracle RACデータベースに接続してください。GridLinkでOracle Single Client Access Name (SCAN)機能を使用するには、Oracle RACデータベースのバージョンがOracle Database 11gR2 (11.2以降、Enterprise Edition)である必要があります。

- Oracle Enterprise Captureでは、スキーマとしてOracle Databaseのみで動作する、Oracle Platform Security Services (OPSS)を使用するため、Captureを使用する場合は、Oracle Database 11gが必要です。

5.2.3 初期化パラメータ

必要な最小値に次の初期化パラメータが設定されていることを確認してください。これは、リポジトリ作成ユーティリティによってチェックされます。

表5-2 必要な初期化パラメータ

構成

パラメータ

必要な値

パラメータ・クラス

Oracle SOA Suite

PROCESSES

400以上

静的

Oracle WebCenter Content

PROCESSES

100以上

静的

Oracle SOA SuiteおよびOracle WebCenter Content

PROCESSES

500以上

静的

SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。

SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。

SHOW PARAMETER processes

次のコマンドを使用して初期化パラメータを設定します。

ALTER SYSTEM SET processes=500 open_cursors=500 SCOPE=SPFILE;

データベースを再起動します。

注意:
パラメータ値の変更に使用する方法は、パラメータが静的であるか動的であるかと、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用するかによって異なります。パラメータ・ファイル、サーバー・パラメータ・ファイルおよびパラメータ値の変更方法の詳細は、Oracle Database管理者ガイドを参照してください。

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

複数のOracle Fusion Middleware製品が同じデータベースを共有する場合は、個別の専用のデータベース・サービスに接続するように、各製品を構成する必要があります。サービスを使用したOracle Databaseへの接続の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドのサービスとVIPアドレスを使用したOracleデータベースへの接続の概要に関する項を参照してください。データベース・サービスの作成および管理の詳細な手順は、Oracle Real Application Clusters管理およびデプロイメント・ガイドの自動ワークロード管理の概要に関する項を参照してください。

ランタイム接続のロード・バランシングでは、ロード・バランシングが有効化されるサービスごとにサービスレベルの目標値を使用して、Oracle RACロード・バランシング・アドバイザを構成する必要があります。SERVICE_TIMEまたはTHROUGHPUTについて、Oracle RACロード・バランシング・アドバイザを構成できます。接続ロード・バランシングの目標をSHORTに設定します。Oracle Database 11gリリース1 (11.1)では、DBMS_SERVICEパッケージを使用してこの変更を行います。Oracle Database 11gリリース2 (11.2)では、かわりにサーバー制御ユーティリティ(SRVCTL)を使用します。

Oracle WebCenter Contentインストールは、wccedg.example.comサービスを使用するように構成されています。

注意:
簡略化のために、このガイドでのデータ・ソース構成の画面では同じサービス名(wccedg.example.com)を使用します。

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

- 第5.3.1項「11gリリース1 (11.1)データベース用のデータベース・サービスの作成」

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

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

11gリリース1 (11.1)データベース・サービスは、DBMS_SERVICEパッケージを使用して作成および変更できます。

11.1データベース・サービスを作成および変更する手順は次のとおりです。

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コマンドを使用して、データベースにサービスを追加し、それをインスタンスに割り当てます。

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

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

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

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

4. 次のどちらかのEXECUTEコマンドを使用して、適切なサービス目標でサービスを変更します。

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'wccedg.example.com',goal => DBMS_SERVICE.GOAL_THROUGHPUT, clb_goal =>DBMS_SERVICE.CLB_GOAL_SHORT);

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'wccedg.example.com', goal => DBMS_SERVICE.GOAL_SERVICE_TIME, clb_goal =>DBMS_SERVICE.CLB_GOAL_SHORT);

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

11gリリース2 (11.2)データベース・サービスは、srvctlコマンドを使用して作成および変更できます。

11.2データベース・サービスを作成および変更する手順は次のとおりです。

1. 次のsrvctlコマンドを使用して、データベースにサービスを追加し、それをインスタンスに割り当てます。

srvctl add service -d wccdb -s wccedg.example.com -r wccdb1,wccdb2 -q FALSE -m NONE -e SELECT -w 0 -z 0

次に、コマンドラインの引数について説明します。

オプション

引数

-d

データベースの一意の名前

-s

サービス名

-r

優先インスタンスのカンマ区切りリスト

-q

AQ HA通知(TRUEまたはFALSE)

-e

フェイルオーバー・タイプ(NONE、SESSIONまたはSELECT)

-m

フェイルオーバー方式(NONEまたはBASIC)

-w

フェイルオーバー遅延(整数)

-z

フェイルオーバー再試行回数(整数)

2. 次のsrvctl start serviceコマンドを使用して、サービスを開始します。

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

3. 次のどちらかのsrvctl modify serviceコマンドを使用して、適切なサービス目標でサービスを変更します。

srvctl modify service -d wccdb -s wccedg.example.com -B SERVICE_TIME -j SHORT

srvctl modify service -d wccdb -s wccedg.example.com -B THROUGHPUT  -j SHORT

別のサービス定義の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドのロード・バランシング・アドバイザに関する項を参照してください。

4. 次のsrvctl status serviceコマンドを使用して、開始したサービスを検証します。

srvctl status service -d wccdb -s wccedg.example.com
Service wccedg.example.com is running on instance(s) wccdb1,wccdb2

5. srvctl config serviceを使用して、サービスが正しく作成されたことを検証します。

srvctl config service -d wccdb -s wccedg.example.com
Service name: wccedg.example.com
Service is enabled
Server pool: wccdb_wccedg.example.com
Cardinality: 2
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SELECT
Failover method: NONE
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Preferred instances: wccdb1,wccdb2
Available instances:

注意:
SRVCTLコマンドの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のSRVCTLでのサービスの管理に関する項を参照してください。

5.4 データベース・スキーマの作成

リポジトリ作成ユーティリティ(RCU)はRCUディストリビューションから入手できます。データベースのシードに使用するRCUは、Oracle WebCenter Contentインストールのパッチ・セット・レベルと一致している必要があります。つまり、このエンタープライズ・デプロイメントにOracle WebCenter Content 11gリリース1 (11.1.1.9)をインストールする場合は、RCU 11gリリース1 (11.1.1.9)を使用する必要があります。

データベースにOracle Fusion Middlewareリポジトリをロードする手順は次のとおりです。

1. リポジトリ作成ユーティリティ(RCU)ディストリビューションを開いて、RCUホーム・ディレクトリのbin/ディレクトリからRCUを起動します。

cd RCU_HOME/bin
./rcu

2. 「ようこそ」画面で(表示されている場合のみ)、「次へ」をクリックします。

3. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。

4. 「データベース接続の詳細」画面(図5-1)で、データベースの接続情報を入力します。

- データベース・タイプ: 「Oracle Database」を選択します。

- 「ホスト名」にデータベースが存在するノードの名前を指定します。Oracle RACデータベースの場合、VIP名、SCANアドレス、またはホスト名としてノード名のいずれか(dbscan.example.comなど)を指定します。

- ポート: データベースのリスニング・ポート番号である1521を指定します。

- 「サービス名」: データベースのサービス名を指定します(wccedg.example.com)。

- ユーザー名: DBA権限またはSYSDBA権限を有するユーザーの名前(SYS)を指定します。

- パスワード: SYSユーザーのパスワードを入力します。

- ロール: データベース・ユーザーのロール(SYSDBA)をリストで選択します(SYSユーザーに必要)。

「次へ」をクリックします。

図5-1 「データベース接続の詳細」画面

5. 使用中のデータベースでUTF-8文字セットを使用していない場合には警告メッセージが表示され、多言語サポート対応のデータベースを使用した場合にデータ損失の可能性がある旨を通知します。今後、多言語サポートを使用しない場合は、「無視」をクリックすることもできます。それ以外の場合は、「停止」をクリックします。

6. 「コンポーネントの選択」画面(図5-2)で、次の手順を実行します。

- 「接頭辞の新規作成」を選択し、データベース・スキーマに使用する接頭辞を入力します(例: WCC)。6文字まで接頭辞として指定できます。接頭辞は、データベースで複数のリポジトリの論理グループを作成するために使用されます。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

ヒント:
スキーマ名を書き留めておきます。この情報は後続の手順で必要になります。

- 使用しているトポロジに対して次の表から適切なコンポーネントを選択します。

図5-2「コンポーネントの選択」画面

表5-3に、使用しているOracle WebCenter Content機能セットに選択するRCUコンポーネントを示します。

表5-3 Oracle WebCenter ContentトポロジのRCUコンポーネント

コンポーネント・グループ

選択するRCUコンポーネント

スキーマ名

AS共通サービス

メタデータ・サービス

監査サービス

Oracle Platform Security Services

WCC_MDS

WCC_IAU

WCC_OPSS

WebCenter Content

Oracle WebCenter Content Server - 完全

Oracle WebCenter Content: Imaging

Oracle WebCenter Enterprise Capture

WCC_OCS

WCC_IPM

WCC_CAPTURE

SOAおよびBPMインフラストラクチャ

SOAインフラストラクチャ

ユーザー・メッセージング・サービス

WCC_SOAINFRA

WCC_ORASDPM

MDSスキーマがWebCenter Contentユーザー・インタフェースには必要です。このスキーマは、エンタープライズ・デプロイメント参照トポロジの他のスキーマと同じデータベースに存在することがあります。ただし、WS_Policyの実装にMDSスキーマを必要とするOracle WebCenter Content設定でWS_Policyを使用する場合、WebCenter Contentユーザー・インタフェースでは自身のMDSスキーマが必要になります。同じデータベースで異なる接頭辞を使用してMDS用の新しいスキーマを作成できます。

Oracle Platform Security Services (OPSS)は、そのスキーマとしてOracle Database 11gのみと動作します。OPSSスキーマがクラスタ設定に必要です(Oracle Internet Directoryを使用していて、これを使用するセキュリティ・ストアを再関連付けする場合以外)。

CaptureクラスタにOPSSスキーマまたはOracle Internet Directoryが必要になる理由は、system-jazn-data.xmlファイルがクラスタのセットアップに不十分なためです。データベース内のOPSSスキーマまたはOracle Internet Directoryのどちらかにセキュリティ・ストアが存在していないと、クラスタ内の2番目のノードのsystem-jazn-data.xmlファイルが上書きされるので、2つのノードで構成したクラスタのノードの同期が取れなくなります。これは、ノード・マネージャが1番目のノードのデータから同期し、2番目のノードのファイルを上書きするためです。OPSSスキーマまたはOracle Internet Directoryを使用すると、アプリケーション・データは、両方のノードからアクセスできる共有場所に維持されます。OPSSを使用する場合は、ドメインの作成後に、そのOPSSのデータ・ソースを手動で作成する必要があります。

「次へ」をクリックします。

7. 「スキーマ・パスワード」画面(図5-3)で、「すべてのスキーマに異なるパスワードを指定」を選択して「次へ」をクリックします。次の画面で、各コンポーネントのスキーマ・パスワードを入力します。

ヒント:
スキーマ名を書き留めておきます。この情報は後続の手順で必要になります。

図5-3「スキーマ・パスワード」画面

8. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
確認のダイアログが表示され、選択したスキーマに存在しない表領域が作成されるという内容のメッセージが表示されます。「OK」をクリックして、このメッセージを確認します。

9. 「サマリー」画面で「作成」をクリックします。

10. 「完了サマリー」画面で「閉じる」をクリックします。

11. 追加した新しいユーザーでデータベースに接続し、必要なスキーマが正常に作成されていることを確認します。

ORACLE_HOME/bin/sqlplus

WCC_OCSユーザーとしてログインし、パスワードを入力します。スキーマ・バージョンのレジストリを検索することで、簡単な確認を実行できます。

-bash-3.00$ $ORACLE_HOME/bin/sqlplus WCC_OCS/password as SYSDBA
SQL> SELECT version, status FROM schema_version_registry where owner = 'WCC_OCS';

VERSION STATUS
-----------------------------------------
11.1.1.9.0 VALID

注意:
Oracle WSMポリシーを格納するには、Oracle Identity Management用のデータベースを使用することをお薦めします(第18章「Oracle Identity Managementとの統合」を参照)。そのため、OWSM MDSスキーマのOracle Identity Managementデータベース接続情報が使用されることが予想されます。これは、その他のOracle SOA Suiteスキーマで使用されるデータベース情報とは異なります。データベースで必要なスキーマを作成するには、Oracle Identity Managementデータベース情報を使用して前述の手順を繰り返します。ただし、手順6の「コンポーネントの選択」画面では「AS共通スキーマ: Metadata Services」のみを選択します。

5.5 データベースのバックアップ

使用中のデータベースにメタデータ・リポジトリをロードした後は、まずバックアップを実行し、その後でエンタープライズ・デプロイメント用ソフトウェアをインストールする必要があります。

データベースのバックアップは、今後の手順で問題が発生した場合に迅速なリカバリを行うために明示的に行います。この目的のためにデータベースのバックアップ戦略を使用することも、オペレーティング・システムのツールやRMANを使用して単純にバックアップすることもできます。データベースでOracle Recovery Managerを使用することをお薦めします(特に、Oracle ASMを使用してデータベースを作成した場合)。可能な場合、オペレーティング・システムのツール(tarなど)を使用してコールド・バックアップも実行できます。

6 エンタープライズ・デプロイメント用のサーバーの準備

この章では、エンタープライズ・デプロイメント用のサーバーを準備する方法を説明します。

この章には次の項が含まれます:

- 第6.1項「サーバーの準備の概要」

- 第6.2項「サーバーおよびオペレーティング・システムの検証」

- 第6.3項「最小ハードウェア要件の達成」

- 第6.4項「オペレーティング・システム要件の達成」

- 第6.5項「Unicodeサポートの有効化」

- 第6.6項「仮想IPアドレスの有効化」

- 第6.7項「ユーザーおよびグループの構成」

6.1 サーバーの準備の概要

Oracle Fusion Middlewareを新しいハードウェアにデプロイする前に、Oracleソフトウェアが最適なパフォーマンスで動作するように、使用するサーバーを設定する必要があります。具体的には、次の構成を確認する必要があります。

- 必要なソフトウェア・パッチがインストールされている証明されたオペレーティング・システムをサーバーが実行中。

- UNIXカーネルを正しく構成済。

- Oracleソフトウェアを所有するユーザーおよびグループを作成済。

この章の設定は単なる見本です。Oracleソフトウェアを使用した後、オペレーティング・システムのユーティリティを使用して構成を調整し、サーバーの能力を最大化していることを確認する必要があります。

表6-0に、サーバーがOracle WebCenter Contentエンタープライズ・デプロイメント・トポロジで実行するホストを示します。

表6-1 ホスト・マシン

ホスト名

WCCHOST1

WCCHOST2

WEBHOST1

WEBHOST2

WCCUIHOST1

WCCUIHOST2

6.2 サーバーおよびオペレーティング・システムの検証

使用する計画のサーバーおよびオペレーティング・システムが使用する計画の製品の証明済の組合せであることを確認します。詳細は、Oracleの動作保証マトリクスを参照してください。

6.3 最小ハードウェア要件の達成

Oracleエンタープライズ・デプロイメントでサーバーを使用するには、第1.2項「Linuxシステムにおけるエンタープライズ・デプロイメントのハードウェア要件」に記載されている最小仕様をそのサーバーが満たしていることを確認する必要があります。別のデプロイメント・アーキテクチャ(様々な数のマシンにより多いまたはより少ないコンポーネントをデプロイしたアーキテクチャなど)を使用する計画の場合、Oracle Fusion Middlewareのシステム要件と仕様を確認し、これらのサーバーにデプロイする計画の製品をサポートするための最小仕様を備えていることを確認する必要があります。

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

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

十分なスワップ領域および一時領域を確保します。

- スワップ領域: 最低500MB

- 一時領域: /tmpに最低500MB

6.4 オペレーティング・システム要件の達成

オペレーティング・システム・プロビジョニングを開始する前に、次のタスクを実行します。

1. 証明済オペレーティング・システムをインストールします。

2. 必要なパッチおよびパッケージをすべてインストールします。

次の各トピックでは、UNIXまたはLinuxオペレーティング・システムでOracleソフトウェアの要件を達成する場合の構成タスクについて説明します。

- カーネル・パラメータの構成

- オープン・ファイル制限の設定

- シェル制限の設定

- ローカルHostsファイルの構成

6.4.1 UNIXまたはLinuxシステムでのカーネル・パラメータの構成

次のカーネル・パラメータおよびシェル制限値をチューニングして本番データベース・システムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータのチューニングの詳細は、ご使用のオペレーティング・システムのドキュメントを参照してください。

カーネル・パラメータは、クラスタ内のすべてのノードで次の表に示す最小値以上に設定する必要があります。

次の表の値は、現行のLinuxの推奨値です。詳細は、「Oracle Fusion Middlewareのシステム要件と仕様」を参照してください。データベースをホストにデプロイしている場合、追加のカーネル・パラメータを変更する必要がある場合があります。

表6-2 UNIXのカーネル・パラメータ

パラメータ

値

kernel.sem

256 32000 100 142

kernel.shmmax

4294967295

前述のカーネル・パラメータを設定する手順は次のとおりです。

1. rootとしてログインし、ファイル/etc/sysctl.confのエントリを追加または修正します。

2. ファイルを保存します。

3. 次のコマンドを発行して変更をアクティブ化します。

4. /sbin/sysctl -p

6.4.2 UNIXまたはLinuxシステムでのオープン・ファイル制限の設定
すべてのUNIXオペレーティング・システムにおいて、最小オープン・ファイル制限は4096です。

注意:
次の例はLinuxオペレーティング・システム用です。オペレーティング・システムのドキュメントを確認して、システムで使用するコマンドを判別します。

次のコマンドでオープンになっているファイル数を確認できます。

/usr/sbin/lsof | wc -l

オープン・ファイル制限を確認するには、次のコマンドを使用します。

Cシェル:

limit descriptors

Bash:

ulimit -n

6.4.3 UNIXまたはLinuxシステムでのシェル制限の設定

シェル制限を変更するには、rootとしてログインし、/etc/security/limits.confファイルを編集して、次の行を追加します。

* soft  nofile  4096
* hard  nofile  65536
* soft  nproc   2047
* hard  nproc   16384

ファイルを編集したら、マシンを再起動します。

最新の推奨値は、「Oracle Fusion Middlewareのシステム要件と仕様」を参照してください。

6.4.4 UNIXまたはLinuxシステムでのローカルHostsファイルの構成

Oracleソフトウェアのインストールを開始する前に、ローカルhostsファイルが次のようにフォーマットされていることを確認します。

IP_Address Fully_Qualified_Name Short_Name

6.5 Unicodeサポートの有効化

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

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

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

6.6 仮想IPアドレスの有効化

エンタープライズ・デプロイメントでは、WebLogic Serverの管理サーバーやOracle SOA Suite管理対象サーバーを実行する特定のホストは仮想IPアドレスを使用する必要があります。各サーバーで適切なIPアドレスを有効化する必要があります。

第3.4項「IPアドレスおよび仮想IPアドレス」でサーバーへのIPアドレスのマッピングを説明しています。

6.6.1 有効化する仮想IPアドレスの決定

他のOracle Fusion Middlewareコンポーネントを後でインストールするかしないかに関係なく、WebLogic Serverの管理サーバーのフェイルオーバーを行うには仮想IPアドレスが必要です。

管理サーバーおよび各管理対象サーバーを仮想IPアドレスと関連付けます。これにより、プライマリ・ホストで障害が発生している場合に、別のホストで管理サーバーを起動させることができます。

表6-3で示すように、各仮想ホストが有効化されていることを確認します。

表6-3 ドメインの仮想ホスト

仮想IPアドレス

有効化されているホスト

ADMINVHN.example.com

WCCHOST1

WCCHOST1VHN1.example.com

WCCHOST1

WCCHOST2VHN1.example.com

WCCHOST2

WCCHOST1VHN2.example.com

WCCHOST1

WCCHOST2VHN2.example.com

WCCHOST2

WCCHOST1VHN3.example.com

WCCHOST1

WCCHOST2VHN3.example.com

WCCHOST2

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

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

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

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

Linuxシステムから仮想IPアドレスを有効にするには、次のコマンドをrootとして実行します。

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

このコマンドで、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

6.7 ユーザーおよびグループの構成

グループ

各ノードに次のグループを作成する必要があります。

- oinstall

- dba

ユーザー

各ノードに次のユーザーを作成する必要があります。

- oracle: Oracleソフトウェアを所有するグループ。別の名前も使用できます。このアカウントのプライマリ・グループはoinstallにする必要があります。このアカウントは、dbaグループにも属している必要があります。

- nobody: 権限のないユーザー。

注意:

- グループoinstallは、Oracleソフトウェアが使用する共有記憶域およびローカル記憶域のすべてのファイル・システムに対する書込み権限を持っている必要があります。

- 各グループは、ノードごとに同じグループIDを持っている必要があります。

- 各ユーザーは、ノードごとに同じユーザーIDを持っている必要があります。

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

この章では、Oracle WebCenter Contentエンタープライズ・デプロイメントの参照用トポロジに必要なソフトウェアをインストールする手順を説明します。Oracle HTTP Serverをインストールした後に、Oracle Fusion Middlewareをインストールします。

この章には次の項が含まれます:

- 第7.1項「ソフトウェアのインストール・プロセスの概要」

- 第7.2項「Oracle HTTP Serverのインストール」

- 第7.3項「Oracle Fusion Middlewareのインストール」

注意:
セットアップのプロセスを開始する前に、各プラットフォームのOracle Fusion Middlewareリリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。

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

エンタープライズ・デプロイメントのソフトウェアのインストールは、2つの部分に分割できます。最初のパートでは必要なWeb層のインストールについて説明し、2番目のパートでは必要なOracle Fusion Middlewareコンポーネントについて説明します。以降の章では、Oracle WebCenter Contentの参照用トポロジを作成するために必要な構成手順を説明します。

ソフトウェアの入手およびダウンロードできる場所

ソフトウェアを入手する場所の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のOracle Fusion Middlewareソフトウェアの入手に関する項を参照してください。

いずれかのダウンロード場所を選択して、Oracle WebCenter ContentおよびOracle SOA Suiteをダウンロードします。ZIPアーカイブ・ファイルがシステムに保存されます。

アーカイブ・ファイルをダウンロードした後、インストールを実行するマシン上の任意のディレクトリにアーカイブ・ファイルを解凍します。

インストールするソフトウェア

表7-1に、各ホストにインストールする必要があるソフトウェアまたは各ホストからアクセス可能なソフトウェアを示します。

表7-1 各ホストにインストールするソフトウェアまたは各ホストからアクセスできる必要があるソフトウェア

ホスト

Oracle HTTP Server

Oracle WebLogic Server

Oracle WebCenter Content

Oracle SOA Suite

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

WEBHOST1

X

WEBHOST2

X

WCCHOST1

X

X

X

WCCHOST2

X

X

X

CSUIHOST1

X

CSUIHOST2

X

7.2 Oracle HTTP Serverのインストール

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

- 第7.2.1項「Oracle HTTP Serverのインストールの前提条件」

- 第7.2.2項「Oracle HTTP ServerのWEBHOST1およびWEBHOST2へのインストール」

- 第7.2.3項「インストールのバックアップ」

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

Oracle HTTP Server (OHS)をインストールする前に、ご使用のマシンが次の要件を満たしていることを確認します。

- 『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』で指定されているように、システム、パッチ、カーネルおよびその他の要件が満たされていることを確認します。

- Oracle HTTP Serverはデフォルトではポート7777にインストールされるので、ノード上のどのサービスでもポート7777を使用していないことを確認する必要があります。このポートが使用中かどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。

netstat -an | grep 7777

ポート7777が使用されている場合は解放する必要があります。

- Linuxプラットフォームで、/etc/oraInst.locファイルが存在する場合はその内容が正しいことを確認します。具体的には、インベントリが正しいことおよびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locが存在しない場合は、この手順を省略してもかまいません。

- インストールを開始する前に、次の環境変数が設定されていないことを確認します。

- LD_ASSUME_KERNEL

- ORACLE_INSTANCE

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

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。同じ手順に従って、Oracle HTTP ServerをWEBHOST1およびWEBHOST2にインストールします。

Oracle HTTP ServerをWEBHOST1およびWEBHOST2にインストールするには:

1. Oracle HTTP Serverのインストーラを次のインストール・メディアから起動します。

./runInstaller

2. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. 各サーバー・ノードのローカル・プライベート記憶域ボリュームで/u02/oracle/oraInventoryと入力します。

2. インストールを実行するユーザーのOSグループを入力します。

3. 「次へ」をクリックします。

画面の手順に従って、createCentralInventory.shをrootとして実行します。

「OK」をクリックします。

3. 「ようこそ」画面で、「次へ」をクリックします。

4. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「ソフトウェアのインストール - 構成なし」を選択し、「次へ」をクリックします。

6. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

7. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホーム (インストールの場所): /u02/oracle/products/fmw_home

- Oracleホーム・ディレクトリ: web_home

「次へ」をクリックします。

8. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。

9. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックして前の画面に戻り、選択内容を変更します。問題がなければ、「インストール」をクリックします。
UNIXシステムでoracleRoot.shスクリプトの実行を要求された場合は、rootユーザーとして実行します。

Oracle HTTP Serverソフトウェアがインストールされます。

10. 「インストール完了画面で「終了」をクリックして終了します。

11. Oracle HTTP Serverのインストール後、Middlewareホーム・ディレクトリに次のディレクトリが表示されることを確認し、インストールが成功したことを確認します。

- oracle_common

- web_home

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

この時点でWEBHOST1からMiddlewareホームをバックアップする必要があります(この時点ですべてのサーバーが停止していることを確認します)。

tar -cvpf fmwhomeback.tar /u02/oracle/products/fmw_home /u02/oracle/oraInventory

7.3 Oracle Fusion Middlewareのインストール

この項では、Oracle WebCenter Contentエンタープライズ・デプロイメントの参照トポロジ用に、Oracle Fusion MiddlewareソフトウェアをMiddlewareホーム(MW_HOME)にインストールする方法について説明します。インストールするソフトウェア・コンポーネントは、WebLogic Serverホーム(WL_HOME)にはOracle JRockit、Oracle WebLogic Serverが含まれ、WebCenter Content Oracleホーム(WCC_ORACLE_HOME)にはOracle WebCenter Contentが含まれ、オプションで、SOA Oracleホーム(SOA_ORACLE_HOME)にはOracle SOA Suiteが含まれています。第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

注意:
セットアップのプロセスを開始する前に、各プラットフォームのOracle Fusion Middlewareリリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。

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

- 第7.3.1項「Middlewareホーム・ディレクトリの作成」

- 第7.3.2項「MiddlewareホームへのOracle JRockitのインストール」

- 第7.3.3項「Oracle WebLogic Serverのインストール」

- 第7.3.4項「Oracle Fusion Middlewareコンポーネントのインストール」

- 第7.3.5項「インストールのバックアップ」

7.3.1 Middlewareホーム・ディレクトリの作成

MiddlewareホームはOracle Fusion Middleware製品をインストールできる場所です。Middlewareホーム(MW_HOME)には、WebLogic Serverホーム(WL_HOME)、Oracle共通ホーム(ORACLE_COMMON_HOME)、オプションで、JDKホーム(JAVA_HOME)、およびOracle Fusion Middlewareコンポーネントおよび製品用に1つ以上のOracleホーム(Oracle WebCenter Content (WCC_ORACLE_HOME)を含む)が含まれています。

Middlewareホームは、ローカル・ファイル・システム上、またはネットワーク・ファイル・システム(NFS)経由でアクセス可能なリモートの共有ディスク上に配置できます。

Oracle Fusion Middlewareソフトウェアをインストールする前に、次のように、Middlewareホーム・ディレクトリを作成する必要があります。

mkdir /u01/oracle/products/fmw_home/

7.3.2 MiddlewareホームへのOracle JRockitのインストール

MiddlewareホームにOracle JRockitをインストールする手順は次のとおりです。

1. Oracle Technology Networkから、使用しているプラットフォーム用のバージョンのOracle JRockitをダウンロードします。

http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html

2. 実行権限をOracle JRockitに追加します。例:

chmod +x jrockit-1.6.0_29-R28.2.0-4.0.1-linux-x64.bin

3. 次のコマンドを発行して、Oracle JRockitインストーラを起動します。

./jrockit-version.bin

例

./jrockit-1.6.0_29-R28.2.0-4.0.1-linux-x64.bin

4. 「ようこそ」画面で、「次へ」をクリックします。

5. 「製品インストール・ディレクトリの選択」画面で、「製品のインストール・ディレクトリ」の値を入力します。これは、JAVA_HOME値で、Oracle JRockitがMiddlewareホーム内にインストールされるディレクトリへのパスです。例:

/u01/oracle/products/fmw_home/JRockit_version

6. オプション・コンポーネント画面で「次へ」をクリックします。

7. 「インストール 完了」画面で「完了」をクリックします。

7.3.3 Oracle WebLogic Serverのインストール

同じ手順に従って、Oracle WebLogic ServerをWCCHOST1およびWCCHOST2にインストールします。

Oracle WebLogic ServerをWCCHOST1またはWCCHOST2にインストールする手順は次のとおりです。

1. 64ビット版のUNIXオペレーティング・システムのWCCHOST1およびWCCHOST2にOracle WebLogic Serverをインストールするには、次のいずれかのコマンドを使用します。

JAVA_HOME/bin/java -jar wls103n_generic.jar

JAVA_HOME/bin/java -d64 -jar wls103n_generic.jar

32ビット版のUNIXオペレーティング・システムのWCCHOST1およびWCCHOST2にOracle WebLogic Serverをインストールするには、Oracle WebLogic Serverのインストーラを次のように起動します。

$ ./wls1036_linux32.bin

2. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. 各サーバー・ノードにマウントされたローカル・プライベート記憶域ボリュームで/u02/oracle/oraInventoryと入力します(これは推奨の場所です)。

2. インストールを実行するユーザーのOSグループを入力します。

3. 「次へ」をクリックします。

画面の手順に従って、createCentralInventory.shをrootとして実行します。

「OK」をクリックします。

3. 「ようこそ」画面で、「次へ」をクリックします。

4. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、次の手順を実行します。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」に、/u01/oracle/products/fmw_homeと入力します。
詳細は、第4.4項「各種ディレクトリの推奨場所」を参照してください。

「次へ」をクリックします。

5. 「セキュリティ更新のための登録」画面で、セキュリティ更新の通知を受け取る連絡先の情報を入力して、「次へ」をクリックします。

6. 「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。

7. 「製品とコンポーネントの選択」画面で、「次へ」をクリックします。

8. 「JDKの選択」画面で、Oracle JRockit 1.6.0_version SDKを選択して、「次へ」をクリックします。

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

9. 「製品インストール・ディレクトリの選択」画面で、ORACLE_BASE/product/fmw_home/wlserver_10.3とORACLE_BASE/product/fmw_home/coherence_3.7ディレクトリを受け入れ、「次へ」をクリックします。

10. 「インストールの概要」画面で「次へ」をクリックします。
Oracle WebLogic Serverソフトウェアがインストールされます。

11. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

12. Oracle WebLogic Serverのインストール後、MW_HOME/ディレクトリに次のディレクトリおよびファイルが表示されることを確認し、インストールが成功したことを確認します。

- coherence_version

- jrockit-jdk1.6.0_version

- modules

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- wlserver_10.3

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

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

- 第7.3.4.1項「Oracle WebCenter Contentのインストール」

- 第7.3.4.2項「Oracle SOA Suiteのインストール」

7.3.4.1 Oracle WebCenter Contentのインストール

Oracle WebCenter Contentソフトウェアをインストールする際には、次の機能セットに対応する製品ビットをシステムにインストールします。

- Oracle WebCenter Content (WebCenter Content、Oracle WebCenter Content Serverを含む)

- Oracle WebCenter Content: Inbound Refinery

- Oracle WebCenter Content: Imaging (Imagingビューア・キャッシュおよびAXF for BPELを含む)

- Oracle WebCenter Content: AXF for BPM

- Oracle WebCenter Enterprise Capture

- Oracle Information Rights Management (Oracle IRM)

- Oracle WebCenter Content: Records

Oracle WebCenter ContentをWCCHOST1およびWCCHOST2にインストールする手順は次のとおりです。

1. Oracle WebCenter Contentのインストーラを起動します。

wcc_media_loc/Disk1/runInstaller -jreLoc jre_location

JREの場所を指定しない場合は、場所の指定を求められるか、エラーが返されます。エラーが発生した場合は、JREの場所を追加してコマンドを再試行します(例: MW_HOME/jrockit-jdk1.6.0_version)。詳細は、第7.3.3項「Oracle WebLogic Serverのインストール」を参照してください。

2. 「ようこそ」画面で、「次へ」をクリックします。

3. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

4. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

5. 「インストール場所の指定」画面(図7-1)で、Oracle WebCenter Contentのインストール場所を指定します。すでにインストールされているMiddlewareホームをドロップダウン・リストから選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(wcc_home)を入力します。
完了したら、「次」をクリックします。

図7-1 インストール・ウィザードの「インストール場所の指定」画面

6. 「アプリケーション・サーバー」画面で、「WebLogic Server」が選択されていること(デフォルト)を確認してから「次へ」をクリックします。

7. 「インストール・サマリー」画面で「インストール」をクリックします。Oracle WebCenter Contentソフトウェアがインストールされます。

8. 「インストール完了」画面で「終了」をクリックします。

9. Oracle WebLogic Server、Oracle Fusion MiddlewareおよびOracle WebCenter Contentのインストール後、MW_HOME/ディレクトリに次のディレクトリおよびファイルが表示されることを確認し、インストールが成功したことを確認します。

- coherence_version

- jrockit-jdkversion

- modules

- oracle_common

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- wlserver_10.3

- wcc

7.3.4.2 Oracle SOA Suiteのインストール

Oracle Application Extension Framework (AXF)などImagingとともにOracle SOA Suiteを使用する場合は、Oracle SOA Suiteを先にインストールして構成する必要があります。この項では、そのインストールと構成について説明します。構成の詳細は、第12.3項「Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張」を参照してください。

Oracle SOA SuiteをWCCHOST1およびWCCHOST2にインストールする手順は次のとおりです

1. Linuxプラットフォームで、/etc/oraInst.locファイルが存在する場合はその内容が正しいことを確認します。具体的には、インベントリ・ディレクトリ(oraInventory)が正しいことおよびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locが存在しない場合は、この手順を省略してもかまいません。

2. Oracle SOA Suiteのインストーラを次のインストール・メディアから起動します。

soa_media_loc/Disk1/runInstaller -jreLoc jre_location

JREの場所を指定しない場合は、場所の指定を求められるか、エラーが返されます。エラーが発生した場合は、JREの場所を追加してコマンドを再試行します(例: MW_HOME/jrockit-jdk1.6.0_version)。詳細は、第7.3.3項「Oracle WebLogic Serverのインストール」を参照してください。

3. 「ようこそ」画面で、「次へ」をクリックします。

4. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

5. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

6. 「インストール場所の指定」画面(図7-1)で、Oracle SOA Suiteのインストール場所を指定します。すでにインストールされているMiddlewareホームをドロップダウン・リストから選択します。「Oracleホーム」ディレクトリとして、ディレクトリ名(soa)を入力します。
完了したら、「次」をクリックします。

7. 「アプリケーション・サーバー」画面で、「WebLogic Server」が選択されていること(デフォルト)を確認してから「次へ」をクリックします。

8. 「インストール・サマリー」画面で「インストール」をクリックします。
Oracle SOA Suiteソフトウェアがインストールされます。

9. 「インストール完了」画面で「終了」をクリックします。

10. Oracle WebLogic Server、Oracle Fusion Middleware、Oracle WebCenter ContentおよびOracle SOA Suiteのインストール後、MW_HOME/ディレクトリに次のディレクトリおよびファイルが表示されることを確認し、インストールが成功したことを確認します。

- coherence_version

- jrockit-jdkversion

- modules

- oracle_common

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- soa

- wlserver_10.3

- wcc

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

この時点でWCCHOST1からMiddlewareホームをバックアップする必要があります(まず、サーバーが停止していることを確認します)。

tar -cvpf fmwhomeback.tar MW_HOME

Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントの両方のインストール・ファイルのバックアップが作成されます。

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

この章では、Fusion Middleware構成ウィザード、Oracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlを使用してドメインを作成する方法について説明します。ドメインを拡張することで、Oracle Fusion Middlewareコンポーネント(Oracle SOA SuiteおよびOracle WebCenter Content、さらにオプションでOracle WebCenter Content: ImagingおよびOracle WebCenter Content: Inbound Refinery)を追加できます。後述の章で、ドメインの拡張方法について説明します。

この章には次の項が含まれます:

- 第8.1項「ドメイン作成の概要」

- 第8.2項「WCCHOST1でのVIP1の有効化」

- 第8.3項「WCCHOST1での構成ウィザードを使用したドメインの作成」

- 第8.4項「ドメインでの構成後タスクおよび検証タスクの実行」

- 第8.5項「Oracle DatabaseのOPSSセキュリティ・ストアとドメインの再関連付け」

- 第8.6項「管理サーバーの手動フェイルオーバーの確認」

- 第8.7項「WebLogic Serverドメイン構成のバックアップ」

注意:
セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

8.1 ドメイン作成の概要

表8-1に、構成後タスクを含む、Oracle WebLogic Serverドメインの作成手順を示します。

表8-1 WebLogic Serverドメインの作成手順

手順

説明

詳細

WCCHOST1でのVIP1の有効化

WCCHOST1ホストに対してADMINVHNを有効にします。

第8.2項「WCCHOST1でのVIP1の有効化」

WebLogic Serverドメインの作成

構成ウィザードを実行してWebLogic Serverドメインを作成します。

第8.3項「WCCHOST1での構成ウィザードを使用したドメインの作成」

構成後タスクおよび検証タスクの実行

構成後タスクおよび検証タスクの手順を実行します。

第8.4項「ドメインでの構成後タスクおよび検証タスクの実行」

ファイルベースのセキュリティ・ストアとOPSSデータベース・ベース・セキュリティ・ストアの再関連付け

Oracle Database 11.2.01以降で、デフォルトのファイルベース・ポリシーおよび資格証明ストアをOracle Platform and Security Services (OPSS)セキュリティ・ストアに再関連付けします。

第8.5項「Oracle DatabaseのOPSSセキュリティ・ストアとドメインの再関連付け」

管理サーバーのフェイルオーバーの確認

WCCHOST1からWCCHOST2への管理サーバーの手動フェイルオーバーをテストします。

第8.6項「管理サーバーの手動フェイルオーバーの確認」

ドメインのバックアップ

新しく構成したWebLogic Serverドメインをバックアップします。

第8.7項「WebLogic Serverドメイン構成のバックアップ」

このドメインを作成し構成すると、次の章で説明するとおり、ドメインの拡張によってOracle WebCenter ContentコンポーネントおよびOracle SOA Suiteコンポーネントを追加できます。

8.2 WCCHOST1でのVIP1の有効化

この手順は、他のOracle Fusion Middlewareコンポーネントを後でインストールするかどうかにかかわらず、管理サーバーをフェイルオーバーするために必要となります。

管理サーバーに仮想ホスト名(ADMINVHN)を関連付けます。仮想ホスト名は、DNSサーバーとカスタムの/etc/hostファイル内のエントリのいずれかによって、適切な仮想IPアドレス(VIP1)にマップする必要があります。Oracle WebCenter Contentトポロジ内の必要なノードにある名前解決システム(DNSサーバーまたは/etc/hosts)に応じてADMINVHNが使用可能であることを確認します。この仮想ホスト名(ADMINVHN1)に関連付けられた仮想IPアドレス(VIP1)は、WCCHOST1で有効になっている必要があります。

表8-2で示すように、仮想ホストが有効化されていることを確認します。仮想IPアドレスを有効にするには、第6.6項「仮想IPアドレスの有効化」を参照してください。

表8-2 ドメインの仮想ホスト

仮想IPアドレス

有効化されているホスト

ADMINVHN.example.com

WCCHOST1

WCCHOST1VHN1.example.com

WCCHOST1

WCCHOST2VHN1.example.com

WCCHOST2

WCCHOST1VHN2.example.com

WCCHOST1

WCCHOST2VHN2.example.com

WCCHOST2

WCCHOST1VHN3.example.com

WCCHOST1

WCCHOST2VHN3.example.com

WCCHOST2

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

8.3 WCCHOST1での構成ウィザードを使用したドメインの作成

Oracle共通ホーム・ディレクトリからFusion Middleware構成ウィザードを実行して、管理サーバーを含むドメインを作成します。その後に、ドメインを拡張して他のコンポーネントを追加します。

WCCHOST1で構成ウィザードを実行してドメインを作成する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. WCCHOST1で、ディレクトリをFusion Middleware構成ウィザードの場所(第7章「エンタープライズ・デプロイメント用ソフトウェアのインストール」で作成)に変更します。

cd ORACLE_COMMON_HOME/common/bin

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

3. 構成ウィザードを起動します。

./config.sh

4. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

5. 「ドメイン・ソースの選択」画面が開きます(図8-1)。

図8-1「ドメイン・ソースの選択」画面

「ドメイン・ソースの選択」画面で、次の手順を実行します。

1. 「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

2. 次の製品を選択します。

- 基本WebLogic Serverドメイン(自動的に選択されます)

- Oracle Enterprise Manager

- Oracle JRF (自動的に選択されます)

- Oracle OPSS Metadata for JRF

- Oracle Platform Security Services for Audit

3. 「次へ」をクリックします。

6. 「ドメイン名と場所の指定」画面で、新しいドメインの名前(WCCDomainなど)およびドメインとアプリケーションのディレクトリを入力します。

- ドメイン名: WCCDomain

- ドメインの場所: /u01/oracle/config/domains

- アプリケーションの場所: /u01/oracle/config/applications

構成ウィザードは、そのドメイン名のサブディレクトリをドメインの場所およびアプリケーションの場所に追加し、それぞれ、ASERVER_HOMEディレクトリ、APPLICATION_HOMEディレクトリを作成します。

これらのディレクトリが、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されたディレクトリおよび共有記憶域のマウント・ポイントと一致していることを確認します。Oracle WebCenter Contentの管理対象サーバーのドメイン・ディレクトリは、各サーバーのローカル・ボリュームに存在している必要があります。

「次へ」をクリックします。

7. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者が使用するユーザー名とパスワードを入力します。
「次へ」をクリックします。

8. 「サーバーの起動モードおよびJDKの構成」画面で、次の手順を実行します。

- 「WebLogicドメインの起動モード」には、「本番モード」を選択します。

- 「JDKの選択」では、「JROCKIT SDK1.6.0_version」を選択します。

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

「次へ」をクリックします。

9. 「JDBCコンポーネント・スキーマの構成」画面(図8-2)で、次の手順を実行します。

1. 次のスキーマを選択します。

- OPSSスキーマ

- OPSS監査スキーマ

- OPSS監査ビューア・スキーマ

図8-2 OPSSの「JDBCコンポーネント・スキーマの構成」画面

2. RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます(付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照)。ここでの説明に合せて、「GridLinkへ変換」を選択します。
RAC構成を選択すると、選択されたすべてのスキーマがグレー表示されます。

3. 「次へ」をクリックします。

10. 「GridLink RACコンポーネント・スキーマの構成」画面(図8-3)で、次の手順を実行します。

1. 3つのスキーマ行をすべて選択します。

図8-3 OPSSの「GridLink RACコンポーネント・スキーマの構成」画面

2. 次の各フィールドに値を入力して、RCUでシードされたGridLink RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLink Connections用ドライバ(Thin)バージョン: 11以上を選択します。

- サービス名: Oracle RACデータベースのサービス名は小文字で入力し、ドメイン名を続けます(例: wccedg.example.com)。

- ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてWCCを使用しています。

- パスワード: データベース・スキーマ・オーナーのパスワードを入力します。

- 「FANの有効化」を選択します。

- SSLの有効化: このオプションは選択解除したままにします。
SSLを選択してOracle Notification Service (ONS)の通知暗号化を有効にする場合は、「ウォレット・ファイル」および「ウォレット・パスワード」の詳細を適切に指定します。

- サービス・リスナー: 使用しているOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。このプロトコルは、TCPである必要があります。
SCANアドレスを使用してサービス・リスナー(およびOSNホスト)を指定することをお薦めします。これにより、Oracle RACノードを追加または削除しても、SCANアドレスを含むGridLinkデータ・ソースを更新する必要がありません。SCANアドレスを判断するには、データベースに対してremote_listenerパラメータを問い合せます。

SQL>show parameter remote_listener;

NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      db-scan.example.com:1521

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベース・インスタンス・リスナーの仮想IPアドレスとポートを使用します。

wccdbhost1-vip.example.com (port 1521)

wccdbhost2-vip.example.com (1521)

マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データソースの使用」を参照してください。

- ONSホスト: データベースによって報告されるRACデータベースのSCANアドレスとONSリモート・ポートも入力します。

[orcl@WCCDBHOST2~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベースのONSサービスのホスト名とポートを使用します。

wccdbhost1.example.com (port 6200)

wccdbhost2.example.com (6200)

3. 「次へ」をクリックします。

11. 「JDBCコンポーネント・スキーマのテスト」画面(図8-4)で、3つのスキーマの行すべてを選択し、「接続のテスト」をクリックします。
「接続結果ログ」に結果が表示されます。スキーマを含むデータベースに正常に接続できたことを確認します。できなかった場合は、「前」をクリックし、前の画面に戻り、入力を修正し、テストを再試行します。

図8-4 OPSSの「JDBCコンポーネント・スキーマのテスト」画面

接続に成功したら、「次へ」をクリックします。

12. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

「次へ」をクリックします。

13. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: ADMINVHN

- リスニング・ポート: 7001

- SSLリスニング・ポート: N/A

- SSL有効: このチェック・ボックスは選択解除したままにします。

「次へ」をクリックします。

14. 「管理対象サーバーの構成」画面で、「次へ」をクリックします。

15. 「クラスタの構成」画面で、「次へ」をクリックします。

16. 「マシンの構成」画面で、「UNIXマシン」タブを開き、「追加」をクリックして次のマシンを追加します。

表8-3 管理サーバー用のマシン

名前

ノード・マネージャのリスニング・アドレス

ADMINHOST

localhost

他のフィールドはすべてデフォルト値のままにします。マシン名は有効なホスト名またはリスニング・アドレスである必要はありません。これはノード・マネージャの場所を示す一意の識別子です。

注意:
localhostはすべてのアクティブなマシンの相対内部アドレスであるため、ADMINHOSTのノード・マネージャ・リスニング・アドレスはlocalhostを指す必要があります。管理サーバーはlocalhost属性と1つ目のノードを組み合せて使用し、フェイルオーバー後は2つ目のノードも使用するため、管理サーバーのフェイルオーバー時には管理サーバーと関連付けられているノード・マネージャのインスタンスは変更されます。

「次へ」をクリックします。

17. 「サーバーのマシンへの割当」画面で、次のように管理サーバーをマシンに割り当てます。

- ADMINHOST:

- AdminServer

「次へ」をクリックします。

18. 「構成のサマリー」画面で、「作成」をクリックします。

19. ドメインの作成画面で、「完了」をクリックします。

8.4 ドメインでの構成後タスクおよび検証タスクの実行

構成ウィザードでドメインを構成したら、次の手順に従って構成後タスクと検証タスクを実行します。

この項は次のトピックで構成されています。

- 第8.4.1項「WCCHOST1での管理サーバー用boot.propertiesの作成」

- 第8.4.2項「WCCHOST1でのノード・マネージャの起動」

- 第8.4.3項「WCCHOST1での管理サーバーの起動」

- 第8.4.4項「管理サーバー構成の検証」

- 第8.4.5項「ホスト名検証の無効化」

- 第8.4.6項「WCCHOST2のMiddlewareホームへのドメイン・レジストリ・ファイルのコピー」

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

WCCHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。このファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。

WCCHOST1上の管理サーバーに対してboot.propertiesファイルを作成する手順は次のとおりです。

1. WCCHOST1上で次のディレクトリ構造を作成します。

mkdir -p ASERVER_HOME/servers/AdminServer/security

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=admin_user
password=admin_password

値admin_userおよびadmin_passwordは、WebLogic Serverドメイン管理者のユーザー名とパスワードです。

注意:
管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。第8.4.3項「WCCHOST1での管理サーバーの起動」に記載した管理サーバーを起動します。セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、できるだけ速やかにサーバーを起動し、エントリを暗号化してください。

3. ファイルを保存してエディタを閉じます。

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

WCCHOST1でノード・マネージャを起動するには、StartScriptEnabledプロパティをtrueに設定し、startNodeManager.shを使用してノード・マネージャを起動します。

WCCHOST1でノード・マネージャを起動する手順は次のとおりです。

1. ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定した後に、ノード・マネージャを起動します。

cd ORACLE_COMMON_HOME/common/bin

./setNMProps.sh
File nodemanager.properties not found. Copying required properties file.

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

2. ノード・マネージャを起動します。

cd WL_HOME/server/bin

export JAVA_OPTIONS=-DDomainRegistrationEnabled=true

nohup ./startNodeManager.sh > nm.out&

参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

注意:
管理サーバーを管理するノード・マネージャを起動するときには、-DDomainRegistrationEnabled=trueパラメータを設定することが重要になります。マシンに管理サーバーがなく、そのマシンが管理サーバーのフェイルオーバー・ノードでない場合には、次のスクリプトを使用してノード・マネージャを起動できます(exportコマンドは不要です)。

nohup ./startNodeManager.sh > nm.out&

8.4.3 WCCHOST1での管理サーバーの起動

管理サーバーは、ノード・マネージャを使用して起動および停止します。ただし、初めてノード・マネージャで管理サーバーを起動するときに、Fusion Middleware構成ウィザードによってノード・マネージャに設定されたデフォルトのユーザー名およびパスワードを変更する必要があります。したがって、初回の起動時には、管理サーバーの起動スクリプトを使用する必要があります。初回起動時は手順1から4までが必要で、それ以後の起動はすべて手順4のみが必要になります。

WCCHOST1で管理サーバーを起動する手順は次のとおりです。

1. WCCHOST1で、ドメイン・ディレクトリの起動スクリプトを使用して管理サーバーを起動します。

cd ASERVER_HOME/bin

./startWebLogic.sh

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

2. 管理コンソールを使用してノード・マネージャの資格証明を更新します。

1. Webブラウザを開き、http://ADMINVHN:7001/consoleにアクセスします。

2. weblogicとしてログインします。

3. 「ロックして編集」をクリックします。

4. 「domain_name」→「セキュリティ」→「一般」をクリックして、一番下にある「詳細」オプションを開きます。

5. ノード・マネージャの新しいユーザー名を入力するか、既存のユーザー名を書き留めておいてノード・マネージャのパスワードを更新します。

6. 変更を保存してアクティブ化します。

3. コマンドstopWebLogic.shを発行して、WebLogic Serverの管理サーバーを停止します。このコマンドは、ASERVER_HOME/binディレクトリの下にあります。
または、管理サーバーのプロセスを停止します。それには、このプロセスが起動されたシェルで[Ctrl]+[C]を使用するか、または標準のプロセス識別子とオペレーティング・システムのkillコマンドを使用します。

4. Oracle WebLogic Scripting Tool (WLST)を起動し、nmconnectおよび前の手順で設定した資格証明によりノード・マネージャに接続し、nmstartを使用して管理サーバーを起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

WLSTシェル内で、次のコマンドを実行します(ノード・マネージャが稼働していることを確認します)。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCHOST1","5556", "domain_name","ASERVER_HOME")

wls:/nm/domain_name> nmStart("AdminServer")

注意:

- WCCHOST1とは、ドメインを作成したノードのアドレスで、管理サーバーのリスニング・アドレスではありません。

- 値node_admin_userおよびnode_admin_passwordは、手順2eで更新したノード・マネージャの資格証明です。ノード・マネージャ管理者のユーザー名とパスワードはサーバー管理者のIDおよびパスワードとは関係なく、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらの資格証明は、ASERVER_HOME/config/nodemanager/nm_password.propertiesファイルに格納されます。

8.4.4 管理サーバー構成の検証

作成したドメインの管理サーバーが適切に構成されていることを確認するには、WebLogic Server管理コンソールにログインし、管理サーバーがリストされていることを確認します。これにより構成を検証してから、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. Webブラウザを開き、http://ADMINVHN:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. http://ADMINVHN:7001/emでFusion Middleware Controlにアクセスできることを確認します。

4. 第8.4.1項「WCCHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してFusion Middleware Controlにログインします。

管理サーバーが稼働している必要があります。

8.4.5 ホスト名検証の無効化

この手順は、管理サーバーでの様々なノードの認証に対して適切な証明書を設定していない場合に必要となります(第16章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、異なるWebLogic Serverインスタンスを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証を行う際に、管理サーバーと各管理対象サーバーに対するホスト名の検証を無効にし、第16章「エンタープライズ・デプロイメント用のノード・マネージャの設定」の説明に従ってエンタープライズ・デプロイメント・トポロジの構成を完了した後に再びホスト名の検証を有効にします。

サーバーが管理サーバーとともに稼働していれば、サーバーのホスト名の検証を無効化できます。

ホスト名検証を無効化するには:

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 左側の「ドメイン構造」ツリーで「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 「サーバーのサマリー」ページで、「サーバー」表の「名前」列にある管理サーバー名をクリックします。

6. このサーバーの「設定」ページで、「SSL」タブをクリックしてください。

7. 表示されたページの「詳細」セクションを開きます。

8. 「ホスト名の検証」を「なし」に設定します。

9. 「保存」をクリックします。

10. 変更を保存してアクティブ化します。

11. この変更内容を有効にするには、ノード・マネージャおよび管理サーバーを再起動する必要があります。

1. 次のコマンドを使用して、管理サーバーとノード・マネージャを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

2. ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。
シェルのフォアグラウンドで実行されている場合は、[Ctrl]キーを押しながら[C]を押します。

シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、killコマンドを使用して停止します。例:

ps -ef | grep NodeManager
orcl   9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh

kill -9 9139

3. ノード・マネージャを起動します。

cd WL_HOME/server/bin
nohup ./startNodeManager.sh > nm.out&

参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

4. 次の手順で管理サーバーを再起動します。

- Oracle WebLogic Scripting Tool (WLST)を起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

- WLSTシェル内で、nmConnectコマンドとノード・マネージャの資格証明を使用してノード・マネージャに接続し(ノード・マネージャが稼動していることを確認しておきます)、nmStartを使用してノード・マネージャおよび管理サーバーを起動します。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCHOST1","5556", "domain_name","ASERVER_HOME")

wls:/nm/domain_name> nmStart("AdminServer")

値node_admin_userおよびnode_admin_passwordは、ノード・マネージャの資格証明です。資格証明の詳細は、第8.4.3項「WCCHOST1での管理サーバーの起動」を参照してください。

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

8.4.6 WCCHOST2のMiddlewareホームへのドメイン・レジストリ・ファイルのコピー

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されているように、WCCHOST2上のMiddlewareホームは、インストール・バイナリ・ボリュームに最大の冗長性を提供する、別の記憶域ボリューム(WCCHOST2に対してローカル)上にあります。管理サーバー・ドメインの作成中にWCCHOST1上で作成されたdomain-registry.xmlファイルは、WCCHOST2では作成されません。このファイルはWCCHOST1からコピーする必要があります。

WCCHOST1上のMiddlewareホームからWCCHOST2上のMiddlewareホームにドメイン・レジストリ・ファイルをコピーする手順は次のとおりです。

1. WCCHOST1のMiddlewareホーム・ディレクトリに移動します。

cd MW_HOME

参照トポロジで、MW_HOMEは/u01/oracle/products/fmw_homeディレクトリです。

2. 次のコマンドを使用して、domain-registry.xmlファイルをWCCHOST2のMiddlewareホームにコピーします。

scp domain-registry.xml oracle@WCCHOST2:MW_HOME/

3. 次のコマンドを使用して、nodemanger.domainsファイルをWCCHOST1からWCCHOST2にコピーします。

scp WL_HOME/common/nodemanager/nodemanager.domains oracle@WCCHOST2:WL_HOME/common/nodemanager/

参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

8.5 Oracle DatabaseのOPSSセキュリティ・ストアとドメインの再関連付け

OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、資格証明、およびキーに関するリポジトリです。この集中化により、ポリシー、資格証明、およびキーに関するデータの管理と保守が容易になります。Oracle Fusion Middlewareでは、Oracle WebLogic Serverドメインに対して異なるタイプのセキュリティ・ストアの使用が許可されています。ドメインでは、XMLファイル(デフォルト)、Oracle DatabaseまたはOracle Internet Directoryに基づいたセキュリティ・ストアを使用できます。

エンタープライズ・デプロイメント・トポロジでは、ポリシー、資格証明およびキーのための一元化されたセキュリティ・ストアが必要です。Oracle WebCenter Contentドメインのセキュリティ・ストアをOracle Database 11g リリース2 (11.2)のOPSSセキュリティ・ストアに再関連付けすることをお薦めします。

OPSSセキュリティ・ストアの再関連付けとは、ポリシー、資格証明、およびキー・ストアをリポジトリ間で再配置することです。再関連付けでは、格納データの整合性を維持しながらリポジトリが変更されます。再関連付けでは、各セキュリティ・アーティファクトに対して、ターゲット・ストアを検索し、一致するストアが見つかった場合は、一致するアーティファクトが更新され、見つからない場合は、新しいアーティファクトが作成されます。

ソースは、ファイルベース、データベース・ベースまたはLDAPベース(Lightweight Directory Application Protocolプロバイダを使用)にできます。ターゲットは、データベース・ベースまたはLDAPベースにできます。LDAPタイプのターゲットでは、Oracle Internet Directoryのみがサポートされ、データベース・タイプのターゲットでは、Oracle Database 11.2.0.1以降のみがサポートされています。Oracle Internet Directoryの使用方法の詳細は、第18.2項「アイデンティティ・ストアと外部LDAP認証プロバイダの再関連付け」を参照してください。

この処理を行う場合、次に示す手順でOracle Enterprise Manager Fusion Middleware ControlまたはOracle WebLogic Scripting Tool (WLST)のいずれかのreassociateSecurityStoreコマンドを使用できます。

8.5.1 ドメインとデータベース・ベースのOPSSセキュリティ・ストアの再関連付けの準備

OPSSセキュリティ・ストアを再関連付けする前に、構成ファイルのバックアップ、OPSSスキーマが正しく作成されていることの確認およびOPSSデータ・ソースの作成を行う必要があります。

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

念のため、OPSSセキュリティ・ストアを変更する前に、次のように、関連する構成ファイルをバックアップする必要があります。

1. 次のドメイン構成ファイルをバックアップします。

ASERVER_HOME/WCCDomain/config/config.xml
ASERVER_HOME/WCCDomain/config/fmwconfig/jps-config.xml
ASERVER_HOME/WCCDomain/config/fmwconfig/system-jazn-data.xml

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

2. 管理サーバーのboot.propertiesファイルをバックアップします。

ASERVER_HOME/servers/AdminServer/security/boot.properties

8.5.1.2 Oracle DatabaseでのOPSSスキーマの確認

OPSSセキュリティ・ストアを再関連付けする前に、第5.4項「データベース・スキーマの作成」の説明に従い、リポジトリ作成ユーティリティ(RCU)を使用してOracle DatabaseでOPSSスキーマが作成されていることを確認する必要があります。

Oracle DatabaseでOPSSスキーマを確認する手順は次のとおりです。

1. 次のように、SQL*Plusにログインします。

ORACLE_HOME/bin/sqlplus sys/password as SYSDBA

SQL>

参照トポロジで、ORACLE_HOMEは/u01/oracle/products/fmw_home/wcc_homeディレクトリです。

2. 次のSQL*Plusコマンドを実行して、データベース・スキーマが正しく作成されていることを確認します。

SQL>desc WCC_OPSS.jps_dn;
Name Null? Type
----------------------------------------- -------- ----------------------------
ENTRYID NOT NULL NUMBER
RDN NOT NULL VARCHAR2(1024)
PARENTDN NOT NULL VARCHAR2(1024)

SQL>

8.5.2 ファイルベースOPSSセキュリティ・ストアとデータベース・ベースOPSSセキュリティ・ストアの再関連付け

ドメインのデフォルトのファイルベースOPSSセキュリティ・ストアをデータベース・ベースOPSSセキュリティ・ストアに再関連付けする手順は次のとおりです。

1. WCCHOST1からwlstシェルを起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

2. 次のwlst connectコマンドを使用して、WebLogic Server管理サーバーに接続します。
構文:

connect("admin_user","admin_password","t3://hostname:port")

例:

wls:/offline> connect ("weblogic","welcome1","t3://ADMINVHN:7001")
Connecting to t3://ADMINVHN:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'WCCDomain'.

Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.

3. reassociateSecurityStoreコマンドを次のように実行します。
構文:

reassociateSecurityStore(domain="domain_name",servertype="DB_ORACLE",datasourcename="opss_datasource_name", jpsroot="cn=jpsroot_wcc")

例:

wls:/WCCDomain/serverConfig>

reassociateSecurityStore(domain="WCCDomain",servertype="DB_ORACLE",datasourcename="jdbc/OPSSDBDS", jpsroot="cn=jpsroot_wcc")

コマンドの出力は次のとおりです。

Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

Starting policy store reassociation.
The store and ServiceConfigurator setup done.
Schema is seeded into the store
Data is migrated to the store. Check logs for any failures or warnings during migration.
Data in the store after migration has been tested to be available
Update of in-memory jps configuration is done
Policy store reassociation done.
Starting credential store reassociation
The store and ServiceConfigurator setup done.
Schema is seeded into the store
Data is migrated to the store. Check logs for any failures or warnings during migration.
Data in the store after migration has been tested to be available
Update of in-memory jps configuration is done
Credential store reassociation done
Starting Keystore reassociation
The store and ServiceConfigurator setup done.
Schema is seeded into the store
Data is migrated to the store. Check logs for any failures or warnings during migration.
Data in the store after migration has been tested to be available
Update of in-memory jps configuration is done
Keystore reassociation done
Starting audit store reassociation
The store and ServiceConfigurator setup done.
Schema is seeded into the store
Data is migrated to the store. Check logs for any failures or warnings during migration.
Data in the store after migration has been tested to be available
Update of in-memory jps configuration is done
Audit store reassociation done
Jps Configuration has been changed. Please restart the application server.
wls:/WCCDomain/serverConfig>

4. コマンドが正しく実行されたら、次の手順に従って管理サーバーを再起動します。

1. Oracle WebLogic Scripting Tool (WLST)を起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

2. 管理コンソールまたは次のようにノード・マネージャのnmKillコマンドを使用して管理サーバーを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

3. nmstartを使用して管理サーバーを起動します。

wls:/nm/domain_name> nmStart("AdminServer")

注意:
管理サーバーのログにはOPSSS監査警告メッセージが含まれていますが、これらは無視しても問題ありません。

5. セキュリティ・ストアの再関連付けを次のように検証します。

1. 新しいドメインのために、次のURL(参照トポロジ)のOracle Enterprise Manager Fusion Middleware Controlにログインします。

http://ADMINVHN:7001/em

2. 「WebLogicドメイン」を開き、「WCCDomain」をクリックします。

3. 「WCCDomain」ページの「WebLogicドメイン」メニューから、「セキュリティ」→「セキュリティ・プロバイダ構成」を選択します。

4. 「セキュリティ・プロバイダ構成」ページの「セキュリティ・ストア」表で、「ストア・タイプ」列の値が「Oracle Database」であることを確認します(図8-5参照)。

図8-5 Oracle Databaseセキュリティ・プロバイダ

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

ドメインを構成したら、第19.8項「管理サーバーの手動フェイルオーバーの確認」の手順に従ってフェイルオーバーのテストをします。

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

ドメインが正常に動作していることを確認した後、バックアップを実行して、ドメイン構成を保存します。これは、後述の章でドメインの拡張時の手順で問題が発生した場合に緊急のリストアを行うためのクイック・バックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。

バックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップに関する詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

この時点でのインストールおよび構成をバックアップする手順は次のとおりです。

1. 管理サーバーを停止し、そのドメイン・ディレクトリをバックアップすることでドメイン構成を保存します。構成ファイルはすべてASERVER_HOMEディレクトリにあります。WCCHOST1で次のコマンドを実行して、バックアップを作成します。

tar -cvpf edgdomainback.tar ASERVER_HOME

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

管理サーバーを停止するには、WLST nmKillコマンドを使用します。

1. Oracle WebLogic Scripting Tool (WLST)を起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

2. WLSTシェル内で、次のように、nmConnectコマンドとノード・マネージャの資格証明を使用してノード・マネージャに接続します(ノード・マネージャが稼動していることを確認しておきます)。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCHOST1","5556", "domain_name","ASERVER_HOME")

値node_admin_userおよびnode_admin_passwordは、ノード・マネージャの資格証明です。資格証明の詳細は、第8.4.3項「WCCHOST1での管理サーバーの起動」を参照してください。

3. nmKillコマンドを使用して、管理サーバーを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

2. データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。

3. nmstartを使用して管理サーバーを起動します。

wls:/nm/domain_name> nmStart("AdminServer")

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

この章では、Oracle WebCenter Contentの実装をサポートするOracle Web層の構成方法について説明します。

この章には次の項が含まれます:

- 第9.1項「Oracle Web層構成の概要」

- 第9.2項「構成ウィザードによるOracle HTTP Serverの構成」

- 第9.3項「インストールの検証」

- 第9.4項「Oracle HTTP Serverでのロード・バランサの構成」

- 第9.5項「仮想ホストの定義」

- 第9.6項「WebLogic ServerドメインのOracle HTTP Serverの構成」

9.1 Oracle Web層構成の概要

Oracle Web層ソフトウェアを構成する前に、第7.2項「Oracle HTTP Serverのインストール」の説明に従ってこのソフトウェアをWEBHOST1とWEBHOST2にインストールする必要があります。第9.2項「構成ウィザードによるOracle HTTP Serverの構成」の説明に従って、インスタンス・ホーム、インスタンス名およびOracle HTTP Serverコンポーネント名を定義します。

その後、インストールが成功したことを確認し、すべてのHTTPリクエストをWEBHOST1およびWEBHOST2にルーティングするようロード・バランサを構成できます。

最後に、構成ファイルのディレクティブを定義して、仮想ホストを構成できます。次の仮想ホスト名は、第3.3項「ロード・バランサ」でロード・バランサを構成したときに作成したものです。

- admin.example.com

- wcc.example.com

- wccinternal.example.com

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

Oracle Web層の構成手順は、WEBHOST1とWEBHOST2で同じです。

Oracle Web層を構成する手順は次のとおりです。

1. ディレクトリをWeb層の構成ウィザードの場所に変更します。

cd WT_ORACLE_HOME/bin

参照トポロジで、WT_ORACLE_HOMEは/u02/oracle/products/fmw_home/web_homeディレクトリです。

2. 構成ウィザードを起動します。

./config.sh

3. 「ようこそ」画面で、「次へ」をクリックします。

4. 「コンポーネントの構成」画面で「Oracle HTTP Server」を選択し、「選択されたコンポーネントとWebLogicドメインの関連付け」が選択されていることを確認します。「Oracle Web Cache」は選択されていないことを確認します。
「次へ」をクリックします。

5. 「WebLogicドメインの指定」画面で、次の値を指定します。

- ドメイン・ホスト名: ADMINVHN

- ドメインのポート番号: 7001

- ユーザー名: weblogic

- パスワード: password

6. 「コンポーネントの詳細の指定」画面で、次の値を指定します。

- インスタンス・ホームの場所: /u02/oracle/config/webn

- インスタンス名: webn

- OHSコンポーネント名: ohsn

(ここでnは、インストール上の連番を示します。たとえば、WEBHOST1には1、WEBHOST2には2などです。)

注意:
WEBHOST1とWEBHOST2で、異なるOracle HTTP Serverインスタンス名を指定する必要があります。

「次へ」をクリックします。

7. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択して、ファイル名を選択し、「表示/編集」をクリックします。
高可用性の実装では、様々なコンポーネントで使用されるポートのすべてを複数のホスト間で同期すると、エンタープライズ・デプロイメントがより簡単になります(必須ではありません)。使用するポートをファイルに指定することで、自動ポート構成をバイパスできます。

ファイルは次のようになります。

[OHS]
#Listen port for OHS component
OHS Port = 7777

[OPMN]
#Process Manager Local port no
OPMN Local Port = 1880

サンプルのstaticports.iniファイルは、インストール・ディスク1のstage/Response/ディレクトリにあります。

「次へ」をクリックします。

8. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。

9. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックして前の画面に戻り、選択内容を変更します。問題がなければ、「構成」をクリックします。

10. 複数のConfiguration Assistantが連続して起動されるため、時間がかかることがあります。終了したら、「次へ」をクリックします。

11. 「インストール完了」画面で「終了」をクリックして終了します。

9.3 インストールの検証

インストールが完了したら、Oracle HTTP Serverホーム・ページに、次のURLからアクセスできることを確認します。

http://WEBHOST1.example.com:7777/
http://WEBHOST2.example.com:7777/

9.4 ロード・バランサを使用したOracle HTTP Serverの構成

Oracle HTTP Server (WEBHOST1、WEBHOST2)を実行するホストへすべてのHTTPリクエストをルーティングするようロード・バランサを構成できます。Oracle HTTP ServerがフロントエンドのOracle WebLogic Serverである場合は、ロード・バランサでスティッキー・セッション(Cookieの挿入)を有効にする必要はありません。このドキュメントで説明するトポロジには該当しませんが、ロード・バランサからOracle WebLogic Serverに直接移動する場合にはスティッキー・セッションが必要です。HTTPの監視も設定する必要があります。

使用するロード・バランサによって、構成手順は異なります。具体的な手順は、ロード・バランサのドキュメントを参照してください。

9.5 仮想ホストの定義

このガイドの参照トポロジでは、Oracle HTTPサーバーに対する仮想ホスト・セットを定義する必要があります。各仮想ホストについては、後にWebLogicサーバー・ドメイン内の適切な管理サーバーまたは管理対象サーバーに要求をルーティングするための特定のURLセットを定義する必要があります。

この項で説明する項目は、次のとおりです。

- 第9.5.1項「*_vh.confファイルの作成による<VirtualHost>ディレクティブの定義」

- 第9.5.2項「構成の検証」

9.5.1 *_vh.confファイルの作成による<VirtualHost>ディレクティブの定義

すべてのORACLE_INSTANCE/ohsn/moduleconfディレクトリにある固有の*_vh.confファイルでそれぞれの仮想ホストを定義する必要があります。こうすることで、定義する個々の仮想ホストのURLの管理が容易になります。

次の新しいファイルで<VirtualHost>ディレクティブを定義します。

- admin_vh.conf

- wccinternal_vh.conf

- wcc_vh.conf

- wccui_vh.conf

参照トポロジで、次の各ディレクトリでこれらのファイルを作成します。

/u02/oracle/config/web1/config/OHS/ohs1/moduleconf

/u02/oracle/config/web2/config/OHS/ohs2/moduleconf

個々の仮想ホストをホスト自身の*_vh.confファイルに定義する手順は次のとおりです。

1. ORACLE_INSTANCE/ohsn/moduleconfディレクトリでadmin_vh.confファイルを作成し、次のディレクティブを追加します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName admin.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
RewriteRule ^/console/jsp/common/logout.jsp "/oamsso/logout.html?end_url=/console" [R]
</VirtualHost>

第18章「Oracle Identity Managementとの統合」の手順が完了していない場合は、統合が完了するまで、RewriteRuleの行をコメント・アウトします。

2. ORACLE_INSTANCE/ohsn/moduleconfディレクトリでwccinternal_vh.confファイルを作成し、次のディレクティブを追加します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName wccinternal.example.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

3. ORACLE_INSTANCE/ohsn/moduleconfディレクトリでwcc_vh.confファイルを作成し、次のディレクティブを追加します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://wcc.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

4. ORACLE_INSTANCE/ohsn/moduleconfディレクトリでwccui_vh.confファイルを作成し、次のディレクティブを追加します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://wcc.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

5. Oracle HTTPサーバーを両方とも再起動します。

cd /u02/oracle/config/webN/bin
opmnctl stopall
opmnctl startall

注意:
wcc.example.com:443、ServerAdmin you@your.address、admin.example.com:80などの値は、例を示すための値です。実際の環境に基づく値を入力してください。

9.5.2 構成の検証

次のURLにアクセスして、ロード・バランサとOracle HTTP Serverが正しく構成されていることを確認します。

- http://admin.example.com/index.html

- https://wcc.example.com/index.html

- http://wccinternal.example.com/index.html

これらのURLにアクセスできない場合は、第3.3項「ロード・バランサ」の手順を正しく実行していることを確認してください。

9.6 WebLogic ServerドメインのOracle HTTP Serverの構成

この項では、WebLogic ServerドメインにおけるOracle HTTP Serverの構成タスクおよびその構成の検証タスクについて説明します。

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

- 第9.6.1項「管理サーバー用のOracle HTTP Serverの構成」

- 第9.6.2項「WebLogic Serverプラグイン有効化フラグの有効化」

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

- 第9.6.4項「ロード・バランサを介したアクセスの検証」

9.6.1 管理サーバーでのOracle HTTP Serverの構成

Oracle HTTP Serverから管理サーバーへのルーティングを有効にするには、HTTPサーバーの構成に対応するマウント・ポイントを設定する必要があります。

管理サーバーでOracle HTTP Serverを構成する手順は次のとおりです。

1. WEBHOST1およびWEBHOST2上の各Webサーバーで、ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/admin_vh.confファイルおよびORACLE_INSTANCE/config/OHS/ohs2/moduleconf/admin_vh.confファイルに次の行を追加します。

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WebLogicPort 7001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WebLogicPort 7001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WebLogicPort 7001
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

2. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

/u02/oracle/config/webN/bin/opmnctl restartproc ias-component=ohsX

ias-componentに対して、WEBHOST1ではohs1を使用し、WEBHOST2ではohs2を使用します。

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

セキュリティのため、またロード・バランサがSSLリクエストを終了するため(Oracle HTTP ServerはリクエストをWebLogic Serverに非SSLとしてルーティングします)、ロード・バランサにSSLを構成した場合、そのドメインに対しWebLogic Serverプラグイン有効化フラグをオンにする必要があります。

WebLogic Serverプラグイン有効化フラグを有効にする手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左側のナビゲーション・ツリーでドメイン名をクリックします。

3. 「Webアプリケーション」タブを開きます。

4. 「ロックして編集」をクリックします。

5. 「WebLogicプラグインの有効化」チェック・ボックスを選択します。

6. 変更を保存してアクティブ化します。

7. 管理サーバーを再起動します(管理コンソールが特に要求しない場合でも再起動してください)。

1. Oracle WebLogic Scripting Tool (WLST)を起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

2. WLSTシェル内で、nmConnectコマンドとノード・マネージャの資格証明を使用してノード・マネージャに接続し(ノード・マネージャが稼動していることを確認しておきます)、nmStartを使用してノード・マネージャを起動します。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCHOST1","5556", "domain_name","ASERVER_HOME")

wls:/nm/domain_name> nmStart("AdminServer")

値node_admin_userおよびnode_admin_passwordは、ノード・マネージャの資格証明です。資格証明の詳細は、第8.4.3項「WCCHOST1での管理サーバーの起動」を参照してください。

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

3. 管理コンソールまたは次のようにWLST nmKillコマンドを使用して管理サーバーを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

4. nmStartを使用して管理サーバーを起動します。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCHOST1","5556", "domain_name","ASERVER_HOME")

wls:/nm/domain_name> nmStart("AdminServer")

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

ロード・バランサを使用してWebLogic Server管理コンソールにアクセスする際には、管理サーバーのフロントエンドURLを変更し、適切なロード・バランサ・アドレスにユーザーのWebブラウザをリダイレクトする必要があります。

WebLogic Server管理コンソール・アプリケーションでは、コンソールを使用して、ポート、チャネル、セキュリティに対する変更を追跡します。コンソールを使用して行われた変更をアクティブ化するとき、コンソールは現在のリスニング・アドレス、ポートおよびプロトコルを検証します。このリスニング・アドレス、ポートおよびプロトコルがまだ有効の場合、コンソールはHTTPリクエストをリダイレクトし、ホストとポートの情報を管理サーバーのリスニング・アドレスとポートに置き換えます。

管理サーバーのフロントエンドURLを変更する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 「サーバーのサマリー」ページで、表の「名前」列にある「管理サーバー」をクリックします。

6. AdminServerの設定ページで、「プロトコル」タブをクリックします。

7. 「HTTP」タブをクリックします。

8. 「フロントエンド・ホスト」フィールドをadmin.example.comに設定し、「フロントエンドHTTPポート」フィールドを80に設定します(admin URLにHTTPSを使用する場合は適宜変更します)。

9. 変更を保存してアクティブ化します。

10. 管理サーバーを再起動して、フロントエンド・ホスト・ディレクティブに対する変更を有効にします。

注意:
フロントエンド・ホストやポートの設定を変更した後、構成の変更をアクティブ化できない場合は、第19.13.10項「Oracle Access Managerに対する変更をアクティブ化した後でユーザーが管理コンソールのホーム・ページにリダイレクトされる」を参照してください。

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

管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」を参照してください。

次のURLを使用して、ロード・バランサを介した管理コンソールとOracle Enterprise Manager Fusion Middleware Controlへのアクセスを検証します。

- http://admin.example.com/console

- http://admin.example.com/em

ロード・バランサを使用してシステム・アクセスを構成する方法の詳細については、第3.3項「ロード・バランサ」を参照してください。

Oracle HTTP ServerはFusion Middleware Controlで管理可能なターゲットとして表示されます。これを確認するには、Fusion Middleware Controlにログインします。ナビゲーション・ツリーにある「WebTier」項目に、該当のOracle HTTP Serverが登録されていることが示されます。

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

この章では、Fusion Middleware構成ウィザードを使用して、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成するドメインを拡張し、Oracle WebCenter Content (Oracle WebCenter Content Serverを含む)を追加する方法について説明します。次の章の説明に従うと、作成されたドメインを拡張し、他のOracle Fusion Middlewareコンポーネントを追加できます。

この章には次の項が含まれます:

- 第10.1項「WebCenter Contentを追加するためのドメイン拡張の概要」

- 第10.2項「WebCenter Contentを使用するためのドメインの拡張」

- 第10.3項「管理サーバーの再起動」

- 第10.4項「WebCenter Content用の構成後タスクおよび検証タスクの実行」

- 第10.5項「WebCenter Contentユーザー・インタフェース用のコンテンツ・サーバーの構成」

- 第10.6項「WebCenter Contentクラスタと使用するOracle HTTP Serverの構成」

- 第10.7項「WLS_WCC管理対象サーバー用のノード・マネージャの構成」

- 第10.8項「インストールのバックアップ」

注意:
セットアップのプロセスを開始する前に、各プラットフォームのOracle Fusion Middlewareリリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。

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

Oracle WebCenter Contentシステムは、第7章「エンタープライズ・デプロイメント用のソフトウェアのインストール」で作成された、共有記憶域でのWebLogic ServerホームおよびOracleホームの場所を使用してインストールされます。

Oracle WebCenter Contentを追加するためのドメインを拡張します。表10-1に、WebCenter Contentの構成手順と、WebCenter Content管理対象サーバーを含むドメインの拡張に必要なタスクを示します。

表10-1 WebCenter Contentを含むドメインの拡張手順

手順

説明

詳細

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

Oracle WebCenter Contentを追加するには、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogic Serverドメインを拡張します。

第10.2項「WebCenter Contentを使用するためのドメインの拡張」

WebCenter Content管理対象サーバーのノード・マネージャの起動

setNMProps.shスクリプトを実行し、WCCHOST1およびWCCHOST2のノード・マネージャを起動します。

第10.4.1項「WCCHOST2でのノード・マネージャの起動」

WebCenter Content管理対象サーバーへのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第10.4.2項「WLS_WCC1およびWLS_WCC2へのドメイン構成の伝播」

ドメインの管理サーバーの再起動

管理サーバーを停止し、再起動します。

第10.3項「管理サーバーの再起動」

1台目のWebCenter Content管理対象サーバーの起動およびコンテンツ・サーバーのインスタンスの構成

WLS_WCC1管理対象サーバーを起動し、コンテンツ・サーバーの初期構成を完了します。

第10.4.3項「WLS_WCC1管理対象サーバーの起動とコンテンツ・サーバーの構成」

cwallet.ssoファイルの変更を元の管理サーバーに伝播

更新されたcwallet.ssoファイルを管理サーバー・ディレクトリにコピーします。

第10.4.4項「管理サーバーのcwalletファイルの更新」

2台目のWebCenter Content管理対象サーバーの起動およびコンテンツ・サーバーのインスタンスの構成

WLS_WCC2管理対象サーバーを構成し、コンテンツ・サーバーの初期構成を完了します。

第10.4.5項「WLS_WCC2管理対象サーバーの起動とコンテンツ・サーバーの構成」

GridLinkデータ・ソースおよびOracle Notification Service (ONS)の構成の確認

GridLinkデータ・ソースおよびONSの構成が適切であることを確認する手順に従います。

第10.4.6項「WebCenter ContentのGridLinkデータ・ソースの検証」

クラスタ・ノードのパラメータを構成

必要に応じて、WebCenter Contentのトレースおよびイベント・ログ用に、ディレクトリの場所を追加します。

第10.4.7項「その他のパラメータの構成」

Oracle RACフェイルオーバー後のサービス再試行の有効化

コンテンツ・サーバーのconfig.cfgファイルでServiceAllowRetry構成パラメータをtrueに設定します。

第10.4.8項「Oracle WebCenter Contentのサービス再試行の構成」

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

管理対象サーバーとともにOracle HTTP Serverを構成し、フロントエンドHTTPのホストおよびポートの設定およびWCC_ClusterのWebLogic Serverクラスタ・アドレスの設定を行います。

第10.6項「WebCenter Contentクラスタと使用するOracle HTTP Serverの構成」

Oracle HTTP Serverを介したWebCenter Contentへのアクセスの検証

URLを検証し、Oracle HTTP ServerからWCC_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

第10.6.3項「ロード・バランサを介したアクセスの検証」

ドメインの管理対象サーバーとノード・マネージャ間通信に対するホスト名検証の構成

管理サーバーや他のサーバーとの通信には、それぞれのアドレス用の証明書を使用します。

第10.7項「WLS_WCC管理対象サーバー用のノード・マネージャの構成」

WebCenter Contentの構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第10.8項「インストールのバックアップ」

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを拡張して、Oracle WebCenter Contentを追加できます。

注意:
これらの手順を実行する前に、Oracle Fusion Middleware管理者ガイドの説明に従ってドメインをバックアップしてください。

WebCenter Contentを使用するためにドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。
Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. WCCHOST1で、ディレクトリをFusion Middleware構成ウィザードの場所に変更します。これはOracle共通ホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行します)。

cd ORACLE_COMMON_HOME/common/bin

3. Fusion Middleware構成ウィザードを起動します。

./config.sh

4. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

5. 「WebLogicドメイン・ディレクトリの選択」画面で、WebLogic Serverのドメイン・ディレクトリ(ASERVER_HOME)を選択し、「次へ」をクリックします。

6. 「拡張ソースの選択」画面(図10-1)で、次の選択を行います。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。
Oracle Universal Content Management - Content Server

これがOracle WebCenter Contentの選択肢です。

図10-1 WebCenter Contentの「拡張ソースの選択」画面

次の製品は、ドメインを作成した際(第8.3項)に選択している場合、グレー表示されます。

- WebLogic Serverの基本ドメイン

- Oracle Enterprise Manager

- Oracle JRF

「次へ」をクリックします。

7. 「JDBCコンポーネント・スキーマの構成」画面(図10-2)で、次の手順を実行します。

1. (WebCenter Contentの)UCMスキーマを選択します。

図10-2 WebCenter Contentの「JDBCコンポーネント・スキーマの構成」画面

2. RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます(付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照)。ここでの説明に合せて、「GridLinkへ変換」を選択します。
RAC構成を選択すると、選択されたすべてのスキーマがグレー表示されます。

3. 「次へ」をクリックします。

8. 「GridLink RACコンポーネント・スキーマの構成」画面(図10-3)で、次の手順を実行します。

1. UCMスキーマが選択されていることを確認します。

図10-3 WebCenter Contentの「GridLink RACコンポーネント・スキーマの構成」画面

2. 次の各フィールドに値を入力して、RCUでシードされたGridLink RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 11以上を選択します。

- サービス名: Oracle RACデータベースのサービス名は小文字で入力し、ドメイン名を続けます(例: wccedg.example.com)。

- ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてWCCを使用しています。

- パスワード: データベース・スキーマの所有者のパスワードを入力します。

- 「FANの有効化」を選択します。

- SSLの有効化: このオプションは選択解除したままにします。
SSLを選択してOracle Notification Service (ONS)の通知暗号化を有効にする場合は、「ウォレット・ファイル」および「ウォレット・パスワード」の詳細を適切に指定します。

- サービス・リスナー: 使用するOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。プロトコルはTCPである必要があります。
SCANアドレスを使用してサービス・リスナー(およびOSNホスト)を指定することをお薦めします。これにより、Oracle RACノードを追加または削除しても、SCANアドレスを含むGridLinkデータ・ソースを更新する必要がありません。SCANアドレスを特定するには、データベース内のremote_listenerパラメータを問い合せます。

SQL>show parameter remote_listener;

NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      db-scan.example.com:1521

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベース・インスタンス・リスナーの仮想IPアドレスとポートを使用します。

wccdbhost1-vip.example.com (port 1521)

wccdbhost2-vip.example.com (1521)

マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データソースの使用」を参照してください。

- ONSホスト: データベースによって報告されるRACデータベースのSCANアドレスとONSリモート・ポートも入力します。

[orcl@WCCDBHOST2~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベースのONSサービスのホスト名とポートを使用します。

wccdbhost1.example.com (port 6200)

wccdbhost2.example.com (6200)

3. 「次へ」をクリックします。

9. 「JDBCコンポーネント・スキーマのテスト」画面(図10-4)で、「UCMスキーマ」行を選択し、「接続のテスト」をクリックします。
結果は「接続結果ログ」に表示されます。スキーマを含むデータベースへの接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正してテストを再試行します。

図10-4 WebCenter Contentの「JDBCコンポーネント・スキーマのテスト」画面

接続に成功したら、「次へ」をクリックします。

10. 「オプションの構成を選択」画面で、次のオプションを選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

11. 「管理対象サーバーの構成」画面(図10-5)で、必要な管理対象サーバーを追加します。

図10-5 WebCenter Contentの「管理対象サーバーの構成」画面

サーバーが自動的に作成されます。このサーバーの名前をWLS_WCC1に変更し、WLS_WCC2という新しいサーバーを追加します。表10-2に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは変更しないでください。

表10-2 WebCenter Contentの管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_WCC1

WCCHOST1

16200

n/a

いいえ

WLS_WCC2

WCCHOST2

16200

n/a

いいえ

「次へ」をクリックします。

12. 「クラスタの構成」画面(図10-6)で、「追加」をクリックし、WCC_Cluster(表10-3を参照)と入力します。

表10-3 WebCenter Contentのクラスタ構成

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

WCC_Cluster

ユニキャスト

n/a

n/a

空のままにします。

図10-6 WebCenter Contentの「クラスタの構成」画面

「次へ」をクリックします。

13. 「サーバーのクラスタへの割当」画面で、WCC_Clusterに次のサーバーを割り当てます。

- WLS_WCC1

- WLS_WCC2

「次へ」をクリックします。

14. 「マシンの構成」画面で「Unixマシン」タブを開き、次の2つのマシンを追加します。

表10-4 WebCenter Contentのマシン

名前

ノード・マネージャのリスニング・アドレス

WCCHOST1

WCCHOST1

WCCHOST2

WCCHOST2

ADMINHOST

localhost

他のフィールドはすべてデフォルト値のままにします。マシン名は有効なホスト名やリスニング・アドレスである必要はありません。これらはノード・マネージャの場所を示す一意の識別子です。

「次へ」をクリックします。

15. 「サーバーのマシンへの割当」画面(図10-7)で、次のようにサーバーをマシンに割り当てます。

- WLS_WCC1をWCCHOST1に割り当てます。

- WLS_WCC2をWCCHOST2に割り当てます。

図10-7 WebCenter Contentの「サーバーのマシンへの割当」画面

「次へ」をクリックします。

16. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のようにターゲット設定されていることを確認します。

- DMS ApplicationがWCC_ClusterとAdminServerにターゲット指定されていること。

- EMアプリケーションは、AdminServerにのみターゲット設定します。

「次へ」をクリックします。

17. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、図10-85に示すようにWCC_ClusterにデプロイされるすべてのOPSS関連のデータ・ソースを選択します。

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

図10-8 サービスのWebCenter Contentクラスタへのターゲット設定

「次へ」をクリックします。

18. 「構成のサマリー」画面で、「拡張」をクリックします。

19. ドメインのポートの競合に関する警告ダイアログが表示された場合、「OK」をクリックします。

20. 「ドメインの作成中」画面で、「完了」をクリックします。

10.3 管理サーバーの再起動

ドメイン拡張の変更を有効にするには、Oracle WebLogic Scripting Tool (WLST)でノード・マネージャのnmKillコマンドとnmStartコマンドを使用して管理サーバーを再起動する必要があります。nmKillのかわりに管理コンソールを使用して管理サーバーを停止することもできます。再起動後に、weblogicユーザーの資格証明を使用して管理コンソールにログインします。

管理サーバーを再起動する手順は次のとおりです。

1. Oracle WebLogic Scripting Tool (WLST)を起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

2. WLSTシェル内で、nmConnectコマンドとノード・マネージャの資格証明を使用してノード・マネージャに接続し(ノード・マネージャが稼動していることを確認しておきます)、nmStartを使用してノード・マネージャを起動します。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCHOST1","5556", "domain_name","MSERVER_HOME")

wls:/nm/domain_name> nmStart("AdminServer")

値node_admin_userおよびnode_admin_passwordは、ノード・マネージャの資格証明です。資格証明の詳細は、第8.4.3項「WCCHOST1での管理サーバーの起動」を参照してください。

参照トポロジで、MSERVER_HOMEは/u02/oracle/config/domains/WCCDomainディレクトリです。

3. 管理コンソールまたは次のようにノード・マネージャのnmKillコマンドを使用して管理サーバーを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

4. nmStartを使用して管理サーバーを起動します。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCHOST1","5556", "domain_name","ASERVER_HOME")

wls:/nm/domain_name> nmStart("AdminServer")

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

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

次の項では、WebCenter Content用の構成後タスクと検証タスクを実行する方法について説明します。

- 第10.4.1項「WCCHOST2でのノード・マネージャの起動」

- 第10.4.2項「WLS_WCC1およびWLS_WCC2へのドメイン構成の伝播」

- 第10.4.3項「WLS_WCC1管理対象サーバーの起動とコンテンツ・サーバーの構成」

- 第10.4.4項「管理サーバーのcwalletファイルの更新」

- 第10.4.5項「WLS_WCC2管理対象サーバーの起動とコンテンツ・サーバーの構成」

- 第10.4.6項「WebCenter ContentのGridLinkデータ・ソースの検証」

- 第10.4.7項「その他のパラメータの構成」

- 第10.4.8項「Oracle WebCenter Contentのサービス再試行の構成」

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

WCCHOST2でノード・マネージャが起動されていない場合は、起動する必要があります。

WCCHOST2でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、WCCHOST2でORACLE_COMMON_HOME/common/bin/ディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

cd ORACLE_COMMON_HOME/common/bin

./setNMProps.sh

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

2. WCCHOST2で次のコマンドを実行し、ノード・マネージャを起動します。

cd WL_HOME/server/bin

nohup ./startNodeManager.sh > nm.out&

参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

10.4.2 WLS_WCC1およびWLS_WCC2へのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

WebCenter Content管理対象サーバーにドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain= ASERVER_HOME -template=edgdomaintemplateWCC.jar -template_name=edgdomain_templateWCC

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

3. 次のunpackコマンドをWCCHOST1で実行して、前の手順で作成したテンプレートをWLS_WCC1ドメイン・ディレクトリに伝幡します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain= MSERVER_HOME -template=edgdomaintemplateWCC.jar -app_dir= APPLICATION_HOME -overwrite_domain=true

参照トポロジで、MSERVER_HOMEは/u02/oracle/config/domains/WCCDomainディレクトリで、APPLICATION_HOMEは/u01/oracle/config/applications/WCCDomainディレクトリです。

注意:

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

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

- unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

- APPLICATION_HOMEディレクトリは、このunpackコマンドでバックアップされます。

- APPLICATION_HOMEはアプリケーション・サーバーおよび管理対象サーバーで共有するには、unpackコマンドでオプション-overwrite_domain=trueを使用します。

- unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびEARファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびEARファイルをリストアする必要があります。

4. 次のコマンドをWCCHOST1で実行し、手順1で作成したテンプレート・パックをWCCHOST2にコピーします。

scp edgdomaintemplateWCC.jar oracle@WCCHOST2:ORACLE_COMMON_HOME/common/bin

5. 次のunpackコマンドをWCCHOST2で実行して、伝播されたテンプレートをWLS_WCC2管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateWCC.jar -app_dir=APPLICATION_HOME

注意:

- unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

- APPLICATION_HOMEディレクトリは、このunpackコマンドでバックアップされます。

6. ここまでの変更を有効にするために管理サーバーを再起動します。まずnmKillコマンドまたは管理コンソールで管理サーバーを停止し、次にnmStartコマンドで起動します(第10.3項「管理サーバーの再起動」を参照)。再起動後に、weblogicユーザーの資格証明を使用して管理サーバーにログインします。

10.4.3 WLS_WCC1管理対象サーバーの起動とコンテンツ・サーバーの構成

WLS_WCC1管理対象サーバーの起動後、Webインタフェースを介してコンテンツ・サーバーを構成できます。

WLS_WCC1管理対象サーバーを起動する手順は次のとおりです。

1. http://admin.example.com:7001/consoleでOracle WebLogic Server管理コンソールにログインします。

2. 次の手順に従い、管理コンソールを使用してWLS_WCC1管理対象サーバーを起動します。

1. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

2. 「サーバー」をクリックします。

3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

4. 表の「サーバー」列から「WLS_WCC1」を選択します。

5. 「起動」をクリックします。

3. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

- サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。

- 「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」を参照してください。

コンテンツ・サーバーを構成する手順は次のとおりです。

1. http://WCCHOST1:16200/csでWebLogic Serverの管理ユーザー名とパスワードを使用してWLS_WCC1にログインし、構成ページを表示します。

注意:
WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Contentエンタープライズ・デプロイメントの共有ディスクの場所は、ASERVER_HOME/WCC_Clusterディレクトリです。
参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

2. サーバー構成ページで次の値を設定します(すべてのオプションを参照するには、「コンテンツ・サーバーの新規インスタンス」チェック・ボックスを選択してください)。

- コンテンツ・サーバーのインスタンス・フォルダ: /u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs
構成を保存する前に、このディレクトリが存在しているか作成済であることを確認してください。

- ネイティブ・ファイル・リポジトリの場所: /u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/vault
構成を保存する前に、このディレクトリが存在しているか作成済であることを確認してください。

- Webレイアウト・フォルダ: /u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/weblayout
構成を保存する前に、このディレクトリが存在しているか作成済であることを確認してください。

- ユーザー・プロファイル・フォルダ: /u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/data/users/profiles
構成を保存する前に、このディレクトリが存在しているか作成済であることを確認してください。

- サーバーのソケット・ポート: 4444

- ソケット接続アドレス・セキュリティ・フィルタを着信中: 次に示すような、ローカル・ホストとサーバーIPアドレスのパイプ区切り一覧

127.0.0.1|WCCHOST1-IP|WCCHOST2-IP|WEBHOST1-IP|WEBHOST2-IP|WCCUIHOST1|WCCUIHOST2|ucminternal.example.com|load-balancer-host-name

注意:
これは後でホスト名ベースのリストに変更されます(第13.5.11項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」を参照)。この時点では、セキュリティ・フィルタがホスト名に変更されるようにするために、実行する操作用の接続が事前に許可されている必要があります。

- WebサーバーのHTTP/HTTPSアドレス: wcc.example.com:443

- WebアドレスはHTTPSです: このチェック・ボックスを選択します。

- コンテンツ・サーバーのインスタンス名: WCC_Cluster

- コンテンツ・サーバーのインスタンス・ラベル: WCC_Cluster

- サーバー・インスタンスの説明: WebCenter Contentクラスタ

- 自動採番接頭辞: WCC_Cluster-

3. 完了したら「送信」をクリックし、WebLogic Server管理コンソールを使用して管理対象サーバーを再起動します。

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

コンテンツ・サーバーは、起動時にMSERVER_HOME/config/fmwconfigディレクトリにあるcwallet.ssoファイルを更新します。この変更は、元の管理サーバーに伝播する必要があります。これを行うには、WCCHOST1で次のコマンドを(すべて1行で)使用して、このファイルをWCCHOST1のASERVER_HOME/config/fmwconfigにコピーします。

cp -p MSERVER_HOME/config/fmwconfig/cwallet.sso ASERVER_HOME/config/fmwconfig

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

注意:
WLS_WCCnサーバーでMSERVER_HOME/config/fmwconfig/ディレクトリにあるcwallet.ssoファイルを変更する操作を行った場合は、ASERVER_HOME/config/fmwconfigにあるWCCHOST1の管理サーバー・ドメイン構成ディレクトリにそのファイルをすぐにコピーする必要があります。

10.4.5 WLS_WCC2管理対象サーバーの起動とコンテンツ・サーバーの構成

WLS_WCC2管理対象サーバーの起動後、Webインタフェースを介してコンテンツ・サーバーを構成できます。

WLS_WCC2管理対象サーバーを起動する手順は次のとおりです。

1. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_WCC2管理対象サーバーを起動します。

1. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

2. 「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. 「WLS_WCC2」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」を参照してください。

コンテンツ・サーバーを構成する手順は次のとおりです。

1. http://WCCHOST2:16200/csでOracle WebLogic Serverの管理ユーザー名とパスワードを使用してWLS_WCC2にログインし、構成ページを表示します。

注意:
Oracle WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Contentエンタープライズ・デプロイメントの共有ディスクの場所は、ASERVER_HOME/WCC_Clusterです。
参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

2. 「サーバーの構成」ページで次の値を変更します。

- コンテンツ・サーバーのインスタンス・フォルダ: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/csに設定します。

- ネイティブ・ファイル・リポジトリの場所: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/vaultに設定します。

- Webレイアウト・フォルダ: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/weblayoutに設定します。

- ユーザー・プロファイル・フォルダ: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/data/users/profilesに設定します。

- コンテンツ・サーバーのURL接頭辞: /cs/ (デフォルト値)

「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。

3. 完了したら「送信」をクリックし、WebLogic Server管理コンソールを使用して管理対象サーバーを再起動します。

10.4.6 WebCenter ContentのGridLinkデータ・ソースの検証

サーバーを起動したら、GridLinkデータ・ソースが正しく構成され、ONS設定が正しいことを確認します。これらの手順を、作成した各GridLinkデータ・ソースで実行します。

WebCenter ContentのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. 作成したGridLinkデータ・ソースの名前をクリックします。

4. 「監視」タブをクリックします。

5. 「テスト」タブ(図10-9)をクリックし、いずれかのサーバーを選択し、「データ・ソースのテスト」をクリックします。

図10-9 WebCenter ContentのGridLinkデータ・ソースのテスト

構成が適切であればテストは成功します。

6. GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスでテストを繰り返します。

WebCenter ContentのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。

1. 管理コンソールの「ドメイン構造」ツリーで、「サービス」ノードを開いて「データ・ソース」をクリックします。

2. GridLinkデータ・ソースの名前をクリックします。

3. 「監視」タブをクリックします。

4. サーバーの名前(WLS_WCC1)をクリックします。

5. 「ONS」タブをクリックし、「テスト」タブ(図10-10)をクリックします。

6. サーバーを選択し、「ONSのテスト」をクリックします。

図10-10 WebCenter Contentの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テストを繰り返します。

10.4.7 その他のパラメータの構成

テキスト・エディタを使用して、次のオプションを各クラスタ・ノードの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のようにノードのサーバー名と一致している必要があります。

この変更は、第10.4.8項「Oracle WebCenter Contentのサービス再試行の構成」で説明される手順の最後に、すべてのWebCenter Content管理対象サーバーを再起動させてから有効になります。

注意:
ディレクトリは、WebCenter Contentログおよび任意のトレースを構成する場合は、ログおよびトレースを保持するために十分なスペースがあると判断される任意のローカル・ディスク・パスに配置できます。前述のパスは一案です。

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

Oracle RACのフェイルオーバー時にログインの再試行を可能にするため、コンテンツ・サーバーのconfig.cfgファイル内の次のパラメータを設定する必要があります。

ServiceAllowRetry=true

この値が設定されていない場合、フェイルオーバーが開始されたときに、ユーザーは処理中の任意の操作を手動で再試行する必要があります。

Oracle WebCenter Contentのサービス再試行を構成する手順は次のとおりです。

1. コンテンツ・サーバー(http://WCCHOST1:16200/cs)にアクセスし、WebLogic Serverの管理ユーザー名とパスワードを使用してログインします。

2. 「管理」トレイまたはメニューで、「管理サーバー」、「一般構成」の順に選択します。

3. 「一般構成」ページで、「追加の構成変数」ボックスに、次のパラメータを追加します。

ServiceAllowRetry=true

4. 「保存」をクリックしたら、WebLogic Server管理コンソールを使用してすべてのWebCenter Content管理対象サーバーを再起動します。

注意:
新しいパラメータはconfig.cfgファイルに含まれます。このファイルは次の場所にあります。

/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfg

(このファイルをテキスト・エディタで直接編集することもできます。必ずすべてのWebCenter Content管理対象サーバーを再起動してください。)

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

WebCenter Contentユーザー・インタフェースを使用する予定である場合(コンテンツ・サーバーのネイティブ・ユーザー・インタフェースに加えて)、次のコンテンツ・サーバーのパラメータを有効にする必要があります。

- AutoSuggestConfig

- DynamicConverter

- FrameworkFolders

さらに、WebCenter Contentユーザー・インタフェースとコンテンツ・サーバー間の通信用にRemote Intradoc Client (RIDC)を設定する必要があります。

WebCenter Contentユーザー・インタフェースのフォルダおよび検索用に、次のコンテンツ・サーバーのパラメータも設定できます。

- FoldersIndexParentFolderValues=true

- FldEnforceFolderFileNameUniqueness=true

- FldEnforceCaseInsensitiveNameUniqueness=true

- SearchIndexerEngineName=OracleTextSearchまたはSearchIndexerEngineName=DATABASE.METADATA

詳細は、第15.2項「WebCenter Contentユーザー・インタフェースのインストールおよび構成の準備」を参照してください。

10.6 WebCenter Contentクラスタと使用するOracle HTTP Serverの構成

WLS_WCC1およびWLS_WCC2管理対象サーバーを含むWCC_ClusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。これにより、ロード・バランサを介した管理対象サーバーへのアクセスを検証できます。

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

- 第10.6.1項「WLS_WCC管理対象サーバー用のOracle HTTP Serverの構成」

- 第10.6.3項「ロード・バランサを介したアクセスの検証」

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

WLS_WCC管理対象サーバー用に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ファイルに次の行を追加します。

# UCM
<Location /cs>
WebLogicCluster WCCHOST1:16200,WCCHOST2:16200
SetHandler weblogic-handler
WLCookieName JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /adfAuthentication>
WebLogicCluster WCCHOST1:16200,WCCHOST2:16200
SetHandler weblogic-handler
WLCookieName JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /_ocsh>
WebLogicCluster WCCHOST1:16200,WCCHOST2:16200
SetHandler weblogic-handler
WLCookieName JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

参照トポロジで、ORACLE_INSTANCEは/u02/oracle/config/web1または/u02/oracle/config/web2ディレクトリです。

2. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

/u02/oracle/config/webN/bin/opmnctl restartproc ias-component=ohsX

ias-componentに対して、WEBHOST1ではohs1を使用し、WEBHOST2ではohs2を使用します。

10.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. 「WebLogicプラグインの有効化」のチェック・ボックスを選択します。

6. 「保存」ボタンをクリックして、変更内容を保存します。

7. 管理コンソールからWLS_WCC1管理対象サーバーを再起動します。

8. WLS_WCC2管理対象サーバーに対して手順2-6を実行します。

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

URLを検証して、Oracle HTTP ServerからWCC_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。

URLを検証する手順は次のとおりです。

1. WLS_WCC2が稼動している状態で、WebLogic Server管理コンソールを使用してWLS_WCC1を停止します。

2. http://wcc.example.com/csにアクセスし、正しく動作していることを確認します。

3. WebLogic Server管理コンソールからWLS_WCC1を起動します。

4. WebLogic Server管理コンソールでWLS_WCC2を停止します。

5. http://wcc.example.com/csにアクセスし、正しく動作していることを確認します。

クラスタ・ノードを検証できます。このクラスタ・ノードは、ロード・バランサを介してトラフィック・バランシングが行われ、再びWeb層を介してトラフィック・バランシングが行われた後で転送されるクラスタ・ノードです。

クラスタ・ノードを検証する手順は次のとおりです。

1. 管理ユーザーおよびパスワードの資格証明を使用して、次のWebCenter Contentページにログインします。

https://wcc.example.com/cs/idcplg?IdcService=CONFIG_INFO

2. 「管理」、「構成」を参照してinstanceページを表示します。

3. ページの「オプションとその他」セクションで、右側の「Javaプロパティ」をクリックします。

4. weblogic.Nameの値を確認します。
この値は、現在アクセスしているクラスタ・ノードを示します。

10.7 WLS_WCC管理対象サーバーのノード・マネージャの構成

ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第16章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照してください。その章の手順をOracle WebCenter Contentデプロイメントで実行する必要があります。

第16.3項「ノード・マネージャでのホスト名検証証明書の有効化」の手順は、次の表のホストとWebCenter Content管理対象サーバーに対して実行する必要があります。

ホスト名(HOST)

仮想IPアドレス(VIP)

サーバー名(WLS_SERVER)

WCCHOST1

n/a

WLS_WCC1

WCCHOST2

n/a

WLS_WCC2

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

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

1. WEBHOST1でOracle Web層をバックアップします。

1. opmnctlを使用してインスタンスを停止します。

/u02/oracle/config/webN/bin/opmnctl stopall

2. 次のコマンドをrootとして実行して、Oracle Web層のMiddlewareホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドを実行して、Oracle Web層のOracleインスタンスをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

4. 次のように、opmnctlを使用してインスタンスを起動します。

cd /u02/oracle/config/webN/bin
opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、あるいは可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。

3. ドメイン構成を保存するために、管理サーバーと管理対象サーバーのドメイン・ディレクトリをバックアップします。構成ファイルはすべて/u01/oracle/config/domains/WCCDomainディレクトリに存在しています。WCCHOST1で次のコマンドを実行して、バックアップを作成します。

tar -cvpf edgdomainback.tar /u01/oracle/config/domains/WCCDomain

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

この章では、Fusion Middleware構成ウィザードを使用して、Oracle WebCenter Content: Inbound Refineryを追加するためのドメインの拡張方法について説明します。

この章には次の項が含まれます:

- 第11.1項「Inbound Refineryを追加するためのドメインの拡張の概要」

- 第11.2項「Inbound Refineryを使用するためのドメインの拡張」

- 第11.3項「管理サーバーの再起動」

- 第11.4項「Inbound Refinery用の構成後タスクおよび検証タスクの実行」

- 第11.5項「Inbound Refinery管理対象サーバーの構成」

- 第11.6項「Inbound Refinery管理対象サーバーの構成の検証」

- 第11.7項「WLS_IBR管理対象サーバー用のノード・マネージャの構成」

注意:
セットアップのプロセスを開始する前に、各プラットフォームのOracle Fusion Middlewareリリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。

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

Inbound Refineryは、Oracle WebCenter Content Serverがドキュメント変換を行う際に必要になります。実際のInbound Refinery管理対象サーバーの数は、要件によって異なります。可用性の理由から、少なくとも2つのInbound Refinery管理対象サーバーを別々のマシン上にインストールおよび構成することをお薦めします。参照用Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジにおいて、Inbound RefineryはContent Serverと同一のマシンに構成されます。

このエンタープライズ・デプロイメント・トポロジにInbound Refineryを追加してドメインを拡張するためのプロセスで複数の管理対象サーバーを作成しても、各Inbound Refineryインスタンスは完全に独立しています。Inbound Refineryはクラスタでは実行されません。

Oracle WebCenter Content: Inbound Refineryを追加するには、ドメインを拡張します。表11-1に、WebCenter Contentの構成手順と、Inbound Refinery管理対象サーバーを使用したドメインの拡張に必要なタスクを示します。

表11-1 Inbound Refineryを使用するためのドメインの拡張手順

手順

説明

詳細

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したOracle WebLogic Serverドメインを拡張します。

第11.2項「Inbound Refineryを使用するためのドメインの拡張」

Inbound Refinery管理対象サーバーへのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第11.4.1項「WLS_IBR1およびWLS_IBR2へのドメイン構成の伝播」

ドメインの管理サーバーの再起動

管理サーバーを停止して起動し、前の手順で行った変更を有効にします。

第11.3項「管理サーバーの再起動」

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

WLS_IBR1およびWLS_IBR2管理対象サーバーを起動します。

第11.4.2項「Inbound Refinery管理対象サーバーの起動」

Inbound Refineryインスタンスの構成

WLS_IBR1およびWLS_IBRでInbound Refineryの初期構成を完了します。

第11.5項「Inbound Refinery管理対象サーバーの構成」

Inbound Refineryの構成の検証

変換に有効と認識された拡張子を持つファイルがコンテンツ・サーバーで正しく変換されていることを検証します。

第11.6項「Inbound Refinery管理対象サーバーの構成の検証」

ドメインの管理対象サーバーとノード・マネージャ間通信に対するホスト名検証の構成

管理サーバーや他のサーバーとの通信には、それぞれのアドレス用の証明書を使用します。

第11.7項「WLS_IBR管理対象サーバー用のノード・マネージャの構成」

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

エンタープライズ・デプロイメント・トポロジを完了するには、Oracle WebCenter Content: Inbound Refineryを追加するために第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを拡張する必要があります。

注意:
これらの手順を実行する前に、Oracle Fusion Middleware管理者ガイドの説明に従ってドメインをバックアップしてください。

Inbound Refineryを使用するためにドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。
Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内のすべての管理対象サーバーを停止します。

3. WCCHOST1で、ディレクトリをFusion Middleware構成ウィザードの場所に変更します。これは共通のOracleホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行することに注意してください)。

cd ORACLE_COMMON_HOME/common/bin

4. 構成ウィザードを起動します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. 「WebLogicドメイン・ディレクトリの選択」画面で、WebLogic Serverのドメイン・ディレクトリ(ASERVER_HOME)を選択し、「次へ」をクリックします。

7. 「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。

- Oracle Universal Content Management - Inbound Refinery
これがOracle WebCenter Content: Inbound Refineryの選択肢です。

- Oracle Enterprise Manager Plugin for IBR (Oracle Universal Content Management - Inbound Refineryを選択した場合は自動的に選択されます。)

図11-1 Inbound Refineryの「拡張ソースの選択」画面

次の製品は、ドメインを作成した際(第8.3項)またはWebCenter Content用(第10.2項)にドメインを拡張した際に選択している場合、グレー表示されます。

- WebLogic Serverの基本ドメイン

- Oracle Universal Content Management - Content Server

- Oracle Enterprise Manager

- Oracle JRF

「次へ」をクリックします。

8. 「GridLink RACコンポーネント・スキーマの構成」画面で必要な手順はありません。Inbound Refineryでは、データベースにスキーマがありません。「次へ」をクリックして続行します。

9. 「JDBCコンポーネント・スキーマのテスト」画面で必要な手順はありません。「次へ」をクリックして続行します。

10. 「オプションの構成を選択」画面で、次のオプションを選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

11. 「管理対象サーバーの構成」画面(図11-2)で、Inbound Refineryの管理対象サーバーを追加し、Inbound Refineryサーバーを構成します。

図11-2 Inbound Refinery管理対象サーバーの構成

1台のサーバーが自動的に作成されます。このサーバーの名前をWLS_IBR1に変更し、WLS_IBR2という新しいサーバーを追加します。表11-2に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは変更しないでください。

表11-2 Inbound Refineryの管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_IBR1

WCCHOST1

16250

n/a

いいえ

WLS_IBR2

WCCHOST2

16250

n/a

いいえ

「次へ」をクリックします。

12. 「クラスタの構成」画面で、「追加」をクリックし、表11-3に示すIBR_Serversを追加します。この画面に表示されている他のクラスタは変更しないでください。

表11-3 Inbound Refineryサーバーの管理用の構成

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

IBR_Servers

ユニキャスト

n/a

n/a

空のままにします。

「次へ」をクリックします。

注意:
すべてのInbound Refineryインスタンスは完全に独立しています。このクラスタは、管理のみの目的で使用されます。Inbound Refineryをサーバー・グループに割り当てることができますが、Inbound Refineryの各管理対象サーバーは個別に動作するため、そのサーバー・グループがクラスタとして機能することはありません。

13. 「サーバーのクラスタへの割当」画面(図11-3)で、IBR_Serversに次のサーバーを割り当てます。

- WLS_IBR1

- WLS_IBR2

この画面に表示されている他の割当ては変更しないでください。

図11-3 Inbound Refineryサーバーのサーバー・グループへの割当て

「次へ」をクリックします。

14. 「マシンの構成」画面で「次へ」をクリックします。
ここでマシンを追加する必要はありません。第10.2項「WebCenter Contentでのドメインの拡張」の説明に従って先ほど構成したマシンは、WCCHOST1およびWCCHOST2上に構成されているすべての管理対象サーバーに使用されます。

15. 「サーバーのマシンへの割当」画面(図11-4)で、次のようにInbound Refinery管理対象サーバーをマシンに割り当てます。

- WLS_IBR1をWCCHOST1に割り当てます。

- WLS_IBR2をWCCHOST2に割り当てます。

図11-4 Inbound Refineryサーバーのマシンへの割当て

「次へ」をクリックします。

16. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、EMアプリケーションがAdminServerのみにターゲット設定されていることを確認します。
「次へ」をクリックします。

17. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、図11-5に示すようにIBR_ServersにデプロイされるすべてのOPSS関連のデータ・ソースを選択します。

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

図11-5 サービスのInbound Refineryへのターゲット設定

「次へ」をクリックします。

18. 「構成のサマリー」画面で、「拡張」をクリックします。

19. 「ドメインの作成中」画面で、「完了」をクリックします。

11.3 管理サーバーの再起動

ドメイン拡張の変更を有効にするには、Oracle WebLogic Scripting Tool (WLST)でノード・マネージャのnmKillコマンドとnmStartコマンドを使用して管理サーバーを再起動する必要があります(第10.3項「管理サーバーの再起動」を参照)。管理サーバーを停止する際には、nmKillのかわりに管理コンソールを使用できます。weblogicユーザーの資格証明を使用して管理コンソールにログインします。

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

次の項では、Inbound Refinery用の構成後タスクと検証タスクを実行する方法について説明します。

- 第11.4.1項「WLS_IBR1およびWLS_IBR2へのドメイン構成の伝播」

- 第11.4.2項「Inbound Refinery管理対象サーバーの起動」

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

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

Inbound Refinery管理対象サーバーにドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateIBR.jar -template_name=edgdomain_templateIBR

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

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

参照トポロジで、MSERVER_HOMEは/u02/oracle/config/domains/WCCDomainディレクトリで、APPLICATION_HOMEは/u01/oracle/config/applications/WCCDomainディレクトリです。

注意:

- unpackコマンドはWL_HOME/common/bin/から実行するのではなく、ORACLE_COMMON_HOME/common/bin/ディレクトリから実行してください。

- APPLICATION_HOMEディレクトリは、このunpackコマンドでバックアップされます。

- unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびEARファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびEARファイルをリストアする必要があります。

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

注意:

- unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

- APPLICATION_HOMEディレクトリは、このunpackコマンドでバックアップされます。

6. ここまでの変更を有効にするために管理サーバーを再起動します。まずnmKillコマンドまたは管理コンソールで管理サーバーを停止し、次にnmStartコマンドで起動します(第10.3項「管理サーバーの再起動」を参照)。その後weblogicユーザーの資格証明を使用して管理コンソールにログインします。

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

ドメイン構成を伝播したら、Inbound Refinery管理対象サーバーを起動します。

WCCHOST1でWLS_IBR1管理対象サーバーを起動する手順は次のとおりです。

1. http://admin.example.com:7001/consoleでOracle WebLogic Server管理コンソールにログインします。

2. 次の手順に従い、管理コンソールを使用してWLS_IBR1管理対象サーバーを起動します。

1. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

2. 「サーバー」をクリックします。

3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

4. 表の「サーバー」列からWLS_IBR1を選択します。

5. 「起動」をクリックします。

3. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

- サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。

- 「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」を参照してください。

4. 前述の手順を繰り返し、WCCHOST2でWLS_IBR2管理対象サーバーを起動します。

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

Inbound Refinery管理対象サーバーの構成を初期化するには、その管理対象サーバーに一度だけHTTP経由でアクセスする必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound RefineryインスタンスはHTTPサーバーの後方に配置する必要があります。

Inbound Refineryインスタンスへのすべての後続のアクセスは、ソケット・リスナーを介して行われます。このリスナーは、次の項で構成される着信ソケット接続アドレス・セキュリティ・フィルタによって保護されます。

すべてのInbound Refineryインスタンスを使用して各コンテンツ・サーバー・インスタンスを構成することをお薦めします。コンテンツ・サーバーの構成プロセスは、Inbound Refineryインスタンスをプロバイダとして追加することです。また、一部のインストール後の手順をInbound Refineryで実行する必要があります。

次の項では、各Inbound Refineryインスタンスのインストール後の構成手順について説明します。

- 第11.5.1項「Inbound Refineryの設定の構成」

- 第11.5.2項「フォント・パスの指定」

- 第11.5.3項「ドキュメント変換の構成」

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

11.5.1 Inbound Refineryの設定の構成

Inbound Refinery管理対象サーバーを起動したら、インストール後の構成画面で各サーバーの設定を構成します。

各Inbound Refineryインスタンスの設定を構成する手順は次のとおりです。

1. 次のURLからInbound Refineryのインストール後の構成画面にアクセスします。Nには1または2を指定します。

http://WCCHOSTN:16250/ibr/

2. 「構成」画面で、Inbound Refineryインスタンス識別子であるnameを確認します。このインスタンスの構成設定を次のように設定します。

- Inbound Refineryのインスタンス・フォルダ: /u01/oracle/config/domains/WCCDomain/IBR_Servers/ibrN/
ディレクトリ・パスが共有ディスク上に存在していて、構成が保存される前にディレクトリが作成されている必要があります。

- ネイティブ・ファイル・リポジトリの場所: /u01/oracle/config/domains/WCCDomain/IBR_Servers/ibrN/vault/

- Webレイアウト・フォルダ: /u01/oracle/config/domains/WCCDomain/IBR_Servers/ibrN/weblayout/

- ユーザー・プロファイル・フォルダ: /u01/oracle/config/domains/WCCDomain/IBR_Servers/ibrN/data/users/profiles/

- ソケット接続アドレス・セキュリティ・フィルタを着信中: 次に示すような、ローカル・ホストとサーバーIPアドレスのパイプ区切り一覧です。

127.0.0.1|WCCHOST1-IP|WCCHOST2-IP

この設定によってコンテンツ・サーバーからアクセスできるようになります。WCCHOST1-IPおよびWCCHOST2-IPの値は、Inbound Refineryにジョブを送信するコンテンツ・サーバーのインスタンスが1つ以上あるマシンのIPアドレスである必要がありますが、必ずしもInbound RefineryのIPアドレスとは限りません。(ただし、このエンタープライズ・デプロイメント・ガイドで使用される参照トポロジでは、これらのIPアドレスは同じです。)

「ソケット接続アドレス・セキュリティ・フィルタを着信中」フィールドの値にはワイルドカードを指定できます(例: 192.0.2.*)。

この値は、後で/u02/oracle/config/domains/WCCDomain/ucm/ibr/config/config.cfgファイルのSocketHostAddressSecurityFilterを設定し、Inbound Refinery管理対象サーバーを再起動すると、変更できます。

- サーバーのソケット・ポート: 5555のように、使用されていないポート番号を入力します。この値は、トップレベルのサービスを呼び出すためのポートの番号です。
このポート番号は、後でOracle WebCenter Contentの構成時に必要となるため、書き留めておいてください。

このフィールドの値を変更すると、/u02/oracle/config/domains/WCCDomain/ucm/ibr/config/config.cfgのIntradocServerPortエントリが変更されます。

- コンテンツ・サーバーのインスタンス名: Inbound Refineryサーバーのインスタンス名を指定します。
デフォルト値を受け入れることも、より便利な名前に変更することもできます。このサーバー名は、後でOracle WebCenter Contentの構成時に必要となるため、書き留めておいてください。

構成ページの他のすべてのフィールドはそのままにします。

「送信」をクリックすると、次のメッセージが表示されます。

Post-install configuration complete. Please restart this node.

3. WebLogic Server管理コンソールを使用して、Inbound Refinery管理対象サーバーを再起動します。

4. 各Inbound Refineryインスタンスに対して個別のコンテンツ・フォルダ名を使用して、前述の手順を実行します。

11.5.2 フォント・パスの指定

Inbound Refineryが正常に機能するには、フォント・イメージを生成するために使用されるフォントへのパスを指定する必要があります。デフォルトでは、フォント・パスはInbound Refineryで使用されるJVM内のフォント・ディレクトリ(MW_HOME/jdk160_version/jre/lib/fonts)に設定されます。ただし、デフォルト・ディレクトリに含まれるフォントは限定されているため、レンディションが低下する可能性があります。また、非標準のJVMを使用した場合、デフォルトで指定されているJVMのフォント・パスと異なることがあります。この場合、エラー・メッセージがInbound Refineryとコンテンツ・サーバーの両方から表示されます。これが発生した場合は、変換を正しくレンダリングするために必要なフォントを含むディレクトリにフォント・パスが設定されていることを確認してください。

詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のフォント・パスの指定に関する項を参照してください。

11.5.3 ドキュメント変換の構成

コンポーネント・マネージャを使用して、各Inbound Refinery管理対象サーバーでドキュメント変換に必要なコンポーネントを有効にします。

各Inbound Refinery管理対象サーバーでドキュメント変換を構成する手順は次のとおりです。

1. 次のURLからInbound Refineryにログインします。Nには1または2を指定します。

http://WCCHOSTN:16250/ibr/

2. Inbound Refineryでの変換コンポーネントを有効にします。コアInbound Refineryは、ファイルをTIFF Web表示可能ファイルおよびJPEGイメージ・サムネイルに変換します。追加の変換タイプを使用するには、必要なコンポーネントを有効にする必要があります。

1. 「管理」トレイまたはメニューで、「管理サーバー」、「コンポーネント・マネージャ」の順に選択します。

2. 「コンポーネント・マネージャ」ページで、「Inbound Refinery」のPDFExportConverterとその他に必要なコンポーネントを選択します。
PDFExportConverterは、Oracle Outside In Technologyを使用して、ドキュメントを直接PDFファイルに変換します。この変換はクロス・プラットフォームにすることができ、サードパーティ製品を必要としません。Inbound Refinery用のPDFExportConverterはサービス機能として有効にできます。詳細は、readmeファイルおよび各コンポーネントのドキュメントを参照してください。

3. 「更新」をクリックします。

4. 「OK」をクリックして、コンポーネントを有効にします。

5. WebLogic Server管理コンソールを使用して、Inbound Refinery管理対象サーバーを再起動します。

6. プライマリWeb表示可能変換をPDF Exportに設定します。

- 「変換設定」→「プライマリWebレンディション」を選択します。

- 「プライマリWeb表示可能レンディション」ページで、「PDFエクスポートによるPDFへの変換」を選択します。

- 「更新」をクリックして変更内容を保存します。

再起動後、Outside In Technology PDF Exportを使用してファイルがPDFに直接変換されます。サード・パーティ・アプリケーションは使用しません。

7. WebLogic Server管理コンソールを使用して、Inbound Refinery管理対象サーバーを再起動します。

注意:
変換コンポーネントの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のコンテンツ・サーバーRefinery変換オプションの構成に関する項を参照してください。

3. 管理サーバーとすべてのInbound Refinery管理対象サーバーを再起動します。
管理サーバーを再起動するには、最初に管理コンソールを使用してサーバーを停止し、第8.4.3項「WCCHOST1での管理サーバーの起動」の説明に従って再起動します。管理対象サーバーを再起動するには、WebLogic Server管理コンソールを使用します。

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

Oracle WebCenter Content ServerからInbound Refineryにジョブを送信して変換を実施できるようにするには、次の項の説明に従って、Inbound Refinery管理対象サーバーごとに設定タスクを事前に実行する必要があります。

- 第11.5.4.1項「送信プロバイダの作成」

- 第11.5.4.2項「コンテンツ・サーバーでのInbound Refinery用のコンポーネントの有効化」

- 第11.5.4.3項「変換するファイル形式の選択」

11.5.4.1 送信プロバイダの作成

コンテンツ・サーバーからInbound Refineryにファイルを送信して変換を実施するには、「Inbound Refinery変換ジョブの処理」オプションを事前に選択して、コンテンツ・サーバーから各Inbound Refineryへの送信プロバイダを設定する必要があります。

各Inbound Refineryインスタンスの送信プロバイダを作成する手順は次のとおりです。

1. 次のURLからコンテンツ・サーバーにログインします。

http://WCCHOST1:16200/cs/

2. 「管理」トレイまたはメニューを開いて、「プロバイダ」を選択します。

3. 「プロバイダ」ページの「新規プロバイダの作成」表で、「送信」行の「追加」をクリックします。

4. 次の値をフィールドに入力します。

- プロバイダ名: 空白が含まれない短縮名。「インスタンス名」と同じ値を使用することをお薦めします。

- プロバイダの説明: テキスト文字列。

- サーバー・ホスト名: Inbound Refineryインスタンスが実行されているホスト・マシンの名前。たとえば、WCCHOST1など。

- HTTPサーバー・アドレス: Inbound Refineryインスタンスのアドレス。たとえば、WCCHOST1: 16250など。

- サーバー・ポート: 第11.5.1項「Inbound Refineryの設定の構成」で指定されているInbound Refineryインスタンスの「サーバーのソケット・ポート」フィールドの値。たとえば、5555など。これは、コンテンツ・サーバーのconfig.cfgファイルにあるIntradocServerPortの値です。

- インスタンス名: 第11.5.1項「Inbound Refineryの設定の構成」で指定されているInbound Refineryのサーバー・インスタンス名。これは、Inbound Refineryのconfig.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のマネージング』のコンテンツ・サーバーとRefineryの通信の構成に関する項を参照してください。

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

変換タイプによっては、コンテンツ・サーバーでヘルパー・コンポーネントを有効にする必要があります。ドキュメント変換にInbound Refineryを使用するコンテンツ・サーバーのインスタンスでは、InboundRefinerySupportコンポーネントを常に有効にする必要があります。新しいコンテンツ・サーバーのインストールではデフォルトで有効になっています。

コンテンツ・サーバーでInbound Refineryコンポーネントを有効にする手順は次のとおりです。

1. 次のURLからコンテンツ・サーバーにログインします。

http://WCCHOST1:16200/cs/

2. 「管理」トレイまたはメニューで、「管理サーバー」、「コンポーネント・マネージャ」の順に選択します。

3. 「コンポーネント・マネージャ」ページで、「Inbound Refinery」を選択し、「Inbound Refinery」で有効にするコンポーネント(XMLConverterSupportなど)を選択したら、「更新」をクリックします。

4. コンテンツ・サーバーを再起動するために、WebLogic Server管理コンソールを使用してWebCenter Content管理対象サーバーを再起動します。

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

変換のためにInbound Refineryに送信するファイルをコンテンツ・サーバーに指定するには、ファイル形式を選択する必要があります。

変換するファイル形式を選択するには、次の手順を実行します。

1. 次のURLからコンテンツ・サーバーにログインします。

http://WCCHOST1:16200/cs/

2. 「管理」トレイまたはメニューを開いて「リファイナリ管理」、「ファイル形式ウィザード」の順に選択し、「ファイル形式ウィザード」ページを開きます。
このページでは、どのファイル形式をコンテンツ・サーバーにチェックインした場合に、そのファイル形式をInbound Refineryに送信して変換を実施するかを指定します。

3. Microsoft Wordドキュメントのdoc、dot、docxおよびdotxなど、変換が必要なフォーマットを選択します。

4. 「更新」をクリックします。

また、構成マネージャでファイル形式を選択することもできます。構成マネージャでは、ウィザードでは示されないファイル形式など、さらにきめ細かく制御できます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のファイル・タイプの管理に関する項を参照してください。

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

作成したInbound Refinery管理対象サーバーが正しく構成されているかどうかを確認するには、コンテンツ・サーバーにログインし、変換に有効と認識された拡張子を持つファイルが正しく変換されることを確認して、構成を検証します。

たとえば、変換するフォーマットとしてdocxを選択した場合は、拡張子が.docxのMicrosoft Word文書をPDFフォーマットに変換できます。

チェックインとチェックアウトの手順の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの使用』のドキュメントのアップロードおよびファイルのチェックアウトとダウンロードに関する項を参照してください。

変換プロセスの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のRefineryにジョブを送信するためのコンテンツ・サーバーの構成に関する項を参照してください。

11.7 WLS_IBR管理対象サーバー用のノード・マネージャの構成

ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第16章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照してください。その章の手順をOracle WebCenter Contentデプロイメントで実行する必要があります。

第16.3項「ノード・マネージャでのホスト名検証証明書の有効化」の手順は、次の表のホストおよびInbound Refinery管理対象サーバーに対して実行する必要があります。

ホスト名(HOST)

仮想IPアドレス(VIP)

サーバー名(WLS_SERVER)

WCCHOST1

n/a

WLS_IBR1

WCCHOST2

n/a

WLS_IBR2

12 Oracle SOA Suiteコンポーネントを追加するためのドメインの拡張

この章では、Fusion Middleware構成ウィザードを使用して、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを拡張し、Oracle SOA SuiteコンポーネントとOracle WSMポリシー・マネージャ・サーバーを追加する方法について説明します。

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

- 第12.1項「Oracle SOA Suiteコンポーネントを追加するためのドメインの拡張の概要」

- 第12.2項「WCCHOST1でのVIP2およびWCCHOST2でのVIP3の有効化」

- 第12.3項「Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張」

- 第12.4項「管理サーバーの再起動」

- 第12.5項「コンポジットをデプロイするためのOracle Coherenceの構成」

- 第12.6項「Oracle SOA Suite用の構成後タスクおよび検証タスクの実行」

- 第12.7項「Oracle Web Services Manager用のJavaオブジェクト・キャッシュの構成」

- 第12.8項「拡張したドメインでのOracle HTTP Serverの構成」

- 第12.9項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」

- 第12.10項「WLS_SOA管理対象サーバー用のノード・マネージャの構成」

- 第12.12項「インストールのバックアップ」

注意:

- Oracle SOA Suiteは、エンタープライズ・デプロイメント・トポロジにOracle WebCenter Content: Imagingを追加する場合にのみ必要になります。

- セットアップのプロセスを開始する前に、各プラットフォームのOracle Fusion Middlewareリリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。

12.1 Oracle SOA Suiteコンポーネントを追加するためのドメインの拡張の概要

この章の手順は、SOA Oracleホーム(バイナリ)がすでにインストールされていて、WCCHOST1およびWCCHOST2からアクセス可能な状態であること、さらに、管理サーバーを含むドメインが作成されていることを前提としています。このドメインを拡張して、Oracle SOA Suiteコンポーネントをサポートします。

Oracle WebLogic Serverドメインを拡張して、Oracle SOA Suiteコンポーネントを追加します。表12-1に、Oracle SOA Suiteの構成手順と、Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張に必要なタスクを示します。

表12-1 Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張手順

手順

説明

詳細

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

Oracle SOA Suite WebLogic Serverクラスタの各ホスト名で仮想IPアドレスのマッピングを有効にします。

第12.2項「WCCHOST1でのVIP2およびWCCHOST2でのVIP3の有効化」

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogic Serverドメインを拡張します。

第12.3項「Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張」

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

コンポジットのデプロイにユニキャスト通信を使用するためOracle Coherenceを構成します。

第12.5項「コンポジットをデプロイするためのOracle Coherenceの構成」

構成後タスクおよび検証タスクの実行

ホスト名の検証の無効化、ノード・マネージャの再起動、ドメイン構成の伝播、管理対象サーバーの起動と検証、GridLinkデータ・ソースの検証の手順に従います。

第12.6項「Oracle SOA Suite用の構成後タスクおよび検証タスクの実行」

Oracle Web Services Manager (Oracle WSM)を実行しているすべてのサーバー間の、Javaオブジェクト・キャッシュ(JOC)の構成

Oracle WSMのパフォーマンスを向上させるためにローカル・キャッシュを構成します。

第12.7項「Oracle Web Services Manager用のJavaオブジェクト・キャッシュの構成」

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

管理対象サーバーとともにOracle HTTP Serverを構成し、アクセスの検証、フロントエンドHTTPのホストおよびポートの設定およびSOA_ClusterのWebLogic Serverクラスタ・アドレスの設定を行います。

第12.8項「拡張したドメインでのOracle HTTP Serverの構成」

デフォルト永続ストアの構成

トランザクション・リカバリのためのデフォルトの永続ストアを構成します。

第12.9項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」

ドメインの管理対象サーバーとノード・マネージャ間通信に対するホスト名検証の構成

管理サーバーや他のサーバーとの通信には、それぞれのアドレス用の証明書を使用します。

第12.10項「WLS_SOA管理対象サーバー用のノード・マネージャの構成」

Oracle SOA Suite管理対象サーバー用のサーバー移行の構成

移行のためのOracle SOA Suite管理対象サーバー名、ホスト名およびクラスタ名を指定します。

第12.11項「WLS_SOA管理対象サーバー用のサーバー移行の構成」

Oracle SOA Suite構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第12.12項「インストールのバックアップ」

12.2 WCCHOST1でのVIP2およびWCCHOST2でのVIP3の有効化

Oracle WebCenter Contentドメインでは、Oracle SOA Suiteの管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。まだ対応していない場合は、VIP2からWCCHOST1のWCCHOST1VHN1に対して、またVIP3からWCCHOST2のWCCHOST2VHN1に対して仮想IPアドレスのマッピングを有効にし、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーまたは/etc/hosts解決のいずれかで)正しく解決する必要があります。

まだ仮想IPアドレスを有効化していない場合には、第6.6項「仮想IPアドレスの有効化」で説明している手順に従ってください。これらの仮想IPアドレスおよび仮想ホスト名は、Oracle SOA Suiteサーバーでサーバー移行を有効にするときに必要となります。この後、高可用性を実現するために、Oracle SOA Suiteサーバーのサーバー移行を構成できます。サーバー移行の構成の詳細は、第17章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。

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

構成ウィザードを使用して、Oracle Web Services ManagerおよびOracle SOA Suiteコンポーネントをサポートするために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成されたドメインを拡張します。

注意:

- Oracle SOA Suiteは、エンタープライズ・デプロイメント・トポロジにOracle WebCenter Content: Imagingを追加する場合にのみ必要になります。

- 第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインをバックアップしていない場合は、Oracle SOA Suiteコンポーネントを使用するためのドメイン拡張を実行する前に、現在のドメインをバックアップします。ドメインの拡張時になんらかのエラーが発生した場合は、このバックアップを使用してリカバリできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

Oracle SOA Suiteコンポーネントを使用するためにドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。
Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内のすべての管理対象サーバーを停止します。

3. WCCHOST1で、ディレクトリをFusion Middleware構成ウィザードの場所に変更します。これはOracle共通ホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行します)。

cd ORACLE_COMMON_HOME/common/bin

4. 構成ウィザードを起動します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. 「WebLogicドメイン・ディレクトリの選択」画面で、WebLogic Serverのドメイン・ディレクトリ(ASERVER_HOME)を選択し、「次へ」をクリックします。

7. 「拡張ソースの選択」画面(図12-1)で、次の手順を実行します。

1. 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

2. 次の製品を選択します。

- Oracle SOA Suite

- Oracle WSMポリシー・マネージャ

次の製品は、ドメインを作成した際(第8.3項)あるいはWebCenter Content用(第10.2項)またはInbound Refinery用(第11.2項)にドメインを拡張した際に選択している場合、グレー表示されます。

- WebLogic Serverの基本ドメイン

- Oracle Universal Content Management - Inbound Refinery

- Oracle Universal Content Management - Content Server

- Oracle Enterprise ManagerプラグインIBR用

- Oracle Enterprise Manager

- Oracle JRF

図12-1 Oracle SOA Suiteの「拡張ソースの選択」画面

3. 「次へ」をクリックします。

8. このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。

9. 図12-2に示す「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. 「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」、「OWSM MDSスキーマ」および「SOA MDSスキーマ」の各行を選択します。

2. RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます(付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照)。ここでの説明に合せて、「GridLinkへ変換」を選択します。
RAC構成を選択すると、選択されたすべてのスキーマがグレー表示されます。

図12-2 Oracle SOA Suiteの「JDBCコンポーネント・スキーマの構成」画面

3. 「次へ」をクリックします。

10. 図12-3に示す「GridLink RACコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. 「SOAインフラストラクチャ」行のみを選択します。

図12-3 Oracle SOA Suiteの「GridLink RACコンポーネント・スキーマの構成」画面

2. 次の各フィールドに値を入力して、RCUでシードされたGridLink RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 11以上を選択します。

- サービス名: Oracle RACデータベースのサービス名は小文字で入力し、ドメイン名を続けます(例: wccedg.example.com)。

- ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてWCCを使用しています。

- パスワード: データベース・スキーマの所有者のパスワードを入力します。

- 「FANの有効化」を選択します。

- SSLの有効化: このオプションは選択解除したままにします。
SSLを選択してOracle Notification Service (ONS)の通知暗号化を有効にする場合は、「ウォレット・ファイル」および「ウォレット・パスワード」の詳細を適切に指定します。

- サービス・リスナー: 使用するOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。プロトコルはTCPである必要があります。
SCANアドレスを使用してサービス・リスナー(およびOSNホスト)を指定することをお薦めします。これにより、Oracle RACノードを追加または削除しても、SCANアドレスを含むGridLinkデータ・ソースを更新する必要がありません。SCANアドレスを特定するには、データベース内のremote_listenerパラメータを問い合せます。

SQL>show parameter remote_listener;

NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      db-scan.example.com:1521

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベース・インスタンス・リスナーの仮想IPアドレスとポートを使用します。

wccdbhost1-vip.example.com (port 1521)

wccdbhost2-vip.example.com (1521)

- ONSホスト: データベースによって報告されるRACデータベースのSCANアドレスとONSリモート・ポートも入力します。

[orcl@WCCDBHOST2 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベースのONSサービスのホスト名とポートを使用します。

wccdbhost1.example.com (port 6200)

wccdbhost2.example.com (6200)

3. 各データ・ソースを1つずつ選択し、適切な値のユーザー名とパスワードを入力します。

4. すべてのスキーマ(SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマ)で、すべての値が正しいことを確認し、「次へ」をクリックします。

注意:
Oracle WSMポリシーを格納するには、Oracle Identity Management用のデータベースを使用することをお薦めします(第18章「Oracle Identity Managementとの統合」を参照)。そのため、(第3章「エンタープライズ・デプロイメント用のネットワークの準備」で推奨されるように)RCUでシードされたOracle Identity Managementデータベース情報を使用してWSMメタデータを格納し、この画面ではOWSM MDSスキーマ用にOracle Identity Managementデータベース情報が使用されることが予想されます。このデータベース接続情報は、その他のOracle SOA Suiteスキーマで使用されるものとは異なります。

11. 「JDBCコンポーネント・スキーマのテスト」画面(図12-4)で、各スキーマを選択し、「接続のテスト」をクリックします。
結果は「接続結果ログ」に表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正してテストを再試行します。

図12-4 Oracle SOA Suiteの「JDBCコンポーネント・スキーマのテスト」画面

すべての接続に成功したら「次へ」をクリックします。

12. 「オプションの構成を選択」画面で、次のオプションを選択します。

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

- JMSファイル・ストア

「次へ」をクリックします。

13. 「JMS分散宛先タイプの選択」画面で次の手順を実行します。

- UMSJMSystemResourceのドロップダウン・リストからUDDを選択します。

- SOAJMSModuleのドロップダウン・リストからUDDを選択します。

- BPMJMSModuleのドロップダウン・リストからUDDを選択します。

オーバーライドの警告が表示された場合、「OK」をクリックして、このメッセージを確認します。

14. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
soa_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_SOA1に変更し、WLS_SOA2という新しいサーバーを追加します。表12-2に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは変更しないでください。

表12-2 Oracle SOA Suiteの管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_SOA1

WCCHOST1VHN1

8001

n/a

いいえ

WLS_SOA2

WCCHOST2VHN1

8001

n/a

いいえ

「次へ」をクリックします。

15. 「クラスタの構成」画面でSOA_Clusterを追加します(表12-3を参照)。

表12-3 Oracle SOA Suiteのクラスタ構成

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

SOA_Cluster

ユニキャスト

n/a

n/a

WCCHOST1VHN1:8001、WCCHOST2VHN1:8001

「次へ」をクリックします。

注意:
直接バインディングを介してリクエスト/レスポンスが非同期でやり取りされるようにするため、SOAコンポジットでは、JNDIプロバイダURLを提供して、呼び出されたサービスが、コールバックするBeanを検索できるようにする必要があります。
soa-infraの構成プロパティは指定されていないがWebLogic Serverクラスタ・アドレスが指定されている場合は、JNDIプロバイダURLのクラスタ・アドレスが使用されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名、またはserver ip:portのカンマ区切りリストを使用できます。また、ユーザーが明示的に設定していれば、soa-infraの構成プロパティJndiProviderURL/SecureJndiProviderURLを同じ目的に使用することもできます。

16. 「サーバーのクラスタへの割当」画面で、SOA_Clusterに次のサーバーを割り当てます。

- WLS_SOA1

- WLS_SOA2

この画面に表示されている他の割当ては変更しないでください。

「次へ」をクリックします。

17. 「マシンの構成」画面で、デフォルトで表示される「LocalMachine」を削除し、「Unixマシン」タブを開いて、「次へ」をクリックします。
ここでマシンを追加する必要はありません。第10.2項「WebCenter Contentでのドメインの拡張」の説明に従って先ほど構成したマシンは、WCCHOST1およびWCCHOST2上に構成されているすべての管理対象サーバーに使用されます。

18. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- ADMINHOST:

- AdminServer

- WCCHOST1:

- WLS_SOA1

- WCCHOST2:

- WLS_SOA2

「次へ」をクリックします。

19. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のようにターゲット設定されていることを確認します。

- usermessagingserverおよびusermessagingdriver-emailデプロイメントは、SOA_Clusterにのみターゲット設定します(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。

- WSM-PMは、SOA_Clusterにのみターゲット設定します。

- oracle.rules#*、oracle.sdp.*およびoracle.soa.*の各ライブラリは、SOA_Clusterにのみターゲット設定されます。

- EMアプリケーションは、AdminServerにのみターゲット設定します。

「次へ」をクリックします。

20. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、図12-5に示すようにSOA_ClusterにデプロイされるすべてのOPSS関連のデータ・ソースを選択します。

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

図12-5 サービスのSOAクラスタへのターゲット設定

「次へ」をクリックします。

21. 「JMSファイル・ストアの構成」画面(図12-6)で、第4.4項「各種ディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。

ASERVER_HOME/SOA_Cluster/jms

ドメインを拡張する前に、このドメインを作成する必要があります。

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

図12-6 SOAクラスタのJMSファイル・ストア

「次へ」をクリックします。

22. 「構成のサマリー」画面で、「拡張」をクリックします。
このドメインを拡張して、Oracle SOA Suiteコンポーネントを追加します。

23. 「ドメインの拡張中」画面で、「完了」をクリックします。

12.4 管理サーバーの再起動

ドメイン拡張の変更を有効にするには、Oracle WebLogic Scripting Tool (WLST)でノード・マネージャのnmKillコマンドとnmStartコマンドを使用して管理サーバーを再起動する必要があります(第10.3項「管理サーバーの再起動」を参照)。管理サーバーを停止する際には、nmKillのかわりに管理コンソールを使用できます。weblogicユーザーの資格証明を使用して管理コンソールにログインします。

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

コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、Oracle SOA Suiteエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。

ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPアドレスを使用できるOracle SOA Suiteエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

注意:
デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、Oracle SOA Suiteシステムを起動できないことがあります。Oracle SOA Suiteシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。

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

tangosol.coherence.wkanシステム・プロパティを使用してノードを指定します(nは1から9の範囲の番号)。「Well Knownアドレス」として指定できるのは9ノードまでですが、クラスタには9ノードを超えるノードを含めることができます。番号は、1から開始します。この番号付けは、連続的で間隙を含まないようにする必要があります。

ヒント:
Oracle SOA Suiteコンポジットのデプロイメント時の高可用性を保証するためには、十分なノードを指定して、いつでも最低1つのコンポジットが実行されているようにします。

また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、Oracle SOA Suiteサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(WCCHOST1VHN1とWCCHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図12-7を参照)。

注意:
WCCHOST1VHN1は、WCCHOST1でWLS_SOA1がリスニングする仮想IPアドレスにマップされる仮想ホスト名です。WCCHOST2VHN1は、WCCHOST2でWLS_SOA2がリスニングする仮想IPアドレスにマップされる仮想ホスト名です。

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

管理コンソールを使用して、Oracle Coherenceで使用するホスト名を追加します。

Oracle Coherenceで使用されるホスト名を指定する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 左側の「ドメイン構造」ツリーで「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 「サーバーのサマリー」ページでサーバー名(WLS_SOA1またはWLS_SOA2)をクリックします。これらは、表の「名前」列にハイパーリンクで表示されています。

5. 選択したサーバーの「設定」ページで、「ロックして編集」をクリックします。

6. 「構成」タブで、「サーバーの起動」タブをクリックします(図12-7を参照)。

7. WLS_SOA1とWLS_SOA2について、「引数」フィールドに次のパラメータを入力します。

注意:
異なる-Dパラメータの間には、空白の行を入れないでください。テキストは、コピーして管理コンソールの「引数」テキスト・フィールドに貼り付けないでください。貼り付けると、Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。

WLS_SOA1について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=WCCHOST1VHN1
-Dtangosol.coherence.wka2=WCCHOST2VHN1
-Dtangosol.coherence.localhost=WCCHOST1VHN1

WLS_SOA2について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=WCCHOST1VHN1
-Dtangosol.coherence.wka2=WCCHOST2VHN1
-Dtangosol.coherence.localhost=WCCHOST2VHN1

注意:
デプロイメントに使用されるCoherenceクラスタは、デフォルトでポート8088を使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。例:

- WLS_SOA1(「引数」フィールドに、改行なしで1行で次のテキストを入力):

-Dtangosol.coherence.wka1=WCCHOST1VHN1
-Dtangosol.coherence.wka2=WCCHOST2VHN1
-Dtangosol.coherence.localhost=WCCHOST1VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

- WLS_SOA2(「引数」フィールドに、改行なしで1行で次のテキストを入力):

-Dtangosol.coherence.wka1=WCCHOST1VHN1
-Dtangosol.coherence.wka2=WCCHOST2VHN1
-Dtangosol.coherence.localhost=WCCHOST2VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。

8. 「保存」→「変更のアクティブ化」をクリックします。

注意:

- これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります。(これらの変数はサーバーの出力ログに記録されます)。Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。

- このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。Oracle SOA Suiteでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。

図12-7 管理コンソールの「サーバーの起動」タブを使用したホスト名の設定

12.6 Oracle SOA Suite用の構成後タスクおよび検証タスクの実行

構成ウィザードでドメインを拡張し、Oracle Coherenceを構成したら、次の手順に従って、構成後タスクと検証を行います。次の項では、Oracle SOA Suite用の構成後タスクと検証タスクを実行する方法について説明します。

- 第12.6.1項「WLS_SOAn管理対象サーバーに対するホスト名検証の無効化」

- 第12.6.2項「WLS_SOA1およびWLS_SOA2へのドメイン構成の伝播」

- 第12.6.3項「WLS_SOA1管理対象サーバーの起動と検証」

- 第12.6.4項「WLS_SOA2管理対象サーバーの起動と検証」

- 第12.6.5項「Oracle SOA SuiteのGridLinkデータ・ソースの検証」

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

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_SOA1およびWLS_SOA2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.5項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したら、ホスト名検証を再び有効化します。詳細は、第16.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

12.6.2 WLS_SOA1およびWLS_SOA2へのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

Oracle SOA Suite管理対象サーバーにドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateSOA.jar -template_name=edgdomain_templateSOA

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

3. 次のunpackコマンドをWCCHOST1で実行して、前の手順で作成したテンプレートをWLS_SOA1ドメイン・ディレクトリに伝幡します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateSOA.jar -app_dir=APPLICATION_HOME -overwrite_domain=true

参照トポロジで、MSERVER_HOMEは/u02/oracle/config/domains/WCCDomainディレクトリで、APPLICATION_HOMEは/u01/oracle/config/applications/WCCDomainディレクトリです。

注意:

- unpackコマンドはWL_HOME/common/bin/から実行するのではなく、ORACLE_COMMON_HOME/common/bin/ディレクトリから実行してください。

- APPLICATION_HOMEディレクトリは、このunpackコマンドでバックアップされます。

- unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびEARファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびEARファイルをリストアする必要があります。

4. 次のコマンドをWCCHOST1で実行し、手順2で作成したテンプレート・パックをWCCHOST2にコピーします。

scp edgdomaintemplateSOA.jar oracle@WCCHOST2:ORACLE_COMMON_HOME/common/bin

5. 次のunpackコマンドをWCCHOST2で実行して、伝播されたテンプレートをWLS_SOA2管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateSOA.jar -app_dir=APPLICATION_HOME –overwrite_domain=true

注意:

- unpackコマンドはWL_HOME/common/bin/から実行するのではなく、ORACLE_COMMON_HOME/common/bin/ディレクトリから実行してください。

- APPLICATION_HOMEディレクトリは、このunpackコマンドでバックアップされます。

6. ここまでの変更を有効にするために管理サーバーを再起動します。まずnmKillコマンドまたは管理コンソールで管理サーバーを停止し、次にnmStartコマンドで起動します(第10.3項「管理サーバーの再起動」を参照)。その後weblogicユーザーの資格証明を使用して管理コンソールにログインします。

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

管理コンソールを介してWLS_SOA1管理対象サーバーを起動して、検証できます。

WCCHOST1でWLS_SOA1管理対象サーバーを起動する手順は次のとおりです。

1. http://admin.example.com:7001/consoleでOracle WebLogic Server管理コンソールにログインします。

2. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。

1. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

2. 「サーバー」をクリックします。

3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

4. 表の「サーバー」列から「WLS_SOA1」を選択します。

5. 「起動」をクリックします。

3. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

- サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。

- 「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」を参照してください。

4. 次のURLにアクセスします。

- http://WCCHOST1VHN1:8001/soa-infraにアクセスしてWLS_SOA1のステータスを確認します。

- http://WCCHOST1VHN1:8001/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データ・ストアで使用できるポリシーとアサーション・テンプレートのリストが開きます。ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

- http://WCCHOST1VHN1:8001/integration/worklistappにアクセスしてワークリスト・アプリケーションのステータスを確認します。

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

WLS_SOA2管理対象サーバーを起動すると、WebLogic Server管理コンソールおよびURLを介して管理対象サーバーのステータスを確認することにより、検証できます。

注意:
WebLogic Server管理コンソールを使用してWLS_SOA2管理対象サーバーを起動する前に、ノード・マネージャが稼働していることを確認します。第19.8.1項「前提条件および手順」の手順3で、「WCCHOST2でノード・マネージャを起動」と説明しています。
ノード・マネージャが実行されていない場合は、第8.4.2項「WCCHOST1でのノード・マネージャの起動」の説明に従ってWCCHOST2で再起動します。

WLS_SOA2管理対象サーバーの起動と検証の手順は次のとおりです。

1. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。

1. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

2. 「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. 「WLS_SOA2」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

3. 次のURLにアクセスします。

- http://WCCHOST2VHN1:8001/soa-infraにアクセスしてWLS_SOA2のステータスを確認します。

- http://WCCHOST2VHN1:8001/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データ・ストアで使用できるポリシーとアサーション・テンプレートのリストが開きます。

注意:
ポリシーやアサーション・テンプレートがまったく表示されない場合は、構成が正しくありません。

- http://WCCHOST2VHN1:8001/integration/worklistappにアクセスしてワークリスト・アプリケーションのステータスを確認します。

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

サーバーを起動したら、GridLinkデータ・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。

Oracle SOA SuiteのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. 作成したGridLinkデータ・ソースの名前をクリックします。

4. 「監視」タブをクリックします。

5. 「テスト」タブ(図12-8)をクリックし、いずれかのサーバーを選択し、「データ・ソースのテスト」をクリックします。

図12-8 Oracle SOA SuiteのGridLinkデータ・ソースのテスト

構成が適切であればテストは成功します。

6. GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスでテストを繰り返します。

Oracle SOA SuiteのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。

1. 管理コンソールの「ドメイン構造」ツリーで、「サービス」ノードを開いて「データ・ソース」をクリックします。

2. 作成したGridLinkデータ・ソースの名前をクリックします。

3. 「監視」タブをクリックします。

4. サーバーの名前(WLS_SOA1)をクリックします。

5. 「ONS」タブをクリックし、「テスト」タブ(図12-9)をクリックします。

6. サーバーを選択し、「ONSのテスト」をクリックします。

図12-9 Oracle SOA Suiteの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.7 Oracle Web Services Manager用のJavaオブジェクト・キャッシュの構成

Oracle Web Services Manager (Oracle WSM)を実行しているすべてのサーバー間に、Javaオブジェクト・キャッシュ(JOC)を構成する必要があります。このローカル・キャッシュは、Oracle WSMのパフォーマンスを向上させるために用意されています。Javaオブジェクト・キャッシュは、MW_HOME/oracle_common/bin/configure-joc.pyスクリプトを使用して構成できます。これはPythonスクリプトであり、管理対象サーバーでJOCを構成するために使用できます。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが稼働中であることが求められます。

Oracle製品のJOCポートを構成する場合は、9988から9998の範囲のポートを使用することをお薦めします。

注意:
WLSTコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成したら、構成を有効にするために、WebLogic Server管理コンソールを使用して、影響を受ける管理対象サーバーをすべて再起動する必要があります。

Oracle WSMのJavaオブジェクト・キャッシュを構成する手順は次のとおりです。

1. コマンドラインのOracle WebLogic Scripting Tool (WLST)を次のように使用して、管理サーバーに接続します。例:

MW_HOME/oracle_common/common/bin/wlst.sh
$ connect()

プロンプトが表示されたら、WebLogic Server管理者のユーザー名、パスワード、サーバーURL (t3://ADMINVHN:7001)を入力します。

2. WLSTを使用して管理サーバーに接続後、execfileコマンドを使用してスクリプトを開始します。例:

wls:/domain_name/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")

特に、エンタープライズ・デプロイメント環境では、手順2で1つ目のクラスタ・オプションを使用する必要があります。エンタープライズ・デプロイメント環境でconfigure-joc.pyを使用するための処理手順を示します(次のスクリプト入力パラメータのテキストを参照)。

Execfile("MW_HOME/oracle_common/bin/configure-joc.py").
Enter Hostnames (eg host1,host2) : WCCHOST1VHN1,WCCHOST2VHN1
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : SOA_Cluster
.
Enter Discover Port : 9991
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n

WLSTコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成したら、構成を有効にするために、WebLogic Server管理コンソールを使用して、影響を受ける管理対象サーバーをすべて再起動します。

スクリプト入力パラメータ

入力パラメータは、スクリプトによって求められます。このスクリプトを使用すると、次のようなJOC構成を実行できます。

- 特定のクラスタで指定したすべての管理対象サーバーに対してJOCを構成します。クラスタ名を指定するかどうかを尋ねるスクリプト・プロンプトが表示されたらyを入力し、プロンプトに従ってクラスタ名および検出ポートを指定します。これによって、指定したクラスタの管理対象サーバーがすべて検出され、JOCが構成されます。検出ポートはクラスタのJOC構成全体で共通です。例:

Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : SOA_Cluster
Enter Discover Port : 9991

- 指定されたすべての管理対象サーバーに対してJOCを構成します。クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたらnを入力し、プロンプトが表示されたら管理対象サーバーと検出ポートを指定します。例:

Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WLS_SOA1:9991, WLS_SOA21:9991) : WLS_SOA1:9999,WLS_SOA2:9999

この例では、指定した管理対象のサーバー(WLS_SOA1およびWLS_SOA2)用のJOCのみが構成されます。検出ポートは管理対象サーバーとともに指定します(WLS_SOA1:2222など)。

- 特定の管理対象サーバーのJOC構成を除外します。スクリプトでは、JOC構成のDistributeModeがfalseに設定される管理対象サーバーのリストを指定できます。一部のサーバーをJOC構成から除外するかどうかを尋ねられたらyを入力し、プロンプトが表示されたら除外する管理対象サーバーの名前を入力します。例:

Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
Exclude Managed Server List (eg Server1,Server2) : WLS_SOA1,WLS_SOA2

- すべての管理対象サーバーに対して分散モードを無効にします。スクリプトにより、指定されたクラスタのすべての管理対象サーバーに対して分散を無効化できます。分散モードを指定するように求められたら、falseを指定します。デフォルトでは、分散モードはtrueに設定されています。

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

ドメイン構成をWCCHOST2に伝播した後、拡張したドメインでOracle HTTP Serverを構成します。

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

- 第12.8.1項「WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成」

- 第12.8.2項「フロントエンドHTTPホストおよびポートの設定」

- 第12.8.3項「ロード・バランサを介したアクセスの検証」

12.8.1 WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成

WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

WLS_SOA管理対象サーバー用にOracle HTTP Serverを構成する手順は次のとおりです。

1. WEBHOST1およびWEBHOST2上の各Webサーバーで、ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/wccinternal_vh.confファイルおよびORACLE_INSTANCE/config/OHS/ohs2/moduleconf/wccinternal_vh.confファイルに次の行を追加します。

# WSM-PM
<Location /wsm-pm>
WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# SOA soa-infra app
<Location /soa-infra>
WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Worklist
<Location /integration/>
WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow/>
WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Workflow
<Location /workflow>
WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

#SOA Composer
<Location /soa/composer>
WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

参照トポロジで、ORACLE_INSTANCEは/u02/oracle/config/web1または/u02/oracle/config/web2ディレクトリです。

2. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

/u02/oracle/config/webN/bin/opmnctl restartproc ias-component=ohsX

ias-componentに対して、WEBHOST1ではweb1を使用し、WEBHOST2ではweb2を使用します。

WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このノードのリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。

次に例を示します。

- 例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時にその場で検出されます。

- 例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのメンバーをすべてリストに記述した場合は、Oracle HTTP Serverの起動時にそのうちの1つ以上を実行しておくことで、クラスタに確実に到達できます。

WebLogic Serverプラグインの構成の詳細は、『Oracle WebLogic ServerでWeb Serverプラグインを使用するOracle Fusion Middlewareのガイド』を参照してください。

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

Oracle SOA SuiteサーバーをホスティングするOracle WebLogic Serverクラスタについて、フロントエンドHTTPのホストとポートを設定する必要があります。

Oracle SOA SuiteクラスタのフロントエンドHTTPホストとポートを設定する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「チェンジ・センター」セクションに移動して、「ロックして編集」をクリックします。

3. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

4. 「クラスタ」をクリックします。

5. 「サーバーのサマリー」ページで、「SOA_Cluster」を選択します。

6. 「HTTP」タブを開きます。

7. 次の値を設定します。

- フロントエンド・ホスト: wccinternal.example.com

- フロントエンドHTTPポート: 80

8. 「保存」をクリックします。

9. 管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

10. WebLogic Server管理コンソールを使用してWLS_SOA1およびWLS_SOA2の管理対象サーバーを再起動し、クラスタ内のフロントエンド・ホスト・ディレクティブを有効にします。

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

管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」を参照してください。

次のURLを使用し、SOA_Clusterにアクセスできることを検証します。

- 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

ロード・バランサを使用してシステム・アクセスを構成する方法の詳細については、第3.3項「ロード・バランサ」を参照してください。

12.9 トランザクション・リカバリのためのデフォルトの永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:
デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。

Oracle SOA Suite管理対象サーバーのデフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. このページの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

3. 左側の「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」ノードをクリックします。

4. 「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)サーバー名WLS_SOA1をクリックします。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

5. 「構成」タブで「サービス」タブをクリックします(トップレベルの「サービス」タブではありません)。

6. 表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。

ASERVER_HOME/SOA_Cluster/tlogs/

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

7. WLS_SOA2サーバーについて手順4、5、6を繰り返します。

8. 「保存」→「変更のアクティブ化」をクリックします。

9. WebLogic Server管理コンソールを使用して、WLS_SOA1およびWLS_SOA2の管理対象サーバーを再起動します。

10. WLS_SOA1とWLS_SOA2を再起動した後、次のディレクトリに次のDATファイルが作成されていることを確認します。

ASERVER_HOME/SOA_Cluster/tlogs/

- _WLS_WLS_SOA1000000.DAT

- _WLS_WLS_SOA2000000.DAT

注意:
トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリは存在する必要があります。

12.10 WLS_SOA管理対象サーバー用のノード・マネージャの構成

ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第16章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照してください。その章の手順をOracle WebCenter Contentデプロイメントで実行する必要があります。

第16.3項「ノード・マネージャでのホスト名検証証明書の有効化」の手順は、次の表のホストとOracle SOA Suite管理対象サーバーに対して実行する必要があります。

ホスト名(HOST)

仮想IPアドレス(VIP)

サーバー名(WLS_SERVER)

WCCHOST1

WCCHOST1VHN1

WLS_SOA1

WCCHOST2

WCCHOST2VHN1

WLS_SOA2

Oracle SOA Suite管理対象サーバーをサーバー移行するには、それらのサーバーを指定の仮想ホスト名に関連付ける必要があります。これらの仮想ホスト名がDNSまたはシステム内の/etc/hosts解決で有効になっていることおよびそれらが適切な仮想IPアドレスにマップされていることを確認します。詳細は、第3.4項「IPアドレスおよび仮想IPアドレス」を参照してください。

12.11 WLS_SOA管理対象サーバー用のサーバー移行の構成

サーバー移行は、WCCHOST1ノードとWCCHOST2ノードのどちらかで障害が発生した場合に、Oracle SOA Suiteコンポーネントを正しくフェイルオーバーするために必要です。詳細は、第17章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。Oracle SOA Suiteに関しては、その章で次の変数の値を使用します。

- サーバー名:

- WLS_SERVER1: WLS_SOA1

- WLS_SERVER2: WLS_SOA2

- ホスト名:

- HOST1: WCCHOST1

- HOST2: WCCHOST2

- クラスタ名:

- CLUSTER: SOA_Cluster

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

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップの詳細は、Oracle Databaseバックアップおよびリカバリ・ガイドを参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

1. WEBHOST1でOracle Web層をバックアップします。

1. opmnctlを使用してインスタンスを停止します。

/u02/oracle/config/webN/bin/opmnctl stopall

2. 次のコマンドをrootとして実行して、Oracle Web層のMiddlewareホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドを実行して、Oracle Web層のOracleインスタンスをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

4. 次のように、opmnctlを使用してインスタンスを起動します。

cd /u02/oracle/config/webN/bin

opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。

3. ドメイン構成を保存するために、管理サーバーと管理対象サーバーのドメイン・ディレクトリをバックアップします。構成ファイルはすべて/u01/oracle/config/domains/WCCDomainディレクトリに存在しています。WCCHOST1で次のコマンドを実行して、バックアップを作成します。

tar -cvpf edgdomainback.tar /u01/oracle/config/domains/WCCDomain

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

この章では、Fusion Middleware構成ウィザードを使用して、Oracle WebCenter Content: Imagingを含むドメインの拡張方法について説明します。

この章には次の項が含まれます:

- 第13.1項「Imagingを追加するためのドメインの拡張の概要」

- 第13.2項「WCCHOST1でのVIP4およびWCCHOST2でのVIP5の有効化」

- 第13.3項「Imagingを使用したドメインの拡張」

- 第13.4項「管理サーバーの再起動」

- 第13.5項「Imaging用の構成後タスクおよび検証タスクの実行」

- 第13.6項「Imagingクラスタと使用するOracle HTTP Serverの構成」

- 第13.7項「WLS_IMG管理対象サーバーのノード・マネージャの構成」

- 第13.8項「WLS_IMG管理対象サーバー用のサーバー移行の構成」

- 第13.9項「インストールのバックアップ」

注意:
セットアップのプロセスを開始する前に、各プラットフォームのOracle Fusion Middlewareリリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。

13.1 Imagingを追加するためのドメインの拡張の概要

Imagingシステムは、第7章「エンタープライズ・デプロイメント用のソフトウェアのインストール」で作成された、共有記憶域上のWL_HOMEとORACLE_HOMEの場所を使用してインストールされます。

Imagingを追加するためにドメインを拡張します。表13-1に、Imagingの構成手順と、Imaging管理対象サーバーを使用したドメインの拡張に必要なタスクを示します。

表13-1 Imagingを含むドメインの拡張手順

手順

説明

詳細

Imagingを使用するためのドメインの拡張の準備

Imaging WebLogic Serverクラスタの各ホスト名で仮想IPアドレスのマッピングを有効にします。

第13.2項「WCCHOST1でのVIP4およびWCCHOST2でのVIP5の有効化」

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインをOracle WebCenter Content: Imagingで拡張します。

第13.3項「Imagingを使用したドメインの拡張」

Imagingのホスト名検証の無効化

トポロジの設定と検証中にホスト名の検証を無効にします。

第13.5.1項「WLS_IMG管理対象サーバーに対するホスト名検証の無効化」

Imaging管理対象サーバーへのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第13.5.2項「WLS_IMG1およびWLS_IMG2へのドメイン構成の伝播」

JMS永続ストアの構成

両方のImaging管理対象サーバーへ参照できるディレクトリとして、JMS永続ストアの場所を構成します。

第13.5.3項「Imaging用のJMS永続ストアの構成」

ドメインの管理サーバーの再起動

管理サーバーを停止し、再起動します。

第13.4項「管理サーバーの再起動」

Imaging管理対象サーバーの起動

WLS_IMG1およびWLS_IMG2管理対象サーバーを起動します。

第13.5.4項「Imaging管理対象サーバーの起動」

GridLinkデータ・ソースおよびOracle Notification Service (ONS)の構成の確認

GridLinkデータ・ソースおよびONSの構成が適切であることを確認する手順に従います。

第13.5.5項「ImagingのGridLinkデータ・ソースの検証」

ImagingのシステムMBeanの構成

システムMBeanブラウザで、InputDirectories、SampleDirectoryおよびGDFontPathのMBeanを構成します。

第13.5.7項「Imaging用のシステムMBeanの構成」

WebCenter ContentのImaging機能セットの有効化

Oracle WebCenter Content ServerのIpmRepositoryコンポーネントを有効にします。

第13.5.8項「Oracle WebCenter ContentにおけるImaging機能セットの有効化」

Imagingビューア・キャッシュの構成

Imagingビューアを設定してキャッシュされたドキュメントを使用します。

第13.5.9項「Imagingビューア・キャッシュの構成」

キャッシュされたドキュメントの暗号化

追加のセキュリティが必要な場合には、キャッシュされたドキュメントを暗号化します。

第13.5.10項「キャッシュされたドキュメントの暗号化」

Imaging管理対象サーバーに対するリスニング・アドレスの追加

WLS_IMG1およびWLS_IMG2管理対象サーバー(WCCHOST1VHN2およびWCCHOST2VHN2)のホスト名をSocketHostNameSecurityFilterパラメータ・リストに追加します。

第13.5.11項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」

ImagingとWebCenter Content管理対象サーバーの間の接続の作成

Oracle WebCenter Content Serverへの接続を作成します。

第13.5.12項「コンテンツ・サーバーへの接続の作成」

BPEL CSF資格証明の構成

Oracle SOA Suiteとの通信に必要な資格証明を構成します。

第13.5.13項「BPEL CSF資格証明の構成」

Imaging用のワークフロー接続の構成

ワークフロー接続を作成し、テストします。

第13.5.14項「ワークフロー接続の構成」

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

管理対象サーバーとともにOracle HTTP Serverを構成し、IMG_ClusterのWLSクラスタ・アドレスを設定します。

第13.6項「Imagingクラスタと使用するOracle HTTP Serverの構成」

Oracle HTTP Serverを介したWebCenter Contentへのアクセスの検証

URLを検証し、Oracle HTTP ServerからIMG_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

第13.6.2項「ロード・バランサを介したアクセスの検証」

ドメインの管理対象サーバーとノード・マネージャ間通信に対するホスト名検証の構成

管理サーバーや他のサーバーとの通信には、それぞれのアドレス用の証明書を使用します。

第13.7項「WLS_IMG管理対象サーバーのノード・マネージャの構成」

Imaging管理対象サーバー用のサーバー移行の構成

移行のためのImaging管理対象サーバー名、ホスト名およびクラスタ名を指定します。

第13.8項「WLS_IMG管理対象サーバー用のサーバー移行の構成」

Imagingの構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第13.9項「インストールのバックアップ」

13.2 WCCHOST1でのVIP4およびWCCHOST2でのVIP5の有効化

Imagingシステムは、Imagingが実行している管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。これらの仮想ホスト名および対応する仮想IPアドレスは、Imagingコンポーネントのサーバー移行を有効にするために必要です。まだ対応していない場合は、VIP4からWCCHOST1のWCCHOST1VHN2に対して、またVIP5からWCCHOST2のWCCHOST2VHN2に対して仮想IPアドレスのマッピングを有効にし、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーまたは/etc/hosts解決のいずれかで)正しく解決する必要があります。

まだ仮想IPアドレスを有効化していない場合には、第6.6項「仮想IPアドレスの有効化」で説明している手順に従ってください。これらの仮想IPアドレスおよび仮想ホスト名は、Imagingサーバーでサーバー移行を有効にするときに必要となります。この後、高可用性を実現するために、Imagingサーバーのサーバー移行を構成できます。サーバー移行の構成の詳細は、第17章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。

13.3 Imagingを使用したドメインの拡張

Oracle WebCenter Content: Imagingを追加するには、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成し、WebCenter Content、Inbound Refinery、CaptureおよびOracle SOA Suiteで拡張したドメインを拡張します。この項の手順は、Oracle WebCenter Contentのデプロイメントと同じデータベース・サービス(wccedg.example.com)をImagingのデプロイメントでも使用することを前提としています。ただし、Imaging専用の別のデータベース・サービスをデプロイメントに使用することもできます。

注意:
これらの手順を実行する前に、Oracle Fusion Middleware管理者ガイドの説明に従ってドメインをバックアップしてください。

Imagingを使用するためにドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。
Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内のすべての管理対象サーバーを停止します。

3. WCCHOST1で、ディレクトリをFusion Middleware構成ウィザードの場所に変更します。これはOracle共通ホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行します)。

cd ORACLE_COMMON_HOME/common/bin

4. Fusion Middleware構成ウィザードを起動します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. 「WebLogicドメイン・ディレクトリの選択」画面で、WebLogic Serverのドメイン・ディレクトリ(ASERVER_HOME)を選択し、「次へ」をクリックします。
参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

7. 「拡張ソースの選択」画面(図13-1)で、次の選択を行います。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。
Oracle WebCenter Content: Imagingビューア・キャッシュ

Oracle WebCenter Content: Imaging

(前述の製品のうちの1つを選択すると、もう一方の製品も自動的に選択されます。)

注意:

- BPEL用のAXFがImagingに追加されています。

- Oracle WebCenter Content: AXF for BPMをImagingに追加する方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』を参照してください。

次の製品は、ドメインを作成した際(第8.3項)あるいはWebCenter Content用(第10.2項)、Inbound Refinery用(第11.2項)またはOracle SOA Suiteコンポーネント用(第12.3項)にドメインを拡張した際に選択している場合、グレー表示されます。

- WebLogic Serverの基本ドメイン

- Oracle SOA Suite

- Oracle Universal Content Management - Inbound Refinery

- Oracle Universal Content Management - Content Server

- Oracle Enterprise ManagerプラグインIBR用

- Oracle Enterprise Manager

- Oracle WSMポリシー・マネージャ

- Oracle JRF

図13-1 Imagingの「拡張ソースの選択」画面

「次へ」をクリックします。

8. 図13-2に示す「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. (Imagingの場合は)IPMスキーマのみを選択します。他の既存スキーマはいずれも選択しないでください。

2. RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます(付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照)。ここでの説明に合せて、「GridLinkへ変換」を選択します。
RAC構成を選択すると、選択されたすべてのスキーマがグレー表示されます。

図13-2 Imagingの「JDBCコンポーネント・スキーマの構成」画面

3. 「次へ」をクリックします。

9. 「GridLink RACコンポーネント・スキーマの構成」画面(図13-3)で、次の手順を実行します。

1. IPMスキーマが選択されていることを確認します。その他のデータ・ソースはそのままにします。

図13-3 Imagingの「GridLink RACコンポーネント・スキーマの構成」画面

2. 次の各フィールドに値を入力して、RCUでシードされたGridLink RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 11以上を選択します。

- サービス名: Oracle RACデータベースのサービス名は小文字で入力し、ドメイン名を続けます(例: wccedg.example.com)。

- ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてWCCを使用しています。

- パスワード: データベース・スキーマの所有者のパスワードを入力します。

- 「FANの有効化」を選択します。

- SSLの有効化: このオプションは選択解除したままにします。
SSLを選択してOracle Notification Service (ONS)の通知暗号化を有効にする場合は、「ウォレット・ファイル」および「ウォレット・パスワード」の詳細を適切に指定します。

- サービス・リスナー: 使用するOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。プロトコルはTCPである必要があります。
SCANアドレスを使用してサービス・リスナー(およびOSNホスト)を指定することをお薦めします。これにより、Oracle RACノードを追加または削除しても、SCANアドレスを含むGridLinkデータ・ソースを更新する必要がありません。SCANアドレスを特定するには、データベース内のremote_listenerパラメータを問い合せます。

SQL>show parameter remote_listener;

NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      db-scan.example.com :1521

注意:
Oracle Database 11gリリース1 (11.1)の場合は、次の例に示すように、各データベース・インスタンス・リスナーの仮想IPアドレスとポートを使用します。

wccdbhost1-vip.example.com (port 1521)

wccdbhost2-vip.example.com (1521)

- ONSホスト: データベースによって報告されるRACデータベースのSCANアドレスとONSリモート・ポートも入力します。

[orcl@WCCDBHOST1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベースのONSサービスのホスト名とポートを使用します。

wccdbhost1.example.com (port 6200)

wccdbhost2.example.com (6200)

3. 「次へ」をクリックします。

注意:
「UCMスキーマ」、「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」、「OWSM MDSスキーマ」および「SOA MDSスキーマ」の情報はそのままにしておきます。

10. 「JDBCコンポーネント・スキーマのテスト」画面で、「IPMスキーマ」行を選択し、「接続のテスト」をクリックします。
結果は「接続結果ログ」に表示されます。スキーマを含むデータベースへの接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正してテストを再試行します。

図13-4 Imagingの「JDBCコンポーネント・スキーマのテスト」画面

接続に成功したら、「次へ」をクリックします。

11. 「オプションの構成を選択」画面で、次のオプションを選択します。

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

12. 「JMS分散宛先タイプの選択」画面で、すべてのOracle Fusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストからUDDを選択します。「次へ」をクリックします。オーバーライドの警告が表示された場合、「OK」をクリックして、このメッセージを確認します。

13. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
サーバーが自動的に作成されます。このサーバーの名前をWLS_IMG1に変更し、WLS_IMG2という新しいサーバーを追加します。表13-2に示す属性をこれらのサーバーに指定します。画面に表示されている他のサーバーは変更せず、そのままにしておきます。

表13-2 Imagingの管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_IMG1

WCCHOST1VHN2

16000

n/a

いいえ

WLS_IMG2

WCCHOST2VHN2

16000

n/a

いいえ

「次へ」をクリックします。

14. 「クラスタの構成」画面で、「追加」をクリックし、表13-3に示すクラスタを追加します。画面に表示されている他のクラスタは変更せず、そのままにしておきます。

表13-3 Imagingのクラスタ構成

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

IMG_Cluster

ユニキャスト

n/a

n/a

空のままにします。

「次へ」をクリックします。

15. 「サーバーのクラスタへの割当」画面で、次の項目を追加します。画面に表示されている他の割当ては変更せず、そのままにしておきます。

- IMG_Cluster:

- WLS_IMG1

- WLS_IMG2

「次へ」をクリックします。

16. 「マシンの構成」画面で、「Unixマシン」タブを開きます。マシンWCCHOST1およびWCCHOST2を確認して、次のように入力します。

表13-4 マシンおよびノード・マネージャのリスニング・アドレス

名前

ノード・マネージャのリスニング・アドレス

WCCHOST1

WCCHOST1

WCCHOST2

WCCHOST2

ADMINHOST

localhost

その他のすべてのフィールドはデフォルト値のままにします。「次へ」をクリックします。

17. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- WLS_IMG1をWCCHOST1に割り当てます。

- WLS_IMG2をWCCHOST2に割り当てます。

「次へ」をクリックします。

18. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のようにターゲット設定されていることを確認します(図13-5を参照)。

- usermessagingserverおよびusermessagingdriver-emailデプロイメントは、SOA_Clusterにのみターゲット設定します(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。

- WSM-PMはSOA_Clusterにのみターゲット設定する必要があります。

- oracle.rules.*、oracle.sdp.*およびoracle.soa.*の各デプロイメントは、SOA_Clusterにのみターゲット設定する必要があります。ただし、oracle.soa.workflow.wcライブラリは除きます。これは、SOA_ClusterとIMG_Clusterの両方にターゲット設定する必要があります。

- EMアプリケーションは、AdminServerにのみターゲット設定します。

図13-5 デプロイメントのImagingクラスタへのターゲット設定

「次へ」をクリックします。

19. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、IMG_Clusterにターゲット設定されるすべてのOPSS関連のデータ・ソースを選択します。

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

「次へ」をクリックします。

20. 「構成のサマリー」画面で、「拡張」をクリックします。

21. ドメインのポートの競合に関する警告ダイアログ・ボックスが表示された場合、「OK」をクリックします。この警告は、ノードに以前から存在していたサーバーによるもので、無視してかまいません。

22. 「ドメインの作成中」画面で、「完了」をクリックします。

13.4 管理サーバーの再起動

ドメイン拡張の変更を有効にするには、Oracle WebLogic Scripting Tool (WLST)でノード・マネージャのnmKillコマンドとnmStartコマンドを使用して管理サーバーを再起動する必要があります(第10.3項「管理サーバーの再起動」を参照)。管理サーバーを停止する際には、nmKillのかわりに管理コンソールを使用できます。

13.5 Imaging用の構成後タスクおよび検証タスクの実行

次の項では、Imaging用の構成後タスクと検証タスクを実行する方法について説明します。

- 第13.5.1項「WLS_IMG管理対象サーバーに対するホスト名検証の無効化」

- 第13.5.2項「WLS_IMG1およびWLS_IMG2へのドメイン構成の伝播」

- 第13.5.3項「Imaging用のJMS永続ストアの構成」

- 第13.5.4項「Imaging管理対象サーバーの起動」

- 第13.5.5項「ImagingのGridLinkデータ・ソースの検証」

- 第13.5.6項「Imagingビューア・キャッシュのデプロイメントの検証」

- 第13.5.7項「Imaging用のシステムMBeanの構成」

- 第13.5.8項「Oracle WebCenter ContentにおけるImaging機能セットの有効化」

- 第13.5.9項「Imagingビューア・キャッシュの構成」

- 第13.5.10項「キャッシュされたドキュメントの暗号化」

- 第13.5.11項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」

- 第13.5.12項「コンテンツ・サーバーへの接続の作成」

- 第13.5.13項「BPEL CSF資格証明の構成」

- 第13.5.14項「ワークフロー接続の構成」

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

このガイドで説明するエンタープライズ・デプロイメントでは、Imagingを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_IMG1およびWLS_IMG2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.5項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したら、ホスト名検証を再び有効化します。詳細は、第16.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

13.5.2 WLS_IMG1およびWLS_IMG2へのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

Imaging管理対象サーバーへのドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateIMG.jar -template_name=edgdomain_templateIMG

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

3. 次のunpackコマンドをWCCHOST1で実行して、前の手順で作成したテンプレートをWLS_IMG1ドメイン・ディレクトリに伝幡します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateIMG.jar -app_dir=APPLICATION_HOME -overwrite_domain=true

参照トポロジで、MSERVER_HOMEは/u02/oracle/config/domains/WCCDomainディレクトリで、APPLICATION_HOMEは/u01/oracle/config/applications/WCCDomainディレクトリです。

注意:

- unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

- APPLICATION_HOMEディレクトリは、このunpackコマンドでバックアップされます。

- unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびEARファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびEARファイルをリストアする必要があります。

4. 次のコマンドをWCCHOST1で実行し、手順1で作成したテンプレート・パックをWCCHOST2にコピーします。

scp edgdomaintemplateIMG.jar oracle@WCCHOST2: /u01/oracle/products/fmw_home/oracle_common/common/bin

5. 次のunpackコマンドをWCCHOST2で実行して、伝播されたテンプレートをWLS_IMG2管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=/u02/oracle/config/domains/WCCDomain  -template=edgdomaintemplateIMG.jar -app_dir=/u01/oracle/config/applications/WCCDomain –overwrite_domain=true

注意:

- unpackコマンドはWL_HOME/common/bin/から実行するのではなく、ORACLE_COMMON_HOME/common/bin/ディレクトリから実行してください。

- APPLICATION_HOMEディレクトリは、このunpackコマンドでバックアップされます。

6. ここまでの変更を有効にするために管理サーバーを再起動します。まずnmKillコマンドまたは管理コンソールで管理サーバーを停止し、次にnmStartコマンドで起動します(第10.3項「管理サーバーの再起動」を参照)。その後weblogicユーザーの資格証明を使用して管理コンソールにログインします。

13.5.3 Imaging用のJMS永続ストアの構成

2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Oracle WebCenter Content: Imagingで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(デフォルト/u01/oracle/config/applications/WCCDomain/servers/server_name/data/store/)を使用しています。

共有ベースのディレクトリを使用するように、ImagingのJMSサーバーの永続ストアを変更する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。

3. 「永続ストアのサマリー」ページで「ロックして編集」をクリックします。

4. 「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。

5. 名前(例: IMGJMSServer1Store。これにより、作成対象のサービスを特定できます)およびターゲットのWLS_IMG1を入力します。WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを入力します(/u01/oracle/config/domains/WCCDomain/IMG_Cluster/jms)。

6. 「OK」をクリックして、変更をアクティブ化します。

7. 左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」→「JMSサーバー」ノードをクリックします。

8. 「JMSサーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)JMSサーバー「IpmJmsServer1 JMSサーバー」をクリックします。

9. このJMSサーバーの「設定」ページで、「ロックして編集」をクリックしてください。

10. 「永続ストア」ドロップダウン・リストで、「IMGJMSServer1Store」を選択します。

11. 「保存してアクティブ化」をクリックします。

12. 手順を繰り返して、IpmJmsServer2のIMGJMSServer2Storeを作成します。

13.5.4 Imaging管理対象サーバーの起動

WCCHOST1よびWCCHOST2でImaging管理対象サーバーを起動します。

Imaging管理対象サーバーを起動する手順は次のとおりです。

1. 管理対象サーバーWLS_IMG1を起動します。

1. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにログインします。

2. 左側の「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. 表の「サーバー」列から「WLS_IMG1」を選択します。

5. 「起動」をクリックします。

2. http://WCCHOST1VHN2:16000/imagingにアクセスしてWLS_IMG1のステータスを確認します。「Oracle WebCenter Content: Imaging」ログイン・ページが開きます。WebLogic Server管理のユーザー名とパスワードを入力し、ログインします。

3. 管理対象サーバーWLS_IMG2を起動します。

1. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにログインします。

2. 左側の「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. 表の「サーバー」列から「WLS_IMG2」を選択します。

5. 「起動」をクリックします。

4. http://WCCHOST2VHN2:16000/imagingにアクセスしてWLS_IMG2のステータスを確認します。「Oracle WebCenter Content: Imaging」ログイン・ページが開きます。WebLogic Server管理のユーザー名とパスワードを入力し、ログインします。

注意:
ここで示す手順は、WCCHOST2でOracle WSMまたはOracle SOA Suiteの管理対象サーバーについて事前にホスト名の検証が行われており、さらに、WCCHOST2でノード・マネージャがすでに実行されていることを前提としています。

13.5.5 ImagingのGridLinkデータ・ソースの検証

サーバーを起動したら、GridLinkデータ・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。

ImagingのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. 作成したGridLinkデータ・ソースの名前をクリックします。

4. 「監視」タブをクリックします。

5. 「テスト」タブ(図13-6)をクリックし、いずれかのサーバーを選択し、「データ・ソースのテスト」をクリックします。

図13-6 ImagingのGridLinkデータ・ソースのテスト

構成が適切であればテストは成功します。

6. GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスでテストを繰り返します。

ImagingのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。

1. 管理コンソールの「ドメイン構造」ツリーで、「サービス」ノードを開いて「データ・ソース」をクリックします。

2. GridLinkデータ・ソースの名前をクリックします。

3. 「監視」タブをクリックします。

4. サーバーの名前(WLS_IMG1)をクリックします。

5. 「ONS」タブをクリックし、「テスト」タブ(図13-7)をクリックします。

6. サーバーを選択し、「ONSのテスト」をクリックします。

図13-7 Imagingの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テストを繰り返します。

13.5.6 Imagingビューア・キャッシュのデプロイメントの検証

Imagingサーバーが起動したら、ビューア・キャッシュが正しくデプロイされていることを確認します。

Imagingビューア・キャッシュのデプロイメントを検証する手順は次のとおりです。

1. WebLogic Server管理コンソールで、左側の「ドメイン構造」の「デプロイメント」をクリックします。

2. 「デプロイメント」表のimaging-vc行で、「状態」の値が「アクティブ」、「ヘルス」の値が「OK」であることを確認します。
imaging-vcの「状態」または「ヘルス」の値が異なる場合は、続行する前に機能を再デプロイする必要があります。

13.5.7 Imaging用のシステムMBeanの構成

Imaging用に次のシステムMBeanを構成できます。

- InputDirectories

- SampleDirectory

- GDFontPath

Imaging用にシステムMBeanを構成する手順は次のとおりです。

1. http://ADMINVHN:7001/emでOracle Enterprise Manager Fusion Middleware Controlにログインします(図13-8)。

図13-8 システムMBeanブラウザ

2. 左側のナビゲーション・ツリーで、ファームのドメイン名→「WebLogicドメイン」→ドメイン名→「IMG_Cluster」を開き、「WLS_IMG1」をクリックします。

3. 一番上で、「WebLogic Server」ドロップダウン・メニューをクリックし、「システムMBeanブラウザ」を選択します。

4. 「アプリケーション定義のMBean」→「oracle.imaging」を開きます。

5. 「サーバー: WLS_IMG1」→「config」を開きます。

6. 豆の形をした「config」リンクをクリックします。

7. 右側で、InputDirectories MBeanを設定し、パスを入力ファイル(ASERVER_HOME/IMG_Cluster/input_files)に指定します。
参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

関連するすべてのOracle WebCenter Contentのサーバーがこの場所を解決(つまりNFSマウント・ポイントを経由)できる必要があります。

8. SampleDirectoryのMBeanを次のように設定します: ASERVER_HOME/IMG_Cluster/input_files/Samples
入力ファイルを処理するには、入力エージェントが入力ディレクトリに対して適切な権限を持ち、入力ディレクトリにおいてファイル・ロックができる必要があります。入力エージェントを使用する場合は、WebLogic Serverのサービスを実行中のユーザー・アカウントが、入力ディレクトリと入力ディレクトリ内のすべてのファイルとサブディレクトリに対して、読取りと書込みの権限を保持している必要があります。この必要な権限によって、入力エージェントは、ファイルを処理する際に様々なディレクトリにファイルを移動できます。クラスタのサーバー間で処理を調整するために、共有上のファイル・ロックが入力エージェントに必要になります。

9. X Windowsシステム用のGDフォントへのパスを指定するように「GDFontPath」のMBeanを設定します。システム管理者に確認してください。多くの場合、デフォルトは、/usr/share/X11/fonts/TTFまたは/usr/lib/X11/fonts/TTFです。

10. 変更が2番目の管理対象サーバー(WLS_IMG2)に反映されていることを検証します。反映されていない場合、これらの変更をWLS_IMG2に追加します。

11. 「適用」をクリックします。

13.5.8 Oracle WebCenter ContentにおけるImaging機能セットの有効化

Oracle WebCenter Content Serverコンポーネント・マネージャでImagingの機能セットを有効にします。

WebCenter Contentにおいて、Imagingの機能セットを有効にする手順は次のとおりです。

1. http://WCCHOST1:16200/csでコンテンツ・サーバーにログインします。

2. 「管理」トレイまたはメニューで、「管理サーバー」、「コンポーネント・マネージャ」の順に選択します。

3. 「コンポーネント・マネージャ」ページの「統合」で「IpmRepository」を選択します。

4. 「更新」をクリックしてIpmRepositoryコンポーネントを有効にし、次のアクションを行います。

1. 「コンポーネント・マネージャ」ページの段落で、「拡張コンポーネント・マネージャ」をクリックします。

2. 「拡張コンポーネント・マネージャ」ページで、「有効なコンポーネント」ボックスにIpmRepositoryがあることを確認します。

5. WebLogic Server管理コンソールを使用して管理対象サーバーを再起動し(第8.4.3項「WCCHOST1での管理サーバーの起動」の手順を参照)、続いてOracle WebCenter Contentクラスタ内のすべての管理対象サーバーを再起動します。

13.5.9 Imagingビューア・キャッシュの構成

Imagingビューアは、サーバーのリポジトリの外にドキュメントをキャッシュして、クライアント・マシンのレンダリング速度を向上させることを可能にします。キャッシュされたドキュメントのセキュリティは、ドキュメントがストアされているサーバーの認証により制御されます。サーバーが保護されていれば、追加のセキュリティは必要ありません。

追加のセキュリティが必要な場合は、第13.5.10項「キャッシュされたドキュメントの暗号化」の説明に従ってキャッシュされたドキュメントを暗号化できます。プレキャッシュ・オプションを使用する場合、および大量のドキュメントを処理する際のインジェスチョンおよびレンダリングを最適化する方法の詳細は、Oracle Fusion Middleware Oracle WebCenter Content: Imagingの管理のビューア・キャッシュが有効化された場合のインジェスチョンおよびレンダリングのバランシングに関する項を参照してください。

Imagingビューアを設定してキャッシュされたドキュメントを使用するには、次のシステムMBeanを設定する必要があります。

- ViewerCachePath

- ViewerCacheDays

- ViewerCacheEnablePrecache

Imagingビューア・キャッシュでこれらのMBeanを構成するには、次のように第13.5.7項「Imaging用のシステムMBeanの構成」の手順を使用します。

- ViewerCachePath MBeanをドキュメントがキャッシュされる場所に設定し、「適用」をクリックします。

ASERVER_HOME/IMG_Cluster/ViewerCache

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

注意:
ViewerCachePath MBeanは、クラスタ内のすべてのサーバーから利用可能な場所に設定する必要があります。ディレクトリ・パスがすべてのサーバーから利用可能でない場合は、各サーバーはローカルにドキュメントをキャッシュします。その結果、キャッシュ全体のインスタンスが複数存在します。

- ViewerCacheDays MBeanを30に設定し、「適用」をクリックします。

注意:
この構成値は、キャッシュされたイメージがキャッシュからクリアされる前に維持される必要のある日数を指定します。ViewerCacheDaysを0に設定すると、キャッシュがクリアされるのを防ぐことができます。

- ViewerCacheEnablePrecache MBeanをtrueに設定し、「適用」をクリックします。

注意:
この構成値は、ドキュメントがImagingに取り込まれてすぐにキャッシュされる(プレキャッシュされる)必要があるかどうかを指定します。

- キャッシュされたドキュメントを暗号化する場合は、第13.5.10項「キャッシュされたドキュメントの暗号化」の説明に従って、それらを暗号化するようにImagingを構成します。

注意:
これは、キャッシュのページ・イメージを暗号化する追加オプションです。ViewerCacheEnableEncryption MBeanを設定する前に、ドメインにパスワード資格証明が存在している必要があります。パスワード資格証明を追加するには、第13.5.10項「キャッシュされたドキュメントの暗号化」の手順を使用します。

ビューア・キャッシュを別の場所に移動する方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』のビューア・キャッシュ・パスの変更に関する項を参照してください。

13.5.10 キャッシュされたドキュメントの暗号化

追加のセキュリティが必要な場合は、キャッシュされたドキュメントを暗号化するようにImagingを構成できます。暗号化すると、ドキュメントを参照するために復号化する追加処理が必要となり、レンダリング速度が低下します。キャッシュされたドキュメントを暗号化するようにImagingが構成されている場合も、生成されたドキュメントが暗号化されていなければ、キャッシングに短い所要時間が発生します。

キャッシュされたドキュメントの暗号化を有効化するには、Oracle Enterprise Manager Fusion Middleware Controlを使用して新しいパスワード資格証明をドメインに追加し、ViewerCacheEnableEncryption MBeanを設定します。

キャッシュされたドキュメントの暗号化を有効にする手順は次のとおりです。

1. http://ADMINVHN:7001/emでFusion Middleware Controlにログインします(図13-8)。

2. Oracle WebCenter Contentの「WebLogic Server」ドメインを選択します。

3. 「WebLogicドメイン」メニューで、「セキュリティ」→「資格証明」を選択します。

4. マップoracle.imagingを選択します。oracle.imagingという名前のマップが存在しない場合は、「マップの作成」をクリックして「マップ名」にoracle.imagingを入力し、選択します。

5. oracle.imagingマップで「キーの作成」をクリックします。キーにviewer.cacheと名前を付け、「パスワード」のタイプを選択します。

6. ユーザー名を入力します。ユーザー名はいずれかのシステムに存在している必要はありません。

7. パスワードを入力して確認し、「OK」をクリックします。

8. 第13.5.7項「Imaging用のシステムMBeanの構成」の説明に従って、ViewerCacheEnableEncryption MBeanをtrueに設定します。

暗号化の無効化の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』のキャッシュされたドキュメントの暗号化の無効化に関する項を参照してください。

13.5.11 Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加

WLS_IMG1およびWLS_IMG2管理対象サーバー(それぞれWCCHOST1VHN2およびWCCHOST2VHN2)のホスト名をSocketHostNameSecurityFilterパラメータ・リストに追加します。

Oracle WebCenter Contentで許可されているホストにImagingサーバーのリスニング・アドレスを追加する手順は次のとおりです。

1. テキスト・エディタでファイル/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgを開きます。

2. 次の行を削除またはコメント・アウトします。

SocketHostAddressSecurityFilter=127.0.0.1|WCCHOST1-IP|WCCHOST2-IP|WEBHOST1-IP|WEBHOST2-IP

3. Oracle WebCenter Contentへの接続を許可するアドレスのリストにWLS_IMG1およびWLS_IMG2のリスニング・アドレスを含めるために、次の行を追加します。

SocketHostNameSecurityFilter=localhost|localhost.example.com|WEBHOST1| WEBHOST2|WCCHOST1|WCCHOST2|WCCHOST1VHN1|WCCHOST2VHN1|WCCHOST1VHN2|WCCHOST2VHN2| ucminternal.example.com|load-balancer-host-name
AlwaysReverseLookupForHost=Yes

注意:

- 第19.13.13項「Oracle WebCenter Content: ImagingからOracle WebCenter Contentに情報量の多いドキュメントをアップロードする際のパフォーマンスを向上させる」でお薦めしているように、SocketHostAddressSecurityFilterの値にIPアドレス(リスニング・アドレス)を使用できます。

- ロード・バランサのホスト名は、第3.3項「ロード・バランサ」の仮想サーバーの構成で使用したホスト名です。

4. 変更されたconfig.cfgファイルを保存したら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

13.5.12 コンテンツ・サーバーへの接続の作成

Oracle WebCenter Content Serverへの接続をImagingで作成します。

コンテンツ・サーバー接続を作成する手順は次のとおりです。

1. http://WCCHOST1VHN2:16000/imagingでWLS_IMG1 Imagingコンソールにログインします。

2. 左側で、「接続の管理」→「Content Server接続の作成」をクリックします。

3. 新しい接続の名前と説明を入力し、「次へ」をクリックします。

4. 「接続設定」画面で、次のように変更します。

- 「ローカルContent Serverの使用」の選択を解除します。

- Content Serverポートを6300に設定します。

- 「Content Serverプール」にロード・バランサのアドレスucminternal.example.comを追加します。

Permission deniedエラーが発生した場合は、第13.5.11項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」に戻り、拒否されたホストの名前を許容ホストのリストに追加します。

「次へ」をクリックします。

5. 「接続セキュリティ」画面で、WebLogic Serverユーザーに対するデフォルトの選択をそのまま受け入れて、「次へ」をクリックします。

6. 接続の詳細を確認し、「送信」をクリックします。

13.5.13 BPEL CSF資格証明の構成

Oracle WebCenter Content: ImagingからBPELシステムに接続する場合、Oracle SOA Suiteと通信するために必要な資格証明を構成する必要があります。

BPEL CSF資格証明を追加する手順は次のとおりです。

1. WCCHOST1で、(管理サーバーが存在する)WCCHOST1のWebCenter ContentのOracleホーム配下にあるcommon/bin/の場所にディレクトリを変更します。

cd WCC_ORACLE_HOME/common/bin

(WCC_ORACLE_HOMEはOracle WebCenter ContentのOracleホームで、このOracleホームはEDGトポロジのMW_HOME/wcc_homeとなります。)

2. Oracle WebLogic Scripting Tool (WLST)を実行します。

./wlst.sh

3. connect()を実行して、ユーザー名、パスワードおよび管理サーバーのURL (t3://ADMINVHN:7001)を指定します。

wls:/offline> connect()

4. CSF(資格証明ストア・フレームワーク)資格証明を作成します。この資格証明は、ImagingがBPELシステムへの接続に使用する資格証明です。これをBPEL管理ユーザーにします。CSF資格証明は、別名がキーとなり、CSFの名前付きマップの内部に格納されるユーザー名/パスワードのペアです。OWSM Webサービスと統合するため、Imagingは現在oracle.wsm.securityという標準のOWSM CSFマップを使用しています。資格証明を作成するには、createCred WLSTコマンドを使用します。

wls:/domain_name/serverConfig> createCred(map="oracle.wsm.security", key="basic.credential", user="weblogic", password="password_for_credential")

コマンドのkey値は、Imaging管理ユーザー・インタフェースのBPEL接続定義のCredential Aliasプロパティに使用される別名です(APIのConnection.CONNECTION_BPEL_CSFKEY_KEYプロパティにも使用されます)。OWSMおよびBPELで使用される標準のデフォルト名であるため、この例では別名basic.credentialを使用します。ただし、別名はマップ内で一意であれば、任意に指定できます。

注意:
Oracle SOA Suiteシステムと、中央のLDAPおよびシングル・サインオン(SSO)のシステムとの統合時に、異なるユーザーやパスワード(あるいはその両方)を後で使用する場合、新しいマップの作成または既存マップの更新が必要となります。作成されるサンプル・ユーザーの詳細は、第18章「Oracle Identity Managementとの統合」を参照してください。

5. WebLogic Server管理コンソールを使用して、Oracle SOA SuiteおよびImagingの管理対象サーバーを再起動します。

13.5.14 ワークフロー接続の構成

Imaging用のワークフロー接続を作成し、テストします。

ワークフロー接続を構成する手順は次のとおりです。

1. http://WCCHOST1VHN2:16000/imagingでWLS_IMG1 Imagingコンソールにログインします。

2. 「接続の管理」で、「追加」アイコン→「ワークフロー接続の作成」をクリックします。

3. 「ワークフロー接続基本情報」ページで、接続名を入力します。この名前は、「接続の管理」パネルに表示されます。このフィールドは必須です。必要に応じて、接続の簡単な説明を入力します。接続タイプはデフォルトで「ワークフロー接続」に設定されます。

4. 「次へ」をクリックします。

5. ワークフロー接続設定ページで、次の手順を実行します。

1. 「HTTPフロントエンド・アドレス」フィールドで、ワークフロー・サーバー(http://wccinternal.example.com:80)のホスト名またはIPアドレス、ドメインおよびポート番号を指定します。このフィールドは必須です。

2. 「資格証明別名」フィールドに、第13.5.13項「BPEL CSF資格証明の構成」の説明に従って先ほど作成した資格証明の別名(basic.credential)を入力します。

3. 「プロバイダ」フィールドに、2つのOracle SOA Suiteサーバー・リスニング・アドレスをカンマで区切って、t3://SOAHOST1VHN1,SOAHOST2VHN1:8001と入力します。

4. 「接続のテスト」ボタンをクリックして、接続パラメータを確認し、BPELマシンに存在するコンポジットを確かめます。

5. 「次へ」をクリックします。

6. 必要に応じて、付与するセキュリティを変更します。

7. 「次へ」をクリックします。

8. 「送信」をクリックします。

13.6 Imagingクラスタと使用するOracle HTTP Serverの構成

WLS_IMG1とWLS_IMG2の管理対象サーバーが属するIMG_ClusterにOracle HTTP Serverからルーティングをできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

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

- 第13.6.1項「WLS_IMG管理対象サーバー用のOracle HTTP Serverの構成」

- 第13.6.2項「ロード・バランサを介したアクセスの検証」

13.6.1 WLS_IMG管理対象サーバー用のOracle HTTP Serverの構成

WLS_IMG管理対象サーバー用に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ファイルに次の行を追加します。

# Oracle WebCenter Content: Imaging Application
<Location /imaging >
WebLogicCluster WCCHOST1VHN2:16000,WCCHOST2VHN2:16000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

2. WEBHOST1およびWEBHOST2上の各Webサーバーで、ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/wccinternal_vh.confファイルおよびORACLE_INSTANCE/config/OHS/ohs2/moduleconf/wccinternal_vh.confファイルに次の行を追加します。

# Oracle WebCenter Content: Imaging Application
<Location /imaging/ws >
WebLogicCluster WCCHOST1VHN2:16000,WCCHOST2VHN2:16000
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# AXF WS Invocation
<Location /axf-ws >
WebLogicCluster WCCHOST1VHN2:16000,WCCHOST2VHN2:16000
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

参照トポロジで、ORACLE_INSTANCEは/u02/oracle/config/web1または/u02/oracle/config/web2ディレクトリです。

注意:
Captureなどのコンポーネントでは、ImagingのCaptureプロファイル構成にあるような内部参照のために、内部ロード・バランサのURL (wccinternal.example.com)を介して、これらのURIを使用します。

3. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohsX

ias-componentに対して、WEBHOST1ではohs1を使用し、WEBHOST2ではohs2を使用します。

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

URLを検証して、HTTPサーバーからIMG_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。

URLを検証する手順は次のとおりです。

1. WLS_IMG2が稼動している状態で、WebLogic Server管理コンソールからWLS_IMG1を停止します。

2. http://wcc.example.com/imagingにアクセスし、正しく動作していることを確認します。(Imagingサーバーが停止しているため、レポートやデータは取得できません。)

3. WebLogic Server管理コンソールからWLS_IMG1を起動します。

4. WebLogic Server管理コンソールでWLS_IMG2を停止します。

5. http://wcc.example.com/imagingにアクセスし、正しく動作していることを確認します。

6. WebLogic Server管理コンソールからWLS_IMG2を起動します。

13.7 WLS_IMG管理対象サーバーのノード・マネージャの構成

ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第16章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照してください。

その章の手順は、Oracle WebCenter Contentデプロイメント用に実行する必要があります。第16.3項「ノード・マネージャでのホスト名検証証明書の有効化」の手順は、次の表のホストとOracle SOA Suite管理対象サーバーに対して実行する必要があります。

ホスト名(HOST)

仮想IPアドレス(VIP)

サーバー名(WLS_SERVER)

WCCHOST1

WCCHOST1VHN2

WLS_IMG1

WCCHOST2

WCCHOST2VHN2

WLS_IMG2

Imaging管理対象サーバーをサーバー移行するには、それらのサーバーを指定の仮想ホスト名に関連付ける必要があります。これらの仮想ホスト名がDNSまたはシステム内の/etc/hosts解決で有効になっていることおよびそれらが適切な仮想IPアドレスにマップされていることを確認します。詳細は、第3.4項「IPアドレスおよび仮想IPアドレス」を参照してください。

13.8 WLS_IMG管理対象サーバー用のサーバー移行の構成

サーバー移行は、WCCHOST1ノードとWCCHOST2ノードのどちらかで障害が発生した場合に、Oracle WebCenter Content: Imagingのコンポーネントを正しくフェイルオーバーするために必要です。詳細は、第17章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。Imagingに関しては、その章で次の変数の値を使用します。

- サーバー名:

- WLS_SERVER1: WLS_IMG1

- WLS_SERVER2: WLS_IMG2

- ホスト名:

- HOST1: WCCHOST1

- HOST2: WCCHOST2

- クラスタ名:

- CLUSTER: IMG_Cluster

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

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

1. WEBHOST1でOracle Web層をバックアップします。

1. opmnctlを使用してインスタンスを停止します。

/u02/oracle/config/webN/bin/opmnctl stopall

2. 次のコマンドをrootとして実行して、Oracle Web層のMiddlewareホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドを実行して、Oracle Web層のOracleインスタンスをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

4. 次のように、opmnctlを使用してインスタンスを起動します。

cd /u02/oracle/config/webN/bin

opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。

3. ドメイン構成を保存するために、管理サーバーと管理対象サーバーのドメイン・ディレクトリをバックアップします。構成ファイルはすべて/u01/oracle/config/domains/WCCDomainディレクトリに存在しています。WCCHOST1で次のコマンドを実行して、バックアップを作成します。

tar -cvpf edgdomainback.tar /u01/oracle/config/domains/WCCDomain

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

この章では、Fusion Middleware構成ウィザードを使用して、Oracle WebCenter Enterprise Captureでドメインを拡張する方法について説明します。

この章には次の項が含まれます:

- 第14.1項「Captureを追加するためのドメインの拡張の概要」

- 第14.2項「WCCHOST1でのVIP6およびWCCHOST2でのVIP7の有効化」

- 第14.3項「Captureを使用するためのドメインの拡張」

- 第14.4項「管理サーバーの再起動」

- 第14.5項「Capture用の構成後タスクおよび検証タスクの実行」

- 第14.6項「Captureクラスタ用のOracle HTTP Serverの構成」

- 第14.7項「WLS_CPT管理対象サーバー用のノード・マネージャの構成」

- 第14.8項「WLS_CPT管理対象サーバー用のサーバー移行の構成」

- 第14.9項「インストールのバックアップ」

注意:
セットアップのプロセスを開始する前に、各プラットフォームのOracle Fusion Middlewareリリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。

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

Captureシステムは、第7章「エンタープライズ・デプロイメント用のソフトウェアのインストール」で作成された、共有記憶域上のWebLogic Serverホーム(WL_HOME)とOracleホーム(ORACLE_HOME)の場所を使用してインストールされます。

Captureを追加するためにドメインを拡張します。表14-1に、Captureの構成手順と、Capture管理対象サーバーを使用するためのドメインの拡張に必要なタスクを示します。

この構成は、Captureの初期設定専用です。CaptureプロファイルなどのCaptureの構成の詳細は、Oracle Fusion Middleware Oracle WebCenter Enterprise Captureの管理を参照してください。

表14-1 Captureを使用するためのドメインの拡張手順

手順

説明

詳細

Captureを使用するためのドメインの拡張の準備

Capture WebLogic Serverクラスタの各ホスト名で仮想IPアドレスのマッピングを有効にします。

第14.2項「WCCHOST1でのVIP6およびWCCHOST2でのVIP7の有効化」

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを拡張します。

第14.3項「Captureを使用するためのドメインの拡張」

Capture管理対象サーバーへのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第14.5.2項「WLS_CPT1およびWLS_CPT2へのドメイン構成の伝播」

JMS永続ストアの構成

両方のCapture管理対象サーバーへ参照できるディレクトリとして、JMS永続ストアの場所を構成します。

第14.5.5項「Capture用のJMS永続ストアの構成」

Capture管理対象サーバーの起動

WLS_CPT1およびWLS_CPT2管理対象サーバーを起動します。

第14.5.3.2項「Capture管理対象サーバーの起動」

GridLinkデータ・ソースおよびOracle Notification Service (ONS)の構成の確認

GridLinkデータ・ソースおよびONSの構成が適切であることを確認する手順に従います。

第14.5.4項「CaptureのGridLinkデータ・ソースの検証」

Capture管理対象サーバーに対するリスニング・アドレスの追加

WLS_CPT1およびWLS_CPT2管理対象サーバー(WCCHOST1VHN3およびWCCHOST2VHN3)のホスト名をSocketHostNameSecurityFilterパラメータ・リストに追加します。

第14.5.6項「Oracle WebCenter Contentで許可されたホストのリストに対するCaptureサーバーのリスニング・アドレスの追加」

Captureの構成の実行

Captureの初期構成を行った後に、その他のインストール後のタスクを実行します。

第14.5.3項「Captureの初期構成の実行」

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

管理対象サーバーとともにOracle HTTP Serverを構成し、CPT_ClusterのWLSクラスタ・アドレスを設定します。

第14.6項「Captureクラスタ用のOracle HTTP Serverの構成」

Captureに対するフロントエンドHTTPのホストおよびポートの設定

CPT_Clusterに対するフロントエンドHTTPのホストおよびポートを構成します。

第14.6.2項「フロントエンドHTTPホストおよびポートの設定」

Oracle HTTP Serverを介したWebCenter Contentへのアクセスの検証

URLを検証し、Oracle HTTP ServerからCPT_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

第14.6.3項「ロード・バランサを介したアクセスの検証」

Capture用のノード・マネージャの構成

移行のためのCapture管理対象サーバー名、ホスト名およびクラスタ名を指定します。

第14.7項「WLS_CPT管理対象サーバー用のノード・マネージャの構成」

Capture管理対象サーバー用のサーバー移行の構成

移行のためのCapture管理対象サーバー名、ホスト名およびクラスタ名を指定します。

第14.8項「WLS_CPT管理対象サーバー用のサーバー移行の構成」

Capture構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第14.9項「インストールのバックアップ」

14.2 WCCHOST1でのVIP6およびWCCHOST2でのVIP7の有効化

Captureシステムは、Captureが実行している管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。これらの仮想ホスト名および対応する仮想IPアドレスは、Captureコンポーネントのサーバー移行を有効にするために必要です。まだ対応していない場合は、VIP6からWCCHOST1のWCCHOST1VHN3に対して、またVIP7からWCCHOST2のWCCHOST2VHN3に対して仮想IPアドレスのマッピングを有効にし、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーまたは/etc/hosts解決のいずれかで)正しく解決する必要があります。

まだ仮想IPアドレスを有効化していない場合には、第6.6項「仮想IPアドレスの有効化」で説明している手順に従ってください。これらの仮想IPアドレスおよび仮想ホスト名は、Captureサーバーでサーバー移行を有効にするときに必要となります。この後、高可用性を実現するために、Captureサーバーのサーバー移行を構成できます。サーバー移行の構成の詳細は、第17章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。

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

第10章「WebCenter Contentを追加するためのドメインの拡張」で構成したドメインを拡張して、Oracle WebCenter Enterprise Captureを追加します。この項の手順は、Oracle WebCenter Contentのデプロイメントと同じデータベース・サービス(wccedg.example.com)をCaptureのデプロイメントでも使用することを前提としています。ただし、Capture専用の別のデータベース・サービスをデプロイメントに使用することもできます。

注意:
これらの手順を実行する前に、Oracle Fusion Middleware管理者ガイドの説明に従ってドメインをバックアップしてください。

Capture用にドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。
Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内のすべての管理対象サーバーを停止します。

3. WCCHOST1で、ディレクトリをFusion Middleware構成ウィザードの場所に変更します。これはOracle共通ホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行します)。

cd ORACLE_COMMON_HOME/common/bin

4. Fusion Middleware構成ウィザードを起動します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. 「WebLogicドメイン・ディレクトリの選択」画面で、WebLogic Serverのドメイン・ディレクトリ(ASERVER_HOME)を選択し、「次へ」をクリックします。
参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

7. 「拡張ソースの選択」画面(図14-1)で、次の選択を行います。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 「Oracle WebCenter Enterprise Capture」を選択します。
次の製品は、ドメインを作成した際(第8.3項)あるいはWebCenter Content用(第10.2項)、Inbound Refinery用(第11.2項)、Oracle SOA Suiteコンポーネント用(第12.3項)またはImaging用(第13.3項)にドメインを拡張した際に選択している場合、グレー表示されます。

- WebLogic Serverの基本ドメイン

- Oracle SOA Suite

- Oracle WebCenter Content: Imagingビューア・キャッシュ

- Oracle WebCenter Content: Imaging

- Oracle Universal Content Management - Inbound Refinery

- Oracle Universal Content Management - Content Server

- Oracle Enterprise ManagerプラグインIBR用

- Oracle Enterprise Manager

- Oracle WSMポリシー・マネージャ

- Oracle JRF

図14-1 Captureの「拡張ソースの選択」画面

「次へ」をクリックします。

8. 図14-2に示す「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. CaptureスキーマおよびCapture MDSスキーマを選択します。他の既存スキーマはいずれも選択しないでください。

2. RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます(付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照)。ここでの説明に合せて、「GridLinkへ変換」を選択します。
RAC構成を選択すると、選択されたすべてのスキーマがグレー表示されます。

図14-2 Captureの「JDBCコンポーネント・スキーマの構成」画面

3. 「次へ」をクリックします。

9. 「GridLink RACコンポーネント・スキーマの構成」画面(図14-3)で、次の手順を実行します。

1. CaptureスキーマおよびCapture MDSスキーマを選択します。その他のデータ・ソースはそのままにします。

図14-3 Captureの「GridLink RACコンポーネント・スキーマの構成」画面

2. 次の各フィールドに値を入力して、RCUでシードされたGridLink RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLinkConnections用ドライバ (Thin) バージョン: 11以上を選択します。

- サービス名: Oracle RACデータベースのサービス名は小文字で入力し、ドメイン名を続けます(例: wccedg.example.com)。

- ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてWCCを使用しています。

- パスワード: データベース・スキーマの所有者のパスワードを入力します。

- 「FANの有効化」を選択します。

- SSLの有効化: このオプションは選択解除したままにします。
SSLを選択してOracle Notification Service (ONS)の通知暗号化を有効にする場合は、「ウォレット・ファイル」および「ウォレット・パスワード」の詳細を適切に指定します。

- サービス・リスナー: 使用するOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。プロトコルはTCPである必要があります。
SCANアドレスを使用してサービス・リスナー(およびOSNホスト)を指定することをお薦めします。これにより、Oracle RACノードを追加または削除しても、SCANアドレスを含むGridLinkデータ・ソースを更新する必要がありません。SCANアドレスを特定するには、データベース内のremote_listenerパラメータを問い合せます。

SQL>show parameter remote_listener;

NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      db-scan.example.com :1521

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベース・インスタンス・リスナーの仮想IPアドレスとポートを使用します。

wccdbhost1-vip.example.com (port 1521)

wccdbhost2-vip.example.com (1521)

- ONSホスト: データベースによって報告されるRACデータベースのSCANアドレスとONSリモート・ポートも入力します。

[orcl@WCCDBHOST1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベースのONSサービスのホスト名とポートを使用します。

wccdbhost1.example.com (port 6200)

wccdbhost2.example.com (6200)

3. 「次へ」をクリックします。

注意:
UCMスキーマの情報は変更しません。

10. 「JDBCコンポーネント・スキーマのテスト」画面で、「CPTスキーマ」行を選択し、「接続のテスト」をクリックします。
結果は「接続結果ログ」に表示されます。スキーマを含むデータベースへの接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正してテストを再試行します。

図14-4 Captureの「JDBCコンポーネント・スキーマのテスト」画面

接続に成功したら、「次へ」をクリックします。

11. 「オプションの構成を選択」画面で、次のオプションを選択します。

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

12. 「JMS分散宛先タイプの選択」画面で、すべてのOracle Fusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストからUDDを選択します。「次へ」をクリックします。オーバーライドの警告が表示された場合、「OK」をクリックして、このメッセージを確認します。

13. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
サーバーが自動的に作成されます。このサーバーの名前をWLS_CPT1に変更し、WLS_CPT2という新しいサーバーを追加します。表14-2に示す属性をこれらのサーバーに指定します。画面に表示されている他のサーバーは変更せず、そのままにしておきます。

表14-2 Captureの管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_CPT1

WCCHOST1VHN3

16400

n/a

いいえ

WLS_CPT2

WCCHOST2VHN3

16400

n/a

いいえ

「次へ」をクリックします。

14. 「クラスタの構成」画面で、「追加」をクリックし、表14-3に示すクラスタを追加します。画面に表示されている他のクラスタは変更せず、そのままにしておきます。

表14-3 Captureのクラスタ構成

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

CPT_Cluster

ユニキャスト

n/a

n/a

空のままにします。

「次へ」をクリックします。

15. 「サーバーのクラスタへの割当」画面で、次の項目を追加します。画面に表示されている他の割当ては変更せず、そのままにしておきます。

- CPT_Cluster:

- WLS_CPT1

- WLS_CPT2

「次へ」をクリックします。

16. 「マシンの構成」画面で、「Unixマシン」タブを開きます。マシンWCCHOST1およびWCCHOST2を確認して、次のように入力します。

表14-4 マシンおよびノード・マネージャのリスニング・アドレス

名前

ノード・マネージャのリスニング・アドレス

WCCHOST1

WCCHOST1

WCCHOST2

WCCHOST2

ADMINHOST

localhost

その他のすべてのフィールドはデフォルト値のままにします。「次へ」をクリックします。

17. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- WLS_CPT1をWCCHOST1に割り当てます。

- WLS_CPT2をWCCHOST2に割り当てます。

「次へ」をクリックします。

18. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のようにターゲット設定されていることを確認します。

- captureデプロイメントは、CPT_Clusterにのみターゲット設定します。

- EMアプリケーションは、AdminServerにのみターゲット設定します。

「次へ」をクリックします。

19. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、図14-5に示すようにCPT_ClusterにデプロイされるすべてのOPSS関連のデータ・ソースを選択します。

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

図14-5 サービスのCaptureクラスタへのターゲット設定

「次へ」をクリックします。

20. 「構成のサマリー」画面で、「拡張」をクリックします。

21. ドメインのポートの競合に関する警告ダイアログ・ボックスが表示された場合、「OK」をクリックします。この警告は、ノードに以前から存在していたサーバーによるもので、無視してかまいません。

22. 「ドメインの作成中」画面で、「完了」をクリックします。

14.4 管理サーバーの再起動

ドメイン拡張の変更を有効にするには、Oracle WebLogic Scripting Tool (WLST)でノード・マネージャのnmKillコマンドとnmStartコマンドを使用して管理サーバーを再起動する必要があります(第10.3項「管理サーバーの再起動」を参照)。管理サーバーを停止する際には、nmKillのかわりに管理コンソールを使用できます。weblogicユーザーの資格証明を使用して管理コンソールにログインします。

14.5 Capture用の構成後タスクおよび検証タスクの実行

次の項では、Capture用の構成後タスクと検証タスクを実行する方法について説明します。

- 第14.5.1項「WLS_CPT管理対象サーバーに対するホスト名検証の無効化」

- 第14.5.2項「WLS_CPT1およびWLS_CPT2へのドメイン構成の伝播」

- 第14.5.3項「Captureの初期構成の実行」

- 第14.5.4項「CaptureのGridLinkデータ・ソースの検証」

- 第14.5.5項「Capture用のJMS永続ストアの構成」

- 第14.5.6項「Oracle WebCenter Contentで許可されたホストのリストに対するCaptureサーバーのリスニング・アドレスの追加」

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

このガイドで説明するエンタープライズ・デプロイメントでは、Captureを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。WLS_CPT1およびWLS_CPT2管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverインスタンスを管理するときにエラーが出ないようにします。詳細は、第8.4.5項「ホスト名検証の無効化」を参照してください。

エンタープライズ・デプロイメントのトポロジ構成が完了したら、ホスト名検証を再び有効化します。詳細は、第16.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

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

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

Capture管理対象サーバーへのドメイン構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。

2. 次のpackコマンドをWCCHOST1で実行し、テンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateCPT.jar -template_name=edgdomain_templateCPT

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

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

参照トポロジで、MSERVER_HOMEは/u02/oracle/config/domains/WCCDomainディレクトリで、APPLICATION_HOMEは/u01/oracle/config/applications/WCCDomainディレクトリです。

注意:

- unpackコマンドはWL_HOME/common/bin/から実行するのではなく、ORACLE_COMMON_HOME/common/bin/ディレクトリから実行してください。

- APPLICATION_HOMEディレクトリは、このunpackコマンドでバックアップされます。

- unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびEARファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびEARファイルをリストアする必要があります。

4. 次のコマンドをWCCHOST1で実行し、手順1で作成したテンプレート・パックをWCCHOST2にコピーします。

scp edgdomaintemplateCPT.jar oracle@WCCHOST2:/u01/oracle/products/fmw_home/oracle_common/bin

5. 次のunpackコマンドをWCCHOST2で実行して、伝播されたテンプレートをWLS_CPT2管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=/u02/oracle/config/domains/WCCDomain -template=edgdomaintemplateCPT.jar -app_dir=/u01/oracle/config/applications/WCCDomain –overwrite_domain=true

注意:

- unpackコマンドはWL_HOME/common/bin/から実行するのではなく、ORACLE_COMMON_HOME/common/bin/ディレクトリから実行してください。

- APPLICATION_HOMEディレクトリは、このunpackコマンドでバックアップされます。

6. ここまでの変更を有効にするために管理サーバーを再起動します。まずnmKillコマンドまたは管理コンソールで管理サーバーを停止し、次にnmStartコマンドで起動します(第10.3項「管理サーバーの再起動」を参照)。
再起動の前に、管理コンソールを使用してドメイン内のすべての管理対象サーバーを停止します。続いて再起動後に、それらの管理対象サーバーを起動します。weblogicユーザーの資格証明を使用して管理コンソールにログインします。

14.5.3 Captureの初期構成の実行

WebLogic ServerドメインでCaptureの初期構成を完了するには、weblogicシステム管理者を使用して次のタスクを行います。

1. Capture管理対象サーバーを起動します。

2. Fusion Middleware Controlを使用してキャプチャ・ユーザーにロールを割り当てます。

3. MBeanを使用してシステム・レベルの設定を変更します。

14.5.3.1 Captureの初期構成の実行について

インストールおよび初期構成を実行するシステム管理者は、Oracle Enterprise Manager Fusion Middleware ControlやOracle WebLogic Serverへのアクセス権などのシステム管理権限を保有している必要があります。Oracle WebCenter Enterprise Captureを使用する前に、システム管理者はWebLogic ServerのLDAPアイデンティティ・ストアのユーザーをFusion Middleware Controlのキャプチャ・ロールに関連付ける必要があります。

グループとユーザーを保存するために、Oracle Internet Directoryポリシー・ストアを使用できます。ポリシー・ストアはFusion Middleware Controlから管理できます。

次のキャプチャ・ロールをユーザーに割り当てることができます。

- キャプチャ・ワークスペース・マネージャ(CaptureWorkspaceManager)

- キャプチャ・ワークスペース参照者(CaptureWorkspaceViewer)

- キャプチャ・ユーザー(CaptureUser)

システム管理者はCaptureWorkspaceManagerロールとCaptureUserロールの両方にワークスペース・マネージャを割り当てて、ワークスペース・コンソールとクライアントにアクセスできるようにする必要があります。CaptureUserロールのメンバーのみがCaptureクライアントを使用できます。アカウントにCaptureWorkspaceManagerロールが付与されると、そのアカウントでワークスペース・コンソールへのサインイン、ワークスペースの作成、およびキャプチャ・ロールを割り当てられている他のユーザーへのキャプチャ・アクセス権の付与が可能になります。

Capture管理対象サーバーの起動後、システム管理者はFusion Middleware ControlまたはOracle WebLogic Scripting Tool (WLST)のコマンドを使用して、Capture MBeanのシステム・レベルの設定を変更できます。

14.5.3.2 Capture管理対象サーバーの起動

WCCHOST1よびWCCHOST2でCapture管理対象サーバーを起動します。

Capture管理対象サーバーを起動する手順は次のとおりです。

1. 管理対象サーバーWLS_CPT1を起動します。

1. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにログインします。

2. 左側の「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。

3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

4. 表の「サーバー」列から「WLS_CPT1」を選択します。

5. 「起動」をクリックします。

2. http://WCCHOST1VHN3:16400/dc-consoleにアクセスしてWLS_CPT1のステータスを確認します。「Oracle WebCenter Enterprise Captureワークスペース・コンソール」ログイン・ページが開きます。WebLogic Server管理のユーザー名とパスワードを入力し、ログインします。

3. 管理対象サーバーWLS_CPT2を起動します。

1. http://ADMINVHN:7001/consoleで
WebLogic Server管理コンソールにログインします。

2. 左側の「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。

3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

4. 表の「サーバー」列から「WLS_CPT2」を選択します。

5. 「起動」をクリックします。

4. http://WCCHOST2VHN3:16400/dc-consoleにアクセスしてWLS_CPT2のステータスを確認します。「Oracle WebCenter Enterprise Captureワークスペース・コンソール」ログイン・ページが開きます。WebLogic Server管理のユーザー名とパスワードを入力し、ログインします。

14.5.3.3 キャプチャ・ユーザーへのロールの割当て

Captureを使用するには、システム管理者(weblogic)がLDAP資格証明ストアのユーザーをポリシー・ストアのキャプチャ・ロールに関連付ける必要があります。Fusion Middleware Controlの「アプリケーション・ロール」ページでこれを実行できます。

キャプチャ・ロールをワークスペース・マネージャに割り当てる手順は次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 左側で、「WebLogicドメイン」を開きます。

3. ドメイン名を右クリックして、「セキュリティ」→「アプリケーション・ロール」の順に選択します。
「アプリケーション・ロール」ページが開きます。

図14-6 Captureのアプリケーション・ロール

4. 「アプリケーション・ストライプ」フィールドで、ドロップダウン・リストから「capture」を選択し、検索アイコンをクリックします。
検索を実行すると、「キャプチャ・ユーザー」、「キャプチャ・ワークスペース・マネージャ」および「キャプチャ・ワークスペース参照者」のロールが表に移入されます。

5. CaptureWorkspaceManagerロールを編集します。

6. このロールにユーザーを追加します。

7. CaptureUserロールを編集します。

8. CaptureWorkspaceManagerロールとCaptureUserロールの両方がユーザーに付与されるように、このロールにも同じユーザーを追加します。

キャプチャ・ユーザーにロールを割り当てる方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Captureの管理』のOracle Enterprise Managerによるキャプチャ・ロールの割当てに関する項を参照してください。

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

Fusion Middleware Controlの「システム構成」ページを使用して、Captureのシステム・レベルの構成設定(システム・プロパティや電子メールのSMTP設定など)を変更できます。このページの設定ではドメインのCapture MBeanを構成します。この設定はWLSTコマンドで変更することもできます。

システム・レベルの設定をFusion Middleware Controlで変更する方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Captureの管理』のシステム構成設定の変更に関する項を参照してください。

次のWLSTコマンドを使用しても、システム・レベルの設定にアクセスしたり、システム・レベルの設定を変更したりできます。

- listCaptureConfig

- getCaptureConfig

- setCaptureConfig

これらのコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のOracle WebCenter Enterprise CaptureのカスタムWLSTコマンドに関する項を参照してください。

14.5.4 CaptureのGridLinkデータ・ソースの検証

サーバーを起動したら、GridLinkデータ・ソースが正しく構成され、ONS設定が正しいことを確認します。作成されたすべてのGridLinkデータ・ソースに対して、この手順を実行します。

CaptureのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. 作成したGridLinkデータ・ソースの名前をクリックします。

4. 「監視」タブをクリックします。

5. 「テスト」タブ(図15-7)をクリックし、いずれかのサーバーを選択し、「データ・ソースのテスト」をクリックします。

図14-7 CaptureのGridLinkデータ・ソースのテスト

構成が適切であればテストは成功します。

6. GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスでテストを繰り返します。

CaptureのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。

1. 管理コンソールの「ドメイン構造」ツリーで、「サービス」ノードを開いて「データ・ソース」をクリックします。

2. GridLinkデータ・ソースの名前をクリックします。

3. 「監視」タブをクリックします。

4. サーバーの名前(WLS_CPT1)をクリックします。

5. 「ONS」タブをクリックし、「テスト」タブ(図14-8)をクリックします。

6. サーバーを選択し、「ONSのテスト」をクリックします。

図14-8 Captureの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テストを繰り返します。

14.5.5 Capture用のJMS永続ストアの構成

2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Oracle WebCenter Enterprise Captureで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(デフォルト/u02/oracle/config/domains/WCCDomain/servers/server_name/data/store/)を使用しています。共有ベースのディレクトリを使用するように、各Capture JMSサーバーの永続ストアを変更する必要があります。

Capture用のJMS永続ストアを構成する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。

3. 「永続ストアのサマリー」ページで「ロックして編集」をクリックします。

4. 「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。

5. 名前(例: CPTJMSServer1Store。これにより、作成対象のサービスを特定できます)およびターゲットのWLS_CPT1を入力します。WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを入力します(/u01/oracle/config/domains/WCCDomain/CPT_Cluster/jms)。

6. 「OK」をクリックして、変更をアクティブ化します。

7. 左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」→「JMSサーバー」ノードをクリックします。

8. 「JMSサーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)JMSサーバー「CaptureJmsServer1」をクリックします。

9. このJMSサーバーの「設定」ページで、「ロックして編集」をクリックしてください。

10. 「永続ストア」ドロップダウン・リストで、「CPTJMSServer1Store」を選択します。

11. 「保存してアクティブ化」をクリックします。

12. 手順を繰り返して、CaptureJMSServer2のCPTJMSServer2Storeを作成します。

14.5.6 Oracle WebCenter Contentで許可されたホストのリストに対するCaptureサーバーのリスニング・アドレスの追加

第13.5.11項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」でOracle WebCenter Content Server用に構成した許容ホストの設定は、この設定にCapture管理対象サーバーのリスナーを追加すればCaptureにも適用できます。コンテンツ・サーバーの許容ホストを初めて追加する場合(Imaging以外のOracle WebCenter Contentエンタープライズ・デプロイメントを設定する場合)は、コンテンツ・サーバーから次の構成を行う必要があります。

WLS_CPT1およびWLS_CPT2管理対象サーバー(それぞれWCCHOST1VHN3およびWCCHOST2VHN3)のホスト名をSocketHostNameSecurityFilterパラメータ・リストに追加します。

Oracle WebCenter Contentで許可されているホストにCaptureサーバーのリスニング・アドレスを追加する手順は次のとおりです。

1. テキスト・エディタでファイル/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgを開きます。

2. 次の行を削除またはコメント・アウトします。

SocketHostAddressSecurityFilter=127.0.0.1|WCCHOST1-IP|WCCHOST2-IP|WEBHOST1-IP|WEBHOST2-IP

3. Oracle WebCenter Contentへの接続を許可するアドレスのリストにWLS_CPT1およびWLS_CPT2のリスニング・アドレスを含めるために、次の2行を追加します。

SocketHostNameSecurityFilter=localhost|localhost.example.com|WEBHOST1|
WEBHOST2|WCCHOST1|WCCHOST2|WCCHOST1VHN1|WCCHOST2VHN1|WCCHOST1VHN2|WCCHOST2VHN2|
WCCHOST1VHN3|WCCHOST2VHN3|ucminternal.example.com|load-balancer-host-name
AlwaysReverseLookupForHost=Yes

注意:
ロード・バランサのホスト名は、第3.3項「ロード・バランサ」の仮想サーバーの構成で使用したホスト名です。

4. 変更されたconfig.cfgファイルを保存したら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

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

WLS_CPT1およびWLS_CPT2管理対象サーバーを含むCPT_ClusterにOracle HTTP Serverをルーティングするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

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

- 第14.6.1項「WLS_CPT管理対象サーバー用のOracle HTTP Serverの構成」

- 第14.6.2項「フロントエンドHTTPホストおよびポートの設定」

- 第14.6.3項「ロード・バランサを介したアクセスの検証」

14.6.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 WCCHOST1VHN3:16400,WCCHOST2VHN3:16400
SetHandler weblogic-handler
WLCookieName JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# DC-Client
<Location /dc-client>
WebLogicCluster WCCHOST1VHN3:16400,WCCHOST2VHN3:16400
SetHandler weblogic-handler
WLCookieName JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

参照トポロジで、ORACLE_INSTANCEは/u02/oracle/config/web1または/u02/oracle/config/web2ディレクトリです。

2. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

/u02/oracle/config/webN/bin/opmnctl restartproc ias-component=ohsX

ias-componentに対して、WEBHOST1ではohs1を使用し、WEBHOST2ではohs2を使用します。

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

Captureクラスタ(CPT_Cluster)について、フロントエンドHTTPのホストとポートを設定する必要があります。

CaptureクラスタのフロントエンドHTTPホストとポートを設定する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「チェンジ・センター」セクションに移動して、「ロックして編集」をクリックします。

3. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

4. 「クラスタ」をクリックします。

5. 「クラスタのサマリー」ページで、「CPT_Cluster」を選択します。

6. 「HTTP」タブを開きます。

7. 次の値を設定します。

- フロントエンド・ホスト: wcc.example.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80

8. 「保存」をクリックします。

9. 管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

10. サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効にします。

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

URLを検証し、HTTP ServerからCPT_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

URLを検証する手順は次のとおりです。

1. WLS_CPT2が稼動している状態で、WebLogic Server管理コンソールからWLS_CPT1を停止します。

2. http://wcc.example.com/dc-consoleにアクセスし、正しく動作していることを確認します。(Captureサーバーが停止しているため、レポートやデータは取得できません。)

3. WebLogic Server管理コンソールからWLS_CPT1を起動します。

4. WebLogic Server管理コンソールでWLS_CPT2を停止します。

5. http://wcc.example.com/dc-consoleにアクセスし、正しく動作していることを確認します。

6. WebLogic Server管理コンソールからWLS_CPT2を起動します。

14.7 WLS_CPT管理対象サーバーのノード・マネージャの構成

ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第16章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照してください。その章の手順をOracle WebCenter Contentデプロイメントで実行する必要があります。

第16.3項「ノード・マネージャでのホスト名検証証明書の有効化」の手順は、次の表のホストとCapture管理対象サーバーに対して実行する必要があります。

ホスト名(HOST)

仮想IPアドレス(VIP)

サーバー名(WLS_SERVER)

WCCHOST1

WCCHOST1VHN3

WLS_CPT1

WCCHOST2

WCCHOST2VHN3

WLS_CPT2

Capture管理対象サーバーをサーバー移行するには、それらのサーバーを指定の仮想ホスト名に関連付ける必要があります。これらの仮想ホスト名がDNSまたはシステム内の/etc/hosts解決で有効になっていることおよびそれらが適切な仮想IPアドレスにマップされていることを確認します。詳細は、第3.4項「IPアドレスおよび仮想IPアドレス」を参照してください。

14.8 WLS_CPT管理対象サーバー用のサーバー移行の構成

サーバー移行は、WCCHOST1ノードとWCCHOST2ノードのどちらかで障害が発生した場合に、Oracle WebCenter Enterprise Captureのコンポーネントを正しくフェイルオーバーするために必要です。詳細は、第17章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。Captureに関しては、その章で次の変数の値を使用します。

- サーバー名:

- WLS_SERVER1: WLS_CPT1

- WLS_SERVER2: WLS_CPT2

- ホスト名:

- HOST1: WCCHOST1

- HOST2: WCCHOST2

- クラスタ名:

- CLUSTER: CPT_Cluster

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

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップの詳細は、Oracle Databaseバックアップおよびリカバリ・ガイドを参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

1. WEBHOST1でOracle Web層をバックアップします。

1. opmnctlを使用してインスタンスを停止します。

/u02/oracle/config/webN/bin/opmnctl stopall

2. 次のコマンドをrootとして実行して、Oracle Web層のMiddlewareホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドを実行して、Oracle Web層のOracleインスタンスをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

cd /u02/oracle/config/webN/bin

opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。

3. ドメイン構成を保存するために、管理サーバーと管理対象サーバーのドメイン・ディレクトリをバックアップします。構成ファイルはすべて/u01/oracle/config/domains/WCCDomainディレクトリに存在しています。WCCHOST1で次のコマンドを実行して、バックアップを作成します。

tar -cvpf edgdomainback.tar /u01/oracle/config/domains/WCCDomain

15 WebCenter Contentユーザー・インタフェースのインストールおよび構成

この章では、Oracle WebCenter Content管理対象サーバーとWebCenter Contentユーザー・インタフェースをインストールおよび構成する方法について説明します。Oracle WebCenter Content Server用のこのインタフェースは、Oracle Application Development Framework (Oracle ADF)に基づいています。

この章では、次の項目について説明します。

- 第15.1項「WebCenter Contentユーザー・インタフェースのインストールおよび構成について」

- 第15.2項「WebCenter Contentユーザー・インタフェースのインストールおよび構成の準備」

- 第15.3項「11.1.1.6.0 MiddlewareホームとOracle ADF 11.1.2のインストール」

- 第15.4項「WebCenter Contentユーザー・インタフェース・アプリケーションのインストール」

- 第15.5項「WebCenter Contentユーザー・インタフェース・アプリケーションの新しいドメインへのデプロイ」

- 第15.6項「管理者ユーザーの構成」

- 第15.7項「WebCenter Contentユーザー・インタフェースへのアクセス」

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

- 第15.9項「ワークフロー構成の完了」

15.1 WebCenter Contentユーザー・インタフェースのインストールおよび構成について

コンテンツ・サーバーがデフォルトで使用するネイティブの11gユーザー・インタフェース以外にも、WebCenter Contentユーザー・インタフェースを使用してコンテンツ・サーバーを構成できます。WebCenter Contentユーザー・インタフェースは、コンテンツ・サーバーとは別のドメインに存在し、異なるポート(デフォルトでは16225)で実行されます。

この別ドメインには、独自のMiddlewareホームが必要ですが、これはコンテンツ・サーバー用のMiddlewareホームと同一のマシンまたは別のマシンに存在していてもかまいません。WebCenter Contentユーザー・インタフェース・サーバーの複数インスタンスが同じOracle WebCenter Content Server (旧称Oracle UCM Content Server)と動作するように選択できます。

WebCenter Contentユーザー・インタフェースのドメイン・トポロジの図は、図1-2を参照してください。

この章では、次の用語を使用します。

- 最初のMiddlewareホームは、Oracle WebCenter Contentを含み、Oracle WebCenter Content Middlewareホーム(ディレクトリ・パスではMW_HOME)と呼ばれます。

- 最初のドメインは、WebCenter Contentを含み、Oracle WebCenter Contentドメイン(WCCDomain)と呼ばれます。このドメインは、Oracle WebCenter Content Middlewareホームと関連付けられています。

- 2番目のMiddlewareホームは、WebCenter Contentユーザー・インタフェースを含み、WebCenter Contentユーザー・インタフェースMiddlewareホーム(ディレクトリ・パスではWCCUI_MW_HOME)と呼ばれます。

- 2番目のドメインは、WebCenter Contentユーザー・インタフェースを含み、WebCenter Contentユーザー・インタフェース・ドメイン(WCCUIDomain)と呼ばれます。このドメインは、WebCenter Contentユーザー・インタフェースMiddlewareホームと関連付けられています。

WebCenter Contentユーザー・インタフェースに必要となるOracle ADFスタックに変更を加えるため、WebCenter Contentユーザー・インタフェース・ドメインには、独自のMiddlewareホームが必要です。

2つのMiddlewareホームおよびドメインは、同じホストまたは別のホスト上に存在できます。同じホスト上で両方のドメインを実行するには、各ドメインに異なる管理サーバー・ポートを使用することが唯一必要となります。

WebCenter Contentユーザー・インタフェースをインストールし、これをコンテンツ・サーバー用に構成するには、次の項で説明するタスクを実行する必要があります。

15.2 WebCenter Contentユーザー・インタフェースのインストールおよび構成の準備

WebCenter Contentユーザー・インタフェースをインストールおよび構成する前に、前述の章の説明に従って、Oracle WebCenter Content 11gR1、およびオプションでInbound Refineryをインストールおよび構成する必要があります。

この項のすべての操作はOracle WebCenter Content Middlewareホームに関連しているため、Oracle WebCenter Contentドメイン(WCCDomain)にも関連しています。

Oracle WebCenter Content Serverを次のように構成します。

- 第15.2.1項「WebCenter Contentユーザー・インタフェース・コンポーネントの有効化」
この構成は、WebCenter Contentユーザー・インタフェースを使用する場合に必要です。

- 第15.2.2項「Remote Intradoc Client (RIDC)の設定」
この構成は、WebCenter Contentユーザー・インタフェースを使用する場合に必要です。

- 第15.2.3項「追加のコンテンツ・サーバーのパラメータの設定」
この構成は、追加の構成変数およびコンテンツ・サーバー用の検索エンジンを設定するためのオプションです。

- 第15.2.4項「フルテキスト検索の有効化」
この構成は、Oracle Text Searchを設定するためのオプションです。

- 第15.2.5項「画像およびWeb表示可能レンディションの生成」
この構成は、WebCenter Contentユーザー・インタフェースの操作性を向上させるためのオプションです。

- 第15.2.6項「コンテンツ・サーバーでの拡張機能の構成」
この構成は、標準的なコンテンツ・サーバー機能を設定するためのオプションです。

- 第15.8.1項「WLS_WCCUI管理対象サーバー用のOracle HTTP Serverの構成」
この構成は、Oracle HTTP Serverの設定に必要です。

- 第15.8.2項「ロード・バランサを介したアクセスの検証」
この検証は、以前の構成のテストに必要です。

15.2.1 WebCenter Contentユーザー・インタフェース・コンポーネントの有効化

WebCenter Contentユーザー・インタフェースを使用できるようにするには、これらのコンテンツ・サーバー・コンポーネント(AutoSuggestConfig、DynamicConverterおよびFrameworkFolders)を有効にする必要があります。これらを有効化するには、コンテンツ・サーバー・コンポーネント・マネージャ・インタフェースを使用して、次の手順を実行します。

1. コンテンツ・サーバーにWebCenter Content管理者としてログインします。

2. 「管理」トレイまたはメニューから、「管理サーバー」→「コンポーネント・マネージャ」を選択します。

3. 「コンポーネント・マネージャ」ページで、「すべてのコンポーネント」の下の3つのコンポーネントすべてを選択します。

- AutoSuggestConfig

- DynamicConverter

- FrameworkFolders

4. 「更新」をクリックして「OK」をクリックし、コンポーネントの有効化を確定します。

5. WebLogic Server管理コンソールを使用して、WebCenter Contentの管理対象サーバー(WLS_WCC1およびWLS_WCC2)を再起動します(停止後、起動)。

15.2.2 Remote Intradoc Client (RIDC)の設定

WebCenter Contentユーザー・インタフェースは、IDCソケット・プロトコルを使用してコンテンツ・サーバーと通信します。この通信を有効にするには、Oracle WebCenter Contentドメインで、コンテンツ・サーバーのASERVER_HOME/WCC_Cluster/cs/config/config.cfg構成ファイルのIntradocServerPortおよびSocketHostAddressSecurityFilter値を設定する必要があります。

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

次の構文にこれらの値の設定方法を示します。

IntradocServerPort=port_number
SocketHostAddressSecurityFilter=IP addresses of permitted UI hosts separated by a bar symbol (|)
AlwaysReverseLookupForHost=Yes

次に例を示します。

IntradocServerPort=4444
SocketHostNameSecurityFilter=localhost|localhost.example.com|WEBHOST1|WEBHOST2|
WCCHOST1|WCCHOST2||WCCUIHOST1|WCCUIHOST2|ucminternal.example.com|
load-balancer-host-name
AlwaysReverseLookupForHost=Yes

config.cfgファイルの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』のconfigディレクトリに関する項を参照してください。

15.2.3 追加のコンテンツ・サーバーのパラメータの設定

WebCenter Contentユーザー・インタフェースのフォルダおよび検索用に、コンテンツ・サーバーのパラメータも設定できます。

追加のコンテンツ・サーバーのパラメータを設定する手順は次のとおりです。

1. コンテンツ・サーバーの「管理」メニューまたはトレイから、「管理サーバー」→「一般構成」を選択します。

2. 「アカウントの有効化」チェック・ボックスを選択します。

3. 「追加の構成変数」領域で、次のパラメータ(まだ設定されていない場合)を追加して、Iconfig.cfgファイルに移動します。

- FoldersIndexParentFolderValues=true
このパラメータを使用すると、サブフォルダも含め、フォルダ内のコンテンツを検索できるようなります。

- FldEnforceFolderFileNameUniqueness=true
このパラメータにより、フォルダに子ドキュメントと同じ名前の子フォルダを作成できなくなります。

- FldEnforceCaseInsensitiveNameUniqueness=true
このパラメータにより、フォルダ名とファイル名の一意性チェックでの大/小文字の区別を解除します。パス解決での大/小文字の区別も解除します。

- SearchIndexerEngineName=OracleTextSearchまたはSearchIndexerEngineName=DATABASE.METADATA
このパラメータを使用すると、デフォルトのデータベースのフルテキスト検索のかわりに、OracleTextSearchフルテキスト検索またはデータベース・メタデータ検索が有効になります。

4. WLS_WCC管理対象サーバーを再起動します。

15.2.4 フルテキスト検索の有効化

フルテキスト検索の場合、OracleTextSearch (SearchIndexerEngineName=ORACLETEXTSEARCHパラメータ)を使用して、コンテンツ・サーバーの索引を再構築する必要があります。

WebCenter Contentユーザー・インタフェースでフルテキスト検索を有効にする手順は次のとおりです。

1. ネイティブ・ユーザー・インタフェースでコンテンツ・サーバーにアクセスします。

http://WCCHOST1:16200/cs

2. 「管理」メニューまたはトレイから、「管理アプレット」→「リポジトリ・マネージャ」を選択します。

3. 「索引作成」タブをクリックします。

4. 「コレクション再構築サイクル」で、「起動」ボタンをクリックします。

5. 「高速再構築の使用」を選択解除します。

6. 「OK」ボタンをクリックします。

15.2.5 サムネイルおよびWeb表示可能レンディションの生成

WebCenter Contentユーザー・インタフェースからファイルのサムネイル画像およびWeb表示可能レンディションを取得するには、Inbound Refineryでそれらが提供されるように構成します。ネイティブの11gユーザー・インタフェースを使用して、サムネイルおよびPDF Exportなどのファイル変換のためにInbound Refineryプロバイダを設定できます。

コンテンツ・サーバーでサムネイルを構成する手順は次のとおりです。

1. ネイティブ・ユーザー・インタフェースでコンテンツ・サーバーにアクセスします。

http://WCCHOST1:16200/cs

2. 「管理」メニューまたはトレイから、「サムネイル・オプションの構成」を選択します。

3. 「このサーバーを有効にする」を選択して、サムネイル・イメージ・ボックスを作成します。

4. 「更新」ボタンをクリックします。

サムネイルおよびWeb表示可能レンディションの生成の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のInbound Refineryの構成に関する項を参照してください。

15.2.6 コンテンツ・サーバーでの拡張機能の構成

一部のコンテンツ・サーバー機能はサポートされていますが、WebCenter Contentユーザー・インタフェースでは必ずしも必要ありません。たとえば、アクセス制御リスト(ACL)およびアカウントは、デフォルトでは構成されていません。ただし、これらの機能がコンテンツ・サーバーで有効化されている場合、WebCenter Contentユーザー・インタフェースは追加機能へのアクセスを提供します。

コンテンツ・サーバーでのACLの有効化の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のアクセス制御リストのセキュリティの管理に関する項を参照してください。

コンテンツ・サーバーでのアカウントの有効化の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のアカウントの管理に関する項を参照してください。

これらの標準的なコンテンツ・サーバー設定は、WebCenter Contentユーザー・インタフェースに固有なものではありません。コンテンツ・サーバーのその他の拡張機能の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』を参照してください。

15.3 11.1.1.6.0 MiddlewareホームとOracle ADF 11.1.2のインストール

Oracle Application Development Framework (Oracle ADF) 11gR1 (11.1.2)を11gR1 (11.1.1.6.0) MiddlewareホームにOracle WebLogic Serverとともにインストールします。これには、Middlewareホームを作成後、続いてOracle ADFおよび2つのOracle ADF OPatchファイルをインストールするためのOracle WebLogic Server 11gR1 (10.3.6のみ)が含まれます。サイトで、WebCenter Contentユーザー・インタフェースを使用してOracle WebCenter Content: Desktopを使用する場合、Desktop 11.1.1.9での互換性モードをサポートするパッチもインストールする必要があります。

注意:
次の手順に従って、Content Server 11.1.1.9用のWebCenter Contentユーザー・インタフェースを有効にする必要があります。Oracle Application Development Framework 11gR1 (11.1.2)が使用可能であっても、これをWebCenter Content ユーザー・インタフェース11.1.1.6.0ドメイン用に使用できません。かわりに、次の手順に従って、Oracle ADF 11.1.1.6.0をインストールして、パッチでこれをOracle ADF 11.1.2.4.0にアップグレードします。

この項のすべての操作は、WebCenter Contentユーザー・インタフェースMiddlewareホームに関連しているため、WebCenter Contentインタフェース・ドメインにも関連しています。次のコマンドで、WCCUI_MW_HOMEは、Oracle ADFインストールを含むWebCenter Contentユーザー・インタフェースMiddlewareホームを指します。

WebCenter Contentユーザー・インタフェース・ドメインの場合、WCCUIHOST1とWCCUIHOST2の両方のホストで次の手順を実行します。

1. Oracle WebLogic Server 11gR1 (10.3.6)をインストールして、Middlewareホームを作成します。これが、WebCenter Contentユーザー・インタフェースMiddlewareホーム(WCCUI_MW_HOME)になります。
参照トポロジで、WCCUI_MW_HOMEは/u01/oracle/products/fmw_homeディレクトリです。

2. WCCUI_MW_HOMEにOracle Application Development Framework 11gR1 (11.1.1.6.0)をインストールします。

1. 『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』のOracle WebCenter Contentのインストールおよび構成のためのソフトウェア・ダウンロードに関する項の説明に従って、Oracle Application Development Framework 11gR1 (11.1.1.6.0)メディアを入手します。

2. Oracle ADFを含むZIPファイルを一時的な場所media_locに解凍します。

3. 次のコマンドを使用してインストーラを実行します。

media_loc/Disk1/runInstaller -jreLoc WCCUI_MW_HOME/jrockit_160_24_D1.1.2-4

3. https://support.oracle.comにアクセスし、My Oracle Support (旧称OracleMetaLink)からOracle Application Development Framework 11gR1 (11.1.2.4.0) OPatch 16546129 - (p16546129_111160_Generic.zip)を入手します。

4. パッチZIPファイルを一時的なフォルダtemp_locationに解凍し、次のコマンドを実行します。

WCCUI_MW_HOME/oracle_common/OPatch/opatch apply -jre WCCUI_JAVA_HOME/jre -oh WCCUI_MW_HOME/oracle_common/ temp_location/16546129

参照トポロジで、WCCUI_JAVA_HOMEは/u01/oracle/products/fmw_home/jrockit_160_24_D1.1.2-4ディレクトリ(JDKの場所)です。

5. https://support.oracle.comから、Oracle Application Development Framework 11gR1 (11.1.2) OPatch 16546157 (p16546157_111160_generic.zip)を入手します。

6. パッチZIPファイルを一時的なフォルダtemp_locationに解凍し、次のコマンドを実行します。

WCCUI_MW_HOME/oracle_common/OPatch/opatch apply -jre WCCUI_JAVA_HOME/jre -oh WCCUI_MW_HOME/oracle_common/ temp_location/16546157

7. (オプション) WebCenter Contentユーザー・インタフェースをMDSカスタマイズする場合は、https://support.oracle.comから、パッチ番号16020846、バージョン11.1.2.4.0 (p16020846_111240_Generic.zip)を入手します。

8. (オプション) パッチZIPファイルを一時フォルダtemp_locationに解凍し、次のコマンドを実行します。

WCCUI_MW_HOME/oracle_common/OPatch/opatch apply -jre WCCUI_JAVA_HOME/jre -oh WCCUI_MW_HOME/oracle_common/ temp_location/16020846

9. (オプション) Internet Explorer 11レンディションには、https://support.oracle.comから、パッチ番号19469801、バージョン11.1.2.4.0 (p19469801_111240_Generic.zip)を入手します。

10. (オプション) パッチZIPファイルを一時フォルダtemp_locationに解凍し、次のコマンドを実行します。

WCCUI_MW_HOME/oracle_common/OPatch/opatch apply -jre WCCUI_JAVA_HOME/jre -oh WCCUI_MW_HOME/oracle_common/ temp_location/19469801

11. (オプション)Oracle ADFヘルプには、https://support.oracle.comから、パッチ番号18102108、バージョン11.1.2.4.0 (p18102108_111240_Generic.zip)を入手します。

12. (オプション) パッチZIPファイルを一時フォルダtemp_locationに解凍し、次のコマンドを実行します。

WCCUI_MW_HOME/oracle_common/OPatch/opatch apply -jre WCCUI_JAVA_HOME/jre -oh WCCUI_MW_HOME/oracle_common/ temp_location/18102108

15.4 WebCenter Contentユーザー・インタフェース・アプリケーションのインストール

WebCenter Contentユーザー・インタフェース・アプリケーションをWCCHOST1およびWCCHOST2にインストールする必要があります。WebCenter Contentユーザー・インタフェース・アーティファクトは、Oracle WebCenter Content (最初)のMiddlewareホームのWebCenter Content Oracleホームから入手できるWccADFUI.zipというZIPファイル内にあります。ファイルの場所は、WCC_ORACLE_HOME/ucm/Distribution/WccADFUI/WccADFUI.zipです。

参照トポロジで、WCC_ORACLE_HOMEはWCCHOST1またはWCCHOST2上の/u01/oracle/products/fmw_home/wcc_homeディレクトリです。

WccADFUI.zipファイルには、次のWebCenter Contentユーザー・インタフェース・アーティファクトが含まれています。

- アプリケーションEARファイル, WccAdf.ear

- ドメイン拡張の構成テンプレート

- Oracle WebCenter Content Serverへの接続を管理するためのカスタムOracle Weblogicスクリプティング・ツール(WLST)コマンド

- アプリケーションのデプロイおよび管理をサポートするスクリプト

WebCenter Contentユーザー・インタフェース・アプリケーションをインストールするには、次の手順をWCCHOST1およびWCCHOST2で実行します。

1. WebCenter Contentユーザー・インタフェース(2番目の)Middlewareホームに、ディレクトリWCCUI_MW_HOME/oracle_common/webcenter/wccadfを作成します。
参照トポロジで、WCCUI_MW_HOMEはWCCUIHOST1またはWCCUIHOST2上の/u01/oracle/products/fmw_homeディレクトリです。

2. WCC_ORACLE_HOME/ucm/Distribution/WccADFUI/WccADFUI.zipファイルをWCCUI_MW_HOME/oracle_common/webcenter/wccadfディレクトリにコピーします。

3. WCCUI_MW_HOME/oracle_common/webcenter/wccadfディレクトリでZIPファイルを展開します。

15.5 WebCenter Contentユーザー・インタフェース・アプリケーションの新しいドメインへのデプロイ

WebCenter Contentユーザー・インタフェース・アプリケーションをWCCUIHOST1上の新しいWebLogic Serverドメインにデプロイし、ドメイン構成をWCCUIHOST2にコピーする必要があります。その後、Oracle WebCenter Contentドメインでコンテンツ・サーバー・アプリケーションとともにこのアプリケーションを使用できるようになります。両方のドメインの構成の完了後、WebCenter Contentユーザー・インタフェースまたはネイティブ11gのユーザー・インタフェースのいずれかをコンテンツ・サーバーとともに使用できます。

注意:
この項のすべての操作は、WebCenter Contentユーザー・インタフェースMiddlewareホームに関連しているため、WebCenter Contentインタフェース・ドメインにも関連しています。

WebCenter Contentユーザー・インタフェース・アプリケーションを新しいドメインにデプロイするには、次のタスクを実行する必要があります。

1. MDSリポジトリの登録

2. WCCUIHOST1での構成ウィザードを使用したドメインの作成

3. ドメインでの構成後タスクおよび検証タスクの実行

4. WCCUI管理対象サーバーのMDSへの登録およびメタデータ・パーティションの作成

5. WLS_WCCUI1およびWLS_WCCUI2へのドメイン構成の伝播

6. WebCenter Contentユーザー・インタフェースとコンテンツ・サーバーの関連付け

15.5.1 MDSリポジトリの登録

Oracle Metadata Services (MDS)リポジトリをWebCenter Contentユーザー・インタフェース・アプリケーションに登録するには、次の手順をWCCHOST1で実行します。

1. WebCenter Contentユーザー・インタフェースMiddlewareホームからWLSTを実行します。

WCCUI_MW_HOME/oracle_common/common/bin/wlst.sh

参照トポロジで、WCCUI_MW_HOMEは/u01/oracle/products/fmw_homeディレクトリです。

2. 次のコマンドをオフライン・モードで実行します。

wls:/offline> archive = getMDSArchiveConfig('WCCADF_EAR_LOCATION')

wls:/offline> archive.setAppMetadataRepository(repository='mds-mds_repo_name', partition='partition_name', type='DB', jndi='jdbc/mds/mds_repo_name')

wls:/offline> archive.save()

getMDSArchiveConfigコマンドでは、WCCADF_EAR_LOCATIONはWccADFUI.zipファイルが展開されたディレクトリで、参照トポロジではWCCUI_MW_HOME/oracle_common/webcenter/wccadfです。

archive.setAppMetadataRepositoryコマンドのmds_repo_nameは、リポジトリの名前で、partition_nameは、作成するパーティションの名前です。

次に例を示します。

archive =
getMDSArchiveConfig('/u01/oracle/products/fmwhome/ADFMW/oracle_common/webcenter/wccadf/WccAdf.ear')
archive.setAppMetadataRepository(repository='mds-WCCUIMDSREPO', partition='MDS_PARTITION', type='DB', jndi='jdbc/mds/WCCUIMDSREPO')
archive.save()

15.5.2 WCCUIHOST1での構成ウィザードを使用したドメインの作成

WCCUIHOST1でFusion Middleware構成ウィザードを実行してドメインを作成する手順は次のとおりです。

1. WebCenter Contentユーザー・インタフェースMiddlewareホームで、WebCenter Contentユーザー・インタフェース・ドメイン・テンプレートoracle.ucm.cs_adf_template_11.1.1.jarをWCCUI_MW_HOME/oracle_common/webcenter/wccadfディレクトリから次のディレクトリにコピーします。

WCCUI_MW_HOME/oracle_common/common/templates/applications

参照トポロジで、WCCUI_MW_HOMEは/u01/oracle/products/fmw_homeディレクトリです。

2. 次のように、WebCenter Contentユーザー・インタフェースのMiddlewareホームで構成ウィザードを実行します。

WCCUI_MW_HOME/oracle_common/common/bin/config.sh

3. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

4. 「ドメイン・ソースの選択」画面が開きます(図15-1)。

図15-1 WebCenter Contentユーザー・インタフェースの「ドメイン・ソースの選択」

「ドメイン・ソースの選択」画面で、次の手順を実行します。

1. 「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

2. 次の製品を選択します。

- 基本WebLogic Serverドメイン(自動的に選択されます)

- Oracle WebCenter Content - Web UI

- Oracle Enterprise Manager (自動的に選択)

- Oracle JRF (自動的に選択されます)

3. 「次へ」をクリックします。

5. 「ドメイン名と場所の指定」画面で、新しいドメインの名前(WCCUIDomainなど)およびドメインとアプリケーションのディレクトリを入力します。

- ドメイン名: WCCUIDomain

- ドメインの場所: /u01/oracle/config/domains

- アプリケーションの場所: /u01/oracle/config/applications

構成ウィザードは、そのドメイン名のサブディレクトリをドメインの場所およびアプリケーションの場所に追加し、それぞれ、WCCUI_ASERVER_HOMEディレクトリ、WCCUI_APPLICATION_HOMEディレクトリを作成します。

これらのディレクトリが、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されたディレクトリおよび共有記憶域のマウント・ポイントと一致していることを確認します。WebCenter Contentの管理対象サーバーのドメイン・ディレクトリは、各サーバーのローカル・ボリュームに存在している必要があります。

「次へ」をクリックします。

6. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者が使用するユーザー名とパスワードを入力します。
「次へ」をクリックします。

7. 「サーバーの起動モードおよびJDKの構成」画面で、次の手順を実行します。

- 「WebLogicドメインの起動モード」には、「本番モード」を選択します。

- 「JDKの選択」では、「JROCKIT SDK1.6.0_version」を選択します。

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

「次へ」をクリックします。

8. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

9. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: ADMINVHN

- リスニング・ポート: 7001
管理サーバーのデフォルトのポート番号は7001です。Oracle WebCenter Contentドメインと同じマシンにWebCenter Contentユーザー・インタフェース・ドメインを構成する場合、異なるポート番号を使用します。

- SSLリスニング・ポート: N/A

- SSL有効: このチェック・ボックスは選択解除したままにします。

「次へ」をクリックします。

10. 「管理対象サーバーの構成」画面で、図15-2に示すように、WLS_WCCUI1およびWLS_WCCUI2を構成します。

図15-2 WLS_WCCUI管理対象サーバーの構成画面

「次へ」をクリックします。

11. 「クラスタの構成」画面で、図15-3に示すように、WCCUI_Clusterを構成します。

図15-3 WCCUI_Clusterの「クラスタの構成」画面

「次へ」をクリックします。

12. 「サーバーのクラスタへの割当」画面で、図15-4に示すように、各管理対象サーバーをWCCUI_Clusterに割り当てます。

図15-4 管理対象サーバーのWCCUI_Clusterへの割当て

「次へ」をクリックします。

13. 「マシンの構成」画面で、「Unixマシン」タブを開き、「追加」をクリックして、WCCUIADMINHOST、WCCUIHOST1およびWCCUIHOST2マシンを追加します(図15-5参照)。

図15-5 WCCUIホストの「マシンの構成」画面

マシン名は有効なホスト名またはリスニング・アドレスである必要はありません。各名前はノード・マネージャの場所を示す一意の識別子です。

注意:
localhostがすべてのアクティブなマシンの内部相対アドレスであるため、管理サーバーの仮想ホスト・マシンはlocalhostを指す必要があります。管理サーバーはlocalhost属性と1つ目のノードを組み合せて使用し、フェイルオーバー後は2つ目のノードも使用するため、管理サーバーのフェイルオーバー時には管理サーバーと関連付けられているノード・マネージャのインスタンスは変更されます。

「次へ」をクリックします。

14. 「サーバーのマシンへの割当」画面で、図15-6に示すように、管理サーバーおよび管理対象サーバーをマシンに割り当てます。

図15-6 WCCUIサーバーのマシンへの割当て

「次へ」をクリックします。

15. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

16. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

17. 「構成のサマリー」画面で、「作成」をクリックします。

18. ドメインの作成画面で、「完了」をクリックします。

この手順により、新しいドメインおよびWebCenter Contentユーザー・インタフェース・アプリケーションのための管理対象サーバーが作成されます。このアプリケーション用にデータ・ソースを設定する必要はありません。

15.5.3 ドメインでの構成後タスクおよび検証タスクの実行

構成ウィザードでドメインを構成したら、次の手順に従って構成後タスクと検証タスクを実行します。

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

- 第15.5.3.1項「Oracle ADF共有ライブラリのSherman Update 2へのアップグレード」

- 第15.5.3.2項「WCCUIHOST1での管理サーバー用boot.propertiesの作成」

- 第15.5.3.3項「WCCUIHOST1でのノード・マネージャの起動」

- 第15.5.3.4項「WCCUIHOST1での管理サーバーの起動」

- 第15.5.3.5項「管理サーバー構成の検証」

- 第15.5.3.6項「ホスト名検証の無効化」

- 第15.5.3.7項「WCCUIHOST2のMiddlewareホームへのドメイン・レジストリ・ファイルのコピー」

15.5.3.1 Oracle ADF共有ライブラリのSherman Update 2へのアップグレード

WebCenter Contentユーザー・インタフェース・ドメインのOracle ADF共有ライブラリをSherman Update 2にアップグレードする手順は次のとおりです。

1. 次の例に示すように、WCCUI_ORACLE_COMMON_HOME/common/binディレクトリからWLSTを実行します。

cd /u01/oracle/products/fmw_home/oracle_common/common/bin

./wlst.sh

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline>

参照トポロジで、WCCUI_ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

2. 次のコマンドをオフライン・モードで実行します。

wls:/offline> upgradeADF('WCCUI_ASERVER_HOME');

次に例を示します。

wls:/offline> upgradeADF('/u01/oracle/config/domains/WCCUIDomain')
Target Library "jsf#2.0@1.0.0.0_2-0-2" to JRF "WCCUI_Cluster"
Target Library "jsf#2.0@1.0.0.0_2-0-2" to JRF "AdminServer"

参照トポロジで、WCCUI_ASERVER_HOMEは/u01/oracle/config/domains/WCCUIDomainディレクトリです。

15.5.3.2 WCCUIHOST1での管理サーバー用boot.propertiesの作成

WCCUIHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。このファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。

WCCHOST1上の管理サーバーに対してboot.propertiesファイルを作成する手順は次のとおりです。

1. WCCUIHOST1上で次のディレクトリ構造を作成します。

mkdir -p WCCUI_ASERVER_HOME/servers/AdminServer/security

参照トポロジで、WCCUI_ASERVER_HOMEは/u01/oracle/config/domains/WCCUIDomainディレクトリです。

2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=admin_user
password=admin_password

値admin_userおよびadmin_passwordは、WebLogic Serverドメイン管理者のユーザー名とパスワードです。

注意:
管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。第15.5.3.4項「WCCUIHOST1での管理サーバーの起動」に記載した管理サーバーを起動します。セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、できるだけ速やかにサーバーを起動し、エントリを暗号化してください。

3. ファイルを保存してエディタを閉じます。

15.5.3.3 WCCUIHOST1でのノード・マネージャの起動

WCCUIHOST1でノード・マネージャを起動するには、StartScriptEnabledプロパティをtrueに設定し、startNodeManager.shを使用してノード・マネージャを起動します。

WCCUIHOST1でノード・マネージャを起動する手順は次のとおりです。

1. WCCUI_ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定した後に、ノード・マネージャを起動します。

cd WCCUI_ORACLE_COMMON_HOME/common/bin

./setNMProps.sh

参照トポロジで、WCCUI_ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

2. ノード・マネージャを起動します。

cd WCCUI_WL_HOME/server/bin

export JAVA_OPTIONS=-DDomainRegistrationEnabled=true

nohup ./startNodeManager.sh > nm.out&

参照トポロジで、WCCUI_WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

注意:
管理サーバーを管理するノード・マネージャを起動するときには、-DDomainRegistrationEnabled=trueパラメータを設定することが重要になります。マシンに管理サーバーがなく、そのマシンが管理サーバーのフェイルオーバー・ノードでない場合には、次のスクリプトを使用してノード・マネージャを起動できます(exportコマンドは不要です)。

nohup ./startNodeManager.sh > nm.out&

15.5.3.4 WCCUIHOST1での管理サーバーの起動

管理サーバーは、ノード・マネージャを使用して起動および停止します。ただし、初めてノード・マネージャで管理サーバーを起動するときに、Fusion Middleware構成ウィザードによってノード・マネージャに設定されたデフォルトのユーザー名およびパスワードを変更する必要があります。したがって、初回の起動時には、管理サーバーの起動スクリプトを使用する必要があります。初回起動時は手順1から4までが必要で、それ以後の起動はすべて手順4のみが必要になります。

WCCUIHOST1で管理サーバーを起動する手順は次のとおりです。

1. WCCUIHOST1で、ドメイン・ディレクトリの起動スクリプトを使用して管理サーバーを起動します。

cd WCCUI_ASERVER_HOME/bin

./startWebLogic.sh

参照トポロジで、WCCUI_ASERVER_HOMEは/u01/oracle/config/domains/WCCUIDomainディレクトリです。

2. 管理コンソールを使用してノード・マネージャの資格証明を更新します。

1. Webブラウザを開き、http://WCCUIADMINVHN:7001/consoleにアクセスします。

2. weblogicとしてログインします。

3. 「ロックして編集」をクリックします。

4. 「domain_name」→「セキュリティ」→「一般」をクリックして、一番下にある「詳細」オプションを開きます。

5. ノード・マネージャの新しいユーザー名を入力するか、既存のユーザー名を書き留めておいてノード・マネージャのパスワードを更新します。

6. 変更を保存してアクティブ化します。

3. コマンドstopWebLogic.shを発行して、WebLogic Serverの管理サーバーを停止します。このコマンドは、WCCUI_ASERVER_HOME/binディレクトリの下にあります。
または、管理サーバーのプロセスを停止します。それには、このプロセスが起動されたシェルで[Ctrl]+[C]を使用するか、または標準のプロセス識別子とオペレーティング・システムのkillコマンドを使用します。

4. Oracle WebLogic Scripting Tool (WLST)を起動し、nmconnectおよび前の手順で設定した資格証明によりノード・マネージャに接続し、nmstartを使用して管理サーバーを起動します。

cd WCCUI_ORACLE_COMMON_HOME/common/bin

./wlst.sh

参照トポロジで、WCCUI_ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

WLSTシェル内で、次のコマンドを実行します(ノード・マネージャが稼働していることを確認します)。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCUIHOST1","5556", "domain_name","WCCUI_ASERVER_HOME")

wls:/nm/domain_name> nmStart("AdminServer")

注意:

- WCCUIHOST1とは、ドメインを作成したノードのアドレスで、管理サーバーのリスニング・アドレスではありません。

- 値node_admin_userおよびnode_admin_passwordは、手順2eで更新したノード・マネージャの資格証明です。ノード・マネージャ管理者のユーザー名とパスワードはサーバー管理者のIDおよびパスワードとは関係なく、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらの資格証明は、WCCUI_ASERVER_HOME/config/nodemanager/nm_password.propertiesファイルに格納されます。

15.5.3.5 管理サーバー構成の検証

作成したドメインの管理サーバーが適切に構成されていることを確認するには、WebLogic Server管理コンソールにログインし、管理サーバーがリストされていることを確認します。これにより構成を検証してから、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. Webブラウザを開き、http://WCCUIADMINVHN:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. http://WCCUIADMINVHN:7001/emでFusion Middleware Controlにアクセスできることを確認します。

4. 第15.5.3.2項「WCCUIHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してFusion Middleware Controlにログインします。

管理サーバーが稼働している必要があります。

15.5.3.6 ホスト名検証の無効化

この手順は、管理サーバーでの様々なノードの認証に対して適切な証明書を設定していない場合に必要となります(第16章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、異なるWebLogic Serverインスタンスを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証を行う際に、管理サーバーと各管理対象サーバーに対するホスト名の検証を無効にし、第16章「エンタープライズ・デプロイメント用のノード・マネージャの設定」の説明に従ってエンタープライズ・デプロイメント・トポロジの構成を完了した後に再びホスト名の検証を有効にします。

サーバーに対するホスト名の検証は、サーバーが起動して稼働するとただちに、管理サーバーから順に無効にできます。

ホスト名検証を無効にする手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 左側の「ドメイン構造」ツリーで「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 「サーバーのサマリー」ページで、「サーバー」表の「名前」列にあるサーバー名をクリックします。

6. このサーバーの「設定」ページで、「SSL」タブをクリックします。

7. ページの「詳細」セクションを開きます。

8. 「ホスト名の検証」を「なし」に設定します。

9. 「保存」をクリックします。

10. 変更を保存してアクティブ化します。

11. この変更内容を有効にするには、ノード・マネージャおよび管理サーバーを再起動する必要があります。

1. 次のコマンドを使用して、管理サーバーとノード・マネージャを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

2. ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。
シェルのフォアグラウンドで実行されている場合は、[Ctrl]キーを押しながら[C]を押します。

シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、killコマンドを使用して停止します。例:

ps -ef | grep NodeManager
orcl   9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh

kill -9 9139

3. ノード・マネージャを起動します。

cd WCCUI_WL_HOME/server/bin
nohup ./startNodeManager.sh > nm.out&

参照トポロジで、WCCUI_WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

4. 次の手順で管理サーバーを再起動します。

- Oracle WebLogic Scripting Tool (WLST)を起動します。

cd WCCUI_ORACLE_COMMON_HOME/common/bin

./wlst.sh

参照トポロジで、WCCUI_ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

- WLSTシェル内で、nmConnectコマンドとノード・マネージャの資格証明を使用してノード・マネージャに接続し(ノード・マネージャが稼動していることを確認しておきます)、nmStartを使用してノード・マネージャを起動します。

wls:/offline>nmConnect("node_admin_user","node_admin_password", "WCCUIHOST1","5556","domain_name","WCCUI_ASERVER_HOME")

値node_admin_userおよびnode_admin_passwordは、ノード・マネージャの資格証明です。これらの資格証明の詳細は、第15.5.3.4項「WCCUIHOST1での管理サーバーの起動」を参照してください。

参照トポロジで、WCCUI_ASERVER_HOMEは/u01/oracle/config/domains/WCCUIDomainディレクトリです。

- nmStartを使用して管理サーバーを起動します。

wls:/nm/domain_name> nmStart("AdminServer")

15.5.3.7 WCCUIHOST2のMiddlewareホームへのドメイン・レジストリ・ファイルのコピー

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されているように、WCCUIHOST2上のMiddlewareホームは、インストール・バイナリ・ボリュームに最大の冗長性を提供する、別の記憶域ボリューム(WCCUIHOST2に対してローカル)上にあります。管理サーバー・ドメインの作成中にWCCUIHOST1上で作成されたdomain-registry.xmlファイルは、WCCUIHOST2では作成されません。このファイルはWCCUIHOST1からコピーする必要があります。

WCCUIHOST1上のMiddlewareホームからWCCUIHOST2上のMiddlewareホームにドメイン・レジストリ・ファイルをコピーする手順は次のとおりです。

1. WCCUIHOST1のMiddlewareホーム・ディレクトリに移動します。

cd WCCUI_MW_HOME

参照トポロジで、WCCUI_MW_HOMEは/u01/oracle/products/fmw_homeディレクトリです。

2. 次のコマンドを使用して、domain-registry.xmlファイルをWCCUIHOST2のMiddlewareホームにコピーします。

scp domain-registry.xml oracle@WCCUIHOST2:WCCUI_MW_HOME

3. 次のコマンドを使用して、nodemanger.domainsファイルをWCCUIHOST1からWCCUIHOST2にコピーします。

scp WCCUI_WL_HOME/common/nodemanager/nodemanager.domains oracle@WCCUIHOST2:WCCUI_WL_HOME/common/nodemanager/

参照トポロジで、WCCUI_WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

15.5.4 WCCUI管理対象サーバーのMDSへの登録およびメタデータ・パーティションの作成

Oracle Enterprise Manager Fusion Middleware ControlまたはWebLogic Server Scripting Tool (WLST)でWCCUI管理対象サーバーをOracle Metadata Services (MDS)リポジトリに登録できます。

Fusion Middleware ControlでMDSリポジトリにWCCUI管理対象サーバーを登録して、メタデータ・パーティションを作成する手順:

1. http://ADMINVHN:7001/emのOracle Enterprise Manager Fusion Middleware Controlにアクセスします。

2. 第15.5.3.2項「WCCUIHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してFusion Middleware Controlにログインします。

3. 左側の「WebLogicドメイン」で「WCCUI Domain」をクリックし、「WebLogicドメイン」メニューから「メタデータ・リポジトリ」を選択します(図15-7を参照)。

図15-7 「WCCUIDomain」ページの「WebLogicドメイン」メニュー

4. 「メタデータ・リポジトリ」ページで、「データベース・ベース・リポジトリ」の下にある「登録」をクリックします(図15-8を参照)。

図15-8 「メタデータ・リポジトリ」ページ

5. 「データベース・ベースのメタデータ・リポジトリの登録」ページでMDSリポジトリを登録し(図15-9を参照)、右端の「OK」をクリックします。

図15-9 MDSリポジトリの登録

「リポジトリをターゲット設定します」ダイアログ・ボックスが開きます。

6. 「リポジトリをターゲット設定します」ダイアログ・ボックスで、「WCCUI_Cluster」を選択し(図15-10を参照)、「ターゲット」をクリックします。

図15-10 リポジトリのWCCUI_Clusterへのターゲット設定

7. メッセージ「ターゲット設定操作が完了しました。」が表示されたら、「閉じる」をクリックします。

8. WebCenter Contentユーザー・インタフェース・ドメインで管理サーバーを再起動(停止してから起動)します(第10.3項「管理サーバーの再起動」を参照)。

WLSTでMDSリポジトリにWCCUI管理対象サーバーを登録して、メタデータ・パーティションを作成する手順:

1. WCCUI_MW_HOME/oracle_common/common/bin/wlst.shからWLSTを実行し、相互モードでWebLogic Server instanceに接続します。

wls:/offline> connect()
Please enter your username : weblogic
Please enter your password : password

Please enter your server URL: [t3://localhost:7001] :t3://host:port of admin server where the WebCenter Content user interface Managed Server is running
Connecting to t3://host:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'WCCUIDomain'.

Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.

wls:/WCCUIDomain/serverConfig>

参照トポロジで、WCCUI_MW_HOMEは/u01/oracle/products/fmw_homeディレクトリです。

2. 次のコマンドを実行してパーティションを作成します。

wls:/WCCUIDomain/serverConfig> createMetadataPartition(repository='mds-WCCUIMDSREPO', partition='MDS_PARTITION')
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

Executing operation: createMetadataPartition.

Partition "MDS_PARTITION" in Metadata DB repository "mds-WCCUIMDSREPO" was created successfully.

3. registerMetadataDBRepositoryコマンドを使用してMDSリポジトリを登録します。

registerMetadataDBRepository('WCCUIMDSREPO', 'Oracle','dbscan.example.com', '1521', 'wccedg.example.com', 'WCCUI_MDS', 'password', 'WLS_WCCUI1')

前述のコマンドのターゲット・サーバーは、WebCenter Contentユーザー・インタフェース管理対象サーバーです。

サンプルのregisterMetadataDBRepositoryコマンドには次のパラメータがあります。

- WCCUIMDSREPOはメタデータ・リポジトリの名前です。

- oracleはデータベース・タイプです。

- dbscan.example.comはデータベース・ホストの名前です。

- 1521はデータベースのポート番号です。

- wccedg.example.comはデータベース・サービス名です。

- WCCUI_MDSはスキーマ名です。

- passwordはスキーマ所有者のパスワードです。

- WLS_WCCUI1はWebCenter Contentユーザー・インタフェース管理対象サーバーです。

4. WebCenter Contentユーザー・インタフェース・ドメインで管理サーバーを再起動(停止してから起動)します(第10.3項「管理サーバーの再起動」を参照)。

同じホストに両方のドメインをインストールした場合、WebCenter Contentユーザー・インタフェース・ドメイン内の管理対象サーバーのポートは、デフォルトの管理対象サーバー・ポートとなりません。

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

WLS_WCCUI1およびWLS_WCCUI2にドメイン構成を伝播する手順は次のとおりです。

1. 管理サーバーを停止します。

2. 次のpackコマンドをWCCUIHOST1で実行し、テンプレート・パックを作成します。

cd WCCUI_ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=WCCUI_ASERVER_HOME -template=WCCUIDomainTemplateUI.jar
-template_name=WCCUIDomainTemplateUI

参照トポロジで、WCCUI_ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、WCCUI_ASERVER_HOMEは/u01/oracle/config/domains/WCCUIDomainディレクトリです。

3. 次のunpackコマンドをWCCUIHOST1で実行して、WLS_WCCUI1管理対象サーバー用のドメイン・ディレクトリを作成します。

cd WCCUI_ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain= WCCUI_MSERVER_HOME -template=WCCUIDomainTemplateUI.jar -app_dir= WCCUI_APPLICATION_HOME -overwrite_domain=true

参照トポロジで、WCCUI_MSERVER_HOMEは/u02/oracle/config/domains/WCCUIDomainディレクトリで、WCCUI_APPLICATION_HOMEは/u01/oracle/config/applications/WCCUIDomainディレクトリです。

注意:

- unpackコマンドはWCCUI_WL_HOME/common/binから実行するのではなく、WCCUI_ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

- WCCUI_APPLICATION_HOMEディレクトリは、unpackコマンドでバックアップされます。

- unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびEARファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびEARファイルをリストアする必要があります。

4. 次のコマンドをWCCUIHOST1で実行し、手順1で作成したテンプレート・パックをWCCUIHOST2にコピーします。

scp WCCUIDomainTemplateUI.jar oracle@WCCUIHOST2:WCCUI_ORACLE_COMMON_HOME/common/bin

参照トポロジで、WCCUI_ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリです。

5. 次のunpackコマンドをWCCUIHOST2で実行して、伝播されたテンプレートをWLS_WCCUI2管理対象サーバーのドメイン・ディレクトリに解凍します。

cd WCCUI_ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=/u02/oracle/config/domains/WCCUIDomain
-template=WCCUIDomainTemplateUI.jar
-app_dir=/u01/oracle/config/applications/WCCUIDomain
-overwrite_domain=true
<< read template from "/u01/oracle/products/fmw_home/oracle_common/common/bin/WCCUIDomainTemplateUI.jar"
>>  succeed: read template from "/u01/oracle/products/fmw_home/oracle_common/common/bin/WCCUIDomainTemplateUI.jar"
<< set config option OverwriteDomain to "true"
>>  succeed: set config option OverwriteDomain to "true"
<< set config option AppDir to "/u01/oracle/config/applications/WCCUIDomain"
>>  succeed: set config option AppDir to "/u01/oracle/config/applications/WCCUIDomain"
<< set config option DomainName to "WCCUIDomain"
>>  succeed: set config option DomainName to "WCCUIDomain"
<< write Domain to "/u02/oracle/config/domains/WCCUIDomain"
...............................................................................................
>>  succeed: write Domain to "/u02/oracle/config/domains/WCCUIDomain"
<< close template
>>  succeed: close template

6. WCCUIHOST2のノード・マネージャ、管理サーバーおよび管理対象サーバーを起動します。

15.5.6 WebCenter Contentユーザー・インタフェースとコンテンツ・サーバーの関連付け

次に、接続アーキテクチャを使用して、WebCenter Contentユーザー・インタフェースをコンテンツ・サーバーに関連付ける必要があります。

WebCenter Contentユーザー・インタフェースをコンテンツ・サーバーに関連付ける手順は次のとおりです。

1. 変数WCCUI_WL_HOMEをWebLogic Serverインストールの場所に設定します。例:

WCCUI_WL_HOME=WCCUI_MW_HOME/wlserver_10.3

参照トポロジで、WCCUI_MW_HOMEは/u01/oracle/products/fmw_homeディレクトリです。

2. 次のディレクトリに移動します:

WCCUI_MW_HOME/oracle_common/webcenter/wccadf/ConnArchWlstResources/common/bin

3. manageconnwlst.sh(前述のディレクトリ内のカスタムWLSTスクリプト)を実行します。

./manageconnwlst.sh

wls:/offline> connect()

Please enter your username :weblogic

Please enter your password :

Please enter your server URL [t3://localhost:7001] :t3://WCCUIHOST1:16225

Connecting to t3://WCCUIHOST1:16225 with userid weblogic ...

Successfully connected to managed Server 'WLS_WCCUI1' that belongs to domain 'WCCUIDomain'.

Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead.

wls:/WCCUIDomain/serverConfig>

4. RIDC接続をWebCenter Contentユーザー・インタフェース管理対象サーバーに更新します。

wls:/domain_name/serverConfig/updateRIDCConnection('ADF_UI_APP_NAME','WccAdfDefaultConnection',connUrl='idc://contentserver_host:intradoc_port',credUsername='ucm_admin_user')

次のコマンドのADF_UI_APP_NAMEは、Oracle WebCenter Content - Web UIアプリケーションです。例:

wls:/WCCUIDomain/serverConfig> updateRIDCConnection('Oracle WebCenter Content - Web UI', 'WccAdfDefaultConnection', connUrl='idc://ucminternal.example.com:6300', credUsername='weblogic')

注意:
この例で、WCCUI管理対象サーバーとWCC管理対象サーバー間のRIDC接続では、IDCプロトコルを使用しています。
Oracle WebCenter Content用にJAX-WS、HTTPまたはHTTPSクライアント接続を構成して、WebCenter Contentユーザー・インタフェースをコンテンツ・サーバーに関連付けることもできます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』のWebCenter Contentユーザー・インタフェースとコンテンツ・サーバーの関連付けに関する項を参照してください。

この時点で、WebCenter Contentユーザー・インタフェース・アプリケーション・インスタンスが設定されて、1台目のマシンにインストールされたWebCenter Content管理対象サーバーに関連付けられています。

5. WebLogic Serverの管理コンソールを使用して、コンテンツ・サーバーの管理対象サーバーを再起動します。

6. WebCenter Contentユーザー・インタフェース・ドメインにWebLogic Serverの管理コンソールを使用して、WebCenter Contentユーザー・インタフェースの管理対象サーバーを再起動します。

15.6 管理者ユーザーの構成

コンテンツ・サーバーおよびWebCenter Contentユーザー・インタフェースは、同じユーザー・ディレクトリにアクセスする必要があります。Oracle Internet DirectoryおよびActive Directoryなどの標準的なLDAP機能をドメイン間で共有できます。このような統合で標準的なガイドラインを使用すると、Oracle Access ManagerまたはOracleシングル・サインオンを使用したシングル・サインオン・ソリューションを構成できます。

LDAPオプションの詳細は、第8章「エンタープライズ・デプロイメント用のドメインの作成」を参照してください。

デフォルトでは、WebCenter Contentユーザー・インタフェースには、有効なWebCenter Content管理者ユーザーが1つ必要です。

- 管理者ユーザーは、第15.5項「WebCenter Contentユーザー・インタフェース・アプリケーションの新しいドメインへのデプロイ」の手順9dで、WebCenter Contentユーザー・インタフェース管理対象サーバーに接続するために使用されたupdateRIDCConnection() WLSTコマンドのcredUsernameパラメータで指定されました。

- LDAPストアで選択された名前のユーザーが必要です。この管理者ユーザーがない場合、WebCenter Contentユーザー・インタフェース・デプロイメントは成功しません。

- ユーザーには、WebCenter Content管理対象サーバーの管理者権限が必要です。

15.7 WebCenter Contentユーザー・インタフェースへのアクセス

WebCenter Contentユーザー・インタフェースには、次のURLからアクセスできます。

http://WCCUIHOST1:16225/wcc

WebCenter Contentユーザー・インタフェース・アプリケーションは、デフォルトではポート16225で実行されます。

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

WLS_WCCUI1およびWLS_WCCUI2管理対象サーバーを含むWCCUI_ClusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。これにより、ロード・バランサを介した管理対象サーバーへのアクセスを検証できます。

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

- 第15.8.1項「WLS_WCCUI管理対象サーバー用のOracle HTTP Serverの構成」

- 第15.8.2項「ロード・バランサを介したアクセスの検証」

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

WLS_WCCUI管理対象サーバー用にOracle HTTP Serverを構成する手順は次のとおりです。

1. 次のディレクトリのそれぞれにwccui_vh.confという名前の新しいファイルを作成し、WebCenter Contentユーザー・インタフェース用に<VirtualHost>ディレクティブを定義します。

- /u02/oracle/config/web1/config/OHS/ohs1/moduleconf

- /u02/oracle/config/web2/config/OHS/ohs2/moduleconf

2. WEBHOST1およびWEBHOST2上の各Webサーバーで、/u02/oracle/config/web1/config/OHS/ohs1/moduleconf/wccui_vh.confおよび/u02/oracle/config/web2/config/OHS/ohs2/moduleconf/wccui_vh.confファイルに次の行を追加します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://wcc.example.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

## Added for external access for WCCUI

# ADF UI
<Location /wcc>
WebLogicCluster WCCUIHOST1:16225,WCCUIHOST2:16225
SetHandler weblogic-handler
WLCookieName WCC-ADF-JSESSIONID
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

参照トポロジで、ORACLE_INSTANCEは/u02/oracle/config/web1または/u02/oracle/config/web2ディレクトリです。

3. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

ORACLE_INSTANCE/admin/bin/opmnctl restartproc ias-component=ohsX

ias-componentに対して、WEBHOST1ではohs1を使用し、WEBHOST2ではohs2を使用します。

参照トポロジで、ORACLE_INSTANCEは/u02/oracle/config/web1または/u02/oracle/config/web2ディレクトリです。

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

URLを検証して、Oracle HTTP ServerからWCCUI_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。

URLを検証する手順は次のとおりです。

1. WLS_WCCUI2が稼動している状態で、WebLogic Server管理コンソールからWLS_WCCUI1を停止します。

2. http://wcc.example.com/wccにアクセスし、正しく動作していることを確認します。

3. WebLogic Server管理コンソールからWLS_WCCUI1を起動します。

4. WebLogic Server管理コンソールでWLS_WCCUI2を停止します。

5. http://wcc.example.com/wccにアクセスし、正しく動作していることを確認します。

クラスタ・ノードを検証できます。このクラスタ・ノードは、ロード・バランサを介してトラフィック・バランシングが行われ、再びWeb層を介してトラフィック・バランシングが行われた後で転送されるクラスタ・ノードです。

15.9 ワークフロー構成の完了

WebCenter Contentユーザー・インタフェースのワークフロー構成を完了するには、管理対象サーバーを再起動し、構成を確認する必要があります。UseDatabaseWfInQueue構成変数により、WebCenter Contentユーザー・インタフェースは、ユーザーに割り当てられたワークフローにフィルタを適用できるようになります。EmailNotificationType構成変数では、ワークフローとサブスクリプションが異なるコンテンツ・サーバー・ユーザー・インタフェースに含まれる場合に、通知電子メール内のリンクがポイントする先を指定します。この構成変数のデフォルト値は、NativeWebUIです。

ワークフロー構成を完了するには:

1. WCCUI_DOMAIN/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のマネージング』のワークフローの管理に関する項を参照してください。

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

この章では、エンタープライズ・デプロイメントの推奨事項に従ってノード・マネージャを構成する方法を説明します。

この章には次の項が含まれます:

- 第16.1項「ノード・マネージャの設定の概要」

- 第16.2項「ノード・マネージャのログの場所の変更」

- 第16.3項「ノード・マネージャのホスト名検証証明書の有効化」

- 第16.4項「ノード・マネージャの起動」

16.1 ノード・マネージャの設定の概要

ノード・マネージャによって、Oracle WebLogic Serverドメインの管理サーバーおよび管理対象サーバーの起動と停止が可能です。表16-1では、設定手順を説明するほか、設定プロセスの概要、ノード・マネージャ・ログおよびホスト名検証の推奨場所について説明します。

表16-1 ノード・マネージャの設定手順

手順

説明

詳細

EDの管理ディレクトリ内でノード・マネージャ・ログの場所を指定

nodemanager.propertiesファイルにあるLogFileプロパティを編集して、ノード・マネージャを再起動します。

第16.2項「ノード・マネージャのログの場所の変更」

ノード・マネージャと管理サーバー間のSSL通信を設定

自己署名付き証明書を生成し、アイデンティティ・キーストアおよびトラスト・キーストアを作成するほか、カスタム・キーストアを使用するためにノード・マネージャおよび管理対象サーバーを構成し、各管理対象サーバーのホスト名検証設定を変更します。

第16.3項「ノード・マネージャのホスト名検証証明書の有効化」

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

初めてノード・マネージャを起動する場合は、その前にスクリプトsetNMProps.shを実行します。

第16.4項「ノード・マネージャの起動」

設定プロセス

この章で説明される手順は、第1.1.1項「このガイドに記載されている参照用トポロジ」で概略を説明したエンタープライズ・デプロイメント・トポロジの各種コンポーネントで実行される必要があります。この章では、コンポーネント固有のアイテム間で識別するために変数を使用しています。

- WLS_SERVER: この変数は、エンタープライズ・デプロイメント・コンポーネントのWebLogic Server管理対象サーバー(例: WLS_WCC1)を示します。

- HOST: この変数は、エンタープライズ・デプロイメント・コンポーネントのホスト・コンピュータ(例: WCCHOST1)を示します。

- VIP: この変数は、エンタープライズ・デプロイメント・コンポーネントの仮想IPアドレス(例: WCCHOST1VHN1)を示します。

これらの変数に使用する値は、このエンタープライズ・デプロイメント・ガイドのコンポーネント関連の章に記載されています。この章に記載されている手順は、第10.7項「WLS_WCC管理対象サーバーのノード・マネージャの構成」に記載されている情報を使用して、ホスト名と仮想IPアドレスのペアごとに複数回にわたり実行する必要があります。

推奨事項

エンタープライズ・デプロイメント・トポロジのノード・マネージャの構成に関して、次の2つの推奨事項があります。

1. ノード・マネージャのログ・ファイルは、デフォルト(ノード・マネージャが存在するミドルウェア・ホーム内)以外の場所に置くことをお薦めします。詳細は、第16.2項「ノード・マネージャのログの場所の変更」を参照してください。

2. また、ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。それには、ドメイン内で使用される複数のアドレスの証明書を使用する必要があります。この章では、ホスト名検証のために各ホストで証明書を構成する手順について説明します。詳細は、第16.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

注意:
このガイドで使用するパスワードはあくまでも一例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字をランダムな順序で並べたパスワードを使用します。

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

ノード・マネージャのログの場所を変更するには、ノード・マネージャのプロパティ・ファイルWL_HOME/common/nodemanager/nodemanager.propertiesを編集してから、ノード・マネージャを再起動します。

ログ・ファイルの新しい場所を指定する次の行を追加します。

LogFile=/u02/oracle/config/nodemanager/nodemanager.log

この配置場所は、MW_HOMEディレクトリの外にあり、エンタープライズ・デプロイメント・トポロジの/u02/oracle/configディレクトリ内にすることをお薦めします。

参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリで、MW_HOMEは/u01/oracle/products/fmw_homeディレクトリです。

ノード・マネージャを再起動して、変更を有効にする必要があります。

ノード・マネージャを再起動する手順は次のとおりです。

1. ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。
シェルのフォアグラウンドで実行されている場合は、[Ctrl]キーを押しながら[C]を押します。

シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、killコマンドを使用して停止します。例:

ps -ef | grep NodeManager
orcl   9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh

kill -9 9139

2. ノード・マネージャを起動します。

cd WL_HOME/server/bin
nohup ./startNodeManager.sh > nm.out&

参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

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

ノード・マネージャと管理サーバーまたは管理対象サーバー間の通信にSSLを設定する手順は次のとおりです。

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

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

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

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

- ステップ5: カスタム・キーストアを使用するための管理対象サーバーの構成

- ステップ6: 管理対象サーバーのホスト名検証設定の変更

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

この章で(例として)追加する証明書は、ノード・マネージャが物理ホスト名(HOST.example.com)でリスニングし、WebLogic Server管理対象サーバーが仮想ホスト名(VIP.example.com)でリスニングする構成に対応します。サーバーが仮想ホスト名を使用している場合は、サーバーを1つのノードから別のノードに移行できることを意味します。したがって、キーストアおよびトラスト・キーストアを保持するディレクトリは、理想としては、フェイルオーバーが発生してもアクセス可能な共有記憶域に配置する必要があります。

これらの証明書はネットワーク名または別名を使用して作成する必要があります。自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。

次の手順では、HOST.example.comおよびVIP.example.comの証明書を構成しています。つまり、物理ホスト名(HOST)と仮想ホスト名(VIP)の両方がHOSTで使用されることを想定しています。また、HOST.example.comはノード・マネージャが使用するアドレスであり、VIP.example.comは管理対象サーバーまたは管理サーバーが使用するアドレスであることも想定しています。これは、管理サーバーとOracle Fusion Middlewareコンポーネントをホストするノードや、1つのサーバーに共存する2つの管理対象サーバーの一方が物理ホスト名をリスニングしてもう一方が仮想ホスト名をリスニング(移行サーバーを使用するサーバーの場合)するノードで、よく見られる状況です。

HOSTに自己署名証明書を作成する手順は次のとおりです。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して、環境設定を行います。Bourneシェルの場合、HOST上で次のコマンドを実行します。

cd WL_HOME/server/bin

. ./setWLSEnv.sh

CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

2. キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。各種目的(HTTPの起動用のSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、WCCHOST2では、WCCHOST1の証明書用に作成されたcertディレクトリを使用します。証明書用のユーザー定義ディレクトリを作成します。

mkdir cert

3. 前の手順で作成したディレクトリに移動します。

cd cert

4. HOST上でユーザー定義ディレクトリからutils.CertGenツールを実行して、HOST.example.comおよびVIP.example.comの両方に対する証明書を作成します。
構文(すべてを1行で入力します):

java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name [export | domestic] [Host_Name]

例:

java utils.CertGen password HOST.example.com_cert HOST.example.com_key domestic HOST.example.com

java utils.CertGen password VIP.example.com_cert VIP.example.com_key domestic VIP.example.com

5. 同じノードまたは別のノードで別のホスト名を使用する場合は、証明書ストアに必要なホスト名を追加します(必要なホスト名がHOST.example.comおよびVIP.example.comと異なる場合)。

6. 同じノードまたは別のノードで別のホスト名を使用する場合は、アイデンティティ・ストアおよびトラスト・ストアの場所に関する情報を、ノード・マネージャ(ノード・マネージャで別のホスト名を使用する場合)またはサーバー(管理対象サーバーで別のホスト名を使用する場合)で変更します。

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

utils.ImportPrivateKeyユーティリティを使用して、新しいアイデンティティ・キーストアを作成します。

HOSTにアイデンティティ・キーストアを作成する手順は次のとおりです。

1. utils.ImportPrivateKeyユーティリティを使用してappIdentityKeyStoreという新しいアイデンティティ・キーストアを作成します。このキーストアの作成場所は、証明書と同じディレクトリ(/u01/oracle/config/domains/WCCDomain/cert)とします。

注意:
utils.ImportPrivateKeyユーティリティを使用して証明書およびそれに対応するキーをアイデンティティ・ストアにインポートすると、アイデンティティ・ストアが1つも存在しない場合は、新しく作成されます。

2. HOST上で、HOST.example.comおよびVIP.example.comの両方の証明書と秘密鍵をアイデンティティ・ストアにインポートします。必ず、インポートする証明書と鍵のペアごとに異なる別名を使用してください。
構文(すべてを1行で入力します):

java utils.ImportPrivateKey Keystore_File Keystore_Password
Certificate_Alias_to_Use Private_Key_Passphrase
Certificate_File
Private_Key_File
[Keystore_Type]

例:

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity1 password
/u01/oracle/config/domains/WCCDomain/cert/HOST.example.com_cert.pem
/u01/oracle/config/domains/WCCDomain/cert/HOST.example.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
appIdentity2 password
/u01/oracle/config/domains/WCCDomain/cert/VIP.example.com_cert.pem
/u01/oracle/config/domains/WCCDomain/cert/VIP.example.com_key.pem

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

keytoolユーティリティを使用して、新しいトラスト・キーストアを作成します。

HOSTにトラスト・キーストアを作成する手順は次のとおりです。

1. 新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在するからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME/server/lib/ディレクトリの下にあるHOST上で標準JavaキーストアのCA証明書をその証明書と同じディレクトリにコピーします。例:

cp WL_HOME/server/lib/cacerts /u01/oracle/config/domains/WCCDomain/cert/appTrustKeyStore.jks

2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは常に変更することをお薦めします。これを実行するには、HOST上でkeytoolユーティリティを使用します。構文は次のとおりです。

keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password

例:

keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit

3. このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用します。これは、WL_HOME/server/libディレクトリにあります。このCA証明書は、HOST上でkeytoolユーティリティを使用して、appTrustKeyStoreにインポートする必要があります。構文は、次のとおりです。

keytool -import -v -noprompt -trustcacerts -alias Alias_Name -file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password

例:

keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass password

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

カスタム・キーストアを使用するようにノード・マネージャを構成するには、WL_HOME/common/nodemanagerディレクトリにある nodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity_Keystore
CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password
CustomIdentityAlias=Identity_Keystore_Alias
CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate

各ノードに個々に割り当てられたカスタム・アイデンティティの別名が、各ノードのCustomIdentityAlias値に正しく使用されていることを確認します。たとえばWCCHOST2の場合は、次のようになります。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=/u01/oracle/config/domains/WCCDomain/cert/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentity2
CustomIdentityPrivateKeyPassPhrase=password

第16.4項「ノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化してください。

MW_HOMEに共通記憶域または共有記憶域のインストールを使用している場合は、同じ基本構成(nodemanager.properties)を使用する別のノードからノード・マネージャを起動します。この場合、バイナリを共有するすべてのノード用の証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加する必要があります。これを行うには、新しいノードの証明書を作成し、第16.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」の説明に従って、その証明書をappIdentityKeyStore.jksにインポートします。

このアイデンティティ・ストアで証明書が使用できるようになった時点で、各ノード・マネージャはそれぞれのアイデンティティ別名を指定して、正しい証明書を管理サーバーに送信する必要があります。これを実行するためには、HOST上で異なる環境変数を設定し、各ノードでノード・マネージャを起動します。

cd WL_HOME/server/bin

export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX

注意:
各ホストに個々に割り当てられているカスタム・アイデンティティの別名を指定してください。つまり、WCCHOST1にはappIdentity1、WCCHOST2にはappIdentity2を指定します。

16.3.5 カスタム・キーストアを使用するための管理対象サーバーの構成

Oracle WebLogic Server管理コンソールを使用して、アイデンティティ・キーストアとトラスト・キーストアを使用するように管理対象サーバーを構成します。

カスタム・キーストアを使用するように管理対象サーバーを構成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 「サーバーのサマリー」ページで、アイデンティティ・キーストアとトラスト・キーストアを構成するサーバー名(WLS_SERVER)をクリックします。

6. 選択されたサーバーの設定ページで、「構成」を選択し、「キーストア」を選択します。

7. 「キーストア」フィールドの横にある「変更」をクリックして、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書を格納し管理するための「カスタムIDとカスタム信頼」方法を選択します。作業が終了したら、「保存」をクリックします。

8. 「ID」セクションで、IDキーストアの次の属性を定義します。

- カスタムIDキーストア: IDキーストアへの完全修飾パス。

/u01/oracle/config/domains/WCCDomain/cert/appIdentityKeyStore.jks

- カスタムIDキーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

- カスタムIDキーストアのパスフレーズ: 第16.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

9. 「 信頼 」セクションで、トラスト・キーストアのプロパティを定義します。

- カスタム信頼キーストア: トラスト・キーストアへの完全修飾パス。

/u01/oracle/config/domains/WCCDomain/cert/appTrustKeyStore.jks

- カスタム信頼キーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

- カスタム信頼キーストアのパスフレーズ: 第16.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(New_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

10. 「保存」をクリックします。

11. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

12. 「構成」をクリックし、「SSL」をクリックします。

13. 「ロックして編集」をクリックします。

14. 「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第16.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。

15. 「保存」をクリックします。

16. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

17. 管理コンソールを使用して、変更を適用したサーバーを再起動します。

16.3.6 管理対象サーバーのホスト名検証設定の変更

前述の手順を実行したら、変更を反映した管理対象サーバーのホスト名検証をBea Host Name Verifierに設定する必要があります。

管理対象サーバーのホスト名検証の設定を変更する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 左側の「ドメイン構造」ツリーの「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 「サーバーのサマリー」ページで、表の「名前」列にある管理対象サーバーを選択します。

5. サーバーの設定ページで「SSL」タブを開きます。

6. 表示されたページの「詳細」セクションを開きます。

7. 「ロックして編集」をクリックします。

8. ホスト名検証をBea Host Name Verifierに設定します。

9. 「保存」をクリックします。

10. 管理コンソールを使用して、変更を適用したサーバーを再起動します。

16.4 ノード・マネージャの起動

次のコマンドを実行して、HOSTでノード・マネージャを起動します。ノード・マネージャが未構成で、まだ一度も起動していない場合は、第8.4.2項「WCCHOST1でのノード・マネージャの起動」で指定したsetNMProps.shスクリプトを実行し、管理対象サーバーの起動スクリプトの使用を有効化します。

cd WL_HOME/server/bin

export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX

nohup ./startNodeManager.sh > nm.out&

注意:

- 各ホストに個々に割り当てられているカスタム・アイデンティティの別名を指定してください。つまり、WCCHOST1にはappIdentity1、WCCHOST2にはappIdentity2を指定します。

- 他の関連するJavaオプションが各ノードのノード・マネージャに渡されることを前提としています。たとえば、管理サーバーをホストするWCCHOST1では、JAVA_OPTIONSパラメータに-DDomainRegistrationEnabled=および-DCustomIdentityAlias=も追加されます。

- ノード・マネージャの出力から、ノード・マネージャが適切なストアおよび別名を使用していることを確認します。出力は次のようになります。

CustomIdentityKeyStoreFileName=
ASERVER_HOME/certs/appIdentityKeyStore.jks
CustomIdentityAlias=appIdentityX

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

ホスト名の検証は、テスト構成の変更をサーバーに適用した場合に実行され、ノード・マネージャからSSLエラーの報告がない場合には正常終了します。

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

この章では、エンタープライズ・デプロイメント用にサーバー移行を構成する手順を説明します。

この章には次の項が含まれます:

- 第17.1項「エンタープライズ・デプロイメント用のサーバー移行の概要」

- 第17.2項「サーバー移行leasing表のユーザーと表領域の設定」

- 第17.3項「管理コンソールを使用したleasingのGridLinkデータ・ソースの作成」

- 第17.4項「ノード・マネージャのプロパティ・ファイルの編集」

- 第17.5項「wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定」

- 第17.6項「サーバー移行ターゲットの構成」

- 第17.7項「サーバー移行のテスト」

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

Oracle WebLogic Serverの管理対象サーバーではサーバー移行を構成できます。サーバー移行が構成された状態で障害が発生した場合は、各管理対象サーバーを別のホスト・マシン上で再起動できます。管理対象サーバーは、WebLogic Serverによってフェイルオーバーされた特定の浮動IPアドレスをリスニングします。

注意:
サーバー移行を使用するかどうかまたはサーバー移行が必要かどうかの詳細は、各コンポーネントの章を参照してください。

この章に記載されている手順は、第1.1.1項「このガイドに記載されている参照用トポロジ」で説明しているエンタープライズ・デプロイメント・トポロジの様々なコンポーネントで実行する必要があります。

この章では、次の変数を使用して、コンポーネント固有の項目を区別します。

- WLS_SERVER1およびWLS_SERVER2は、エンタープライズ・デプロイメント・コンポーネントのWebLogic Server管理対象サーバーを指します。

- HOST1およびHOST2は、エンタープライズ・デプロイメント・コンポーネントのホスト・マシンを指します。

- CLUSTERは、エンタープライズ・デプロイメント・コンポーネントと関連付けされたクラスタを指します。

これらの変数に使用する値は、このEDGのコンポーネント固有の章に記載されています。

このエンタープライズ・トポロジでは、WLS_SERVER1およびWLS_SERVER2の管理対象サーバーに対してサーバー移行を構成する必要があります。WLS_SERVER1の管理対象サーバーは、障害発生時にHOST2で再起動するように構成されています。WLS_SERVER2の管理対象サーバーは、障害発生時にHOST1で再起動するように構成されています。この構成では、WLS_SERVER1サーバーとWLS_SERVER2サーバーは、WebLogic Serverの移行によりフェイルオーバーされた特定の浮動IPアドレスをリスニングしています。

表17-1は、WebLogic Server管理対象サーバー用のサーバー移行を構成する手順を説明しています。

表17-1 サーバー移行の構成手順

手順

説明

詳細

ユーザー、表領域および移行表を設定します。

leasingという表領域、ユーザーおよびサーバー移行表を作成します。

第17.2項「サーバー移行leasing表のユーザーと表領域の設定」

Leasing表のGridLinkデータ・ソースを作成します。

Oracle RACデータベースの各インスタンスにデータ・ソースを作成するほか、管理コンソールでグローバルなLeasing GridLinkデータ・ソースを作成します。

第17.3項「管理コンソールを使用したleasingのGridLinkデータ・ソースの作成」

ノード・マネージャのプロパティに、移行用の値を指定します。

各ホストでnodemanager.propertiesファイルのプロパティの値を編集し、その値を検証します。

第17.4項「ノード・マネージャのプロパティ・ファイルの編集」

環境を設定し、oracleユーザーにスーパー・ユーザー権限を指定します。

PATH環境変数にファイルを追加し、wlsifconfig.shスクリプトに対するsudo権限を付与します。

第17.5項「wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定」

クラスタの移行を構成します。

移行ターゲットとして利用可能なノードを割り当て、各サーバーに候補となるマシンを指定します。

第17.6項「サーバー移行ターゲットの構成」

サーバー移行のテストを実行します。

ノード・マネージャまたは管理コンソールからホスト間のサーバー移行を検証します。

第17.7項「サーバー移行のテスト」

17.2 サーバー移行leasing表のユーザーと表領域の設定

create tablespace Leasingコマンドを使用して、サーバー移行leasing表のユーザーおよび表領域を設定します。

注意:
同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。その場合、データベース表leasing用のデータ・ソースおよびGridLinkデータ・ソースを再作成する必要はありませんが、サーバー移行用に構成されているクラスタを再度ターゲットに設定する必要があります。

サーバー移行リース表のユーザーおよび表領域を設定する手順は次のとおりです。

1. leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

注意:
データベース・ファイルの場所は、データベースに使用されるストレージの種類とデータ・ファイルの場所によって異なります。

2. leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by password;

SQL> grant create table to leasing;

SQL> grant create session to leasing;

SQL> alter user leasing default tablespace leasing;

SQL> alter user leasing quota unlimited on leasing;

3. leasing.ddlスクリプトを使用してleasing表を作成します。

1. 次のいずれかのディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。

WL_HOME/server/db/oracle/817/
WL_HOME/server/db/oracle/920/

2. leasingユーザーとしてデータベースに接続します。

3. leasing.ddlをSQL*Plusで実行します。

SQL> @copy_location/leasing.ddl;

4. データベースに加えた変更をコミットします。

SQL> commit;

17.3 管理コンソールを使用したleasingのGridLinkデータ・ソースの作成

Oracle WebLogic Server管理コンソールでleasing表のGridLinkデータ・ソースを作成します。

GridLinkデータ・ソースを作成する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「チェンジ・センター」の「ロックして編集」をまだクリックしていない場合はこれをクリックし、「次へ」をクリックします。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースのサマリー・ページで、「新規」をクリックし、「GridLinkデータ・ソース」を選択して、次の手順を実行します。

- 「名前」フィールドに、データ・ソースの論理名を入力します。たとえば、leasingと入力します。

- JNDIの名前を入力します。たとえば、jdbc/leasingと入力します。

- 「データベース・ドライバ」では、OracleのGridLink接続用ドライバ(Thin)、バージョン11以降を選択します。

- 「次へ」をクリックします。

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースの場合は、Oracle RACサービス名を入力する必要があります。例:

wccedg.example.com

- ホスト名とポート: 使用するRACデータベースのSCANアドレスとポートを入力して、「追加」をクリックます。このアドレスは、TCPプロトコルを使用してデータベース内の該当のパラメータを問い合せることによって特定できます。

SQL>show parameter remote_listener;

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string      db-scan.example.com

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベース・インスタンス・リスナーの仮想IPアドレスとポートを使用します。

wccdbhost1-vip.example.com (port 1521)

wccdbhost2-vip.example.com (1521)

- データベース・ユーザー名: leasing

- パスワード: leasingユーザーのパスワードを入力します。

- パスワードの確認: パスワードを再入力し、「次へ」をクリックします。

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イベントに登録し、それらのイベントを処理できるようにします。

- データベースによって報告されるRACデータベースのホスト名とONSリモート・ポートを入力し、「追加」をクリックします。
次の例は、ONSリモート・ポートの番号を表示しています。

[orcl@db-scan1 ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

- 「次へ」をクリックします。

注意:
Oracle Database 11gの場合は、次の例に示すように、各データベースのONSサービスのホスト名とポートを使用します。

wccdbhost1.example.com (port 6200)

wccdbhost2.example.com (6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
接続に成功した場合の通知の例を次に示します。

Connection test for db-scan.example.com:6200 succeeded.

「次へ」をクリックします。

11. 「ターゲットの選択」ページで、サーバーを移行中のIMG_Cluster、CPT_ClusterおよびSOA_Clusterをターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 「変更のアクティブ化」をクリックします。

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

3番目の手順では、ノード・マネージャのプロパティ・ファイルを編集します。これは、サーバー移行が構成されている両方のノード上のノード・マネージャに対して行う必要があります。

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

- Interface: このプロパティは浮動IPアドレスのインタフェース名(eth0など)を指定します。
eth0:1やeth0:2などのサブインタフェースは指定しないでください。このインスタンスは、:0や:1なしに使用されます。ノード・マネージャのスクリプトでは、異なる:X対応IPアドレスを横断して、追加または削除の対象を特定します。たとえば、Linux環境で有効な値は、構成するインタフェースの数に応じて、eth0、eth1、eth2、eth3およびethnになります。

- NetMask: このプロパティでは、インタフェースの浮動IPアドレスのネット・マスクを指定します。このネット・マスクは、インタフェースのネット・マスクと同じにする必要があります。このドキュメントの例では、255.255.255.0を使用します。

- UseMACBroadcast: このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

ノード・マネージャの出力(ノード・マネージャを起動するシェル)で、これらのプロパティが使用されていることを確認してください。使用されていない場合は、移行中に問題が発生することがあります。ノード・マネージャの出力は、次のように表示されます。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:
サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

- nodemanager.propertiesファイルで次のプロパティを設定します。
StartScriptEnabled: このプロパティをtrueに設定します。これは、ノード・マネージャが起動スクリプトを使用して管理対象サーバーを起動するために必要です。

注意:
共有記憶域のインストールからノード・マネージャを実行すると、同じnodemanager.propertiesファイルを使用して複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個々のプロパティを指定します。たとえば、HOSTnで別のインタフェース(eth3)を使用するには、Interface環境変数を次のように使用します。

export JAVA_OPTIONS=-DInterface=eth3

さらに、ノード・マネージャを起動する前に、この変数をシェルに設定しておきます。
各ノードで、他のJavaオプションを指定することによって、ノード・マネージャに渡すプロパティを指定できます。たとえば、管理サーバーをホストするWCCHOST1では、JAVA_OPTIONSパラメータに-DDomainRegistrationEnabled=および-DCustomIdentityAlias=も追加されます。

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

4番目の手順では、(oracleユーザーに対して)wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。

スクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。

1. 表17-2に一覧表示されているファイルがPATH環境変数に含まれていることを確認します。

表17-2 PATH環境変数に必要なファイル

ファイル

ディレクトリの場所

wlsifconfig.sh

/u02/oracle/config/domains/WCCDomain/bin/server_migration/

wlscontrol.sh

WL_HOME/common/bin/

nodemanager.domains

WL_HOME/common/nodemanager/

2. wlsifconfig.shスクリプトに対するsudo構成権限を付与します。

- パスワード・プロンプトを使用しないで機能するsudoを構成します。

- セキュリティ上の理由から、sudoを、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトのenvironmentとsuperuser権限を設定するには、次の手順を実行します。

1. WebLogic Serverユーザー(oracle)に、パスワード制限のないsudo権限を付与し、さらに/sbin/ifconfigと/sbin/arpingバイナリのexecute権限を付与します。

2. WebLogic Serverユーザー(oracle)がこのスクリプトを実行できることを確認します。/etc/sudoers内の次のエントリ例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。

oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

注意:
この手順に必要なsudo権限とsystem権限についてはシステム管理者に問い合せてください。

3. WL_HOME/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行して、HOST1およびHOST2のノード・マネージャを起動します。

nohup ./startNodeManager.sh > nm.out&

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

5番目の手順は、サーバー移行ターゲットを構成することです。まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。

クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。

1. WebLogic Server管理コンソール(http//ADMINVHN:7001/console)にログインします。

2. 左側の「ドメイン構造」ツリーで「環境」を開き、「クラスタ」を選択します。

3. 「クラスタのサマリー」ページで、表の「名前」列内から移行を構成するクラスタ(CLUSTER)をクリックします。

注意:
このドキュメントの手順では、Imaging、CaptureおよびOracle SOA Suiteクラスタのサーバー移行を構成します。

4. 「移行」タブを開きます。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「HOST1」と「HOST2」を選択します。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。

8. 「保存」をクリックします。

9. 「変更のアクティブ化」をクリックします。

10. 「ロックして編集」をクリックします。

11. サーバー移行の候補となるマシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。

1. WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「環境」ノードを開き、「サーバー」を選択します。

2. 移行を構成するサーバーを選択します。

注意:
このドキュメントの手順では、Imaging、CaptureおよびOracle SOA Suiteクラスタのサーバー移行を構成します。

3. 「移行」タブを開きます。

4. 「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。WLS_SERVER1には「HOST2」を選択します。WLS_SERVER2には「HOST1」を選択します。

5. 「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

6. 「保存」をクリックします。

7. 「変更のアクティブ化」をクリックします。

8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

- まず、管理コンソールを使用して管理対象サーバーを停止します。

- 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

- 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

17.7 サーバー移行のテスト

6番目と最後の手順として、サーバー移行のテストを実行します。

サーバー移行が適切に機能していることをHOST1から確認する手順は次のとおりです。

1. WLS_SERVER1管理対象サーバーを停止します。これを行うには、HOST1で次のコマンドを実行します。

kill -9 pid

pidは、その管理対象サーバーのプロセスID (PID)を指定します。次のコマンドを実行すると、ノードのプロセスIDを識別できます。

ps -ef | grep WLS_SERVER1

2. ノード・マネージャのコンソールを確認します。WLS_SERVER1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SERVER1の2回目の再起動を試行するまで待ちます。この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャによってログに記録されます。

サーバー移行が適切に機能していることをHOST2から確認する手順は次のとおりです。

1. ローカルのノード・マネージャのコンソールを確認します。ノード1で最後にWLS_SERVER1の再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、WLS_SERVER1の浮動IPアドレスが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。

2. 同じIPアドレスでサーバーのコンソールにアクセスします。

サーバー移行が適切に機能していることを管理コンソールから確認する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左側の「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行ステータス」表に、移行のステータスに関する情報が表示されます(図17-1)。

図17-1 管理コンソールの「移行ステータス」画面

注意:
サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

18 Oracle Identity Managementとの統合

この章では、Oracle WebCenter ContentをOracle Identity Managementと統合する方法について説明します。

この章には次の項が含まれます:

- 第18.1項「Oracle Identity Managementとの統合の概要」

- 第18.2項「アイデンティティ・ストアと外部LDAP認証プロバイダの再関連付け」

- 第18.3項「Oracle Access Manager 11gとの統合」

- 第18.4項「ロード・バランサおよびSSOを介したアクセスの検証」

- 第18.5項「インストールのバックアップ」

18.1 Oracle Identity Managementとの統合の概要

Oracle Fusion Middleware 11g リリース1の推奨シングル・サインオン・ソリューションはOracle Access Managerです。Oracle Fusion Middlewareエンタープライズ・デプロイメントをOracle Identity Management 11gと統合できます。次の項では、Oracle WebCenter Contentドメインのポリシー・ストアとアイデンティティ・ストアをOracle Identity Managementと統合する方法について説明します。

注意:
Oracle Identity Managementとの統合時には、Oracle Access Managementサーバーで現在使用されているトランスポート・モードを使用します(例: Open、Simple、Cert)。

表18-1は、Oracle Identity Management 11gをOracle WebCenter Contentエンタープライズ・デプロイメントに統合するための大まかな手順を示しています。

表18-1 Oracle Identity Management 11gとの統合手順

手順

説明

詳細

Webゲート・エージェントの登録

RREGツールを使用したWebゲート・エージェントの登録

第18.3.3項「Webゲート・エージェントの登録」

Webゲートのインストールと構成

Oracle HTTPサーバーがすでにインストールされている各WEBHOSTマシンにWebゲートをインストールします。

第18.3.4項「Webゲートの設定」

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

構成ファイルのバックアップ、Oracle Access Manager IDアサーション・プロバイダの設定およびプロバイダの順序設定によって、WebLogic Server認証プロバイダを設定します。

第18.3.6項「WebLogic Server認証プロバイダの設定」

アイデンティティ・ストアとOracle Internet Directoryまたは他の外部LDAP認証プロバイダと再関連付けします。

Oracle Internet Directory、Oracle Virtual Directoryまたはサード・パーティのLDAP認証プロバイダをドメインのアイデンティティ・ストアとして構成します。weblogic_ecm管理ユーザーを追加して、残りのエンタープライズ・デプロイメント・トポロジの設定に使用します。

第18.2項「アイデンティティ・ストアと外部LDAP認証プロバイダの再関連付け」

18.2 アイデンティティ・ストアと外部LDAP認証プロバイダの再関連付け

次の項では、Oracle WebLogic Serverにデフォルトで組み込まれているLDAPストアのアイデンティティ・ストアをOracle Internet Directory、Oracle Virtual Directoryまたはサード・パーティの外部LDAP認証プロバイダに再関連付けする方法について説明します。

- 第18.2.1項「構成ファイルのバックアップ」

- 第18.2.2項「LDAP認証プロバイダの作成」

- 第18.2.3項「プロバイダの順序の設定」

- 第18.2.4項「LDAPアイデンティティ・ストアへのWebLogic Server管理者の移動」

- 第18.2.5項「新しいアイデンティティ・ストアのImagingセキュリティの再設定」

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

念のため、LDAP認証プロバイダを作成する前に、まず関連する構成ファイルをバックアップしておきます。

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

管理サーバーのboot.propertiesファイルもバックアップします。

ASERVER_HOME/servers/AdminServer/security/boot.properties

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

18.2.2 LDAP認証プロバイダの作成

Oracle WebLogic Server管理コンソールを使用して、適切なオーセンティケータを設定します。

LDAP認証プロバイダを作成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左のナビゲーション・バーにある「セキュリティ・レルム」リンクをクリックします。

3. myrealmデフォルト・レルム・エントリをクリックして構成します。

4. このレルムにある「プロバイダ」タブを開きます。

5. このレルム用に構成したDefaultAuthenticatorプロバイダがあることを確認します。

6. 「ロックして編集」をクリックします。

7. 「新規」ボタンをクリックし、新しいプロバイダを追加します。

8. Oracle Internet Directory用のプロバイダの名前を入力します(OIDAuthenticatorなど)。

9. オーセンティケータのリストから「OracleInternetDirectoryAuthenticator」タイプを選択します。

10. 「OK」をクリックします。

11. 「プロバイダ」画面で、新しく作成したオーセンティケータをクリックします。

12. 「制御フラグ」を「SUFFICIENT」に設定します。
このフラグは、この認証プロバイダによって正常に認証されたユーザーは、その認証を受け入れたうえで、他の認証プロバイダを呼び出さないようにすることを示しています。認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。以降のすべてのオーセンティケータの制御フラグも「SUFFICIENT」に設定されていることを確認してください。特にDefaultAuthenticatorを確認し、その制御フラグを「SUFFICIENT」に設定します。

13. 「保存」をクリックしてこの設定を保存します。

14. 「プロバイダ固有」タブを開き、LDAPサーバーの詳細情報を入力します。

15. 次の表に示すように、使用しているLDAPサーバーに固有の詳細情報を入力します。

パラメータ

値

値の説明

ホスト

例: oid.example.com

LDAPサーバーのサーバーID。

ポート

例: 636

LDAPサーバーのポート番号。

プリンシパル

例: cn=orcladmin

LDAPサーバーへの接続に使用されるLDAPユーザーのDN。

資格証明

なし

LDAPサーバーへの接続に使用されるパスワード。

SSL有効

チェック済

LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。

ユーザー・ベースDN

例: cn=Users,dc=us, dc=example,dc=com

ユーザーが開始時に使用するDNを指定します。

グループ・ベースDN

例: cn=Groups,dc=us, dc=example,dc=com

ご使用のGroupsノードを指すDNを指定します。

取得したユーザー名をプリンシパルとして使用する

チェック済

オンにする必要があります。

「保存」をクリックします。

16. 「変更のアクティブ化」をクリックして変更を伝播します。

18.2.3 プロバイダの順序の設定

Oracle Internet Directoryオーセンティケータおよびデフォルト・オーセンティケータを並べ替えて、それぞれのオーセンティケータの制御フラグが次のように設定されていることを確認します。

- Oracle Internet Directory LDAPオーセンティケータ: SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

プロバイダの順序を設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. 「並替え」をクリックし、Oracle Internet Directoryオーセンティケータおよびデフォルト・オーセンティケータの制御フラグが次のように設定されていることを確認します。

- Oracle Internet Directory LDAPオーセンティケータ: SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

注意:
認証プロバイダがSUFFICIENTとして設定されていないと、Enterprise Captureの認証は正しく機能しません。

5. 「保存」をクリックします。

6. 「変更のアクティブ化」をクリックして、変更を伝播します。

7. 第10.3項「管理サーバーの再起動」の説明に従って管理サーバーを再起動し、ドメインのすべての管理対象サーバーも再起動します。
管理対象サーバーを再起動するには、管理対象サーバーをすべて停止してから管理サーバーを再起動し、その後、管理対象サーバーを起動します。

18.2.4 LDAPアイデンティティ・ストアへのWebLogic Server管理者の移動

この項では、Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジでOracle WebCenter ContentのWebLogic Serverドメインを管理するための、新規の管理ユーザーおよび管理グループのプロビジョニングの詳細について説明します。この項で説明するタスクは次のとおりです。

- 第18.2.4.1項「LDAPディレクトリへの管理ユーザーと管理グループのプロビジョニング」

- 第18.2.4.2項「管理ロールの管理グループへの割当て」

- 第18.2.4.3項「boot.propertiesファイルの更新およびシステムの再起動」

18.2.4.1 LDAPディレクトリへの管理ユーザーと管理グループのプロビジョニング

この項の冒頭で述べたように、複数のWebLogic Serverドメインのユーザーおよびグループは、中央のLDAPユーザー・ストアにプロビジョニングできます。そのような場合、あるWebLogic Server管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。このような状況は好ましくありません。このような状況にならないようにするために、プロビジョニングされるユーザーおよびグループには、ディレクトリ・ツリー内で一意の識別名を付与しておく必要があります。エンタープライズ・デプロイメント・トポロジ全体の設定とテストが終了したら、各アプリケーション用の適切なロールを使用して別のシステム管理者を設定してもかまいません。

Oracle WebCenter Content WebLogic Serverドメインの設定時に、次のDNを使用してweblogic_ecmという新しいシステム管理者をLDAPアイデンティティ・ストアにプロビジョニングします。

- 管理ユーザーDN:

cn=weblogic_ecm,cn=Users,dc=us,dc=example,dc=com

- 管理グループDN:

cn=ECM Administrators,cn=Groups,dc=us,dc=example,dc=com

管理ユーザーおよび管理グループをOracle Internet Directoryにプロビジョニングする手順は次のとおりです。

1. 次に示す内容を指定してadmin_user.ldifという名前のLDIFファイルを作成し、保存します。

dn: cn=weblogic_ecm, cn=Users, dc=us, dc=example, dc=com
orclsamaccountname: weblogic_ecm
givenname: weblogic_ecm
sn: weblogic_ecm
userpassword: password
mail: weblogic_ecm
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
uid: weblogic_ecm
cn: weblogic_ecm
description: Admin User for the Oracle WebCenter Content Domain

2. ORACLE_HOME/binディレクトリにあるOracle Internet Directoryホストのldapaddコマンドを実行して、Oracle Internet Directory内のユーザーをプロビジョニングします。

注意:
ここで使用するOracleホームは、Oracle Internet Directoryが存在するOracle Identity ManagementインストールのOracleホームです。

例(1行ですべて指定):

ORACLE_HOME/bin/ldapadd -h oid.example.com -p 389 -D "cn=orcladmin" -w password -c -v -f PATH/admin_user.ldif

3. 次に示す内容を指定してadmin_group.ldifという名前のLDIFファイルを作成し、保存します。

dn: cn=ECM Administrators, cn=Groups, dc=us, dc=example, dc=com
displayname: ECM Administrators
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_ecm, cn=Users, dc=us, dc=example, dc=com
cn: ECM Administrators
description: Administrators Group for the Oracle WebCenter Content Domain

4. ORACLE_HOME/binディレクトリにあるOracle Internet Directoryホストのldapaddコマンドを実行して、Oracle Internet Directory内のグループをプロビジョニングします(1行ですべて指定)。

ORACLE_HOME/bin/ldapadd -h oid.example.com -p 389 -D "cn=orcladmin"  -w password -c -v -f PATH/admin_group.ldif_file

5. 次に示す内容を指定してadministrators_group.ldifという名前のLDIFファイルを作成し、保存します。

dn: cn=Administrators, cn=Groups, dc=us, dc=example, dc=com
displayname: Default WLS Administrators
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
cn: Administrators
description: WL Administrators Group

注意:
管理グループは、Oracle Internet Directoryに存在しない場合にのみ作成してください。

6. ORACLE_HOME/binディレクトリにあるOracle Internet Directoryホストのldapaddコマンドを実行して、Oracle Internet Directoryに管理グループをプロビジョニングします。

ORACLE_HOME/bin/ldapadd -h oid.example.com -p 389 -D "cn=orcladmin" -w password -c -v -f PATH/administrators_group.ldif

7. 次に示す内容を指定してmodify_administrators_group.ldifという名前のLDIFファイルを作成し、保存します。

dn: cn=Administrators, cn=Groups, dc=us, dc=example, dc=com
changetype: modify
add: uniqueMember
uniqueMember: cn=ECM Administrators, cn=Groups, dc=us, dc=example, dc=com

8. ORACLE_HOME/binディレクトリにあるOracle Internet Directoryホストのldapmodifyコマンドを実行して、Oracle Internet Directoryの管理グループを変更します。

ORACLE_HOME/bin/ldapmodify -h oid.example.com -p 389 -D "cn=orcladmin" -w password -c -v -f PATH/modify_administrators_group.ldif

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

Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内で、グループに管理ロールを割り当てる必要があります。これにより、そのグループに属するすべてのユーザーをそのドメインの管理者にできます。

管理ロールを管理グループに割り当てる手順は次のとおりです。

1. WebLogic Serverの管理サーバー・コンソールにログインします。

2. 左側のナビゲーション・ツリーで「セキュリティ・レルム」をクリックします。

3. 「セキュリティ・レルムのサマリー」ページで、「レルム」表の下の「myrealm」をクリックします。

4. myrealmの「設定」ページで、「ロールとポリシー」タブを開きます。

5. 「レルム・ロール」ページの表「ロール」の「グローバル・ロール」エントリを開きます。これにより、ロールのエントリが表示されます。「ロール」リンクをクリックすると、「グローバル・ロール」ページが開きます。

6. 「グローバル・ロール」ページで、「管理」ロールをクリックして「グローバル・ロールの編集」ページを開きます。

1. 「グローバル・ロールの編集」ページで、「ロール条件」表の下の「条件の追加」ボタンをクリックします。

2. 「述部の選択」ページで、述部のドロップダウン・リストから「グループ」を選択して、「次へ」をクリックします。

3. 「引数の編集」ページで、グループ引数フィールドのECM管理者を指定し、「追加」をクリックします。

7. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。

8. この時点で、「ロール条件」表には、ECM Administrators Groupというエントリが表示されます。

9. 「保存」をクリックして、Admin RoleをECM Administrators Groupに追加します。

10. Webブラウザを使用して管理コンソールを開き、変更が正しく行われたことを確認します。weblogic_ecmユーザーの資格証明を使用してログインします。

注意:
Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジの各Oracleアプリケーションには、あらかじめ定義されたロールや管理目的および監視目的で定義されたグループが存在する可能性があります。デフォルトでは、Administratorsグループでこれらの作業ができるようになっています。ただし、このグループは広範になりすぎている可能性もあります。たとえば、Oracle WebCenter Contentが稼動しているWebLogic Serverドメインの管理者がOracle SOA Suiteの管理者を兼務するのは、望ましくないとも考えられます。そのため、この項で提案しているとおり、ECM Administratorsなどのより詳細なグループを作成することが望ましいと思われます。様々なアプリケーションでECM Administratorsグループが各種のシステムを管理できるようにするには、そのグループに必要なロールを追加する必要があります。たとえば、SOA Worklistappの管理のためには、SOAAdminロールを追加します。それぞれのケースで必要なロールについては、各コンポーネントの固有のロールを参照してください。

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

管理サーバーのboot.propertiesファイルをweblogic_ecm (Oracle Internet Directoryで作成したWebLogic Server管理ユーザー)で更新する必要があります。

boot.propertiesファイルを更新する手順は次のとおりです。

1. WCCHOST1で、次のディレクトリに移動します。

cd ASERVER_HOME/servers/AdminServer/security

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

2. 既存のboot.propertiesファイルの名前を変更します。

mv boot.properties boot.properties.backup

3. テキスト・エディタを使用して、セキュリティ・ディレクトリにboot.propertiesというファイルを作成します。次の行をファイルに入力します。

username=weblogic_ecm
password=password

4. ファイルを保存します。

5. 第10.3項「管理サーバーの再起動」の説明に従って管理サーバーを再起動します。

18.2.5 新しいアイデンティティ・ストアのImagingセキュリティの再設定

Imaging管理対象サーバーを構成した後でLDAPプロバイダを変更した場合は、Imagingセキュリティ表のグローバル・ユーザーID (GUID)は無効になります。Imagingは、外部LDAPプロバイダからGUIDをキャッシュしてローカルのセキュリティ表に格納し、そのIDを認証に使用します。WLSTコマンドまたはOracle Enterprise Manager Fusion Middleware Controlを使用して、Imagingセキュリティ表のGUID値をリフレッシュできます。

両方のLDAPプロバイダに存在するユーザーおよびグループに対してのみ、GUIDがリフレッシュされます。以前のLDAPからユーザーおよびグループに割り当てられたImaging権限は、新しいLDAPに一致するユーザーおよびグループにリフレッシュされます。ユーザーやグループが新しいLDAPプロバイダのユーザーやグループに一致しない場合、refreshIPMSecurityはそのユーザーやグループを無視します。

注意:
リフレッシュ中、対応する識別情報が見つからないユーザーまたはグループは無視されます。セキュリティに変更を加えると、無効なユーザーまたはグループがImagingデータベースから削除されます。

18.2.5.1 WLSTを使用してImagingセキュリティ表でGUID値をリフレッシュ

コマンド・ラインからGUID値をリフレッシュする場合は、Oracle WebLogic Scripting Tool (WLST)を使用できます。

WLSTを使用してImagingセキュリティ表のGUID値をリフレッシュするには、次の手順を実行します。

1. 第8.4.3項「WCCHOST1での管理サーバーの起動」の説明に従って、Oracle WebLogic Serverドメインの管理サーバーを起動します。

2. 管理サーバーが実行されているWCCHOST1にログインします。

3. Oracle WebCenter Contentのホーム・ディレクトリMW_HOME/WCC_ORACLE_HOMEに移動します。

4. WLSTを呼び出します。

cd common/bin
./wlst.sh

5. Imaging管理対象サーバーに接続します。

wls:/offline> connect()
Please enter your username :weblogic_ecm
Please enter your password : XXXXXXXXXXXXX
Please enter your server URL [t3://localhost:7001]
: t3://WCCHOST1VHN2:16000
Connecting to t3://WCCHOST1VHN2:16000 with userid weblogic_ecm ...
Successfully connected to Managed Server 'WLS_IMG1' that belongs to domain
'domainName'.

Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.

wls:/domainName/serverConfig> listIPMConfig()   <This is just to check
that the connection is to the right Imaging server>

wls:/domainName/serverConfig>
refreshIPMSecurity()  <This is the command that will refresh the GUIDs in the
Security tables.>

wls:/domainName/serverConfig> exit()

6. Imagingにログインして、ユーザーおよびグループのセキュリティを確認します。

18.2.5.2 Fusion Middleware Controlを使用してImagingセキュリティ表のGUID値をリフレッシュ

MBeanを介してGUID値をリフレッシュする場合は、Fusion Middleware ControlのシステムMBeanブラウザを使用できます。

Fusion Middleware Controlを使用してImagingセキュリティ表のGUID値をリフレッシュするには、次の手順を実行します。

1. WCCdomainのOracle Enterprise Manager Fusion Middleware Controlにログインします。

http://ADMINVHN:7001/em

2. 左側のナビゲーション・ツリーでWebLogicドメイン、Oracle WebCenter Contentドメイン・フォルダ、IMG_Clusterの順に展開し、WLS_IMG1などImagingサーバーの名前を展開します。

3. 右側で、「WebLogic Server」ドロップダウン・メニューをクリックし、「システムMBeanブラウザ」を選択します。

4. 「システムMBeanブラウザ」ナビゲーション・ツリーで、「アプリケーション定義のMBean」、oracle.imaging、「サーバー: WLS_IMG1」、「cmd」の順に展開し、「cmd」をクリックします。

5. 「操作」タブの右側で「refreshIPMSecurity」をクリックします。

6. 「起動」ボタンをクリックします。

7. Imagingにログインして、ユーザーおよびグループのセキュリティを確認します。

18.2.6 Enterprise Captureロールを持つシステム管理者のLDAPへの追加

LDAPと統合したシステムでは、Enterprise Capture管理者ロールを実行できるように、Oracle Enterprise Captureロールを新しいシステム管理者ユーザー(weblogic_ecm)に割り当てる必要があります。

Enterprise Captureロールを持つシステム管理者をLDAPに追加する手順は次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 左側で、「WebLogicドメイン」を開きます。

3. ドメイン名を右クリックして、「セキュリティ」→「アプリケーション・ロール」の順に選択します。
「アプリケーション・ロール」ページが開きます。

4. 「アプリケーション・ストライプ」フィールドで、ドロップダウン・リストから「capture」を選択し、検索アイコンをクリックします。
検索を実行すると、「キャプチャ・ユーザー」、「キャプチャ・ワークスペース・マネージャ」および「キャプチャ・ワークスペース参照者」のロールが表に移入されます。

5. CaptureWorkspaceManagerロールを編集し、weblogic_ecmをこのロールに追加します。

6. CaptureUserロールを編集し、weblogic_ecmをこのロールに追加すると、CaptureWorkspaceManagerおよびCaptureUserロールの両方が含まれるようになります。

18.3 Oracle Access Manager 11gとの統合

この項では、Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのシングル・サインオン・ソリューションとしてOracle Access Manager 11gを設定する方法について説明します。この章には次の項目があります。

- 第18.3.1項「Oracle Access Managerの統合の概要」

- 第18.3.2項「Oracle Access Managerの前提条件」

- 第18.3.3項「Webゲート・エージェントの登録」

- 第18.3.4項「Webゲートの設定」

- 第18.3.5項「OAM Webゲート登録から生成されたファイルおよびアーティファクトのWebゲート・インスタンスの場所へのコピー」

- 第18.3.6項「WebLogic Server認証プロバイダの設定」

18.3.1 Oracle Access Manager統合の概要

この項では、既存のOracle Access Manager 11gインストールおよび基礎となるディレクトリ・サービスとしてOracle Internet Directoryを使用して、Oracle WebCenter Contentのインストールを構成する手順について説明します。Oracle Access Managerインストールのインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

注意:
このガイドに記載されているOracle WebCenter Contentエンタープライズ・デプロイメント・トポロジでは、Oracle WebCenter Contentシステムおよびシングル・サインオン・システムの両方が同じネットワーク・ドメイン(example.com)に存在する状態で、シングル・サインオン構成を使用します。マルチドメイン構成については、『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service管理者ガイド』のOAMポリシー・モデル、シングル・サインオンの概要に関する項で必要な構成手順を参照してください。

18.3.2 Oracle Access Managerの前提条件

Oracle Access Managerの設定では、Oracle Access Manager 11gがインストールされていることを前提とします。Oracle Access Managerインストールのインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。この設定には、ディレクトリ・サービスとしてOracle Internet Directoryが含まれます。

また、Oracle Access Managerインストールには、Webゲートを使用するように構成された独自のWebサーバーが必要です。

18.3.3 Webゲート・エージェントの登録

この項では、Oracle Access ManagerにWebゲート・エージェントを登録する手順および各WEBHOSTマシンでのWebゲート・エージェント・インスタンスの使用について説明します。

- 第18.3.3.1項「RREGツールの解凍および使用」

- 第18.3.3.2項「Oracle Access Manager 11gリクエスト・ファイルの更新」

- 第18.3.3.3項「oamregツールの実行」

- 第18.3.3.4項「基本認証スキームを使用するためのinspection.wsilリソースの変更」

- 第18.3.3.5項「Cookieを使用しない基本スキームをサポートするためのOracle Access Manager 11gサーバー構成の更新」

18.3.3.1 RREGツールの解凍および使用

RREGツールは、Oracle Access Manager 11gインストールに付属しています。見つからない場合は、各Oracle Identity Managementマシンで解凍します。

RREGツールを解凍する手順は次のとおりです。

1. Oracle Access Managerのインストールおよび構成後、次の場所に移動します。

IDM_Home/oam/server/rreg/client

2. コマンド・ラインから、次の例のとおり、gunzipを使用してRREG.tar.gzファイルを解凍します。

gunzip RREG.tar.gz

tar -xzvf RREG.tar

3. 必要に応じて、RREG_HOME/bin/oamreg.shスクリプトを開き、設定に合せてOAM_REG_HOMEパラメータを変更します。

RREG構成ツールは、WebCenter ContentリソースをOracle Access Managerシステムに登録する手段を提供します。

これらのリソースをOracle Access Managerシステムに追加する必要があります。

/adfAuthentication
/imaging/faces
/ibr/adfAuthentication
/em
/console
/DefaultToDoTaskFlow
/sdpmessaging/userprefs-ui
/integration/worklistapp
/workflow/sdpmessagingsca-ui-worklist
/soa/composer
/soa-infra
/soa-infra/deployer
/soa-infra/events/edn-db-log
/soa-infra/cluster/info
/dc-console/adfAuthentication
/dc-client/adfAuthentication
/wcc/adfAuthentication

パブリック・リソースのリストは次のとおりです。

/cs
/_ocsh
/imaging
/_dav
/soa-infra/directWSDL
/dc-console
/dc-client
/wcc

除外されるリソースのリストは次のとおりです。

/idcnativews
/imaging/ws
/imaging/lib
/cs/common/idcapplet.jar
/cs/images
/wsm-pm
/soa-infra/services
/ucs/messaging/webservice
/axf-ws

注意:
これらのリソース・リストは、Oracle Access Manager 11.1.2.1.0に適用されます。Oracle Access Manager 11.1.2.2.0を使用している場合は、除外されたリソース・リストに/dc-clientを移動する必要があります。

18.3.3.2 Oracle Access Manager 11gリクエスト・ファイルの更新

RREG_Home/inputディレクトリには、OAM11gRequest.xmlという名前のテンプレート・ファイルがあります。このファイルをWCCOAM11gRequest.xmlにコピーし、コピーしたファイルを編集してOracle WebCenter Contentインストールのポリシーを作成します。

注意:
OAM_HOST、OAM_ADMINSERVER_PORT、
WCC_EDG_AGENTおよびWCC_EDG_DOMAINを、インストールにおけるそれぞれの値に置換します。

編集後のファイルは次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<OAM11GRegRequest>

<serverAddress>http://OAM_HOST:OAM_ADMINSERVER_PORT</serverAddress>
<agentName>WCC_EDG_AGENT</agentName>
<applicationDomain>WCC_EDG_DOMAIN</applicationDomain>
<cachePragmaHeader>private</cachePragmaHeader>
<cacheControlHeader>private</cacheControlHeader>
<ipValidation>1</ipValidation>
<ValList ListName="ipValidationExceptions">
<ValListMember Value="10.1.1.1"/>
</ValList>
<logOutUrls>
<url>/oamsso/logout.html</url>
</logOutUrls>
<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>/dc-client</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>/axf-ws</resource>
</excludedResourcesList>

<userDefinedParameters>
<userDefinedParam>
<name>filterOAMAuthnCookie</name>
<value>false</value>
</userDefinedParam>
</userDefinedParameters>

</OAM11GRegRequest>

注意:

- このファイルの内容は、Oracle Access Manager 11.1.2.1.0に適用されます。Oracle Access Manager 11.1.2.2.0を使用している場合は、除外されたリソース・リストに/dc-clientを移動する必要があります。

- resource_name/.../*のリソースは、登録時に自動追加されます。

- このガイドでは、Oracle Access Manager 11g (11.1.1.2)以降のリクエスト・ファイルの検証フィールドのエントリについて説明します。検証例外リストは、Oracle Access Manager 11gより前のバージョンでは別の方法で定義されます。以前のバージョンでは、前述のテキスト内の<ValList>エントリを使用するかわりに、</publicResourcesList>エントリの後で次の構文を使用します。

<userDefinedParameters>
<userDefinedParam>
<name>ipValidationExceptions</name>
<value>10.1.1.1</value>
</userDefinedParam>
</userDefinedParameters>

検証例外の追加の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

18.3.3.3 oamregツールの実行

次のコマンドを使用し、oamregツールを実行します。

$ ./RREG_Home/bin/oamreg.sh inband input/WCCOAM11gRequest.xml

実行すると次のように表示されます。

------------------------------------------------
Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: MW_HOME/iam/oam/server/rreg/client/rreg/input/WCCOAM11GRequest.xml
Enter admin username:oamadmin
Username: your_oamadmin_user
Enter admin password: your_oamadmin_password
Do you want to enter a Webgate password?(y/n): y
Enter webgate password: your_webgate_password
Enter webgate password again: your_webgate_password
Password accepted. Proceeding to register..
Apr 18, 2011 12:22:36 PM oracle.security.am.engines.rreg.client.handlers.request.OAM11GRequestHandler getWebgatePassword
INFO: Passwords matched and accepted.
Do you want to import an URIs file?(y/n): n

----------------------------------------
Request summary:
OAM11G Agent Name:WCC_EDG_AGENT
URL String:WCC_EDG_AGENT
Registering in Mode:inband
Your registration request is being sent to the Admin server at: http://oamserver.example.com:7001
----------------------------------------

Inband registration process completed successfully! Output artifacts are created in the output folder.

18.3.3.4 基本認証スキームを使用するためのinspection.wsilリソースの変更

デフォルトでは、inspection.wsilリソースは、フォーム認証スキームを使用するように設定されています。このワークフローとOracle WebCenter Content: Imagingの間の接続が機能するようにするには、次に示すように、このリソースが基本認証スキームを使用するように各WEBHOSTマシンで更新する必要があります。

基本認証スキームを使用するようにinspection.wsilリソースを変更する手順は次のとおりです。

1. http://OAM_HOST:OAM_ADMINSERVER_PORT/oamconsoleにあるOracle Access Managerコンソールにログインします。

2. 左側のナビゲーション・ツリーを使用して、「アプリケーション・ドメイン」をクリックし、アプリケーション・ドメイン名をクリックして、作成したアプリケーション・ドメイン(WCC_EDG_DOMAIN)に移動します。

3. 使用しているアプリケーション・ドメイン名を開きます。

4. 「認証ポリシー」を開きます。

5. ナビゲーション・ツリーの上にあるツール・バーの「作成」ボタンをクリックします。

1. ポリシーの名前(New Basic Policyなど)を入力します。

2. 認証スキームとして「BasicSessionlessScheme」を選択します。

3. 「適用」をクリックします。
ナビゲーション・ツリーの「認証ポリシー」の下に新しく作成されたポリシーが表示されます。

4. 新規に作成したポリシーを開きます。

5. 「リソース」ペインで、右側にある「追加」アイコン(+印付き)をクリックして、inspection.wsilおよびinspection.wsil/.../*のリソースを追加します。

6. 「適用」をクリックします。

6. ナビゲーション・ツリー上の「リフレッシュ」アイコンをクリックし、新しい認証ポリシーを確認します(認証ポリシーをクリックしてinspection.wsilおよびinspection.wsil/.../*のリソースが追加されたことを確認します)。

注意:
新規のユーザーに対しては、必ず新規の資格証明を作成してください。詳細は、第13.5.13項「BPEL CSF資格証明の構成」を参照してください。(このマニュアルでは、SSOの例としてweblogic_ecmユーザーを使用しています。)

18.3.3.5 Cookieを使用しない基本スキームをサポートするためのOracle Access Manager 11gサーバー構成の更新

各OAMHOSTマシンで、Oracle Access Manager 11g構成のNoUniqueSessionsFor10gAgentsパラメータをtrueに設定する必要があります。これを行うには、IDM_Home/oam/server/config/ディレクトリにあるoam-config.xmlファイルを編集して、次の行を変更します。

<Setting Name="NoUniqueSessionsFor10gAgents" Type="xsd:string">false</Setting>

ファイルのコピー先

<Setting Name="NoUniqueSessionsFor10gAgents" Type="xsd:string">true</Setting>

ファイルを保存し、Oracle Identity ManagementシステムのOracle Access Managerサーバーを再起動して、変更を有効にします。

18.3.4 Webゲートの設定

Oracle HTTP Serverがすでにインストールされている各WEBHOSTマシン上でWebゲートを設定する必要があります。

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

- 第18.3.4.1項「GCCライブラリのインストール」

- 第18.3.4.2項「Webゲートのインストール」

- 第18.3.4.3項「インストール後の手順」

18.3.4.1 GCCライブラリのインストール

Webゲートをインストールする前に、各WEBHOSTマシンにサード・パーティGCCライブラリをダウンロードおよびインストールする必要があります。適切なGCCライブラリを次のサードパーティWebサイトからダウンロードできます。

http://gcc.gnu.org

注意:
このガイドの設定では、Oracle Identity and Access Management 11g (11.1.1.6.0)を使用します。バージョン11.1.1.7.0以降を使用する場合、サード・パーティのGCCライブラリは必要ありません。

32ビットのLinuxの場合、必要なライブラリはバージョン番号3.3.2のlibgcc_s.so.1およびlibstdc++.so.5になります。表18-2は、サード・パーティのGCCライブラリでLinuxおよびSolarisオペレーティング・システムに対応するバージョンを示しています。

表18-2 LinuxおよびSolarisシステムのGCCサードパーティ製ライブラリのバージョン

オペレーティング・システム

アーキテクチャ

GCCライブラリ

必要なライブラリ・バージョン

Linux 32ビット

x86

libgcc_s.so.1

libstdc++.so.5

3.3.2

Linux 64ビット

x64

libgcc_s.so.1

libstdc++.so.6

3.4.6

Solaris 64ビット

SPARC

libgcc_s.so.1

libstdc++.so.5

3.3.2

18.3.4.2 Webゲートのインストール

この項では、Webゲートをインストールする手順を説明します。Webゲートを各WEBHOSTマシンにインストールする必要があります。

18.3.4.2.1 インストーラの起動

Oracle HTTP Server 11g WebGate for Oracle Access Managerのインストーラ・プログラムはwebgate.zipファイルに含まれています。

インストール・ウィザードを起動する手順は次のとおりです。

1. webgate.zipファイルの内容をディレクトリに展開します。デフォルトでは、このディレクトリはwebgateと名前が付けられています。

2. webgateディレクトリの下のDisk1サブディレクトリに移動します。

3. MW_HOME環境変数をOracle Web層のMiddlewareホームに設定します。

export MW_HOME=/u02/oracle/products/fmw_home

4. 次のコマンドを使用し、インストーラを開始します。

$ ./runInstaller -jreLoc WT_ORACLE_HOME/jdk

コマンドで、WT_ORACLE_HOME=/u02/oracle/products/fmw_home/web_homeと入力します。

注意:
Oracle HTTP Serverをインストールすると、ミドルウェア・ホーム・ディレクトリの下にjdkディレクトリが作成されます。インストーラを起動するときに、このJDKの中にあるJREフォルダの絶対パスを入力する必要があります。

インストーラが起動すると、「ようこそ」画面が開きます。

18.3.4.2.2 インストール・フローおよび手順

インストール画面の詳細なヘルプが必要な場合は、「ヘルプ」をクリックしてオンライン・ヘルプにアクセスします。

Oracle HTTP Server 11g WebGate for Oracle Access Managerをインストールする手順:

1. 「ようこそ」画面で、「次へ」をクリックします。

2. 「前提条件のチェック」画面で、「次へ」をクリックします。

3. 「インストール場所の指定」画面で、次のように、「Oracleミドルウェア・ホーム」および「Oracleホーム・ディレクトリ」の場所を指定します。

- MW_HOME

- webgate_home

注意:
MiddleWareホームには、Oracle Web層のOracleホームがあります。

「次へ」をクリックします。

4. GCCライブラリの指定画面で、GCCライブラリが含まれるディレクトリを指定し、「参照」をクリックして、使用しているローカル・コンピュータ上のライブラリの場所に移動し(第18.3.4.1項「GCCライブラリのインストール」を参照)、「次へ」をクリックします。

注意:
この手順にWebゲート・バージョン11.1.1.7.0以降は不要です。

5. 「インストール・サマリー」画面で、画面に表示される情報を確認し、「インストール」をクリックしてインストールを開始します。

6. 「インストールの進行状況」画面で、ファイルおよびディレクトリに対して正しい権限を設定するために、ORACLE_HOME/oracleRoot.shスクリプトの実行を求められる場合があります。
「次へ」をクリックして続行します。

7. 「インストール完了」画面で、「終了」をクリックしてインストーラを終了します。

18.3.4.3 インストール後の手順

Oracle HTTP Server 11g WebGate for Oracle Access Managerのインストール後、各WEBHOSTマシンで次の手順を完了します。

インストール後の手順は次のとおりです。

1. WebGateのOracleホームの下にある次のディレクトリに移動します。

$ cd WEBGATE_ORACLE_HOME/webgate/ohs/tools/deploy

参照トポロジで、WEBGATE_ORACLE_HOMEは/u02/oracle/products/fmw_home/webgate_homeディレクトリです。このディレクトリは、Oracle HTTP Server Webゲートをインストールし、WebゲートのOracleホームを作成した場所です。

2. コマンド・ラインで次のコマンドを実行し(1行で)、WEBGATE_ORACLE_HOMEディレクトリからWebゲート・インスタンスの場所にエージェントの必要な部分をコピーします。

$ ./deployWebGateInstance.sh -w /u02/oracle/config/webN/config/OHS/ohsN/
-oh WEBGATE_ORACLE_HOME

/u02/oracle/config/webN/config/OHS/ohsNディレクトリは、Oracle HTTP Serverのインスタンス・ホームになります(Nはインストールごとに付される連番で、1番目はWEBHOST1、2番目はWEBHOST2などとなります)。

注意:
Oracle HTTP Serverのインスタンス・ホームはOracle HTTP Serverの構成後に作成されます。

3. 次のコマンドを実行し、LD_LIBRARY_PATH変数にWT_ORACLE_HOME/libが含まれるようにします。

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/u02/oracle/products/fmw_home/web_home/lib

4. 現在の作業ディレクトリから1レベル上位のディレクトリに移動します。

$ cd WEBGATE_ORACLE_HOME/webgate/ohs/tools/setup/InstallTools

5. コマンド・ラインで次のコマンドを実行し(1行で)、WEBGATE_RACLE_HOMEディレクトリからWebゲート・インスタンスの場所(webgate.confに名前が変更されている)にapache_webgate.templateをコピーし、httpd.confファイルにwebgate.confの名前を追加する1行を追加して更新をかけます。

$ ./EditHttpConf -w /u02/oracle/config/webN/config/OHS/ohsN/ [-oh WEBGATE_ORACLE_HOME]
[-o output_file]

注意:
-oh WEBGATE_ORACLE_HOMEおよび-o output_fileパラメータはオプションです。

コマンド内のWEBGATE_ORACLE_HOMEは、Oracle Access Manager用のOracle HTTP Server Webゲートをインストールしたディレクトリです。このディレクトリはWebゲートのOracleホームです。例:

/u02/oracle/products/fmw_home/webgate_home

/u02/oracle/config/webN/config/OHS/ohsN/ディレクトリは、Oracle HTTP Serverのインスタンス・ホームになります(Nはインストールごとに付される連番で、1番目はWEBHOST1、2番目はWEBHOST2などとなります)。

output_fileの値は、ツールによって使用された一時出力ファイルの名前です。次の例を参照してください。

Edithttpconf.log

18.3.5 OAM Webゲート登録から生成されたファイルおよびアーティファクトのWebゲート・インスタンスの場所へのコピー

RREG_Home/output/WCC_EDG_AGENTに次の2つのファイルが生成されます。

- ObAccessClient.xml

- cwallet.sso

これらのファイルを、各WEBHOSTマシンのWebゲート・インスタンスの場所にコピーします。

scp ObAccessClient.xml oracle@WEBHOSTN:ORACLE_INSTANCE/config/OHS/ohsN/webgate/config/

scp cwallet.sso oracle@WEBHOSTN:ORACLE_INSTANCE/config/OHS/ohsN/webgate/config/

scpコマンドの、Nはインストールの連番で、たとえば、WEBHOST1は1、WEBHOST2は2です。

参照トポロジで、ORACLE_INSTANCEは/u02/oracle/config/web1または/u02/oracle/config/web2ディレクトリです。

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

この項では、第18.2.2項「LDAP認証プロバイダの作成」の手順に従ってLDAP認証プロバイダをすでに設定していることを前提としています。まだLDAP認証プロバイダを作成していない場合は、作成してからこの項の続きを実行してください。

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

- 第18.3.6.1項「構成ファイルのバックアップ」

- 第18.3.6.2項「Oracle Access Manager IDアサーション・プロバイダの設定」

- 第18.3.6.3項「プロバイダの順序の設定」

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

まず、次の関連する構成ファイルをバックアップします。

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fwmconfig/system-jazn-data.xml

参照トポロジで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

さらに、管理サーバー用にboot.propertiesファイルをバックアップします。

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

Oracle WebLogic Server管理コンソールを使用してOracle Access Manager IDアサーション・プロバイダを設定します。

Oracle Access Manager IDアサーション・プロバイダを設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. 「新規」をクリックし、ドロップダウン・メニューからアサータ・タイプ「OAMIdentityAsserter」を選択します。

5. アサータに名前(OAM ID Asserterなど)を付け、「OK」をクリックします。

6. 新しく追加したアサータをクリックし、Oracle Access Manager IDアサーション・プロバイダの構成画面を確認します。

7. 制御フラグを「必須」に設定します。

8. 「選択済み」タイプで「ObSSOCookie」および「OAM_REMOTE_USER」の2つのオプションを選択します。

9. 設定を保存し、「変更のアクティブ化」をクリックして、変更を伝播します。

10. 管理者としてOracle WebLogic Scripting Tool (WLST)にログインし、addOAMSSOProviderコマンドを実行します。

1. WLSTを起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

2. WCCDomain管理サーバーに接続して、addOAMSSOProviderコマンドを発行します。

wls:/offline> connect('weblogic_ecm', password,'ADMINVHN:7001')

Connecting to t3://ADMINVHN:7001 with userid weblogic_ecm ..

Successfully connected to Admin Server 'AdminServer' that belongs to domain 'WCCDomain'.

Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead.

wls:/WCCDomain/serverConfig> addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",logouturi="/oamsso/logout.html",autologinuri="/obrar.cgi")

Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.For more help, use help(domainRuntime)

wls:/WCCDomain/serverConfig> exit()

Exiting WebLogic Scripting Tool

18.3.6.3 プロバイダの順序の設定

WebLogic Server管理コンソールを使用してIDアサーション・プロバイダと認証プロバイダを設定します。

プロバイダの順序を設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. 各認証プロバイダの制御フラグが次のように設定されていることを確認することによって、Oracle Access Manager IDアサーション・プロバイダ、Oracle Internet Directory認証プロバイダおよびデフォルト認証プロバイダを並べ替えます。

- Oracle Access Manager IDアサーション・プロバイダ: REQUIRED

- Oracle Internet Directory認証プロバイダ: SUFFICIENT

- DefaultAuthenticator: SUFFICIENT

5. 「OK」をクリックします。

6. 「変更のアクティブ化」をクリックして、変更を伝播します。

7. 管理サーバーとすべての管理対象サーバーを再起動します。
nmKillコマンドまたは管理コンソールで管理サーバーを停止し、nmStartコマンドで起動します(第10.3項「管理サーバーの再起動」を参照)。

再起動の前に、管理コンソールを使用してドメイン内のすべての管理対象サーバーを停止します。続いて再起動後に、それらの管理対象サーバーを起動します。weblogic_ecmユーザーの資格証明を使用して管理コンソールにログインします。

18.4 ロード・バランサおよびSSOを介したアクセスの検証

(SSOのユーザー名およびパスワードを使用した)フロンドエンドでのシングル・サインオンを検証します。

- http://admin.example.com/console

- http://admin.example.com/em

- http://wcc.example.com/cs

- http://wcc.example.com/imaging

- https://wcc.example.com/dc-console

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

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、このガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

1. Oracle Web層をバックアップします。

1. opmnctlを使用してインスタンスを停止します。

/u02/oracle/config/webN/bin/opmnctl stopall

2. 次のコマンドをrootとして実行して、Oracle Web層のMiddlewareホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_home.tar $MW_HOME

3. 次のコマンドをrootとして実行して、Oracle Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE

4. 次のように、opmnctlを使用してインスタンスを起動します。

/u02/oracle/config/webN/bin/opmnctl startall

参照トポロジで、ORACLE_INSTANCEは/u02/oracle/config/web1または/u02/oracle/config/web2ディレクトリです。

2. WCCHOST1上の管理サーバーのドメイン・ディレクトリをバックアップします。バックアップを実行してドメイン構成を保存します。構成ファイルはすべて/u01/oracle/config/domains/WCCDomainディレクトリに存在しています。

tar -cvpf edgdomainback.tar /u01/oracle/config/domains/WCCDomain

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

この章では、トポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップなどがあります。

この章には次の項が含まれます:

- 第19.1項「Oracle WebCenter Contentトポロジの管理の概要」

- 第19.2項「Imagingの入力ファイルを最適化する戦略の定義」

- 第19.3項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジ内でのコンポジットおよびアーティファクトのデプロイ」

- 第19.4項「SOAインフラストラクチャ・データベースでの領域の管理」

- 第19.5項「Oracle WebCenter Content: ImagingのUMSドライバの構成」

- 第19.6項「Oracle WebCenter Contentトポロジのスケール・アップ」

- 第19.7項「Oracle WebCenter Contentトポロジのスケール・アウト」

- 第19.8項「管理サーバーの手動フェイルオーバーの検証」

- 第19.9項「Oracle WebCenter Contentエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」

- 第19.10項「Oracle DatabaseでのOPSSセキュリティ・ストアの保持」

- 第19.11項「SQLNet接続のタイムアウト防止」

- 第19.12項「Oracle WebCenter ContentとImagingサービスで使用するOracle Web Service Managerのセキュリティ・ポリシーの構成」

- 第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」

19.1 Oracle WebCenter Contentトポロジの管理の概要

Oracle WebCenter Contentエンタープライズ・デプロイメントを構成したら、この章の情報を使用してトポロジを管理できます。表19-1に、トポロジを管理するために実行できるタスクを示します。

表19-1 Oracle WebCenter Contentトポロジを管理するためのタスク

タスク

説明

詳細

Imagingクラスタにおいて高いパフォーマンス、スケーラビリティおよび高可用性を実現するためのImagingの構成

入力ファイルを最適化する戦略を定義します。

第19.2項「Imagingの入力ファイルを最適化する戦略の定義」

Imagingで使用するOracle SOA Suiteサブシステムの管理

SOAコンポジットをサーバーのアドレスにデプロイし、Oracle SOA Suiteインフラストラクチャ内の領域を管理し、UMSドライバを構成します。

第19.3項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジ内でのコンポジットおよびアーティファクトのデプロイ」

第19.4項「SOAインフラストラクチャ・データベースでの領域の管理」

第19.5項「Oracle WebCenter Content: ImagingのUMSドライバの構成」

スケール・アップまたはスケール・アウトによるトポロジの拡張

ノードに新しい管理対象サーバーを追加するか、または新しいノードを追加します。

第19.6項「Oracle WebCenter Contentトポロジのスケール・アップ」

第19.7項「Oracle WebCenter Contentトポロジのスケール・アウト」

構成の変更前後におけるトポロジのバックアップ

ディレクトリおよびファイルをバックアップし、構成の変更によって発生する障害から保護します。

第19.9項「Oracle WebCenter Contentエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行」

接続タイムアウトの防止

データベース接続がタイムアウトしないようにファイアウォールを構成します。

第19.11項「SQLNet接続のタイムアウト防止」

Oracle WebCenter ContentとOracle WebCenter Content: ImagingのWebサービスで使用するOracle Web Service Manager (Oracle WSM)のセキュリティ・ポリシーの構成

HTTP基本認証のかわりに適切なOracle WSMポリシーを適用します。

第19.12項「Oracle WebCenter ContentとImagingサービスで使用するOracle Web Service Managerのセキュリティ・ポリシーの構成」

問題のトラブルシューティング

トポロジの構成後に発生する可能性のある既知の問題の解決方法を実施します。

第19.13項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」

Oracle WebCenter Contentの管理の詳細は、次のドキュメントを参照してください。

- Oracle WebCenter Enterprise Captureの管理

- Oracle WebCenter Contentの管理

- Oracle Fusion Middleware Oracle WebCenter Content: Imagingの管理

- Oracle WebCenter Contentのマネージング

19.2 Imagingの入力ファイルを最適化する戦略の定義

入力ファイルは、入力エージェントがスケジュール設定および処理できる作業の最小単位です。Imagingクラスタにおいて最高のパフォーマンス、スケーラビリティ、および可用性を実現するために、いくつかの考慮事項があります。

- Imagingクラスタ内のすべてのマシンは、共通の入力ディレクトリを共有します。

- このディレクトリからの入力ファイルは、JMSキューを介してそれぞれのマシンに配信されます。

- このディレクトリをポーリングして新しいファイルを調べる間隔は構成可能です。

- 各マシンには、入力ファイルを処理する解析エージェントが複数あります。解析エージェントの数は、Imagingデプロイメント内で作成されたワーク・マネージャを使用して構成されます。

次のような場合に最適なパフォーマンスを実現できます。

- それぞれのImagingクラスタ・インスタンスに、ユーザー・インタフェースやWebサービスなどの他のImagingアクティビティのパフォーマンスを損ねることなく、ワーク・マネージャを介して構成された最適な最大数の解析エージェントがある場合。

- ドキュメントのインバウンド・フローは、最適な数のドキュメントを含む入力ファイルに分割されます。平均では、クラスタ内の解析エージェントごとに2つの入力ファイルをキューに格納する必要があります。

- クラスタ内で1台以上のマシンに障害が発生した場合、アクティブなマシンが入力ファイルの処理を続行します。障害が発生したマシンの入力ファイルは、サーバーが再起動するまで処理されません。入力ファイルを小さくすることで、マシンの障害によって大量のドキュメントが未処理の状態にならないようにします。

たとえば、2台のサーバーで1時間当たり10,000のインバウンド・ドキュメントが処理されるとします。サーバーごとに2つの解析エージェントを構成すると、全体的に適度なパフォーマンスが実現され、エージェントごとに2ドキュメント/秒でインジェストされます。2ドキュメント/秒の解析エージェントが4つある場合、8ドキュメント/秒(28,800ドキュメント/時)で処理されます。10,000ドキュメントの単一の入力ファイルは、1時間では処理できません(7,200ドキュメント/時で処理する単一の解析エージェントだとその処理を完了できまません)。ただし、その入力ファイルを8つに分割して1,250ドキュメントずつにすると、4つのすべての解析エージェントはフルに活用され、1時間内に10,000ドキュメントの処理が完了するようになります。また、一方のサーバーで障害が発生した場合、処理が正常に終了するまでもう一方のサーバーで解析エージェントに残っている処理を続行できます。

19.3 Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジ内でのコンポジットおよびアーティファクトのデプロイ

Imagingによって使用されているOracle SOA SuiteサブシステムにSOAコンポジットをデプロイする場合は、ロード・バランサのアドレス(wcc.example.com)ではなく、特定のサーバーのアドレスにデプロイします。ロード・バランサ・アドレスにデプロイするには、デプロイヤ・ノードから外部のロード・バランサ・アドレスへの直接接続が必要になることがあり、その接続のために、システムのファイアウォールで追加ポートを開く必要が生じる場合があります。

19.4 SOAインフラストラクチャ・データベースでの領域の管理

すべてのコンポジットでデータベースが頻繁に使用されるわけではありませんが、サービス・エンジンは大量のデータをCUBE_INSTANCEスキーマとMEDIATOR_INSTANCEスキーマで生成します。データベース領域が不足すると、SOAコンポジットが機能しなくなることがあります。Oracle Enterprise Manager Fusion Middleware Control(ダッシュボードなど)で、oracle.fabric.common.FabricInvocationExceptionのような一般的なエラーがないかどうか監視してください。Oracle SOA Suiteサーバーのログについても、次のようなエラーがないかどうか検索します。

Error Code: 1691
...
ORA-01691: unable to extend lob segment
SOAINFRA.SYS_LOB0000108469C00017$$ by 128 in tablespace SOAINFRA

これらのメッセージは、通常、データ・ファイルの追加や既存のファイルへの領域の追加を必要とする、データベースの領域の問題を示します。SOAデータベース管理者は、領域の追加で使用される拡張ポリシーとパラメータを決定する必要があります。また、古いコンポジット・インスタンスを消去してSOAインフラストラクチャ・データベースのサイズを縮小することもできます。Fusion Middleware Controlのこのような操作への使用は、ほとんどの場合、トランザクション・タイムアウトが発生するのでお薦めできません。

提供されるSQLパッケージに含まれている可能性のある操作の詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイドのSOAコンポジット・アプリケーションの管理とデプロイに関する項を参照してください。正しく消去するには、提供されているスクリプトを常に使用します。composite_dn表からのみ行を削除すると、Oracle SOA Suiteインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。

19.5 Oracle WebCenter Content: ImagingのUMSドライバの構成

UMSドライバの構成情報は、Oracle SOA Suiteクラスタに自動的には伝播されません。Oracle WebCenter Content: Imagingによって起動されるOracle SOA SuiteシステムがUMSを使用する場合、UMSドライバを構成する必要があります。

注意:
この手順が必要になるのは、Oracle WebCenter Content: Imagingが使用するOracle SOA SuiteシステムがUnified Messaging System (UMS)を使用している場合のみです。

ImagingのUMSドライバを構成する手順は次のとおりです。

1. UMSドライバの構成情報を、そのドライバを使用するエンタープライズ・デプロイメント・トポロジ内のすべてのサーバーに適用します。

2. サーバーの移行機能を使用すると、サーバーは別のノードのドメイン・ディレクトリに移動します。UMSドライバ構成は、フェイルオーバー・ノード内であらかじめ作成しておく必要があります。UMSドライバ構成ファイルの場所は次のとおりです。

/u02/oracle/config/domains/WCCDomain/servers/server_name/
tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml

コマンド内の*は、デプロイ中にOracle WebLogic Serverによってランダムに生成される3682yqなどのディレクトリ名を表しています。

フェイルオーバーに備えてファイルを作成するには、強制的にサーバー移行を実行してファイルをソース・ノードからコピーしてください。例:

1. WLS_IMG1のドライバをWCCHOST1内に構成します。

2. WCCHOST2へのWLS_IMG1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内のUMSドライバ構成のディレクトリ構造が、次のとおりであることを確認してください。

cd /u02/oracle/config/domains/WCCDomain/servers/server_name/
tmp/_WL_user/ums_driver_name/*/configuration

コマンド内の*は、デプロイ中にWLSによってランダムに生成される3682yqなどのディレクトリ名を表しています。

3. 次のコマンドをWCCHOST1で実行し、WCCHOST1からWCCHOST2にドライバ構成ファイルをリモート・コピーします

scp /u02/oracle/config/domains/WCCDomain/servers/server_name/
tmp/_WL_user/ums_driver_name/*/configuration/
driverconfig.xml oracle@WCCHOST2:/u02/oracle/config/domains/WCCDomain/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/

コマンド内の*は、デプロイ中にOracle WebLogic Serverによってランダムに生成される3682yqなどのディレクトリ名を表しています。

これまでに行った変更を有効にする(変更後の構成情報をドライバに読み取らせる)ためにドライバを再起動する必要があります。

ドライバを再起動する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. ナビゲーション・ツリーで「環境」ノードを開きます。

3. 「デプロイメント」をクリックします。

4. ドライバを選択します。

5. 「停止」→「作業完了時」をクリックし、操作を確定します。

6. ドライバの状態が「準備完了」に変化するまで待ちます(必要に応じて、管理コンソール・ページを更新します)。

7. ドライバをもう一度選択し、「起動」→「すべてのリクエストを処理」をクリックして、操作を確定します。

ドライバのプロパティが保持されていることを、Fusion Middleware Controlで確認します。

19.6 Oracle WebCenter Contentトポロジのスケール・アップ

トポロジのスケールアップとは、1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することです。必要なコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。このノードには、共有記憶域内にWebLogic ServerホームとMiddlewareホームが存在します。新しい管理対象サーバーを作成する場合は、このような既存のインストール(WebLogic Serverホーム、Middlewareホーム、ドメイン・ディレクトリなど)を使用します。WebLogic Serverのバイナリを新しい場所にインストールしたり、packとunpackを実行したりする必要はありません。

注意:
コンテンツ・サーバーを含む管理対象サーバーの場合、共有ドメイン・ディレクトリは動作しません。intradoc.cfgなどのドメイン内の特定のファイルは各ノードに固有だからです。ノード固有のファイルの問題を防ぐには、各Oracle WebCenter ContentおよびOracle WebCenter Content: Inbound Refinery管理対象サーバーにローカル(ノードごと)のドメイン・ディレクトリを使用します。

スケール・アップの手順は、トポロジのコンポーネントによって異なります。

- 第19.6.1項「WebCenter Contentのスケール・アップ手順」

- 第19.6.2項「Oracle WebCenter Content: Imagingのスケール・アップ手順」

- 第19.6.3項「Oracle WebCenter Enterprise Captureのスケール・アップ手順」

- 第19.6.4項「Oracle SOA Suiteのスケール・アップ手順」

19.6.1 WebCenter Contentのスケール・アップ手順

1つのドメイン、1つのノードに対して、Oracle Fusion MiddlewareがサポートするWebCenter Content管理対象サーバーは1つのみです。WebCenter Content管理対象サーバーを追加するには、第19.7.1項「WebCenter Contentのスケール・アウト手順」に従い、新しいノードにWebCenter Content管理対象サーバーを追加します。

19.6.2 Oracle WebCenter Content: Imagingのスケール・アップ手順

Imagingサーバーをスケール・アップする前に、WCCHOST1 (WCCHOST1VHN2など)で仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスの有効化方法の詳細は、第10.7項「WLS_WCC管理対象サーバー用のノード・マネージャの構成」を参照してください。

エンタープライズ・デプロイメント・トポロジ内でImagingサーバーをスケール・アップする手順は次のとおりです。

1. WebLogic Server管理コンソールを使用し、WLS_IMG1のクローンを作成して新しい管理対象サーバーにします。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。
管理対象サーバーをクローニングする手順は次のとおりです。

1. WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。

2. 「サーバーのサマリー」ページで、「ロックして編集」をクリックし、クローンを作成する管理対象サーバー(WLS_IMG1)を選択します。

3. 「クローンの作成」をクリックします。

4. 新しい管理対象サーバーの名前を「WLS_IMGn」にします。nは、新しい管理対象サーバーの識別番号です。

5. サーバーのリスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPアドレスを割り当てます。このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーの仮想ホスト名を割り当てる必要があります。この仮想ホスト名は、既存の管理対象サーバーとは別のものを使用してください。

6. サーバーのリスニング・ポートに対して、Imagingクラスタ(IMG_Cluster)のリスニング・ポート番号を入力します。このガイドにおける参照用トポロジはポート番号16000を使用します。

7. 「OK」をクリックし、「変更のアクティブ化」をクリックします。この時点で、「サーバーのサマリー」に、新しく作成されたサーバーWLS_IMGnが表示されます。

以降の手順は、新しいサーバーをWCCHOST1に追加する場合の想定に基づいています。このホストではすでにWLS_IMG1が実行されています。

2. Oracle WebCenter Content: Imaging用にJMS永続ストアとJMSサーバーを構成します。
2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Imagingで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(/u02/oracle/config/domains/WCCDomain/servers/server_name/data/store/default)を使用しています。

次のように、共有ベースのディレクトリを使用するように、各Oracle JMSサーバーの永続ストアを変更する必要があります。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。

3. 「永続ストアのサマリー」ページで「ロックして編集」をクリックします。

4. 「新規」→「ファイル・ストアの作成」をクリックします。

5. 「新しいファイル・ストアの作成」ページで次の情報を入力します。
- 名前: IMGJMSServerNStore(例: IMGJMSServer3Store。これにより、作成対象のサービスを特定できます)。

- ターゲット: WLS_IMGn(例: WLS_IMG3)。

- ディレクトリ: WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを指定します(/u01/oracle/config/domains/WCCDomain/IMG_Cluster/jms)。

6. 「OK」をクリックして、変更内容を有効にします。

7. 「ドメイン構造」ウィンドウで、「サービス」ノード→「メッセージ」ノードを開いて、「JMSサーバー」をクリックします。

8. 「JMSサーバーのサマリー」ページで「新規」をクリックし、次の情報を入力します。
- 名前: IpmJmsServern(例: IpmJmsServer3)。

- 永続ストア: 前述のとおり作成した永続ストアIMGJMSServerNStore(例: IMGJMSServer3Store)を選択します。

「次へ」をクリックし、WLS_IMGn(例: WLS_IMG3)をターゲットとして指定します。

9. 「終了」をクリックして変更内容を有効にします。

3. トランザクション・リカバリのためのWLS_IMGnのデフォルトの永続ストアを構成します。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)「WLS_IMGn」をクリックします。WLS_IMGnサーバーの設定ページが開き、「構成」タブがアクティブに表示されます。

4. 「サービス」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「保存」をクリックして、変更をアクティブ化します。

4. 新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第8.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_IMGn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

5. 新しく作成した管理対象サーバー(WLS_IMG)を起動します。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、「制御」タブを開き、クラスタ内にある既存のWLS_IMGnすべての管理対象サーバーを停止します。

4. 新規作成した管理対象サーバーであるWLS_IMGnが稼働していることを確認します。

6. WLS_IMGn管理対象サーバー(WCCHOSTnVHN2)のホスト名をSocketHostNameSecurityFilterパラメータ・リストに追加します。

1. テキスト・エディタでファイル/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgを開きます。

2. リスニング・アドレスをOracle WebCenter Contentへの接続を許可するアドレスのリストに追加するために、WLS_IMGn管理対象サーバーを追加します(SocketHostNameSecurityFilter=localhost|localhost.example.com|WCCHOST1|WCCHOST2|WCCHOSTnVHNn)。

3. 変更されたconfig.cfgファイルを保存しら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

7. サーバー移行が新しい管理対象サーバー用に構成されていることを確認します。

注意:
これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。よって、次の手順は確認用にのみ使用されます。新しいImaging管理対象サーバー用の浮動IPアドレスも、すでに存在している必要があります。

サーバー移行が構成されていることを確認する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成する新しい管理対象サーバー名(ハイパーリンクで表示されている)をクリックします。

4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

5. 「移行の構成」セクションで、移行に参加するサーバーを 「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、すでにWLS_IMG1が実行されているWCCHOST1上の新しい管理対象サーバーには、WCCHOST2を選択します。すでにWLS_IMG2が実行されているWCCHOST2上の新しい管理対象サーバーには、WCCHOST1を選択します。

注意:
移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。

6. 「サーバーの自動移行を有効化」オプションが選択されていることを確認します。
これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

- まず、管理コンソールを使用して管理対象サーバーを停止します。

- 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

- 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

8. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

- WLS_IMGn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_IMGn

- ノード・マネージャ・コンソールに、WLS_IMGnの浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。

- ノード・マネージャがWLS_IMGnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

- ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:
サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

19.6.3 Oracle WebCenter Enterprise Captureのスケール・アップ手順

Oracle WebCenter Enterprise Captureサーバーをスケール・アップする前に、WCCHOST1 (WCCHOST1VHN3など)で仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスの有効化方法の詳細は、第10.7項「WLS_WCC管理対象サーバー用のノード・マネージャの構成」を参照してください。

エンタープライズ・デプロイメント・トポロジでCaptureサーバーをスケール・アップする手順は次のとおりです。

1. WebLogic Server管理コンソールを使用して、WLS_CPT1をクローニングして新しい管理対象サーバーを作成します。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。
管理対象サーバーをクローニングする手順は次のとおりです。

1. WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。

2. 「サーバーのサマリー」ページで、「ロックして編集」をクリックし、クローンを作成する管理対象サーバー(WLS_CPT1)を選択します。

3. 「クローンの作成」をクリックします。

4. 新しい管理対象サーバーの名前をWLS_CPTnにします。nは、新しい管理対象サーバーの識別番号です。

5. サーバーのリスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPアドレスを割り当てます。このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーの仮想ホスト名を割り当てる必要があります。この仮想ホスト名は、既存の管理対象サーバーとは別のものを使用してください。

6. サーバーのリスニング・ポートに対して、Captureクラスタ(CPT_Cluster)のリスニング・ポート番号を入力します。このガイドにおける参照用トポロジはポート番号16400を使用します。

7. 「OK」をクリックし、「変更のアクティブ化」をクリックします。この時点で、「サーバーのサマリー」に、新しく作成されたサーバーWLS_CPTnが表示されます。

以降の手順は、新しいサーバーをWCCHOST1に追加することを想定しています。このホストではすでにWLS_CPT1が実行されています。

2. Capture用にJMS永続ストアとJMSサーバーを構成します。
2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Captureで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(/u01/oracle/config/domains/WCCDomain/servers/server_name/data/store/default)を使用しています。

次のように、共有ベースのディレクトリを使用するように、各Oracle JMSサーバーの永続ストアを変更する必要があります。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。

3. 「永続ストアのサマリー」ページで「ロックして編集」をクリックします。

4. 「新規」→「ファイル・ストアの作成」をクリックします。

5. 「新しいファイル・ストアの作成」ページで次の情報を入力します。
- 名前: CPTJMSServernStore(例: CPTJMSServer3Store。これにより、作成対象のサービスを特定できます)。

- ターゲット: WLS_CPTn(例: WLS_CPT3)。

- ディレクトリ: WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを指定します(/u01/oracle/config/domains/WCCDomain/CPT_Cluster/jms)。

6. 「OK」をクリックして、変更内容を有効にします。

7. 「ドメイン構造」ウィンドウで、「サービス」ノード→「メッセージ」ノードを開いて、「JMSサーバー」をクリックします。

8. 「JMSサーバーのサマリー」ページで「新規」をクリックし、次の情報を入力します。
- 名前: CaptureJmsServern(例: CaptureJmsServer3)。

- 永続ストア: 前述のとおり作成した永続ストアCPTJMSServernStore(例: CPTJMSServer3Store)を選択します。

「次へ」をクリックし、WLS_CPTn(例: WLS_CPT3)をターゲットとして指定します。

9. 「終了」をクリックして変更内容を有効にします。

3. トランザクション・リカバリのためのCPTnのデフォルトの永続ストアを構成します。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)「CPT_IMGn」をクリックします。CPT_IMGnサーバーの設定ページが開き、「構成」タブがアクティブに表示されます。

4. 「サービス」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「保存」をクリックして、変更をアクティブ化します。

4. 新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第8.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
CPT_IMGn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

5. 新しく作成した管理対象サーバー(WLS_CPT)を起動します。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、「制御」タブを開き、クラスタ内にある既存のWLS_CPTnすべての管理対象サーバーを停止します。

4. 新規作成した管理対象サーバーであるWLS_CPTnが稼動していることを確認します。

6. WLS_CPTn管理対象サーバー(WCCHOSTnVHN3)のホスト名をSocketHostNameSecurityFilterパラメータ・リストに追加します。

1. テキスト・エディタでファイル/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgを開きます。

2. リスニング・アドレスをOracle WebCenter Contentへの接続を許可するアドレスのリストに追加するために、WLS_CPTn管理対象サーバーを追加します(SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|WCCHOST1|WCCHOST2|WCCHOSTnVHNn)。

3. 変更されたconfig.cfgファイルを保存しら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

7. サーバー移行が新しい管理対象サーバー用に構成されていることを確認します。

注意:
これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。よって、次の手順は確認用にのみ使用されます。新しいImaging管理対象サーバー用の浮動IPアドレスも、すでに存在している必要があります。

サーバー移行が構成されていることを確認する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成する新しい管理対象サーバー名(ハイパーリンクで表示されている)をクリックします。

4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

5. 「移行の構成」セクションで、移行に参加するサーバーを 「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、すでにWLS_CPT1が実行されているWCCHOST1上の新しい管理対象サーバーには、WCCHOST2を選択します。すでにWLS_CPT2が実行されているWCCHOST2上の新しい管理対象サーバーには、WCCHOST1を選択します。

注意:
移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。

6. 「サーバーの自動移行を有効化」オプションが選択されていることを確認します。
これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

- まず、管理コンソールを使用して管理対象サーバーを停止します。

- 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

- 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

8. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

- WLS_CPTn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_IMGn

- ノード・マネージャ・コンソールに、WLS_CPTnの浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。

- ノード・マネージャがWLS_CPTnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

- ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:
サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

19.6.4 Oracle SOA Suiteのスケール・アップ手順

Imagingサーバーをスケール・アップする前に、WCCHOST1 (WCCHOST1VHN1など)で仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスの有効化方法の詳細は、第10.7項「WLS_WCC管理対象サーバー用のノード・マネージャの構成」を参照してください。

注意:
Oracle WebCenter Content: Imagingが使用するOracle SOA Suiteサブシステムのスケール・アップについては、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのドキュメントを参照してください。

エンタープライズ・デプロイメント・トポロジ内でOracle SOA Suiteサーバーをスケール・アップする手順は次のとおりです。

1. WebLogic Server管理コンソールを使用して、WLS_SOA1をクローニングして新しい管理対象サーバーを作成します。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。
管理対象サーバーをクローニングする手順は次のとおりです。

1. WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。

2. 「サーバーのサマリー」ページで、クローンを作成する管理対象サーバー(WLS_SOA1)を選択します。

3. 「クローンの作成」をクリックします。

4. 新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。

注意:
以降の手順は、新しいサーバーをWCCHOST1に追加することを想定しています。このホストではすでにWLS_SOA1が実行されています。

2. リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPアドレスを割り当てます。このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、別のノードへの移動を可能にするために、このアドレスに仮想IPアドレス(浮動IPアドレスともいう)を割り当てる必要があります。仮想IPアドレスは、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。

3. 新しい管理対象サーバーにOracle SOA SuiteおよびUMSのJMSサーバーを作成します。

1. WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。第4.4項「各種ディレクトリの推奨場所」でお薦めしているように、これは共有記憶域上のディレクトリにします。

/u01/oracle/config/domains/WCCDomain/SOA_Cluster/jms/

2. Oracle SOA Suiteの新しいJMSサーバーを作成します(例: SOAJMSServer_N)。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

3. 新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_N)。このストアのパスを指定します。第4.4項「各種ディレクトリの推奨場所」でお薦めしているように、これは共有記憶域上のディレクトリにします。

/u01/oracle/config/domains/WCCDomain/SOA_Cluster/jms/

注意:
新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

4. UMS用の新しいJMSサーバーを作成します(例:UMSJMSServer_N)。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

5. SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、先ほど作成したSOA JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが開きます。「SOAJMSModule」(表の「名前」列にハイパーリンクとして表示)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。このタブには、SOAJMSのサブデプロイメント・モジュールに関する情報が表示されます。

注意:
このサブデプロイメント・モジュール名は、SOAJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)の構成ウィザードJMS構成から生成されます。

「SOAJMSServerXXXXXX」サブデプロイメントをクリックします。Oracle SOA Suiteの新しいJMSサーバーであるSOAJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。

6. UMSJMSSystemResourceのサブデプロイメント・ターゲットを更新し、先ほど作成したUMS JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが開きます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。このタブには、UMSJMSのサブデプロイメント・モジュールに関する情報が表示されます。

注意:
このサブデプロイメント・モジュール名は、UCMJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)の構成ウィザードJMS構成から生成されます。

「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。UMSの新しいJMSサーバーであるUMSJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。

4. 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順は、第12.5項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。

注意:
変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostの値を、追加された新しいサーバーのリスニング・アドレスに置き換えます。
Dtangosol.coherence.localhost=SOAHOST1VHNn

5. 新しいサーバーのTx永続ストアを構成します。これは、共有記憶域に関する推奨事項で示されるとおり、他のノードから見える場所にする必要があります。(第4.4項「各種ディレクトリの推奨場所」を参照)。
管理コンソールから、「サービス」タブにあるサーバー名(WLS_SOAn)を選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。

/u01/oracle/config/domains/WCCDomain/SOA_Cluster/tlogs

6. 新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第8.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_SOAn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

7. WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. 新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。

2. LBR上のアプリケーション(http://wccinternal.example.com/soa-infra)にアクセスします。アプリケーションが機能している必要があります。

注意:
トポロジ内のOracle HTTP Serverは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverの*_vh.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

8. 新しい管理対象サーバーのサーバー移行を構成します。

注意:
これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。新しいOracle SOA Suite管理対象サーバー用の浮動IPアドレスも、すでに存在している必要があります。

サーバー移行を構成する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成する新しい管理対象サーバー名(ハイパーリンクで表示されている)をクリックします。

4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

5. 「移行の構成」セクションで、移行に参加するサーバーを 「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、すでにWLS_SOA1が実行されているWCCHOST1上の新しい管理対象サーバーには、WCCHOST2を選択します。すでにWLS_SOA2が実行されているWCCHOST2上の新しい管理対象サーバーには、WCCHOST1を選択します。

注意:
移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。

6. 「サーバーの自動移行を有効化」オプションが選択されていることを確認します。
これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

- まず、管理コンソールを使用して管理対象サーバーを停止します。

- 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

- 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

9. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

- WLS_SOAn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_SOAn

- ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。

- ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

- ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:
サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

19.7 Oracle WebCenter Contentトポロジのスケール・アウト

トポロジのスケール・アウトでは、新しいノードに構成された新しい管理対象サーバーを追加します。

前提条件

この項の手順を実行する前に、次の要件が満たされていることを確認してください。

- Oracle Fusion Middlewareで構成された管理対象サーバーを実行しているノードがトポロジ内に存在しています。

- 新しいノードは、WebLogic ServerとOracle Fusion Middlewareの既存のホーム・ディレクトリにアクセスできます。(新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerやOracle Fusion Middlewareのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpackとunpackを実行してドメイン構成をブートストラップする必要はあります。)

- OracleホームまたはWebLogic Serverホームが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノードでoraInventoryディレクトリを更新して、これに共有記憶域のインストールを関連付けるには、ORACLE_HOME/oui/bin/attachHome.shを使用します。
Middlewareホームの一覧を更新してWebLogic Serverホームを追加または削除するには、User_Home/bea/beahomelistファイルを編集します。次の手順を参照してください。

- 新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。

注意:
コンテンツ・サーバーを含む管理対象サーバーの場合、共有ドメイン・ディレクトリは動作しません。intradoc.cfgなどのドメイン内の特定のファイルは各ノードに固有だからです。ノード固有のファイルの問題を防ぐには、各Oracle WebCenter ContentおよびOracle WebCenter Content: Inbound Refinery管理対象サーバーにローカル(ノードごと)のドメイン・ディレクトリを使用します。

スケール・アウト手順

スケール・アウトの手順は、トポロジのコンポーネントによって異なります。

- 第19.7.1項「WebCenter Contentのスケール・アウト手順」

- 第19.7.2項「Oracle WebCenter Content: Imagingのスケール・アウト手順」

- 第19.7.3項「Oracle WebCenter Enterprise Captureのスケール・アウト手順」

- 第19.7.4項「Oracle SOA Suiteのスケール・アウト手順」

19.7.1 WebCenter Contentのスケール・アウト手順

WebCenter Contentのスケール・アウト手順では、構成済のWLS_WCCn管理対象サーバーを新しいノードに追加します。

エンタープライズ・デプロイメント・トポロジ内でWebCenter Contentのサーバーをスケール・アウトする手順は次のとおりです。

1. 新しいノードで、Oracle WebCenter Contentのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

注意:
この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいWebCenter Contentのサーバーを追加することを想定しています。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、WCCHOSTnで次のコマンドを実行します(まだ実行していない場合)。

cd ORACLE_COMMON_HOME/oui/bin/

./attachHome.sh -jreLoc MW_HOME/jrockit_160_version

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

Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogic Serverインストールがノード内に存在する場合はこれを編集)、/u01/oracle/products/fmw_homeをこれに追加します。

3. WebLogicサーバーの管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

注意:
ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_WCCnサーバーをスケール・アウトする場合は、unpackコマンドで-overwrite_domainオプションを指定する必要があります。

5. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。

6. WebLogic Server管理コンソールを使用して、WLS_WCC1をクローニングして新しい管理対象サーバーを作成します。これにWLS_WCCnという名前を付けます(nには番号を指定します)。

注意:
この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

7. 新しい管理対象サーバーのサーバー・リスニング・アドレスとして使用するWCCHOSTnのホスト名またはIPアドレスを割り当てます。

8. WLS_WCCn管理対象サーバーを新しく作成されたマシンに割り当てます。
使用可能なサーバーのリストからWLS_WCCnを選択し、「終了」→「変更のアクティブ化」の順にクリックします。

9. WCCHOST1でpackコマンドを実行してテンプレート・パックを作成します。

注意:
管理対象サーバーのドメイン・ディレクトリはWCCHOSTnでまだ作成されていないため、この手順と次の2つの手順を実行する必要があります。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateScaleWCC.jar -template_name=edgdomain_templateScaleWCC

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

10. 次のコマンドをWCCHOST1で実行し、作成したテンプレート・ファイルをWCCHOSTnにコピーします。

scp edgdomaintemplateScaleWCC.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin

11. 次のように、unpackコマンドをWCCHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=/u02/oracle/config/domains/WCCDomain -template=edgdomaintemplateScaleWCC.jar -app_dir=/u01/oracle/config/applications/WCCDomain

12. WCCHOSTnで次のコマンドを実行し、ノード・マネージャを起動します。

CD WL_HOME/server/bin
nohup ./startNodeManager.sh > nm.out&

参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

13. 新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第8.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_WCCn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

14. WebLogic Server管理コンソールで、新しい管理対象サーバーであるWLS_WCCnを起動し、サーバーの状態が「実行中」と表示されることを確認します。

15. 新しい管理対象サーバーであるWLS_WCCnを構成します。

1. http://WCCHOSTn:16200/csでWebLogic Serverの管理ユーザー名とパスワードを使用してWLS_WCCnにログインします。WebCenter Contentの「構成」ページが表示されます。

注意:
「データベース内のRevisions表が空ではないため、このサーバーを新規インスタンスとして 構成できません。このサーバーは既存のクラスタ内のノードのみに構成できます。」というテキストが、ページの最後に表示されます。

2. 「サーバーの構成」ページで次の値を変更します。「クラスタ・ノード識別子」が、管理対象サーバーの名前(WLS_WCC1など)と一致するように設定されていることを確認してください。
- コンテンツ・サーバーのインスタンス・フォルダ: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/csに設定します。

- ネイティブ・ファイル・リポジトリの場所: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/vaultに設定します。

- Webレイアウト・フォルダ: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/weblayoutに設定します。

- ユーザー・プロファイル: これを/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/data/users/profilesに設定します。

3. 完了したら「送信」をクリックし、WebLogic Server管理コンソールを使用して新しい管理対象サーバーを再起動します。

16. /u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgファイルにあるOracle WebCenter Contentで許可されているホストのリストに、WLS_WCCnのリスニング・アドレスを追加します。管理コンソールを使用して、Oracle WebCenter Content管理対象サーバーを再起動します。
サーバーおよびリスニング・アドレスは次のContent Serverプールに追加されます。

- WCCHOST1:4444

- WCCHOST2:4444

- WCCHOST3:4444

詳細は、第13.5.12項「コンテンツ・サーバーへの接続の作成」を参照してください。

17. LBR上のアプリケーション(https://wcc.example.com/cs)にアクセスしてWLS_WCCn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

注意:
トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverの*_vh.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

19.7.2 Oracle WebCenter Content: Imagingのスケール・アウト手順

Imagingのスケール・アウト手順では、構成済のWLS_IMGn管理対象サーバーを新しいノードに追加します。

エンタープライズ・デプロイメント・トポロジ内でImagingサーバーをスケール・アウトする手順は次のとおりです。

1. 新しいノードで、Oracle WebCenter Contentのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、WCCHOSTnで次のコマンドを実行します(まだ実行していない場合)。

cd ORACLE_COMMON_HOME/oui/bin/

./attachHome.sh -jreLoc MW_HOME/jrockit_160_version

Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogic Serverインストールがノード内に存在する場合は、このファイルを編集)、MW_HOMEをこのファイルに追加します。

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

3. WebLogicサーバーの管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

注意:
WLS_WCCnサーバーと同じマシンでWLS_IMGnサーバーをスケール・アウトする場合、新しいマシンを作成する必要はありません。第19.7.1項「WebCenter Contentのスケール・アウト手順」の手順4で作成したマシンを使用します。

5. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。

6. WebLogic Server管理コンソールを使用して、WLS_IMG1をクローニングして新しい管理対象サーバーを作成します。これにWLS_IMGnという名前を付けます(nには番号を指定します)。

注意:
この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

1. 新しい管理対象サーバー用に使用するホスト名またはIPアドレスを、その管理対象サーバーのリスニング・アドレスとして割り当てます。このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーの仮想IPアドレス(別称: 浮動IPアドレス)である必要があります。この仮想IPアドレスは、既存の管理対象サーバーとは別のものを使用してください。

注意:
ノードnでは仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスを有効化する方法の詳細は、第6.6項「仮想IPアドレスの有効化」を参照してください。

2. 「はい、このサーバーを既存のクラスタのメンバーにします。」を選択します。

3. 新しく作成したサーバーを、手順4で追加したマシンに割り当てます。これを実行しない場合、クローン元のサーバーのマシン名が残ります。

7. 新しい管理対象サーバーでOracle WebCenter Content: ImagingのJMSサーバーを作成します。

1. WebLogic Server管理コンソールを使用して、新しいIpmJmsServerN用の新しい永続ストアを最初に作成し(作成方法は後述)、IMGJMSServerNStoreなどの名前を付けます。JMS永続ストアのディレクトリとして、第4.4項「各種ディレクトリの推奨場所」で推奨されているストアのパスを指定します。

/u01/oracle/config/domains/WCCDomain/IMG_Cluster/jms

2. 新しいJMSサーバーを作成します(例: IpmJmsServerN)。
前の手順で作成したIMGJMSServerNStoreをJMSサーバーに使用します。IpmJmsServerNサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_IMGn)を指定します。

8. WCCHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateScaleIMG.jar
-template_name=edgdomain_templateScaleIMG

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

注意:
他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、この手順および次の2つの手順は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバー用に使用します。

9. 次のコマンドをWCCHOST1で実行し、作成したテンプレート・ファイルをWCCHOSTnにコピーします。

scp edgdomaintemplateScaleIMG.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin

注意:
新しいホストである、WCCHOSTnがWCCHOST1と同じMiddlewareホームを使用する場合、この手順は不要です。

10. 次のように、unpackコマンドをWCCHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template= edgdomaintemplateScaleIMG.jar -app_dir=APPLICATION_HOME

参照トポロジで、APPLICATION_HOMEは/u01/oracle/config/applications/WCCDomainディレクトリです。

注意:
ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_IMGnサーバーをスケール・アウトする場合は、unpackコマンドで-overwrite_domainオプションを指定する必要があります。

11. 新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第8.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_WCCn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

12. 次により、「サーバーの自動移行を有効化」オプションを無効にします。

1. WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「環境」ノードを開き、「サーバー」を選択します。

2. WLS_IMGn管理対象サーバーを選択し、「移行」タブをクリックします。

3. 「サーバーの自動移行を有効化」の選択を解除します。

4. 「保存」および「変更のアクティブ化」をクリックします。

13. ノード・マネージャがまだ起動されていない場合は、新しいノードで起動します。WCCHOSTnで次のコマンドを実行し、ノード・マネージャを起動します。

CD WL_HOME/server/bin
nohup ./startNodeManager.sh > nm.out&

参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

14. Fusion Middleware Controlで、新しい管理対象サーバーであるWLS_IMGnを起動し、稼働していることを確認します。

15. Oracle WebCenter Content Serverで許可されているホストのリストに、新しいImagingサーバーのリスニング・アドレスを追加します。第13.5.11項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」の手順に従って、新しいサーバーを、Oracle WebCenter ContentのSocketHostNameSecurityFilter構成に追加します。

注意:
すべてのImaging管理対象サーバーのホスト名が/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgファイルにあるSocketHostNameSecurityFilterパラメータ・リストに追加されていることを確認してください。

16. WebLogic Server管理コンソールを使用してすべてのOracle WebCenter Content管理対象サーバーを再起動します。

17. LBR上のアプリケーション(https://wcc.example.com/imaging)にアクセスしてWLS_IMGn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

注意:
トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverの*_vh.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

18. 新しく追加したサーバー用のサーバー移行を構成します。
新しいサーバーのクローン元となったソース・サーバー(ここではWLS_IMGn)はすでにサーバー移行が構成されていると想定しています。この場合、サーバー移行の設定はクローンされたサーバーに伝播されるため、次の手順は不要です。

すでにノード・マネージャにホスト名検証証明書を設定している場合は、前提条件として、新しく作成されたサーバーに対してこの手順を実行する必要があります。詳細は、第16.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

注意:
この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいノードで定義される権限を検証して、サーバー移行が機能することを確認します。権限の要件の詳細は、第17章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。

サーバー移行を構成する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成するサーバー名(ハイパーリンクで表示されている)をクリックします。

4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右向き矢印をクリックします。

注意:
マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

- まず、管理コンソールを使用して管理対象サーバーを停止します。

- 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

- 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

19. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

- WLS_IMGn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_IMGn

- ノード・マネージャ・コンソールに、WLS_IMGnの浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。

- ノード・マネージャがWLS_IMGnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

- ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:
サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

19.7.3 Oracle WebCenter Enterprise Captureのスケール・アウト手順

Imagingのスケール・アウト手順では、構成済のWLS_CPTn管理対象サーバーを新しいノードに追加します。

エンタープライズ・デプロイメント・トポロジ内でCaptureサーバーをスケール・アウトする手順は次のとおりです。

1. 新しいノードで、Oracle WebCenter Contentのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、WCCHOSTnで次のコマンドを実行します(まだ実行していない場合)。

cd ORACLE_COMMON_HOME/oui/bin/

./attachHome.sh -jreLoc MW_HOME/jrockit_160_version

Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogic Serverインストールがノード内に存在する場合はこれを編集)、/u01/oracle/products/fmw_homeをこれに追加します。

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

3. WebLogicサーバーの管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します(まだ実行していない場合)。

5. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。

6. WebLogic Server管理コンソールを使用して、WLS_CPT1をクローニングして新しい管理対象サーバーを作成します。これにWLS_CPTnという名前を付けます(nには番号を指定します)。

注意:
この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

1. 新しい管理対象サーバー用に使用するホスト名またはIPアドレスを、その管理対象サーバーのリスニング・アドレスとして割り当てます。このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーの仮想IPアドレス(別称: 浮動IPアドレス)である必要があります。この仮想IPアドレスは、既存の管理対象サーバーとは別のものを使用してください。

注意:
ノードnでは仮想IPアドレスを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはホスト解決のいずれかで)正しく解決する必要があります。仮想IPアドレスを有効化する方法の詳細は、第6.6項「仮想IPアドレスの有効化」を参照してください。

2. 新しく作成したサーバーを、手順4で追加したマシンに割り当てます。これを実行しない場合、クローン元のサーバーのマシン名が残ります。

7. 新しい管理対象サーバーにCapture用のJMSサーバーを作成します。

1. WebLogic Server管理コンソールを使用して、新しいCaptureJmsServerN用の新しい永続ストアを最初に作成し(作成方法は後述)、CPTJMSServerNStoreなどの名前を付けます。JMS永続ストアのディレクトリとして、第4.4項「各種ディレクトリの推奨場所」で推奨されているストアのパスを指定します。

MSERVER_HOME/cluster_name/jms

2. 新しいJMSサーバーを作成します(例: CaptureJmsServerN)。1つ前の手順で作成したCPTJMSServerNStore永続ストアをこのJMSサーバーに使用します。CaptureJmsServerNのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_CPTn)を指定します。

8. WCCHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateScaleCPT.jar
-template_name=edgdomain_templateScaleCPT

参照トポロジで、ORACLE_COMMON_HOMEは/u01/oracle/products/fmw_home/oracle_commonディレクトリで、ASERVER_HOMEは/u01/oracle/config/domains/WCCDomainディレクトリです。

注意:
他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、この手順および次の2つの手順は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバー用に使用します。

9. 次のコマンドをWCCHOST1で実行し、作成したテンプレート・ファイルをWCCHOSTnにコピーします。

scp edgdomaintemplateScaleCPT.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin

注意:
新しいホストである、WCCHOSTnがWCCHOST1と同じMW_HOMEを使用する場合、この手順は不要です。

10. 次のように、unpackコマンドをWCCHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template= edgdomaintemplateScaleCPT.jar -app_dir=APPLICATION_HOME

注意:
ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_CPTnサーバーにunpackコマンドを実行する場合は、unpackコマンドで-overwrite_domainオプションを指定する必要があります。

11. 新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第8.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_WCCn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

12. 次により、「サーバーの自動移行を有効化」オプションを無効にします。

1. WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「環境」ノードを開き、「サーバー」を選択します。

2. WLS_CPTn管理対象サーバーを選択し、「移行」タブをクリックします。

3. 「サーバーの自動移行を有効化」の選択を解除します。

4. 「保存」および「変更のアクティブ化」をクリックします。

13. ノード・マネージャがまだ起動されていない場合は、新しいノードで起動します。WCCHOSTnで次のコマンドを実行し、ノード・マネージャを起動します。

CD WL_HOME/server/bin
nohup ./startNodeManager.sh > nm.out&

参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

14. Fusion Middleware Controlで、新しい管理対象サーバーであるWLS_CPTnを起動し、稼動していることを確認します。

15. Oracle WebCenter Content Serverで許可されているホストのリストに、新しいCaptureサーバーのリスニング・アドレスを追加します。第13.5.11項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」の手順に従って、新しいサーバーを、Oracle WebCenter ContentのSocketHostNameSecurityFilter構成に追加します。

注意:
すべてのCapture管理対象サーバーのホスト名が/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgファイルにあるSocketHostNameSecurityFilterパラメータ・リストに追加されていることを確認してください。

16. WebLogic Server管理コンソールを使用してすべてのOracle WebCenter Content管理対象サーバーを再起動します。

17. LBR上のアプリケーション(Captureコンソールの場合はhttps://wcc.example.com/dc-console、Captureクライアントの場合はhttps://wcc.example.com/dc-client)にアクセスして、WLS_CPTn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

注意:
トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverの*_vh.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

18. 新しく追加したサーバー用のサーバー移行を構成します。
新しいサーバーのクローン元となったソース・サーバー(ここではWLS_CPTn)はすでにサーバー移行が構成されていると想定しています。この場合、サーバー移行の設定はクローンされたサーバーに伝播されるため、次の手順は不要です。

すでにノード・マネージャにホスト名検証証明書を設定している場合は、前提条件として、新しく作成されたサーバーに対してこの手順を実行する必要があります。詳細は、第16.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

注意:
この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいノードで定義される権限を検証して、サーバー移行が機能することを確認します。権限の要件の詳細は、第17章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。

サーバー移行を構成する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成するサーバー名(ハイパーリンクで表示されている)をクリックします。

4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右向き矢印をクリックします。

注意:
マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

- まず、管理コンソールを使用して管理対象サーバーを停止します。

- 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

- 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

19. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

- WLS_CPTn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_CPTn

- ノード・マネージャ・コンソールに、WLS_CPTnの浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。

- ノード・マネージャがWLS_CPTnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

- ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:
サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

19.7.4 Oracle SOA Suiteのスケール・アウト手順

Imagingのスケール・アウト手順では、構成済のWLS_SOAn管理対象サーバーを新しいノードに追加します。

注意:
Captureが使用するOracle SOA Suiteサブシステムのスケール・アウトについては、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのドキュメントを参照してください。

エンタープライズ・デプロイメント・トポロジ内でOracle SOA Suiteサーバーをスケール・アウトする手順は次のとおりです。

1. 新しいノードで、Oracle SOA Suiteのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、WCCHOSTnで次のコマンドを実行します(まだ実行していない場合)。

cd ORACLE_COMMON_HOME/oui/bin/

./attachHome.sh -jreLoc MW_HOME/jrockit_160_version

Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogic Serverインストールがノード内に存在する場合はこれを編集)、/u01/oracle/products/fmw_homeをこれに追加します。

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

3. WebLogicサーバーの管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

注意:
ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_SOAnサーバーをスケール・アウトする場合は、unpackコマンドで-overwrite_domainオプションを指定する必要があります。

5. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。

6. WebLogic Server管理コンソールを使用し、WLS_SOA1をクローニングして新しい管理対象サーバーを作成します。これにWLS_SOAnという名前を付けます。nは番号です。

注意:
この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

7. 新しい管理対象サーバー用に使用するホスト名またはIPアドレスを、その管理対象サーバーのリスニング・アドレスとして割り当てます。
このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーの仮想IPアドレス(別称: 浮動IPアドレス)である必要があります。この仮想IPアドレスは、既存の管理対象サーバーとは別のものを使用してください。

8. WCCHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateScaleSOA.jar
-template_name=edgdomain_templateScaleSOA

注意:
他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、この手順は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバー用に使用します。

9. 次のコマンドをWCCHOST1で実行し、作成したテンプレート・ファイルをWCCHOST2にコピーします。

scp edgdomaintemplateScaleSOA.jar oracle@WCCHOST2:/ORACLE_COMMON_HOME/common/bin

10. 次のように、unpackコマンドをWCCHOST2で実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME -template= edgdomaintemplateScaleSOA.jar
-app_dir=APPLICATION_HOME

注意:
ドメインおよびアプリケーションのディレクトリがすでに存在するホストでWLS_CPTnサーバーをスケール・アウトする場合は、unpackコマンドで-overwrite_domainオプションを指定する必要があります。

11. 新しい管理対象サーバーにOracle SOA SuiteおよびUMSのJMSサーバーを作成します。

1. WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。第4.4項「各種ディレクトリの推奨場所」でお薦めしているように、これは共有記憶域上のディレクトリにします。

/u01/oracle/config/domains/WCCDomain/SOA_Cluster/jms

2. Oracle SOA Suiteの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_N)。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

3. 新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_N)。このストアのパスを指定します。第4.4項「各種ディレクトリの推奨場所」でお薦めしているように、これは共有記憶域上のディレクトリにします。

/u01/oracle/config/domains/WCCDomain/SOA_Cluster/jms

注意:
新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

4. UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

5. SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、先ほど作成したSOA JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが開きます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。このタブには、SOAJMSのサブデプロイメント・モジュールに関する情報が表示されます。

注意:
このサブデプロイメント・モジュール名は、SOAJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)の構成ウィザードJMS構成から生成されます。

「SOAJMSServerXXXXXX」サブデプロイメントをクリックします。Oracle SOA Suiteの新しいJMSサーバーであるSOAJMSServer_Nをこのサブデプロイメントに追加します。「保存」をクリックします。

6. UMSJMSSystemResourceのサブデプロイメント・ターゲットを更新し、先ほど作成したUMS JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「サービス」ノードを開き、「メッセージング」ノードを開きます。「JMSモジュール」をクリックします。「JMSモジュール」ページが開きます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。このタブには、UMSJMSのサブデプロイメント・モジュールに関する情報が表示されます。

注意:
このサブデプロイメント・モジュール名は、UCMJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)の構成ウィザードJMS構成から生成されます。

「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

12. 新しいサーバーのTx永続ストアを構成します。これは、共有記憶域に関する推奨事項で示されるとおり、他のノードから見える場所にする必要があります。(第4.4項「各種ディレクトリの推奨場所」を参照)。
管理コンソールから、「サービス」タブにあるサーバー名(WLS_SOAn)を選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。

/u01/oracle/config/domains/WCCDomain/SOA_Cluster/tlogs

13. 新しい管理対象サーバーのホスト名検証をまだ無効にしていない場合は、第8.4.5項「ホスト名検証の無効化」の手順に従って無効にします。
WLS_SOAn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。

14. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用し、次のようにWCCHOSTnで新しいノードのホスト名をパラメータとして渡します。

cd WL_HOME/server/bin
nohup ./startNodeManager.sh > nm.out& New_Node_IP

参照トポロジで、WL_HOMEは/u01/oracle/products/fmw_home/wlserver_10.3ディレクトリです。

15. WebLogic Server管理コンソールで、新しい管理対象サーバーであるWLS_SOAnを起動し、稼働していることを確認します。

16. LBR上のアプリケーション(http://wccinternal.example.com/soa-infra)にアクセスしてWLS_SOAn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

注意:
トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverの*_vh.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

17. 新しく追加したサーバー用のサーバー移行を構成します。

注意:
この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいOracle SOA Suite管理対象サーバーの浮動IPアドレスも、新しいノードにすでに存在します。

サーバー移行を構成する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成するサーバー名(ハイパーリンクで表示されている)をクリックします。

4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右向き矢印をクリックします。

注意:
マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。

- まず、管理コンソールを使用して管理対象サーバーを停止します。

- 次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。

- 最後に、管理コンソールを使用して管理対象サーバーを再度起動します。

18. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

- WLS_SOAn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_SOAn

- ノード・マネージャ・コンソールに、WLS_SOAnの浮動IPアドレスが無効になったことを示すメッセージが表示されることを確認します。

- ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

- ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:
サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

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

ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをWCCHOST1からWCCHOST2にフェイルオーバーする方法を説明します。

- 第19.8.1項「前提条件および手順」

- 第19.8.2項「ロード・バランサを介したWCCHOST2へのアクセスの検証」

- 第19.8.3項「WCCHOST1への管理サーバーのフェイルバック」

19.8.1 前提条件および手順

次の前提条件があることに留意してください。

- 管理サーバーを、任意のアドレスではなくADMINVHN上でリスニングするように構成します。第8.3項「WCCHOST1での構成ウィザードを使用したドメインの作成」の手順16を参照してください。

- 管理サーバーはWCCHOST1からWCCHOST2にフェイルオーバーされ、この2つのノードに次のIPアドレスがある。

- WCCHOST1: 100.200.140.165

- WCCHOST2: 100.200.140.205

- ADMINVHN: 100.200.140.206.これは管理サーバーを実行している場所の仮想IPアドレスであり、ethX:Yに割り当てられています。

- WCCHOST1での管理サーバーの実行場所であるドメイン・ディレクトリは共有記憶域にあり、WCCHOST2からもマウントされています。

- 第7章「エンタープライズ・デプロイメント用のソフトウェアのインストール」の説明のとおり、Oracle WebLogic ServerおよびOracle Fusion MiddlewareコンポーネントはWCCHOST2にインストールされています(つまり、WCCHOST1に存在するORACLE_HOMEおよびMW_HOMEのパスをWCCHOST2でも使用できます)。

管理サーバーを別ノード(WCCHOST2)にフェイルオーバーする手順は次のとおりです。

1. 管理サーバーが実行されている場合は停止します。

2. IPアドレスを第2ノードに移行します。

1. WCCHOST1上で次のコマンドをroot権限で実行します(ここでは、X:YがADMINVHNで現在使用されているインタフェースになります)。

/sbin/ifconfig ethX:Y down

2. 次のコマンドをWCCHOST2上で実行します。

/sbin/ifconfig interface:index IP_address netmask netmask

例:

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

注意:
使用するネットマスクとインタフェースは、WCCHOST2で使用可能なネットワーク構成と一致している必要があります。また、第4.4項「各種ディレクトリの推奨場所」で説明するとおりの位置に、管理サーバー・アプリケーションのディレクトリがマウントされていることを確認してください。

3. 次の例のとおり、arpingを使用してWCCHOST2のルーティング表を更新します。

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

3. WCCHOST2でノード・マネージャを起動するには、第8.4.2項「WCCHOST1でのノード・マネージャの起動」の説明に従います。

4. WCCHOST2上で管理サーバーを起動するには、第8.4.3項「WCCHOST1での管理サーバーの起動」の説明に従います。

5. 次の方法でWCCHOST2上の管理サーバーにアクセスできることをテストします。

1. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにアクセスできることを確認します。

2. http://ADMINVHN:7001/emでOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、そのコンポーネントのステータスを確認します。

19.8.2 ロード・バランサを介したWCCHOST2へのアクセスの検証

第9.6.4項「ロード・バランサを使用したアクセスの検証」と同様の手順を実行します。この目的は、WCCHOST2で稼動中の管理サーバーにアクセスできることを確認することにあります。

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

この手順により、管理サーバーをフェイルバックできることを確認します。すなわち、WCCHOST2では管理サーバーを停止し、WCCHOST1で再び管理サーバーを実行します。

ADMINVHNを元のWCCHOST1ノードに移行する手順は次のとおりです。

1. 管理サーバーが起動されていないことを確認します。

2. 次のコマンドをWCCHOST2上で実行します。

/sbin/ifconfig ethZ:N down

3. 次のコマンドをWCCHOST1上で実行します。

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

注意:
使用するネットマスクとインタフェースは、WCCHOST1で使用可能なネットワーク構成と一致している必要があります。

4. arpingを使用し、ルーティング表を更新します。次のコマンドをWCCHOST1から実行します。

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

5. WCCHOST1上で管理サーバーを再度起動するには、第8.4.3項「WCCHOST1での管理サーバーの起動」の説明に従います。

6. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにアクセスできるかどうかテストします。

7. http://ADMINVHN:7001/emでOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、そのコンポーネントのステータスを確認します。

19.9 Oracle WebCenter Contentエンタープライズ・デプロイメントにおけるバックアップとリカバリの実行

表19-2は、Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。

表19-2 Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト

タイプ

ホスト

場所

層

Oracleホーム(DB)

WCCDBHOST1およびWCCDBHOST2

ユーザー定義

データ層

Middlewareホーム(OHS)

WEBHOST1およびWEBHOST2

/u02/oracle/products/fmw_home/web_home

Web層

Middlewareホーム(MW_HOME。これには、Oracle WebCenter ContentおよびOracle SOA SuiteのOracleホームが含まれています。)

WCCHOST1およびWCCHOST2*

/u01/oracle/products/fmw_home

Oracle WebCenter ContentおよびOracle SOA SuiteのOracleホームもMW_HOMEにあります。

アプリケーション層

インストール関連ファイル

OraInventory、User_Home/bea/beahomelist、
oraInst.loc、oratab

N/A

表19-3は、Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。

表19-3 Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト

タイプ

ホスト

場所

層

アプリケーション・アーティファクト(EARおよびWARファイル)

WCCHOST1およびWCCHOST2

アプリケーション・アーティファクトの場所を調べるには、管理コンソールですべてのデプロイメントを表示します。

アプリケーション層

Oracle WebCenter Contentランタイム・アーティファクト

WCCHOST1またはWCCHOST2

/u01/oracle/config/domains/WCCDomain/WCC_Cluster

アプリケーション層

Captureランタイム・アーティファクト

WCCHOST1またはWCCHOST2

/u01/oracle/config/domains/WCCDomain/CPT_Cluster

アプリケーション層

Oracle WebCenter Enterprise Captureランタイム・アーティファクト

WCCHOST1またはWCCHOST2

/u01/oracle/config/domains/WCCDomain/CPT_Cluster

アプリケーション層

Oracle SOA Suiteランタイム・アーティファクト

WCCHOST1またはWCCHOST2

/u01/oracle/config/domains/WCCDomain/SOA_Cluster

アプリケーション層

Oracle WebCenter Content用にカスタマイズされた管理対象サーバーの構成

WCCHOST1またはWCCHOST2

/u02/oracle/config/domains/WCCDomain/ucm/cs/bin/intradoc.cfg

および

/u02/oracle/config/domains/WCCDomain/bin/server_migration/wlsifconfig.sh

アプリケーション層

Oracle SOA Suite用にカスタマイズされた管理対象サーバーの構成

WCCHOST1またはWCCHOST2

UMSを使用している場合: /u02/oracle/config/domains/WCCDomain/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml

(*は、デプロイ中にWebLogic Serverによってランダムに生成される3682yqなどのディレクトリ名を表します)

および

/u02/oracle/config/domains/WCCDomain/bin/server_migration/wlsifconfig.sh

アプリケーション層

Oracle HTTP Serverインスタンス・ホーム

WEBHOST1およびWEBHOST2

/u02/oracle/config/webN

Web層

Oracle RACデータベース

WCCDBHOST1およびWCCDBHOST2

ユーザー定義

データ層

Oracle Fusion Middlewareコンポーネントのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

19.10 Oracle DatabaseでのOPSSセキュリティ・ストアの保持

この項では、管理者がOracle Databaseのセキュリティ・ストアをメンテナンスする場合に実行する可能性のある一部のタスクについて説明します。

データベース・ベースのセキュリティ・ストアには、変更ログが保持されますが、このログは定期的にパージする必要があります。変更ログをパージするには、管理者が、提供されているSQLスクリプトopss_purge_changelog.sqlを使用して、24時間以上前の変更ログをパージするか、データベースに接続して、次の行で示すように、SQLのdeleteを(適切な引数を指定して)実行します。

SQL>delete from jps_changelog where createdate < (select(max(createdate) - 1) from jps_changelog);
SQL>Commit;

データベース・ベースのセキュリティ・ストアにアクセスする際に、OPSS管理APIの実行速度が遅い場合は、DBMS_STATSパッケージを実行して、DBの表、索引、クラスタの物理記憶域に関する統計情報を収集します。この情報はデータ・ディクショナリに格納され、分析対象のオブジェクトにアクセスするSQL文の実行計画を最適化する際に使用できます。

数千の新しいアプリケーション・ロールを作成する場合など、大量のデータをデータベース・ベースのセキュリティ・ストアにロードする場合は、短期間内にロード・アクティビティと同時にDBMS_STATSを実行することをお薦めします。それ以外で、ロード・アクティビティが小規模な場合は、DBMS_STATSを必要に応じて1回のみ実行する必要があります。

次のサンプルは、DBMS_STATSの使用例を示しています。

EXEC DBMS_STATS.GATHER_SCHEMA_STATS('WCC_OPSS', DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);

WCC_OPSSは、RCUの設定時(第5.4項「データベース・スキーマの作成」を参照)に作成されたDBスキーマの名前です。DBMS_STATSパッケージの詳細は、『Oracle Database管理者ガイド』を参照してください。

DBMS_STATSを定期的に実行するには、次に説明するように、シェル・スクリプトまたはSQLスクリプトを使用します。

次のサンプル・スクリプトは、コマンドDBMS_STATSを10分ごとに実行します。

#!/bin/sh
i=1
while [ $i -le 1000 ]
do
echo $i
sqlplus wcc_opss/welcome1@inst1 @opssstats.sql
sleep 600
i=`expr $i + 1`
done

opssstats.sqlには、次のテキストが含まれます。

EXEC DBMS_STATS.gather_schema_stats('WCC_OPSS',DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);
QUIT;

また次のサンプルSQLスクリプトも、コマンドDBMS_STATSを10分ごとに実行します。

variable jobno number;
BEGIN
DBMS_JOB.submit
(job => :jobno,
what => 'DBMS_STATS.gather_schema_stats(''WCC_OPSS'',DBMS_STATS.AUTO_SAMPLE_SIZE,no_invalidate=>FALSE);',
interval => 'SYSDATE+(10/24/60)');
COMMIT;
END;
/

前述のSQLスクリプトによるDBMS_STATSの定期的な起動を停止するには、最初に次のコマンドを発行してそのジョブ番号を見つけます。

sqlplus '/as sysdba'
SELECT job FROM dba_jobs WHERE schema_user = 'WCC_OPSS' AND what = 'DBMS_STATS.gather_schema_stats(''WCC_OPSS'',DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);';

続いて、次のようなコマンドを発行します。このコマンドでは、前述の問合せがジョブ番号31を返すと仮定しています。

EXEC DBMS_JOB.remove(31);

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

本番エンタープライズ・デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters (RAC)の場合、データベース接続はOracle RACの仮想IPアドレスとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。そのように構成できない場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルの*SQLNET.EXPIRE_TIME=n*パラメータを設定してください。nは分単位の数値です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定してください。

19.12 Oracle WebCenter ContentとImagingサービスで使用するOracle Web Service Managerのセキュリティ・ポリシーの構成

初回インストール時、Oracle WebCenter ContentおよびImagingのWebサービスは、Oracle Web Service Manager (OWSM) のセキュリティ・ポリシーを適用せずに構成されています。セキュリティ・ポリシーが適用されていない場合、サービスは、HTTPの基本認証メカニズムを使用します。このメカニズムでは、ユーザーの資格証明(ユーザーIDおよびパスワード)は、WebサービスのHTTPメッセージ・ヘッダー内で送信されます。HTTP基本認証ではなく適切なOracle WSMポリシーを適用することをお薦めします。Oracle WebCenter ContentおよびImagingのWebサービスで使用するOracle WSMのセキュリティ・ポリシーを構成するには、『Oracle Fusion Middleware Oracle WebCenter Content: Imagingの開発』および『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』の手順に従います。

19.13 Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング

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

- 第19.13.1項「soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する」

- 第19.13.2項「デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)」

- 第19.13.3項「データベース内の最大プロセス数に達したために、WebCenter Contentサーバー、Oracle SOA SuiteサーバーまたはImagingサーバーの起動に失敗する」

- 第19.13.4項「手動フェイルオーバー後に管理サーバーの起動に失敗する」

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

- 第19.13.6項「サーバー移行後にSOAサーバー、ImagingサーバーまたはCaptureサーバーがフェイルオーバーしない」

- 第19.13.7項「サーバー移行後にSOAサーバー、ImagingサーバーまたはCaptureサーバーにブラウザからアクセスできない」

- 第19.13.8項「OAM構成ツール実行時にURLが削除されない」

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

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

- 第19.13.11項「構成されたJOCポートがすでに使用中」

- 第19.13.12項「CredentialAccessPermissionsを使用することで、Oracle WebCenter Content: Imagingが資格証明ストアから資格証明を読み取ることが可能になる」

- 第19.13.13項「Oracle WebCenter Content: ImagingからOracle WebCenter Contentに情報量の多いドキュメントをアップロードする際のパフォーマンスを向上させる」

- 第19.13.14項「管理対象サーバーのメモリー不足の問題」

- 第19.13.15項「Oracle WebCenter Content管理対象サーバーのマスター・パスワードを再生成する」

- 第19.13.16項「WebLogic Server管理コンソールからログアウトしても、ユーザー・セッションが終了しない」

- 第19.13.17項「トランザクション・タイムアウト・エラー」

- 第19.13.18項「ファイルのキャッシュとロック」

- 第19.13.19項「リモートでデプロイされたアプリケーションで使用するアップロード・ディレクトリおよびステージ・ディレクトリの変更」

19.13.1 soa-infraアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する

問題: ロード・バランサのアドレスを使用してsoa-infraアプリケーションにアクセスしようとしたときに、404メッセージ(ページが見つかりません)がWebブラウザに表示されます。このエラーは断続的に発生し、WebLogic Server管理コンソールではOracle SOA Suiteサーバーが「実行中」と表示されます。

解決方法: Oracle SOA Suite管理対象サーバーが実行中であっても、そのサーバー内のアプリケーションの状態がActiveではなく、AdminやPreparedである場合があります。Oracle SOA Suiteサーバーが実行中でも、soa-infraアプリケーションが使用不可になることもあります。管理コンソールの「デプロイメント」ページで、soa-infraアプリケーションの状態を調べてください。これが「アクティブ」状態である必要があります。Oracle SOA Suiteサーバーの出力ログにsoa-infraアプリケーション関連のエラーがないことを確認し、管理コンソールの「デプロイメント」ページでsoa-infraアプリケーションを起動してください。

19.13.2 デプロイメント・フレームワークの問題が原因でsoa-infraアプリケーションの起動に失敗する(Coherence)

問題: デプロイメントのCoherence構成に対する変更を適用した後、soa-infraアプリケーションの起動に失敗します。Oracle SOA Suiteサーバーの出力ログには、次のように報告されます。

Cluster communication initialization failed. If you are using multicast, Please make sure multicast is enabled on your network and that there is no interference on the address in use. Please see the documentation for more details.

解決方法:

1. SOAコンポジットのクラスタ・デプロイメントに対してユニキャストではなくマルチキャストを使用する場合、前述のようなメッセージが表示されることがあります。その原因は、soa-infraアプリケーションの起動時(つまり、Oracle SOA Suiteが実行される管理対象サーバーの起動時)にマルチキャスト競合が発生したためです。このメッセージは、Oracle Coherenceがランタイム例外をスローしたときに生成されるもので、例外自体の詳細情報も含まれています。このようなメッセージが表示された場合、ネットワークのマルチキャスト構成を確認してください。マルチキャスト・アドレスに対してpingを実行できることを確認します。さらに、ネットワーク内の別の名前のクラスタが同じマルチキャスト・アドレスを使用しているかどうかを調べてください。このようなクラスタがあると、競合が発生してsoa-infraを起動できなくなることがあります。ネットワークでマルチキャストが有効化されていない場合、ユニキャストを使用するようにデプロイメント・フレームワークを変更してください。その方法については、『Oracle Coherence開発者ガイド』を参照してください。

2. ユニキャスト用の既知アドレス・リストをサーバー起動パラメータ内に入力するときは、ノードのローカル・ホストおよびクラスタ化されたサーバー用のアドレスが正しいことを確認してください。アドレスのいずれかが正しく解決されていない場合は、サーバーの出力ログに次のようなエラー・メッセージが報告されます。

oracle.integration.platform.blocks.deploy.CompositeDeploymentCoordinatorMessages errorUnableToStartCoherence

19.13.3 データベース内の最大プロセス数に達したために、WebCenter Contentサーバー、Oracle SOA SuiteサーバーまたはImagingサーバーの起動に失敗する

問題: WebCenter Contentサーバー、Oracle SOA SuiteサーバーまたはImagingサーバーの起動に失敗します。新しい管理対象サーバー・タイプ用にドメインが拡張されている(たとえば、Imaging用にWebCenter Contentを拡張)か、システムがスケール・アップ(同じタイプの新しいサーバーを追加)されています。WebCenter Contentサーバー、Oracle SOA SuiteサーバーまたはImagingサーバーの出力ログには、次の例外が報告されます。

<Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "SOADataSource-rac0": Listener refused the connection with the following error:

ORA-12516, TNS:listener could not find available handler with matching protocol stack >

解決方法: データベース内のプロセス数を確認し、それにあわせて調整します。SYSユーザーとして、SHOW PARAMETERコマンドを発行します。

SHOW PARAMETER processes

次のSQLコマンドを使用して初期化パラメータを設定します。

ALTER SYSTEM SET processes=300 SCOPE=SPFILE

データベースを再起動します。

注意:
パラメータ値の変更に使用する方法は、パラメータが静的であるか動的であるかと、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用するかによって異なります。パラメータ・ファイル、サーバー・パラメータ・ファイルおよびパラメータ値の変更方法の詳細は、Oracle Database管理者ガイドを参照してください。

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

問題: 管理サーバー・ノードに障害が発生して別のノードへの手動フェイルオーバーが実行された後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。

<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ASERVER_HOME/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

解決方法: ノードの障害発生後にノードを復旧させるときに、ドメイン・ディレクトリに共有記憶域が使用されている場合、ロック・クリーンアップの失敗が原因で、管理サーバーのログにこのエラーが記録されることがあります。このエラーを解決するには、ファイルASERVER_HOME/
servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lokを削除します。

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

問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。

An error occurred during activation of changes, please see the log for details.
[Management:141190]The commit phase of the configuration update failed with an exception:
In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean

解決方法: これは、管理コンソールでサーバーの起動パラメータが変更された場合に発生する可能性があります。この場合、管理コンソールで、構成を変更した特定のサーバーのサーバー起動構成でユーザー名とパスワードの情報を指定します。

19.13.6 サーバー移行後にSOAサーバー、ImagingサーバーまたはCaptureサーバーがフェイルオーバーしない

問題: ローカルのノード・マネージャによる再起動試行回数が最大数に達した後で、フェイルオーバー・ノードのノード・マネージャがサーバーの再起動を試行しますが、サーバーが起動しません。ノード・マネージャの出力情報には、サーバーがフェイルオーバーしたことが報告されます。ノード・マネージャがOracle SOA Suiteサーバー、Oracle WebCenter Content: ImagingサーバーまたはOracle WebCenter Enterprise Captureサーバーの移行を試行した後でも、このサーバーが使用する仮想IPアドレスがフェイルオーバー・ノード内で有効になりません(フェイルオーバー・ノードでifconfigを実行しても、どのインタフェースの仮想IPアドレスも報告されません)。コマンドsudo ifconfig $INTERFACE $ADDRESS $NETMASKを実行しても、そのIPアドレスはフェイルオーバー・ノード内で有効になりません。

解決方法: sudo実行時にパスワード入力を要求するような権限と構成を設定しないでください。パスワード入力を要求しなくてもsudoが動作するようにsudoが構成されていることを、システム管理者に確認してください。

19.13.7 サーバー移行後にSOAサーバー、ImagingサーバーまたはCaptureサーバーにブラウザからアクセスできない

問題: サーバー移行は正常に実行されます(Oracle SOA SuiteサーバーまたはOracle WebCenter Content: Imagingサーバーがフェイルオーバー・ノード内で再起動される)が、Virtual_Hostname:7001/soa-infraのURLにWebブラウザからアクセスできません。元のホストではすでにサーバーが強制終了されており、フェイルオーバー・ノードのノード・マネージャでは、仮想IPアドレスが移行済でサーバーが起動していることが報告されます。Oracle SOA Suiteサーバー、ImagingサーバーまたはCaptureサーバーが使用する仮想IPアドレスに対して、クライアントのノード(ブラウザが使用されているノード)からpingを実行しても応答がありません。

解決方法: arpingコマンドがノード・マネージャによって実行されてARPキャッシュが更新されましたが、この更新が適切にブロードキャストされていません。この場合、そのノードが外部ノードからは到達不能になります。nodemanager.propertiesファイルを更新してMACBroadcastを追加するか、次のように手動でarpingを実行してください。

/sbin/arping -b -q -c 3 -A -I INTERFACE ADDRESS > $NullDevice 2>&1

ここで、INTERFACEは、仮想IPアドレスが有効化されているネットワーク・インタフェース、ADDRESSは仮想IPアドレスです。

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

問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しました。しかし、そのURLの1つに誤記がありました。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。

解決方法: 同じapp_domain名を指定してOAM構成ツールを実行すると、既存ポリシーへの新しいURLの追加のみが行われます。特定のURLを削除するには、Oracle Access Managerのポリシー・マネージャ・コンソールを使用してください。Oracle Access Managerのアクセス管理サイトにログインして、「ポリシー・ドメイン」→「SOA_EDG」(作成済のポリシー・ドメイン)→「リソース」タブをクリックし、誤ったURLを削除します。

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

問題: WebLogic Server管理コンソールにアクセスするためにOHSおよびLBRを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。

解決方法: これは、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、コンソールがその変更を反映しようとすると発生します。変更内容によっては、コンソールが管理サーバーのリスニング・アドレスにリダイレクトされることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、URLをwcc.example.com/console/console.portalに変更すれば、管理コンソールのホーム・ページに直接アクセスできます。

注意:
この項で説明されている変更の追跡を無効にしてある場合は、この問題は発生しません。

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

問題: Oracle Access Managerを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻りません)。

解決方法: これは、Oracle Access Manager SSOが構成され、管理コンソールが構成の変更を反映するように設定されている場合に発生することが予想されます(リダイレクトはなんらかの変更をアクティブ化する際に管理コンソールによって実行されます)。このリダイレクトにかかわらず、アクティブ化は完了します。連続して変更を行ってもリダイレクトされないようにするには、管理コンソールにアクセスして、「プリファレンス」→「共有プリファレンス」を選択し、「構成変更の追跡」チェック・ボックスの選択を解除します。

19.13.11 構成されたJOCポートがすでに使用中

問題: Javaオブジェクト・キャッシュ(OWSM管理対象サーバーなど)を使用している管理対象サーバーの起動に失敗します。次のエラーがログに表示されます。

J2EE JOC-058 distributed cache initialization failure
J2EE JOC-043 base exception:
J2EE JOC-803 unexpected EOF during read.

解決方法: JOCが取得しようとしているポートを別のプロセスが使用しています。そのプロセスを停止するか、このクラスタのJOCを再構成して、推奨されるポート範囲内で別のポートを使用するようにします。

19.13.12 CredentialAccessPermissionsを使用することで、Oracle WebCenter Content: Imagingが資格証明ストアから資格証明を読み取ることが可能になる

問題: Oracle WebCenter Content: Imagingが、起動中に資格証明のアクセス権限を作成し、system-jazn-data.xmlファイルのローカル・ドメイン・ディレクトリ・コピーを更新します。LDAPポリシー・ストアが構成されていない状態で環境をテストしている間に、Imagingサーバーの存在しているドメイン・ディレクトリに、system.jazn-data.xmlファイルへの手動の更新を管理サーバーがプッシュする可能性があります。これによって、ファイルのコピーが上書きされたり、Imagingコンソールの再起動またはアクセス時に、様々な例外およびエラーが発生したりする可能性があります。

解決方法: 資格証明のアクセス権限を再作成し、管理サーバーにある、system-jazn-data.xmlファイルのドメイン・ディレクトリ・コピーを更新するために、Oracle WebLogic Scripting ToolでgrantIPMCredAccessコマンドを使用します。このためには、Oracle WebCenter Contentに関連付けられたORACLE_HOMEからwlst.shを起動して管理サーバーに接続し、WCCHOST1でgrantIPMCredAccess()コマンドを実行します。

cd ORACLE_HOME/common/bin

./wlst.sh

wls:/offline> connect()

wls:/domain_name/serverConfig> grantIPMCredAccess()

注意:
接続時には、管理サーバー用の資格証明とアドレスを指定してください。

19.13.13 Oracle WebCenter Content: ImagingからOracle WebCenter Contentに情報量の多いドキュメントをアップロードする際のパフォーマンスを向上させる

問題: ホスト名ベースのセキュリティ・フィルタがOracle WebCenter Content (config.cfgファイル)で使用されている場合、Oracle WebCenter Content: ImagingからOracle WebCenter Contentに情報量の多いドキュメントをアップロードする際に、大きな遅延とパフォーマンスへの影響がシステム内に発生する可能性があります。この問題の原因は、Imagingサーバーからの接続を許可するためにOracle WebCenter Contentで必要とされるDNSの逆引き参照です。

解決方法: 災害からの保護および異なるホストへのリストアのためにシステム構成を準備する場合、ホスト名ベースのセキュリティ・フィルタを使用することをお薦めします(ホスト名ベースのセキュリティ・フィルタ使用時は、使用される構成がIPにとらわれないものになるため)。ただし、アップロードのパフォーマンスを向上させる必要がある場合は、ホスト名ベースのフィルタのかわりにIPベースのセキュリティ・フィルタを使用できます。

Oracle WebCenter Contentでホスト名ベースのセキュリティ・フィルタをIPベースのフィルタに変更する手順は次のとおりです。

1. テキスト・エディタでファイル/u01/oracle/config/domains/WCCDomain/WCC_Cluster/cs/config/config.cfgを開きます。

2. 次の行を削除またはコメント・アウトします。

SocketHostNameSecurityFilter=localhost|localhost.example.com|wcchost1vhn1|wcchost2vhn1
AlwaysReverseLookupForHost=Yes

3. WLS_CPT1およびWLS_CPT2管理対象サーバー(それぞれWCCHOST1VHN3およびWCCHOST2VHN3)のIPアドレス(リスニング・アドレス)をSocketHostAddressSecurityFilterパラメータ・リストに追加します。

SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1|X.X.X.X|Y.Y.Y.Y

この例では、X.X.X.XおよびY.Y.Y.Yは、それぞれWLS_CPT1とWLS_CPT2のリスニング・アドレスです。(同様に、アドレス127.0.0.1がこのリストに含まれている必要があります。)

4. 変更されたconfig.cfgファイルを保存しら、WebLogic Server管理コンソールを使用してOracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

19.13.14 管理対象サーバーのメモリー不足の問題

問題: 管理対象サーバーでメモリー不足が発生します。

解決方法: Java VMに割り当てられているメモリー・ヒープのサイズを少なくとも1GBに増やします。

Java VMに割り当てられているメモリー・ヒープのサイズを増やす手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「環境」をクリックし、「サーバー」をクリックします。

3. 管理対象サーバー名をクリックします。

4. 「構成」タブを開きます。

5. 2列目にある「サーバーの起動」タブを開きます。

6. 「引数」ボックスでメモリー・パラメータを追加します。例:

-Xms256m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m

注意:
メモリー・パラメータ要件は、各種のJVM (Sun JDK、Oracle JRockitなど)ごとに異なる可能性があります。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成』の管理対象サーバーのJava VMヒープ・サイズの増加に関する項を参照してください。

7. 構成の変更を保存します。

8. WebLogic Server管理コンソールを使用して、実行中のすべての管理対象サーバーを再起動します。

19.13.15 Oracle WebCenter Content管理対象サーバーのマスター・パスワードを再生成する

Oracle WebCenter Content管理対象サーバーのドメイン・ホームのcwallet.ssoファイルが、クラスタ間で不整合を生じたり、ASERVER_HOME/config/fmwconfigディレクトリにおける無効なコピーによってこのファイルが削除または誤って上書きされた場合は、ファイルを再生成できます。

Oracle WebCenter Content管理対象サーバーのマスター・パスワードを再生成する手順は次のとおりです。

1. すべてのOracle WebCenter Content管理対象サーバー(WLS_WCCx)を停止します。

2. MSERVER_HOME/config/fmwconfig/からcwallet.ssoファイルを削除します。

3. ASERVER_HOME/wcc_cluster_name/cs/config/privateからpassword.hdaファイルを削除します。

4. WCCHOST1でWLS_WCC1サーバーを起動します。

5. MSERVER_HOME/config/fmwconfig/にあるcwallet.ssoファイルの作成または更新、およびASERVER_HOME/wcc_cluster_name/cs/config/private/にあるpassword.hdaファイルの作成を確認します。

6. Oracle WebCenter Contentのシステム・プロパティのコマンドライン・ツールを使用して、データベースのパスワードを更新します。

7. スタンドアロンのOracle WebCenter Contentアプリケーション(Batchloader、システム・プロパティなど)が正しく機能しているか検証します。

8. MSERVER_HOME/config/fmwconfigディレクトリからASERVER_HOME/config/fmwconfigにある管理サーバーのドメイン・ディレクトリにcwallet.ssoファイルをコピーします。

9. 2番目のOracle WebCenter Content管理対象サーバーを起動し、更新されたcwallet.ssoファイルを、管理サーバーがWCCHOST2にあるMSERVER_HOME/config/fmwconfigディレクトリにプッシュし、そのファイルがWCCHOST1上のOracle WebCenter Content Serverによって作成または更新されたものと同じファイルであることを検証します。

10. スタンドアロンのOracle WebCenter Contentアプリケーション(Batchloader、システム・プロパティなど)が正しく機能しているか検証します。

11. スタンドアロンのOracle WebCenter Contentアプリケーションが両方のノードで同時に正しく機能することを検証します。

19.13.16 WebLogic Server管理コンソールからログアウトしても、ユーザー・セッションが終了しない

Oracle Access Managerのシングル・サインオン(SSO)を使用してWebLogic Serverの管理コンソールにログインする場合、ログアウトボタンをクリックしても、ユーザー・セッションが終了しません。これは、SSOのログアウトのガイドラインに従って、Oracle Access Managerログイン・ページにリダイレクトされるのではなく、ホームページがリロードされるからです。本当にログアウトするには、WebブラウザのCookieを手動で消去する必要があります。

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

問題: 次のトランザクション・タイムアウト・エラーがログに表示されます。

Internal Exception: java.sql.SQLException: Unexpected exception while enlisting
XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start()
failed on resource 'SOADataSource_soaedg_domain': XAER_NOTA : The XID
is not valid

解決方法: トランザクション・タイムアウトの設定を確認し、JTAトランザクション・タイムアウトがDataSource XAトランザクション・タイムアウトよりも短くなっており、distributed_lock_timeoutよりも短くなっていることを(データベースで)確認します。

すぐに使用できる構成の場合、SOAデータ・ソースはXAタイムアウトに値を設定していません。Set XA Transaction Timeout構成パラメータはWebLogic Server管理コンソールでは確認されません。この場合、データ・ソースは30に設定されたドメインレベルのJTAタイムアウトを使用します。また、データベースのdistributed_lock_timeoutのデフォルト値は60です。この結果、トランザクションにかかる時間がこれらの値よりも短いと想定されるシステムでは、SOA構成は正しく動作します。特定の操作に想定されるトランザクション時間に合せて、これらの値を調整します。

19.13.18 ファイルのキャッシュとロック

Oracle WebCenter Contentは、ファイルに対して固有のロック・メカニズムを使用するため、ファイル属性のキャッシュおよびクラスタ・ノードにより実行されるロックなしでファイルにアクセスする必要があります。ノードの1つがある状態のファイルにアクセスし、そのファイルがキャッシュされている場合、そのノードは別のノードがすでに実行しているプロセスの実行を試みる場合があります。または、特定のファイルがノード・クライアントの1つにロックされている場合、別のノードによるアクセスが妨げられる場合があります。ファイル共有でファイル属性のキャッシュを無効化すると、パフォーマンスに影響する可能性があります。よって、必要とされる特定のフォルダでのみキャッシュおよびロックを無効化することが重要です。たとえば、ネットワーク・ファイル・システム(NFS)を介して共有を作成している場合は、マウント・オプションでnoacおよびnolockを使用します。

19.13.19 リモートでデプロイされたアプリケーションで使用するアップロード・ディレクトリおよびステージ・ディレクトリの変更

アプリケーションをリモートでデプロイした場合は、ドメインを作成しmserverディレクトリに解凍した後、uploadディレクトリおよびstageディレクトリを絶対パスに更新する必要がある場合があります。絶対パスの名前により、リモートのデプロイメントの問題とステージ・モードを使用するデプロイメントの混乱を防ぐことができます。

これらのディレクトリに対するデフォルトのパス名は次のとおりです。

./servers/AdminServer/upload

./servers/server_name/stage

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

新規のOracle RACアプリケーションを開発する場合は、GridLinkデータ・ソースの使用をお薦めします。ただし、GridLinkデータ・ソースをサポートしないレガシー・アプリケーションおよびデータベースを使用している場合は、この付録の情報を参照してください。

この付録の構成は、次のとおりです。

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

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

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

マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。通常、このようなマルチ・データ・ソースへの接続リクエストはすべて、リストの先頭のデータ・ソースによって処理されます。データベース接続テストが失敗して接続を置き換えられなかった場合、またはデータ・ソースが中断された場合は、リストの次のデータ・ソースから順番に接続が検索されます。

Oracle RACでのマルチ・データ・ソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のOracle RACでのマルチ・データ・ソースの使用に関する項を参照してください。

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

ドメインを構成するときにデータ・ソースを構成します。たとえば、エンタープライズ・デプロイメントの参照トポロジの最初の管理ドメインを構成するときに、構成ウィザードを使用して、ドメインの特性とともにデータ・ソースも定義します。

このエンタープライズ・デプロイメント・ガイド内のトポロジの構成手順には、Oracle RACでGridLinkデータ・ソースを定義するための具体的な手順が含まれています。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLinkの手順を次の手順に置き換えます。

エンタープライズ・デプロイメント・トポロジ用のマルチ・データソースを構成する手順は次のとおりです。

1. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

1. 適切なスキーマを選択します。

2. 「コンポーネント・スキーマのRAC構成」については、「RACマルチ・データ・ソースへ変換」を選択します。

3. リポジトリ作成ユーティリティを実行すると、データ・ソースに含まれる同じスキーマの接頭辞とともに次のデータ・ソースが画面に表示されることを確認します。

4. 「次へ」をクリックします。

2. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面(図A-1)が開きます。

図A-1 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

この画面で、次の手順を実行します。

1. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「*OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11」を選択します。

- サービス名: データベースのサービス名を入力します。

- ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてWCCを使用しています。

- パスワード: スキーマへのアクセスに使用するパスワードを入力します。

2. ホスト名、インスタンス名およびポートを入力します。

3. 「追加」をクリックします。

4. この手順をOracle RACインスタンスごとに実行します。

5. 「次へ」をクリックします。

3. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

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

この付録は、Oracle WebCenter Contentで使用するOracle WebLogic Serverドメインのサーバーにターゲット設定されるアプリケーション、データ・ソース、永続ストア、Java Messaging Service (JMS)モジュール、起動クラスおよび停止クラスの一覧です。

この付録では次の項について説明します。

- 付録B.1「WebCenter Content管理対象サーバーで使用するアプリケーションとリソース」

- 付録B.2「Inbound Refinery管理対象サーバーで使用するアプリケーションとリソース」

- 付録B.3「Oracle SOA Suite管理対象サーバーで使用するアプリケーションとリソース」

- 付録B.4「Imaging管理対象サーバーで使用するアプリケーションとリソース」

- 付録B.5「Capture管理対象サーバーで使用するアプリケーションとリソース」

- 付録B.6「管理サーバーで使用するアプリケーションとリソース」

B.1 WebCenter Content管理対象サーバーで使用するアプリケーションとリソース

この項に示すアプリケーションおよびリソースは、次の管理対象サーバーが含まれるWebCenter Contentクラスタ(WCC_Cluster)にターゲット設定されます。

- WCCHOST1上のWLS_WCC1

- WCCHOST2上のWLS_WCC2

WebCenter Content用アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- Oracle UCMヘルプ

- Oracle UCMネイティブWebサービス

- Oracle UCM Webサービス

- Oracle WebCenter Content - コンテンツ・サーバー

- wsil-wls

WebCenter Contentのデータ・ソース

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

- CSDS

- leasing

WebCenter Contentの起動クラスおよび停止クラス

- oracle.jrf.AppContextStartup

- oracle.dms.wls.DMSStartup

- oracle.dms.wls.DMSShutdown

- oracle.as.jmx.framework.wls.spi.StartupListener

- oracle.ias.cache.Shutdown

- oracle.ias.cache.Startup

- oracle.security.jps.wls.JpsWlsStartupClass

- oracle.jrf.wls.JRFStartup

- oracle.core.ojdl.weblogic.ODLConfiguration

- oracle.j2ee.ws.server.WebServiceServerStartup

B.2 Inbound Refinery管理対象サーバーで使用するアプリケーションとリソース

次のアプリケーションとリソースは、Oracle WebCenter Content: Inbound Refineryサーバーおよび次の管理対象サーバーが含まれるIBR_Serversにターゲット設定されます。

- WCCHOST1上のWLS_IBR1

- WCCHOST2上のWLS_IBR2

Inbound Refinery用アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- Oracle UCMヘルプ

- Oracle UCMネイティブWebサービス

- Oracle UCM Webサービス

- Oracle WebCenter Content - Inbound Refinery

- wsil-wls

Inbound Refineryのデータ・ソース

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

Inbound Refineryの起動クラスおよび停止クラス

- oracle.jrf.AppContextStartup

- oracle.dms.wls.DMSStartup

- oracle.dms.wls.DMSShutdown

- oracle.as.jmx.framework.wls.spi.StartupListener

- oracle.ias.cache.Shutdown

- oracle.ias.cache.Startup

- oracle.security.jps.wls.JpsWlsStartupClass

- oracle.jrf.wls.JRFStartup

- oracle.core.ojdl.weblogic.ODLConfiguration

- oracle.j2ee.ws.server.WebServiceServerStartup

B.3 Oracle SOA Suite管理対象サーバーで使用するアプリケーションとリソース

この項に示すアプリケーションおよびリソースは、次の管理対象サーバーが含まれるOracle SOA Suiteクラスタ(SOA_Cluster)にターゲット設定されます。

- WCCHOST1上のWLS_SOA1

- WCCHOST2上のWLS_SOA2

Oracle SOA Suite用アプリケーション

- AQアダプタ

- b2bu

- composer

- DBアダプタ

- DefaultToDoTaskFlow

- DMSアプリケーション(11.1.1.1.0)

- ファイル・アダプタ

- FTPアダプタ

- JMSアダプタ

- MQシリーズ・アダプタ

- OracleAppsアダプタ

- OracleBamアダプタ

- soa-infra

- ソケット・アダプタ

- usermessagingdriver-email

- usermessagingserver

- worklistapp

- wsil-wls

- wsm-pm

Oracle SOA Suiteのデータ・ソース

- EDNDataSource

- EDNLocalTxDataSource

- mds-owsm

- mds-soa

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

- OraSDPMDataSource

- SOADataSource

- SOALocalTxDataSource

Oracle SOA Suiteの永続ストア

- BPMJMSFileStore_auto_1

- BPMJMSFileStore_auto_2

- SOAJMSFileStore_auto_1

- SOAJMSServer_auto_2

- UMSJMSFileStore_auto_1

- UMSJMSFileStore_auto_2

Oracle SOA SuiteのJMSデプロイメント・モジュール

- BPMJMSServer_auto_1

- BPMJMSServer_auto_2

- SOAJMSServer_auto_1

- SOAJMSServer_auto_2

- UMSJMSServer_auto_1

- UMSJMSServer_auto_2

Oracle SOA Suiteの起動クラスおよび停止クラス

- oracle.jrf.AppContextStartup

- oracle.dms.wls.DMSStartup

- oracle.dms.wls.DMSShutdown

- oracle.as.jmx.framework.wls.spi.StartupListener

- oracle.ias.cache.Shutdown

- oracle.ias.cache.Startup

- oracle.security.jps.wls.JpsWlsStartupClass

- oracle.jrf.wls.JRFStartup

- oracle.core.ojdl.weblogic.ODLConfiguration

- oracle.bpel.services.common.util.GenerateBPMCryptoKey

- oracle.j2ee.ws.server.WebServiceServerStartup

B.4 Imaging管理対象サーバーで使用するアプリケーションとリソース

次のアプリケーションとリソースは、次の管理対象サーバーが含まれるImagingクラスタ(IMG_Cluster)にターゲット設定されます。

- WCCHOST1上のWLS_IMG1

- WCCHOST2上のWLS_IMG2

Imaging用アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- imaging

- imaging-vc

- wsil-wls

Imagingのデータ・ソース

- IPMDS

- mds-owsm

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

Imagingの永続ストア

- IMGJMSServer1Store

- IMGJMSServer2Store

ImagingのJMSデプロイメント・モジュール

- IpmJmsServer1

- IpmJmsServer2

- ViewerJmsServer1

- ViewerJmsServer3

Imagingの起動クラスおよび停止クラス

- oracle.jrf.AppContextStartup

- oracle.dms.wls.DMSStartup

- oracle.dms.wls.DMSShutdown

- oracle.as.jmx.framework.wls.spi.StartupListener

- oracle.ias.cache.Shutdown

- oracle.ias.cache.Startup

- oracle.security.jps.wls.JpsWlsStartupClass

- oracle.jrf.wls.JRFStartup

- oracle.core.ojdl.weblogic.ODLConfiguration

- oracle.j2ee.ws.server.WebServiceServerStartup

B.5 Capture管理対象サーバーで使用するアプリケーションとリソース

次のアプリケーションとリソースは、Oracle WebCenter Enterprise Captureサーバーおよび次の管理対象サーバーが含まれるCPT_Clusterにターゲット設定されます。

- WCCHOST1上のWLS_CPT1

- WCCHOST2上のWLS_CPT2

Capture用アプリケーション

- capture

Captureのデータ・ソース

- capture-ds

- capture-mds-ds

- mds-owsm

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

Captureの起動クラスおよび停止クラス

- oracle.jrf.AppContextStartup

- oracle.dms.wls.DMSStartup

- oracle.dms.wls.DMSShutdown

- oracle.as.jmx.framework.wls.spi.StartupListener

- oracle.ias.cache.Shutdown

- oracle.ias.cache.Startup

- oracle.security.jps.wls.JpsWlsStartupClass

- oracle.jrf.wls.JRFStartup

- oracle.core.ojdl.weblogic.ODLConfiguration

- oracle.j2ee.ws.server.WebServiceServerStartup

B.6 管理サーバーで使用するアプリケーションとリソース

次のアプリケーションおよびリソースは、WCCHOST1およびWCCHOST2で実行されるOracle WebLogic Server管理サーバー、AdminServerにターゲット設定されます。

管理サーバー用アプリケーション

- DMSアプリケーション(11.1.1.1.0)

- em

- FMW Welcomeページ・アプリケーション(11.1.0.0.0)

- EM (11.1.1)

- wsil-wls

管理サーバーのデータ・ソース

- mds-owsm

- mds-soa

- opss-audit-viewDS

- opss-audit-DBDS

- opss-DBDS

管理サーバーの起動クラスおよび停止クラス

- oracle.jrf.AppContextStartup

- oracle.dms.wls.DMSStartup

- oracle.dms.wls.DMSShutdown

- oracle.as.jmx.framework.wls.spi.StartupListener

- oracle.ias.cache.Shutdown

- oracle.ias.cache.Startup

- oracle.security.jps.wls.JpsWlsStartupClass

- oracle.jrf.wls.JRFStartup

- oracle.core.ojdl.weblogic.ODLConfiguration

- oracle.j2ee.ws.server.WebServiceServerStartup

索引
A B C D E F G H I J K L M N O P R S T U V W X

A

Oracle Access Managerのアクセス・ファイル, 18.3.5

アドレス・セキュリティ・フィルタ, 10.4.3, 11.5.1, 13.5.11, 14.5.6, 19.13.13

管理ロール, 18.2.4.2

admin.conf, 9.6.1

admin.example.com, 3.2.1

管理コンソール

ドメインの作成, 8

変更をアクティブ化するときのエラー, 19.13.5

ホーム・ページへのリダイレクト, 19.13.10

ログイン画面へのリダイレクト, 19.13.9

管理サーバー

アプリケーション・ディレクトリの場所, 4.4.3.1, 4.4.3.2

ドメインのバックアップ, 8.7

WCCHOST1のboot.properties, 8.4.1, 15.5.3.2

--用のOracle HTTP Serverの構成, 9.6.1

--を使用したドメインの作成, 8.3

cwalletファイル, 10.4.4, 19.13.15

ホスト名検証の無効化, 8.4.5, 15.5.3.6

WCCHOST1へのフェイルオーバー, 19.8.3

WCCHOST2へのフェイルオーバー, 8.6, 19.8

リスニング・アドレス, 8.3, 15.5.2

リスニング・ポート, 8.3, 15.5.2

ノード・マネージャのリスニング・アドレス, 8.3, 15.5.2

ポート, 3.5

再起動, 10.3, 11.3, 12.4, 13.4, 14.4

フロントエンドURLの設定, 9.6.3

起動の失敗, 19.13.4

WCCHOST1での起動, 8.4.3, 15.5.3.4

検証, 8.4.4, 15.5.3.5

管理ユーザーと管理グループ, 18.2.4.1 ADMINVHN, 3.4 Webゲートのエージェント, 18.3.3 アプリケーション層, 1.1.4, 4.4.3.1, 4.4.3.2 APPLICATION_HOME, 4.2 アーティファクト, 19.3 ASERVER_HOME, 4.2, 4.2, 4.4.3.1, 4.4.3.2 認証プロバイダ, 18.3.6 認証スキーム, 18.3.3.4 オーセンティケータ

LDAP, 18.2.2

Oracle Internet Directory, 18.2.2

Oracle Virtual Directory, 18.2.2

認可スキーム, 18.3.3.4 AXF for BPEL, インストール, 7.3.4.1 AXF for BPM, インストール, 7.3.4.1

B

バックアップ

管理サーバーを含むドメインの作成後, 8.7

Captureを含むドメインの拡張後, 14.9

Oracle SOA Suiteを含むドメインの拡張後, 12.12

Oracle WebCenter Contentを含むドメインの拡張後, 10.8

Oracle WebCenter Content: Imagingを含むドメインの拡張後, 13.9

Oracle Fusion Middlewareのインストール後, 7.3.5

データベースへのメタデータ・リポジトリのロード後, 5.5

Oracle HTTP Serverの設定後, 7.2.3

バックアップ

構成ファイル, 18.3.6.1

ドメイン, 12.3

エンタープライズ・デプロイメント, 19.9

インストール, 18.5

Oracle Access Manager 11gでCookieを使用しない基本スキーム, 18.3.3.5 ベスト・プラクティス

SQLNet接続のタイムアウト, 19.11

管理サーバーのboot.properties, 8.4.1, 15.5.3.2, 18.2.4.3 BPEL CSF資格証明, 13.5.13

C

Capture, 2.2

Oracle WebCenter Contentセキュリティ・フィルタへのCaptureサーバーのリスニング・アドレスの追加, 14.5.6

ドメインのバックアップ, 14.9

ドメインの拡張, 14.3

ポート, 3.5

仮想ホスト名, 14.2

証明書

ホスト名の検証, 16.3

自己署名, 16.3.1

クロックの同期, 1.3

サーバー, 1.3

クラスタ・エージェント, 2.3 クラスタ通信, 1.1.6 クラスタ

フロントエンドHTTPホストとポート, 12.8.2, 14.6.2

ノード間でのマスター・パスワードの共有, 10.4.4, 19.13.15

クラスタウェア, 2.3 コンポジット, 12.5, 19.3 構成

BPEL CSF資格証明, 13.5.13

ドメインの作成, 8

ノード・マネージャのカスタム・キーストア, 16.3.4

データベース, 5.2

Capture用のデフォルトのJMS永続ストア, 14.5.5

Oracle WebCenter Content: Imaging用のデフォルトのJMS永続ストア, 13.5.3

デフォルトの永続ストア, 12.9

環境変数, 4.2

Captureを含むドメインの拡張, 14

Inbound Refineryを含むドメインの拡張, 11

Oracle SOA Suiteコンポーネントを含むドメインの拡張, 12

Oracle WebCenter Contentを含むドメインの拡張, 10

Oracle WebCenter Content: Imagingを含むドメインの拡張, 13

フロントエンドHTTPホストとポート, 12.8.2, 14.6.2

管理コンソールのフロントエンドURL, 9.6.3

GDFontPath MBean, 13.5.7

Imaging用の入力ディレクトリ, 13.5.7

Javaオブジェクト・キャッシュ, 12.7

使用JOCポート, 19.13.11

LDAP, 1.5

ロード・バランサ, 3.3

ノード・マネージャ, 16

WLS_IMG管理対象サーバー用のノード・マネージャ, 10.7, 11.7, 12.10, 13.7, 14.7

WLS_WCC管理対象サーバー用のノード・マネージャ, 10.7, 11.7, 12.10, 13.7, 14.7

Oracle Coherence, 12.5

Oracle HTTP Server, 9.4

管理サーバー用のOracle HTTP Server, 9.6.1

WLS_CPT管理対象サーバー用のOracle HTTP Server, 14.6, 14.6.1

WLS_IMG管理対象サーバー用のOracle HTTP Server, 13.6, 13.6.1

WLS_SOA管理対象サーバー用のOracle HTTP Server, 12.8.1

WLS_WCC管理対象サーバー用のOracle HTTP Server, 10.6.1, 15.8.1

Oracle Web層, 9

ドメイン構成の伝播, 10.4.2, 11.4.1, 13.5.2, 14.5.2

Imaging用のサンプル・ディレクトリ, 13.5.7

サーバー移行, 17

WLS_CPT管理対象サーバー用のサーバー移行, 14.8

WLS_IMG管理対象サーバー用のサーバー移行, 13.8

WLS_SOA管理対象サーバー用のサーバー移行, 12.11

Oracle WebCenter Contentのサービス再試行, 10.4.8

共有記憶域, 4.5

サーバー移行のターゲット, 17.6

UMSドライバ, 19.5

WLS_WCC1管理対象サーバー, 10.4.3

WLS_WCC2管理対象サーバー, 10.4.5

ワークフロー接続, 13.5.14

構成MBean, 13.5.7 構成ウィザード

管理サーバーを含むドメインの作成, 8.3

Captureを含むドメインの拡張, 14.3

Oracle SOA Suiteコンポーネントを含むドメインの拡張, 12.3

Oracle WebCenter Contentを含むドメインの拡張, 10.2

Oracle WebCenter Content: Imagingを含むドメインの拡張, 13.3

Oracle WebCenter Content: Inbound Refineryを含むドメインの拡張, 11.2

「GridLink RACコンポーネント・スキーマの構成」画面, 8.3, 10.2, 12.3, 13.3, 14.3 configure-joc.py, 12.7 configure-joc.pyスクリプト, 12.7 Oracle WebCenter ContentへのImagingの接続, 13.5.12 コンテンツ・サーバー

Inbound Refineryコンポーネントの有効化, 11.5.4.2

インタフェース, 2.2, 15.1

変換ジョブ、Inbound Refinery、設定, 11.5.4 Oracle Access Manager 11gでCookieを使用しないスキーム, 18.3.3.5 createCentralInventory.sh script, 7.2.2, 7.3.3 ドメインの作成, 8 Middlewareホームの作成, 7.3.3 資格証明ストア, 19.13.12 CredentialAccessPermissions, 19.13.12 資格証明, 1.5 Oracle WebCenter Content: Imagingの資格証明, 13.5.13 Oracle WebCenter Content: ImagingのCSF資格証明, 13.5.13 カスタム・キーストア, 16.3.4, 16.3.5 cwallet.sso, 10.4.4, 19.13.15

D

データ・ソース, 17.3

データ・ソース, A.2

データ層, 1.1.5, 5.2.1

データベース, 1.1.5

バックアップ, 5.5

コンポーネント, 5.4

接続, 5.4

ホストの要件, 5.2.1

初期化パラメータ, 5.2.3

リスナー・ポート, 1.1.5

メタデータ・リポジトリのロード, 5.4

プロセスの最大数, 19.13.3

ポート, 3.5

スキーマの接頭辞, 5.4

サービス, 5.3

設定, 5.2

サポートされているバージョン, 5.2.2

データベース・ベースOPSSセキュリティ・ストア, 8.5 DBMS_STATS, 19.10 コンポジットのデプロイ, 12.5 コンポジットとアーティファクトのデプロイ, 19.3 ディレクトリ環境変数, 4.2 ディレクトリ構造, 4.4

アプリケーション・ディレクトリ(管理サーバー), 4.4.3.1, 4.4.3.2

ドメイン・ディレクトリ

管理サーバーのディレクトリ, 4.4.3.1, 4.4.3.2

管理対象サーバーのディレクトリ, 4.4.3.1, 4.4.3.2

JMSファイル・ストア, 4.4.3.1, 4.4.3.2 Middlewareホーム, 4.4.3.1, 4.4.3.2 Oracle共通ホーム, 4.4.3.1, 4.4.3.2 Oracle WebCenter ContentのOracleホーム, 4.4.3.1, 4.4.3.2 Tlogs, 4.4.3.1, 4.4.3.2 Web層のOracleホーム, 4.4.3.1 WebLogic Serverホーム, 4.4.3.1, 4.4.3.2 ホスト名検証の無効化

管理サーバー, 8.4.5, 15.5.3.6

WLS_CPT管理対象サーバー用, 14.5.1

WLS_IMG管理対象サーバー用, 13.5.1

WLS_SOA管理対象サーバー用, 12.6.1

管理対象サーバー, 8.4.5, 15.5.3.6

WebLogic Serverインスタンス, 8.4.5, 15.5.3.6

ドメイン

バックアップ, 12.3

ドメインの作成, 8

Captureを含むドメインの拡張, 14

Oracle SOA Suiteコンポーネントを含むドメインの拡張, 12

Oracle WebCenter Contentを含むドメインの拡張, 10, 11

Oracle WebCenter Content: Imagingを含むドメインの拡張, 13

ドメイン構成の伝播, 10.4.2, 11.4.1, 13.5.2, 14.5.2

ドメイン構成

伝播, 12.6.2

ドメイン・ディレクトリ

管理サーバーのディレクトリ, 4.4.3.1, 4.4.3.2

管理対象サーバーのディレクトリ, 4.4.3.1, 4.4.3.2

E

Oracle WebCenter ContentでのImagingの有効化, 13.5.8

WCCHOST1でのWCCHOST1VHN1の有効化, 8.2

エンタープライズ・デプロイメント

バックアップとリカバリ, 19.9

利点, 2.4

ディレクトリ構造, 4.4

環境変数, 4.2

高可用性, 2.4.2

ソフトウェアのインストール, 7

LDAP, 1.5

概要, 2.1

ポリシーと資格証明, 1.5

ポリシー・ストア, 1.5

セキュリティ, 2.4.1

ソフトウェア, 1.4

用語, 2.3

トポロジ, 1.1

環境権限, 17.5 環境変数, 4.2 ドメインの拡張

Capture, 14

Inbound Refinery, 11

Oracle SOA Suiteコンポーネント, 12

Oracle WebCenter Content, 10

Oracle WebCenter Content: Imaging, 13

F

フェイルバック, 2.3

WCCHOST1への管理サーバーのフェイルオーバー, 19.8.3

WCCHOST2への管理サーバーのフェイルオーバー, 8.6, 19.8

フェイルオーバー, 2.3, 19.13.4, 19.13.6

ファイル形式, Inbound Refinery変換用の選択, 11.5.4.3

ファイアウォール, 3.5

FMW、「Oracle Fusion Middleware」を参照

フロントエンドHTTPホストとポート, 12.8.2, 14.6.2

管理コンソールのフロントエンドURL, 9.6.3

Fusion Middleware、「Oracle Fusion Middleware」を参照

G

GCCライブラリ, 18.3.4.1

GDFontPath MBean, 13.5.7

自己署名証明書の生成, 16.3.1

GridLinkデータ・ソース, 17.3

構成, 8.3, 10.2, 12.3, 13.3, 14.3

構成の確認, 10.4.6, 12.6.5, 13.5.5, 14.5.4

GridLink RACコンポーネント・スキーマ,8.3, 10.2, 12.3, 13.3, 14.3

H

ハードウェア要件, 1.2

高可用性, 2.4.2

ホーム・ページ、リダイレクト, 19.13.10

ホスト名に基づくセキュリティ・フィルタ, 13.5.11, 14.5.6

ホスト名の検証

ノード・マネージャの証明書, 16.3

管理サーバーに対する--の無効化, 8.4.5, 15.5.3.6

WLS_CPT管理対象サーバーに対する--の無効化, 14.5.1

WLS_IMG管理対象サーバーに対する--の無効化, 13.5.1

WLS_SOA管理対象サーバーに対する--の無効化, 12.6.1

管理対象サーバーに対する無効化, 8.4.5, 15.5.3.6

WebLogicサーバー・インスタンスに対する無効化, 8.4.5, 15.5.3.6

管理対象サーバー, 16.3.6

ホスト名

ネットワーク, 2.3

Oracle Coherence, 12.5.2

物理, 2.3

仮想, 2.3

ホスト

データベース, 5.2.1

httpd.conf, 9.5.1

I

IDアサータ, 18.3.6.2

アイデンティティ・キーストア, 16.3.2

IDM、「Oracle Identity Management」を参照

Imaging、「Oracle WebCenter Content: Imaging」を参照

Inbound Refinery, 2.2

構成, 11.5

Content Server, 変換用ジョブの設定, 11.5.4

変換ジョブ

コンテンツ・サーバー, 11.5.4.1

設定, 11.5.4

Content Serverでのコンポーネントの有効化, 11.5.4.2 ドメインの拡張, 11.2 Content Serverからの送信プロバイダ, 11.5.4.1 変換のファイル形式の選択, 11.5.4.3 起動, 11.4.2 誤ったURL, 19.13.8 増分エンタープライズ・デプロイメント, 1.6.3 Oracle SOA Suiteのインフラストラクチャ・データベース, 19.4 データベースの初期化パラメータ, 5.2.3 Oracle WebCenter Content: Imaging用の入力ディレクトリ, 13.5.7 Oracle WebCenter Content: Imaging用の入力ファイル戦略, 19.2 inspection.wsil, 18.3.3.4 インストール

AXF for BPEL, 7.3.4.1

AXF for BPM, 7.3.4.1

ドメインの作成, 8

Captureを含むドメインの拡張, 14

Oracle SOA Suiteコンポーネントを含むドメインの拡張, 12

Oracle WebCenter Contentを含むドメインの拡張, 10, 11

Oracle WebCenter Content: Imagingを含むドメインの拡張, 13

Imaging, 7.3.4.1

Middlewareホーム, 7.3.3

モジュラ・アプローチ, 1.6.3

Oracle Fusion Middleware, 7.3

Oracle Fusion Middlewareのコンポーネント, 7.3.4

Oracle HTTP Server, 7.2

Oracle IRM, 7.3.4.1

Oracle WebCenter Content, 7.3.4.1, 7.3.4.2

Oracle WebLogic Server, 7.3.3, 7.3.3, 7.3.3

手順, 1.6

ソフトウェア, 7.1

Oracle Web Tierの検証, 9.3

Webゲート, 18.3.4.2

インストールするコンポーネント, 1.4

統合

Oracle Access Manager 11g, 18.3

IPアドレス

物理, 2.3, 3.4

仮想, 2.3, 3.4

IPに基づくセキュリティ・フィルタ, 19.13.13 I/PM、「Oracle WebCenter Content: Imaging」を参照

J

Javaオブジェクト・キャッシュ, 12.7, 19.13.11

Java VM、--のメモリー・ヒープ, 19.13.14

JAVA_HOME, 4.2, 4.2

JMSファイル・ストア

場所, 4.4.3.1, 4.4.3.2

JMS永続ストア

Capture, 14.5.5

Oracle WebCenter Content: Imaging, 13.5.3

JOCポート, 19.13.11

K

キーストア

カスタム, 16.3.4, 16.3.5

アイデンティティ, 16.3.2

トラスト, 16.3.3

keytoolユーティリティ, 16.3.3

L

LDAP, 1.5

管理グループへの管理ロールの割当て, 18.2.4.2

WebLogic Server管理者の移動, 18.2.4

管理ユーザーと管理グループのプロビジョニング, 18.2.4.1

LDAPオーセンティケータ, 18.2.2 LDAPサーバー, 1.1.2 サーバー移行用のリース表, 17.2 leasing.ddlスクリプト, 17.2 ライブラリ

Webゲートに必要なGCC, 18.3.4.1

GCCのインストール, 18.3.4.1, 18.3.4.1, 18.3.4.2.2

Webゲートに必要, 18.3.4.1

リスニング・アドレス

管理サーバー, 8.3, 15.5.2

Capture, 14.5.6

Oracle WebCenter Content: Imaging, 13.5.11

WLS_CPT管理対象サーバー, 14.3, 14.5.6

WLS_IMG管理対象サーバー, 13.3, 13.5.11

WLS_SOA管理対象サーバー, 12.3

WLS_WCC管理対象サーバー, 10.2, 11.2

リスニング・ポート

管理サーバー, 8.3, 15.5.2

WLS_CPT管理対象サーバー, 14.3

WLS_IMG管理対象サーバー, 13.3

WLS_SOA管理対象サーバー, 12.3

WLS_WCC管理対象サーバー, 10.2, 11.2

リスナー・ポート, 1.1.5 ロード・バランサ, 2.4.1, 9.5

構成, 3.3

Oracle HTTP Serverを使用した構成, 9.4

ポート, 3.5, 3.5

要件, 1.1.3, 3.3

仮想サーバー, 3.3.2

データベースへのメタデータ・リポジトリのロード, 5.4 ノード・マネージャのログ・ファイル, 16.1, 16.2 ログイン画面、リダイレクト, 19.13.9

M

管理対象サーバー

ホスト名検証の無効化, 8.4.5, 15.5.3.6

管理対象サーバー

既存ノードへの追加(Capture), 19.6.3, 19.6.3

既存のノードへの追加(Oracle SOA Suite), 19.6.4

既存のノードへの追加(Oracle WebCenter Content: Imaging), 19.6.2

既存のノードへの追加(WebCenter Content), 19.6.1

既存のノードへの追加(WebCenter Content: Imaging), 19.6.2

新規のノードへの追加(Capture), 19.7.3, 19.7.3

新規のノードへの追加(Oracle SOA Suite), 19.7.4

新規のノードへの追加(Oracle WebCenter Content), 19.7.1

新規のノードへの追加(Oracle WebCenter Content: Imaging), 19.7.2, 19.7.2

カスタム・キーストア, 16.3.5

ホスト名検証の無効化, 12.6.1, 13.5.1, 14.5.1

ホスト名の検証, 16.3.6

Java VMのメモリー・ヒープ, 19.13.14

メモリー不足の問題, 19.13.14

ドメイン変更の伝播, 12.6.2

WLS_CPT, 14.3, 14.5.3.2, 14.6, 14.6.1, 14.8

WLS_IMG, 10.7, 11.7, 12.10, 13.3, 13.5.4, 13.6, 13.6.1, 13.7, 13.8, 14.7

WLS_SOA, 12.3, 12.8.1, 12.11

WLS_WCC, 10.2, 10.6.1, 10.7, 11.2, 11.7, 12.10, 13.7, 14.7, 15.8.1

SOAインフラストラクチャ・データベースでの領域の管理, 19.4 トポロジの管理, 19 手動フェイルオーバー, 19.13.4 仮想IPアドレスのマッピング, 3.4 マスター・パスワード, 10.4.4, 19.13.15 MBean

構成, 13.5.7

GDFontPath, 13.5.7

Java VMのメモリー・ヒープ, 19.13.14 メタデータ・リポジトリ, 5.4 Middlewareホーム, 2.3

アプリケーション層, 4.4.3.1, 4.4.3.2

サーバーの移行、「サーバー移行」を参照, 17 トポロジの監視, 19.1 共有記憶域の場所のマウント, 4.5 MSERVER_HOME, 4.2, 4.2, 4.4.3.1, 4.4.3.2 MW_HOME, 4.2, 4.2, 4.2, 4.4.3.1, 4.4.3.2 MW_HOME(アプリケーション層), 4.2, 4.2, 4.2

N

ネットワーク

ファイアウォール, 3.5

物理IPアドレス, 3.4

ポート, 3.5

仮想IPアドレス(VIP), 3.4

仮想サーバー名, 3.2

ネットワーク・ホスト名, 2.3 ノード・マネージャ, 16.3.1

WLS_IMG管理対象サーバー用の構成, 10.7, 11.7, 12.10, 13.7, 14.7

WLS_WCC管理対象サーバー用の構成, 10.7, 11.7, 12.10, 13.7, 14.7

カスタム・キーストア, 16.3.4

ホスト名検証証明書, 16.3

アイデンティティ・キーストア, 16.3.2

管理サーバーのリスニング・アドレス, 8.3, 15.5.2

WCCHOSTに対するリスニング・アドレス, 10.2, 11.2, 13.3, 13.3, 14.3, 14.3

ログ・ファイル, 16.1, 16.2

ポート, 3.5

プロパティ・ファイル, 17.4

設定, 16

起動, 16.4

WCCHOSTでの起動, 10.4.1

WCCHOST1での起動, 8.4.2, 15.5.3.3

トラスト・キーストア, 16.3.3

ノード

既存の--へのサーバーの追加(Oracle SOA Suite), 19.6.4

既存の--へのサーバーの追加(WebCenter Content), 19.6.1

既存の--へのサーバーの追加(WebCenter Content: Imaging), 19.6.2

新規の--へのサーバーの追加(Capture), 19.7.3

新規の--へのサーバーの追加(Oracle SOA Suite), 19.7.4

新規の--へのサーバーの追加(WebCenter Content), 19.7.1

新規の--へのサーバーの追加(Oracle WebCenter Content: Imaging), 19.7.2

1次, 2.3

2次, 2.3

WCCHOST, 8.2

O

OAM11gRequest.xml, 18.3.3.2

OAMHOST, 1.1.3

oamregツール, 18.3.3.3

OHS、「Oracle HTTP Server (OHS)」を参照

OPSSセキュリティ・ストア

データベース・ベース, 8.5

ファイルベース, 8.5

opss_purge_changelog, 19.10 Oracle Access Manager 11gの統合, 18.3

アクセス・ファイル, 18.3.5

Cookieを使用しない基本スキーム, 18.3.3.5

GCCライブラリ, 18.3.4.1

IDアサータ, 18.3.6.2

inspection.wsil, 18.3.3.4

Webゲートのインストール, 18.3.4.2

oamregツール, 18.3.3.3

プロバイダの順序, 18.3.6.3

概要, 18.3.1

前提条件, 18.3.2

Webゲート・エージェントの登録, 18.3.3

RREGツール, 18.3.3.1

OAM11gRequestファイルの更新, 18.3.3.2

WebLogic Server認証プロバイダ, 18.3.6

Oracle Access Managerの統合

検証, 18.4

Oracle Application Development Framework, 15 Oracle BI EE

アップグレード・ロードマップ表, 1.6.2

Oracle Coherence, 12.5, 19.13.2 Oracle共通ホーム, 2.3, 4.4.3.1, 4.4.3.2 Oracle Fusion Middleware

バックアップ, 7.3.5

Middlewareホームの作成, 7.3.3

コンポーネントのインストール, 7.3.4

ソフトウェアのインストール, 7.3

Oracle Fusion Middleware

Oracle WebLogic Serverのインストール, 7.3.3

Oracleホーム, 2.3, 4.4.3.1, 4.4.3.2 Oracle HTTP Server

検証, 9.5

Oracle HTTP Server (OHS), 1.1.3

バックアップ, 7.2.3

構成, 9.4

管理サーバーに対する--の構成, 9.6.1

WLS_CPT管理対象サーバーに対する--の構成, 14.6, 14.6.1

WLS_IMG管理対象サーバーに対する--の構成, 13.6, 13.6.1

WLS_SOA管理対象サーバーに対する--の構成, 12.8.1

WLS_WCC管理対象サーバーに対する--の構成, 10.6.1, 15.8.1

インストール, 7.2

ロード・バランサ, 3.3.2, 9.4

場所, 7.2.2

ポート, 3.5, 3.5, 7.2.1

管理サーバー・アクセスの検証, 9.6.4, 19.8.2

Captureサーバーへのアクセスの検証, 14.6.3

Oracle SOA Suiteサーバーへのアクセスの検証, 12.8.3

Oracle WebCenter Contentサーバーへのアクセスの検証, 10.6.3, 15.8.2

Oracle WebCenter Content: Imagingサーバーへのアクセスの検証, 13.6.2

SSOの検証, 18.4

Oracle Identity Management

概要, 1.1.2

Oracleインスタンス, 2.3 Oracle Internet Directoryオーセンティケータ, 18.2.2 Oracle IRM, インストール, 7.3.4.1 Oracle Notification Service

構成, 8.3, 10.2, 12.3, 13.3, 14.3

構成の確認, 10.4.6, 12.6.5, 13.5.5, 14.5.4

Oracle SOA Suite

ドメインのバックアップ, 12.12

--を含むドメインの拡張, 12, 12.3

インストール, 7.3.4.2

ポート, 3.5

Oracle UCM、「Oracle WebCenter Content」を参照 Oracle Virtual Directoryオーセンティケータ, 18.2.2 Oracle Web Services Manager, 1.1.4 Oracle Web Services Manager (WSM), 12.7, 19.12 Oracle Web層, 1.1.3

構成, 9

Oracleホーム, 4.4.3.1

インストールの検証, 9.3

WT_ORACLE_HOME, 4.2

Oracle WebCenter Capture、「Capture」を参照 Oracle WebCenter Content, 2.2

ドメインのバックアップ, 10.8

Imagingの接続の作成, 13.5.12

Imagingの有効化, 13.5.8

--を含むドメインの拡張, 10, 10.2, 11

Imagingを含むドメインの拡張, 13.3

Inbound Refineryを含むドメインの拡張, 11.2

インストール, 7.3.4.1

Oracleホーム, 4.4.3.1, 4.4.3.2

ポート, 3.5

Webサービスのセキュリティ, 19.12

サービス再試行, 10.4.8

Oracle WebCenter Content: Imaging, 2.2

Oracle WebCenter Contentセキュリティ・フィルタへのImagingサーバーのリスニング・アドレスの追加, 13.5.11

ドメインのバックアップ, 13.9

BPEL CSF資格証明の構成, 13.5.13

ワークフロー接続の構成, 13.5.14

Oracle WebCenter Contentへの接続の作成, 13.5.12

Oracle WebCenter Contentでの--の有効化, 13.5.8

--を含むドメインの拡張, 13

インストール, 7.3.4.1

IPに基づくセキュリティ・フィルタ, 19.13.13

入力ファイルを最適化する戦略, 19.2

ポート, 3.5

資格証明ストアからの資格証明の読取り, 19.13.12

Webサービスのセキュリティ, 19.12

Oracle WebCenter Content: Inbound Refinery, 「Inbound Refinery」を参照 Oracle WebCenter Enterprise Capture、「Capture」を参照 Oracle WebLogic Scripting Tool (WLST)

管理サーバーの起動, 8.4.3, 8.4.5, 8.5.2, 8.5.2, 8.7, 8.7, 9.6.2, 9.6.2, 10.3, 10.3, 15.5.3.4, 15.5.3.6, 15.5.3.6

Oracle WebLogic Server, 1.1.4

インストール, 7.3.3

ログアウト, 19.13.16

Oracle WSM、「Oracle Web Services Manager」を参照 ORACLE_COMMON_HOME, 4.2, 4.2, 4.4.3.1, 4.4.3.2 ORACLE_HOME, 4.2, 4.2, 4.4.3.1, 4.4.3.2 ORACLE_INSTANCE, 4.2 oracleRoot.shスクリプト, 7.2.2 Content ServerからInbound Refineryへの送信プロバイダ, 11.5.4.1 メモリー不足の問題, 19.13.14

P

データベースのパラメータ, 5.2.3

永続ストア, 12.9

Capture, 14.5.5

Oracle WebCenter Content: Imaging, 13.5.3

物理ホスト名, 2.3 物理IPアドレス, 2.3 ポリシー, 1.5 ポリシー・ストア, 1.5 ポート, 3.5

管理サーバー, 3.5

データベース, 3.5

フロントエンドHTTPポート, 12.8.2, 14.6.2

Imaging, 3.5, 3.5

使用JOCポート, 19.13.11

ロード・バランサ, 3.5, 3.5

ノード・マネージャ, 3.5

Oracle HTTP Server, 3.5, 3.5, 7.2.1

Oracle SOA Suite, 3.5

Oracle WebCenter Content, 3.5

データベース・スキーマの接頭辞, 5.4 1次ノード, 2.3 データベースでのプロセス, 5.2.3, 19.13.3 ドメイン変更の伝播, 12.6.2 ドメイン構成の伝播, 10.4.2, 11.4.1, 13.5.2, 14.5.2 ノード・マネージャのプロパティ・ファイル, 17.4 保護URL, 18.3.3.2 Oracle Access Managerのプロバイダの順序, 18.3.6.3

R

RACデータベース, 1.1.5, 5.4, A.2

RACデータベース、「データベース」も参照

RCU、「リポジトリ作成ユーティリティ(RCU)」を参照

エンタープライズ・デプロイメントのリカバリ, 19.9

ホーム・ページへのリダイレクト, 19.13.10

ログイン画面へのリダイレクト, 19.13.9

Webゲート・エージェントの登録, 18.3.3

リポジトリ作成ユーティリティ(RCU), 5.1

Fusion Middlewareメタデータ・リポジトリのロード, 5.4

要件

クラスタ通信, 1.1.6

データベース・ホスト, 5.2.1

ハードウェア, 1.2

ロード・バランサ, 1.1.3, 3.3

ソフトウェア, 1.4, 7.1

ユニキャスト通信, 1.1.6

再開

管理サーバー, 10.3, 11.3, 12.4, 13.4, 14.4

Oracle WebCenter Contentサービスの再試行, 10.4.8 RREGツール, 18.3.3.1

S

Oracle WebCenter Content: Imaging用のサンプル・ディレクトリ, 13.5.7

トポロジのスケール・アウト, 19.7

Capture, 19.7.3, 19.7.3

Oracle SOA Suite, 19.7.4

Oracle WebCenter Content, 19.7.1

Oracle WebCenter Content: Imaging, 19.7.2, 19.7.2

トポロジのスケール・アップ, 19.6

Capture, 19.6.3, 19.6.3

Oracle SOA Suite, 19.6.4

Oracle WebCenter Content, 19.6.1

Oracle WebCenter Content: Imaging, 19.6.2, 19.6.2

画面

GridLink RACコンポーネント・スキーマの構成, 8.3, 10.2, 12.3, 13.3, 14.3

スクリプト

configure-joc.py, 12.7

createCentralInventory.sh, 7.2.2, 7.3.3

leasing.ddl, 17.2

oracleRoot.sh, 7.2.2

setNMProps.sh, 8.4.2, 15.5.3.3

wlsifconfig.sh, 17.5

2次ノード, 2.3 セキュリティ, 2.4.1 セキュリティ・フィルタ, 10.4.3, 11.5.1, 13.5.11, 14.5.6, 19.13.13 セキュリティ・ポリシー, 19.12 セキュリティ・ストア

データベース・ベース, 8.5

ファイルベース, 8.5

OPSS, 8.5

自己署名証明書, 16.3.1 サーバー移行, 17

WLS_CPT管理対象サーバー用の構成, 14.8

WLS_IMG管理対象サーバー用の構成, 13.8

WLS_SOA管理対象サーバー用の構成, 12.11

ターゲットの構成, 17.6

GridLinkデータ・ソースの作成, 17.3

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

GridLinkデータ・ソース, 17.3

leasing表, 17.2

環境とスーパー・ユーザー権限の設定, 17.5

ユーザーと表領域の設定, 17.2

テスト, 17.7

トラブルシューティング, 19.13.6, 19.13.7

サーバー

管理サーバー, 1.6.3

クロックの同期, 1.3

データベース・グリッド, 2.1

LDAP, 1.1.2

ロード・バランサ, 2.3

管理対象サーバー, 1.1.4

ハードウェア・クラスタのノード, 2.3

ポート, 1.1.3

エンタープライズ・デプロイメントの準備, 6

仮想ホスト名, 1.1.3, 2.3

仮想IPアドレス, 2.3

Web, 2.3

WebLogic Server管理対象サーバー, 1.1.4

Oracle WebCenter Contentのサービス再試行, 10.4.8 ServiceAllowRetry, 10.4.8 データベースのサービス, 5.3 setNMProps.sh script, 8.4.2, 15.5.3.3 ノード・マネージャの設定, 16 Webゲートの設定, 18.3.4 WebLogic Server認証プロバイダの設定, 18.3.6 共有記憶域, 2.3

構成, 4.5

図, 4.3, 4.3

構成例, 4.3, 4.3

マウント場所, 4.5

シングル・サインオン検証, 18.4 SOAインフラストラクチャ・データベース, 19.4 soa-infraアプリケーション, 19.13.1, 19.13.2 ソフトウェア

データベース, 5.2.2

インストール, 7.1

Oracle Fusion Middleware, 7.3

Oracle HTTP Server, 7.2

Oracle WebLogic Server, 7.3.3

要件, 1.4, 7.1

バージョン, 1.4, 7.1

SOAインフラストラクチャ・データベースでの領域, 19.4 SQLNet接続、タイムアウト, 19.11 SSO検証, 18.4 開始

WCCHOST1の管理サーバー, 8.4.3, 15.5.3.4

Capture, 14.5.3.2

ノード・マネージャ, 16.4

WCCHOSTでのノード・マネージャ, 10.4.1

WCCHOST1でのノード・マネージャ, 8.4.2, 15.5.3.3

Oracle WebCenter Content: Imaging, 13.5.4

WLS_SOA1管理対象サーバー, 12.6.3

WLS_SOA2管理対象サーバー, 12.6.4

WLS_WCC1管理対象サーバー, 10.4.3

WLS_WCC2管理対象サーバー, 10.4.5

スーパーユーザー権限, 17.5 スイッチバック, 2.3 スイッチオーバー, 2.3 クロックの同期, 1.3 Oracle WebCenter Content: Imaging用のシステムMBean, 13.5.7

T

サーバー移行の表領域, 17.2

サーバー移行のターゲット, 17.6

用語, 2.3

サーバー移行のテスト, 17.7

SQLNet接続のタイムアウト, 19.11

Tlogs

場所, 4.4.3.1, 4.4.3.2

トポロジ, 1.1

アプリケーション層, 1.1.4

データ層, 1.1.5

ディレクトリ構造, 4.4

環境変数, 4.2

ソフトウェアのインストール, 7

管理, 19

監視, 19.1

Oracle Identity Management, 1.1.2

Oracle Web Tier

WEBHOST, 1.1.3

ポリシーと資格証明, 1.5 ポリシー・ストア, 1.5 スケール・アウト, 19.7 スケール・アウト(Capture), 19.7.3, 19.7.3 スケール・アウト(Oracle SOA Suite), 19.7.4 スケール・アウト(Oracle WebCenter Content), 19.7.1 スケール・アウト(Oracle WebCenter Content: Imaging), 19.7.2, 19.7.2 スケール・アップ, 19.6 スケール・アップ(Capture), 19.6.3, 19.6.3 スケール・アップ(Oracle SOA Suite), 19.6.4 スケール・アップ(Oracle WebCenter Content: Imaging), 19.6.2, 19.6.2 スケール・アップ(WebCenter Content), 19.6.1 ソフトウェア, 1.4 トランザクション・リカバリ, 12.9 トラブルシューティング

管理サーバーでの変更のアクティブ化, 19.13.5

Coherence, 19.13.2

デプロイメント・フレームワークの問題(Coherence), 19.13.2

誤ったURL, 19.13.8

WLS管理コンソールからのログアウト, 19.13.16

手動フェイルオーバー, 19.13.4

データベースの最大プロセス数, 19.13.3

Java VMのメモリー・ヒープ, 19.13.14

soa-infraアプリケーションにロード・バランサ経由でアクセスできない, 19.13.1

メモリー不足の問題, 19.13.14

ホーム・ページへのリダイレクト, 19.13.10

ログイン画面へのリダイレクト, 19.13.9

Oracle WebCenter Contentサーバーのマスター・パスワードの再生成, 19.13.15

セキュリティ・フィルタ, 19.13.13

サーバー移行, 19.13.6, 19.13.7

soa-infraアプリケーション, 19.13.1, 19.13.2

トラスト・キーストア, 16.3.3

U

UCM、「Oracle WebCenter Content」を参照

UMSドライバ, 19.5

ユニキャスト通信, 1.1.6, 12.5

URL、保護されている--, 18.3.3.2

utils.CertGenユーティリティ, 16.3.1

utils.ImportPrivateKeyユーティリティ, 16.3.2

V

検証

管理サーバー, 8.4.4, 15.5.3.5

Oracle HTTP Serverを使用した管理サーバー・アクセス, 9.6.4, 19.8.2

Oracle HTTP Serverを介したCaptureサーバーへのアクセス, 14.6.3

Oracle Access Managerの統合, 18.4

Oracle HTTP Server, 9.5

Oracle HTTP Serverを介したOracle SOA Suiteサーバーへのアクセス, 12.8.3

Oracle Web層のインストール, 9.3

Oracle HTTP Serverを使用したOracle WebCenter Contentサーバーへのアクセス, 10.6.3, 15.8.2

Oracle HTTP Serverを使用したOracle WebCenter Content: Imagingサーバーへのアクセス, 13.6.2

サーバー移行, 17.7

Oracle HTTP Serverを使用したSSO, 18.4

WLS_SOA1管理対象サーバー, 12.6.3

WLS_SOA2管理対象サーバー, 12.6.4

ソフトウェアのバージョン, 1.4, 7.1

データベース, 5.2.2

VIP、「仮想IPアドレス(VIP)」を参照 仮想ホスト名, 2.3 仮想ホスト

ADMINVHN, 3.4

WCCHOST1VHN1, 3.4

WCCHOST1VHN2, 3.4

WCCHOST1VHN3, 3.4

WCCHOST2VHN1, 3.4

WCCHOST2VHN2, 3.4

WCCHOST2VHN3, 3.4

仮想IPアドレス, 管理サーバーとの関連付け, 6.6.1, 6.6.2 仮想IPアドレス

WCCHOST1でのWCCHOST1VHN1の有効化, 8.2

仮想IPアドレス(VIP), 2.3, 3.4

説明, 3.4

マッピング, 3.4

VIP2およびVIP3, 13.2, 14.2

WCCHOST1VHN1, 12.2, 12.10, 13.7, 14.7

WCCHOST2VHN1, 12.2, 12.10, 13.7, 14.7

仮想サーバー

admin.example.com, 3.2.1

ロード・バランサ, 3.3.2

wcc.example.com, 3.2.2

wccinternal.mycompany.com, 3.2.3

httpd.confの<VirtualHost>エントリ, 9.5.1

W

WCC_ORACLE_HOME, 4.4.3.1, 4.4.3.2

WCCDBHOST, 1.1.5, 5.4

要件, 5.2.1

wccedg.mycompany.com, 5.3, 5.4 wcc.example.com, 3.2.2 WCCHOST, 1.1.4, 1.1.4

管理サーバーのboot.properties, 8.4.1, 15.5.3.2

管理サーバーを含むドメインの作成, 8.3

Middlewareホームの作成, 7.3.3

VIP2とVIP3の無効化, 13.2, 14.2

WCCHOSTnVHNnの有効化, 12.2, 12.10, 13.7, 14.7

Captureを含むドメインの拡張, 14.3

Imagingを含むドメインの拡張, 13.3

Inbound Refineryを含むドメインの拡張, 11.2

Oracle SOA Suiteコンポーネントを含むドメインの拡張, 12.3

Oracle WebCenter Contentを含むドメインの拡張, 10.2

管理サーバーのフェイルオーバー, 8.6, 19.8, 19.8.3

Oracle SOA Suiteのインストール, 7.3.4.2

Oracle WebCenter Contentのインストール, 7.3.4.1

Oracle WebLogic Serverのインストール, 7.3.3

共有記憶域の場所のマウント, 4.5

ドメイン構成の伝播, 10.4.2, 11.4.1, 13.5.2, 14.5.2

管理サーバーの起動, 8.4.3, 15.5.3.4

Captureの起動, 14.5.3.2

ノード・マネージャの起動, 8.4.2, 10.4.1, 15.5.3.3

Oracle WebCenter Content: Imagingの起動, 13.5.4

WLS_SOA管理対象サーバーの起動, 12.6.3, 12.6.4

WLS_WCC管理対象サーバーの起動, 10.4.3, 10.4.5

WCCHOSTノード, 8.2 WCCHOST1VHN1, 3.4

WCCHOST1での--の有効化, 12.2, 12.10, 13.7, 14.7

WCCHOST1VHN2, 3.4 WCCHOST1VHN3, 3.4 WCCHOST2VHN1, 3.4

WCCHOST2での--の有効化, 12.2, 12.10, 13.7, 14.7

WCCHOST2VHN2, 3.4 WCCHOST2VHN3, 3.4 wccinternal.mycompany.com, 3.2.3 WCCUI_APPLICATION_HOME, 4.2 Webサービス, 19.12 Web層のOracleホーム, 4.2, 4.4.3.1 WebCenter Contentユーザー・インタフェース, 2.2, 15.1 WebCenter Content、「Oracle WebCenter Content」を参照 WebCenter Enterprise Capture、「Capture」を参照 Webゲート, 1.1.3

必要なGCCライブラリ, 18.3.4.1

インストール, 18.3.4.2

エージェントの登録, 18.3.3

設定, 18.3.4

WEBGATE_ORACLE_HOME, 4.2 WEBHOST

admin.conf, 9.6.1

ロード・バランサとOHSの構成 9.4

管理サーバーに対するOracle HTTP Serverの構成, 9.6.1

Oracle Web層の構成, 9.2

Oracle HTTP Serverのインストール, 7.2.2

ロード・バランサ, 3.3.2

Oracle HTTP Serverを使用した管理サーバー・アクセスの検証, 9.6.4, 19.8.2

Oracle HTTP Serverを使用したCaptureサーバーへのアクセスの検証, 14.6.3

Oracle HTTP Serverを介したOracle SOA Suiteサーバーへのアクセスの検証, 12.8.3

Oracle HTTP Serverを使用したOracle WebCenter Contentサーバーへのアクセスの検証, 10.6.3, 15.8.2

Oracle HTTP Serverを使用したOracle WebCenter Content: Imagingサーバーへのアクセスの検証, 13.6.2

Oracle HTTP Serverを使用したSSOの検証, 18.4

WebLogic Server管理サーバー

仮想IPアドレスとの関連付け, 6.6.1, 6.6.2

WebLogic Server管理者, LDAPへの移動, 18.2.4 WebLogic Server認証プロバイダ, 18.3.6 WebLogic Serverホーム, 2.3, 4.4.3.1, 4.4.3.2 WebLogic Serverプラグイン有効化フラグ, 9.6.2 WebLogic Server、「Oracle WebLogic Server」を参照 ウィザード

構成, 1.6.3

インストール, 7.3.4.1

WL_HOME, 4.2, 4.2, 4.4.3.1, 4.4.3.2 WLS_CPT管理対象サーバー, 14.3

Oracle WebCenter Contentへのリスニング・アドレスの追加, 14.5.6

Oracle HTTP Serverの構成, 14.6, 14.6.1

サーバー移行の構成, 14.8

ホスト名検証の無効化, 14.5.1

起動, 14.5.3.2

WLS_IMG管理対象サーバー, 13.3

Oracle WebCenter Contentへのリスニング・アドレスの追加, 13.5.11

ノード・マネージャの構成, 10.7, 11.7, 12.10, 13.7, 14.7

Oracle HTTP Serverの構成, 13.6, 13.6.1

サーバー移行の構成, 13.8

ホスト名検証の無効化, 13.5.1

起動, 13.5.4

WLS_SOA管理対象サーバー, 12.3

Oracle HTTP Serverの構成, 12.8.1

サーバー移行の構成, 12.11

ホスト名検証の無効化, 12.6.1

起動, 12.6.3, 12.6.4

WLS_WCC管理対象サーバー, 10.2, 11.2

ノード・マネージャの構成, 10.7, 11.7, 12.10, 13.7, 14.7

Oracle HTTP Serverの構成, 10.6.1, 15.8.1

起動, 10.4.3, 10.4.5

WLS、「Oracle WebLogic Server」を参照 wlsifconfig.shスクリプト, 17.5 Oracle WebCenter Content: Imagingのワークフロー接続, 13.5.14 WSM、「Oracle Web Services Manager」を参照 WT_ORACLE_HOME, 4.2, 4.4.3.1

X

X Windowsシステム, 13.5.7

オラクル社の法律上の注意点について

コピーライトについて

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

商標と登録商標について

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

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

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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

危険な用途への使用について

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。