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

11g リリース1(11.1.1)

B66703-02(原本部品番号:E15483-07)

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

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

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

- 1.2 Oracle WebCenter Contentについて

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

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

- 1.4.1 組込みセキュリティ

- 1.4.2 高可用性

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

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

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

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

- 2.1.3 Web層ノードについて

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

- 2.1.5 データ層について

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

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

- 2.3 クロックの同期

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

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

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

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

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

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

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

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

- 3.2.1 wcc.mycompany.com

- 3.2.2 admin.mycompany.com

- 3.2.3 soainternal.mycompany.com

- 3.2.4 wccinternal.mycompany.com

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

- 3.4 IPと仮想IP

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

- 3.6 資格証明ストアおよびポリシー・ストアとしてのLDAPの使用

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

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

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

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

- 4.4共有記憶域の構成

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

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

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

- 5.2 データベース要件

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

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

- 5.2.3 初期化パラメータ

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

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

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

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

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

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

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

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

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

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

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

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

- 6.3.1 Oracle WebLogic Serverのインストールとミドルウェア・ホームの作成

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

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

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

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

7 Web層の構成

- 7.1 Web層構成の概要

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

- 7.3 インストールの検証

- 7.4 Oracle Web層とOracle WebLogicドメインの関連付け

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

- 7.6 仮想ホストの構成

- 7.6.1 httpd.confファイルの編集による<VirtualHost>ディレクティブの定義

- 7.6.2 両方のOracle HTTP Serverの再起動

- 7.6.3 構成の検証

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

- 8.1 ドメイン作成の概要

- 8.2 SOAHOST1でのADMINVHNの有効化

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

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

- 8.4.1 RACデータベース・サービスの確認

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

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

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

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

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

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

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

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

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

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

- 8.5.5 Oracle HTTP Serverを使用したアクセスの検証

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

- 8.5.6.1 前提条件および手順

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

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

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

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

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

- 9.2 SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化

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

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

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

- 9.4.2 ホスト名の指定

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

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

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

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

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

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

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

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

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

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

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

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

- 9.9 Oracle HTTP Serverを使用したアクセスの検証

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

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

- 9.12 Oracleデータベース・アダプタのスケーリング

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

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

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

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

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

- 10.2 WCCHOST1でのWCCHOST1VHN1およびWCCHOST2でのWCCHOST2VHN1の有効化

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

- 10.4 WCCHOST1およびWCCHOST2でのノード・マネージャの起動

- 10.5 WCC_WLS1のGridLinkデータ・ソースの検証

- 10.6 pack/unpackユーティリティを使用した、WCCHOST1へのドメイン構成の伝播

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

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

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

- 10.10 WCCHOST1からWCCHOST2へのドメイン構成の伝播

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

- 10.12 WLS_WCC2のGridLinkデータ・ソースの検証

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

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

- 10.15 Oracle HTTP Serverを使用したアクセスの検証

- 10.16 WLS_WCCおよびWLS_IMG管理対象サーバーのノード・マネージャの構成

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

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

- 11.1 Imagingを使用するためのドメインの拡張の概要

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

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

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

- 11.5 WCCHOST1およびWCCHOST2でのノード・マネージャの起動

- 11.6 WCC_IMG1のGridLinkデータ・ソースの検証

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

- 11.8 Oracle WebCenter Content: Imaging用のJMS永続ストアの構成

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

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

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

- 11.12 WLS_IMG2のGridLinkデータ・ソースの検証

- 11.13 Oracle WebCenter Content: Imaging用のシステムMBeanの構成

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

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

- 11.16 Oracle WebCenter Contentへの接続の作成

- 11.17 BPEL CSF資格証明の構成

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

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

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

- 11.21 Oracle HTTP Serverを使用したアクセスの検証

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

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

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

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

- 12.1 Oracle WebCenter Content: Inbound Refineryを使用するためのドメインの拡張の概要

- 12.2 Inbound Refinery管理対象サーバーと仮想ホスト名の関連付け

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

- 12.4 WCCHOST1およびWCCHOST2でのノード・マネージャの起動

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

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

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

- 12.8 Inbound Refineryの構成

- 12.8.1 Inbound Refineryの設定の構成

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

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

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

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

- 12.8.3.3 変換するファイル・フォーマットの選択

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 14.4 HOST1およびHOST2と管理サーバー間でのホスト名検証証明書の有効化

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

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

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

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

15 Oracle Identity Managementとの統合

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

- 15.2 資格証明ストアおよびポリシー・ストアの構成

- 15.2.1 資格証明ストアとポリシー・ストアの構成の概要

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

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

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

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

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

- 15.2.3.1 LDAPベースのポリシー・ストアを使用するための前提条件

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

- 15.2.4 資格証明およびポリシーの再関連付け

- 15.2.4.1 Oracle Internet Directoryの属性のカタログ化

- 15.3 Oracle Access Manager 10gの統合

- 15.3.1 Oracle Access Managerの統合の概要

- 15.3.2 Oracle Access Managerの前提条件

- 15.3.3 Oracle Access Managerの構成

- 15.3.3.1 OAM構成ツールで使用する情報の収集

- 15.3.3.2 OAM構成ツールの実行

- 15.3.3.3 Oracle Access Managerのログアウトのガイドライン

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

- 15.3.3.5 Cookieを使用しない基本認証スキームが適切に割り当てられていることの確認

- 15.3.3.6 ホスト識別子の更新

- 15.3.3.7 Webゲート・プロファイルの更新

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

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

- 15.3.4 Webゲートのインストールと構成

- 15.3.5 EDG WebGateのIP検証の構成

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

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

- 15.3.6.2 OAM IDアサータの設定

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

- 15.4 Oracle Access Manager 11gの統合

- 15.4.1 Oracle Access Managerの統合の概要

- 15.4.2 Oracle Access Managerの前提条件

- 15.4.3 WebGateの設定

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

- 15.4.3.2 WebGateのインストール

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

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

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

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

- 15.4.4.3 oamregツールの実行

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

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

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

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

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

- 15.4.5.2 OAM IDアサータの設定

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

- 15.5 Oracle HTTP ServerおよびSSOを使用したアクセスの検証

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

16 トポロジの管理

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

- 16.2 Oracle WebCenter Content: Imagingの入力ファイルを最適化する戦略の定義

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 16.11.3 SOAサーバーの再起動に失敗したためにポリシー移行が未完になる

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

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

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

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

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

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

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

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

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

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

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

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

- 16.11.16 Oracle WebCenter Contentサーバーのマスター・パスワードを再生成する

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

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

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

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

索引

Oracle® Fusion Middleware

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

11g リリース1(11.1.1)

B66703-02(原本部品番号:E15483-07)

2012年5月

Oracle WebCenter Contentコンポーネントのエンタープライズ・デプロイメントへのインストールおよび構成方法を説明するインストール実行者向けのドキュメントです。Oracle WebCenter Content EDGトポロジのベスト・プラクティスの青写真が含まれています。

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

B66703-02

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

原本主著者:  Ron van de Crommert (ライター), Bonnie Vaughan (ライター), Janga Aliminati (アーキテクト), Fermin Castro (協力エンジニア)

原本協力者: Joe Paul

原本協力者:  Richard Delval、Pradeep Bhat、Eileen He、Van Sioung Ng Yan Tun、Madhwa Chintarevula、Izeta Delic、Nouar Garcia-Mardambek、Pascal Prevot

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

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

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(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 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 WebCenter Contentクイック・インストレーション・ガイド

- Oracle WebCenter Contentのインストレーション・ガイド

- Oracle Fusion Middleware管理者ガイド

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

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

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

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

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

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

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

1.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 Database高可用性に関するページ(http://www.oracle.com/technetwork/database/features/availability/index-087701.html)を参照してください。

注意:

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

1.2 Oracle WebCenter Contentについて

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

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

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

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

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

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

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

- Oracle WebCenter Content

- Oracle WebCenter Content: Inbound Refinery

- Oracle WebCenter Content: Imaging

Oracle WebCenter Content

Oracle WebCenter Content(以前のOracle Universal Content ManagementまたはOracle UCM)では、統一リポジトリが組織に提供され、ビジネス・ユーザーに配信されます。この配信は適切なフォーマットで行われ、またビジネス・ユーザーの業務に親和性の高いアプリケーションのコンテキスト内で行われます。

Oracle WebCenter Content: Imaging

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

Oracle WebCenter Content: Inbound Refinery

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- AdminServerドメイン・ホーム

- JMS

- Tlogs(該当する場合)

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

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

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

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

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

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

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

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

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

注意:

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

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

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

1.4 Oracle推奨事項のメリット

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

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

- 第1.4.2「高可用性」

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

1.4.1 組込みセキュリティ

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

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

注意:

Oracle Technology Network(http://www.oracle.com/technetwork/index.html)には、検証されたロード・バランサとその構成の一覧(http://www.oracle.com/technetwork/middleware/ias/tested-lbr-fw-sslaccel-100648.html)が用意されています。

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

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

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

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

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

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

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

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

1.4.2 高可用性

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

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

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

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

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

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

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

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

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

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

この項では、このガイドで使用するエンタープライズ・デプロイメントの参照用トポロジの説明に使用するダイアグラムについて説明します。この項を使用してエンタープライズ・デプロイメント・トポロジを計画してください。

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

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

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

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

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

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

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

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

このガイドは、図2-1で示すように、サービス指向アーキテクチャ(SOA)およびOracle WebCenter ContentのOracle Access Managerを使用する参照用エンタープライズ・トポロジの構成手順について説明します。

注意:

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

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

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

2.1.2 Oracle Identity Managementの統合について

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

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

2.1.3 Web層ノードについて

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

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

Oracle HTTP ServerにあるWebゲート(Oracle Access Managerコンポーネント)はOracle Access Protocol(OAP)を使用して、アイデンティティ管理DMZ内のOAMHOST2で実行されているOracle Access Managerと通信します。WebゲートとOracle Access Managerは、ユーザー認証などの操作を実行するために使用されます。

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

Oracle HTTP Server内のWebGateモジュールは、Oracle Access Protocol(OAP)を使用してOracle Access Managerと通信し、ユーザー・グループへの問合せなどの操作を実行します。

Web層を保護するファイアウォール上では、HTTPポート(HTTPS用の443とHTTP用の80)のみが開放されています。

ロード・バランサの要件

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

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

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

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

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

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

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

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

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

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

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

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

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

アプリケーション層のノードはDMZセキュア・ゾーンにあります。この層では、2つのノード(SOAHOST1およびSOAHOST2)が、BPELプロセス・マネージャなどのOracle SOA Suiteコンポーネントを実行する管理対象サーバーとともに構成されているOracle WebLogic Serverを実行します。管理対象サーバーは、アクティブ/アクティブで構成されます。

WCCHOST1およびWCCHOST2では、Oracle WebCenter Contentサーバー、ImagingサーバーおよびInbound Refineryサーバーを実行します。

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

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

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

2.1.5 データ層について

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サーバー

ディスク

メモリー

TMPディレクトリ

スワップ

データベース

nXm

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

6～8GB

デフォルト

デフォルト

WEBHOSTn

10GB

4GB

デフォルト

デフォルト

SOAHOSTn

10GB脚注 1

10GB

デフォルト

デフォルト

WCCHOSTn

10GB脚注 2

10GB

デフォルト

デフォルト

脚注1共有記憶域のMW_HOME構成の場合、2つのインストールでは、スロット数と関係なく合計20GBにすると十分です。

脚注2Oracle WebCenter Contentでは、共有記憶域のOracle SOA SuiteインストールからMW_HOMEバイナリを再利用できます。

注意:

- 適切な容量計画を実施して、ノードの数、特定のシステムへの負荷に応じてノードごとにおけるCPUとメモリーに関する要件、スループットとレスポンスに関する要件を決める必要があります。これらは、アプリケーションごと、または使用しているカスタムOracle SOA Suiteシステムごとに異なります。

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

2.3 クロックの同期

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

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

2.4 インストールするソフトウェア・コンポーネントの特定

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

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

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

コンポーネント

詳細

Oracle Database 10gまたは11g

Oracle Database 10g (10.2.0.4以降、Standard EditionまたはEnterprise Edition)、AL32UTF8キャラクタ・セットの使用

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.6)

Oracle WebLogic Server

Oracle WebLogic Server (10.3.6)

Oracle HTTP Server(OHS)

Oracle Fusion Middleware WebTier and Utilities 11g (11.1.1.6)

Oracle SOA Suite

Oracle SOA Suite 11g (11.1.1.6)

Oracle WebCenter Content

Oracle WebCenter Content 11g (11.1.1.6)

Oracle Access Manager WebGate

Oracle Access Manager 10gの場合はWebGate 10g (10.1.4.3)またはOracle Access Manager 11gの場合はWebGate 11g (11.1.1.2以降)

Oracle Virtual Directory

Oracle Identity and Access Management 11g (11.1.1.5)

Oracle Internet Directory

Oracle Identity and Access Management 11g (11.1.1.5)

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

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

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

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

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

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

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

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

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

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

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

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

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

手順

説明

詳細

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

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

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

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

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

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

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

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

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

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

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

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

Web層の構成

Oracle Web層をWebLogic Serverドメインに関連付け、Oracle HTTP Serverをロード・バランサとともに構成し、仮想ホスト名を構成することでOracle Web層を構成します。

第7章「Web層の構成」

ドメインの作成

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

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

Oracle SOA Suiteのドメインの拡張

Fusion Middleware構成ウィザードを実行し、Oracle SOA Suiteコンポーネントを構成して、既存のWebLogic Serverドメインを拡張します。

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

Oracle WebCenter Contentのドメインの拡張

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

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

Oracle WebCenter Content: Imagingのドメインの拡張

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

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

Oracle WebCenter Content: Inbound Refineryのドメインの拡張

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

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

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

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

第13項「ノード・マネージャの設定」

サーバー移行の構成

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

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

Identity Managementとの統合

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

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

2.5.3 エンタープライズ・デプロイメントへの増分、モジュラ・アプローチについて

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

記憶域、データベース、ネットワーキングおよび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構成ウィザードの各ステップ後に環境を確認できます。また、セットアップ・プロセス中のトラブルシューティングが容易になります。

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

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

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

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

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

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

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

- 第3.4項「IPと仮想IP」

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

- 第3.6項「資格証明ストアおよびポリシー・ストアとしてのLDAPの使用」

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

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

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

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

- 第3.2.1項「wcc.mycompany.com」

- 第3.2.2項「admin.mycompany.com」

- 第3.2.3項「soainternal.mycompany.com」

- 第3.2.4項「wccinternal.mycompany.com」

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

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

3.2.1 wcc.mycompany.com

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

3.2.2 admin.mycompany.com

admin.mycompany.comは、Oracle WebLogic Server管理コンソールやOracle Enterprise Manager Fusion Middleware Controlなどの管理サービスへの、すべての内部HTTPトラフィックのアクセス・ポイントとして動作する仮想サーバー名です。

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

3.2.3 soainternal.mycompany.com

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

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

3.2.4 wccinternal.mycompany.com

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

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

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

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

次に示す手順は大まかな手順です。実行する必要がある実際の手順は、使用するロード・バランサのタイプによって異なります。次の手順を実行するための詳細は、使用するロード・バランサのドキュメントを参照してください。

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

注意:

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

第3.2項「トポロジで使用する仮想サーバー名」で説明する仮想サーバー名を定義して、ロード・バランサを構成するには、次の手順を実行します。

1. サーバーのプールを作成します。このプールを仮想サーバーに割り当てます。

2. Oracle HTTP Serverホストのアドレスをプールに追加します。たとえば、次のようになります。

- WEBHOST1:7777

- WEBHOST2:7777

3. ロード・バランサにsoainternal.mycompany.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

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

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

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

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

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

4. ロード・バランサにwcc.mycompany.com:443の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

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

- ポート80とポート443でこの仮想サーバーを構成します。ポート80に入力するリクエストはすべて、ポート443にリダイレクトされる必要があります。

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

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

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

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

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

5. ロード・バランサにadmin.mycompany.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

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

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

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

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

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

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

6. ロード・バランサにwccinternal.mycompany.com:80の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

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

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

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

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

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

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

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

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

ヒント:

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

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

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

第7.6項「仮想ホストの構成」に従って仮想ホストを構成すると、仮想ホスト名アドレスへのアクセスが可能になります。アクセスできない場合は、この手順を正しく実行していることを確認してください。

3.4 IPと仮想IP

図3-1に示すように、異なる仮想IPと物理IPでリスニングするように、管理サーバーと管理対象サーバーを構成してください。この図が示すとおり、各VIPおよび各IPは、それらを使用するOracle WebLogicサーバーに付加されています。VIP1に障害が発生すると、手動で管理サーバーがSOAHOST2で再起動します。Oracle WebLogic Serverの移行機能により、VIP2とVIP3では、SOAHOST1からSOAHOST2へのフェイルオーバーとSOAHOST2からSOAHOST1へのフェイルオーバーがそれぞれ実行されます。また、WLS_IMG1とWLS_IMG2では、VIP4とVIP5をそれぞれWCCHOST1からWCCHOST2にフェイルオーバーするサーバー移行が使用されます。

WebLogic Serverの移行機能の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

(仮想ではない)物理IPが、各ノードに固定的に割り当てられます。IP1はWCCHOST1の物理IPで、WLS_WCC1サーバーによりリスニング・アドレスとして使用されます。IP2はWCCHOST2の物理IPで、WLS_WCC2サーバーによりリスニング・アドレスとして使用されます。

仮想IP db-scan.mycompany.comは、GridLinkデータ・ソースのデータベースOracle Single Client Access Name (SCAN)のアドレスです。

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

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

表3-1には、各種の仮想ホストの説明が記載されています。

表3-1 仮想ホスト

仮想IP

VIPのマップ先

説明

VIP1

ADMINVHN

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

VIP2

SOAHOST1VHN1

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

VIP3

SOAHOST2VHN1

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

VIP4

WCCHOST1VHN1

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

VIP5

WCCHOST2VHN1

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

db-scan.mycompany.com

db-scan.mycompany.comは、GridLinkデータ・ソースのデータベースOracle Single Client Access Name (SCAN)のアドレスです。

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

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

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

表3-2には、Oracle WebCenter Contentトポロジで使用されるポートの一覧が記載されているほか、トポロジのファイアウォール上で開く必要のあるポートも記載されています。

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

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

- FW1は、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 HTTP Serverへのロード・バランサ

なし

7777

HTTP

なし

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

管理サーバーによる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 ContentへのImagingによる接続

なし

4444

TCP/IPユニキャスト

なし

永続的に接続されます。WebCenter Content Serverのタイムアウトを構成できます。

SOA_Clusterメンバー間の通信

なし

8001

TCP/IPユニキャスト

なし

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

WCC_Clusterメンバー間の通信

なし

16200

TCP/IPユニキャスト

なし

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

IMG_Clusterメンバー間の通信

なし

16000

TCP/IPユニキャスト

なし

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

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

なし

なし

なし

なし

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

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

FW1

7001

HTTP / 管理サーバーおよびOracle Enterprise Manager Fusion Middleware Control

t3

両方

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

ノード・マネージャ

なし

5556

TCP/IP

なし

なし

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

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

F

5575
(OAM 11g)

6021
(OAM 10g)

OAP

インバウンド

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

アイデンティティ・サーバーへのアクセス(OAM 10g)

FW1

6022

OAP

インバウンド

データベースへのアクセス

FW2

1521

SQL*Net

両方

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

デプロイメントの一貫性

なし

8088

範囲: 8000から8090

なし

なし

Oracle Internet Directoryのアクセス

FW2

389

LDAP

インバウンド

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

Oracle Internet Directoryのアクセス

FW2

636

LDAP SSL

インバウンド

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

OWSM用JOC

該当なし

9991

範囲: 9988から9998

TCP/IP

該当なし

該当なし

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

該当なし

16250

16250

HTTP / WLS_IBRn

該当なし

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

注意:

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

3.6 資格証明ストアおよびポリシー・ストアとしてのLDAPの使用

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

Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジでは、第4.3項「各種ディレクトリの推奨場所」の説明のとおり、管理サーバーと管理対象サーバーに各種のドメイン・ホームを使用します。この理由から、また整合性と一貫性を保持するために、Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジ環境のポリシー・ストアおよび資格証明ストアとしてLDAPサーバーを使用する必要があります。資格証明ストアおよびポリシー・ストアとしてLDAPを使用し、Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジを構成するには、第15.2項「資格証明ストアおよびポリシー・ストアの構成」の手順に従います。

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

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

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

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

- 第4.2項「ディレクトリとディレクトリ環境変数の用語」

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

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

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

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

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

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

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

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

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

- MW_HOME: この環境変数と関連ディレクトリ・パスは、Fusion Middleware(FMW)が存在する場所を指しています。

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

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

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

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

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

ヒント:

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

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

Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数の管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、可用性が最大になるように、バイナリの冗長インストールを使用することをお薦めします。

エンタープライズ・デプロイメント・モデルでは、2つのOracle Fusion Middlewareホーム(MW_HOME)が共有記憶域にインストールされ、この2つのホームにはそれぞれ、製品スイートごとにWL_HOMEおよびORACLE_HOMEが存在します。(スケール・アウトまたはスケール・アップの際の)同じタイプの追加サーバーは、さらなるインストールをしなくてもこれらの2つの場所のどちらかを使用できます。理想的には、ユーザーは冗長バイナリの場所として2つの異なるボリューム(次の説明では、それぞれVOL1、VOL2と呼びます)を使用する必要があり、そうすることによって、各ボリュームでの障害が可能なかぎり隔離されます。さらに保護を強化するために、これらのボリュームでディスクをミラー化することをお薦めします。複数ボリュームが利用できない場合は、共有記憶域上の異なるディレクトリで同じマウント場所をシミュレートするマウント・ポイントを使用することをお薦めします。これによって複数ボリュームが提供するような保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護は可能になります。

ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリ(oraInventory)とMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノードでoraInventoryを更新して、これに共有ストレージのインストールを関連付けるには、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してミドルウェア・ホーム・リストを更新する場合は、user_home/bea/beahomelistファイルを編集します。これは、このエンタープライズ・デプロイメントで使用される2つのノードに加えてインストールされるノードで必要になります。oraInventoryとbeahomelistを更新する例が、このガイドに記載されているスケールアウト手順で用意されています。

また、管理サーバーで使用されるドメイン・ディレクトリと管理対象サーバーで使用されるドメイン・ディレクトリを別々にすることもお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。管理対象サーバーのドメイン・ディレクトリはローカル記憶域または共有記憶域に配置できますが、WebCenter ContentおよびInbound Refineryの管理対象サーバーは別で、共有記憶域に配置できません。このような管理対象サーバーには、intradoc.cfgなど、ノード固有のファイルを使用するOracle WebCenter Content Serverが含まれます。

異なるノード内の他のすべての管理対象サーバーで共有のドメイン・ディレクトリを使用することも、ノードごとに1つのドメイン・ディレクトリを使用することもできます。WebCenter ContentおよびInbound Refineryの管理対象サーバーを除いて、管理対象サーバーのドメイン・ディレクトリを共有すると、スケール・アウト手順が容易になります。この場合、ストレージ・システムの要件があればデプロイメントではその要件に適合する必要があります。これによって、複数のマシンで同じ共有ボリュームのマウントが容易になります。このエンタープライズ・デプロイメント・トポロジで提供される構成手順では、管理対象サーバーごとにローカル(ノード単位)のドメイン・ディレクトリが使用されることを想定しています。

複数のローカル・ドメインに適用される手順はすべて、単一の共有ドメインに適用されます。したがって、ノードごとにドメイン・ディレクトリが1つ使用されるモデルが、このエンタープライズ・デプロイメント・ガイドで使用されています。このディレクトリは、ローカルにも共有記憶域にも配置できます。サーバーの障害や移行の場合にリカバリで複数のボックスを利用可能にするには、JMSファイル・ストアとJTAトランザクション・ログは共有記憶域に配置する必要があります。

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

ORACLE_BASE:

/u01/app/oracle

MW_HOME(アプリケーション層):

ORACLE_BASE/product/fmw

- マウント・ポイント: ORACLE_BASE/product/fmw

- 共有記憶域の場所: ORACLE_BASE/product/fmw(VOL1とVOL2)

- マウント元: 少なくとも半分のノードで1つのインストールを使用し、残りの半分で他方のインストールを使用するように、ノードではVOL1とVOL2を互換的にマウントします。Oracle WebCenter Contentエンタープライズ・デプロイメントでは、SOAHOST1およびWCCHOST1がVOL1をマウントし、SOAHOST2およびWCCHOST2がVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域の2つの別のディレクトリを互換的にマウントします(たとえば、共有記憶域の場所としてSOAHOST1ではORACLE_BASE/product/fmw1が使用され、SOAHOST2ではORACLE_BASE/product/fmw2が使用されます)。

注意:

共有記憶域に利用できるボリュームが1つしかない場合に、誤ってファイルを削除しないように、あるいはパッチを適用できるように、別のディレクトリを使用して冗長に構成することができます。2つのMW_HOMEを使用できます。その場所は、少なくとも1つはORACLE_BASE/product/fmw1、もう一方はORACLE_BASE/product/fmw2とします。これらのMW_HOMEは、すべてのノードで同じマウント・ポイントにマウントされます。

ORACLE_HOME (Web層):

ORACLE_BASE/product/fmw/web

- マウント・ポイント: ORACLE_BASE/product/fmw

- 共有記憶域の場所: ORACLE_BASE/product/fmw(VOL1とVOL2)

- マウント元: 共有記憶域へのインストールの場合、少なくとも半分のノードで1つのインストールを使用し、残りの半分で他方のインストールを使用するように、ノードではVOL1とVOL2を互換的にマウントします。WebCenter Contentエンタープライズ・デプロイメントでは、WEBHOST1がVOL1をマウントし、WEBHOST2がVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域の2つの推奨ディレクトリを互換的にマウントします(つまり、共有記憶域の場所としてWEBHOST1ではORACLE_BASE/product/fmw1が使用され、WEBHOST2ではORACLE_BASE/product/fmw2が使用されます)。

注意:

Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用する場合は、層を横断する記憶域デバイスへのアクセスに対し適切なセキュリティ制限を検討する必要があります。

WL_HOME:

MW_HOME/wlserver_10.3

ORACLE_HOME:

MW_HOME/soaまたはMW_HOME/wcc

ORACLE_COMMON_HOME:

MW_HOME/oracle_common

ORACLE_INSTANCE(OHSインスタンス):

ORACLE_BASE/admin/instance_name

- 共有ディスクを使用している場合、マシンのマウント・ポイントは、ORACLE_BASE/admin/instance_name(VOL1)にマウントされたORACLE_BASE/admin/instance_nameになります。

注意:

(VOL1)はオプションです。(VOL2)も使用できます。

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

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

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

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

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

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

ORACLE_BASE/admin/domain_name/mserver/domain_name

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

注意:

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

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

ORACLE_BASE/admin/domain_name/cluster_name/jms

ORACLE_BASE/admin/domain_name/cluster_name/tlogs

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

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

- マウント元: Oracle SOA SuiteおよびOracle WebCenter Contentコンポーネントが稼働するすべてのノードでこの共有記憶域の場所がマウントされる必要があり、その結果として、別のノードへのサーバーの移行が発生した際にトランザクション・ログおよびJMSストアの使用が可能になります。

Oracle WebCenter Content(Imaging入力ファイル、イメージ、サンプル入力ディレクトリ)の場所:

ORACLE_BASE/admin/domain_name/img_cluster_name/input_files

ORACLE_BASE/admin/domain_name/img_cluster_name/input_files/Samples

ORACLE_BASE/admin/domain_name/img_cluster_name/images

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

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

- マウント元: Imagingを含むすべてのノードはこれらの配置場所をマウントします(入力ファイルおよび処理するイメージにすべてのノードがアクセスできる必要があります)。

入力ファイルおよびイメージの場所は、実装に対する顧客ごとの要求によって異なる可能性があります。ただし、イメージファイルは、システムのパフォーマンスを低下させる可能性のある他の同時アクセスが発生しないデバイスに配置することが妥当です。この目的においては、別のボリュームを使用できます。整合性のとれたバックアップおよびメンテナンスを実行するには、一般的にクラスタ・ディレクトリ構造の下にファイルを置くことをお薦めします。

マルチノード間のImagingインストールでは、この配置場所はすべての入力エージェント間で共有され、すべてのエージェントがアクセスできる必要があります。入力エージェントが異なるマシン上にある場合は、共有ネットワークにする必要があります。

注意:

入力ファイルを処理するには、入力エージェントが入力ディレクトリに対して適切な権限を持ち、入力ディレクトリにおいてファイル・ロックができる必要があります。入力エージェントを使用する場合は、WebLogic Serverのサービスを実行中のユーザー・アカウントが、入力ディレクトリと入力ディレクトリ内のすべてのファイルとサブディレクトリに対して、読取りと書込みの権限を保持している必要があります。この必要な権限によって、入力エージェントは、ファイルを処理する際に様々なディレクトリにファイルを移動できます。クラスタのサーバー間で処理を調整するために、共有上のファイル・ロックが入力エージェントに必要になります。

Oracle WebCenter Contentの保管場所(ネイティブ・ファイル・リポジトリ)の位置:

ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/vault

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

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

- マウント元: WebCenter Contentを含むすべてのノードはこの配置場所をマウントします(入力ファイルおよび処理するイメージにすべてのノードがアクセスできる必要があります)。

Inbound Refineryディレクトリの場所:

ORACLE_BASE/admin/domain_name/ibr_cluster_name

ORACLE_BASE/admin/domain_name/ibr_cluster_name/ibrN (NはInbound Refineryインスタンスの番号を示します)

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

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

- マウント元: Inbound Refineryを含むすべてのノードはこの配置場所をマウントします。

管理サーバーのアプリケーション・ディレクトリの場所:

ORACLE_BASE/admin/domain_name/aserver/applications

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

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

管理対象サーバーのアプリケーション・ディレクトリの場所:

ORACLE_BASE/admin/domain_name/mserver/applications

注意:

このディレクトリは、Oracle WebCenter Contentエンタープライズ・デプロイメント環境ではローカルになります。コンテンツ・サーバーを含む管理対象サーバーの場合、共有ドメイン・ディレクトリは動作しません。intradoc.cfgなどのドメイン内の特定のファイルは各ノードに固有だからです。

図4-1は、このディレクトリ構造を示した図です。

図4-1「Oracle WebCenter Contentエンタープライズ・デプロイメントのディレクトリ構造」

「図4-1 Oracle WebCenter Contentエンタープライズ・デプロイメントのディレクトリ構造」の説明

図4-1のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-1は、図4-1で色分けされた様々な要素の意味を説明します。

表4-1 ディレクトリ構造の要素

要素

説明

管理サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体は共有記憶域上に配置されます。

管理対象サーバーのドメイン・ディレクトリは、ローカルのディスクにも共有ディスクにも配置できます。さらに、管理対象サーバーのドメイン・ディレクトリを複数のノードで共有する場合、ノード全体において共有ディスクの同じ場所をマウントする必要があります。Web層のinstance_nameディレクトリは、ローカル・ディスクまたは共有ディスクに配置できます。

固定名です。

インストール依存名です。

図4-2は、Oracle SOA Suite用に複数のボリュームを持つ共有記憶域の構成例を示しています。

図4-2 共有記憶域の構成例

「図4-2 共有記憶域の構成例」の説明

表4-2は、記憶域を共有するOracle SOA SuiteおよびOracle WebCenter Contentの管理対象サーバーを含むOracle WebLogic Serverドメインのディレクトリ構造を要約しています。

表4-2 共有記憶域の内容

サーバー

データのタイプ

共有記憶域のボリューム

ディレクトリ

ファイル

WLS_WCC1

Txログ

VOL1

ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々です。

WLS_WCC2

Txログ

VOL1

ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々です。

WLS_WCC1

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/wcc_cluster_name/jms

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々で、たとえば、WCCJMSStore1、UMSJMSStore1などのようになっています。

WLS_WCC2

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/wcc_cluster_name/jms

トランザクション・ディレクトリは共通(WebLogic Serverにより決定)ですが、ファイルは別々で、たとえば、WCCJMSStore2、UMSJMSStore2などのようになっています。

WLS_SOA1およびWLS_WCC1

WLSインストール

VOL1

MW_HOME

各ボリューム内では個別ですが、両方のサーバーからは同じディレクトリ構造に見えます(SOAHOST2およびWCCHOST2がVOL1をマウントしている)。

WLS_SOA1およびWLS_WCC1

WLSインストール

VOL2

MW_HOME

各ボリューム内では個別ですが、両方のサーバーからは同じディレクトリ構造に見えます(SOAHOST2およびWCCHOST2がVOL2をマウントしている)。

WLS_WCC1

WCCインストール

VOL1

MW_HOME/wcc

各ボリューム内では個別ですが、両方のサーバーからは同じディレクトリ構造に見えます。

WLS_WCC2

WCCインストール

VOL2

MW_HOME/wcc

各ボリューム内では個別ですが、両方のサーバーからは同じディレクトリ構造に見えます。

WLS_SOA1

ドメイン構成

VOL1

ORACLE_BASE/admin/domain_name/aserver/domain_name

管理サーバーを実行している1つのサーバーのみで使用されます。

WLS_WCC1

ドメイン構成

VOL1

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内では個別ですが、両方のサーバーからは同じディレクトリ構造に見えます。

WLS_WCC2

ドメイン構成

VOL2

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内では個別ですが、両方のサーバーからは同じディレクトリ構造に見えます。

WLS_WCC1

Webファイルおよびボールト・ファイル

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/vault

個別ボリューム上のボールト・ファイルのディレクトリで、ロックが無効になっています。

WLS_WCC1

Webファイルおよびボールト・ファイル

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/weblayout

個別ボリューム上のWebレイアウト・ファイルのディレクトリで、ロックが無効になっています。

WLS_WCC2

Webファイルおよびボールト・ファイル

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/vault

個別ボリューム上のボールト・ファイルのディレクトリで、ロックが無効になっています。

WLS_WCC2

Webファイルおよびボールト・ファイル

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/weblayout

個別ボリューム上のWebレイアウト・ファイルのディレクトリで、ロックが無効になっています。

WLS_IBR1

Inbound Refineryファイル

VOL3

ORACLE_BASE/admin/domain_name/ibr_cluster_name/ibrn

個別ボリューム上のInbound Refineryファイルすべてのディレクトリで、ロックが無効になっています。

注意:

VOL3は、NFSのロック無効化ボリュームとしてマウントされます。詳細は、第4.4項「共有記憶域の構成」を参照してください。

4.4 共有記憶域の構成

次のコマンドを使用して共有記憶域の場所を作成しマウントすることで、WCCHOST1およびWCCHOST2からは別々の2つのボリュームのバイナリ・インストールが同じ場所に見えます。

注意:

共有記憶域のファイル・システムの作成に使用されるユーザーIDは、これらのファイルに対する読取り、書込みおよび実行権限を持ちます。オペレーティング・システム・グループにおける他のユーザーは、ファイルの読取りや実行は可能ですが、書込み権限はありません。インストールと構成の権限に関する詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストールと構成の権限およびユーザーに関する項を参照してください。

コマンドでnasfilerは共有記憶域ファイラです。

SOAHOST1およびWCCHOST1から:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw ORACLE_BASE/product/fmw -t nfs

SOAHOST2およびWCCHOST2から:

mount nasfiler:/vol/vol2/ORACLE_BASE/product/fmw ORACLE_BASE/product/fmw -t nfs

利用できるボリュームが1つのみの場合、共有記憶域で別々のディレクトリを2つ使用し、それらをOracle WebCenter Contentサーバーの同じディレクトリにマウントすることで、バイナリの冗長性を実現できます。

SOAHOST1およびWCCHOST1から:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw1 ORACLE_BASE/product/fmw -t nfs

SOAHOST2およびWCCHOST2から:

mount nasfiler:/vol/vol1/ORACLE_BASE/product/fmw2 ORACLE_BASE/product/fmw -t nfs

次のコマンドは、異なるノード間においてOracle WebCenter Content TXログの場所を共有する方法を示します。

WCCHOST1から:

mount nasfiler:/vol/vol1/ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs -t nfs

WCCHOST2から:

mount nasfiler:/vol/vol1/ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs ORACLE_BASE/admin/domain_name/wcc_cluster_name/tlogs -t nfs

次のコマンドは、異なるノード間においてImaging jmsの場所を共有する方法を示します。

WCCHOST1から:

mount nasfiler:/vol/vol1/ORACLE_BASE/admin/domain_name/img_cluster_name/jms
ORACLE_BASE/admin/domain_name/img_cluster_name/jms  -t nfs

WCCHOST2から:

mount nasfiler:/vol/vol1/ORACLE_BASE/admin/domain_name/img_cluster_name/jms
ORACLE_BASE/admin/domain_name/img_cluster_name/jms  -t nfs

次のコマンドは、異なるノード間においてWebCenter ContentファイルおよびInbound Refineryファイルを共有する方法を示します。

WCPAHOST1> mount nasfiler:/vol/vol3/ORACLE_BASE/admin/wcdomain/wcc_cluster_name/vault
-t nfs -o rw,bg,hard,vers=3,nolock

WCPHOST1> mount nasfiler:/vol/vol3/ORACLE_BASE/admin/wcdomain/ibr_cluster_name/
nfs -o rw,bg,hard,vers=3,nolock

WCPHOST2でも同様に実行します。

共有ストレージの構成の検証

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

例:

cd newly_mounted_directory
touch testfile

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

ls -l testfile

ファイルを削除します。

rm testfile

注意:

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

mount nasfiler:/vol/vol1/fmw11shared ORACLE_BASE/wls -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

使用する環境に適切なオプションについては、ストレージ・ベンダーとマシン管理者と相談してください。

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

この章を読んだ後には、このガイドで定義される推奨ファイル構造について理解できるようになります。また、Oracle WebCenter Contentエンタープライズ・デプロイメントの共有記憶域を構成する準備も整います。第5章「エンタープライズ・デプロイメント用のデータベースの準備」 では、データベースの設定方法、Oracle RACデータベース内のメタデータ・リポジトリのロード方法およびデータベースのバックアップ方法について説明しています。

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

この章では、Oracle WebCenter Contentエンタープライズ・デプロイメント用のデータベースの準備手順について説明します。この手順には、データベースの初期設定、メタデータ・リポジトリのロードおよびデータベースのバックアップが含まれます。

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

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

- 第5.2項「データベース要件」

- 第5.3項「データベース・サービスの作成」

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

- 第5.5項「データベースのバックアップ」

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

Oracle WebCenter Contentエンタープライズ・トポロジでは、データベースにOracle Fusion Middlewareリポジトリが含まれています。これは、Oracle SOA SuiteコンポーネントやOracle WebCenter Contentコンポーネントなど、Oracle Fusion Middlewareの各種コンポーネントによって使用されるスキーマを集めたものです。このデータベースは、アイデンティティ管理データベースとは別になっています。これは、Oracle Internet DirectoryやDIPなどのコンポーネントによってアイデンティティ管理のエンタープライズ・デプロイメントで使用されます。

Oracle Fusion Middlewareコンポーネントを構成するには、まずOracle Fusion Middlewareリポジトリをインストールする必要があります。リポジトリ作成ユーティリティ(RCU)を使用して既存のデータベースにOracle Fusion Middlewareメタデータ・リポジトリをインストールします。RCUは、RCUディストリビューション、または表2-2に記載された場所から入手できます。エンタープライズ・トポロジでは、Oracle Real Application Clusters (RAC)データベースを強くお薦めします。

Oracle SOA Suiteコンポーネントを構成すると、メタデータ・リポジトリを含むデータベースへの接続情報を入力するようにFusion Middleware構成ウィザードで求められます。

5.2 データベース要件

メタデータ・リポジトリをデータベースにロードする前に、次の各項で説明されている要件をデータベースが満たしていることを確認してください。

- 第5.2.1項「データベース・ホストの要件」

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

- 第5.2.3項「初期化パラメータ」

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

データ層内のCUSTDBHOST1およびCUSTDBHOST2には、次の要件があります。

- Oracle Clusterware
Linux用の11gリリース1(11.1)については、Oracle Clusterwareインストレーション・ガイドfor Linuxを参照してください。

- Oracle Real Application Cluster
Linux用の11gリリース1(11.1)については、Oracle Real Application Clustersインストレーション・ガイドfor Linux and UNIX Systemsを参照してください。Linux用の10gリリース2(10.2)については、Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイドfor Linuxを参照してください。

- 自動ストレージ管理(オプション)
ASMでは、ノードが全体としてインストールされます。データベースのOracleホームとは別のOracleホームにインストールすることをお薦めします。このオプションはrunInstallerにあります。「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択し、個別のASMホームを作成します。

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

Oracle WebCenter Contentでは、サポートされているデータベースおよびスキーマが存在することが要求されます。使用するデータベースが認証されていること、または認証済のすべてのデータベースを確認するには、Oracle Fusion Middleware Supported System ConfigurationsのページにあるOracle Fusion Middleware 11g リリース1 (11.1.1.x)の製品エリアを参照してください。

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

データベースのリリースをチェックするには、次のようにPRODUCT_COMPONENT_VERSIONビューに問い合せます。

SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE PRODUCT LIKE "Oracle%";

注意:

- Oracle WebCenter Contentは、メタデータ(10gまたは11g)の格納に使用するデータベースにAL32UTF8キャラクタ・セットをサポートするよう要求します。データベースの文字セットの選択に関する情報は、データベースのドキュメントを確認してください。

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

5.2.3 初期化パラメータ

必要な最小値に次の初期化パラメータが設定されていることを確認してください。これは、リポジトリ作成ユーティリティによってチェックされます。

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

構成

パラメータ

必要な値

パラメータ・クラス

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データベースへの接続の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドのサービスとVIPアドレスを使用したOracleデータベースへの接続の概要に関する項を参照してください。データベース・サービスの作成および管理の詳細な手順は、Oracle Real Application Clusters管理およびデプロイメント・ガイドの自動ワークロード管理の概要に関する項を参照してください。

ランタイム接続のロード・バランシングでは、ロード・バランシングが有効化されるサービスごとにサービスレベルの目標値を使用して、Oracle RACロード・バランシング・アドバイザを構成する必要があります。SERVICE_TIMEまたはTHROUGHPUTについて、Oracle RACロード・バランシング・アドバイザを構成できます。接続ロード・バランシングの目標をSHORTに設定します。Oracle Database 10gまたは11gリリース1 (11.1)では、DBMS_SERVICEパッケージを使用してこの変更を行います。Oracle Database 11gリリース2 (11.2)では、かわりにサーバー制御ユーティリティ(SRVCTL)を使用します。

Oracle WebCenter Contentインストールは、wccedg.mycompany.comサービスを使用するように構成されています。Oracle SOA Suiteでは、soaedg.mycompany.comという名前のサービスの使用をお薦めします。

注意:

簡略化のために、このガイドでのデータ・ソース構成の画面では同じサービス名(wccedg.mycompany.com)を使用します。

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

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

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

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

10gおよび11gリリース1 (11.1)データベース・サービスは、DBMS_SERVICEパッケージを使用して作成および変更できます。

10gまたは11.1データベース・サービスを作成および変更する手順は次のとおりです。

1. SQL*Plusにログインして、サービスを作成します。

sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'wccedg.mycompany.com',
NETWORK_NAME => 'wccedg.mycompany.com',
);

注意:

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

- 示されているEXECUTE DBMS_SERVICEコマンドは1行で入力します。
DBMS_SERVICEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプのリファレンスを参照してください。

2. SRVCTLのsrvctlコマンドを使用して、データベースにサービスを追加し、それをインスタンスに割り当てます。

srvctl add service -d ecmdb -s wccedg.mycompany.com -r ecmdb1,ecmdb2

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

srvctl start service -d ecmdb -s wccedg.mycompany.com

注意:

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

4. 次のどちらかのEXECUTEコマンドを使用して、適切なサービス目標でサービスを変更します。

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'wccedg.mycompany.com',goal => DBMS_SERVICE.GOAL_THROUGHPUT, clb_goal =>DBMS_SERVICE.CLB_GOAL_SHORT);

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'wccedg.mycompany.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のsrvctlコマンドを使用して作成および変更できます。

11.2データベース・サービスを作成および変更する手順は次のとおりです。

1. SQL*Plusにログインして、サービスを作成します。

sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'wccedg.mycompany.com',
NETWORK_NAME => 'wccedg.mycompany.com',
);

注意:

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

- 示されているEXECUTE DBMS_SERVICEコマンドは1行で入力します。
DBMS_SERVICEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプのリファレンスを参照してください。

2. 次のsrvctlコマンドを使用して、データベースにサービスを追加し、それをインスタンスに割り当てます。

srvctl add service -d ecmdb -s wccedg.mycompany.com -r ecmdb1,ecmdb2

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

srvctl start service -d ecmdb -s ecmedg.mycompany.com

注意:

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

4. 次のどちらかのsrvctlコマンドを使用して、適切なサービス目標でサービスを変更します。

srvctl modify service -d ecmdb -s wccedg.mycompany.com -B SERVICE_TIME -j SHORT

srvctl modify service -d ecmdb -s wccedg.mycompany.com -B         THROUGHPUT  -j SHORT

別のサービス定義の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドのロード・バランシング・アドバイザに関する項を参照してください。

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

リポジトリ作成ユーティリティ(RCU)はRCUディストリビューションから入手できます。データベースのシードに使用するRCUは、Oracle WebCenter Contentインストールのパッチ・セット・レベルと一致している必要があります。つまり、このエンタープライズ・デプロイメントにOracle WebCenter Content 11gリリース1 (11.1.1.6)をインストールする場合は、RCU 11gリリース1 (11.1.1.6)を使用する必要があります。

Oracle Fusion Middlewareリポジトリをデータベースにロードする手順は次のとおりです。

1. リポジトリ作成ユーティリティ(RCU)ディストリビューションを開いて、RCUホーム・ディレクトリのbinディレクトリからRCUを起動します。

cd RCU_HOME/bin
./rcu

2. 「ようこそ」画面で(表示されている場合のみ)、「次へ」をクリックします。

3. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。

4. 「データベース接続の詳細」画面(画面5-1)で、データベースの接続情報を入力します。

- データベース・タイプ: 「Oracle Database」を選択します。

- 「ホスト名」にデータベースが存在するノードの名前を指定します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します(例: CUSTDBVIP1)。

- ポート: データベースのリスニング・ポート番号である1521を指定します。

- 「サービス名」にデータベースのサービス名を指定します(wccedg.mycompany.com)。

- 「ユーザー名」にDBA権限またはSYSDBA権限を有するユーザーの名前(SYS)を指定します。

- パスワード: SYSユーザーのパスワードを入力します。

- ロール: データベース・ユーザーのロール(SYSDBA)をリストで選択します(SYSユーザーに必要)。

「次へ」をクリックします。

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

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

5. 使用中のデータベースでUTF-8キャラクタ・セットを使用していない場合には警告メッセージが表示され、多言語サポート対応のデータベースを使用した場合にデータ損失の可能性がある旨を通知します。今後、多言語サポートを使用しない場合は、「無視」をクリックすることもできます。それ以外の場合は、「停止」をクリックします。

6. 「コンポーネントの選択」画面(図5-2)で、次の手順を実行します。

- 「接頭辞の新規作成」を選択し、データベース・スキーマに使用する接頭辞を入力します(DEV、PRODなど)。6文字まで接頭辞として指定できます。接頭辞は、データベースで複数のリポジトリの論理グループを作成するために使用されます。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

ヒント:

スキーマ名を書き留めておきます。この情報は後続の手順で必要になります。

- 次のコンポーネントを選択します。

- AS共通スキーマ
- Metadata Services

- WebCenter Content:
- Oracle WebCenter Content Server - 完了

- Oracle WebCenter Content: Imaging

- SOAおよびBPMインフラストラクチャ:
- SOAインフラストラクチャ

- ユーザー・メッセージング(「SOAインフラストラクチャ」による自動選択)

「次へ」をクリックします。

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

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

7. 「スキーマ・パスワード」画面(図5-3)で、「補助スキーマにメイン・スキーマのパスワードを使用」を選択して「次へ」をクリックします。次の画面で、すべてのコンポーネントのスキーマ・パスワードを入力します。

ヒント:

スキーマ名を書き留めておきます。この情報は後続の手順で必要になります。

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

「図5-3 「スキーマ・パスワード」画面」の説明

8. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
確認のダイアログが表示され、選択したスキーマに存在しない表領域が作成されるという内容のメッセージが表示されます。「OK」をクリックして、このメッセージを確認します。

9. 「サマリー」画面で「作成」をクリックします。

10. 「完了サマリー」画面で「閉じる」をクリックします。

11. 追加した新しいユーザーでデータベースに接続し、必要なスキーマが正常に作成されていることを確認します。

ORACLE_HOME/bin/sqlplus

DEV_OCSユーザーとしてログインし、パスワードを入力します。スキーマ・バージョンのレジストリを検索することで、簡単な確認を実行できます。

-bash-3.00$ $ORACLE_HOME/bin/sqlplus DEV_OCS/password as SYSDBA
SQL> SELECT version, status FROM schema_version_registry where owner = "DEV_OCS";

VERSION STATUS-----------------------------------------11.1.1.6.0 VALID

注意:

Oracle WSMポリシーを格納するには、アイデンティティ管理用のデータベースを使用することをお薦めします(第15章「Oracle Identity Managementとの統合」を参照)。そのため、OWSM MDSスキーマのOracle Identity Managementデータベース接続情報が使用されることが予想されます。これは、その他のOracle SOA Suiteスキーマで使用されるデータベース情報とは異なります。データベースで必要なスキーマを作成するには、Oracle Identity Managementデータベース情報を使用して前述の手順を繰り返します。ただし、手順6の「コンポーネントの選択」画面では「AS共通スキーマ: Metadata Services」のみを選択します。

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

使用中のデータベースにメタデータ・リポジトリをロードした後は、まずバックアップを実行し、その後でエンタープライズ・デプロイメント用ソフトウェアをインストールする必要があります。

データベースのバックアップは、今後の手順で問題が発生した場合に迅速なリカバリを行うために明示的に行います。この目的のためにデータベースのバックアップ計画を使用することも、オペレーティング・システムのツールやRMANを使用して単純にバックアップすることもできます。特にデータベースがOracle ASMを使用して作成された場合は、データベースにOracle Recovery Managerを使用することをお薦めします。可能な場合、オペレーティング・システムのツール(tarなど)を使用してコールド・バックアップも実行できます。

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

この章では、Oracle WebCenter Contentエンタープライズ・デプロイメントの参照用トポロジに必要なソフトウェアをインストールする手順を説明します。Oracle HTTP Serverをインストールした後に、Oracle Fusion Middlewareをインストールします。

注意:

セットアップ・プロセスを開始する前に、リリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。これらは、Oracle Fusion Middlewareドキュメント・ライブラリ(http://docs.oracle.com/cd/E23943_01/relnotes.htm)で入手できます。

この章は次の項で構成されています。

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

- 第6.2項「Oracle HTTP Serverのインストール」

- 第6.3項「Oracle Fusion Middlewareのインストール」

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

エンタープライズ・デプロイメントのソフトウェアのインストールは、2つの部分に分割できます。最初のパートでは必要なWeb層のインストールについて説明し、2番目のパートでは必要なOracle Fusion Middleware (FMW)コンポーネントについて説明します。以降の章では、Oracle WebCenter Contentの参照用トポロジを作成するために必要な構成手順を説明します。

ソフトウェアの入手

ソフトウェアを入手する場所の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のOracle Fusion Middlewareソフトウェアの入手に関する項を参照してください。

いずれかのダウンロード場所を選択して、Oracle WebCenter ContentおよびOracle SOA Suiteをダウンロードします。ZIPアーカイブ・ファイルがシステムに保存されます。

アーカイブ・ファイルをダウンロードした後、インストールを実行するマシン上の任意のディレクトリにアーカイブ・ファイルを解凍します。

インストールするソフトウェア

表6-1に、各ホストにインストールする必要があるソフトウェアまたは各ホストからアクセス可能なソフトウェアを示します。

表6-1 各ホストにインストールする必要があるソフトウェアまたは各ホストからアクセス可能なソフトウェア

ホスト

Oracle HTTP Server

Oracle WebLogic Server

Oracle SOA Suite

Oracle WebCenter Content

WEBHOST1

X

WEBHOST2

X

SOAHOST1

X

X

X

SOAHOST2

X

X

X

WCCHOST1

X

X

X

WCCHOST2

X

X

X

6.2 Oracle HTTP Serverのインストール

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

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

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

- 第6.2.3項「インストールのバックアップ」

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

Oracle HTTP Server (OHS)をインストールする前に、ご使用のマシンが次の要件を満たしていることを確認します。

- 『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』で指定されているように、システム、パッチ、カーネルおよびその他の要件が満たされていることを確認します。

- Oracle HTTP Serverはデフォルトではポート7777にインストールされるので、ノード上のどのサービスでもポート7777を使用していないことを確認する必要があります。このポートが使用中かどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。

netstat -an | grep 7777

ポート7777が使用されている場合は解放する必要があります。

- Linuxプラットフォームで、 /etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいことおよびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

- インストールを開始する前に、次の環境変数が設定されていないことを確認します。

- LD_ASSUME_KERNEL

- ORACLE_INSTANCE

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

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

1. Oracle HTTP Serverのインストーラを次のインストール・メディアから起動します。

./runInstaller

2. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

2. インストールを実行するユーザーのOSグループを入力します。

3. 「次へ」をクリックします。

画面の手順に従って、/createCentralInventory.shをrootとして実行します。

「OK」をクリックします。

3. 「ようこそ」画面で、「次へ」をクリックします。

4. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

5. 「インストール・タイプの選択」画面でインストール - 構成なしを選択し、「次へ」をクリックします。

6. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

7. 「インストール場所の指定」画面で、次の値を指定します。

- Fusion Middlewareホームの場所(インストール場所): ORACLE_BASE/product/fmw

- Oracleホームの場所のディレクトリ: web

「次へ」をクリックします。

8. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。

9. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。正しくない場合は「戻る」をクリックして前の画面に戻り、選択を修正します。問題がなければ、「インストール」をクリックします。
UNIXシステムでoracleRoot.shスクリプトの実行を求められたら、rootユーザーとして実行します。

Oracle HTTP Serverソフトウェアがインストールされます。

10. 「インストール完了」画面で「終了」をクリックして終了します。

11. Oracle HTTP Serverのインストール後、MW_HOMEディレクトリに次のディレクトリが表示されることを確認し、インストールが成功したことを確認します。

- oracle_common

- web

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

この時点でMiddlewareホームをバックアップする必要があります(この時点ですべてのサーバーが停止していることを確認します)。

tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw HOME/oraInventory

6.3 Oracle Fusion Middlewareのインストール

この章では、Oracle WebCenter Contentエンタープライズ・デプロイメントの参照用トポロジに必要なOracle Fusion Middlewareソフトウェアをインストールする方法を説明します。インストールするソフトウェア・コンポーネントは、Oracle WebLogic Serverホーム(WL_HOME)およびOracleホーム(ORACLE_HOME)です。第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

注意:

セットアップ・プロセスを開始する前に、リリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。これらは、Oracle Fusion Middlewareドキュメント・ライブラリ(http://docs.oracle.com/cd/E23943_01/relnotes.htm)で入手できます。

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

- 第6.3.1項「Oracle WebLogic Serverのインストールとミドルウェア・ホームの作成」

- 第6.3.2項「Oracle Fusion Middlewareコンポーネントのインストール」

- 第6.3.3項「インストールのバックアップ」

6.3.1 Oracle WebLogic ServerのインストールおよびMiddlewareホームの作成

Oracle WebLogic ServerをSOAHOST1およびSOAHOST2にインストールする手順は次のとおりです。

注意:

64ビットJDKを使用して64ビット・プラットフォームにWebLogic Serverをインストールするための汎用インストーラ実行の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の64ビット・プラットフォームへの64ビットJDKを使用したWebLogic Serverのインストールに関する項を参照してください。

1. Oracle WebLogic Serverのインストーラを起動します。

$ ./wls1036_linux32.bin

2. 「ようこそ」画面で、「次へ」をクリックします。

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、次の手順を実行します。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します。
ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。このディレクトリは/u01/app/oracleとすることをお薦めします。詳細は、第4.3項「各種ディレクトリの推奨場所」を参照してください。

「次へ」をクリックします。

4. 「セキュリティ更新のための登録」画面で、セキュリティ更新の通知を受け取る連絡先の情報を入力して、「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。

6. 「製品とコンポーネントの選択」画面で、「次へ」をクリックします。

7. 「JDKの選択」画面で、「Oracle JRockit 1.6.0_version SDK」のみを選択して「次へ」をクリックします。

8. 「製品インストール・ディレクトリの選択」画面で、ORACLE_BASE/product/fmw/wlserver_10.3とORACLE_BASE/product/fmw/coherence_3.7ディレクトリを受け入れ、「次へ」をクリックします。

9. 「インストールの概要」画面で「次へ」をクリックします。
Oracle WebLogic Serverソフトウェアがインストールされます。

10. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

11. Oracle WebLogic Serverのインストール後、MW_HOMEディレクトリに次のディレクトリおよびファイルが表示されることを確認し、インストールが成功したことを確認します。

- coherence_version

- jrockit-jdkversion

- modules

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- wlserver_10.3

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

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

- 第6.3.2.1項「Oracle SOA Suiteのインストール」

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

6.3.2.1 Oracle SOA Suiteのインストール

Oracle SOA SuiteをSOAHOST1およびSOAHOST2にインストールする手順は次のとおりです

1. Linuxプラットフォームで、 /etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいことおよびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

2. Oracle SOA Suiteのインストーラを次のインストール・メディアから起動します。

./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します(例: ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version)。詳細は、第6.3.1項「Oracle WebLogic ServerのインストールおよびMiddlewareホームの作成」を参照してください。

注意:

インストールは共有記憶域で実行されるため、MW_HOMEは、WCCHOST1とWCCHOST2のOracle WebCenter Contentサーバーによるアクセスおよび使用が可能です。

3. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

2. インストールを実行するユーザーのOSグループを入力します。

3. 「OK」をクリックします。

画面の手順に従って、/createCentralInventory.shをrootとして実行します。

「OK」をクリックします。

4. 「ようこそ」画面で、「次へ」をクリックします。

5. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

6. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「OK」をクリックします。

7. 「インストール場所の指定」画面(図6-1)で、Oracle SOA Suiteのインストール場所を指定します。すでにインストールされているOracleミドルウェア・ホームをドロップダウン・リストから選択します。Oracleホーム・ディレクトリとして、ディレクトリ名soaを入力します。

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

「図6-1 インストーラ・ウィザードの「インストール場所の指定」画面」の説明

完了したら、「次」をクリックします。

8. 「アプリケーション・サーバー」画面で、「WebLogic Server」が選択されていること（これがデフォルト）を確認してから「次へ」をクリックします。

9. 「インストールの概要」画面で「インストール」をクリックします。
Oracle SOA Suiteソフトウェアがインストールされます。

10. 「インストール 完了」画面で「終了」をクリックします。

11. Oracle WebLogic Server、Oracle Fusion Middlewareおよび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

6.3.2.2 Oracle WebCenter Contentのインストール

Oracle WebCenter Contentソフトウェア・スイートをインストールする際には、次の機能セットに対応する製品ビットをシステムにインストールします。

- Oracle WebCenter Content

- Oracle WebCenter Content: Imaging

- Oracle WebCenter Content: Records

- Oracle WebCenter Content: Inbound Refinery

SOAHOST1およびSOAHOST2にOracle WebCenter Contentをインストールする手順は次のとおりです。

注意:

インストールは共有記憶域で実行されるため、MW_HOMEは、WCCHOST1とWCCHOST2のOracle WebCenter Contentサーバーによるアクセスおよび使用が可能です。

1. Oracle WebCenter Contentのインストーラを起動します。

./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します(例: ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version)。詳細は、第6.3.1項「Oracle WebLogic ServerのインストールおよびMiddlewareホームの作成」を参照してください。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

4. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

5. 「インストール場所の指定」画面で、Oracle WebCenter Contentをインストールする場所を指定します。すでにインストールされているOracleミドルウェア・ホームをドロップダウン・リストから選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(wcc)を入力します。
完了したら、「次」をクリックします。

6. 「アプリケーション・サーバー」画面で、「WebLogic Server」が選択されていること（これがデフォルト）を確認してから「次へ」をクリックします。

7. 「インストールの概要」画面で「インストール」をクリックします。
Oracle WebCenter Contentソフトウェアがインストールされます。

8. 「インストール 完了」画面で「終了」をクリックします。

9. Oracle WebLogic Server、Oracle Fusion Middleware、Oracle SOA SuiteおよびOracle WebCenter Contentのインストール後、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

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

この時点でSOAHOST1からMiddlewareホームをバックアップする必要があります(まず、サーバーが停止していることを確認します)。

tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw

Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントの両方のインストール・ファイルのバックアップが作成されます。

7 Web層の構成

この章では、Oracle Fusion Middleware WebCenter Contentの実装をサポートするOracle Web層の構成方法を説明します。

この章は次の項で構成されています:

- 第7.1項「Web層構成の概要」

- 第7.2項「構成ウィザードによるOracle HTTP Serverの構成」

- 第7.3項「インストールの検証」

- 第7.4項「Oracle Web層とOracle WebLogicドメインの関連付け」

- 第7.5項「Oracle HTTP Serverでのロード・バランサの構成」

- 7.6項「仮想ホストの構成」

7.1 Web層構成の概要

Oracle Web層ソフトウェアを構成する前に、第6.2項「Oracle HTTP Serverのインストール」の説明に従ってこのソフトウェアをWEBHOST1とWEBHOST2にインストールする必要があります。Fusion Middleware構成ウィザードを実行して、インスタンス・ホーム、インスタンス名およびOracle HTTP Serverコンポーネント名を定義します。

またこの章では、Oracle Web層をWebLogic Serverドメインに関連付ける方法を説明します。Web層をWebLogic Serverに関連付けすると、Oracle Fusion Middlewareコンソールを使用してWeb層を監視できるようになります。

その後、すべてのHTTPリクエストをWEBHOST1およびWEBHOST2にルーティングするようロード・バランサを構成します。

最後の項では、両方のOracle HTTP Server上にあるhttpd.confファイルの<VirtualHost>セクションのディレクティブを定義する方法について説明します。これらの仮想ホスト名は、第3.3項「ロード・バランサの構成」でロード・バランサを構成したときに作成したものです。

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

Oracle Web層の構成手順は、WEBHOST1とWEBHOST2で同じです。

Oracle Web層を構成する手順は次のとおりです。

1. Oracle Fusion Middleware構成ウィザードの場所にディレクトリを変更します。

cd ORACLE_COMMON_HOME/common/bin

2. 構成ウィザードを起動します。

./config.sh

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「コンポーネントの構成」画面で「Oracle HTTP Server」を選択し、「選択されたコンポーネントとWebLogicドメインの関連付け」の選択を解除します。「Oracle Web Cache」は選択されていないことを確認します。
「次へ」をクリックします。

5. 「コンポーネントの詳細の指定」画面で、次の値を指定します。

- インスタンス・ホームの場所: ORACLE_BASE/admin/webn

- ASインスタンス名: webn

- OHSコンポーネント名: ohsn

(ここでnは、インストール上の連番を示します。たとえば、WEBHOST1には1、WEBHOST2には2などです。)

注意:

WEBHOST1とWEBHOST2で、異なるOracle HTTP Serverインスタンス名を指定する必要があります。

「次へ」をクリックします。

6. 高可用性の実装では、様々なコンポーネントで使用されるすべてのポートをホスト間で同期することは必須ではありません。ただし、これを実行すると、エンタープライズ・デプロイメントはずっと簡略化されます。使用するポートをファイルに指定することで、自動ポート構成をバイパスできます。
「ポートの構成」画面でファイル名を選択し、「表示/編集」をクリックします。ファイルは次のようになります。

[OHS]
#Listen port for OHS component
OHS Port = 7777

[OPMN]
#Process Manager Local port no
OPMN Local Port = 1880

サンプルのstaticports.iniファイルは、インストール・ディスク1のstage/Responseディレクトリにあります。

「次へ」をクリックします。

7. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。

8. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。問題がなければ、「構成」をクリックします。

9. 複数のConfiguration Assistantが連続して起動されるため、時間がかかることがあります。終了したら、「次へ」をクリックすると、「インストール 完了」画面が表示されます。

10. 「インストール完了」画面で「終了」をクリックして終了します。

7.3 インストールの検証

インストールが完了したら、Oracle HTTP Serverホーム・ページに、次のURLからアクセスできることを確認します。

http://webhost1.mycompany.com:7777/

7.4 Oracle Web層とOracle WebLogicドメインの関連付け

一度Oracle WebLogicドメインを作成すると、Oracle Web層をドメインに接続できます。これには、Oracle Fusion Middlewareコンソールを使用してOracle Web層を管理および監視できるというメリットがあります。

Oracle Web層とWebLogicドメインを関連付けるには、次のコマンドをWEBHOST1とWEBHOST2の両方で実行します。

cd ORACLE_BASE/admin/instance_name/bin

./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic

7.5 ロード・バランサを使用したOracle HTTP Serverの構成

Oracle HTTP Server(WEBHOST1、WEBHOST2)を実行するホストへすべてのHTTPリクエストをルーティングするようロード・バランサを構成できます。Oracle HTTP ServerがフロントエンドのOracle WebLogic Serverである場合は、ロード・バランサでスティッキー・セッション(Cookieの挿入)を有効にする必要はありません。このドキュメントで説明するトポロジには該当しませんが、ロード・バランサからOracle WebLogic Serverに直接移動する場合にはスティッキー・セッションが必要です。HTTPの監視も設定する必要があります。

使用するロード・バランサによって、構成手順は異なります。具体的な手順は、ロード・バランサのドキュメントを参照してください。

7.6 仮想ホストの構成

仮想ホストを構成するには、次の3つのタスクを実行します。

1. 第7.6.1項「httpd.confファイルの編集による<VirtualHost>ディレクティブの定義」

2. 第7.6.2項「両方のOracle HTTP Serverの再起動」

3. 第7.6.3項「構成の検証」

7.6.1 httpd.confファイルの編集による<VirtualHost>ディレクティブの定義

Oracle WebCenter Contentをロード・バランサとともに動作させるには、Oracle HTTP Server構成内に仮想ホストを作成する必要があります。ORACLE_INSTANCE/config/OHS/ohs1(またはohs2)にあるhttpd.confファイルを編集して、<VirtualHost>セクションに次のエントリを追加します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://wcc.mycompany.com:443
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName admin.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName soainternal.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

7.6.2 両方のOracle HTTP Serverの再起動

httpd.confファイルを変更した後で両方のOracle HTTP Serverを再起動します。WEBHOST1とWEBHOST2の両方で、次のコマンドを実行します。

cd ORACLE_BASE/admin/instance_name/bin

opmnctl stopall

opmnctl startall

7.6.3 構成の検証

次のURLにアクセスして、ロード・バランサとOracle HTTP Serverが正しく構成されていることを確認します。

- http://WEBHOST1.mycompany.com:7777/

- http://WEBHOST2.mycompany.com:7777/

これらのURLにアクセスできない場合は、第3.3項「ロード・バランサの構成」の手順を正しく実行していることを確認してください。

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

この章では、Oracle Fusion Middleware構成ウィザード、Oracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlを使用してドメインを作成する方法について説明します。ドメインを拡張することで、Fusion Middleware (FMW)コンポーネント(Oracle SOA SuiteおよびOracle WebCenter Content、さらにオプションでOracle WebCenter Content: ImagingおよびOracle WebCenter Content: Inbound Refinery)を追加できます。これは、このドキュメントの後続の章で説明します。

注意:

セットアップ・プロセスを開始する前に、リリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。これらは、Oracle Fusion Middlewareドキュメント・ライブラリ(http://docs.oracle.com/cd/E23943_01/relnotes.htm)で入手できます。

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

- 第8.1項「ドメイン作成の概要」

- 第8.2項「SOAHOST1でのADMINVHNの有効化」

- 第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」

- 第8.4項「構成後タスクおよび検証タスク」

- 第8.5項「WebLogicドメインのOracle HTTP Serverの構成」

- 第8.6項「WebLogic Serverドメイン構成のバックアップ」

8.1 ドメイン作成の概要

表8-1に、構成後タスクを含む、WebLogicドメインの作成手順を示します。

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

手順

説明

詳細

SOAHOST1でのVIP1の有効化

SOAHOST1ホスト名に対してADMINVHNを有効にします。

第8.2項「SOAHOST1でのADMINVHNの有効化」

WebLogicドメインの作成

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

第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」

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

構成後タスクおよび検証タスクの手順に従います。

第8.4項「構成後タスクおよび検証タスク」

WebLogicドメインでのOracle HTTP Serverの構成

WebLogicドメインを使用してOracle HTTP Serverを構成し、その構成を検証します。

第8.5項「WebLogicドメインのOracle HTTP Serverの構成」

ドメインのバックアップ

新しく構成したWebLogicドメインをバックアップします。

第8.6項「WebLogic Serverドメイン構成のバックアップ」

このドメインを作成し構成すると、次の章で説明するとおり、ドメインの拡張によってOracle SOA SuiteコンポーネントおよびOracle WebCenter Contentコンポーネントを追加できます。

8.2 SOAHOST1でのADMINVHNの有効化

この手順は、他のFusion Middlewareコンポーネントを後でインストールするかどうかにかかわらず、管理サーバーをフェイルオーバーするために必要となります。

管理サーバーに仮想ホスト名(ADMINVHN)を関連付けます。この仮想ホスト名は、DNSサーバーとカスタムの/etc/hostエントリのいずれかによって、適切なVIP(VIP1)にマップする必要があります。Oracle WebCenter Contentトポロジ内の必要なノードにある名前解決システム(DNSサーバー、/etc/hosts)に応じてADMINVHNが使用可能であることを確認します。この仮想ホスト名(ADMINVHN1)に関連付けられたVIP(VIP1)はSOAHOST1で有効になっている必要があります。

Linuxで仮想IPを有効にする手順は次のとおりです。

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

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

例:

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

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

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

3. 次の例のように、別のノードからこのアドレスにpingを実行して、このアドレスが使用可能であることを確認します。

/bin/ping 100.200.140.206

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

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

Oracle共通ホーム・ディレクトリからOracle Fusion Middleware構成ウィザードを実行して、管理サーバーを含むドメインを作成します。その後に、ドメインを拡張して他のコンポーネントを追加します。

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. SOAHOST1で、ディレクトリをOracle Fusion Middleware構成ウィザードの場所(第6章「エンタープライズ・デプロイメント用ソフトウェアのインストール」で作成)に変更します。

cd ORACLE_COMMON_HOME/common/bin

3. 構成ウィザードを起動します。

./config.sh

4. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

5. 「ドメイン・ソースの選択」画面が開きます(図8-1)。

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

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

「ドメイン・ソースの選択」画面で、次の手順を実行します。

- 「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

- 次の製品を選択します。

- WebLogic Serverの基本ドメイン - 10.3.6.0 [wlserver_10.3](これは自動的に選択されます)

- Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

いくつかのターゲットを間違って選択解除した場合は、この画面で次の項目が選択されていることを確認します。

- Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

- Oracle JRF - 11.1.1.0 [oracle_common]

「次へ」をクリックします。

6. 「ドメイン名と場所の指定」画面で、ドメイン名(domain_name)を入力します。
第3章「エンタープライズ・デプロイメント用ネットワークの準備」で推奨されるディレクトリおよび共有記憶域のマウント・ポイントにドメイン・ディレクトリが一致していることを確認します。ドメイン・ディレクトリにはORACLE_BASE/admin/domain_name/aserver、アプリケーション・ディレクトリにはORACLE_BASE/admin/domain_name/aserver/applicationsを入力します。このドメインは共有記憶域内にある必要があります。

「次へ」をクリックします。

7. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者が使用するユーザー名とパスワードを入力します。
「次へ」をクリックします。

8. 「サーバーの起動モードおよびJDKの構成」画面で、次の手順を実行します。

- 「WebLogicドメインの起動モード」には、「本番モード」を選択します。

- 「JDKの選択」では、「JROCKIT SDK1.6.0_version」を選択します。

「次へ」をクリックします。

9. 「オプションの構成を選択」画面で、次の項目を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

「次へ」をクリックします。

10. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: ADMINVHN

- リスニング・ポート: 7001

- SSLリスニング・ポート: N/A

- SSL有効: このチェック・ボックスは選択解除したままにします。

「次へ」をクリックします。

11. 「管理対象サーバーの構成」画面で、「次へ」をクリックします。

12. 「クラスタの構成」画面で、「次へ」をクリックします。

13. 「マシンの構成」画面で、「UNIXマシン」タブを開き、「追加」をクリックして次のマシンを追加します。

表8-2 マシン

名前

ノード・マネージャのリスニング・アドレス

ADMINVHN

localhost

他のフィールドはすべてデフォルト値のままにします。マシン名は有効なホスト名またはリスニング・アドレスである必要はありません。これはノード・マネージャの場所を示す一意の識別子であることに注意してください。

「次へ」をクリックします。

14. 「サーバーのマシンへの割当」画面で、次のように管理サーバーをマシンに割り当てます。

- ADMINVHN

- AdminServer

「次へ」をクリックします。

15. 「構成サマリー」画面で「作成」をクリックします。

16. 「ドメインの作成」画面で「完了」をクリックします。

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

構成ウィザードでドメインを構成した後は、次の手順に従って構成後タスクと検証タスクを実行します。

この項は次のトピックで構成されています。

- 第8.4.1項「RACデータベース・サービスの確認」

- 第8.4.2項「SOAHOST1での管理サーバー用boot.propertiesの作成」

- 第8.4.3項「SOAHOST1でのノード・マネージャの起動」

- 第8.4.4項「SOAHOST1での管理サーバーの起動」

- 第8.4.5項「管理サーバー構成の検証」

- 第8.4.6項「管理サーバーに対するホスト名検証の無効化」

8.4.1 RACデータベース・サービスの確認

両方のRACデータベース・インスタンスを起動して、サービスが稼動していることを確認します。

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

SOAHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。このファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。

1. SOAHOST1上で次のディレクトリ構造を作成します。

mkdir -p ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security

2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=Admin_Username
password=Password

注意:

管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。第8.4.4項「SOAHOST1での管理サーバーの起動」に記載した管理サーバーを起動します。セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、できるだけ速やかにサーバーを起動し、エントリを暗号化してください。

3. ファイルを保存してエディタを閉じます。

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

SOAHOST1でノード・マネージャを起動するには、StartScriptEnabledプロパティをtrueに設定し、startNodeManager.shを使用してノード・マネージャを起動します。

SOAHOST1でノード・マネージャを起動する手順は次のとおりです。

1. ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定した後に、ノード・マネージャを起動します。

cd ORACLE_COMMON_HOME/common/bin

./setNMProps.sh

注意:

クラスのロードの失敗やその他の問題を回避するには、StartScriptEnabledプロパティを使用します。第16.11.3項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」も参照してください。

2. ノード・マネージャを起動します。

cd WL_HOME/server/bin

export JAVA_OPTIONS=-DDomainRegistrationEnabled=true

./startNodeManager.sh

注意:

管理サーバーを管理するノード・マネージャを起動しているときは、次のパラメータを-DDomainRegistrationEnabled=trueに設定することが重要になります。マシンに管理サーバーがなく、そのマシンが管理サーバーのフェイルオーバー・ノードでない場合には、次のスクリプトを使用してノード・マネージャを起動できます。

./startNodeManager.sh

(exportコマンドは必要ありません。)

注意:

ノード・マネージャの出力から、ノード・マネージャが適切なストアおよび別名を使用していることを確認します。ノード・マネージャのプロンプトは次のようになります。

CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks
CustomIdentityAlias=appIdentityX

ホスト名の検証は、テスト構成の変更をサーバーに適用した場合に実行され、ノード・マネージャからSSLエラーの報告がない場合には正常終了します。

8.4.4 SOAHOST1での管理サーバーの起動

管理サーバーは、ノード・マネージャを使用して起動および停止します。ただし、初めてノード・マネージャで管理サーバーを起動するときに、Oracle Fusion Middleware構成ウィザードによってノード・マネージャに設定されたデフォルトのユーザー名およびパスワードを変更する必要があります。したがって、初回の起動時には、管理サーバーの起動スクリプトを使用する必要があります。ノード・マネージャを使用して管理サーバーを起動するには、次の手順に従います(初回起動時は手順1から4までが必要で、それ以後の起動はすべて手順4のみが必要になります)。

1. SOAHOST1で、ドメイン・ディレクトリの起動スクリプトを使用して管理サーバーを起動します。

cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin

./startWebLogic.sh

2. 管理コンソールを使用してノード・マネージャの資格証明を更新します。

1. Webブラウザを開き、http://ADMINVHN:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. 「ロックして編集」をクリックします。

4. 「domain_name」→「セキュリティ」→「一般」をクリックして、一番下にある「詳細」オプションを開きます。

5. ノード・マネージャの新しいユーザー名を入力するか、既存のユーザー名を書き留めておいてノード・マネージャのパスワードを更新します。

6. 変更を保存してアクティブ化します。

3. 管理サーバーのプロセスを停止します。それには、このプロセスが起動されたシェルでCtrl+Cを使用するか、または標準のプロセス識別子とオペレーティング・システムのkillコマンドを使用します。

4. Oracle WebLogic Scripting Tool (WLST)を起動し、nmconnectおよび前の手順で設定した資格証明によりノード・マネージャに接続し、nmstartを使用して管理サーバーを起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

WLSTシェル内で、次のコマンドを実行します(ノード・マネージャが稼働していることを確認します)。

wls:/offline>nmConnect("Admin_User","Admin_Pasword", "SOAHOST1","5556","domain_name","/u01/app/oracle/admin/domain_name/aserver/domain_name")

wls:/nm/domain_name> nmStart("AdminServer")

注意:

SOAHOST1は、ドメインを作成したノードのアドレスで、管理サーバーのリスニング・アドレスではありません。
また、ユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理者のIDおよびパスワードとは関係なく、ORACLE_BASE/admin/domain_name/aserver/domain_name/config/nodemanager/nm_password.propertiesファイルに格納されています。

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

作成したドメインの管理サーバーが適切に構成されていることを確認するには、Oracle 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.2項「SOAHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してFusion Middleware Controlにログインします。

管理サーバーが稼働している必要があります。

8.4.6 管理サーバーに対するホスト名検証の無効化

この手順は、管理サーバーで様々なノードを認証するための適切な証明書を設定していない場合に必要です(第13章「ノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、異なるWebLogicサーバーを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定および検証の間はホスト名の検証を無効にし、エンタープライズ・デプロイメント・トポロジの構成完了後に、第13章「ノード・マネージャの設定」の説明に従って再度ホスト名の検証を有効にします。

ホスト名検証を無効化するには:

1. WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 「サーバーのサマリー」ページで、表の「名前」列にある管理サーバー(管理者)を選択します。

6. サーバーの設定ページで「SSL」タブを開きます。

7. 表示されたページの「詳細」セクションを開きます。

8. ホスト名の検証をNoneに設定します。

9. 「保存」をクリックします。

10. 変更を保存してアクティブ化します。

11. この変更内容は、管理サーバーが再起動されるまでは有効になりません(ノード・マネージャが稼働している必要があります)。

1. 次のコマンドを使用して、管理サーバーを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

2. 第8.4.4項「SOAHOST1での管理サーバーの起動」の説明に従って管理サーバーを再起動します。

8.5 WebLogicドメインのOracle HTTP Serverの構成

この項では、WebLogicドメインにおけるOracle HTTP Serverの構成タスクおよびその構成の検証タスクについて説明します。

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

- 第8.5.1項「管理サーバー用のOracle HTTP Serverの構成」

- 第8.5.2項「WebLogicプラグイン有効化フラグの有効化」

- 第8.5.3項「WebLogic ServerへのOracle HTTP Serverの登録」

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

- 第8.5.5項「Oracle HTTP Serverを使用したアクセスの検証」

- 第8.5.6項「管理サーバーの手動フェイルオーバーの確認」

8.5.1 管理サーバーでのOracle HTTP Serverの構成

Oracle HTTP Serverから管理サーバーへのルーティングを有効にするには、HTTPサーバーの構成に対応するマウント・ポイントを設定する必要があります。

1. WEBHOST1およびWEBHOST2上の各Webサーバーで、ORACLE_INSTANCE/config/OHS/component_name/mod_wl_ohs.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上の各Webサーバーで、ORACLE_INSTANCE/config/OHS/component_name/httpd.confファイルに次の行が含まれていることを確認します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName admin.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

注意:

ここで挙げている7777、admin.mycompany.com:80、you@your.addressなどの値は、単なる例です。これらのかわりに、実際の環境に基づいた値を入力してください。

3. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohsX

ias-componentに対して、WEBHOST1ではohs1を使用し、WEBHOST2ではohs2を使用します。

8.5.2 WebLogicプラグインをオンにするフラグの有効化

セキュリティ上の目的で、またロード・バランサがSSLリクエストを終了させる(Oracle HTTP ServerがWebLogic Serverに非SSLとしてリクエストをルーティングする)ために、一度ロード・バランサにSSLを構成した場合は、そのドメインに対しWebLogicプラグインの有効化フラグをオンにする必要があります。ロード・バランサにSSLを構成している場合にのみこれが行われることを確認します。この処理を実行するには、次の手順に従います。

1. 管理コンソールにログインします。

2. 左側のナビゲーション・ツリーでドメイン名をクリックします。

3. 「Webアプリケーション」タブを開きます。

4. 「ロックして編集」をクリックします。

5. 「WebLogicプラグインの有効化」チェック・ボックスを選択します。

6. 変更を保存してアクティブ化します。

7. 管理サーバーを再起動します(管理コンソールが特に要求しない場合でも再起動してください)。

8.5.3 WebLogic ServerへのOracle HTTP Serverの登録

Oracle WebLogicドメインが作成されると、Oracle Web層をドメインに接続できます。これには、Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Web層を管理および監視できるというメリットがあります。

Oracle Web層をWebLogicドメインに関連付けるには、WEBHOST1で次のコマンドを使用します。

cd ORACLE_BASE/admin/instance_name/bin

./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic

このコマンドは、OHS2に対してWEBHOST2からも実行する必要があります。

登録したOracle HTTP ServerはFusion Middleware Controlで管理可能なターゲットとして表示されます。これを確認するには、Fusion Middleware Controlにログインします。ナビゲーション・ツリーのWeb層の項目にOracle HTTP Serverが登録されていることが示されます。

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

ロード・バランサを使用してWebLogic Server管理コンソールにアクセスする際には、管理サーバーのフロントエンドURLを変更し、適切なロード・バランサ・アドレスにユーザーのWebブラウザをリダイレクトする必要があります。

WebLogic Server管理コンソール・アプリケーションでは、コンソールを使用して、ポート、チャネル、セキュリティに対する変更を追跡します。コンソールを使用して行われた変更をアクティブ化するとき、コンソールは現在のリスニング・アドレス、ポートおよびプロトコルを検証します。このリスニング・アドレス、ポートおよびプロトコルがまだ有効の場合、コンソールはHTTPリクエストをリダイレクトし、ホストとポートの情報を管理サーバーのリスニング・アドレスとポートに置き換えます。

管理サーバーのフロントエンドURLを変更する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 「サーバーのサマリー」ページで、表の「名前」列にある「管理サーバー」を選択します。

6. 管理サーバー(管理者)の設定ページで「プロトコル」タブを開きます。

7. 「HTTP」タブを開きます。

8. 「フロントエンド・ホスト」フィールドをadmin.mycompany.comに設定し、「フロントエンドHTTPポート」フィールドを80に設定します(管理URLにHTTPSを使用する場合は適宜変更します)。

9. 変更を保存してアクティブ化します。

10. WebLogic Server管理コンソールでの構成変更の追跡を無効にして、変更がアクティブ化されたときにコンソールによって構成ページがリロードされないようにします。

1. WebLogicサーバーの管理コンソールにログインします。

2. バナー内の「プリファレンス」リンクをクリックします。

3. 「共有プリファレンス」タブを開きます。

4. 「構成変更の追跡」チェック・ボックスを選択解除します。

5. 「保存」をクリックします。

注意:

フロントエンド・ホストやポートの設定を変更した後、構成の変更をアクティブ化できない場合は、第16.11.10項「管理コンソールで変更をアクティブ化した後にユーザーがログイン画面にリダイレクトされる」を参照してください。

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

管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.11項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

次のURLを使用して、両方のOracle HTTP Serverインスタンスを介した管理コンソールとOracle Enterprise Manager Fusion Middleware Controlへのアクセスを検証します。

- http://WEBHOST1:7777/console

- http://WEBHOST2:7777/console

- http://WEBHOST1:7777/em

- http://WEBHOST2:7777/em

- http://admin.mycompany.com/console

- http://admin.mycompany.com/em

フロントエンドURLをロード・バランサのアドレスに設定すると、WEBHOSTnアドレスを介したコンソールへのアクセスはコンソールによってフロントエンドURLにリダイレクトされるため、Oracle HTTP Serverとロード・バランサの両方の構成が正しいことを検証できます。

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

第8.5.3項「WebLogic ServerへのOracle HTTP Serverの登録」の説明に従ってOracle HTTP Serverを登録すると、Fusion Middleware Controlに管理可能なターゲットとして表示されます。これを確認するには、Fusion Middleware Controlにログインします。ナビゲーション・ツリーのWeb層の項目にOracle HTTP Serverが登録されていることが示されます。

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

ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをSOAHOST1からSOAHOST2にフェイルオーバーする方法を説明します。

- 第8.5.6.1項「前提条件および手順」

- 第8.5.6.2項「Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証」

- 第8.5.6.3項「SOAHOST1への管理サーバーのフェイルバック」

8.5.6.1 前提条件および手順

次の前提条件に注意してください。

- 管理サーバーは、任意のアドレスではなくADMINVHNをリスニングするよう構成されています。第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順13を参照してください。

- 管理サーバーはSOAHOST1からSOAHOST2にフェイルオーバーされ、この2つのノードには次のIPアドレスが割り当てられています。

- SOAHOST1: 100.200.140.165

- SOAHOST2: 100.200.140.205

- ADMINVHN: 100.200.140.206。これは管理サーバーを実行している場所のVIPであり、ethX:Yに割り当てられており、SOAHOST1とSOAHOST2からアクセスできます。

- SOAHOST1での管理サーバーの実行場所であるドメイン・ディレクトリは共有記憶域にあり、SOAHOST2からもマウントされています。

- 第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」の説明のとおり、Oracle WebLogic ServerおよびOracle Fusion MiddlewareコンポーネントはSOAHOST2にインストールされています(つまり、SOAHOST1に存在するORACLE_HOMEおよびMW_HOMEのパスをSOAHOST2でも使用できます)。

手順

次の手順は、管理サーバーを別のノード(SOAHOST2)にフェイルオーバーする方法を示します。

1. 管理サーバーが実行されている場合は停止します。

2. IPアドレスを第2ノードに移行します。

1. SOAHOST1上で次のコマンドをroot権限で実行します(ここでは、X:YがADMINVHNで現在使用されているインタフェースになります)。

/sbin/ifconfig ethX:Y down

2. 次のコマンドをSOAHOST2上で実行します。

/sbin/ifconfig interface:index IP_address netmask netmask

例:

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、SOAHOST2で使用可能なネットワーク構成と一致している必要があります。また、第4.3項「各種ディレクトリの推奨場所」で説明するとおりの位置に、管理サーバー・アプリケーションのディレクトリがマウントされていることを確認してください。

3. 次の例のとおり、arpingを使用してSOAHOST2のルーティング表を更新します。

/sbin/arping -b -A -c 3 -I eth0 100.200.140.206

3. 第8.4.3項「SOAHOST1でのノード・マネージャの起動」の説明に従って、SOAHOST2でノード・マネージャを起動します。

4. 第8.4.4項「SOAHOST1での管理サーバーの起動」の説明に従って、SOAHOST2上で管理サーバーを起動します。

5. 次の方法でSOAHOST2上の管理サーバーにアクセスできることをテストします。

1. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにアクセスできることを確認します。

2. http://ADMINVHN:7001/emでOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、そのコンポーネントのステータスを確認します。

8.5.6.2 Oracle HTTP Serverを使用したSOAHOST2へのアクセスの検証

第8.5.5項「Oracle HTTP Serverを使用したアクセスの検証」と同様の手順を実行します。この目的は、SOAHOST2で稼働中の管理サーバーにアクセスできることを確認することにあります。

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

この手順により、管理サーバーをフェイルバックできることを確認します。すなわち、SOAHOST2では管理サーバーを停止し、SOAHOST1で再び管理サーバーを実行します。これを実行するには、次の手順に従ってADMINVHNを元のSOAHOST1ノードに移行します。

1. 管理サーバーが起動されていないことを確認します。

2. 次のコマンドをSOAHOST2上で実行します。

/sbin/ifconfig ethZ:N down

3. 次のコマンドをSOAHOST1上で実行します。

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、SOAHOST1で使用可能なネットワーク構成と一致している必要があります。

4. arpingを使用し、ルーティング表を更新します。次のコマンドをSOAHOST1から実行します。

/sbin/arping -b -A -c 3 -I ethZ 100.200.140.206

5. 第8.4.4項「SOAHOST1での管理サーバーの起動」の説明に従って、SOAHOST1上で管理サーバーを再起動します。

6. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにアクセスできるかどうかテストします。

7. http://ADMINVHN:7001/emでOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認し、そのコンポーネントのステータスを確認します。

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

拡張したドメインが正常に動作していることを確認した後、バックアップを実行して、ドメイン構成を保存します。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。また、データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ガイドを参照してください。

この時点でのインストールをバックアップするには、次の手順に従います。

1. 次の手順に従って、WEBHOST1からWeb層をバックアップします。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドを使用して、Web層のOracleインスタンスをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

cd ORACLE_BASE/admin/instance_name/bin

opmnctl startall

2. WEBHOST2に対して手順1を繰り返します。

3. データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。

4. 管理サーバーを停止し、そのドメイン・ディレクトリをバックアップすることでドメイン構成を保存します。構成ファイルはすべて、ORACLE_BASE/admin/domain_nameディレクトリにあります。SOAHOST1で次のコマンドを実行して、バックアップを作成します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

管理サーバーをもう一度再起動します。

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

この章では、Oracle Fusion Middleware構成ウィザードを使用して、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成されたドメインを拡張し、Oracle SOA SuiteコンポーネントとOracle WSM Policy Managerを含める方法について説明します。次の章の説明に従うと、作成されたドメインを拡張し、他のFusion Middlewareコンポーネントを追加できます。SOA Oracleホーム(バイナリ)がインストール済でSOAHOST1とSOAHOST2からアクセス可能であること、および管理サーバーが属するドメインが作成済であることを前提としています。この章では、このドメインを拡張して、Oracle SOA Suiteコンポーネントをサポートします。

注意:

セットアップ・プロセスを開始する前に、リリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。これらは、Oracle Fusion Middlewareドキュメント・ライブラリ(http://docs.oracle.com/cd/E23943_01/relnotes.htm)で入手できます。

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

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

- 第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」

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

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

- 第9.5項「構成後タスクおよび検証タスクの実行」

- 第9.6項「Oracle Web Services Manager用のJavaオブジェクト・キャッシュの構成」

- 第9.7項「WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成」

- 第9.8項「フロントエンドHTTPホストおよびポートの設定」

- 第9.9項「Oracle HTTP Serverを使用したアクセスの検証」

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

- 第9.11項「OracleファイルとFTPアダプタの高可用性化」

- 第9.12項「Oracleデータベース・アダプタのスケーリング」

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

- 第9.14項「WLS_SOA管理対象サーバー用のサーバー移行の構成」

- 第9.15項「インストールのバックアップ」

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

WebLogicドメインを拡張して、Oracle SOA Suiteコンポーネントを追加します。表9-1に、Oracle SOA Suiteの構成手順と、Oracle SOA Suiteコンポーネントを使用するためのドメインの拡張に必要なタスクを示します。

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

手順

説明

詳細

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

各ホスト名でVIPマッピングを有効にし、SOA WebLogic Serverクラスタのシステム・クロックを同期します。

第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogicドメインを拡張します。

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

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

コンポジットのデプロイにユニキャスト通信を使用するためOracle Coherenceを構成します。

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

構成後タスクおよび検証タスクの実行

構成後タスクおよび検証タスクの手順に従います。

第9.5項「構成後タスクおよび検証タスクの実行」

GridLinkデータ・ソースおよびOracle Notification Service (ONS)の構成の確認

GridLinkデータ・ソースおよびONSの構成が適切であることを確認する手順に従います。

第9.5.3項「GridLinkデータ・ソースの検証」

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

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第9.5.6項「SOAHOST2へのドメイン構成の伝播」

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

管理対象サーバーとともにOracle HTTP Serverを構成し、アクセスの検証、フロントエンドHTTPのホストおよびポートの設定およびSOA_ClusterのWebLogic Serverクラスタ・アドレスの設定を行います。

第9.7項「WLS_SOA管理対象サーバー用のOracle HTTP Serverの構成」

デフォルト永続ストアの構成

トランザクション・リカバリのためのデフォルトの永続ストアを構成します。

第9.10項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」

Oracleアダプタの構成

ファイル用のOracle JCAアダプタおよびFTP用のOracle JCAアダプタの高可用性を有効化し、JMS用のOracle JCAアダプタの高可用性を有効化し、データベース用のOracle JCAアダプタをスケーリングします。

第9.12項「Oracleデータベース・アダプタのスケーリング」

Oracle SOA Suite構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第9.15項「インストールのバックアップ」

9.2 SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化

この手順は、WLS_SOA1およびWLS_SOA2のサーバー移行に必要です。WLS_SOA1およびWLS_SOA2サーバーを仮想ホスト名(SOAHOST1VHN1およびSOAHOST2VHN1)に関連付けます。これらの仮想ホスト名がDNSまたはシステム内の/etc/hosts解決で有効になっていること、およびそれらが適切なVIP(VIP2およびVIP3)にマップされていることを確認します。

仮想IPを有効にするには、root権限で次のようにifconfigコマンドを実行します。

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

次に例を示します。

/sbin/ifconfig ethX:Y 100.200.140.205 netmask 255.255.255.0

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

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

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

/bin/ping 100.200.140.205

注意:

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

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

Oracle Fusion Middleware構成ウィザードを使用して、Oracle Web Services ManagerおよびOracle SOA Suiteコンポーネントをサポートするために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成されたドメインを拡張します。

注意:

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインをバックアップしていない場合は、Oracle SOA Suiteコンポーネントを使用するためのドメイン拡張を実行する前に、現在のドメインをバックアップします。ドメインの拡張時になんらかのエラーが発生した場合は、このバックアップを使用してリカバリできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

構成ウィザードを使用してドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。
Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内のすべての管理対象サーバーを停止します。

3. SOAHOST1で、ディレクトリをOracle Fusion Middleware構成ウィザードの場所に変更します。これはOracle共通ホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行します)。

cd ORACLE_COMMON_HOME/common/bin

4. 構成ウィザードを起動します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name)を選択し、「次へ」をクリックします。

7. 「拡張ソースの選択」画面(図9-1)で、次の手順を実行します。

1. 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

2. 次の製品を選択します。
Oracle SOA Suite - 11.1.1.0 [soa]

Oracle WSM Policy Manager - 11.1.1.0 [oracle_common] (Oracle SOA Suiteとともに自動的に選択)

次の製品はすでに選択されてグレー表示されています。これらはドメインを作成した際に選択されました(第8.3項)。

WebLogic Serverの基本ドメイン - 10.3.6.0 [wlserver_10.3]

Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

Oracle JRF - 11.1.1.0 [oracle_common]

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

「図9-1 Oracle SOA Suiteの「拡張ソースの選択」画面」の説明

3. 「次へ」をクリックします。

8. このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。

9. 「JDBCコンポーネント・スキーマの構成」画面(図9-2)で、次の手順を実行します。

1. 「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」、OWSM MDSスキーマおよびSOA MDSスキーマの各行を選択します。

2. RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます(付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照)。ここでの説明に合わせて、「GridLinkへ変換」を選択します。
RAC構成を選択すると、選択されたすべてのスキーマがグレー表示されます。

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

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

3. 「次へ」をクリックします。

10. 「GridLink RACコンポーネント・スキーマの構成」画面(図9-3)で、次の手順を実行します。

1. 「SOAインフラストラクチャ」行のみを選択します。

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

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

2. 次の各フィールドに値を入力して、RCUでシードされたGridLink RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLink接続用のドライバ(Thin)、バージョン:10以降を選択します。

- サービス名: Oracle RACデータベースのサービス名は小文字で入力し、ドメイン名を続けます(例: wccedg.mycompany.com)。

- ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてDEVを使用しています。

- パスワード: データベース・スキーマの所有者のパスワードを入力します。

- 「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.mycompany.com:1521

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。次に例を示します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データソースの使用」を参照してください。

- ONSホスト: データベースによって報告されるRACデータベースのSCANアドレスとONSリモート・ポートも入力します。

[orcl@CUSTDBHOST2 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

3. 各データ・ソースを1つずつ選択し、適切な値のユーザー名とパスワードを入力します。

4. すべてのスキーマ(SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマ)で、すべての値が正しいことを確認し、「次へ」をクリックします。

注意:

Oracle WSMポリシーを格納するには、アイデンティティ管理用のデータベースを使用することをお薦めします(第15章「Oracle Identity Managementとの統合」を参照)。そのため、(第3章「エンタープライズ・デプロイメント用のネットワークの準備」で推奨されるように)RCUでシードされたOracle Identity Managementデータベース情報を使用してWSMメタデータを格納し、この画面ではOWSM MDSスキーマ用にOracle Identity Managementデータベース情報が使用されることが予想されます。このデータベース接続情報は、その他のOracle SOA Suiteスキーマで使用されるものとは異なります。

11. 「JDBCコンポーネント・スキーマのテスト」画面(図9-4)で、各スキーマを選択し、「接続のテスト」をクリックします。
結果は「接続結果ログ」に表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正してテストを再試行します。

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

「図9-4「JDBCコンポーネント・スキーマのテスト」画面」の説明

すべての接続に成功したら「次へ」をクリックします。

12. 「オプションの構成を選択」画面で、次のオプションを選択します。

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

- JMSファイル・ストア

「次へ」をクリックします。

13. 「JMS分散宛先タイプの選択」画面で次の操作を行います。

- UMSJMSystemResourceのドロップダウン・リストからUDDを選択します。

- SOAJMSModuleのドロップダウン・リストからUDDを選択します。

オーバーライドの警告が表示された場合、「OK」をクリックして、このメッセージを確認します。

14. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
soa_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_SOA1に変更し、WLS_SOA2という新しいサーバーを追加します。表9-2に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは変更せず、そのままにしておきます。

表9-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_SOA1

SOAHOST1VHN1

8001

なし

いいえ

WLS_SOA2

SOAHOST2VHN1

8001

なし

いいえ

「次へ」をクリックします。

15. 「クラスタの構成」画面で、表9-3に示すクラスタを追加します。

表9-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

SOA_Cluster

ユニキャスト

なし

なし

SOAHOST1VHN1:8001、SOAHOST2VHN1: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マシン」タブを開きます。マシンSOAHOST1およびSOAHOST2を追加して、最終的に次のような入力内容にします。

表9-4 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINVHN

localhost

この画面に表示されている他の割当ては変更せず、そのままにしておきます。マシン名は有効なホスト名またはリスニング・アドレスである必要がない点に留意してください。これらはノード・マネージャの場所を示す一意の識別子です。

「次へ」をクリックします。

18. 「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

- ADMINVHN

- AdminServer

- SOAHOST1:

- WLS_SOA1

- SOAHOST2:

- 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にのみターゲット設定する必要があります。

「次へ」をクリックします。

20. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

21. 「JMSファイル・ストアの構成」画面で、第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、JMSストアに指定した共有ディレクトリの場所を入力します。

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

「次へ」をクリックします。

22. 「構成のサマリ」画面で、「拡張」をクリックします。
このドメインを拡張して、Oracle SOA Suiteコンポーネントを追加します。

23. 「ドメインの拡張」画面で、「完了」をクリックします。

24. 加えた変更を有効にするために管理サーバーを再起動します。

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

コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、Oracle SOA Suiteエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。

ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるOracle SOA Suiteエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

注意:

デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、Oracle SOA Suiteシステムを起動できないことがあります。Oracle SOA Suiteシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。

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

tangosol.coherence.wkanシステム・プロパティを使用してノードを指定します(nは1から9の番号)。Well Knownアドレスとして指定できるのは9ノードまでですが、クラスタには9ノードを超えるノードを含めることができます。番号は、1から開始します。この番号付けは、連続的で間隙を含まないようにする必要があります。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、Oracle SOA Suiteサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHN1とSOAHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図9-5)。

ヒント:

Oracle SOA Suiteコンポジットのデプロイメント時の高可用性を保証するためには、十分なノードを指定して、いつでも最低1つのコンポジットが実行されているようにします。

注意:

SOAHOST1VHN1は、SOAHOST1でWLS_SOA1がリスニングする仮想IPにマップされる仮想ホスト名です。SOAHOST2VHN1は、SOAHOST2でWLS_SOA2がリスニングする仮想IPにマップされる仮想ホスト名です。

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

「図9-5 WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定」の説明

9.4.2 ホスト名の指定

Oracle Coherenceで使用されるホスト名を指定する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 「サーバーのサマリー」ページでサーバー名(WLS_SOA1またはWLS_SOA2)をクリックします。これらは、表の「名前」列にハイパーリンクで表示されています。

5. 選択したサーバーの「設定」ページで、「ロックして編集」をクリックします。

6. 「構成」タブを開いて、「サーバーの起動」タブを開きます。

7. WLS_SOA1とWLS_SOA2について、「引数」フィールドに次の値を入力します。
WLS_SOA1について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1

WLS_SOA2について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN1-Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1

注意:

前述のすべての引数を1行で入力します。つまり、管理コンソールのJava引数フィールドに改行を入れないでください。また、前述のテキストをコピーして管理コンソールの引数テキスト・フィールドに貼り付けないでください。これによって、余分な文字がJava引数に挿入されてしまう可能性があります。テキストには、前述のもの以外のテキストや文字を含めることはできません。

デプロイメントに使用されるCoherenceクラスタは、デフォルトでポート8088を使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。次に例を示します。

- WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
-Dtangosol.coherence.localport=8089

- WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
-Dtangosol.coherence.localport=8089

8. 「保存」→「変更のアクティブ化」をクリックします。

注意:

これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります(これらの変数はサーバーの出力ログに記録されます)。Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。

注意:

このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。Oracle SOA Suiteでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。

9.5 構成後タスクおよび検証タスクの実行

構成ウィザードでドメインを拡張し、Oracle Coherenceを構成したら、次の手順に従って、構成後タスクと検証を行います。

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

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

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

- 第9.5.3項「GridLinkデータ・ソースの検証」

- 第9.5.4項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更の伝播」

- 第9.5.5項「WLS_SOA1管理対象サーバーの起動と検証」

- 第9.5.6項「SOAHOST2へのドメイン構成の伝播」

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

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOA Suiteを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。そのため、WLS_SOAn管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverを管理するときにエラーが出ないようにします。エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第13.3項「ノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

ホスト名検証を無効化するには:

1. WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 「サーバーのサマリー」ページで、表の「名前」列にあるWLS_SOA1を選択します。

6. サーバーの設定ページで「SSL」タブを開きます。

7. 表示されたページの「詳細」セクションを開きます。

8. 「ホスト名の検証」を「なし」に設定します。

9. 「保存」をクリックします。

10. WLS_SOA2管理対象サーバーについて手順4から8を繰り返します。

11. 変更を保存してアクティブ化します。

12. この変更内容を有効にするには、管理サーバーおよびノード・マネージャを再起動する必要があります。

1. 管理サーバーを再起動する手順は、第8.4.4項「SOAHOST1での管理サーバーの起動」を参照してください。

2. SOAHOST1でノード・マネージャを再起動するには、第9.5.2項「SOAHOST1でのノード・マネージャの再起動」を参照してください。

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

startNodeManager.shスクリプトを使用してノード・マネージャを再起動します。

SOAHOST1でノード・マネージャを再起動する手順は次のとおりです。

1. ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。
シェルのフォアグラウンドで実行されている場合は、[Ctrl]キーを押しながら[C]を押します。

シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、killコマンドを使用して停止します。例:

ps -ef | grep NodeManager
orcl   9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh

kill -9 9139

2. ノード・マネージャを起動します。

./startNodeManager.sh

9.5.3 GridLinkデータ・ソースの検証

WLS_SOA1およびWLS_SOA2の構成が終了し、管理サーバーおよび管理対象サーバーを起動した後、作成したすべてのGridLinkデータ・ソースが適切に構成されており、各管理対象サーバーで各データ・ソースのOracle Notification Service (ONS)設定が適切であることを確認します。

Oracle SOA SuiteのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. 作成したGridLinkデータ・ソースの名前をクリックします。

4. 「監視」タブをクリックし、いずれかのサーバーの名前をクリックします。

5. 「テスト」タブ(図9-6)をクリックし、いずれかのサーバーを選択し、「データ・ソースのテスト」をクリックします。

図9-6 Oracle SOA SuiteのGridLinkデータ・ソースのテスト

「図9-6 Oracle SOA SuiteのGridLinkデータ・ソースのテスト」の説明

構成が適切であればテストは成功します。

6. GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスでテストを繰り返します。

Oracle SOA SuiteのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. 作成したGridLinkデータ・ソースの名前をクリックします。

4. 「監視」タブをクリックし、いずれかのサーバーの名前をクリックします。

5. 「ONS」タブをクリックし、「テスト」タブ(図9-7)をクリックします。

6. サーバーを選択し、「ONSのテスト」をクリックします。

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

「図9-7 Oracle SOA SuiteのONS構成のテスト」の説明

構成が適切であればテストは成功します。ONSテストが失敗する場合は、Oracle RACデータベース・ノード内でONSサービスが稼動していることを確認します。

[orcl@CUSTDBHOST1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node CUSTDBHOST1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node CUSTDBHOST2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node CUSTDBHOST2

[orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@CUSTDBHOST1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: CUSTDBHOST1
ONS daemon is running on node: CUSTDBHOST2

7. GridLinkデータ・ソースを使用するすべてのWebLogic ServerインスタンスでONSテストを繰り返します。

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

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。

2. 次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateSOA.jar -template_name=soa_domain_templateExtSOA

3. 次のようにunpackコマンドをSOAHOST1上で実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -overwrite_domain=true -template=edgdomaintemplateSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

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

WLS_SOA1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

1. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。

1. http://ADMINVHN:7001/consoleで管理コンソールにアクセスします。
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」を選択します。

4. 「サーバーのサマリー」ページで、「制御」タブを開きます。

5. 「WLS_SOA1」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.11項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

3. 次のURLにアクセスします。

- http://SOAHOST1VHN1:8001/soa-infraにアクセスしてWLS_SOA1のステータスを確認します。

- http://SOAHOST1VHN1:8001/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データ・ストアで使用できるポリシーとアサーション・テンプレートのリストが開きます。ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

- http://SOAHOST1VHN1:8001/integration/worklistappにアクセスしてワークリスト・アプリケーションのステータスを確認します。

9.5.6 SOAHOST2へのドメイン構成の伝播

SOAHOST1の構成が完了したら、unpackユーティリティを使用してSOAHOST2に構成を伝播し、伝播した構成を検証します。

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

- 第9.5.6.1項「unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」

- 第9.5.6.2項「WLS_SOA2管理対象サーバーの起動と検証」

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

unpackユーティリティを使用して、構成したドメインをSOAHOST2に伝播します。

ドメイン構成を伝播する手順は次のとおりです。

1. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします

cd ORACLE_BASE/product/fmw/oracle_common/common/bin

scp edgdomaintemplateSOA.jar oracle@SOAHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin

2. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

注意:

unpackはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackを実行する前に、ORACLE_BASE/admin/domain_name/mserverディレクトリが存在している必要があります。また、ORACLE_BASE/admin/domain_name/mserver/applicationsが空である必要があります。

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

WLS_SOA2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

1. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. 「WLS_SOA2」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.11項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

3. 次のURLにアクセスします。

- http://SOAHOST2VHN1:8001/soa-infraにアクセスしてWLS_SOA2のステータスを確認します。

- http://SOAHOST2VHN1:8001/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データ・ストアで使用できるポリシーとアサーション・テンプレートのリストが開きます。

注意:

ポリシーやアサーション・テンプレートがまったく表示されない場合は、構成が正しくありません。

- http://SOAHOST2VHN1:8001/integration/worklistapp/にアクセスしてワークリスト・アプリケーションのステータスを確認します。

9.6 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オブジェクト・キャッシュを構成した後で、構成を有効にするために、影響を受ける管理対象サーバーをすべて再起動する必要があります。

Oracle WSMのJavaオブジェクト・キャッシュを構成する手順は次のとおりです。

1. コマンドラインのOracle WebLogic Scripting Tool (WLST)を次のように使用して、管理サーバーに接続します。

MW_HOME/oracle_common/common/bin/wlst.sh
$ connect()

プロンプトが表示されたら、サーバーURL、Oracle WebLogicの管理ユーザー名およびパスワードを入力します。

2. WLSTを使用して管理サーバーに接続後、execfileコマンドを使用してスクリプトを開始します。たとえば、次のようにします。

wls:/domain_name/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")

特に、エンタープライズ・デプロイメント環境では、手順2で1つ目のクラスタ・オプションを使用する必要があります。EDG環境でconfigure-joc.pyを使用するための処理手順を示します(次のスクリプト入力パラメータを参照)。

Execfile("MW_HOME/oracle_common/bin/configure-joc.py").
Enter Hostnames (eg host1,host2) : SOAHOST1VHN1,SOAHOST2VHN1
.
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

また、『Oracle Fusion Middleware高可用性ガイド』の説明に従って、Oracle WebLogic管理コンソールで「HAパワー・ツール」タブを使用してJavaオブジェクト・キャッシュ(JOC)を構成することもできます。

スクリプト入力パラメータ

入力パラメータは、スクリプトによって求められます。このスクリプトを使用すると、次のような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に設定されています。

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

WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

1. WEBHOST1とWEBHOST2で、ORACLE_BASE/ admin/instance_name/config/OHS/component_name/mod_wl_ohs.confファイルに次の行を追加します。

# WSM-PM
<Location /wsm-pm>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# SOA soa-infra app
<Location /soa-infra>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Worklist
<Location /integration/>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow/>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

# Workflow
<Location /workflow>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

#SOA Composer
<Location /soa/composer>
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
SetHandler weblogic-handler
WLProxySSL OFF
WLProxySSLPassThrough OFF
</Location>

2. mod_wl_ohsファイルと同じディレクトリに格納されているhttpd.confファイルに、次の行が記述されていることを確認します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://wcc.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName admin.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName soainternal.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit</VirtualHost>

注意:

ここで挙げているwcc.mycompany.com:443、admin.mycompany.com:80、you@youraddressなどの値は、単なる例です。これらのかわりに、実際の環境に基づいた値を入力してください。

3. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohsX

ias-componentに対して、WEBHOST1ではohs1を使用し、WEBHOST2ではohs2を使用します。

WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このノードのリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。

次に例を示します。

- 例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時にその場で検出されます。

- 例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのメンバーをすべてリストに記述した場合は、Oracle HTTP Serverの起動時にそのうちの1つ以上を実行しておくことで、クラスタに確実に到達できます。

WebLogic Serverプラグインの構成の詳細は、『Oracle WebLogic ServerでWeb Serverプラグインを使用するOracle Fusion Middlewareのガイド』を参照してください。

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

Oracle SOA SuiteサーバーをホスティングするOracle WebLogic Serverクラスタに対して、フロントエンドHTTPのホストとポートを設定する必要があります。

1. WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」セクションに移動して、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「クラスタ」をクリックします。

5. 「サーバーのサマリー」ページで、「SOA_Cluster」を選択します。

6. 「HTTP」タブを開きます。

7. 次の値を設定します。

- フロントエンド・ホスト: soainternal.mycompany.com

- フロントエンドHTTPポート: 80

8. 「保存」をクリックします。

9. 管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

10. サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効にします。

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

管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.11項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

(WEBHOST1およびWEBHOST2の両方に対して)次のURLを使用し、Oracle HTTP ServerからWSM_Clusterを検証します。

- http://WEBHOSTn:7777/soa-infra

- http://WEBHOSTn:7777/integration/worklistapp

- http://WEBHOSTn:7777/sdpmessaging/userprefs-ui

- http://WEBHOSTn:7777/soa/composer

- http://WEBHOSTn:7777/wsm-pm

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

注意:

第8.5.3項「WebLogic ServerへのOracle HTTP Serverの登録」の説明に従ってOracle HTTP Serverを登録すると、そのOracle HTTP Serverは管理可能なターゲットとしてOracle Enterprise Managerコンソールに表示されます。これを確認するには、Oracle Enterprise Managerコンソールにログインします。ナビゲーション・ツリーのWeb層の項目にOracle HTTP Serverが登録されていることが示されます。

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

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)サーバー名をクリックします。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

4. 「構成」内の「サービス」タブを開きます(トップレベルの「サービス」タブではありません)。

5. 「ロックして編集」をクリックします。

6. 表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

7. 変更を保存してアクティブ化します。

8. WLS_SOA1およびWLS_SOA2管理対象サーバーを再起動します。

注意:

トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。

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

注意:

この手順はオプションで、起動されるBPELプロセスのアダプタのサポートを必要とするデプロイメントにのみ適用されます。

OracleファイルとFTPアダプタを使用すると、BPELプロセスやOracle MediatorでFTP(ファイル転送プロトコル)を使用して、ローカルとリモートのファイル・システムにあるファイルの読取りと書込みができます。これらのアダプタは、インバウンドとアウトバウンドの両方の操作に対し、Oracle BPEL Process ManagerとOracle Mediatorサービス・エンジンを使用してアクティブ/アクティブ・トポロジの高可用性をサポートします。Oracle File AdapterとOracle FTP Adapterがアウトバウンド操作に対する高可用性を備えるようにするには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作での高可用性に関する項で説明されているデータベースのmutexロック操作を使用します。データベースのmutexロック操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。

注意:

ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、Oracle RACバックエンドまたはOracle SOA Suite管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。

データベースのmutexロック操作の使用

データベース表をコーディネータとして使用し、アウトバウンドのOracleファイルやFTPアダプタ・サービスの高可用性を実現するには、Oracle WebLogic Serverコンソールで、eis/HAFileAdapterに対応するconnection-instanceのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更する必要があります。

注意:

データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトの値を大きくする必要があります。

データベースのmutexロック操作を使用する手順は次のとおりです。

1. Oracle WebLogic Serverコンソールにログインします。コンソールにアクセスするには、http://server_name:port_number/consoleに移動します。

2. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

3. 右ペインの「デプロイメントの概要」で「FileAdapter」をクリックします。

4. 「構成」タブを開きます。

5. 「アウトバウンド接続プール」タブを開き、「javax.resource.cci.ConnectionFactory」を開いて、構成済接続ファクトリを表示します。

6. 「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」画面が開きます。図9-8に示すように、接続ファクトリのプロパティが表示されます。

図9-8 Oracle WebLogic Serverコンソール - 「javax.resource.cci.ConnectionFactoryの設定」ページ

「図9-8 Oracle WebLogic Serverコンソール - 「javax.resource.cci.ConnectionFactoryの設定」ページ」の説明

7. 「ロックして編集」をクリックします。これにより、プロパティ値の列が編集可能になります(「プロパティ値」列で任意の行を選択してその値を変更できます)。
Oracleファイル・アダプタとFTPアダプタの接続ファクトリの新しいパラメータは次のとおりです。

- controlDir: 制御ファイルを格納するディレクトリ構造に設定します。1つのクラスタの中で複数のWebLogic Serverインスタンスを実行する場合は、この値を共有場所に設定する必要があります。この共有記憶域のディレクトリは次のような構造にします。

ORACLE_BASE/admin/domain_name/cluster_name/fadapter

- inboundDataSource: jdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。事前に作成されたスキーマは、ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。別のスキーマを選択した場合は、それに応じてinboundDataSourceプロパティを設定する必要があります。

- outboundDataSource: 値をjdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。事前に作成されたスキーマは、ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。その場合は、outboundDataSourceプロパティを設定する必要があります。

- outboundLockTypeForWrite: Oracle Databaseを使用している場合は、この値をoracleに設定します。デフォルトでは、Oracleファイル/FTPアダプタは、メモリー内mutexを使用してアウトバウンドの書込み操作をロックします。書込み操作を同期化するには、次の値のいずれかを選択する必要があります。

- memory: OracleファイルとFTPアダプタはメモリー内mutexを使用してファイル・システムへのアクセスを同期化します。

- oracle: アダプタは、Oracleデータベース・シーケンスを使用します。

- db: アダプタは、事前に作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用している場合にのみ使用します。

- user-defined: アダプタはユーザー定義のmutexを使用します。ユーザー定義mutexを構成するには、mutexインタフェース(oracle.tip.adapter.file.Mutex)を実装し、名前がoracle.tip.adapter.file.mutexで、アウトバウンド参照のmutexの完全修飾クラス名の値を指定した新規バインディング・プロパティを構成する必要があります。

注意:

FTPアダプタで使用可能なパラメータは、接続ファクトリの場合とは少し異なりますが、高可用性の観点からすると、重要なのは、共有記憶域の場所への制御ディレクトリの設定のみです。

8. これらのプロパティを更新した後、「保存」をクリックします。

9. 「デプロイメント・プランの保存」ページで、デプロイメント・プランの共有記憶域の場所を入力します。そのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/cluster_name/dp/Plan.xml

10. 「保存してアクティブ化」をクリックします。

11. 次の例のように、接続ファクトリが使用されるようにBPELプロセスまたはMediatorシナリオを構成します。

<adapter-config name="FlatStructureOut" adapter="File Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">  <connection-factory location="eis/HAFileAdapter" adapterRef=""/>  <endpoint-interaction portType="Write_ptt" operation="Write"><interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec">      <property../>      <property../>    </interaction-spec>  </endpoint-interaction></adapter-config>

注意:

location属性は、接続ファクトリのeis/HAFileAdapterに設定されています。

9.12 Oracleデータベース・アダプタのスケーリング

注意:

この手順はオプションで、起動されるBPELプロセスのアダプタのサポートを必要とするデプロイメントにのみ適用されます。

論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。以前は、複数のOracle BPEL Process ManagerまたはOracle Mediatorノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするための基本的なベスト・プラクティスは、ポーリング・ノードごとに一意のMarkReservedValueを指定してLogicalDeletePollingStrategyまたはDeletePollingStrategyを使用し、MaxTransactionSizeを設定することでした。ただし、Oracle Fusion Middleware 11gリリース1 (11.1.2.0)でロックのスキップが導入されたため、そのアプローチは破棄されました。以前にこのアプローチを使用していた場合は、単にMarkReservedValue属性を(db.jca内で)削除するか、または(「論理削除」ウィザードページで)クリアすることによって、自動的にロッキングのスキップを使用できるようになります。

予約された値に対してロックのスキップを使用することには、次のような利点があります。

- ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。

- (更新/予約の次にコミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。

- 一意のMarkReservedValueを指定する必要はありません。以前は、そのようにするためには、R${weblogic.Name-2}-${IP-2}-${instance}のように、複雑な変数を構成することが必要でした。

詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティとポーリング計画に関する項を参照してください。

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

ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第13章「ノード・マネージャの設定」を参照してください。その章の手順は、次に示す情報を使用して、2回実行する必要があります。

実行

ホスト名(HOST)

仮想IP(VIP)

サーバー名(WLS_SERVER)

Run 1:

SOAHOST1

SOAHOST1VHN1

WLS_SOA1

Run 2:

SOAHOST2

SOAHOST2VHN1

WLS_SOA2

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

サーバー移行は、SOAHOST1ノードとSOAHOST2ノードのどちらかで障害が発生した場合に、Oracle SOA Suiteコンポーネントを正しくフェイルオーバーするために必要です。詳細は、第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。Oracle SOA Suiteに関しては、その章で次の変数の値を使用します。

- サーバー名:

- WLS_SERVER1: WLS_SOA1

- WLS_SERVER2: WLS_SOA2

- ホスト名:

- HOST1: SOAHOST1

- HOST2: SOAHOST2

- クラスタ名:

- CLUSTER: SOA_Cluster

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

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。また、データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ガイドを参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

1. WEBHOST1でWeb層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドを使用して、Web層のOracleインスタンスをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

cd ORACLE_BASE/admin/instance_name/bin

opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。

3. ドメイン構成を保存するために、管理サーバーと管理対象サーバーのドメイン・ディレクトリをバックアップします。構成ファイルはすべて、ORACLE_BASE/admin/domain_nameディレクトリにあります。SOAHOST1で次のコマンドを実行して、バックアップを作成します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

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

この章では、Oracle Fusion Middleware構成ウィザードを使用して、Oracle WebCenter Contentを追加するためのドメインの拡張方法について説明します。この章には次の項目があります。

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

- 第10.2項「WCCHOST1でのWCCHOST1VHN1およびWCCHOST2でのWCCHOST2VHN1の有効化」

- 第10.3項「WebCenter Contentを追加するためのドメインの拡張」

- 第10.4項「WCCHOST1およびWCCHOST2でのノード・マネージャの起動」

- 第10.5項「WCC_WLS1のGridLinkデータ・ソースの検証」

- 第10.6項「pack/unpackユーティリティを使用した、WCCHOST1へのドメイン構成の伝播」

- 第10.7項「管理サーバーの再起動」

- 第10.8項「WLS_WCC1管理対象サーバーの起動とコンテンツ・サーバーの構成」

- 第10.9項「管理サーバーのcwalletファイルの更新」

- 第10.10項「WCCHOST1からWCCHOST2へのドメイン構成の伝播」

- 第10.11項「WLS_WCC2管理対象サーバーの起動とコンテンツ・サーバーの構成」

- 第10.12項「WLS_WCC2のGridLinkデータ・ソースの検証」

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

- 第10.14項「WLS_WCC管理対象サーバー用のOracle HTTP Serverの構成」

- 第10.15項「Oracle HTTP Serverを使用したアクセスの検証」

- 第10.16項「WLS_WCCおよびWLS_IMG管理対象サーバーのノード・マネージャの構成」

- 第10.17項「インストールのバックアップ」

注意:

セットアップ・プロセスを開始する前に、リリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。これらは、Oracle Fusion Middlewareドキュメント・ライブラリ(http://docs.oracle.com/cd/E23943_01/relnotes.htm)で入手できます。

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

Oracle WebCenter Contentシステムは、第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」で作成された、共有記憶域でのWL_HOMEおよびORACLE_HOMEの場所を使用してインストールされます。WCCHOST1およびWCCHOST2はMW_HOMEをマウントし、既存のOracle WebLogic Server、Oracle SOA SuiteおよびOracle WebCenter Contentのバイナリ・インストールを再利用します。packユーティリティおよびunpackユーティリティを使用して、この2つの新しいノードでWLS_WCC1サーバーおよびWLS_WCC2サーバーのドメイン構成をブートストラップします。この結果、各ノードにソフトウェアをインストールする必要がなくなります。

Oracle WebCenter Contentシステムが正常に機能するには、SOAHOST1およびSOAHOST2にOracle Fusion Middlewareをインストールするときに必要としたものと同じシステム要件とシステム構成をWCCHOST1およびWCCHOST2で保持しておく必要があります。このシステム構成がないと、バイナリの実行で予期しない動作が発生することがあります。

注意:

第9項「Oracle SOA Suiteコンポーネントを追加するためのドメインの拡張」に記述されているように、ドメインにはOracle SOA Suiteコンポーネントが追加されます。

Oracle WebCenter Contentを追加するためのドメインを拡張します。表10-1に、WebCenter Contentの構成手順と、WebCenter Content管理対象サーバーを含むドメインの拡張に必要なタスクを示します。

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

手順

説明

詳細

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

ホスト名のそれぞれに対してVIPマッピングを有効にします。

第10.2項「WCCHOST1でのWCCHOST1VHN1およびWCCHOST2でのWCCHOST2VHN1の有効化」

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogic Serverドメインを拡張します。

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

WebCenter Content管理対象サーバーのノード・マネージャの起動

setNMProps.shスクリプトを実行し、WCCHOST1およびWCCHOST2のノード・マネージャを起動します。

第10.4項「WCCHOST1およびWCCHOST2でのノード・マネージャの起動」

GridLinkデータ・ソースおよびOracle Notification Service (ONS)の構成の確認

GridLinkデータ・ソースおよびONSの構成が適切であることを確認する手順に従います。

第10.5項「WCC_WLS1のGridLinkデータ・ソースの検証」

1台目のWebCenter Content管理対象サーバーへのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第10.6項「pack/unpackユーティリティを使用した、WCCHOST1へのドメイン構成の伝播」

ドメインの管理サーバーの再起動

管理サーバーを停止し、再起動します。

第10.7項「管理サーバーの再起動」

1台目のWebCenter Content管理対象サーバーの起動およびコンテンツ・サーバーのインスタンスの構成

WLS_WCC1管理対象サーバーの起動およびコンテンツ・サーバーの初期構成の完了

第10.8項「WLS_WCC1管理対象サーバーの起動とコンテンツ・サーバーの構成」

cwallet.ssoファイルの変更を元の管理サーバーに伝播

更新されたcwallet.ssoファイルを管理サーバー・ディレクトリにコピーします。

第10.9項「管理サーバーのcwalletファイルの更新」

2台目のWebCenter Content管理対象サーバーへのドメイン構成の伝播

WebCenter Content管理対象サーバーの1台目から2台目へ、起動スクリプトおよびクラスパス構成を伝播します。

第10.10項「WCCHOST1からWCCHOST2へのドメイン構成の伝播」

2台目のWebCenter Content管理対象サーバーの起動およびコンテンツ・サーバーのインスタンスの構成

WLS_WCC2管理対象サーバーを構成し、コンテンツ・サーバーの初期構成を完了します。

第10.11項「WLS_WCC2管理対象サーバーの起動とコンテンツ・サーバーの構成」

Oracle RACフェイルオーバー後のサービス再試行の有効化

コンテンツ・サーバーのconfig.cfgファイルでServiceAllowRetry構成パラメータをtrueに設定します。

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

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

管理対象サーバーとともにOracle HTTP Serverを構成し、フロントエンドHTTPのホストおよびポートの設定およびWCC_ClusterのWebLogic Serverクラスタ・アドレスの設定を行います。

第10.14項「WLS_WCC管理対象サーバー用のOracle HTTP Serverの構成」

Oracle HTTP Serverを介したWebCenter Contentへのアクセスの検証

URLを検証し、Oracle HTTP ServerからWCC_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

第10.15項「Oracle HTTP Serverを使用したアクセスの検証」

ドメインの管理対象サーバーとノード・マネージャ間通信に対するホスト名検証の構成

管理サーバーや他のサーバーとの通信には、それぞれのアドレス用の証明書を使用します。

第10.16項「WLS_WCCおよびWLS_IMG管理対象サーバーのノード・マネージャの構成」

WebCenter Contentの構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第10.17項「インストールのバックアップ」

10.2 WCCHOST1でのWCCHOST1VHN1およびWCCHOST2でのWCCHOST2VHN1の有効化

この手順は、WLS_WCC1およびWLS_WCC2のサーバー移行に必要です。WLS_WCC1およびWLS_WCC2サーバーを仮想ホスト名(WCCHOST1VHN1およびWCCHOST2VHN1)に関連付けます。これらの仮想ホスト名がDNSまたはシステム内の/etc/hosts解決で有効になっていること、およびそれらが適切なVIPにマップされていることを確認します。

詳細は、第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」を参照してください。

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを拡張して、Oracle WebCenter Contentを追加できます。この項の手順は、Oracle SOA Suiteのデプロイメントと同じデータベース・サービス(wccedg.mycompany.com)をOracle WebCenter Contentのデプロイメントでも使用することを前提としています。

注意:

これらの手順を実行する前に、Oracle Fusion Middleware管理者ガイドの説明に従ってドメインをバックアップしてください。

Oracle WebCenter Contentを追加するためにドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。
Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. SOAHOST1で、ディレクトリをOracle Fusion Middleware構成ウィザードの場所に変更します。これはOracle共通ホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行します)。

cd ORACLE_COMMON_HOME/common/bin

3. Fusion Middleware構成ウィザードを起動します。

./config.sh

4. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

5. 「WebLogicドメイン・ディレクトリ」画面で、WebLogic Serverドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name)を選択し、「次へ」をクリックします。

6. 「拡張ソースの選択」画面(図10-1)で、次の選択を行います。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。
Oracle Universal Content Management - Content Server - 11.1.1.0 [wcc]

これがOracle WebCenter Contentの選択肢です。

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

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

次の製品はすでに選択されてグレー表示されています。これらは、ドメインを作成した際(第8.3項)またはOracle SOA Suiteコンポーネント用に拡張した際(第9.3項)に選択されました。

WebLogic Serverの基本ドメイン - 10.3.6.0 [wlserver_10.3]

Oracle SOA Suite for developers - 11.1.1.0 [soa]

Oracle SOA Suite - 11.1.1.0 [soa]

Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

Oracle WSM Policy Manager - 11.1.1.0 [oracle_common]

Oracle JRF - 11.1.1.0 [oracle_common]

「次へ」をクリックします。

7. 「JDBCコンポーネント・スキーマの構成」画面(図10-2)で、次の手順を実行します。

1. (WebCenter Contentの)UCMスキーマを選択します。他の既存スキーマはいずれも選択しないでください。

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

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

2. RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます(付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照)。ここでの説明に合わせて、「GridLinkへ変換」を選択します。
RAC構成を選択すると、選択されたすべてのスキーマがグレー表示されます。

3. 「次へ」をクリックします。

8. 「GridLink RACコンポーネント・スキーマの構成」画面(図10-3)で、次の手順を実行します。

1. (WebCenter Contentの)UCMスキーマを選択します。その他のデータ・ソースはそのままにします。

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

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

2. 次の各フィールドに値を入力して、RCUでシードされたGridLink RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLink接続用のドライバ(Thin)、バージョン:10以降を選択します。

- サービス名: Oracle RACデータベースのサービス名は小文字で入力し、ドメイン名を続けます(例: wccedg.mycompany.com)。

- ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてDEVを使用しています。

- パスワード: データベース・スキーマの所有者のパスワードを入力します。

- 「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.mycompany.com:1521

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。次に例を示します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データソースの使用」を参照してください。

- ONSホスト: データベースによって報告されるRACデータベースのSCANアドレスとONSリモート・ポートも入力します。

[orcl@CUSTDBHOST2~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

3. 「次へ」をクリックします。

注意:

「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」、OWSM MDSスキーマおよびSOA MDSスキーマの情報はそのままにしておきます。

9. 「JDBCコンポーネント・スキーマのテスト」画面(図10-4)で、UCMスキーマ行を選択し、「接続のテスト」をクリックします。
結果は「接続結果ログ」に表示されます。スキーマを含むデータベースへの接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正してテストを再試行します。

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

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

接続に成功したら、「次へ」をクリックします。

10. 「オプションの構成を選択」画面で、次のオプションを選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

11. 「管理対象サーバーの構成」画面(図10-5)で、必要な管理対象サーバーを追加します。

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

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

サーバーが自動的に作成されます。このサーバーの名前をWLS_WCC1に変更し、WLS_WCC2という新しいサーバーを追加します。表10-2に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは変更せず、そのままにしておきます。

表10-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_WCC1

WCCHOST1

16200

n/a

いいえ

WLS_WCC2

WCCHOST2

16200

n/a

いいえ

「次へ」をクリックします。

12. 「クラスタの構成」画面(図10-6)で、「追加」をクリックし、表10-3に示すクラスタを追加します。画面に表示されている他のクラスタは変更せず、そのままにしておきます。

表10-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

WCC_Cluster

ユニキャスト

n/a

n/a

空のままにします。

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

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

「次へ」をクリックします。

13. 「サーバーのクラスタへの割当」画面で、次の項目を追加します。この画面に表示されている他の割当ては、このまま変更しません。

- WCC_Cluster:

- WLS_WCC1

- WLS_WCC2

「次へ」をクリックします。

14. 「マシンの構成」画面(図10-7)で「Unixマシン」タブを開き、次の2つのマシンを新規追加します。

表10-4 マシン

名前

ノード・マネージャのリスニング・アドレス

WCCHOST1

WCCHOST1

WCCHOST2

WCCHOST2

他のフィールドはすべてデフォルト値のままにします。

図10-7 「マシンの構成」画面

「図10-7 「マシンの構成」画面」の説明

「次へ」をクリックします。

15. 「サーバーのマシンへの割当」画面(図10-8)で、次のようにサーバーをマシンに割り当てます。

- WLS_WCC1をWCCHOST1に割り当てます。

- WLS_WCC2をWCCHOST2に割り当てます。

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

「図10-8 WebCenter Contentの「サーバーのマシンへの割当」画面」の説明

「次へ」をクリックします。

16. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、DMSアプリケーションがSOA_Cluster、WCC_Clusterおよび管理サーバーにターゲット設定されていることを確認します。「次へ」をクリックします。

17. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

18. 「構成のサマリ」画面で、「拡張」をクリックします。

19. ドメインのポートの競合に関する警告ダイアログが表示された場合、「OK」をクリックします。

20. 「ドメインの作成中」画面で、「完了」をクリックします。

21. 加えた変更を有効にするために管理サーバーを再起動します。第10.7項「管理サーバーの再起動」を参照してください。

10.4 WCCHOST1およびWCCHOST2でのノード・マネージャの起動

ノード・マネージャがまだ起動されていない場合に、WCHOST1およびWCHOST2でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、WCCHOST1とWCCHOST2の両方で、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

cd ORACLE_COMMON_HOME/common/bin

./setNMProps.sh

注意:

クラスのロードの失敗やその他の問題を回避するには、StartScriptEnabledプロパティを使用します。第16.11.3項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」も参照してください。

注意:

第3章「エンタープライズ・デプロイメント用のネットワークの準備」の構成で示しているように、WebCenter Contentのサーバーがローカル記憶域または共有記憶域でOracle SOA SuiteとMiddlewareホームを共有している場合には、setNMProps.shを再実行する必要はありません。この場合、ノード・マネージャはすでに起動スクリプトを使用するように構成されています。

2. WCHOST1およびWCHOST2の両方で次のコマンドを実行し、ノード・マネージャを起動します。

cd WL_HOME/server/bin

./startNodeManager.sh

10.5 WCC_WLS1のGridLinkデータ・ソースの検証

ドメイン構成をWCCHOST2に伝播する前に、作成したすべてのGridLinkデータ・ソースが適切に構成されており、各管理対象サーバーで各データ・ソースのOracle Notification Service (ONS)設定が適切であることを確認します。

WebCenter ContentのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. 作成したGridLinkデータ・ソースの名前をクリックします。

4. 「監視」タブをクリックし、いずれかのサーバーの名前をクリックします。

5. 「テスト」タブ(図10-9)をクリックし、いずれかのサーバーを選択し、「データ・ソースのテスト」をクリックします。

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

「図10-9 WebCenter ContentのGridLinkデータ・ソースのテスト」の説明

構成が適切であればテストは成功します。

6. GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスでテストを繰り返します。

WebCenter ContentのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. GridLinkデータ・ソースの名前をクリックします。

4. 「ONS」タブをクリックし、「テスト」タブ(図10-10)をクリックします。

5. サーバーを選択し、「ONSのテスト」をクリックします。

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

「図10-10 WebCenter ContentのONS構成のテスト」の説明

構成が適切であればテストは成功します。ONSテストが失敗する場合は、Oracle RACデータベース・ノード内でONSサービスが稼動していることを確認します。

[orcl@CUSTDBHOST1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node CUSTDBHOST1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node CUSTDBHOST2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node CUSTDBHOST2

[orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@CUSTDBHOST1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: CUSTDBHOST1
ONS daemon is running on node: CUSTDBHOST2

6. GridLinkデータ・ソースを使用するすべてのWebLogic ServerインスタンスでONSテストを繰り返します。

10.6 pack/unpackユーティリティを使用した、WCCHOST1へのドメイン構成の伝播

ドメイン構成をSOAHOST1からWCCHOST1へ伝搬する手順は次のとおりです。

1. 次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateWCC.jar -template_name=edgdomain_templateWCC

2. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・パックをWCCHOST1にコピーします。

注意:

WCCHOST1がORACLE_HOMEをSOAHOST1と共有していると仮定した場合、テンプレートは、WCCHOST1の同一のディレクトリに存在します。そうでなければ、これもWCCHOST1にコピーします。

scp edgdomaintemplateWCC.jar oracle@WCCHOST1ORACLE_BASE/product/fmw/oracle_common/common/bin

3. unpackコマンドをWCCHOST1で実行し、伝播されたテンプレートを解凍します。

注意:

unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateWCC.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackを実行する前に、ORACLE_BASE/admin/domain_name/mserverディレクトリが存在している必要があります。また、ORACLE_BASE/admin/domain_name/mserver/applicationsディレクトリが空である必要があります。

10.7 管理サーバーの再起動

管理サーバーを再起動して、ここまでの変更を有効にします。管理サーバーを再起動するには、最初に管理コンソールを使用してサーバーを停止し、第8.4.4項「SOAHOST1での管理サーバーの起動」の説明に従って再起動します。

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

WLS_WCC1管理対象サーバーの起動後、Webインタフェースを介してOracle WebCenter Content Serverを構成できます。

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

WLS_WCC1管理対象サーバーを起動する手順は次のとおりです。

1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_WCC1管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブを開きます。

4. 「WLS_WSM1」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.11項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

コンテンツ・サーバーの構成

コンテンツ・サーバーを構成する手順は次のとおりです。

1. http://WCCHOST1:16200/csでWebLogic Serverの管理ユーザー名とパスワードを使用してWLS_WCC1にログインし、構成ページを表示します。

注意:

WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Contentエンタープライズ・デプロイメントの共有ディスクの場所は、ORACLE_BASE/admin/domain_name/wcc_cluster_nameです。

2. サーバー構成ページで次の値を変更します(すべてのオプションを参照するには、「コンテンツ・サーバーの新規インスタンス」チェック・ボックスを選択してください)。

- コンテンツ・サーバーのインスタンス・フォルダ: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/csに設定します。

- ネイティブ・ファイル・リポジトリの場所: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/vaultに設定します。

- Webレイアウト・フォルダ: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/weblayoutに設定します。

- ユーザー・プロファイル・フォルダ: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/data/users/profilesに設定します。

- サーバーのソケット・ポート: これを4444に設定します。

- ソケット接続アドレス・セキュリティ・フィルタを着信中: これを次に示すようにローカル・ホストおよびサーバーのIPのパイプ区切り一覧に設定します。

127.0.0.1|WCCHOST1|WCCHOST2|WEBHOST1|WEBHOST2

注意:

これは後でホスト名ベースのリストに変更されます(第11.15項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」を参照)。この時点では、セキュリティ・フィルタがホスト名に変更されるようにするために、実行する操作用の接続が事前に許可されている必要があります。

- WebサーバーのHTTP/HTTPSアドレス: これをwcc.mycompany.com:443に設定します。

- WebアドレスはHTTPSです: このチェック・ボックスを選択します。

- コンテンツ・サーバーのインスタンス・ラベル: これをWCC_Cluster1に設定します。

- サーバー・インスタンスの説明: これをCluster wcc_cluster1に設定します。

- 自動採番接頭辞: これをwcc_cluster1-に設定します。

3. 完了したら「送信」をクリックし、WebLogic Server管理コンソールを使用して管理対象サーバーを再起動します。

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

Oracle WebCenter Content Serverは、起動時にORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfigにあるcwallet.ssoファイルを更新します。この変更は、元の管理サーバーに伝播する必要があります。これを行うには、WCCHOST1で次のコマンドを(すべて1行で)使用して、このファイルをSOAHOST1のORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfigにコピーします。

scp ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig/cwallet.sso oracle@SOAHOST1:ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/

注意:

WLS_WCCnサーバーでORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfigディレクトリにあるcwallet.ssoファイルを変更する操作を行った場合は、SOAHOST1の管理サーバー・ドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig)にそのファイルをすぐにコピーする必要があります。

10.10 WCCHOST1からWCCHOST2へのドメイン構成の伝播

ドメイン構成をWCCHOST1からWCCHOST2へ伝搬する手順は次のとおりです。

1. 管理コンソールを介してWLS_WCC1管理対象サーバーを停止します。

2. 次の一連のコマンドを使用し、WCCHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateWCC.jar -template_name=edgdomain_templateWCC

3. 次のコマンドをWCCHOST1で実行し、前の手順で作成したテンプレート・パックをWCCHOST2にコピーします。

注意:

WCCHOST2がORACLE_HOMEをSOAHOST2と共有していると仮定した場合、テンプレートは、WCCHOST2の同一のディレクトリに存在します。そうでなければ、これもWCCHOST2にコピーします。

scp edgdomaintemplateWCC.jar oracle@WCCHOST1ORACLE_BASE/product/fmw/oracle_common/common/bin

4. unpackコマンドをWCCHOST2で実行し、伝播されたテンプレートを解凍します。

注意:

unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateWCC.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackを実行する前に、ORACLE_BASE/admin/domain_name/mserverディレクトリが存在している必要があります。また、ORACLE_BASE/admin/domain_name/mserver/applicationsディレクトリが空である必要があります。

5. 第8.4.4項「SOAHOST1での管理サーバーの起動」の説明に従って管理サーバーを再起動して、変更を反映します。

6. WLS_WCC1管理対象サーバーを再起動します。

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

WLS_WCC2管理対象サーバーの起動後、Webインタフェースを介してOracle WebCenter Content Serverを構成できます。

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

WLS_WCC2管理対象サーバーを起動する手順は次のとおりです。

1. 次の手順に従い、WebLogic Server管理コンソールを使用してWLS_WCC2管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. 「WLS_WCC2」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因は、第16.11項「Oracle WebCenter Contentエンタープライズ・デプロイメントのトポロジのトラブルシューティング」を参照してください。

コンテンツ・サーバーの構成

コンテンツ・サーバーを構成する手順は次のとおりです。

1. http://WCCHOST2:16200/csでOracle WebLogicの管理ユーザー名とパスワードを使用してWLS_WCC2にログインし、構成ページを表示します。

注意:

Oracle WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Contentエンタープライズ・デプロイメントの共有ディスクの場所は、ORACLE_BASE/admin/domain_name/wcc_cluster_nameです。

2. 「サーバーの構成」ページで次の値を変更します。

- コンテンツ・サーバーのインスタンス・フォルダ: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/csに設定します。

- ネイティブ・ファイル・リポジトリの場所: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/vaultに設定します。

- Webレイアウト・フォルダ: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/weblayoutに設定します。

- ユーザー・プロファイル・フォルダ: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/data/users/profilesに設定します。

「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。

3. 完了したら「送信」をクリックし、WebLogic Server管理コンソールを使用して管理対象サーバーを再起動します。

10.12 WLS_WCC2のGridLinkデータ・ソースの検証

WLS_WCC1およびWLS_WCC2の構成が終了し、管理サーバーおよび管理対象サーバーを起動した後、作成したすべてのGridLinkデータ・ソースが適切に構成されており、各管理対象サーバーで各データ・ソースのOracle Notification Service (ONS)設定が適切であることを確認します。

注意:

作成したGridLinkデータ・ソースが適切に構成されていることを確認するには、第10.5項「WCC_WLS1のGridLinkデータ・ソースの検証」に示されている手順に従います。ただし、2台目のサーバーはWLS_WCC2になります。

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

Oracle RACのフェイルオーバー時にログインの再試行を可能にするため、コンテンツ・サーバーのconfig.cfgファイル内の次のパラメータを設定する必要があります。

ServiceAllowRetry=true

この値が設定されていない場合、フェイルオーバーが開始されたときに、ユーザーは処理中の任意の操作を手動で再試行する必要があります。

Oracle WebCenter Content用の構成パラメータを追加する手順は次のとおりです。

1. Oracle WebCenter Content Server(http://WCHOST1:16200/cs)にアクセスし、Oracle WebLogic Serverの管理ユーザー名とパスワードを使用してログインします。

2. 「管理」ページを開き、「管理サーバー」を選択します。

3. 「コンテンツ管理サーバー」ページで、左側の「一般構成」をクリックします。

4. 「一般構成」ページで、「追加の構成変数」ボックスに、次のパラメータを追加します。

ServiceAllowRetry=true

5. 「保存」をクリックし、すべてのWebCenter Content管理対象サーバーを再起動します。

注意:

新しいパラメータはconfig.cfgファイルに含まれます。このファイルは次の場所にあります。

ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfg

(このファイルをテキスト・エディタで直接編集することもできます。必ず、すべてのWebCenter Content管理対象サーバーを再起動してください。)

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

WLS_WCC1およびWLS_WCC2管理対象サーバーを含むWCC_ClusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

1. WEBHOST1とWEBHOST2で、ORACLE_BASE/admin/instance_name/config/OHS/component_name/mod_wl_ohs.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>

2. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohsX

ias-componentに対して、WEBHOST1ではohs1を使用し、WEBHOST2ではohs2を使用します。

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

URLを検証して、Oracle HTTP ServerからWCC_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。URLを検証する手順は次のとおりです。

1. WLS_WCC2が稼動している状態で、WebLogic Server管理コンソールを使用してWLS_WCC1を停止します。

2. http://WEBHOST1:7777/csにアクセスし、正しく動作していることを確認します。

3. WebLogic Server管理コンソールからWLS_WCC1を起動します。

4. WebLogic Server管理コンソールでWLS_WCC2を停止します。

5. http://WEBHOST1:7777/csにアクセスし、正しく動作していることを確認します。

10.16 WLS_WCCおよびWLS_IMG管理対象サーバーのノード・マネージャの構成

ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第13章「ノード・マネージャの設定」を参照してください。その章の手順は、次に示す情報を使用して、2回実行する必要があります。

実行

ホスト名(HOST)

仮想IP(VIP)

サーバー名(WLS_SERVER)

Run 1:

WCCHOST1

WCCHOST1VHN1*

WLS_WCC1

Run 2:

WCCHOST2

WCCHOST2VHN1*

WLS_WCC2

* オプション: Oracle WebCenter Content: Imaging管理対象サーバー(WLS_IMG)でのみ必要です。

次のことに注意してください。

- WLS_IMG管理対象サーバーがこの時点でまだ構成されておらず(第11章「Imagingを追加するためのドメインの拡張」を参照)、WLS_IMG管理対象サーバーがWebCenter Contentのみを追加するOracle WebCenter Contentの構成には必須でなくても、両方の種類のサーバーを追加するための構成を1ステップのプロセスで実現するために、Oracle WebCenter Content: Imagingで使用される仮想ホスト名がここ(\)で構成されます。

- 第13章「ノード・マネージャの設定」(WLS_IMGサーバーに関する第13.3.5項「カスタム・キーストアを使用するための管理対象サーバーの構成」は除く)に記述されている手順をすべて実行します。この手順は、ドメインにWLS_IMGサーバーが追加された後に実行できます。

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

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。また、データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ガイドを参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

1. WEBHOST1でWeb層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドを使用して、Web層のOracleインスタンスをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

cd ORACLE_BASE/admin/instance_name/bin
opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。

3. ドメイン構成を保存するために、管理サーバーと管理対象サーバーのドメイン・ディレクトリをバックアップします。構成ファイルはすべて、ORACLE_BASE/admin/domain_nameディレクトリにあります。SOAHOST1で次のコマンドを実行して、バックアップを作成します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

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

この章では、Oracle Fusion Middleware構成ウィザードを使用して、Oracle WebCenter Content: Imagingを含むドメインの拡張方法について説明します。この章には次の項目があります。

- 第11.1項「Imagingを使用するためのドメインの拡張の概要」

- 第11.2項「WCCHOST1およびWCCHOST2のVIP4およびVIP5の有効化」

- 第11.3項「Imagingを追加するためのドメインの拡張」

- 第11.4項「WLS_IMG管理対象サーバーに対するホスト名検証の無効化」

- 第11.5項「WCCHOST1およびWCCHOST2でのノード・マネージャの起動」

- 第11.6項「WCC_IMG1のGridLinkデータ・ソースの検証」

- 第11.7項「unpackユーティリティを使用したWCCHOST1およびWCCHOST2へのドメイン構成の伝播」

- 第11.8項「Oracle WebCenter Content: Imaging用のJMS永続ストアの構成」

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

- 第11.10項「管理サーバーの再起動」

- 第11.11項「Imaging管理対象サーバーの起動」

- 第11.12項「WLS_IMG2のGridLinkデータ・ソースの検証」

- 第11.13項「Oracle WebCenter Content: Imaging用のシステムMBeanの構成」

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

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

- 第11.16項「Oracle WebCenter Contentへの接続の作成」

- 第11.17項「BPEL CSF資格証明の構成」

- 第11.18項「ワークフロー接続の構成」

- 第11.19項「WLS_IMG管理対象サーバー用のOracle HTTP Serverの構成」

- 第11.20項「フロントエンドHTTPホストおよびポートの設定」

- 第11.21項「Oracle HTTP Serverを使用したアクセスの検証」

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

- 第11.23項「WLS_IMG管理対象サーバー用のサーバー移行の構成」

- 第11.24項「インストールのバックアップ」

注意:

セットアップ・プロセスを開始する前に、リリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。これらは、Oracle Fusion Middlewareドキュメント・ライブラリ(http://docs.oracle.com/cd/E23943_01/relnotes.htm)で入手できます。

11.1 Imagingを使用するためのドメインの拡張の概要

Oracle WebCenter Content: Imagingシステムは、第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」で作成された、共有記憶域でのWL_HOMEおよびORACLE_HOMEの場所を使用してインストールされます。WCCHOST1およびWCCHOST2はMW_HOMEをマウントし、既存のOracle WebLogic Server、Oracle SOA SuiteおよびOracle WebCenter Contentのバイナリ・インストールを再利用します。packユーティリティおよびunpackユーティリティを使用して、この2つの新しいノードでWLS_IMG1サーバーおよびWLS_IMG2サーバーのドメイン構成をブートストラップします。この結果、各ノードにソフトウェアをインストールする必要がなくなります。Imagingシステムが正常に機能するには、SOAHOST1およびSOAHOST2にOracle Fusion Middlewareをインストールするときに必要としたシステム構成と同一の構成をWCCHOST1およびWCCHOST2で保持しておく必要があります。このシステム構成がないと、バイナリの実行で予期しない動作が発生することがあります。

Imagingを追加するためにドメインを拡張します。表11-1に、Imagingの構成手順と、Imaging管理対象サーバーを含むドメインの拡張に必要なタスクを示します。

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

手順

説明

詳細

Imagingを使用するためのドメインの拡張の準備

ホスト名のそれぞれに対してVIPマッピングを有効にします。

第11.2項「WCCHOST1およびWCCHOST2のVIP4およびVIP5の有効化」

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したImagingドメインを拡張します。

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

Imaging管理対象サーバーへのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第11.7項「unpackユーティリティを使用したWCCHOST1およびWCCHOST2へのドメイン構成の伝播」

WebCenter Content管理対象サーバーのノード・マネージャの起動

setNMProps.shスクリプトを実行し、WCCHOST1およびWCCHOST2のノード・マネージャを起動します。

第11.5項「WCCHOST1およびWCCHOST2でのノード・マネージャの起動」

ドメインの管理サーバーの再起動

管理サーバーを停止し、再起動します。

第11.10項「管理サーバーの再起動」

JMS永続ストアの構成

両方のImaging管理対象サーバーへ参照できるディレクトリとして、JMS永続ストアの場所を構成します。

第11.8項「Oracle WebCenter Content: Imaging用のJMS永続ストアの構成」

デフォルト永続ストアの構成

トランザクション・リカバリのためのデフォルトの永続ストアを構成します。

第11.9項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」

Imagingのホスト名検証の無効化

トポロジの設定と検証中にホスト名の検証を無効にします。

第11.4項「WLS_IMG管理対象サーバーに対するホスト名検証の無効化」

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

WLS_IMG1およびWLS_IMG2管理対象サーバーを起動します。

第11.11項「Imaging管理対象サーバーの起動」

GridLinkデータ・ソースおよびOracle Notification Service (ONS)の構成の確認

GridLinkデータ・ソースおよびONSの構成が適切であることを確認する手順に従います。

第11.6項「WCC_IMG1のGridLinkデータ・ソースの検証」

ImagingのシステムMBeanの構成

システムMBeanブラウザで、InputDirectories、SampleDirectoryおよびGDFontPathのMBeanを構成します。

第11.13項「Oracle WebCenter Content: Imaging用のシステムMBeanの構成」

WebCenter ContentのImaging機能セットの有効化

コンテンツ・サーバーのIpmRepositoryコンポーネントを有効にします。

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

Imaging管理対象サーバーに対するリスニング・アドレスの追加

WLS_IMG1およびWLS_IMG2管理対象サーバー(WCCHOST1VHN1およびWCCHOST2VHN1)のホスト名をSocketHostNameSecurityFilterパラメータ・リストに追加します。

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

ImagingとOracle WebCenter Content間の接続の作成

Oracle WebCenter Content Serverへの接続を作成します。

第11.16項「Oracle WebCenter Contentへの接続の作成」

BPEL CSF資格証明の構成

Oracle SOA Suiteとの通信に必要な資格証明を構成します。

第11.17項「BPEL CSF資格証明の構成」

Imaging用のワークフロー接続の構成

ワークフロー接続を作成し、テストします。

第11.18項「ワークフロー接続の構成」

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

管理対象サーバーとともにOracle HTTP Serverを構成し、IMG_ClusterのWLSクラスタ・アドレスを設定します。

第11.19項「WLS_IMG管理対象サーバー用のOracle HTTP Serverの構成」

Imagingに対するフロントエンドHTTPのホストおよびポートの設定

IMG_Clusterに対するフロントエンドHTTPのホストおよびポートを構成します。

第11.20項「フロントエンドHTTPホストおよびポートの設定」

Oracle HTTP Serverを介したWebCenter Contentへのアクセスの検証

URLを検証し、Oracle HTTP ServerからIMG_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

第11.21項「Oracle HTTP Serverを使用したアクセスの検証」

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

Imagingのカスタム・キーストアとともにノード・マネージャを構成します。

第11.22項「WLS_IMG管理対象サーバーのノード・マネージャの構成」

Imaging管理対象サーバー用のサーバー移行の構成

移行のためのImaging管理対象サーバー名、ホスト名およびクラスタ名を指定します。

第11.23項「WLS_IMG管理対象サーバー用のサーバー移行の構成」

Imagingの構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第11.24項「インストールのバックアップ」

11.2 WCCHOST1およびWCCHOST2のVIP4およびVIP5の有効化

Oracle WebCenter Content: Imagingシステムは、システムが実行している管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。これらの仮想ホスト名および対応する仮想IPは、Oracle WebCenter Content: Imagingコンポーネントのサーバー移行を有効にするために必要です。WCCHOST1ではWCCHOST1VHN1、WCCHOST2ではWCCHOST2VHN1にVIP(VIP4/VIP5)マッピングを有効にして、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはhosts解決のいずれかで)正しく解決する必要があります。

VIPを有効にするには、第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」で説明した例に従ってください。

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

第10章「Oracle WebCenter Contentを追加するためのドメインの拡張」で構成されたドメインを拡張して、Oracle WebCenter Content: Imagingを追加します。この項の手順は、Oracle WebCenter Contentのデプロイメントと同じデータベース・サービス(wccedg.mycompany.com)をImagingのデプロイメントでも使用することを前提としています。ただし、Imaging専用の別のデータベース・サービスをデプロイメントに使用することもできます。

注意:

これらの手順を実行する前に、Oracle Fusion Middleware管理者ガイドの説明に従ってドメインをバックアップしてください。

Oracle WebCenter Content: Imagingを追加するためにドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。
Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. SOAHOST1で、ディレクトリをFusion Middleware構成ウィザードの場所に変更します。これはOracle共通ホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行します)。

cd ORACLE_COMMON_HOME/common/bin

3. Fusion Middleware構成ウィザードを起動します。

./config.sh

4. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

5. 「WebLogicドメイン・ディレクトリ」画面で、WebLogic Serverドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name)を選択し、「次へ」をクリックします。

6. 「拡張ソースの選択」画面(図11-1)で、次の選択を行います。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。
Oracle WebCenter Content: Imaging - 11.1.1.0 [wcc]

次の製品はすでに選択されてグレー表示されています。これらは、ドメインを作成した際(第8.3項)あるいはOracle SOA Suiteコンポーネント用(第9.3項)またはWebCenter Content用(第10.3項)に拡張した際に選択されました。

WebLogic Serverの基本ドメイン - 10.3.6.0 [wlserver_10.3]

Oracle SOA Suite for developers - 11.1.1.0 [soa]

Oracle SOA Suite - 11.1.1.0 [soa]

Oracle Universal Content Management - Content Server - 11.1.1.0 [wcc]

Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

Oracle WSM Policy Manager - 11.1.1.0 [oracle_common]

Oracle JRF - 11.1.1.0 [oracle_common]

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

「図11-1 Imagingの「拡張ソースの選択」画面」の説明

「次へ」をクリックします。

7. 「JDBCコンポーネント・スキーマの構成」画面(図11-2)で、次の手順を実行します。

1. (Imagingの場合は)IPMスキーマのみを選択します。他の既存スキーマはいずれも選択しないでください。

2. RAC構成については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます(付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照)。ここでの説明に合わせて、「GridLinkへ変換」を選択します。
RAC構成を選択すると、選択されたすべてのスキーマがグレー表示されます。

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

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

3. 「次へ」をクリックします。

8. 「GridLink RACコンポーネント・スキーマの構成」画面(図11-3)で、次の手順を実行します。

1. (Imagingの場合は)IPMスキーマを選択します。その他のデータ・ソースはそのままにします。

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

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

2. 次の各フィールドに値を入力して、RCUでシードされたGridLink RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLink接続用のドライバ(Thin)、バージョン:10以降を選択します。

- サービス名: Oracle RACデータベースのサービス名は小文字で入力し、ドメイン名を続けます(例: wccedg.mycompany.com)。

- ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてDEVを使用しています。

- パスワード: データベース・スキーマの所有者のパスワードを入力します。

- 「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.mycompany.com :1521

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。次に例を示します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データソースの使用」を参照してください。

- ONSホスト: データベースによって報告されるRACデータベースのSCANアドレスとONSリモート・ポートも入力します。

[orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

3. 「次へ」をクリックします。

注意:

UCMスキーマ、「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」、OWSM MDSスキーマおよびSOA MDSスキーマの情報はそのままにしておきます。

9. 「JDBCコンポーネント・スキーマのテスト」画面で、IPMスキーマ行を選択し、 「接続のテスト」をクリックします。
結果は「接続結果ログ」に表示されます。スキーマを含むデータベースへの接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正してテストを再試行します。

図11-4

「図11-4」の説明

接続に成功したら、「次へ」をクリックします。

10. 「オプションの構成を選択」画面で、次のオプションを選択します。

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

11. 「JMS分散宛先タイプの選択」画面で、すべてのOracle Fusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストからUDDを選択します。「次へ」をクリックします。
オーバーライドの警告が表示された場合、「OK」をクリックして、このメッセージを確認します。

12. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
サーバーが自動的に作成されます。このサーバーの名前をWLS_IMG1に変更し、WLS_IMG2という新しいサーバーを追加します。表11-2に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは、このまま変更しません。

表11-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_IMG1

WCCHOST1VHN1

16000

n/a

いいえ

WLS_IMG2

WCCHOST2VHN2

16000

n/a

いいえ

「次へ」をクリックします。

13. 「クラスタの構成」画面で、「追加」をクリックし、表11-3に示すクラスタを追加します。画面に表示されている他のクラスタは変更せず、そのままにしておきます。

表11-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

IMG_Cluster

ユニキャスト

n/a

n/a

空のままにします。

「次へ」をクリックします。

14. 「サーバーのクラスタへの割当」画面で、次の項目を追加します。この画面に表示されている他の割当ては、このまま変更しません。

- IMG_Cluster:

- WLS_IMG1

- WLS_IMG2

「次へ」をクリックします。

15. 「マシンの構成」画面で、「Unixマシン」タブを開きます。マシンWCCHOST1およびWCCHOST2を確認して、次のように入力します。

表11-4 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINVHN

localhost

WCCHOST1

WCCHOST1

WCCHOST2

WCCHOST2

他のフィールドはすべてデフォルト値のままにします。「次へ」をクリックします。

16. 「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

- WLS_IMG1をWCCHOST1に割り当てます。

- WLS_IMG2をWCCHOST2に割り当てます。

「次へ」をクリックします。

17. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- 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の両方にターゲット設定する必要があります。

「次へ」をクリックします。

18. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

19. 「構成のサマリ」画面で、「拡張」をクリックします。

20. ドメインのポートの競合に関する警告ダイアログ・ウィンドウが表示された場合、「OK」をクリックします。この警告は、ノードに以前から存在していたサーバーによるもので、無視してかまいません。

21. 「ドメインの作成中」画面で、「完了」をクリックします。

22. 加えた変更を有効にするために管理サーバーを再起動します。第11.10項「管理サーバーの再起動」を参照してください。

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

この手順は、管理サーバーで様々なノードを認証するための適切な証明書を設定していない場合に必要です(第13章「ノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、様々なWebLogicサーバーを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証中にホスト名の検証を無効にし、EDGトポロジの構成完了後に第13章「ノード・マネージャの設定」の説明に従って再びホスト名の検証を有効にします。

ホスト名検証を無効化するには:

1. WebLogic Server管理コンソールにログインします。

2. 管理コンソールで、「WLS_IMG1」→「SSL」→「詳細」を選択します。

3. 「ロックして編集」をクリックします。

4. ホスト名の検証をNoneに設定します。

5. 管理コンソールで、「WLS_IMG2」→「SSL」→「詳細」を選択します。

6. ホスト名の検証をNoneに設定します。

7. 変更を保存してアクティブ化します。

11.5 WCCHOST1およびWCCHOST2でのノード・マネージャの起動

ノード・マネージャがまだ起動されていない場合に、WCHOST1およびWCHOST2でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、WEBHOST1およびWEBHOST2の両方で、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

cd ORACLE_COMMON_HOME/common/bin

./setNMProps.sh

注意:

クラスのロードの失敗やその他の問題を回避するには、StartScriptEnabledプロパティを使用します。第16.11.3項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」も参照してください。

注意:

第3章「エンタープライズ・デプロイメント用のネットワークの準備」の共有記憶域構成で示しているように、Imaging管理対象サーバーがローカル記憶域または共有記憶域でOracle WebCenter ContentとMW_HOMEを共有している場合には、setNMProps.shを再度実行する必要はありません。この場合、ノード・マネージャはすでに起動スクリプトを使用するように構成されています。また、Oracle WebCenter Contentのノードですでに実行している可能性があります。

2. WCHOST1およびWCHOST2の両方で次のコマンドを実行し、ノード・マネージャを起動します。

cd WL_HOME/server/bin

./startNodeManager.sh

11.6 WCC_IMG1のGridLinkデータ・ソースの検証

ドメイン構成をWCCHOST2に伝播する前に、作成したすべてのGridLinkデータ・ソースが適切に構成されており、各管理対象サーバーで各データ・ソースのOracle Notification Service (ONS)設定が適切であることを確認します。

ImagingのGridLinkデータ・ソースの構成を確認する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. 作成したGridLinkデータ・ソースの名前をクリックします。

4. 「監視」タブをクリックし、いずれかのサーバーの名前をクリックします。

5. 「テスト」タブ(図11-5)をクリックし、いずれかのサーバーを選択し、「データ・ソースのテスト」をクリックします。

図11-5 ImagingのGridLinkデータ・ソースのテスト

「図11-5 ImagingのGridLinkデータ・ソースのテスト」の説明

構成が適切であればテストは成功します。

6. GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスでテストを繰り返します。

ImagingのGridLinkデータ・ソースのONSの構成を確認する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」をクリックします。

3. GridLinkデータ・ソースの名前をクリックします。

4. 「ONS」タブをクリックし、「テスト」タブ(図11-6)をクリックします。

5. サーバーを選択し、「ONSのテスト」をクリックします。

図11-6 ImagingのONS構成のテスト

「図11-6 ImagingのONS構成のテスト」の説明

構成が適切であればテストは成功します。ONSテストが失敗する場合は、Oracle RACデータベース・ノード内でONSサービスが稼動していることを確認します。

[orcl@CUSTDBHOST1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node CUSTDBHOST1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node CUSTDBHOST2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node CUSTDBHOST2

[orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@CUSTDBHOST1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: CUSTDBHOST1
ONS daemon is running on node: CUSTDBHOST2

6. GridLinkデータ・ソースを使用するすべてのWebLogic ServerインスタンスでONSテストを繰り返します。

11.7 unpackユーティリティを使用したWCCHOST1およびWCCHOST2へのドメイン構成の伝播

ドメイン構成を伝播する手順は次のとおりです。

1. 次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateIMG.jar -template_name=edgdomain_templateIMG

2. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・パックをWCCHOST2にコピーします。

注意:

WCCHOST1がORACLE_HOMEをSOAHOST1と共有していると仮定した場合、テンプレートは、WCCHOST1の同一のディレクトリに存在します。そうでなければ、これもWCCHOST1にコピーします。

scp edgdomaintemplateIMG.jar oracle@WCCHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin

3. unpackコマンドをWCCHOST1で実行し、伝播されたテンプレートを解凍します。

注意:

unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateIMG.jar –app_dir= ORACLE_BASE/admin/domain_name/mserver/applications –overwrite_domain=true

注意:

unpackを実行する前に、ORACLE_BASE/admin/domain_name/mserverディレクトリが存在している必要があります。また、ORACLE_BASE/admin/domain_name/mserver/applicationsが空である必要があります。

4. WCCHOST2に対して3の手順を繰り返します。

11.8 Oracle WebCenter Content: Imaging用のJMS永続ストアの構成

2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Oracle WebCenter Content: Imagingで使用されるJMSサーバーに永続ストアは構成されず、Oracle WebLogic Serverのストア(ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/store/default)を使用しています。次のように、共有ベースのディレクトリを使用するように、ImagingのJMSサーバーの永続ストアを変更する必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて永続ストアノードをクリックします。

3. 「永続ストアの概要」ページで「ロックして編集」をクリックします。

4. 「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。

5. 名前(例: IMGJMSServer1Store。これにより、作成対象のサービスを特定できます)およびターゲットのWLS_IMG1を入力します。WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを入力します(ORACLE_BASE/admin/domain_name/img_cluster_name/jms)。

6. 「OK」をクリックして、変更をアクティブ化します。

7. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSサーバー」ノードをクリックします。

8. 「JMSサーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)JMSサーバー「IpmJmsServer1」をクリックします。

9. このJMSサーバーの「設定」ページで、「ロックして編集」をクリックしてください。

10. 「永続ストア」ドロップダウン・リストで、「IMGJMSServer1Store」を選択します。

11. 「保存してアクティブ化」をクリックします。

12. 手順を繰り返して、IMGJMSServer2のIMGJMSServer2Storeを作成します。

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

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーからアクセスできる場所にトランザクション・ログを格納します。

注意:

デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。

WLS_IMG1のデフォルト永続ストアの場所を設定する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)「WLS_IMG1」をクリックします。WLS_IMG1サーバーの設定ページが開き、「構成」タブがアクティブに表示されます。

4. 「サービス」タブを開きます。

5. 「ロックして編集」をクリックします。

6. 表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/img_cluster_name/tlogs

7. 「保存」をクリックして、変更をアクティブ化します。

8. WLS_IMG2サーバーに対して手順を繰り返します。

注意:

トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。WCCHOST1とWCCHOST2の両方が、このディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

11.10 管理サーバーの再起動

管理サーバーを再起動して、ここまでの変更を有効にします。管理サーバーを再起動するには、最初に管理コンソールを使用してサーバーを停止し、第8.4.4項「SOAHOST1での管理サーバーの起動」の説明に従って再起動します。

11.11 Imaging管理対象サーバーの起動

WCCHOST1でWLS_IMG1管理対象サーバーを起動する手順は次のとおりです。

1. 管理対象サーバーWLS_IMG1を起動します。

1. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. 表の「サーバー」列から「WLS_IMG1」を選択します。

5. 「起動」をクリックします。

2. http://WCCHOST1VHN1:16000/imagingにアクセスしてWLS_IMG1のステータスを確認します。Oracle WebCenter Content: Imagingのログイン・ページが表示されます。Oracle WebLogic Server管理のユーザー名とパスワードを入力し、ログインします。
データベースのPROCESSES初期化パラメータができるだけ高い値に設定されていることを確認してください。詳細は、第5.2.3項「初期化パラメータ」を参照してください。このエラーが発生する可能性があるのは、1台のサーバーを起動した後に別のサーバーを起動したときです。

3. 管理対象サーバーWLS_IMG2を起動します。

1. http://ADMINVHN:7001/consoleでWebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. 表の「サーバー」列から「WLS_IMG2」を選択します。

5. 「起動」をクリックします。

4. http://WCCHOST2VHN1:16000/imagingにアクセスしてWLS_IMG2のステータスを確認します。Oracle WebCenter Content: Imagingのログイン・ページが表示されます。Oracle WebLogic Server管理のユーザー名とパスワードを入力し、ログインします。

注意:

ここで示す手順は、SOAHOST2でOracle WSMまたはOracle SOA Suiteの管理対象サーバーについて事前にホスト名の検証が行われており、さらに、SOAHOST2でノード・マネージャがすでに実行されていることを前提としています。

11.12 WLS_IMG2のGridLinkデータ・ソースの検証

WLS_IMG1およびWLS_IMG2の構成が終了し、管理サーバーおよび管理対象サーバーを起動した後、作成したすべてのGridLinkデータ・ソースが適切に構成されており、各管理対象サーバーで各データ・ソースのOracle Notification Service (ONS)設定が適切であることを確認します。

注意:

作成したGridLinkデータ・ソースが適切に構成されていることを確認するには、第11.6項「WCC_IMG1のGridLinkデータ・ソースの検証」に示されている手順に従います。ただし、2台目のサーバーはWLS_IMG2になります。

11.13 Oracle WebCenter Content: Imaging用のシステムMBeanの構成

Oracle WebCenter Content: Imaging用に次のシステムMBeanを構成する手順は次のとおりです。

- InputDirectories

- SampleDirectory

- GDFontPath

1. http://ADMINVHN:7001/emでOracle Fusion Middleware Controlにログインします(図11-7)。

図11-7 システムMBeanブラウザ

「図11-7 システムMBeanブラウザ」の説明

2. 左側のペインで、ファームのドメイン名→「WebLogicドメイン」→ドメイン名→「IMG_Cluster」」を開き、「WLS_IMG1」リンクをクリックします。

3. 右側ペのインの上部で、「WebLogic Server」ドロップダウン・メニューをクリックし、「システムMBeanブラウザ」を選択します。

4. 「アプリケーション定義のMBean」→「oracle.imaging」を開きます。

5. 「サーバー: WLS_IPM1」→「config」を開きます。

6. 豆の形をした「config」リンクをクリックします。

7. 右側のペインで、「InputDirectories」のMbeanを設定し、パスを入力ファイル(ORACLE_BASE/admin/domain_name/img_cluster_name/input_files)に指定します。
関連するすべてのOracle WebCenter Contentのサーバーがこの場所を解決(つまりNFSマウント・ポイントを経由)できる必要があります。

8. 「SampleDirectory」のMBeanの設定: ORACLE_BASE/admin/domain_name/img_cluster_name/input_files/Samples
入力ファイルを処理するには、入力エージェントが入力ディレクトリに対して適切な権限を持ち、入力ディレクトリにおいてファイル・ロックができる必要があります。入力エージェントを使用する場合は、WebLogic Serverのサービスを実行中のユーザー・アカウントが、入力ディレクトリと入力ディレクトリ内のすべてのファイルとサブディレクトリに対して、読取りと書込みの権限を保持している必要があります。この必要な権限によって、入力エージェントは、ファイルを処理する際に様々なディレクトリにファイルを移動できます。クラスタのサーバー間で処理を調整するために、共有上のファイル・ロックが入力エージェントに必要になります。

9. X Windows環境用のGDフォントへのパスを指定するように「GDFontPath」のMBeanを設定します。システム管理者に確認してください。多くの場合、デフォルトは、/usr/share/X11/fonts/TTFまたは/usr/lib/X11/fonts/TTFです。

10. 「適用」をクリックします。

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

WebCenter Contentにおいて、Imagingの機能セットを有効にする手順は次のとおりです。

1. http://WCCHOST1:16200/csでOracle Content Serverにログインします。

2. 「管理」トレイまたはメニューを開いて、「管理サーバー」を選択します。

3. 「コンポーネント・マネージャ」ページで、IpmRepositoryコンポーネントを有効にします。

4. 「更新」をクリックして、処理を確定します。

5. 管理対象サーバーを再起動後、Oracle WebCenter Contentのクラスタ内のすべての管理対象サーバーを再起動します。

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

WLS_IMG1およびWLS_IMG2管理対象サーバー(それぞれWCCHOST1VHN1およびWCCHOST2VHN1)のホスト名をSocketHostNameSecurityFilterパラメータ・リストに追加する手順は次のとおりです。

1. テキスト・エディタで、ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfgのファイルを開きます。

2. 次の行を削除またはコメント・アウトします。

SocketHostAddressSecurityFilter=127.0.0.1|WCCHOST1|WCCHOST2|WEBHOST1|WEBHOST2

3. WLS_IMG1およびWLS_IMG2リスニング・アドレスをOracle WebCenter Contentへの接続を許可するアドレスのリストに含めるために、次の2行を追加します。

SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|WCCHOST1|WCCHOST2|WCCHOST1VHN1|WCCHOST2VHN1
AlwaysReverseLookupForHost=Yes

4. 変更されたconfig.cfgファイルを保存して、Oracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

11.16 Oracle WebCenter Contentへの接続の作成

Oracle WebCenter Content Serverへの接続手順は次のとおりです。

1. http://WCCHOST1VHN1:16000/imagingでWLS_IMG1イメージング・コンソールにログインします。

2. 左側のペインで、「接続の管理」→「Content Server接続の作成」をクリックします。

3. 新しい接続の名前と説明を入力し、「次へ」をクリックします。

4. 「接続設定」画面で、次の操作を実行します。

- 「ローカルContent Serverの使用」チェック・ボックスが選択されていることを確認します。

- Content Serverポートを4444に設定します。

- Content Serverプールに2つのサーバーを追加します。

- WCCHOST1:4444

- WCCHOST2:4444

「次へ」をクリックします。

5. 「接続セキュリティ」画面で、WebLogicユーザーに対するデフォルトの選択をそのまま受け入れて、「次へ」をクリックします。

6. 接続の詳細を確認し、「送信」をクリックします。

11.17 BPEL CSF資格証明の構成

Oracle WebCenter Content: ImagingからBPELシステムに接続する場合、Oracle SOA Suiteと通信するために必要な資格証明を構成する必要があります。これらの資格証明を追加するには、次の手順を実行します。

1. SOAHOST1で、(管理サーバーが存在する)SOAHOST1のOracle WebCenter Contentホーム配下のcommon/binの場所にディレクトリを変更します。

cd WCC_ORACLE_HOME/common/bin

(WCC_ORACLE_HOMEはOracle WebCenter ContentのOracleホームで、このOracleホームはEDGトポロジのMW_HOME/wccとなります。)

2. Oracle WebLogic Scripting Tool(WLST)を実行します。

./wlst.sh

3. connect()を実行して、ユーザー名、パスワードおよび管理サーバーのURL (t3://ADMINVHN:7001)を指定します。

wls:/offline> connect()

4. CSF(資格証明ストア・フレームワーク)資格証明を作成します。この資格証明は、ImagingがBPELシステムへの接続に使用する資格証明です。これをBPEL管理ユーザーにします。CSF資格証明は、aliasがキーとなり、CSFのmapという中に保存されるユーザー名/パスワードのペアです。OWSM Webサービスと統合するため、Oracle WebCenter Content: 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は、Oracle WebCenter Content: Imaging管理ユーザー・インタフェースのBPEL接続定義の「資格証明別名」プロパティに使用されるaliasです(APIのConnection.CONNECTION_BPEL_CSFKEY_KEYプロパティにも使用されます)。OWSMおよびBPELで使用される標準のデフォルト名であるため、この例では別名basic.credentialを使用します。ただし、別名はマップ内で一意であれば、任意に指定できます。

注意:

Oracle SOA Suiteシステムと、中央のLDAPおよびシングル・サインオン(SSO)のシステムとの統合時に、異なるユーザーやパスワードを後で使用する場合、新しいマップの作成または既存マップの更新が必要となります。作成されるサンプル・ユーザーの詳細は、第15章「Oracle Identity Managementとの統合」を参照してください。

5. 資格証明のリストコマンドを実行して、資格証明が作成されたことを確認します。

wls:/domain_name/serverConfig> listCred(map="oracle.wsm.security", key="basic.credential")
{map=oracle.wsm.security, key=basic.credential}
Already in Domain Runtime Tree

[Name : weblogic, Description : null, expiry Date : null]
PASSWORD: password_for_credential

11.18 ワークフロー接続の構成

ワークフロー接続を構成する手順は次のとおりです。

1. http://ECHMHOSTVHN1:16000/imagingでWLS_IMG1イメージング・コンソールにログインします。

2. ナビゲーション・ペインから、「接続の管理」の下で「追加」アイコン→「ワークフロー接続の作成」をクリックします。

3. 「ワークフロー接続基本情報」ページで、接続名を入力します。この名前は、「接続の管理」パネルに表示されます。このフィールドは必須です。必要に応じて、接続の簡単な説明を入力します。接続タイプはデフォルトで「ワークフロー接続」に設定されます。

4. 「次へ」をクリックします。

5. 「ワークフロー接続設定」ページで、次の操作を実行します。

1. 「HTTPフロントエンド・アドレス」フィールドで、ワークフロー・サーバー(http://soainternal.mycompany.com:80)のホスト名またはIPアドレス、ドメイン、およびポート番号を指定します。このフィールドは必須です。

2. 「資格証明別名」フィールドに、第11.17項「BPEL CSF資格証明の構成」の説明に従って先ほど作成した資格証明の別名を入力します。

3. 「プロバイダ」フィールドに、2つのOracle SOA Suiteサーバー・リスニング・アドレスをカンマで区切って、t3://SOAHOST1VHN1,SOAHOST2VHN1:8001と入力します。

4. 「接続のテスト」ボタンをクリックして、接続パラメータを確認し、BPELマシンに存在するコンポジットを確かめます。

5. 「次へ」をクリックします。

6. 必要に応じて、付与するセキュリティを変更します。

7. 「次へ」をクリックします。

8. 「送信」をクリックします。

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

WLS_IMG1とWLS_IMG2の管理対象サーバーが属するIMG_ClusterにOracle HTTP Serverからルーティングをできるようにするには、次のようにWebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

1. WEBHOST1とWEBHOST2で、ORACLE_BASE/admin/instance_name/config/OHS/component_name/mod_wl_ohs.confに次の行を追加します。

# Oracle WebCenter Content: Imaging Application
<Location /imaging >
WebLogicCluster WCCHOST1VHN1:16000,WCCHOST2VHN1:16000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# AXF WS Invocation
<Location /axf-ws >
WebLogicCluster WCCHOST1VHN1:16000,WCCHOST2VHN1:16000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

2. WEBHOST1とWEBHOST2の両方でOracle HTTP Serverを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohsX

ias-componentに対して、WEBHOST1ではohs1を使用し、WEBHOST2ではohs2を使用します。

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

Oracle WebLogic Server Imagingクラスタ(IMG_Cluster)について、フロントエンドHTTPのホストとポートを設定する必要があります。

1. WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」セクションに移動して、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「クラスタ」をクリックします。

5. 「クラスタの概要」ページで、「IMG_Cluster」を選択します。

6. 「HTTP」タブを開きます。

7. 次の値を設定します。

- フロントエンド・ホスト: wcc.mycompany.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80

8. 「保存」をクリックします。

9. 管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

10. サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効にします。

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

URLを検証して、HTTPサーバーからIMG_Clusterへのルーティングとフェイルオーバーが適切に機能することを確認します。URLを検証する手順は次のとおりです。

1. WLS_IMG2が稼動している状態で、WebLogic Server管理コンソールを使用してWLS_IMG1を停止します。

2. http://WEBHOST1:7777/imagingにアクセスし、正しく動作していることを確認します。(Imagingサーバーが停止しているので、レポートやデータは取得できません。)

3. WebLogic Server管理コンソールからWLS_IMG1を起動します。

4. WebLogic Server管理コンソールでWLS_IMG2を停止します。

5. http://WEBHOST1:7777/imagingにアクセスし、正しく動作していることを確認します。

6. WebLogic Server管理コンソールからWLS_IMG2を起動します。

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

第10.16項「WLS_WCCおよびWLS_IMG管理対象サーバーのノード・マネージャの構成」の説明のとおり、WLS_IMG管理対象サーバーがリスニング・アドレスとして使用するホスト名は、ホスト名検証用にすでに構成されていることを前提としています。

この時点で、Imaging管理対象サーバーがドメインに追加されてから、サーバーがカスタム・キーストアを使用するように構成されるためには、第13.3.5項「カスタム・キーストアを使用するための管理対象サーバーの構成」の手順を実行する必要があります。

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

サーバー移行は、WCCHOST1ノードとWCCHOST2ノードのどちらかで障害が発生した場合に、Oracle WebCenter Content: Imagingのコンポーネントを正しくフェイルオーバーするために必要です。詳細は、第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。Oracle WebCenter Content: Imagingに関しては、その章で次の変数の値を使用します。

- サーバー名:

- WLS_SERVER1: WLS_IMG1

- WLS_SERVER2: WLS_IMG2

- ホスト名:

- HOST1: WCCHOST1

- HOST2: WCCHOST2

- クラスタ名:

- CLUSTER: IMG_Cluster

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

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。また、データベースのバックアップに関する詳細は、Oracle Databaseバックアップおよびリカバリ・ガイドを参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

1. WEBHOST1でWeb層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドを使用して、Web層のOracleインスタンスをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

cd ORACLE_BASE/admin/instance_name/bin

opmnctl startall

2. データベースをバックアップします。これは、Oracle Recovery Managerを使用したデータベース全体のホット・バックアップまたはコールド・バックアップ(推奨)、または可能な場合はtarなどのオペレーティング・システム・ツールを使用したコールド・バックアップです。

3. ドメイン構成を保存するために、管理サーバーと管理対象サーバーのドメイン・ディレクトリをバックアップします。構成ファイルはすべて、ORACLE_BASE/admin/domain_nameディレクトリにあります。SOAHOST1で次のコマンドを実行して、バックアップを作成します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

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

この章では、Oracle Fusion Middleware構成ウィザードを使用して、Oracle WebCenter Content: Inbound Refineryを使用するドメインの拡張方法について説明します。この章には次の項目があります。

- 第12.1項「Oracle WebCenter Content: Inbound Refineryを使用するためのドメインの拡張の概要」

- 第12.2項「Inbound Refinery管理対象サーバーと仮想ホスト名の関連付け」

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

- 第12.4項「WCCHOST1およびWCCHOST2でのノード・マネージャの起動」

- 第12.6項「管理サーバーの再起動」

- 第12.5項「unpackユーティリティを使用したWCCHOST1およびWCCHOST2へのドメイン構成の伝播」

- 第12.7項「Inbound Refinery管理対象サーバーの起動」

- 第12.8項「Inbound Refineryの構成」

- 第12.9項「Inbound Refinery管理対象サーバーの構成の検証」

注意:

セットアップ・プロセスを開始する前に、リリース・ノートを読み、インストールおよびデプロイメントに関する追加情報を確認してください。これらは、Oracle Fusion Middlewareドキュメント・ライブラリ(http://docs.oracle.com/cd/E23943_01/relnotes.htm)で入手できます。

12.1 Oracle WebCenter Content: Inbound Refineryを使用するためのドメインの拡張の概要

Oracle WebCenter Content: Inbound Refineryは、Oracle WebCenter Content Serverがドキュメント変換を行う際に必要になります。実際のInbound Refinery管理対象サーバー数は、要件によって異なります。可用性の理由から、少なくとも2つのInbound Refinery管理対象サーバーを構成することをお薦めします。これらのサーバーは個別のマシンで構成します。参照用Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジにおいて、Inbound RefineryはContent Serverと同一のマシンに構成されます。

Inbound Refineryを使用するためにドメインを拡張するプロセスでクラスタを作成しても、各Inbound Refineryインスタンスは完全に独立しています。クラスタリングは、管理のみの目的で使用されます。

Oracle WebCenter Content: Inbound Refineryを追加するには、ドメインを拡張します。表12-1に、WebCenter Contentの構成手順と、Inbound Refinery管理対象サーバーを含むドメインの拡張に必要なタスクを示します。

表12-1 Inbound Refineryを含むドメインの拡張手順

手順

説明

詳細

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

WLS_IBR1およびWLS_IBR2を仮想ホスト名に関連付けます。

第12.2項「Inbound Refinery管理対象サーバーと仮想ホスト名の関連付け」

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

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogicドメインを拡張します。

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

管理対象サーバーへのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第12.5項「unpackユーティリティを使用したWCCHOST1およびWCCHOST2へのドメイン構成の伝播」

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

setNMProps.shスクリプトを実行し、WCCHOST1およびWCCHOST2のノード・マネージャを起動します。

第12.4項「WCCHOST1およびWCCHOST2でのノード・マネージャの起動」

ドメインの管理サーバーの再起動

管理サーバーを停止して起動し、前の手順で行った変更を有効にします。

第12.6項「管理サーバーの再起動」

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

WLS_IBR1およびWLS_IBR2管理対象サーバーを起動します。

第12.7項「Inbound Refinery管理対象サーバーの起動」

Inbound Refineryインスタンスの構成

WLS_IBR1およびWLS_IBRでInbound Refineryの初期構成を完了します。

第12.8項「Inbound Refineryの構成」

Inbound Refineryの構成の検証

変換に有効と認識された拡張子を持つファイルがコンテンツ・サーバーで正しく変換されていることを検証します。

第12.9項「Inbound Refinery管理対象サーバーの構成の検証」

12.2 Inbound Refinery管理対象サーバーと仮想ホスト名の関連付け

WLS_IBR1およびWLS_IBR2サーバーを仮想ホスト名(WCCHOST1VHN1およびWCCHOST2VHN1)に関連付けます。これらの仮想ホスト名がDNSまたはシステム内の/etc/hosts解決で有効になっていること、およびそれらが適切なVIPにマップされていることを確認します。

詳細は、第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」を参照してください。

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

エンタープライズ・デプロイメント・トポロジを完了するには、Oracle WebCenter Content: Inbound Refineryを追加するために第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを拡張する必要があります。

注意:

これらの手順を実行する前に、Oracle Fusion Middleware管理者ガイドの説明に従ってドメインをバックアップしてください。

Oracle WebCenter Content: Inbound Refineryを追加するためにドメインを拡張する手順は次のとおりです。

1. リポジトリ・スキーマを作成したデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. SOAHOST1で、ディレクトリをOracle Fusion Middleware構成ウィザードの場所に変更します。これは共通のOracleホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するノードから実行することに注意してください)。

cd ORACLE_COMMON_HOME/common/bin

3. 構成ウィザードを起動します。

./config.sh

4. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

5. WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name)を選択し、「次へ」をクリックします。

6. 「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。
Oracle Universal Content Management - Inbound Refinery - 11.1.1.0 [wcc]

これがOracle WebCenter Content: Inbound Refineryの選択肢です。

次の製品はすでに選択されてグレー表示されています。これらは、第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順でドメインを作成したときか、第9.3項「構成ウィザードを使用したOracle SOA Suiteコンポーネントを使用するためのドメインの拡張」、第10.3項「WebCenter Contentを追加するためのドメインの拡張」または第11.3項「Imagingを追加するためのドメインの拡張」の手順でドメインを拡張したときに選択されたものです。

- WebLogic Serverの基本ドメイン

- Oracle SOA Suite for developers

- Oracle SOA Suite

- Oracle WebCenter Content: Imaging

- Oracle Universal Content Management - Content Server

- Oracle Enterprise Manager

- Oracle WSM Policy Manager

- Oracle JRF

「次へ」をクリックします。

7. 「GridLink RACコンポーネント・スキーマの構成」画面で必要な手順はありません。Inbound Refineryでは、データベースにスキーマがありません。「次へ」をクリックして続行します。

8. 「JDBCコンポーネント・スキーマのテスト」画面で必要な手順はありません。「次へ」をクリックして続行します。

9. 「オプションの構成を選択」画面で、次のオプションを選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

10. 「管理対象サーバーの構成」画面(図12-1)で、Inbound Refineryの管理対象サーバーを追加し、Inbound Refineryサーバーを構成します。

図12-1 Inbound Refinery管理対象サーバーの構成

「図12-1 Inbound Refinery管理対象サーバーの構成」の説明

1台のサーバーが自動的に作成されます。このサーバーの名前をWLS_IBR1に変更し、WLS_IBR2という新しいサーバーを追加します。表12-2に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは変更せず、そのままにしておきます。

表12-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_IBR1

WCCHOST1

16250

n/a

いいえ

WLS_IBR2

WCCHOST2

16250

n/a

いいえ

「次へ」をクリックします。

11. 「クラスタの構成」画面で「追加」をクリックし、表12-3に示すInbound Refineryクラスタを追加します。画面に表示されている他のクラスタは変更せず、そのままにしておきます。

表12-3 クラスタ構成

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

IBR_Cluster

ユニキャスト

n/a

n/a

空のままにします。

「次へ」をクリックします。

注意:

すべてのInbound Refineryインスタンスは完全に独立しています。このクラスタは、管理のみの目的で使用されます。

12. 「サーバーのクラスタへの割当」画面(図12-2)で、次の項目を追加します。

- IBR_Cluster:

- WLS_IBR1

- WLS_IBR2

図12-2 Inbound Refineryサーバーのクラスタへの割当て

「図12-2 Inbound Refineryサーバーのクラスタへの割当て」の説明

この画面に表示されている他の割当ては、このまま変更しません。

「次へ」をクリックします。

13. 「マシンの構成」画面で、「次へ」をクリックします。

14. 「サーバーのマシンへの割当」画面(図12-3)で、次のようにInbound Refinery管理対象サーバーをマシンに割り当てます。

- WLS_IBR1をWCCHOST1に割り当てます。

- WLS_IBR2をWCCHOST2に割り当てます。

図12-3 Inbound Refineryサーバーのマシンへの割当て

「図12-3 Inbound Refineryサーバーのマシンへの割当て」の説明

「次へ」をクリックします。

15. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- 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の両方にターゲット設定する必要があります。

「次へ」をクリックします。

16. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

17. 「構成のサマリ」画面で、「拡張」をクリックします。

18. 「ドメインの作成中」画面で、「完了」をクリックします。

19. 管理サーバーを再起動して、ここまでの変更を有効にします。
詳細は、第12.6項「管理サーバーの再起動」を参照してください。

12.4 WCCHOST1およびWCCHOST2でのノード・マネージャの起動

ノード・マネージャがまだ起動されていない場合に、WCHOST1およびWCHOST2でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、WEBHOST1およびWEBHOST2の両方で、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

cd ORACLE_COMMON_HOME/common/bin

./setNMProps.sh

注意:

クラスのロードの失敗やその他の問題を回避するには、StartScriptEnabledプロパティを使用します。第16.11.3項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」も参照してください。

注意:

第3章「エンタープライズ・デプロイメント用のネットワークの準備」の共有記憶域構成で示しているように、Inbound Refineryサーバーがローカル記憶域または共有記憶域でOracle WebCenter ContentとMW_HOMEを共有している場合には、setNMProps.shを再度実行する必要はありません。この場合、ノード・マネージャはすでに起動スクリプトを使用するように構成されています。また、Oracle WebCenter Contentのノードですでに実行している可能性があります。

2. WCHOST1およびWCHOST2の両方で次のコマンドを実行し、ノード・マネージャを起動します。

cd WL_HOME/server/bin

./startNodeManager.sh

12.5 unpackユーティリティを使用したWCCHOST1およびWCCHOST2へのドメイン構成の伝播

ドメイン構成を伝播する手順は次のとおりです。

1. 次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateIBR.jar -template_name=edgdomain_templateIBR

2. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・パックをWCCHOST2にコピーします。

注意:

WCCHOST1がORACLE_HOMEをSOAHOST1と共有していると仮定した場合、テンプレートは、WCCHOST1の同一のディレクトリに存在します。そうでなければ、これもWCCHOST1にコピーします。

scp edgdomaintemplateIBR.jar oracle@WCCHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin

3. unpackコマンドをWCCHOST1で実行し、伝播されたテンプレートを解凍します。

注意:

unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateIBR.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications -overwrite_domain=true

注意:

unpackを実行する前に、ORACLE_BASE/admin/domain_name/mserverディレクトリが存在している必要があります。また、ORACLE_BASE/admin/domain_name/mserver/applicationsが空である必要があります。

4. WCCHOST2に対して3の手順を繰り返します。

12.6 管理サーバーの再起動

管理サーバーを再起動して、ここまでの変更を有効にします。管理サーバーを再起動するには、最初に管理コンソールを使用してサーバーを停止し、第8.4.4項「SOAHOST1での管理サーバーの起動」の説明に従って再起動します。

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

WCCHOST1でWLS_IBR1管理対象サーバーを起動する手順は次のとおりです。

1. http://ADMINVHN:7001/consoleでOracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. 表の「サーバー」列から「WLS_IMG1」を選択します。

5. 「起動」をクリックします。

これらの手順を繰り返し、WCCHOST2でWLS_IBR2管理対象サーバーを起動します。

12.8 Inbound Refineryの構成

Inbound RefineryにはHTTPを介して1回のみアクセスして、その構成を初期化する必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound Refineryは、HTTPサーバーの背面に配置できません。

Inbound Refineryに対する以降のすべてのアクセスは、ソケット・リスナーを介して行われます。このリスナーは、次の項で構成される着信ソケット接続アドレス・セキュリティ・フィルタによって保護されます。

すべてのInbound Refineryインスタンスを使用して各Oracle WebCenter Content Serverを構成することをお薦めします。Oracle WebCenter Contentの構成プロセスは、Inbound Refineryインスタンスをプロバイダとして追加することです。Inbound Refineryを使用して実行する必要がある、インストール後の手順もあります。

次の項では、各Inbound Refineryインスタンスのインストール後の構成手順について説明します。

- 第12.8.1項「Inbound Refineryの設定の構成」

- 第12.8.2項「ドキュメント変換の構成」

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

12.8.1 Inbound Refineryの設定の構成

各Inbound Refineryインスタンスの設定を構成する手順は次のとおりです。

1. 次のURLからInbound Refineryのインストール後の構成画面にアクセスします。Nには1または2を指定します。

http://WCCHOSTN:16250/ibr/

2. 「構成」画面で、Inbound Refineryインスタンス識別子であるnameを確認します。このインスタンスの構成設定を次のように設定します。

- Inbound Refineryのインスタンス・フォルダ: これをORACLE_BASE/admin/domain_name/ibr_cluster_name/ibrNに設定します。ディレクトリ・パスは共有ディスクに配置し、Inbound Refineryインスタンスごとに一意である必要があります。

- ネイティブ・ファイル・リポジトリの場所: これをORACLE_BASE/admin/domain_name/ibr_cluster_name/ibrN/vaultに設定します。

- Webレイアウト・フォルダ: これをORACLE_BASE/admin/domain_name/ibr_cluster_name/ibrN/weblayoutに設定します。

- ユーザー・プロファイル・フォルダ: これをORACLE_BASE/admin/domain_name/ibr_cluster_name/ibrN/data/users/profilesに設定します。

- ソケット接続アドレス・セキュリティ・フィルタを着信中: これを次に示すようにローカル・ホストおよびサーバーのIPのパイプ区切り一覧に設定します。

127.0.0.1|WCCHOST1-IP|WCCHOST2-IP|WEBHOST1-IP|WEBHOST2-IP

これにより、Oracle WebCenter Content Serverから接続できるようになります。WCCHOST1-IPおよびWCCHOST2-IPの値は、Inbound Refineryにジョブを送信するOracle WebCenter Contentのインスタンスが1つ以上あるマシンのIPアドレスである必要がありますが、必ずしもInbound RefineryのIPアドレスとは限りません。(ただし、このエンタープライズ・デプロイメント・ガイドで使用される参照トポロジでは、これらのIPアドレスは同じです。)

このフィールドでは、192.0.2.*のように、値にワイルドカードを使用できます。この値は、ORACLE_BASE/admin/domain_name/mserver/domain_name/ucm/ibr/
config/config.cfgのSocketHostAddressSecurityFilterを設定し、Inbound Refineryを再起動することによって、後で変更できます。

- サーバーのソケット・ポート: 5555のように、使用されていないポート番号を入力します。この値は、トップレベルのサービスを呼び出すためのポートの番号です。このフィールドの値を変更すると、ORACLE_BASE/admin/domain_name/mserver/domain_name/ucm/ibr/config/config.cfg内のIntradocServerPortエントリが変更されます。このポート番号は、後でOracle WebCenter Contentの構成時に必要となるため、書き留めておいてください。

- コンテンツ・サーバーのインスタンス名: Inbound Refineryサーバーのインスタンス名を指定します。デフォルトの値をそのまま使用することも、より便利な名前に変更することもできます。このサーバー名は、後でOracle WebCenter Contentの構成時に必要となるため、書き留めておいてください。

構成ページの他のすべてのフィールドはそのままにします。

「送信」をクリックすると、次のメッセージが表示されます。

Post-install configuration complete. Please restart this node.

3. Inbound Refinery管理対象サーバーを再起動します。

4. コンテンツ・フォルダには異なる名前を使用して、すべてのInbound Refineryに対してこれらの手順を繰り返します。

Inbound Refineryが正常に機能するには、フォント・イメージを生成するために使用されるフォントへのパスを指定する必要があります。デフォルトでは、フォント・パスはInbound Refineryで使用されるJVM内のフォント・ディレクトリ(MW_HOME/jdk160_version/jre/lib/fonts)に設定されます。ただし、デフォルト・ディレクトリに含まれるフォントは限定されているため、レンディションが低下する可能性があります。また、非標準のJVMを使用した場合、デフォルトで指定されているJVMのフォント・パスと異なることがあります。この場合、エラー・メッセージがInbound Refineryとコンテンツ・サーバーの両方から表示されます。これが発生した場合は、変換を正しくレンダリングするために必要なフォントを含むディレクトリにフォント・パスが設定されていることを確認してください。詳細は、『Oracle WebCenter Content Conversion管理者ガイド』のフォント・パスの指定に関する項を参照してください。

12.8.2 ドキュメント変換の構成

各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は、Outside Inを使用して、ドキュメントを直接PDFファイルに変換します。この変換はクロス・プラットフォームにすることができ、サードパーティ製品を必要としません。Inbound Refinery用のPDFExportConverterをサービス機能として有効にできます。詳細は、readmeファイルおよび各コンポーネントのドキュメントを参照してください。

3. 「更新」をクリックします。

4. 「OK」をクリックして、コンポーネントを有効にします。

5. Inbound Refinery管理対象サーバーを再起動します。

注意:

変換コンポーネントの詳細は、『Oracle WebCenter Content Conversion管理者ガイド』のInbound Refinery変換オプションと関連コンポーネントに関する項を参照してください。

3. 管理サーバーとすべてのInbound Refinery管理対象サーバーを再起動します。

4. プライマリWeb表示可能変換をPDFエクスポートに設定します。

1. 「変換設定」→「プライマリWebレンディション」を選択します。

2. 「プライマリWeb表示可能レンディション」ページで、「PDFエクスポートによるPDFへの変換」を選択します。

3. 「更新」をクリックして変更内容を保存します。

これで、Inbound Refineryは、サードパーティ・アプリケーションを使用せずに、Outside In PDF Exportを使用してファイルをPDFに直接変換します。

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

Oracle WebCenter Content ServerからInbound Refineryにジョブを送信して変換を実施できるようにするには、Inbound Refinery管理対象サーバーごとに事前に次の設定タスクを実行する必要があります。

- 送信プロバイダの作成

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

- 変換するファイル・フォーマットの選択

12.8.3.1 送信プロバイダの作成

コンテンツ・サーバーからInbound Refineryにファイルを送信して変換を実施するには、「Inbound Refinery変換ジョブの処理」オプションを事前に選択して、コンテンツ・サーバーから各Inbound Refineryへの送信プロバイダを設定する必要があります。

次のタスクを実行して、各Inbound Refineryの送信プロバイダを作成します。

1. 次のURLからOracle WebCenter Content Serverにログインします。

http://WCCHOST1:16200/cs/

2. 「管理」トレイまたはメニューを開いて、「プロバイダ」を選択します。

3. プロバイダ・ページの「新規プロバイダの作成」セクションで、「送信」行の「追加」をクリックします。

4. 次の値をフィールドに入力します。

- プロバイダ名: 空白が含まれない短縮名。「インスタンス名」と同じ値を使用することをお薦めします。

- プロバイダの説明: テキスト文字列。

- サーバー・ホスト名: Inbound Refineryインスタンスが実行されているホスト・マシンの名前。たとえば、WCCHOST1など。

- HTTPサーバー・アドレス: Inbound Refineryインスタンスのアドレス。たとえば、WCCHOST1: 16250など。

- サーバー・ポート: 第12.8.1項「Inbound Refineryの設定の構成」で指定されているInbound Refineryインスタンスのサーバーのソケット・ポートフィールドの値。たとえば、5555など。これは、コンテンツ・サーバーのconfig.cfgファイルにあるIntradocServerPortの値です。

- インスタンス名: 第12.8.1項「Inbound Refineryの設定の構成」で指定されているInbound Refineryのサーバー・インスタンス名。これは、コンテンツ・サーバーのconfig.cfgファイルにあるIDC_Nameの値です。

- 相対Webルート: Inbound RefineryインスタンスのWebルート。たとえば、/ibr/など。

5. 「変換オプション」で、「Inbound Refinery変換ジョブの処理」を選択します。
「Inbound Refineryの読取り専用モード」は選択しないでください。

6. 「追加」をクリックします。

7. Oracle WebCenter Content Serverを再起動します。

8. プロバイダ・ページに戻り、プロバイダの「接続状態」の値が「良好」であることを確認します。
値が「良好」でない場合は、前述のエントリをすべて正しく入力したことを再確認し、コンテンツ・サーバーとInbound Refineryのインスタンスが相互にpingできることを確認します。

プロバイダの設定の詳細は、『Oracle WebCenter Content Conversion管理者ガイド』のコンテンツ・サーバーとRefineryの通信の構成に関する項を参照してください。

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

変換タイプによっては、コンテンツ・サーバーでヘルパー・コンポーネントを有効にする必要があります。ドキュメント変換にInbound Refineryを使用するコンテンツ・サーバーのインスタンスでは、InboundRefinerySupportコンポーネントを常に有効にする必要があります。新しいコンテンツ・サーバーのインストールではデフォルトで有効になっています。

コンテンツ・サーバーでInbound Refineryコンポーネントを有効にする手順は次のとおりです。

1. 次のURLからOracle WebCenter Content Serverにログインします。

http://WCCHOST1:16200/cs/

2. 「管理」トレイまたはメニューを開いて、「管理サーバー」→「コンポーネント・マネージャ」を選択します。

3. 「Inbound Refinery」で、「InboundRefinerySupport」が選択されていることを確認し、「XMLConverterSupport」など、有効にする他のコンポーネントを選択します。

4. 「更新」をクリックします。

5. Oracle WebCenter Content Serverを再起動します。

12.8.3.3 変換するファイル・フォーマットの選択

Oracle WebCenter Content ServerにどのファイルをInbound Refineryに送信して変換するように指示するには、ファイル・フォーマットを選択する必要があります。

変換するファイル・フォーマットを選択するには、次の手順を実行します。

1. 次のURLからOracle WebCenter Content Serverにログインします。

http://WCCHOST1:16200/cs/

2. 「管理」トレイまたはメニューを開き、「リファイナリ管理」→「ファイル・フォーマット・ウィザード」を選択し、「ファイル・フォーマット・ウィザード」ページを開きます。このページで、コンテンツ・サーバーへのチェックイン時にInbound Refineryに送信して変換するためのファイル・フォーマットを指定します。

3. Microsoft Wordドキュメントのdoc、dot、docxおよびdotxなど、変換が必要なフォーマットを選択します。

4. 「更新」をクリックします。

また、構成マネージャでファイル・フォーマットを選択することもできます。構成マネージャでは、ウィザードでは示されないファイル・フォーマットなど、さらにきめ細かく制御できます。詳細は、『Oracle WebCenter Content Conversion管理者ガイド』のファイル・フォーマット・ウィザードの使用に関する項および構成マネージャの使用に関する項を参照してください。

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

作成したInbound Refinery管理対象サーバーが正しく構成されているかどうかを確認するために、Oracle WebCenter Content Serverにログインして、変換に有効と認識された拡張子を持つファイルが正しく変換されることを確認することによって、構成を検証します。

たとえば、変換するフォーマットとしてdocxを選択した場合は、拡張子が.docxのMicrosoft Word文書をPDFフォーマットに変換できます。

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

この章では、EDGの推奨事項に従ってノード・マネージャを構成する方法を説明します。この章には次の項目があります。

- 第13.1項「ノード・マネージャの設定の概要」

- 第13.2項「ノード・マネージャのログの場所の変更」

- 第13.3項「ノード・マネージャのホスト名検証証明書の有効化」

- 第13.4項「ノード・マネージャの起動」

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

ノード・マネージャによって、Oracle WebLogic Serverドメインの管理サーバーと管理対象サーバーの開始および停止ができます。表13-1では、設定手順を説明するほか、設定プロセスの概要、ノード・マネージャ・ログおよびホスト名検証の推奨場所について説明します。

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

手順

説明

詳細

EDの管理ディレクトリ内でノード・マネージャ・ログの場所を指定します。

nodemanager.propertiesファイルにあるLogFileプロパティを編集して、ノード・マネージャを再起動します。

第13.2項「ノード・マネージャのログの場所の変更」

ノード・マネージャと管理サーバー間のSSL通信を設定します。

自己署名付き証明書を生成し、トラスト・キーストアおよびアイデンティティ・キーストアを作成するほか、カスタム・キーストアを使用するためにノード・マネージャおよび管理対象サーバーを構成し、各管理対象サーバーのホスト名検証設定を変更します。

第13.3項「ノード・マネージャのホスト名検証証明書の有効化」

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

初めてノード・マネージャを起動する場合は、その前にsetNMProps.shを実行します。

第13.4項「ノード・マネージャの起動」

プロセス

この章で説明される手順は、第2.1.1項「このガイドに記載されている参照用トポロジ」で概略を説明したエンタープライズ・デプロイメント・トポロジの各種コンポーネントで実行される必要があります。この章では、コンポーネント固有のアイテム間で識別するために変数を使用しています。

- WLS_SERVER: エンタープライズ・デプロイメント・コンポーネントのWebLogic管理対象サーバー(例: WLS_SOA1)を示します。

- HOST: エンタープライズ・デプロイメント・コンポーネントのホスト・コンピュータ(例: SOAHOST1)を示します。

- VIP: エンタープライズ・デプロイメント・コンポーネントの仮想IP(例: SOAHOST1VHN1)を示します。

これらの変数に使用する値は、このEDGのコンポーネント関連の章に記載されています。この章に記載されている手順は、コンポーネント関連の章に記載されている情報を使用して、VIPとIPのペアごとに複数回にわたり実行する必要があります。

推奨事項

エンタープライズ・デプロイメント・トポロジのノード・マネージャの構成に関して、次の2つの推奨事項があります。

1. ノード・マネージャのログ・ファイルをデフォルトの場所(ノード・マネージャが配置されているミドルウェア・ホーム)とは異なる場所に置くことをお薦めします。詳細は、第13.2項「ノード・マネージャのログの場所の変更」を参照してください。

2. また、ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。それには、ドメイン内で使用される複数のアドレスの証明書を使用する必要があります。この章では、ホスト名検証のために各ホストで証明書を構成する手順について説明します。詳細は、第13.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

注意:

このガイドで使用するパスワードはあくまでも一例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字をランダムな順序で並べたパスワードを使用します。

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

MW_HOME/wlserver_10.3/common/nodemanager/nodemanager.propertiesにあるノード・マネージャのプロパティ・ファイルを編集します。ログ・ファイルの新しい場所を指定する次の行を追加します。

LogFile=ORACLE_BASE/admin/nodemanager.log

この場所はMW_HOMEディレクトリの外かつEDGのadminディレクトリの中に置くことをお薦めします。

ノード・マネージャを再起動して、変更を有効にします。

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

ノード・マネージャと管理サーバー間の通信にSSLを設定する手順は次のとおりです。

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

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

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

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

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

- ステップ6: 管理対象サーバーのホスト名検証設定の変更

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

この章で(例として)追加される証明書は、ノード・マネージャが物理ホスト名(HOST.mycompany.com)でリッスンし、WLS管理対象サーバーが仮想ホスト名(VIP.mycompany.com)でリッスンする構成に対応します。サーバーが仮想ホスト名を使用している場合は、サーバーを1つのノードから別のノードに移行できることを意味します。したがって、キーストアおよびトラスト・キーストアを保持するディレクトリは、理想としては、フェイルオーバーが発生してもアクセス可能な共有記憶域に配置する必要があります。同じノードまたは別のノードで別のホスト名を使用する場合は、この例の手順は次のように拡張されます。

1. 証明書ストアに必要なホスト名を追加します(必要なホスト名がHOST.mycompany.comおよびVIP.mycompany.comと異なる場合)。

2. ノード・マネージャ(追加のホスト名がノード・マネージャで使用される場合)またはサーバー(追加のホスト名が管理対象サーバーで使用される場合)のアイデンティティ・ストアとトラスト・ストアの場所に関する情報を変更します。

次の手順に従って、HOSTに自己署名証明書を作成します。これらの証明書はネットワーク名または別名を使用して作成する必要があります。自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。次の例は、HOST.mycompany.comおよびVIP.mycompany.comの証明書を構成しています。すなわち、物理ホスト名(HOST)と仮想ホスト名(VIP)の両方がHOSTで使用されることを想定しています。また、HOST.mycompany.comはノード・マネージャが使用するアドレスであり、VIP.mycompany.comは管理対象サーバーまたは管理サーバーが使用するアドレスであることを想定しています。これは、管理サーバーとFusion Middlewareコンポーネントをホストするノードや、共存する2つの管理対象サーバーの一方が物理ホスト名をリスニングし、もう一方が仮想ホスト名を使用(移行サーバーを使用するサーバーの場合)するノードで、よく見られる状況です。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。Bourneシェルの場合、HOST上で次のコマンドを実行します。

cd WL_HOME/server/bin

. ./setWLSEnv.sh

CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

2. キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。各種目的(HTTPの起動用のSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、SOAHOST2では、SOAHOST1の証明書用に作成されたcertディレクトリを使用します。証明書用のユーザー定義ディレクトリを作成します。

mkdir cert

3. ディレクトリを今しがた作成したディレクトリに変更します。

cd cert

4. HOST上でユーザー定義ディレクトリからutils.CertGenツールを実行して、HOST. mycompany.comおよびVIP. mycompany.comの両方に対する証明書を作成します。
構文:

java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name [export | domestic] [Host_Name]

例:

java utils.CertGen welcome1 HOST.mycompany.com_cert HOST.mycompany.com_key domestic HOST.mycompany.com

java utils.CertGen welcome1 VIP.mycompany.com_cert VIP.mycompany.com_key domestic VIP.mycompany.com

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

次の手順に従って、HOSTにIDキーストアを作成します。

1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreという名前で新しいアイデンティティ・キーストアを作成します。このキーストアの作成場所は、証明書と同じディレクトリ(ORACLE_BASE/admin/domain_name/cert)とします。

注意:

utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートする際、アイデンティティ・ストアが1つも存在しない場合は、新しく作成されます。

2. HOST上で、HOST.mycompany.comおよびVIP.mycompany.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 welcome1 appIdentity1 welcome1 ORACLE_BASE/admin/domain_name/cert/HOST.mycompany.com_cert.pem ORACLE_BASE/admin/domain_name/cert/HOST.mycompany.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 appIdentity2 welcome1 ORACLE_BASE/admin/domain_name/cert/VIP.mycompany.com_cert.pem ORACLE_BASE/admin/domain_name/cert/VIP.mycompany.com_key.pem

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

次の手順に従って、HOSTにトラスト・キーストアを作成します。

1. 新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在するからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリの下にあるHOST上で標準JavaキーストアのCA証明書をその証明書と同じディレクトリにコピーします。たとえば、次のようになります。

cp WL_HOME/server/lib/cacerts ORACLE_BASE/admin/domain_name/cert/appTrustKeyStore.jks

2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは常に変更することをお薦めします。これを実行するには、HOST上でkeytoolユーティリティを使用します。構文は、次のとおりです。

keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password

例:

keytool -storepasswd -new welcome1 -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 welcome1

13.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に正しい値が使用されていることを確認します。これは、各ノードに個々に割り当てられたカスタム・アイデンティティの別名(たとえば、...HOST2など)に当たります。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/cert/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=welcome1
CustomIdentityAlias=appIdentity2
CustomIdentityPrivateKeyPassPhrase=welcome1

第13.4項「ノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。 セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化してください。

共通記憶域または共有記憶域のインストールをMW_HOMEに指定している場合、ノード・マネージャは同じ基本構成(nodemanager.properties)を使用してそれぞれのノードから起動します。この場合、バイナリを共有するすべてのノード用の証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加する必要があります。これを行うには、新しいノードの証明書を作成し、第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」に従って、それをappIdentityKeyStore.jksにインポートします。ストア内で証明書が利用可能になると、各ノード・マネージャは異なるアイデンティティの別名を指定し、正しい証明書を管理サーバーに送信する必要があります。これを実行するためには、HOST上で異なる環境変数を設定し、各ノードでノード・マネージャを起動します。

cd WL_HOME/server/bin

export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX

注意:

各ホストに個々に割り当てられているカスタム・アイデンティティの別名を指定してください。つまり、...HOST1にはappIdentity1、...HOST2にはappIdentity2を指定します。

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

次の手順に従って、WLS_SERVERのIDキーストアとトラスト・キーストアを構成します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 「サーバーのサマリー」ページで、アイデンティティ・キーストアとトラスト・キーストアを構成するサーバー名(WLS_SERVER)をクリックします。

6. 選択されたサーバーの設定ページで、「構成」を選択し、「キーストア」を選択します。

7. 「キーストア」フィールドの横にある「変更」をクリックして、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書を格納し管理するための「カスタムIDとカスタム信頼」方法を選択します。作業が終了したら、「保存」をクリックします。

8. 「ID」セクションで、IDキーストアの次の属性を定義します。

- カスタムIDキーストア: IDキーストアへの完全修飾パス。

ORACLE_BASE/admin/domain_name/cert/appIdentityKeyStore.jks

- カスタムIDキーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

- カスタムIDキーストアのパスフレーズ: 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。

9. 「 信頼 」セクションで、トラスト・キーストアのプロパティを定義します。

- カスタム信頼キーストア: トラスト・キーストアへの完全修飾パス。

ORACLE_BASE/admin/domain_name/cert/appTrustKeyStore.jks

- カスタム信頼キーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

- カスタム信頼キーストアのパスフレーズ: 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(New_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。

10. 「保存」をクリックします。

11. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

12. 「構成」をクリックし、「SSL」をクリックします。

13. 「ロックして編集」をクリックします。

14. 「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。

15. 「保存」をクリックします。

16. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

17. 変更を適用したサーバーを再起動します。

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

前述の手順を実行したら、変更を反映した管理対象サーバーのホスト名検証をBea Host Name Verifierに設定する必要があります。これには次の手順を実行します。

1. WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 「サーバーのサマリー」ページで、表の「名前」列にある管理対象サーバーを選択します。

5. サーバーの設定ページで「SSL」タブを開きます。

6. 表示されたページの「詳細」セクションを開きます。

7. 「ロックして編集」をクリックします。

8. ホスト名検証をBea Host Name Verifierに設定します。

9. 「保存」をクリックします。

10. 変更を適用したサーバーを再起動します。

13.4 ノード・マネージャの起動

次のコマンドを実行して、HOSTでノード・マネージャを起動します。ノード・マネージャが未構成で、まだ一度も起動していない場合は、第8.4.3項「SOAHOST1でのノード・マネージャの起動」で指定したsetNMProps.shスクリプトを実行し、管理対象サーバーの起動スクリプトの使用を有効化します。

注意:

各ホストに個々に割り当てられているカスタム・アイデンティティの別名を指定してください。つまり、...HOST1にはappIdentity1、...HOST2にはappIdentity2を指定します。

cd WL_HOME/server/bin

export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX

./startNodeManager.sh

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

この章では、エンタープライズ・デプロイメント用にサーバー移行を構成する手順を説明します。

この章は次の項で構成されています:

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

- 第14.2項「サーバー移行leasing表のユーザーと表領域の設定」

- 第14.3項「管理コンソールを使用したLeasingのGridLinkデータ・ソースの作成」

- 第14.4項「HOST1およびHOST2と管理サーバー間でのホスト名検証証明書の有効化」

- 第14.5項「ノード・マネージャのプロパティ・ファイルの編集」

- 第14.6項「wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定」

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

- 第14.8項「サーバー移行のテスト」

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

Oracle WebLogic Serverの管理対象サーバーではサーバー移行を構成できます。サーバー移行が構成された状態で障害が発生した場合は、各管理対象サーバーを別のホスト・マシン上で再起動できます。管理対象サーバーは、Oracle WebLogic Serverによってフェイルオーバーされた特定の浮動IPをリスニングします。

注意:

サーバー移行を使用するかどうかまたはサーバー移行が必要かどうかの詳細は、各コンポーネントの章を参照してください。

この章で説明される手順は、第2.1.1項「このガイドに記載されている参照用トポロジ」で概略を説明したエンタープライズ・デプロイメント・トポロジの各種コンポーネントで実行される必要があります。この章では、コンポーネント固有のアイテム間で識別するために変数を使用しています。

- WLS_SERVER1およびWLS_SERVER2は、エンタープライズ・デプロイメント・コンポーネントのOracle WebLogic Server管理対象サーバーを指します。

- HOST1およびHOST2は、エンタープライズ・デプロイメント・コンポーネントのホスト・マシンを指します。

- CLUSTERは、エンタープライズ・デプロイメント・コンポーネントと関連付けされたクラスタを指します。

これらの変数に使用する値は、このEDGのコンポーネント固有の章に記載されています。

このエンタープライズ・トポロジでは、WLS_SERVER1およびWLS_SERVER2の管理対象サーバーに対してサーバー移行を構成する必要があります。WLS_SERVER1の管理対象サーバーは、障害発生時にHOST2で再起動するように構成されています。WLS_SERVER2の管理対象サーバーは、障害発生時にHOST1で再起動するように構成されています。この構成では、WLS_SERVER1サーバーとWLS_SERVER2サーバーは、Oracle WebLogic Serverの移行によりフェイルオーバーされた特定の浮動IPアドレスをリスニングしています。

表14-1は、Oracle WebLogic Server管理対象サーバー用のサーバー移行を構成する手順を説明しています。

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

手順

説明

詳細

ユーザー、表領域および移行表を設定します。

Leasingという表領域、ユーザーおよびサーバー移行表を作成します。

第14.2項「サーバー移行leasing表のユーザーと表領域の設定」

Leasing表のGridLinkデータ・ソースを作成します。

Oracle RACデータベースの各インスタンスにデータ・ソースを作成するほか、管理コンソールでグローバルなLeasing GridLinkデータ・ソースを作成します。

第14.3項「管理コンソールを使用したLeasingのGridLinkデータ・ソースの作成」

ノード・マネージャのプロパティに、移行用の値を指定します。

各ホストでnodemanager.propertiesファイルのプロパティの値を編集し、その値を検証します。

第14.5項「ノード・マネージャのプロパティ・ファイルの編集」

環境を設定し、oracleユーザーにスーパー・ユーザー権限を指定します。

PATH環境変数にファイルを追加し、wlsifconfig.shスクリプトにsudo構成権限を付与します。

第14.6項「wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定」

クラスタの移行を構成します。

移行ターゲットとして利用可能なノードを割り当て、各サーバーに候補となるマシンを指定します。

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

サーバー移行のテストを実行します。

ノード・マネージャまたは管理コンソールからホスト間のサーバー移行を検証します。

第14.8項「サーバー移行のテスト」

14.2 サーバー移行leasing表のユーザーと表領域の設定

create tablespace Leasingコマンドを使用して、サーバー移行Leasing表のユーザーおよび表領域を設定します。

注意:

同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。その場合、データベースLeasing用のデータ・ソースおよびGridLinkデータ・ソースを再作成する必要はありませんが、サーバー移行用に構成されているクラスタを再度ターゲットに設定する必要があります。

サーバー移行Leasing表のユーザーと表領域を設定する手順は次のとおりです。

1. Leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace Leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

注意:

データベース・ファイルの場所は、データベースに使用されるストレージの種類とデータ・ファイルの場所によって異なります。

2. Leasingという名前のユーザーを作成し、Leasing表領域に割り当てます。

SQL> create user Leasing identified by welcome1;

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;

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

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.mycompany.com

- ホスト名とポート: 使用するRACデータベースのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の該当のパラメータを問い合せることによって特定できます。

SQL>show parameter remote_listener;

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string      db-scan.mycompany.com

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。次に例を示します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データソースの使用」を参照してください。

- ポート: データベース・サーバーが接続リクエストをリスニングするポート。

- データベース・ユーザー名: Leasing

- パスワード: welcome1など

- パスワードの確認: パスワードを再入力し、「次へ」をクリックします。

8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。接続に成功した場合の通知の例を次に示します。

Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.mycompany.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=wccedg.us.oracle.com))) succeeded.

「次へ」をクリックします。

9. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- データベースによって報告されるRACデータベースのSCANアドレスとONSリモート・ポート(次の例を参照)をここにも入力し、「追加」をクリックします。

[orcl@db-scan1 ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

- 「次へ」をクリックします。

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベースのONSサービスのホスト名とポートを使用します。次に例を示します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
接続に成功した場合の通知の例を次に示します。

Connection test for db-scan.mycompany.com:6200 succeeded.

「次へ」をクリックします。

11. 「ターゲットの選択」ページで「WCC_Cluster」をターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 「変更のアクティブ化」をクリックします。

14.4 HOST1およびHOST2と管理サーバー間でのホスト名検証証明書の有効化

ノード・マネージャと管理サーバー間でのホスト名検証に適切な証明書を作成します。この手順の詳細は、第13.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

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

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
...

注意:

サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

1. nodemanager.propertiesファイルで次のプロパティを設定します。

- StartScriptEnabled: このプロパティをtrueに設定します。これは、ノード・マネージャが起動スクリプトを使用して管理対象サーバーを起動するために必要です。

2. WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、HOST1およびHOST2のノード・マネージャを起動します。

注意:

共有記憶域のインストールからノード・マネージャを実行すると、同じnodemanager.propertiesファイルを使用して複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個別にパラメータを指定します。たとえば、HOSTnで別のインタフェース(eth3)を使用するには、Interface環境変数を次のように使用します。
export JAVA_OPTIONS=-DInterface=eth3
さらに、ノード・マネージャを起動する前に、この変数をシェルに設定しておきます。

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

4番目の手順では、(oracleユーザーに対して)wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。

1. 表14-2に一覧表示されているファイルがPATH環境変数に含まれていることを確認します。

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

ファイル

ディレクトリの場所

wlsifconfig.sh

ORACLE_BASE/admin/domain_name/mserver/domain_name/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スクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。

1. WebLogicユーザー(oracle)にパスワード制限のないsudo権限を付与し、さらにsbin/ifconfigと/sbin/arpingバイナリの実行権限を付与します。

2. WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。/etc/sudoers内の次のエントリ例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。

oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

注意:

この手順に必要なsudo権限とシステム権限についてはシステム管理者に問い合せてください。

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

5番目の手順は、サーバー移行ターゲットを構成することです。まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。次の手順に従って、クラスタ内の移行でクラスタ移行を構成します。

1. WebLogic Server管理コンソール(http://Host:Admin_Port/console)にログインします。通常、Admin_Portは7001(デフォルト)です。

2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。

3. 「クラスタのサマリー」ページで、表の「名前」列内から移行を構成するクラスタ(CLUSTER)をクリックします。

注意:

このドキュメントの手順では、Oracle SOA SuiteおよびImagingクラスタのサーバー移行を構成します。

4. 「移行」タブを開きます。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「HOST1」と「HOST2」を選択します。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、Leasingデータ・ソースを選択します。

8. 「保存」をクリックします。

9. 「変更のアクティブ化」をクリックします。

10. 「ロックして編集」をクリックします。

11. サーバー移行の候補となるマシンを設定します。この作業は、次の手順に従ってすべての管理対象サーバーで実行する必要があります。

1. WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。

2. 移行を構成するサーバーを選択します。

注意:

このドキュメントの手順では、Oracle SOA SuiteおよびImagingサーバーのサーバー移行を構成します。

3. 「移行」タブを開きます。

4. 「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。WLS_SERVER1には「HOST2」を選択します。WLS_SERVER2には「HOST1」を選択します。

5. 「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャはターゲット・ノード上で障害発生サーバーを自動的に起動できます。

6. 「保存」をクリックします。

7. 「変更のアクティブ化」をクリックします。

8. 管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。

14.8 サーバー移行のテスト

6番目と最後の手順として、サーバー移行のテストを実行します。サーバー移行が適切に機能していることを確認する手順は次のとおりです。

HOST1から:

1. WLS_SERVER1管理対象サーバーを停止します。これには、HOST1で次のコマンドを実行します。

kill -9 pid

pidは、その管理対象サーバーのプロセスID(PID)を指定します。次のコマンドを実行すると、ノードのPIDを識別できます。

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でsoa-infraコンソールにアクセスします。

管理コンソールからの確認

移行は管理コンソールで確認することもできます。

1. 管理コンソールにログインします。

2. 左のコンソールで「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます(図10-1)。

図14-1 管理コンソールの「移行の状態」画面

「図14-1 管理コンソールの「移行の状態」画面」の説明

注意:

サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

15 Oracle Identity Managementとの統合

この章では、Oracle WebCenter ContentをOracle Identity Managementと統合する方法について説明します。この章には次の項目があります。

- 第15.1項「Oracle Identity Managementとの統合の概要」

- 第15.2項「資格証明ストアおよびポリシー・ストアの構成」

- 第15.3項「Oracle Access Manager 10gの統合」

- 第15.4項「Oracle Access Manager 11gの統合」

- 第15.5項「Oracle HTTP ServerおよびSSOを使用したアクセスの検証」

- 第15.6項「インストールのバックアップ」

15.1 Oracle Identity Managementとの統合の概要

Oracle Fusion Middlewareエンタープライズ・デプロイメントをOracle Identity Manager 10gまたは11gと統合できます。次の項では、資格証明ストアとポリシー・ストアの初回時の構成方法およびその資格証明ストアとポリシー・ストアを再関連付けしてOracle Identity Manager 10gまたは11gと統合する方法について説明します。

表15-1は、Oracle Identity Manager 10gをOracle WebCenter Contentエンタープライズ・デプロイメントに統合するための大まかな手順を示しています。

表15-2は、Oracle Identity Manager 11gをOracle WebCenter Contentエンタープライズ・デプロイメントに統合するための大まかな手順を示しています。

注意:

Oracle Identity Managementとの統合時には、Oracle Identity Managementサーバーで現在使用されているトランスポート・モードを使用します。たとえば、オープン、簡易、証明書などです。

表15-1 Oracle Identity Manager 10gとの統合手順

手順

説明

詳細

資格証明ストアの構成

Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成します。

第15.2項「資格証明ストアおよびポリシー・ストアの構成」

ポリシー・ストアの構成

Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成します。

第15.2.3項「ポリシー・ストアの構成」

OAM構成ツールの実行

OAM構成ツール(oamcfg)は、一連のスクリプトを起動して必要なポリシーを設定します。

第15.3.3.2項「OAM構成ツールの実行」

Webゲートのインストールと構成

各WEBHOSTnマシンにWebゲートをインストールし、Web層を保護します。

第15.3.4項「Webゲートのインストールと構成」

WebGateのIP検証の構成

アクセス・システム・コンソールを使用して、WebGateのIP検証を構成します。

第15.3.5項「EDG WebGateのIP検証の構成」

WebLogic認証プロバイダの設定

構成ファイルのバックアップ、Oracle Access Manager IDアサータの設定およびプロバイダの順序設定によって、WebLogic認証プロバイダを設定します。

第15.3.6項「WebLogic認証プロバイダの設定」

表15-2 Oracle Identity Manager 11gとの統合手順

手順

説明

詳細

資格証明ストアの構成

Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成します。

第15.2項「資格証明ストアおよびポリシー・ストアの構成」

ポリシー・ストアの構成

Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成します。

第15.2.3項「ポリシー・ストアの構成」

WebGateのインストール

HTTPサーバーがすでにインストールされている各WEBHOSTマシンにWebGateをインストールします。

第15.3.4項「Webゲートのインストールと構成」

WebGateエージェントの登録

RREGツールを使用したWebGateエージェントの登録

第15.4.4項「WebGateエージェントの登録」

WebLogic認証プロバイダの設定

構成ファイルのバックアップ、Oracle Access Manager IDアサータの設定およびプロバイダの順序設定によって、WebLogic認証プロバイダを設定します。

第15.3.6項「WebLogic認証プロバイダの設定」

15.2 資格証明ストアおよびポリシー・ストアの構成

次の各項では、資格証明ストアおよびポリシー・ストアの構成について詳細に説明します。

- 第15.2.1項「資格証明ストアとポリシー・ストアの構成の概要」

- 第15.2.2項「資格証明ストアの構成」

- 第15.2.3項「ポリシー・ストアの構成」

- 第15.2.4項「資格証明およびポリシーの再関連付け」

15.2.1 資格証明ストアとポリシー・ストアの構成の概要

Oracle Fusion Middlewareでは、WebLogicドメインで異なるタイプの資格証明ストアおよびポリシー・ストアを使用できます。ドメインでは、XMLファイルに基づくストアまたは様々なタイプのLDAPプロバイダに基づくストアを使用できます。ドメインでLDAPストアを使用する場合は、すべてのポリシー・データと資格証明データが、一元化されたストアで保持および管理されます。ただし、XMLポリシー・ストアを使用している場合、管理対象サーバーへの変更は、同じドメイン・ホームを使用していなければ管理サーバーには伝播されません。Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジでは、管理サーバーと管理対象サーバーに異なるドメイン・ホームを使用するため、整合性と一貫性を保持する目的で、LDAPストアをポリシー・ストアおよび資格証明ストアとして使用する必要があります。デフォルトでは、Oracle WebLogic Serverドメインは、ポリシー・ストアにXMLファイルを使用します。次の項では、資格証明またはポリシー用に、デフォルト・ストアをOracle Internet Directory LDAPに変更するために必要な手順について説明します。

注意:

ポリシー・ストアと資格証明ストアのバックエンド・リポジトリは、同じ種類のLDAPサーバーを使用する必要があります。こうした一貫性を保持するために、一方のストアを再関連付けすると、他方のストアも再関連付けされることに注意してください。すなわち、Fusion Middleware ControlまたはWLSTコマンドのreassociateSecurityStoreを使用して、資格証明ストアとポリシー・ストアの再関連付けが1つの単位として実行されます。詳細は、第15.2.4項「資格証明およびポリシーの再関連付け」を参照してください。

15.2.2 資格証明ストアの構成

資格証明ストアは、セキュリティ・データ(資格証明)のリポジトリです。資格証明には、ユーザー名とパスワードの組合せ、チケットまたは公開鍵証明書を保持できます。資格証明は、プリンシパルをサブジェクトに移入する際の認証時、さらにはサブジェクトが実行できるアクションを決定する際の認可時に使用されます。この項では、Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成する手順について説明します。資格証明ストアの構成の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』の「資格証明ストアの構成」を参照してください。

次の各項では、資格証明ストアの構成について説明します。

- 第15.2.2.1項「LDAP認証プロバイダの作成」

- 第15.2.2.2「WebLogic管理者のLDAPへの移行」

- 第15.2.2.3項「ドメインの資格証明ストアの再関連付け」

15.2.2.1 LDAP認証プロバイダの作成

安全のため、LDAP認証プロバイダを作成する前に、次の関連する構成ファイルをバックアップしておく必要があります。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/system-jazn-data.xml

管理サーバーのboot.propertiesファイルもバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security/boot.properties

次の手順に従って、適切な認証プロバイダを設定します。

1. WebLogicサーバーの管理コンソールにログインします。

2. 左のナビゲーション・バーにある「セキュリティ・レルム」リンクをクリックします。

3. myrealmデフォルト・レルム・エントリをクリックして構成します。

4. このレルムにある「プロバイダ」タブを開きます。

5. このレルム用に構成したDefaultAuthenticatorプロバイダがあることを確認します。

6. 「ロックして編集」をクリックします。

7. 「新規」ボタンをクリックし、新しいプロバイダを追加します。

8. Oracle Internet Directoryを使用する場合はOIDAuthenticator、Oracle Virtual Directoryを使用する場合はOVDAuthenticatorのように、プロバイダの名前を入力します。

9. Oracle Internet Directoryを使用する場合は「OracleInternetDirectoryAuthenticator」タイプ、Oracle Virtual Directoryを使用する場合は「OracleVirtualDirectoryAuthenticator」タイプを、認証プロバイダのリストから選択します。

10. 「OK」をクリックします。

11. 「プロバイダ」画面で、新しく作成した認証プロバイダをクリックします。

12. 「制御フラグ」を「SUFFICIENT」に設定します。このフラグは、この認証プロバイダによって正常に認証されたユーザーは、その認証を受け入れたうえで、他の認証プロバイダを呼び出さないようにすることを示しています。認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。移行のすべての認証プロバイダの制御フラグも「SUFFICIENT」に設定されていることを確認してください。特に「DefaultAuthenticator」を確認し、その制御フラグを「SUFFICIENT」に設定します。

13. 「保存」をクリックしてこの設定を保存します。

14. 「プロバイダ固有」タブを開き、LDAPサーバーの詳細情報を入力します。

15. 次の表に示すように、使用しているLDAPサーバーに固有の詳細情報を入力します。

パラメータ

値

値の説明

ホスト

例: oid.mycompany.com

LDAPサーバーのサーバーID。

ポート

例: 636

LDAPサーバーのポート番号。

プリンシパル

例: cn=orcladmin

LDAPサーバーへの接続に使用されるLDAPユーザーのDN。

資格証明

なし

LDAPサーバーへの接続に使用されるパスワード。

SSL有効

チェック済

LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。

ユーザー・ベースDN

例: cn=users,dc=us,dc=mycompany,dc=com

ユーザーが開始時に使用するDNを指定します。

グループ・ベースDN

例: cn=groups,dc=us,dc=mycompany,dc=com

グループ・ノードを指すDNを指定します。

取得したユーザー名をプリンシパルとして使用する

チェック済

オンにする必要があります。

「保存」をクリックします。

16. 「変更のアクティブ化」をクリックして、変更を伝播します。

15.2.2.1.1 プロバイダの順序の設定

OID/OVD認証プロバイダおよびデフォルト認証プロバイダを並べ替えて、それぞれの認証プロバイダの制御フラグが次のように設定されていることを確認します。

- OID LDAP認証プロバイダ: SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

プロバイダの順序を設定する手順は次のとおりです。

1. WebLogic Server管理コンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. OID/OVD認証プロバイダおよびデフォルト認証プロバイダの制御フラグが次のように設定されていることを確認し、これらの認証プロバイダを並べ替えます。

- OID LDAP認証プロバイダ(またはOVD LDAP認証プロバイダ): SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

5. 「OK」をクリックします。

6. 「変更のアクティブ化」をクリックして、変更を伝播します。

7. 管理サーバーとすべての管理対象サーバーを再起動します。

15.2.2.2 WebLogic管理者のLDAPへの移行

この項では、Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジでOracle WebCenter ContentのWebLogicドメインを管理するための、新規の管理ユーザーおよび管理グループのプロビジョニングの詳細について説明します。この項で説明するタスクは次のとおりです。

- 第15.2.2.2.1項「LDAPディレクトリへの管理ユーザーおよび管理グループのプロビジョニング」

- 第15.2.2.2.2項「管理ロールの管理グループへの割当て」

- 第15.2.2.2.3項「boot.propertiesファイルの更新およびシステムの再起動」

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

この項の冒頭で述べたように、複数のWebLogic Serverドメインのユーザーおよびグループは、中央のLDAPユーザー・ストアにプロビジョニングできます。そのような場合、あるWebLogic Server管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。このような状況は好ましくありません。このような状況にならないようにするために、プロビジョニングされるユーザーおよびグループには、ディレクトリ・ツリー内で一意の識別名を付与しておく必要があります。このガイドでは、WebCenter Content WebLogic Serverドメインの管理ユーザーおよび管理グループを、次のDNでプロビジョニングします。

- 管理ユーザーDN:

cn=weblogic_ecm,cn=Users,dc=us,dc=mycompany,dc=com

- 管理グループDN:

cn=ECM Administrators,cn=Groups,dc=us,dc=mycompany,dc=com

次の手順に従って、Oracle Internet Directoryに管理ユーザーおよび管理グループをプロビジョニングします。

1. 使用しているOracle Access Managerのバージョンに従い、次に示すコンテンツを使用してadmin_user.ldifという名前のLDIFファイルを作成し、そのファイルを保存します。

- Oracle Access Manager 10g:

dn: cn=weblogic_ecm, cn=Users, dc=us, dc=mycompany, dc=com
orclsamaccountname: weblogic_ecm
givenname: weblogic_ecm
sn: weblogic_ecm
userpassword: Welcome1
obver: 10.1.4.0
mail: weblogic_ecm
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
objectclass: oblixorgperson
uid: weblogic_ecm
cn: weblogic_ecm
description: Admin User for the Oracle WebCenter Content Domain

- Oracle Access Manager 11g:

dn: cn=weblogic_ecm, cn=Users, dc=us, dc=mycompany, dc=com
orclsamaccountname: weblogic_ecm
givenname: weblogic_ecm
sn: weblogic_ecm
userpassword: Welcome1
obver: 10.1.4.0
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_HOMEは、Oracle Internet DirectoryがあるIdentity ManagementインストールのORACLE_HOMEです。

次に例を示します。

ORACLE_HOME/bin/ldapadd -h oid.mycompany.com -p 389 -D cn="orcladmin" -w welcome1 -c -v -f admin_user.ldif

3. 次に示す内容を指定してadmin_group.ldifという名前のldifファイルを作成し、保存します。

dn: cn=ECM Administrators, cn=Groups, dc=us, dc=mycompany, dc=com
displayname: ECM Administrators
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_ecm, cn=users, dc=us, dc=mycompany, 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内のグループをプロビジョニングします。

ORACLE_HOME/bin/ldapadd -h oid.mycompany.com -p 389 -D cn="orcladmin" -w welcome1 -c -v -f admin_group.ldif

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

Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内で、グループに管理ロールを割り当てる必要があります。これにより、そのグループに属するすべてのユーザーをそのドメインの管理者にできます。次の手順に従って、管理グループに管理ロールを割り当てます。

1. WebLogic管理サーバー・コンソールにログインします。

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 Server管理コンソールを開き、変更が正しく行われたことを確認します。weblogic_ecmユーザーの資格証明を使用してログインします。

注意:

Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジの各Oracleアプリケーションには、あらかじめ定義されたロールや管理目的および監視目的で定義されたグループが存在する可能性があります。デフォルトでは、Administratorsグループでこれらの作業ができるようになっています。ただし、このグループは広範になりすぎている可能性もあります。たとえば、Oracle SOA、Oracle WebCenter ContentおよびOracle WebCenter Content: Imagingが稼働しているOracle WebLogic Serverドメインの管理者がSOAの管理者を兼務するのは、望ましくないとも考えられます。そのため、この項で提案しているとおり、ECM Administratorsなどのより詳細なグループを作成することが望ましいと思われます。様々なアプリケーションでECM Administratorsグループが各種のシステムを管理できるようにするには、そのグループに必要なロールを追加する必要があります。たとえば、SOA Worklistappの管理のためには、SOAAdminロールを追加します。それぞれのケースで必要なロールについては、各コンポーネントの固有のロールを参照してください。

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

管理サーバーのboot.propertiesファイルは、Oracle Internet Directoryで作成されたWebLogic管理ユーザーで更新する必要があります。次の手順に従って、boot.propertiesファイルを更新します。

1. SOAHOST1で、次のディレクトリに移動します。

cd ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security

2. 既存の boot.properties ファイルの名前を変更します。

mv boot.properties boot.properties.backup

3. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

username=weblogic_ecm
password=welcome1

4. ファイルを保存します。

5. 次のコマンドを使用して、管理サーバーを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

6. 管理サーバーは、第8.4.4項「SOAHOST1での管理サーバーの起動」の手順で起動します。

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

資格証明ストアとポリシー・ストアの再関連付けは、Fusion Middleware ControlまたはWLSTのコマンドreassociateSecurityStoreを使用し、1つの単位として実行されます。詳細な手順は、第15.2.4項「資格証明およびポリシーの再関連付け」を参照してください。

15.2.3 ポリシー・ストアの構成

ドメイン・ポリシー・ストアは、システム固有のポリシーおよびアプリケーション固有のポリシーのリポジトリです。あるドメインには、そのドメインにデプロイされたすべてのアプリケーションで使用できるポリシーがすべて格納されたストアが1つあります。この項では、Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成する手順について説明します。ポリシー・ストアの構成の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』の「OPSSの認可とポリシー・ストア」を参照してください。

15.2.3.1 LDAPベースのポリシー・ストアを使用するための前提条件

ポリシー・ストアとして使用されるLDAPサーバー・ディレクトリ(Oracle Internet Directory)に正しくアクセスできるようにするには、サーバー・ディレクトリにノードを設定する必要があります。

Oracle Internet Directoryの管理者は、次の手順に従って、Oracle Internet Directory Serverに適切なノードを作成する必要があります。

1. 次のDNエントリおよびCNエントリを指定して、LDIFファイル(この例ではjpstestnode.ldifと想定)を作成します。

dn: cn=jpsroot_ecm
cn: jpsroot_ecm
objectclass: top
objectclass: OrclContainer

ルート・ノードの識別名(前述の文字列jpsroot_ecm)は、他の識別名と異なっている必要があります。1つのルート・ノードを複数のWebLogic Serverドメインで共有できます。サブツリーに対する読取りアクセス権および書込みアクセス権がOracle Internet Directory管理者に付与されていれば、このノードを最上位レベルに作成する必要はありません。

2. 次の例で示すとおり、OIDサーバー上のldapaddコマンドを使用してOracle Internet Directoryサーバーにこのデータをインポートします。

ORACLE_HOME/bin/ldapadd -h ldap_host -p ldap_port -D cn=orcladmin -w password -c -v -f jpstestnode.ldif

3. 次の例に示すとおり、Oracle Internet Directoryサーバー上でldapsearchコマンドを使用してノードが正常に挿入されたことを確認します。

ORACLE_HOME/bin/ldapsearch -h ldap_host -p ldap_port -D cn=orcladmin -w password -b "cn=jpsroot_ecm" objectclass="orclContainer"

4. Oracle Internet DirectoryをLDAPベースのポリシー・ストアとして使用する場合は、ユーティリティoidstats.sqlをINFRADBHOSTサーバーで実行し、最適なデータベース・パフォーマンスを実現するためのデータベース統計を生成します。

ORACLE_HOME/bin/sqlplus

ユーザー名にODSを入力します。ODSユーザーの資格証明を入力するよう求められます。SQL*Plus内では次のコマンドを入力して、統計情報を収集します。

@ORACLE_HOME/ldap/admin/oidstats.sql

oidstats.sqlユーティリティは、初回のプロビジョニングの後で1回のみ実行する必要があります。このユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』を参照してください。

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

ポリシー・ストアを再関連付けするには、ファイルベースまたはLDAPベースのリポジトリからLDAPベースのリポジトリにポリシー・データを移行します。つまり、再関連付けでは、格納されているデータの整合性を保持した状態でリポジトリを変更します。再関連付けでは、ソース・ポリシー・ストア内の各ポリシーに対するターゲットLDAPディレクトリが検索され、ディレクトリが検出されると、対応するポリシーが適宜更新されます。何も見つからない場合は、ポリシーがそのまま移行されるだけです。

ドメイン・ポリシー・ストアをインスタンス化した後はいつでも、ファイルベースまたはLDAPベースのポリシー・ストアを、同じデータを格納しているLDAPベースのポリシー・ストアに再関連付けできます。これをサポートするには、必要に応じてLDAPポリシー・ストアを使用するようにドメインを構成する必要があります。

資格証明ストアとポリシー・ストアの両方の再関連付けは、Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTのコマンドreassociateSecurityStoreを使用して、1つの単位として実行されます。詳細な手順は、第15.2.4項「資格証明およびポリシーの再関連付け」を参照してください。

15.2.4 資格証明とポリシーの再関連付け

ポリシー・ストアおよび資格証明ストアをOracle Internet Directoryに再関連付けするには、WLSTのreassociateSecurityStoreコマンドを使用します。実行する手順は次のとおりです。

1. SOAHOST1からwlstシェルを起動します。

cd ORACLE_COMMON_HOME/common/bin

./wlst.sh

2. 次のようにwlst connectコマンドを使用して、WebLogic管理サーバーに接続します。
構文:

connect("Admin_User","Admin_User_Password","t3://hostname:port")

次に例を示します。

connect("weblogic","welcome1","t3://ADMINVHN:7001")

3. 次のようにreassociateSecurityStoreコマンドを実行します。
構文:

reassociateSecurityStore(domain="domain_name",admin="cn=orcladmin",
password="orclPassword",ldapurl="ldap://LDAP_HOST:LDAP_PORT",servertype="OID",
jpsroot="cn=jpsroot_ecm")

例:

wls:/domain_name/serverConfig>reassociateSecurityStore(domain="domain_name", admin="cn=orcladmin",password="welcome1",ldapurl="ldap://oid.mycompany.com:389",servertype="OID",jpsroot="cn=jpsroot_ecm")

このコマンドの出力は次のようになります。

{servertype=OID,jpsroot_ecm=cn=jpsroot_ecm_idm_idmhost1,admin=cn=orcladmin,
domain=IDMDomain,ldapurl=ldap://oid.mycompany.com:389,password=welcome1}
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

Starting Policy Store reassociation.
LDAP server and ServiceConfigurator setup done.

Schema is seeded into LDAP server
Data is migrated to LDAP server
Service in the server after migration has been tested to be available
Update of jps configuration is done
Policy Store reassociation done.
Starting credential Store reassociation
LDAP server and ServiceConfigurator setup done.
Schema is seeded into LDAP server
Data is migrated to LDAP server
Service in LDAP server after migration has been tested to be available
Update of jps configuration is done
Credential Store reassociation done
Starting keystore reassociation
The server and ServiceConfigurator setup done.
Schema is seeded into the server
Data is migrated to the server
Service in the server after migration has been tested to be available
Update of jps configuration is done
keystore reassociation done
Jps Configuration has been changed. Please restart the server.

4. コマンドが正しく実行されたら、管理サーバーを再起動します。
管理サーバーを再起動するには、第8.4.4項「SOAHOST1での管理サーバーの起動」の手順を使用します。

注意:

資格証明およびポリシーの変更を有効にするには、ドメインのサーバーを再起動する必要があります。

15.2.4.1 Oracle Internet Directoryの属性のカタログ化

検索フィルタで使用するOracle Internet Directoryの属性には、索引を付ける必要があります。索引付けは、パフォーマンス向上のために使用するオプションの手順です。このOIDでまだ実行していない場合は、catalogツールを使用して属性に索引を付けます。

catalog connect="orcl" add=true attribute="orclrolescope" verbose="true"

オプションで、属性名を次のようにファイルに入力して、バッチで処理することもできます。

orclrolescope
orclassignedroles
orclApplicationCommonName
orclAppFullName
orclCSFAlias
orclCSFKey
orclCSFName
orclCSFDBUrl
orclCSFDBPort
orclCSFCredentialType
orclCSFExpiryTime
modifytimestamp
createtimestamp
orcljpsassignee

OID属性の索引付けの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』を参照してください。

15.3 Oracle Access Manager 10g統合

この項では、Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのシングル・サインオン・ソリューションとしてOracle Access Manager 10gを設定する方法について説明します。この章には次の項目があります。

- 第15.3.1項「Oracle Access Managerの統合の概要」

- 第15.3.2項「Oracle Access Managerの前提条件」

- 第15.3.3項「Oracle Access Managerの構成」

- 第15.3.4項「Webゲートのインストールと構成」

- 第15.3.5項「EDG WebGateのIP検証の構成」

- 第15.3.6項「WebLogic認証プロバイダの設定」

15.3.1 Oracle Access Manager統合の概要

Oracle Access Managerは、Oracle Fusion Middleware 11gリリース1で推奨されるシングル・サインオン(SSO)ソリューションです。Oracle Access Managerインストールのインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。この項では、既存のOracle Access Manager 10gインストールおよびその基礎となるディレクトリ・サービスを使用してOracle WebCenter Contentのインストールを構成する手順について説明します。Oracle Internet DirectoryまたはOracle Virtual Directoryのいずれか、あるいは両方のディレクトリ・サービスを使用することをお薦めします。

注意:

このガイドに記載されているOracle WebCenter Contentエンタープライズ・デプロイメント・トポロジでは、Oracle WebCenter Contentシステムおよびシングル・サインオン・システムの両方が同じネットワーク・ドメイン(mycompany.com)に存在する状態で、シングル・サインオン構成を使用します。マルチ・ドメイン構成については、『Oracle Access Managerアクセス管理ガイド』のシングル・サインオン構成に関する項に記載されている、必須の構成手順を参照してください。

15.3.2 Oracle Access Managerの前提条件

Oracle Access Managerの設定では、既存のOracle Access Manager 10gインストールにAccess Managerおよびポリシー・マネージャを保護するポリシーが完備されていることを前提とします。Oracle Access Managerインストールのインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。この設定には、スタンドアロンのOracle Internet DirectoryまたはOracle Virtual Directory構成の一部としてのOracle Internet Directoryのいずれかのディレクトリ・サービスが含まれています。この項では、Oracle Internet DirectoryとOracle Virtual Directoryのいずれかでエンタープライズ・デプロイメントを構成するために必要な手順について説明します。

また、Oracle Access Managerインストールには、Webゲートを使用するように構成された独自のWebサーバーが必要です。この項では、Oracle Access Manager Webサーバーを委任認証サーバーとして使用するための手順も説明します。

15.3.3 Oracle Access Managerの構成

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

- 第15.3.3.1項「OAM構成ツールで使用する情報の収集」

- 第15.3.3.2項「OAM構成ツールの実行」

- 第15.3.3.3項「Oracle Access Managerのログアウトのガイドライン」

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

- 第15.3.3.5項「Cookieを使用しない基本認証スキームが適切に割り当てられていることの確認」

- 第15.3.3.6項「ホスト識別子の更新」

- 第15.3.3.7項「Webゲート・プロファイルの更新」

- 第15.3.3.8項「アクセス・サーバーの追加」

- 第15.3.3.9項「委任フォーム認証の構成」

15.3.3.1 OAM構成ツールで使用する情報の収集

OAM構成ツール(oamcfg)は、一連のスクリプトを起動してOracle Access Managerに必要なポリシーを設定します。そのためには、入力情報として様々なパラメータが必要となります。具体的には次の項目が作成されます。

1. Oracle Access Managerのフォーム認証スキーム

2. Oracle WebLogic Serverでの認証を可能にするポリシー

3. Oracle HTTP ServerのWebゲートが(Web層から)構成済アプリケーションを保護できるようにするOracle Access ManagerのWebゲート・エントリ

4. 選択したシナリオに応じたホスト識別子(指定しない場合はデフォルトのホスト識別子が使用されます)

5. 選択したシナリオに応じたホスト識別子(指定しない場合はデフォルトのホスト識別子が使用されます)

6. アプリケーション固有のURLを保護するポリシーおよび保護対象としないポリシー

OAM構成ツールを実行するために収集または事前に準備する情報は次のとおりです。

1. パスワード: セキュアなパスワードを作成します。このパスワードは、この後に作成するWebGateインストールのパスワードとして使用します。

2. LDAPホスト名: ディレクトリ・サーバーのホスト名またはロード・バランサのアドレス(高可用性またはエンタープライズ・デプロイメントの構成の場合)。

3. LDAPポート: ディレクトリ・サーバーのポート。

4. LDAPユーザーのDN: LDAP管理ユーザーのDN。これは、cn=orcladminなどの値になります。

5. LDAPパスワード: LDAP管理ユーザーのパスワード。

6. oam_aaa_host: Oracle Access Managerのホスト名。

7. oam_aaa_port: Oracle Access Managerのポート。

15.3.3.2 OAM構成ツールの実行

OAM構成ツールを実行する前に、Oracle WebCenter ContentコンポーネントのOracle Access Manager 10gに必要なリソースを追加する必要があります。次のコンテンツを使用して保護が必要なURIのリストを含むファイルを作成します。

#########################################
#Product Name: Oracle WebCenter Content
#########################################
#########################################
protected_uris
#########################################
/adfAuthentication
/imaging/faces
/em
/console
/DefaultToDoTaskFlow
/sdpmessaging/userprefs-ui
/integration/worklistapp
/workflow/sdpmessagingsca-ui-worklist
/soa/composer
/soa-infra/deployer
/soa-infra/events/edn-db-log
/soa-infra/cluster/info

#"Policy using Basic Authn Scheme" is the name of the policy
#"Basic Over LDAP" is the authentication scheme configured for this #policy
# Note that the name of the policy and the scheme name in the URIs file
# is tab-separated. In other words, there must be a tab between
# "Basic Authn Scheme" and "OraDefaultBasicAuthNScheme" below.
Policy using Basic Authn Scheme OraDefaultBasicAuthNScheme
/inspection.wsil

#########################################
public_uris
#########################################

/soa-infra/services
/soa-infra/directWSDL

注意:

Oracle Access Manager 10gでは、URL接頭辞に含まれるすべてのリソースは、ポリシーを使用したより個別性の高いルールが適用されている場合を除いて、ポリシー・ドメインのデフォルト・ルールによって保護されます。より専門的な保護パターンを使用する必要がある場合に使用できる別パターンの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

OAM構成ツールは、ORACLE_COMMON_HOME/modules/oracle.oamprovider_11.1.1ディレクトリ(ORACLE_COMMON_HOMEはOAM構成ツールを実行するマシンにより異なる)にあります。このツールは、必要なインストール・ファイルがあればすべてのマシンから実行できます。ここではWCCHOST1から実行します。次のとおりに(すべて1行のコマンド・ラインで)、Oracle Access Manager 10g登録用のOAM構成ツールを実行してください。

MW_HOME/jrockit_160_version/bin/java -jar oamcfgtool.jar mode=CREATE
app_domain="ECM_EDG"
uris_file="full_path_to_file_containing_uri_definitions"
app_agent_password=password_to_be_provisioned_for_App_Agent
ldap_host=OID.MYCOMPANY.COM
ldap_port=389
ldap_userdn="cn=orcladmin"
ldap_userpassword=Password_of_LDAP_admin_user
oam_aaa_host=OAMHOST1
oam_aaa_port=OAMPORT1

コマンドが正常に実行された場合、次のような出力が得られます。

Date,Time oracle.security.oam.oamcfg.OAMCfgGlobalConfigHandler constructGlobalConfig
INFO: Processed input parameters
May 9, 2011 5:09:40 AM oracle.security.oam.oamcfg.OAMCfgGlobalConfigHandler constructGlobalConfig
INFO: Initialized Global Configuration
Date,Time oracle.security.oam.oamcfg.create.impl.OAMCfgConfigCreator doCreate
INFO: Successfully completed the Create operation.
Date,Time oracle.security.oam.oamcfg.create.impl.OAMCfgConfigCreator doCreate
INFO:  Operation Summary:
Date,Time oracle.security.oam.oamcfg.create.impl.OAMCfgConfigCreator doCreate
INFO:      Policy Domain  : ECM_EDG
Date,Time oracle.security.oam.oamcfg.create.impl.OAMCfgConfigCreator doCreate
INFO:      Host Identifier: ECM_EDG
Date,Time oracle.security.oam.oamcfg.create.impl.OAMCfgConfigCreator doCreate
INFO:      Access Gate ID : ECM_EDG_AG

15.3.3.3 Oracle Access Managerのログアウトのガイドライン

Oracle Access Managerのログアウトのガイドラインに準拠するために、Oracle WebCenter ContentおよびOracle WebCenter Content: Imagingによって実行されるアプリケーション(特に、/adfAuthentication?logout=true&end_url=some_URIを使用してログアウトを実行するアプリケーション)では、Oracle Access Manager 10g環境との統合に、Webゲート上でend_urlを処理する追加構成が必要になります。この構成を追加しない場合、ログアウトしても、Oracle Access Manager 10gのWebゲートでend_urlが処理されないので、終了URLへのリダイレクトが行われません。構成手順の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。

Oracle WebCenter ContentとOracle Access Manager 10gを統合する際には、URL /oamsso/logout.htmlをアクセス・ゲートのログアウトURL設定に追加して、シングル・サインオン・ログアウトが適切に動作するようにします。詳細は、『Oracle Access Managerアクセス管理ガイド』のシングル・サインオン・ログアウトURLの構成に関する項およびアクセス・ゲート構成のパラメータに関する項を参照してください。

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

ポリシー・ドメインの確認

ポリシー・ドメインを検証する手順は次のとおりです。

1. Oracle Access Managerにログインします。

http://OAMADMINHOST:port/access/oblix/

2. 「ポリシー・マネージャ」をクリックします。

3. 左側のパネルで「ポリシー・ドメイン」リンクをクリックします。先ほど作成したドメインを含むすべてのポリシー・ドメインのリストが表示されます。その接尾辞は_PD(たとえば、ECM_EDG_PD)となります。3番目の列（「URL接頭辞」）には、このドメインの作成時に指定したURIも表示されます。

4. 作成したポリシー・ドメインへのリンクをクリックすると、このドメインの「一般」領域が表示されます。

5. 「リソース」タブを開くと、指定したURIが表示されます。他のタブをクリックし、他の設定を表示することもできます。

アクセス・ゲート構成の確認

AccessGate構成を検証する手順は次のとおりです。

1. 右上にある「アクセス・システム・コンソール」リンクをクリックします(これはトグルのように動作するので、クリックした後は「ポリシー・マネージャ」リンクになります)。

2. 「アクセス・システム構成」タブを開きます。

3. 左のパネルにある「アクセス・ゲート構成」リンクをクリックします。

4. 検索条件にECM_EDGと入力(または、第15.3.3.2項「OAM構成ツールの実行」でapp_domain名として使用したその他のサブストリングを入力)し、「実行」をクリックします。

5. 作成したドメインのアクセス・ゲート(ECM_EDG_AGなど、接尾辞に_AGが付されています)が表示された場合は、それをクリックすることで、作成したアクセス・ゲートの詳細を参照できます。

15.3.3.5 Cookieを使用しない基本認証スキームが適切に割り当てられていることの確認

Cookieを使用しない基本認証スキームが適切に割り当てられていることを確認する手順は次のとおりです。

1. Oracle Access Managerにログインします。

http://OAMADMINHOST:port/access/oblix/

2. 「ポリシー・マネージャ」をクリックします。

3. 左側のパネルで「ポリシー・ドメイン」リンクをクリックします。作成したポリシー・ドメインのリストが表示されます。

4. 「ECM_EDG」をクリックします。

5. ポリシータブを開いて、Policy using Basic Authn Schemeをクリックします。

6. 一般セクションを開きます。
inspection.wsilリソースがリストされる必要があります。

7. 認証ルールセクションを開きます。
OraDefaultBasicAuthNScheme認証スキームがリストされる必要があります。

15.3.3.6 ホスト識別子の更新

OAM構成ツールは、app_domainパラメータの値を使用してポリシー・ドメインのホスト識別子を作成します。構成が正常に機能するためには、ホストに対するすべてのホスト名バリエーションを反映してホスト識別子を更新する必要があります。

OAM構成ツールで作成したホスト識別子を更新する手順は次のとおりです。

1. Webブラウザで次のURLを指定し、アクセス・システム・コンソールに移動します。

http://host_name:port/access/oblix

host_nameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. ユーザー名とパスワードの入力が要求されたら、管理者としてログインします。「OK」をクリックします。

3. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックします。

4. 「アクセス・システム・コンソール」ページで、「アクセス・システム構成」タブを開きます。

5. 「アクセス・システム構成」ページで、左下にある「ホスト識別子」をクリックします。

6. 「すべてのホスト識別子をリスト」ページで、OAM構成ツールで作成したホスト識別子(ECM_EDGなど)をクリックします。

7. 「ホスト識別子詳細」ページで「変更」をクリックします。

8. アクセス・システム構成で使用される「優先HTTPホスト」値を追加します。次のリストは、SSO/WebGateを使用した場合にホスト名として考えられるバリエーションのすべてを示しています。

webhost1.mydomain.com:7777
webhost2.mydomain.com:7777
soahost1vhn1.mycompany.com:8001
soahost2vhn1.mycompany.com:8001
soainternal.mycompany.com:80
wcchost1vhn1.mycompany.com:16000
wcchost2vhn1.mycompany.com:16000
wcchost1.mycompany.com:16200
wcchost2.mycompany.com:16200
wcc.mycompany.com:443
wccinternal.mycompany.com:80
admin.mycompany.com:80
adminvhn.mycompany.com:7001
sso.mycompany.com:7779 [WebGate access with Oracle IDM port]

9. 「キャッシュの更新」チェック・ボックスを選択し、「保存」をクリックします。
メッセージ・ボックスが表示され、「現時点でキャッシュを更新すると、システム内のすべてのキャッシュがフラッシュされます。よろしいですか。」というメッセージが伝えられます。

「OK」をクリックして、構成変更の保存を終了します。

10. 「ホスト識別子詳細」ページで変更内容を確認します。

15.3.3.7 Webゲート・プロファイルの更新

OAM構成ツールでは、app_domainパラメータの値で作成したWebGateプロファイルのPreferred_HTTP_Hostおよびホスト名属性に値が移入されます。正しく機能する構成とするには、この2つの属性の両方を適切な値で更新する必要があります。

OAM構成ツールで作成したWebGateプロファイルを更新する手順は次のとおりです。

1. Webブラウザで次のURLを指定し、アクセス・システム・コンソールに移動します。

http://host_name:port/access/oblix

host_nameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。

3. 「アクセス・システム・コンソール」メイン・ページで「アクセス・システム構成」をクリックし、左側のペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

4. 適切な検索条件を入力して、「実行」をクリックし、アクセス・ゲートのリストを表示します。

5. OAM構成ツールで作成したアクセス・ゲート(ECM_EDG_AGなど)を選択します。

6. 「アクセス・ゲート詳細」ページで、「変更」を選択し、「アクセス・ゲートの変更」ページを表示します。

7. 「アクセス・ゲートの変更」ページで、次を更新します。

- ホスト名: WebGateを実行しているコンピュータの名前にホスト名を更新します(webhost1.mycompany.comなど)。

- 優先HTTPホスト: Preferred_HTTP_Hostを、前述の項で指定したホスト名バリエーションの1つに更新します(admin.mycompany.com:80など)。

- プライマリHTTP Cookieドメイン: ホスト識別子のドメイン接尾辞(mycompany.comなど)でプライマリHTTP Cookieドメインを更新します。

8. 「保存」をクリックします。
メッセージ・ボックスが表示され、「これらの変更をコミットしますか。」というメッセージが伝えられます。

「OK」をクリックして、構成の更新を終了します。

9. 「アクセス・ゲートの詳細」ページに表示される値を確認し、正常に更新されたことを確認します。

15.3.3.8 アクセス・サーバーの追加

WebGateにアクセス・サーバーを割り当てる手順は次のとおりです。

1. 管理者としてアクセス・システム・コンソールにログインします。

2. 必要に応じて、「アクセス・ゲート」ページの「詳細」に移動します。アクセス・システム・コンソールから、「アクセス・システム構成」を選択して「アクセス・ゲート構成」を選択し、WebGateのリンク(ECM_EDG_AG)を選択します。

3. 「アクセス・ゲート」ページの「詳細」で、「アクセス・サーバーをリスト」をクリックします。

4. ページが開き、このWebGateに現在構成されているプライマリ・アクセス・サーバーまたはセカンダリ・アクセス・サーバーが表示されます。
「追加」をクリックします。

5. 「新規アクセス・サーバーの追加」ページで、「サーバーの選択」リストから「アクセス・サーバー」を選択して、「プライマリ・サーバー」を指定し、WebGateの2つの接続を定義します。
「追加」ボタンをクリックすると、関連付けが完了します。

6. ページが開き、アクセス・サーバーとWebGateが関連付けられていることが示されます。リンクをクリックすると概要が表示されます。後で使用する場合に備えてこのページを印刷しておきます。

7. 手順3～6を繰り返して、さらに多くのアクセス・サーバーをWebGateに関連付けます。

15.3.3.9 委任フォーム認証の構成

Oracle Access ManagerインストールとともにインストールしたWebGateにリダイレクトするようにフォーム認証を構成する手順は次のとおりです。

1. 「アクセス・システム・コンソール」を開きます。

2. 「アクセス・システム構成」画面で、左側のバーから「認証管理」を選択します。

3. 「OraDefaultFormAuthNScheme」を選択します。

4. 「変更」をクリックします。

5. 「チャレンジ・リダイレクト」フィールドで、IDMインストールのホストとポートを入力します(http://sso.mycompany.comなど)。作業が終了したら、「保存」をクリックします。

IDMインストールにすでにWebGateがインストールされている必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

15.3.4 Webゲートのインストールと構成

Web層を保護するために、次の手順を実行して、WEBHOST1とWEBHOST2の両方にWebゲートをインストールする必要があります。

注意:

Oracle Access Managerのインストーラには既知の不具合があり、Linuxではインストール中にハングすることがあります。これはInstallShieldにより発生するサードパーティ問題です。この問題を回避する手順は次のとおりです。

1. 次をコピーしてから、インストーラを起動するシェルに貼り付けます。

cd /tmp
mkdir bin.$$
cd bin.$$
cat > mount <<EOF
#! /bin/sh
exec /bin/true
EOF
chmod 755 mount
export PATH=`pwd`:$PATH

2. インストールを実行します。

3. インストーラの実行が終了したら、次のコマンドを使用してこの一時ディレクトリをクリーンします。

rm -r /tmp/bin.$$

1. WEBHOSTn上で次のコマンドを使用して、WebGateインストーラ(取得場所の詳細は、第2.4項「インストールするソフトウェア・コンポーネントの特定」を参照)を起動します。

./Oracle_Access_Manager10_1_4_3_0_linux_OHS11g_WebGate –gui

2. 「ようこそ」画面で、「次へ」をクリックします。

3. 「顧客情報」画面(図15-1)で、Webサーバーを実行しているユーザー名とユーザー・グループを入力します。「次へ」をクリックして続行します。

図15-1 「顧客情報」画面

「図15-1 「顧客情報」画面」の説明

4. インストール先画面(図15-2)で、WebGateをインストールするディレクトリを指定します。「次へ」をクリックして続行します。

図15-2 インストール先画面

「図15-2 インストール先画面」の説明

5. インストールの概要の画面で「次へ」をクリックします。

6. WebGate構成画面(図15-3)の説明に従って、WebGateに必要なGCCランタイム・ライブラリをダウンロードし、「参照」を使用して、このGCCランタイム・ライブラリのローカル・コンピュータ上の場所を指定します。「次へ」をクリックして続行します。

図15-3 ランタイム・ライブラリ画面

「図15-3 ランタイム・ライブラリ画面」の説明

7. この段階で、インストーラにより必要なアーティファクトが作成されます。作成が完了したら、「次へ」をクリックして続行します。

8. 「トランスポート・セキュリティ・モード」画面(図15-4)で、「オープン・モード: 暗号化なし」を選択し、「次へ」をクリックして続行します。

図15-4 トランスポート・セキュリティ・モード画面

「図15-4 トランスポート・セキュリティ・モード画面」の説明

9. WebGate構成画面で、使用するアクセス・サーバーの詳細を入力します。入力する情報は次のとおりです。

- WebGate ID: OAM構成ツールを実行したときの指定のID

- WebGateのパスワード

- アクセス・サーバーID: Oracle Access Manager Access Server構成から報告されたもの

- アクセス・サーバー・ホスト名: Oracle Access Manager Access Server構成から報告されたもの

- アクセス・サーバー・ポート番号: Oracle Access Manager Access Server構成から報告されたもの

注意:

アクセス・サーバーのID、ホスト名およびポートは、すべて入力が必須の項目です。

これらの詳細は、Oracle Access Manager管理者から取得できます。「次へ」をクリックして続行します。

図15-5 アクセス・サーバー構成画面

「図15-5 アクセス・サーバー構成画面」の説明

10. 「Webサーバーの構成」画面で「はい」をクリックすると、自動的にWebサーバーが更新されます。「次へ」をクリックして続行します。

11. 表示された「Webサーバーの構成」画面で、httpd.confファイルが格納されているディレクトリのフルパスを指定します。このファイルは、次のディレクトリに格納されています。

ORACLE_BASE/admin/OHS_Instance/config/OHS/OHS_Component_Name

例:

/u01/app/oracle/admin/ohs_instance2/config/OHS/ohs2/httpd.conf

「次へ」をクリックして続行します。

12. 表示された「Webサーバーの構成」ページに、Webサーバー構成がWebGate向けに変更されたことを示すメッセージが示されます。「はい」をクリックして確認します。

13. Webサーバーをいったん停止してから再起動し、構成の更新を有効にします。「次へ」をクリックして続行します。

14. 次の「Webサーバーの構成」画面で、次のメッセージが表示されます。: WebサーバーがSSLモードで設定されている場合は、SSL関連のパラメータでhttpd.confファイルを構成する必要があります。SSLの構成を手動で調整するには、表示される説明に従ってください。.
「次へ」をクリックして続行します。

15. 次の「Webサーバーの構成」画面に、製品設定とWebサーバーの構成の残りの部分に関する情報が記載されているドキュメントの場所を示すメッセージが表示されます。「いいえ」を選択し、「次へ」をクリックして続行します。

16. 最後の「Webサーバーの構成」画面が表示されます。Webサーバーの構成に関する詳細情報を得るには、手動でブラウザを起動し、該当のHTMLドキュメントを開くように指示するメッセージが表示されます。「次へ」をクリックして続行します。

17. 「Oracle COREid Readme」画面が表示されます。画面の情報を確認し、「次へ」をクリックして続行します。

18. 正常にインストールが完了したことを示すメッセージが、インストールの詳細とともに表示されます。

15.3.5 EDG WebGateのIP検証の構成

IP検証では、クライアントのIPアドレスとシングル・サインオンで生成されるObSSOCookieというCookieに格納されているIPアドレスが同じであるかどうかを確認します。IP検証では、IPターミネーションの実行用に構成されたロード・バランサ・デバイスを使用するシステムで問題が発生するか、あるいはエンタープライズ・デプロイメントのフロントエンドとは異なるロード・バランシング・ルーター(LBR)またはプロキシがフロントエンドとなるWebGateを認証する際に問題が発生する可能性があります。

次の場合には、エンタープライズ・デプロイメントのLBRまたはプロキシは検証されません。

1. 「アクセス・システム・コンソール」を開いて、次のURLに管理者としてログインします。

http://host_name:port/access/oblix

host_nameにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックします。

3. 「アクセス・システム・コンソール」メイン・ページで、「アクセス・システム構成」をクリックし、左側のペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

4. 適切な検索条件を入力して、「実行」をクリックし、アクセス・ゲートのリストを表示します。

5. OAM構成ツールによって作成されたアクセス・ゲートを選択します。

6. ページの一番下にある「変更」をクリックします。

7. 「IPValidationException」フィールドで、エンタープライズ・デプロイメントのフロントエンドになるロード・バランサまたはプロキシのIPアドレスを入力します。

8. ページの一番下にある「保存」をクリックします。

15.3.6 WebLogic認証プロバイダの設定

この項では、第15.2.2.1項「LDAP認証プロバイダの作成」の手順に従ってLDAP認証プロバイダをすでに設定していることを想定しています。まだLDAP認証を作成していない場合は、それを作成してからこの項の続きを実行してください。

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

- 第15.3.6.1項「構成ファイルのバックアップ」

- 第15.3.6.2項「OAM IDアサータの設定」

- 第15.3.6.3項「プロバイダの順序の設定」

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

まず、次の関連する構成ファイルをバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/
system-jazn-data.xml

管理サーバーのboot.propertiesファイルもバックアップします。

15.3.6.2 OAM IDアサータの設定

OAM IDアサータを設定するには:

1. WebLogicコンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. 「新規」をクリックし、ドロップダウン・メニューから「OAMIdentityAsserter」を選択します。

5. アサータに名前(OAM ID Asserterなど)を付け、「OK」をクリックします。

6. 新しく追加したアサータをクリックし、OAMアイデンティティ・アサータの構成画面を確認します。

7. 「制御フラグ」を「REQUIRED」に設定して、「保存」をクリックします。

8. 「プロバイダ固有」タブを開き、必要な設定を次のように構成します。

- プライマリ・アクセス・サーバー: Oracle Access Managerサーバーのエンドポイント情報を「host:port」という形式で指定します。

- アクセス・ゲート名: アクセス・ゲートの名前(ECM_EDG_AGなど)。

- アクセス・ゲートのパスワード: アクセス・ゲートのパスワード(オプション)。

9. 設定を保存します。

15.3.6.3 プロバイダの順序の設定

OAMアイデンティティ・アサータ、OID/OVD認証プロバイダおよびデフォルト認証プロバイダの制御フラグが次のように設定されていることを確認し、これらの認証プロバイダを並べ替えます。

- OAMアイデンティティ・アサータ: REQUIRED

- OID LDAP認証プロバイダ(またはOVD LDAP認証プロバイダ): SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

- DefaultIdentityAsserter

並替えの実行後、設定を保存し、変更を有効化してからすべてのサーバーを再起動します。

注意:

新規のユーザーに対しては、必ず新規の資格証明を作成してください。詳細は、第11.17項「BPEL CSF資格証明の構成」を参照してください。(このマニュアルでは、SSOの例としてweblogic_ecmユーザーを使用しています。)

15.4 Oracle Access Manager 11g統合

この項では、Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのシングル・サインオン・ソリューションとしてOracle Access Manager 11gを設定する方法について説明します。この章には次の項目があります。

- 第15.4.1項「Oracle Access Managerの統合の概要」

- 第15.4.2項「Oracle Access Managerの前提条件」

- 第15.4.3項「WebGateの設定」

- 第15.4.4項「WebGateエージェントの登録」

- 第15.4.5項「WebLogicオーセンティケータのセットアップ」

15.4.1 Oracle Access Manager統合の概要

Oracle Fusion Middleware 11g リリース1の推奨シングル・サインオン・ソリューションはOracle Access Managerです。Oracle Access Managerインストールのインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。この項では、既存のOracle Access Manager 11gインストールおよびその基礎となるディレクトリ・サービスで、Oracle WebCenter Contentのインストールを構成する手順について説明します。Oracle Internet Directory(OID)またはOracle Virtual Directory(OVD)のいずれか、あるいはこの両方のディレクトリ・サービスの使用をお薦めします。

注意:

このガイドに記載されているOracle WebCenter Contentエンタープライズ・デプロイメント・トポロジでは、Oracle WebCenter Contentシステムおよびシングル・サインオン・システムの両方が同じネットワーク・ドメイン(mycompany.com)に存在する状態で、シングル・サインオン構成を使用します。マルチ・ドメイン構成については、『Oracle Access Managerアクセス管理ガイド』のシングル・サインオン構成に関する項に記載されている、必須の構成手順を参照してください。

15.4.2 Oracle Access Managerの前提条件

Oracle Access Managerの設定では、既存のOracle Access Manager 11gインストールにAccess Managerおよびポリシー・マネージャを保護するポリシーが完備されていることを前提とします。Oracle Access Managerインストールのインストールと構成の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。この設定には、スタンドアロンのOracle Internet DirectoryまたはOracle Virtual Directory構成の一部としてのOracle Internet Directoryのいずれかのディレクトリ・サービスが含まれています。この項では、Oracle Internet DirectoryとOracle Virtual Directoryのいずれかでエンタープライズ・デプロイメントを構成するために必要な手順について説明します。

また、Oracle Access Managerインストールには、Webゲートを使用するように構成された独自のWebサーバーが必要です。この項では、Oracle Access Manager Webサーバーを委任認証サーバーとして使用するための手順も説明します。

15.4.3 WebGateの設定

Oracle HTTPサーバーがすでにインストールされている各WEBHOSTマシン上でWebGateを設定する必要があります。デプロイメント環境の各WEBHOSTnに対して、(UNKNOWN STEP NUMBER)および(UNKNOWN STEP NUMBER)を繰り返す必要があります。

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

- 第15.4.3.1項「GCCライブラリのインストール」

- 第15.4.3.2項「WebGateのインストール」

- 第15.4.3.3項「インストール後の手順」

15.4.3.1 GCCライブラリのインストール

WebGateをインストールする前に、マシンにサード・パーティGCCライブラリをダウンロードおよびインストールする必要があります。次のサード・パーティのWebサイトから適切なGCCライブラリをダウンロードできます。

http://gcc.gnu.org

32ビットのLinuxの場合、必要なライブラリはバージョン番号3.3.2のlibgcc_s.so.1およびlibstdc++.so.5になります。表15-3は、サード・パーティのGCCライブラリでLinuxおよびSolarisに対応するバージョンを示しています。

表15-3 LinuxおよびSolarisのGCCサードパーティ製ライブラリのバージョン

オペレーティング・システム

アーキテクチャ

GCCライブラリ

必要なライブラリ・バージョン

Linux 32ビット

x86

libgcc_s.so.1

libstdc++.so.5

3.3.2

Linux 64ビット

x64

libgcc_s.so.1

libstdc++.so.6

3.4.6

Solaris 64ビット

SPARC

libgcc_s.so.1

libstdc++.so.5

3.3.2

15.4.3.2 WebGateのインストール

この項では、WebGateをインストールする手順を説明します。

インストーラの起動

Oracle HTTP Server 11g Webgate for Oracle Access Managerのインストーラ・プログラムはwebgate.zipファイルに含まれています。

インストール・ウィザードを開始するには:

1. webgate.zipファイルのコンテンツを、ディレクトリに解凍します。デフォルトでは、このディレクトリにはwebgateという名前が付けられています。

2. webgateディレクトリの下のDisk1ディレクトリに移動します。

3. MW_HOME環境変数をWeb層のミドルウェア・ホームに設定します。

export MW_HOME=ORACLE_BASE/product/fmw/web

4. 次のコマンドを使用し、インストーラを開始します。

$ ./runInstaller -jreLoc MW_HOME/jdk

注意:

Oracle HTTP Serverをインストールすると、ミドルウェア・ホーム・ディレクトリの下にjdkディレクトリが作成されます。インストーラを起動するときに、このJDKの中にあるJREフォルダの絶対パスを入力する必要があります。

インストーラが起動すると、「ようこそ」画面が開きます。

インストール・フローおよび手順

インストール画面の詳細なヘルプが必要な場合は、「ヘルプ」をクリックしてオンライン・ヘルプにアクセスします。

Oracle HTTP Server 11g Webgate for Oracle Access Managerをインストールするには:

1. 「ようこそ」画面で、「次へ」をクリックします。

2. 「前提条件のチェック」画面で、「次へ」をクリックします。

3. 「インストール場所の指定」画面で、Oracleミドルウェア・ホームとOracleホーム・ディレクトリの場所を指定します。

- ORACLE_BASE/product/fmw

- Oracle_OAMWebGate1 (デフォルト名のまま)

注意:

ミドルウェア・ホームには、Oracle Web層のOracleホームが含まれます。このOracleホーム・ディレクトリのデフォルト名はOracle_OAMWebGate1で、これはミドルウェア・ホームの下に作成されます。

「次へ」をクリックします。

4. GCCライブラリの指定画面で、GCCライブラリが含まれるディレクトリを指定し、「参照」をクリックして、使用しているローカル・コンピュータ上のライブラリの場所に移動し(第15.4.3.1項「GCCライブラリのインストール」を参照)、「次へ」をクリックします。

5. 「インストール・サマリー」画面で情報を確認し、「インストール」をクリックしインストールを開始します。

6. 「インストールの進行状況」画面で、ファイルおよびディレクトリに対して正しい権限を設定するために、ORACLE_HOME/oracleRoot.shスクリプトの実行を求められる場合があります。
「次へ」をクリックして続行します。

7. 「インストール 完了」画面で、「終了」をクリックしてインストーラを終了します。

15.4.3.3 インストール後の手順

Oracle HTTP Server 11g Webgate for Oracle Access Managerのインストール後、次の手順を完了します。

1. Oracleホーム下のWebgateの次のディレクトリの下に移動します。

$ cd Webgate_Oracle_Home/webgate/ohs/tools/deployWebGate

Webgate_Oracle_Homeは、Oracle HTTP Server Webgateをインストールし、WebgateのOracleホームとして作成したディレクトリです。次の例を参照してください。

MW_HOME/Oracle_OAMWebGate1

注意:

デフォルトでは、Oracle_OAMWebGate1になります。

2. コマンド・ラインで次のコマンドを実行し(1行で)、Webgate_Oracle_HomeディレクトリからWebgateインスタンスの場所にエージェントの必要な部分をコピーします。

$ ./deployWebGateInstance.sh -w ORACLE_BASE/admin/webN/config/OHS/ohsN
-oh Webgate_Oracle_Home

ORACLE_BASE/admin/webN/config/OHS/ohsNディレクトリは、Oracle HTTP Serverのインスタンス・ホームになります(Nはインストールごとに付される連番で、1番目はWEBHOST1、2番目はWEBHOST2などとなります)。

注意:

Oracle HTTP Serverのインスタンス・ホームはOracle HTTP Serverの構成後に作成されます。

3. 次のコマンドを実行し、LD_LIBRARY_PATH変数にOracle_Home_for_Oracle_HTTP_Server/libが含まれることを確認します。

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:ORACLE_BASE/product/fmw/webN/lib

4. 現在の作業ディレクトリから1レベル上位のディレクトリに移動します。

$ cd Webgate_Oracle_Home/webgate/ohs/tools/setup/InstallTools

5. コマンドラインで次のコマンドを実行し(1行で)、Webgate_Oracle_HomeディレクトリからWebgateインスタンスの場所(webgate.confに名前が変更されている)にapache_webgate.templateをコピーし、httpd.confファイルにwebgate.confの名前を追加する1行を追加して更新をかけます。

$ ./EditHttpConf -w ORACLE_BASE/admin/webN/config/OHS/ohsN [-oh Webgate_Oracle_Home]
[-o output_file]

注意:

-oh WebGate_Oracle_Homeパラメータと-o output_fileパラメータはオプションです。

コマンド内のWebGate_Oracle_Homeは、Oracle Access Manager用のOracle HTTP Server Webgateをインストールし、WebgateのOracleホームとして作成したディレクトリです。次の例を参照してください。

MW_HOME/Oracle_OAMWebGate1

ORACLE_BASE/admin/webN/config/OHS/ohsNディレクトリは、Oracle HTTP Serverのインスタンス・ホームになります(Nはインストールごとに付される連番で、1番目はWEBHOST1、2番目はWEBHOST2などとなります)。

output_fileの値は、ツールによって使用された一時出力ファイルの名前です。次の例を参照してください。

Edithttpconf.log

15.4.4 WebGateエージェントの登録

この項では、WebGateエージェントを登録する手順を説明します。

- 第15.4.4.1項「RREGツールの解凍および使用」

- 第15.4.4.2項「Oracle Access Manager 11gリクエスト・ファイルの更新」

- 第15.4.4.3項「oamregツールの実行」

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

- 第15.4.4.5項「Cookieを使用しない基本スキームをサポートするためのOracle Access Manager 11gサーバー構成の更新」

- 第15.4.4.6項「WEBHOSTへのアクセス・ファイルのコピー」

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

RREGツールは、Oracle Access Manager 11gインストールに付属しています。見つからない場合は、次の手順を使用して抽出します。

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パラメータを変更します。

OAM_REG_HOME=RREG_Home

(RREG_Homeは、RREG.tar.gzおよびrregの内容を展開したディレクトリです。)

スクリプト・ファイルを保存します。

RREG構成ツールは、保護されているリソースやパブリック・リソースをOracle Access Managerシステムに登録する手段を提供します。保護されているリソースのうちOracle Access Managerシステムに追加されるものを次にリストします。

/adfAuthentication
/adfAuthentication/…/*
/imaging/faces
/imaging/faces/…/*
/em
/em/…/*
/console
/console/…/*
/DefaultToDoTaskFlow
/DefaultToDoTaskFlow/…/*
/sdpmessaging/userprefs-ui
/sdpmessaging/userprefs-ui/…/*
/integration/worklistapp
/integration/worklistapp/…/*
/workflow/sdpmessagingsca-ui-worklist
/workflow/sdpmessagingsca-ui-worklist/…/*
/soa/composer
/soa/composer/…/*
/soa-infra
/soa-infra/.../*
/soa-infra/deployer
/soa-infra/deployer/…/*
/soa-infra/events/edn-db-log
/soa-infra/events/edn-db-log/…/*
/soa-infra/cluster/info
/soa-infra/cluster/info/…/*
/inspection.wsil
/inspection.wsil/…/*

パブリック・リソースのリストは次のとおりです。

/cs
/cs/…/*
/_ocsh
/_ocsh/…/*
/imaging
/imaging/…/*
/soa-infra/services/.../*
/soa-infra/directWSDL
/soa-infra/directWSDL/…/*
/ucs/messaging/webservice
/ucs/messaging/webservice/…/*

リストの「/…/*」は、URLの基本的なコンテキストの下にあるすべてのリソースを表します。

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

oamregツールを実行する前に、Oracle WebCenter ContentコンポーネントのOracle Access Manager 11gに必要なリソースを追加する必要があります。必要なリソースは、第15.4.4.1項「RREGツールの解凍および使用」にリストされています。

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>/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>/inspection.wsil</resource>
<resource>/soa-infra</resource>
</protectedResourcesList>

<publicResourcesList>
<resource>/cs</resource>
<resource>/_ocsh</resource>
<resource>/imaging</resource>
<resource>/soa-infra/directWSDL</resource>
<resource>/ucs/messaging/webservice</resource>

</publicResourcesList>
<userDefinedParameters>

<userDefinedParam>
<name>filterOAMAuthnCookie</name>
<value>false</value>
</userDefinedParam>

</userDefinedParameters>

</OAM11GRegRequest>

注意:

- 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>

IP検証例外の追加の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

15.4.4.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: /u01/app/oracle/product/fmw/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.mycompany.com:7001
----------------------------------------

Inband registration process completed successfully! Output artifacts are created in the output folder.

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

デフォルトでは、inspection.wsilリソースは、フォーム認証スキームを使用するように設定されています。このワークフローとOracle WebCenter Content: Imagingの間の接続が機能するようにするには、次に示すように、このリソースが基本認証スキームを使用するように更新する必要があります。

1. http://OAM_HOST:OAM_ADMINSERVER_PORT/oamconsoleにあるOracle Access Managerコンソールにログインします。

2. 左側のアプリケーション・ツリーを使用して、「アプリケーション・ドメイン」を選択し、アプリケーション・ドメイン名を選択して、作成したアプリケーション・ドメイン(WCC_EDG_DOMAIN)に移動します。

3. 使用しているアプリケーション・ドメイン名を開きます。

4. 「認証ポリシー」を開きます。

5. 保護されているリソース・ポリシーをダブルクリックします。

6. inspection.wsilおよびinspection.wsil/.../*のリソースを選択し、「リソース」ペインにある「削除」アイコンをクリックしてそれらを削除します。

7. 「適用」をクリックして、求められたら動作を確定します。

8. ナビゲーション・ツリーで「認証ポリシー」を再度クリックし、ナビゲーション・ツリー上部のツール・バーにある「作成」ボタンをクリックします。

1. ポリシーの名前(New Basic Policyなど)を入力します。

2. 認証スキームとして「BasicSessionlessScheme」を選択します。

3. 「適用」をクリックします。
ナビゲーション・ツリーの「認証ポリシー」の下に新しく作成されたポリシーが表示されます。

4. 新規に作成したポリシーを開きます。

5. 「リソース」ペインで、右側にある「追加」アイコン(+印付き)をクリックして、inspection.wsilおよびinspection.wsil/.../*のリソースを追加します。

6. 「適用」をクリックします。

9. ナビゲーション・ツリー上の「リフレッシュ」アイコンをクリックし、新しい認証ポリシーを確認します(認証ポリシーをクリックしてinspection.wsilおよびinspection.wsil/.../*のリソースが追加されたことを確認します)。

注意:

新規のユーザーに対しては、必ず新規の資格証明を作成してください。詳細は、第11.17項「BPEL CSF資格証明の構成」を参照してください。(このマニュアルでは、SSOの例としてweblogic_ecmユーザーを使用しています。)

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

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 Access Managerサーバーを再起動して、変更を有効にします。

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

RREG_Home/output/WCC_EDG_AGENTに次の2つのファイルが生成されます。

- ObAccessClient.xml

- cwallet.sso

これらのファイルを、WEBHOSTマシン上のWebGateインスタンスの場所にコピーします。

scp ObAccessClient.xml oracle@WEBHOSTN:ORACLE_BASE/admin/webN/config/OHS/ohsN/
webgate/config/

scp cwallet.sso oracle@WEBHOSTN:ORACLE_BASE/admin/webN/config/OHS/ohsN/
webgate/config/

scpコマンドの、Nはインストールの連番で、たとえば、WEBHOST1は1、WEBHOST2は2です。

15.4.5 WebLogic認証プロバイダの設定

この項では、第15.2.2.1項「LDAP認証プロバイダの作成」の手順に従ってLDAP認証プロバイダをすでに設定していることを想定しています。まだLDAP認証を作成していない場合は、それを作成してからこの項の続きを実行してください。

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

- 第15.4.5.1項「構成ファイルのバックアップ」

- 第15.4.5.2項「OAM IDアサータの設定」

- 第15.4.5.3項「プロバイダの順序の設定」

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

まず、次の関連する構成ファイルをバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fwmconfig/system-jazn-data.xml

また、管理サーバーのboot.propertiesファイルもバックアップします。

15.4.5.2 OAM IDアサータの設定

OAM IDアサータを設定するには:

1. WebLogicコンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. 「新規」をクリックし、ドロップダウン・メニューから「OAMIdentityAsserter」を選択します。

5. アサータに名前(OAM ID Asserterなど)を付け、「OK」をクリックします。

6. 新しく追加したアサータをクリックし、OAMアイデンティティ・アサータの構成画面を確認します。

7. 制御フラグを「必須」に設定します。

8. 「選択済み」タイプで「ObSSOCookie」および「OAM_REMOTE_USER」の2つのオプションを選択します。

9. 設定を保存します。

最後に、WLSTコンソールに管理者としてログインし、次のコマンドを実行します。

addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",logouturi="oamsso/logout.html")

15.4.5.3 プロバイダの順序の設定

プロバイダの順序を設定する手順は次のとおりです。

1. WebLogicコンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. OAMアイデンティティ・アサータ、OID/OVD認証プロバイダおよびデフォルト認証プロバイダの制御フラグが次のように設定されていることを確認し、これらの認証プロバイダを並べ替えます。

- OAMアイデンティティ・アサータ: REQUIRED

- OID LDAP認証プロバイダ(またはOVD LDAP認証プロバイダ): SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

5. 「OK」をクリックします。

6. 「変更のアクティブ化」をクリックして、変更を伝播します。

7. 管理サーバーとすべての管理対象サーバーを再起動します。

15.5 Oracle HTTP ServerおよびSSOを使用したアクセスの検証

次のURLを使用して、両方のOracle HTTP Serverインスタンスによるシングル・サインオンを検証します。

- http://WEBHOST1:7777/console

- http://WEBHOST1:7777/em

- http://WEBHOST1:7777/cs

- http://WEBHOST1:7777/imaging

- http://WEBHOST2:7777/console

- http://WEBHOST2:7777/em

- http://WEBHOST2:7777/cs

- http://WEBHOST2:7777/imaging

次に、(SSOのユーザー名およびパスワードを使用した)フロンドエンドでのシングル・サインオンを検証します。

- http://admin.mycompany.com/console

- http://admin.mycompany.com/em

- http://wcc.mycompany.com/cs

- http://wcc.mycompany.com/imaging

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

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、このガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法の詳細は、このガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、このガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』も参照してください。

この時点でインストールをバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl startall

2. SOAHOST1上の管理サーバーのドメイン・ディレクトリをバックアップします。バックアップを実行してドメイン構成を保存します。構成ファイルはすべて、ORACLE_BASE/admin/domain_nameディレクトリの下にあります。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

16 トポロジの管理

この章では、トポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップなどがあります。この章には次の項目があります。

- 第16.1項「Oracle WebCenter Contentトポロジの管理の概要」

- 第16.2項「Oracle WebCenter Content: Imagingの入力ファイルを最適化する戦略の定義」

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

- 第16.4項「SOAインフラストラクチャ・データベースでの領域の管理」

- 第16.5項「Oracle WebCenter Content: ImagingのUMSドライバの構成」

- 第16.6項「Oracle WebCenter Contentトポロジのスケール・アップ」

- 第16.7項「Oracle WebCenter Contentトポロジのスケール・アウト」

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

- 第16.9項「SQLNet接続のタイムアウト防止」

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

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

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

Oracle WebCenter Contentエンタープライズ・デプロイメントを構成したら、この章の情報を使用してトポロジを管理できます。表16-1に、トポロジを管理するために実行できるタスクを示します。

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

タスク

説明

詳細

Imagingクラスタにおいて高いパフォーマンス、スケーラビリティおよび高可用性を実現するためのImagingの構成

入力ファイルを最適化する戦略を定義します。

第16.2項「Oracle WebCenter Content: Imagingの入力ファイルを最適化する戦略の定義」

Imagingで使用するOracle SOA Suiteサブシステムの管理

SOAコンポジットをサーバーのアドレスにデプロイし、Oracle SOA Suiteインフラストラクチャ内の領域を管理し、UMSドライバを構成します。

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

第16.4項「SOAインフラストラクチャ・データベースでの領域の管理」

第16.5項「Oracle WebCenter Content: ImagingのUMSドライバの構成」

スケール・アップまたはスケール・アウトによるトポロジの拡張

ノードに新しい管理対象サーバーを追加するか、または新しいノードを追加します。

第16.6項「Oracle WebCenter Contentトポロジのスケール・アップ」

第16.7項「Oracle WebCenter Contentトポロジのスケール・アウト」

構成の変更前後におけるトポロジのバックアップ

ディレクトリおよびファイルをバックアップし、構成の変更によって発生する障害から保護します。

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

接続タイムアウトの防止

データベース接続がタイムアウトしないようにファイアウォールを構成します。

第16.9項「SQLNet接続のタイムアウト防止」

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

HTTP基本認証のかわりに適切なOracle WSMポリシーを適用します。

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

問題のトラブルシューティング

トポロジの構成後に発生する可能性のある既知の問題の解決方法を実施します。

第16.11項「Oracle WebCenter Contentエンタープライズ・デプロイメント・トポロジのトラブルシューティング」

Oracle WebCenter Contentの管理の詳細は、次のドキュメントを参照してください。

- Oracle WebCenter Content Content Serverシステム管理者ガイド

- Oracle WebCenter Content Content Serverアプリケーション管理者ガイド

- Oracle WebCenter Content Imaging管理者ガイド

16.2 Oracle WebCenter Content: Imagingの入力ファイルを最適化する戦略の定義

入力ファイルは、入力エージェントがスケジュール設定および処理できる作業の最小単位です。Imagingクラスタにおいて最高のパフォーマンス、スケーラビリティ、および可用性を実現するために、いくつかの考慮事項があります。

- Imagingクラスタ内のすべてのマシンは、共通の入力ディレクトリを共有します。

- このディレクトリからの入力ファイルは、JMSキューを介してそれぞれのマシンに配信されます。

- このディレクトリをポーリングして新しいファイルを調べる間隔は構成可能です。

- 各マシンには、入力ファイルを処理する解析エージェントが複数あります。解析エージェントの数は、Oracle WebCenter Content: 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ドキュメントの処理が完了するようになります。また、一方のサーバーで障害が発生した場合、処理が正常に終了するまでもう一方のサーバーで解析エージェントに残っている処理を続行できます。

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

Oracle WebCenter Content: Imagingによって使用されているOracle SOA SuiteサブシステムにSOAコンポジットをデプロイする場合は、ロード・バランサのアドレス(wcc.mycompany.com)ではなく、特定のサーバーのアドレスにデプロイします。ロード・バランサ・アドレスにデプロイするには、デプロイヤ・ノードから外部のロード・バランサ・アドレスへの直接接続が必要になることがあり、その接続のために、システムのファイアウォールで追加ポートを開く必要が生じる場合があります。

16.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インフラストラクチャ・データベースのサイズを縮小することもできます。Oracle Enterprise Manager Fusion Middleware Controlのこのような操作への使用は、ほとんどの場合、トランザクション・タイムアウトが発生するのでお薦めできません。

提供されるSQLパッケージで可能な操作の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のSOAコンポジット・アプリケーションの管理に関する項を参照してください。正しく消去するには、提供されているスクリプトを常に使用します。composite_dn表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。

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

注意:

この手順が必要になるのは、Oracle WebCenter Content: Imagingが使用するOracle SOA SuiteシステムがUnified Messaging System (UMS)を使用している場合のみです。

UMSドライバの構成情報は、Oracle SOA Suiteクラスタに自動的には伝播されません。これは、Oracle WebCenter Content: Imagingによって起動されるOracle SOA SuiteシステムがUMSを使用する場合、次を実行する必要があることを意味します。

1. UMSドライバの構成情報を、そのドライバを使用するEDGトポロジ内のすべてのサーバーに適用します。

2. サーバーの移行機能を使用すると、サーバーは別のノードのドメイン・ディレクトリに移動します。UMSドライバ構成は、フェイルオーバー・ノード内であらかじめ作成しておく必要があります。UMSドライバ構成ファイルの場所は次のとおりです。

ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml

(*は、デプロイ中にOracle WebLogic Serverによってランダムに生成される3682yqなどのディレクトリ名を表します)。

フェイルオーバーに備えてファイルを作成するには、強制的にサーバー移行を実行してファイルをソース・ノードからコピーしてください。次に例を示します。

1. WLS_IMG1のドライバをSOAHOST1内で構成します。

2. SOAHOST2へのWLS_IMG1のフェイルオーバーを強制的に実行します。フェイルオーバー・ノード内のUMSドライバ構成のディレクトリ構造が、次のとおりであることを確認してください。

cd ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration

(*は、デプロイ中にWLSによってランダムに生成される3682yqなどのディレクトリ名を表します)。

3. 次のコマンドをSOAHOST1で実行し、SOAHOST1からSOAHOST2にドライバ構成ファイルをリモート・コピーします

scp ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml oracle@SOAHOST2:ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/

(*は、デプロイ中にOracle WebLogic Serverによってランダムに生成される3682yqなどのディレクトリ名を表します)。

これまでに行った変更を有効にする(変更後の構成情報をドライバに読み取らせる)ためにドライバを再起動する必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. ナビゲーション・ツリーの環境ノードを開きます。

3. 「デプロイメント」をクリックします。

4. ドライバを選択します。

5. 「停止」→「作業完了時」をクリックし、操作を確定します。

6. ドライバの状態が「準備完了」に変化するまで待ちます(必要に応じて、管理コンソール・ページを更新します)。

7. ドライバをもう一度選択し、「起動」→「すべてのリクエストを処理」をクリックして、操作を確定します。

ドライバのプロパティが保持されていることを、Oracle Enterprise Manager Fusion Middleware Controlで確認してください。

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

トポロジのスケールアップとは、1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することです。必要なコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。このノードには、共有記憶域内にWebLogic ServerホームとOracle Fusion Middlewareホームが存在します。新しい管理対象サーバーを作成する場合は、このような既存のインストール(WebLogic Serverホーム、Oracle Fusion Middlewareホーム、ドメイン・ディレクトリなど)を使用します。WebLogic Serverのバイナリを新しい場所にインストールしたり、packとunpackを実行したりする必要はありません。

注意:

コンテンツ・サーバーを含む管理対象サーバーの場合、共有ドメイン・ディレクトリは動作しません。intradoc.cfgなどのドメイン内の特定のファイルは各ノードに固有だからです。ノード固有のファイルの問題を防ぐには、各Oracle WebCenter ContentおよびOracle WebCenter Content: Inbound Refinery管理対象サーバーにローカル(ノードごと)のドメイン・ディレクトリを使用します。

スケール・アップの手順は、トポロジのコンポーネントによって異なります。

- 第16.6.1項「Oracle WebCenter Contentのスケール・アップ手順」

- 第16.6.2項「Oracle WebCenter Content: Imagingのスケール・アップ手順」

- 第16.6.3項「Oracle SOA Suiteのスケール・アップ手順」

16.6.1 Oracle WebCenter Contentのスケール・アップ手順

1つのドメイン、1つのノードに対して、Oracle WebCenter Content管理対象サーバー1台のみが、Oracle Fusion Middlewareによってサポートされます。Oracle WebCenter Content管理対象サーバーを追加するには、第16.7.1項「Oracle WebCenter Contentのスケール・アウト手順」に従い、新しいノードにOracle WebCenter Content管理対象サーバーを追加します。

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

エンタープライズ・デプロイメント・トポロジ内でImagingサーバーをスケール・アップする手順は次のとおりです。

1. Oracle 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が実行されています。

注意:

WCCHOST1(WCCHOST1VHN2など)ではVIPを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはhosts解決のいずれかで)正しく解決する必要があります。VIPを有効にするには、第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」で説明した例に従ってください。

2. Oracle WebCenter Content: Imaging JMS用に、JMS永続ストアとJMSサーバーを構成します。
2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Oracle WebCenter Content: Imagingで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/store/default)を使用しています。次のように、共有ベースのディレクトリを使用するように、OracleのJMSサーバーの永続ストアを変更する必要があります。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて永続ストアノードをクリックします。

3. 「永続ストアの概要」ページで「ロックして編集」をクリックします。

4. 「新規」→「ファイル・ストアの作成」をクリックします。

5. 「新しいファイル・ストアの作成」ページで次の情報を入力します。
- 名前: IMGJMSServernStore(例: IMGJMSServer3Store。これにより、作成対象のサービスを特定できます)。

- ターゲット: WLS_IMGn(例: WLS_IMG3)。

- ディレクトリ: WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを指定します (ORACLE_BASE/admin/domain_name/img_cluster_name/jms)。

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

6. 「OK」をクリックして、変更をアクティブ化します。

7. 「ドメイン構造」ウィンドウで、「サービス」ノード→「メッセージ」ノードを開いて、「JMSサーバー」をクリックします。

8. 「JMSサーバーのサマリー」ページで「新規」をクリックし、次の情報を入力します。
- 名前: IpmJmsServern(例: IpmJmsServer3)。

- 永続ストア: 前述のとおり作成した永続ストアIMGJMSServernStore(例: IMGJMSServer3Store)を選択します。

「次へ」をクリックし、WLS_IMGn(例: WLS_IMG3)をターゲットとして指定します。「終了」をクリックして変更内容をアクティブ化します。

9. 表の「名前」列にある(ハイパーリンクで表示されている)JMSサーバー「IpmJmsServer3」をクリックします。

10. このJMSサーバーの「設定」ページで、「ロックして編集」をクリックしてください。

11. 「永続ストア」ドロップダウン・リストで、「IMGJMSServernStore」を選択します。

12. 「保存」をクリックして、変更をアクティブ化します。

3. トランザクション・リカバリのためのWLS_IMGnのデフォルトの永続ストアを構成します。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)「WLS_IMGn」をクリックします。WLS_IMGnサーバーの設定ページが開き、「構成」タブがアクティブに表示されます。

4. 「サービス」タブを開きます。

5. 「ロックして編集」をクリックします。

6. 表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/img_cluster_name/tlogs

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

7. 「保存」をクリックして、変更をアクティブ化します。

4. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_IMGn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名検証を無効化するには:

1. Oracle Enterprise Managerコンソールで、「WebLogic Server管理コンソール」を選択し、ログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある(ハイパーリンクで表示されている)「WLS_IMGn」をクリックします。WLS_IMGnサーバーの設定ページが開き、「構成」タブがアクティブに表示されます。

4. 「SSL」タブを開きます。

5. 表示されたページの「詳細」セクションを開きます。

6. 「ロックして編集」をクリックします。

7. ホスト名の検証をNoneに設定します。

8. 「保存」をクリックします。

5. 新しく作成した管理対象サーバー(WLS_IMG)を起動します。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、「制御」タブを開き、クラスタ内にある既存のWLS_IMGnすべての管理対象サーバーを停止します。

4. 新規作成した管理対象サーバーであるWLS_IMGnが稼働していることを確認します。

6. WLS_IMGn管理対象サーバー(WCCHOSTnVHN1)のホスト名をSocketHostNameSecurityFilterパラメータ・リストに追加します。

1. テキスト・エディタで、ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfgのファイルを開きます。

2. リスニング・アドレスをOracle WebCenter Contentへの接続を許可するアドレスのリストに追加するために、WLS_IMGn管理対象サーバーを追加します。SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|WCCHOST1|WCCHOST2|WCCHOST1VHN1|WCCHOST1VHN2|WCCHOST2VHN1

3. 変更されたconfig.cfgファイルを保存して、Oracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

7. 新しい管理対象サーバー用のサーバー移行を構成します。

注意:

これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。新しい管理対象Imagingサーバー用の浮動IPも、すでに存在している必要があります。

サーバー移行を構成する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成する新しい管理対象サーバー名(ハイパーリンクで表示されている)をクリックします。

4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

5. 「移行の構成」セクションで、移行に参加するサーバーを 「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、すでにWLS_IMG1が実行されているWCCHOST1上の新しい管理対象サーバーには、WCCHOST2を選択します。すでにWLS_IMG2が実行されているWCCHOST2上の新しい管理対象サーバーには、WCCHOST1を選択します。

注意:

移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

8. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

- WLS_IMGn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_IMGn

- ノード・マネージャ・コンソールに、WLS_IMGnの浮動IPが無効になったことを示すメッセージが表示されることを確認します。

- ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

- ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

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

エンタープライズ・デプロイメント・トポロジ内でOracle SOA Suiteサーバーをスケール・アップする手順は次のとおりです。

注意:

Oracle WebCenter Content: Imagingが使用するOracle SOA Suiteサブシステムのスケール・アップについては、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのドキュメントを参照してください。

1. WebLogic Server管理コンソールを使用して、WLS_SOA1をクローニングして新しい管理対象サーバーを作成します。クローニング元の管理対象サーバーとして選択できるのは、新しい管理対象サーバーを実行するノード上にすでに存在しているサーバーです。
管理対象サーバーのクローンを作成するには:

1. WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。

2. 「サーバーのサマリー」ページで、クローンを作成する管理対象サーバー(WLS_SOA1)を選択します。

3. 「クローンの作成」をクリックします。

4. 新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。

注意:

以降の手順は、新しいサーバーをSOAHOST1に追加する場合を想定しています。このホストではすでにWLS_SOA1が実行されています。

2. リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを指定します。このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、別のノードへの移動を可能にするために、このアドレスにVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、実行されている管理対象サーバーとは別のものを使用してください。

3. 新しい管理対象サーバーにOracle SOA SuiteおよびUMSのJMSサーバーを作成します。

1. WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_Nのような名前を付けますこのストアのパスを指定します。第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、これは共有記憶域上のディレクトリにします。

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

2. Oracle SOA Suiteの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_N)。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

3. 新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_N)。このストアのパスを指定します。第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、これは共有記憶域上のディレクトリにします。

ORACLE_BASE/admin/domain_name/soa_cluster_name/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 Modules」を選択します。「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 Modules」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、UCMJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)の構成ウィザードJMS構成から生成されます。

「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

4. 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順は、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。

注意:

サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。
Dtangosol.coherence.localhost=SOAHOST1VHNn

5. 新しいサーバー用の永続ストアを構成します。これは、共有記憶域に関する推奨事項で示されるとおり、他のノードから見える場所にする必要があります。(第4.3項「異なるディレクトリの推奨場所」を参照)。
管理コンソールから、「サービス」タブにあるサーバー名(WLS_SOAn)を選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

6. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名検証を無効化するには:

1. Oracle Enterprise Managerコンソールで、「WebLogic Server管理コンソール」を選択し、ログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 「サマリー」ページまたは「サーバー」ページで、表の「名前」列にある「WLS_SOA」を選択します。

5. サーバーの設定ページで「SSL」タブを開きます。

6. 表示されたページの「詳細」セクションを開きます。

7. 「ロックして編集」をクリックします。

8. ホスト名の検証をNoneに設定します。

9. 「保存」をクリックします。

7. WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. 新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。

2. LBR上のアプリケーション(http://soainternal.mycompany.com/soa-infra)にアクセスします。アプリケーションが機能している必要があります。

注意:

トポロジ内のOracle HTTP Serverは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverのmod_wl_ohs.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

8. 新しい管理対象サーバー用のサーバー移行を構成します。

注意:

これはスケール・アップ操作であるため、ノード・マネージャと、サーバー移行に対して構成された環境が、あらかじめノードに用意されている必要があります。新しいOracle SOA Suite管理対象サーバーの浮動IPも存在している必要があります。

サーバー移行を構成する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成する新しい管理対象サーバー名(ハイパーリンクで表示されている)をクリックします。

4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

5. 「移行の構成」セクションで、移行に参加するサーバーを 「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、SOAHOST1(すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

注意:

移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

9. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

- WLS_SOAn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_SOAn

- ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されることを確認します。

- ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

- ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

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

トポロジのスケール・アウトでは、新しいノードに構成された新しい管理対象サーバーを追加します。

前提条件

この項の手順を実行する前に、次の要件が満たされていることを確認してください。

- Oracle Fusion Middlewareで構成された管理対象サーバーを実行しているノードがトポロジ内に存在しています。

- 新しいノードは、WebLogic ServerとFusion Middlewareの既存のホーム・ディレクトリにアクセスできます。(新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerやFusion Middlewareのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpackとunpackを実行してドメイン構成をブートストラップする必要はあります。)

- ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して、そのノードに共有記憶域内のインストールを追加するには、ORACLE_HOME/oui/bin/attachHome.shを使用します。
WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、User_Home/bea/beahomelistファイルを編集します。次の手順を参照してください。

- 新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。

注意:

コンテンツ・サーバーを含む管理対象サーバーの場合、共有ドメイン・ディレクトリは動作しません。intradoc.cfgなどのドメイン内の特定のファイルは各ノードに固有だからです。ノード固有のファイルの問題を防ぐには、各Oracle WebCenter ContentおよびOracle WebCenter Content: Inbound Refinery管理対象サーバーにローカル(ノードごと)のドメイン・ディレクトリを使用します。

スケール・アウトの手順は、トポロジのコンポーネントによって異なります。

- 第16.7.1項「Oracle WebCenter Contentのスケール・アウト手順」

- 第16.7.2項「Oracle WebCenter Content: Imagingのスケール・アウト手順」

- 第16.7.3項「Oracle SOA Suiteのスケール・アウト手順」

16.7.1 Oracle WebCenter Contentのスケール・アウト手順

エンタープライズ・デプロイメント・トポロジ内でOracle WebCenter Contentのサーバーをスケール・アウトする手順は次のとおりです。

注意:

この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいWebCenter Contentのサーバーを追加することを想定しています。

1. 新しいノードで、Oracle WebCenter Contentのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、WCCHOSTnで次のコマンドを実行します。

cd ORACLE_COMMON_HOME/oui/bin/

./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_version

Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。

3. Oracle WebLogic管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

5. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。

6. WebLogic Server管理コンソールを使用して、WLS_WCC1をクローニングして新しい管理対象サーバーを作成します。これにWLS_WCCnという名前を付けます(nには番号を指定します)。

注意:

この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

7. 新しい管理対象サーバーのリスニング・アドレスとして使用するWCCHOSTnのホスト名またはIPを割り当てます。

8. SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

注意:

他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、手順8、9、10は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバーで使用します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleWCC.jar -template_name=edgdomain_templateScaleWCC

9. 次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをWCCHOSTnにコピーします。

scp edgdomaintemplateScaleWCC.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin

10. 次のように、unpackコマンドをWCCHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateScaleWCC.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

11. ノード・マネージャがまだ起動されていない場合は、新しいノードで起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用し、次のようにWCCHOSTnで新しいノードのホスト名をパラメータとして渡します。

WL_HOME/server/bin/startNodeManager.sh New_Node_IP

注意:

第6.3.1項「Oracle WebLogic Serverのインストールとミドルウェア・ホームの作成」で示されたパスを使用した場合、WL_HOMEは、ORACLE_BASE/product/fmw/wlserver_10.3となります。

12. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_WCCn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名検証を無効化するには:

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 「サーバーのサマリー」ページで、表の「名前」列にある「WLS_WCCn」を選択します。

5. サーバーの設定ページで「SSL」タブを開きます。

6. 表示されたページの「詳細」セクションを開きます。

7. 「ロックして編集」をクリックします。

8. ホスト名の検証をNoneに設定します。

9. 「保存」をクリックします。

13. WebLogic Server管理コンソールで、新しい管理対象サーバーであるWLS_WCCnを起動します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. WLS_WCCnサーバーを選択して、「起動」をクリックします。

5. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。

14. 新しい管理対象サーバーであるWLS_WCCnを構成します。

1. http://WCCHOSTn:16200/csでOracle WebLogic Serverの管理ユーザー名とパスワードを使用してWLS_WCCnにログインします。WebCenter Contentの「構成」ページが表示されます。

注意:

「データベース内のRevisions表が空ではないため、このサーバーを新規インスタンスとして 構成できません。このサーバーは既存のクラスタ内のノードのみに構成できます。」というテキストが、ページの最後に表示されます。

2. 「サーバーの構成」ページで次の値を変更します。「クラスタ・ノード識別子」が、管理対象サーバーのID(WLS_WCCnなど)と一致するように設定されていること、および「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。
- コンテンツ・サーバーのインスタンス・フォルダ: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/csに設定します。

- ネイティブ・ファイル・リポジトリの場所: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/vaultに設定します。

- Webレイアウト・フォルダ: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/weblayoutに設定します。

- ユーザー・プロファイル: これをORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/data/users/profilesに設定します。

3. 完了したら「送信」をクリックし、WebLogic Server管理コンソールを使用して新しい管理対象サーバーを再起動します。

15. LBR上のアプリケーション(https://wcc.mycompany.com/cs)にアクセスしてWLS_WCCn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

注意:

- トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverのmod_wl_ohs.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

- 新しいWebCenter Content管理対象サーバーを追加するためにスケール・アウト手順を実行した場合は、Oracle WebCenter Contentへの接続を作成する間に、この新しく追加したWCCHOSTnが、コンテンツ・サーバー・プールのサーバーのリストに追加されているか確認します。
Content Serverプールに追加されるサーバーは次のとおりです。

- WCCHOST1:4444

- WCCHOST2:4444

- WCCHOST3:4444

詳細は、第11.16項「Oracle WebCenter Contentへの接続の作成」を参照してください。

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

エンタープライズ・デプロイメント・トポロジ内でImagingサーバーをスケール・アウトする手順は次のとおりです。

1. 新しいノードで、Oracle WebCenter Contentのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、WCCHOSTnで次のコマンドを実行します。

cd ORACLE_COMMON_HOME/oui/bin/

./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_version

Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。

3. Oracle WebLogic管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

5. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。

6. WebLogic Server管理コンソールを使用して、WLS_IMG1をクローニングして新しい管理対象サーバーを作成します。これにWLS_IMGnという名前を付けます(nには番号を指定します)。

注意:

この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

7. 新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーのVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、既存の管理対象サーバーとは別のものを使用してください。

注意:

ノードnではVIPを有効にし、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはhosts解決のいずれかで)正しく解決する必要があります。VIPを有効にするには、第9.2項「SOAHOST1でのSOAHOST1VHN1およびSOAHOST2でのSOAHOST2VHN1の有効化」で説明した例に従ってください。

また、新しく作成したサーバーを手順4で追加したマシンに割り当てます。これを実行しない場合、クローン元のサーバーのマシン名が残ります。

8. 新しい管理対象サーバーでOracle WebCenter Content: ImagingのJMSサーバーを作成します。

1. WebLogic Server管理コンソールを使用して、新しいIMGJMSServer用の新しい永続ストアを最初に作成し(IMGJMSServerの作成方法は後述)、IMGJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4.3項「異なるディレクトリの推奨場所」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

2. 新しいJMSサーバーを作成します(たとえば、IMGJMSServer_N)。このJMSサーバーには、前述で作成したIMGJMSFileStore_Nを使用します。IMGJMSServer_Nサーバーのターゲットとして、先ほど作成した管理対象サーバー(WLS_IMGn)を指定します。

9. SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

注意:

他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、この手順は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバー用に使用します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleIMG.jar -template_name=edgdomain_templateScaleIMG

10. 次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをWCCHOSTnにコピーします。

注意:

新しいホストである、WCCHOSTnまたはSOAHOSTnがSOAHOST1と同じMW_HOMEを使用する場合、この手順は不要です。

scp edgdomaintemplateScaleIMG.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin

11. 次のように、unpackコマンドをWCCHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template= edgdomaintemplateScaleIMG.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

12. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_IMGn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとWCCHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名検証を無効化するには:

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 「サーバーのサマリー」ページで、表の「名前」列にある「WLS_IMGn」を選択します。

5. サーバーの設定ページで「SSL」タブを開きます。

6. 表示されたページの「詳細」セクションを開きます。

7. 「ロックして編集」をクリックします。

8. ホスト名の検証をNoneに設定します。

9. 「保存」をクリックします。

13. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用し、次のようにWCCHOSTnで新しいノードのホスト名をパラメータとして渡します。

WL_HOME/server/bin/startNodeManager.sh New_Node_IP

注意:

第6章にある「Oracle WebLogic Serverのインストールとミドルウェア・ホームの作成」で示されたパスを使用した場合は、WL_HOMEは、ORACLE_BASE/product/fmw/wlserver_10.3となります。

14. WebLogic Server管理コンソールで、新しい管理対象サーバーであるWLS_IMGnを起動し、稼働していることを確認します。

15. Oracle WebCenter Content Serverで許可されているホストのリストに、新しいImagingサーバーのリスニング・アドレスを追加します。第11.15項「Oracle WebCenter Contentで許可されたホストのリストに対するImagingサーバーのリスニング・アドレスの追加」の手順に従って、新しいサーバーを、Oracle WebCenter ContentのSocketHostNameSecurityFilter構成に追加します。

16. すべてのOracle WebCenter Content Server管理対象サーバーを再起動します。

注意:

Imaging管理対象サーバーのホスト名が、ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfgファイルにあるSocketHostNameSecurityFilterパラメータ・リストに追加されたことを確認します。

17. LBR上のアプリケーション(https://wcc.mycompany.com/imaging)にアクセスしてWLS_IMGn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

注意:

トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverのmod_wl_ohs.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

18. 新しく追加したサーバー用のサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいノードで定義される権限を検証して、サーバー移行が機能することを確認します。権限の要件の詳細は、第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」を参照してください。

サーバー移行を構成する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成するサーバー名(ハイパーリンクで表示されている)をクリックします。

4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右向き矢印をクリックします。

注意:

マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

19. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

- WLS_IMGn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_IMGn

- ノード・マネージャ・コンソールに、WLS_IMGnの浮動IPが無効になったことを示すメッセージが表示されることを確認します。

- ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

- ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

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

トポロジ内でOracle SOA Suiteサーバーをスケール・アウトする手順は次のとおりです。

注意:

Oracle WebCenter Content: Imagingが使用するOracle SOA Suiteサブシステムのスケール・アウトについては、Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジのドキュメントを参照してください。

1. 新しいノードで、Oracle SOA Suiteのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、SOAHOSTnで次のコマンドを実行します。

cd ORACLE_COMMON_HOME/oui/bin/

./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_version

Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。

3. Oracle WebLogic管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

5. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。

6. WebLogic Server管理コンソールを使用し、WLS_SOA1をクローニングして新しい管理対象サーバーを作成します。これにWLS_SOAnという名前を付けます。nは番号です。

注意:

この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

7. 新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。
このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーのVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、既存の管理対象サーバーとは別のものを使用してください。

8. SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

注意:

他の管理対象サーバーのドメイン・ディレクトリが共有ディレクトリに存在する場合、この手順は不要です。そのかわり、新しいノードは既存のドメイン・ディレクトリをマウントし、これを新しく追加された管理対象サーバー用に使用します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleSOA.jar -template_name=edgdomain_templateScaleSOA

9. 次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをSOAHOSTnにコピーします。

scp edgdomaintemplateScaleSOA.jar oracle@SOAHOSTn:/ORACLE_COMMON_HOME/common/bin

10. 次のように、unpackコマンドをSOAHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template= edgdomaintemplateScaleSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

11. 新しい管理対象サーバーにOracle SOA SuiteおよびUMSのJMSサーバーを作成します。

1. WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_Nのような名前を付けますこのストアのパスを指定します。第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、このディレクトリは共有記憶域上にある必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

2. Oracle SOA Suiteの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_N)。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

3. 新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_N)。このストアのパスを指定します。第4.3項「異なるディレクトリの推奨場所」でお薦めしているように、このディレクトリは共有記憶域上にある必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

4. UMS用の新しいJMSサーバーを作成します(例:UMSJMSServer_N)。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

5. SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、先ほど作成したSOA JMSサーバーを追加します。そのためには、WebLogic Server管理コンソールの「サービス」ノードを開き、「メッセージング」ノードを開きます。「ドメイン構造」ウィンドウで、「JMS Modules」を選択します。「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 Modules」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、UCMJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)の構成ウィザードJMS構成から生成されます。

「UMSJMSServerXXXXXX」サブデプロイメントをクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

12. 新しいサーバー用の永続ストアを構成します。これは、共有記憶域に関する推奨事項で示されるとおり、他のノードから見える場所にする必要があります。(第4.3項「異なるディレクトリの推奨場所」を参照)。
管理コンソールから、「サービス」タブにあるサーバー名(WLS_SOAn)を選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

13. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動および検証を可能にするには、事前にホスト名検証を無効にする必要があります。管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効にされている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名検証を無効化するには:

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 「サーバーのサマリー」ページで、表の「名前」列にある「WLS_SOAn」を選択します。

5. サーバーの設定ページで「SSL」タブを開きます。

6. 表示されたページの「詳細」セクションを開きます。

7. 「ロックして編集」をクリックします。

8. ホスト名の検証をNoneに設定します。

9. 「保存」をクリックします。

14. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用し、次のようにSOAHOSTnで新しいノードのホスト名をパラメータとして渡します。

WL_HOME/server/bin/startNodeManager.sh New_Node_IP

注意:

第6章にある「Oracle WebLogic Serverのインストールとミドルウェア・ホームの作成」で示されたパスを使用した場合は、WL_HOMEは、ORACLE_BASE/product/fmw/wlserver_10.3となります。

15. WebLogic Server管理コンソールで、新しい管理対象サーバーであるWLS_SOAnを起動し、稼働していることを確認します。

16. LBR上のアプリケーション(http://soainternal.mycompany.com/soa-infra)にアクセスしてWLS_SOAn管理対象サーバーをテストします。アプリケーションが機能している必要があります。

注意:

トポロジ内のHTTPサーバーは、新たに追加したサーバーにリクエストをラウンド・ロビンする必要があります(リクエストによっては、クラスタ内のサーバー数に応じて新しいサーバーにヒットする必要がある場合もまれにあります)。Oracle HTTP Serverのmod_wl_ohs.confファイルのWebLogicClusterディレクティブには、クラスタ内のすべてのサーバーを追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

17. 新しく追加したサーバー用のサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいOracle SOA Suite管理対象サーバーの浮動IPも、新しいノードにすでに存在します。

サーバー移行を構成する手順は次のとおりです。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。

3. 「サーバーのサマリー」ページで、表の「名前」列にある移行を構成するサーバー名(ハイパーリンクで表示されている)をクリックします。

4. 選択したサーバーの「設定」ページで、「移行」サブタブを開きます。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右向き矢印をクリックします。

注意:

マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニングをあらかじめ行ってください。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

18. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

- WLS_SOAn管理対象サーバーを強制的に停止します。そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_SOAn

- ノード・マネージャ・コンソールに、WLS_SOAnの浮動IPが無効になったことを示すメッセージが表示されることを確認します。

- ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

- ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。

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

表16-2は、Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。

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

タイプ

ホスト

場所

層

ORACLEホーム(DB)

CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

データ層

MWホーム(OHS)

WEBHOST1およびWEBHOST2

ORACLE_BASE/product/fmw

Web層

MW HOME (SOA Oracleホームも含む)

SOAHOST1およびSOAHOST2*

MW_HOME

SOA OracleホームもMW_HOMEの下: ORACLE_HOME

アプリケーション層

インストール関連ファイル

OraInventory、User_Home/bea/beahomelist、
oraInst.loc、oratab

なし

* WCCHOST1およびWCCHOST2は、SOAHOST1およびSOAHOST2からインストールされたバイナリを使用します。バックアップは、SOAHOST1とSOAHOST2で一元化されています。

表16-3は、Oracle WebCenter Content 11gのエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。

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

タイプ

ホスト

場所

層

アプリケーション・アーティファクト(EARおよびWARファイル)

SOAHOST1、SOAHOST2、WCCHOST1およびWCCHOST2

アプリケーション・アーティファクトの場所を調べるには、管理コンソールですべてのデプロイメントを表示します。

アプリケーション層

Oracle SOA Suiteランタイム・アーティファクト

SOAHOST1またはSOAHOST2

ORACLE_BASE/admin/domain_name/soa_cluster_name

アプリケーション層

Oracle WebCenter Contentランタイム・アーティファクト

WCCHOST1またはWCCHOST2

ORACLE_BASE/admin/domain_name/wcc_cluster_name

アプリケーション層

Oracle WebCenter Content: Imagingランタイム・アーティファクト

WCCHOST1またはWCCHOST2

ORACLE_BASE/admin/domain_name/img_cluster_name

アプリケーション層

Oracle WebCenter Content用にカスタマイズされた管理対象サーバーの構成

WCCHOST1またはWCCHOST2

ORACLE_BASE/admin/domain_name/mserver/domain_name/ucm/cs/bin/intradoc.cfg

および

ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration/wlsifconfig.sh

アプリケーション層

Oracle SOA Suite用にカスタマイズされた管理対象サーバーの構成

SOAHOST1またはSOAHOST2

UMSを使用する場合: DOMAIN_HOME/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml

(*は、デプロイ中にWLSによってランダムに生成される3682yqなどのディレクトリ名を表します)

および

ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration/wlsifconfig.sh

アプリケーション層

Oracle HTTP Serverインスタンス・ホーム

WEBHOST1およびWEBHOST2

ORACLE_BASE/admin/instance_name

Web層

Oracle RACデータベース

CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

データ層

Oracle Fusion Middlewareコンポーネントのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

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

本番エンタープライズ・デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters(RAC)の場合、データベース接続はOracle RACのVIPとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。そのように構成できない場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルの*SQLNET.EXPIRE_TIME=n*パラメータを設定してください。nは分単位の数値です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定してください。

16.10 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 WebCenter Content Imaging開発者ガイドおよび『Oracle WebCenter Contentインストレーション・ガイド』の手順に従います。

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

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

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

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

- 第16.11.3項「SOAサーバーの再起動に失敗したためにポリシー移行が未完になる」

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

- 第16.11.5項「手動フェイルオーバー後に管理サーバーの起動に失敗する」

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

- 第16.11.7項「サーバー移行後にSOAサーバーまたはImagingサーバーがフェイルオーバーしない」

- 第16.11.8項「サーバー移行後にSOAサーバーまたはImagingサーバーにブラウザからアクセスできない」

- 第16.11.9項「OAM構成ツール実行時にURLが削除されない」

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

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

- 第16.11.12項「構成されたJOCポートがすでに使用中」

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

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

- 第16.11.15項「管理対象サーバーのメモリー不足の問題」

- 第16.11.16項「Oracle WebCenter Contentサーバーのマスター・パスワードを再生成する」

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

16.11.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アプリケーションを起動してください。

16.11.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

16.11.3 SOAサーバーの再起動に失敗したためにポリシー移行が未完になる

問題: ノード・マネージャのプロパティをstartScriptEnabled=trueに設定する前にOracle SOA Suiteサーバーを管理コンソールから起動しようとすると、失敗します。このプロパティを設定した後も、サーバーは起動しません。Oracle SOA Suiteサーバーの出力ログには、次のように報告されます。

SEVERE: <.> Unable to Encrypt data
Unable to Encrypt data.
Check installation/post-installation steps for errors. Check for errors during SOA server startup.

ORABPEL-35010
.
Unable to Encrypt data.
Unable to Encrypt data.
Check installation/post-installation steps for errors. Check for errors
during SOA server startup.
.
at oracle.bpel.services.common.util.EncryptionService.encrypt(EncryptionService.java:56)
...

解決方法: クラスタ内の最初のOracle SOA Suiteサーバーの起動が失敗したためにポリシー移行が未完になります。正常に移行するには、次のようにsystem-jazn-data.xmlファイル内の<jazn-policy>要素を編集してbpm-services.jarに権限を付与します。

<grant>
<grantee>
<codesource>
<url>file:${oracle.home}/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>java.security.AllPermission</class>
</permission>
</permissions>
</grant>

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

問題: Oracle SOA Suiteサーバー、Oracle WebCenter ContentサーバーまたはImagingサーバーの起動に失敗します。新しい管理対象サーバー・タイプ用にドメインが拡張されている(たとえば、Imaging用にOracle WebCenter Contentを拡張)か、システムがスケール・アップ(同じタイプの新しいサーバーを追加)されています。Oracle SOA Suiteサーバー、Oracle WebCenter Contentサーバーまたは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管理者ガイドを参照してください。

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

問題: 管理サーバー・ノードに障害が発生して別のノードへの手動フェイルオーバーが実行された後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。

<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/edg_domain/aserver/edg_domain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

解決方法: ノードの障害発生後にノードを復旧させるときに、ドメイン・ディレクトリに共有記憶域が使用されている場合、ロック・クリーンアップの失敗が原因で、管理サーバーのログにこのエラーが記録されることがあります。このエラーを解決するには、ファイルORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lokを削除します。

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

問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。

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

解決方法: これは、管理コンソールでサーバーの起動パラメータが変更された場合に発生する可能性があります。この場合、管理コンソールで、構成を変更した特定のサーバーのサーバー起動構成でユーザー名とパスワードの情報を指定します。

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

問題: ローカルのノード・マネージャによる再起動試行回数が最大数に達した後で、フェイルオーバー・ノードのノード・マネージャが再起動を試行しますが、サーバーは起動しません。ノード・マネージャの出力情報には、サーバーがフェイルオーバーしたことが報告されます。ノード・マネージャがOracle SOA SuiteサーバーまたはOracle WebCenter Content: Imagingサーバーの移行を試行した後でも、このサーバーが使用するVIPがフェイルオーバー・ノード内で有効になりません(フェイルオーバー・ノードでconfigを実行しても、どのインタフェースのVIPも報告されません)。コマンドsudo ifconfig $INTERFACE $ADDRESS $NETMASKを実行しても、そのIPはフェイルオーバー・ノード内で有効になりません。

解決方法: sudo実行時にパスワード入力を要求するような権限と構成を設定しないでください。パスワード入力を要求しなくてもsudoが動作するようにsudoが構成されていることを、システム管理者に確認してください。

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

問題: サーバー移行は正常に実行されます(Oracle SOA SuiteサーバーまたはOracle WebCenter Content: Imagingサーバーがフェイルオーバー・ノード内で再起動される)が、Virtual_Hostname:8001/soa-infraのURLにWebブラウザからアクセスできません。元のホストではすでにサーバーが強制終了(kill)されており、フェイルオーバー・ノードのノード・マネージャでは、VIPが移行済でサーバーが起動していることが報告されます。Oracle SOA SuiteサーバーまたはImagingサーバーが使用するVIPに対して、クライアントのノード(ブラウザが使用されているノード)からpingを実行しても応答がありません。

解決方法: arpingコマンドがノード・マネージャによって実行されてARPキャッシュが更新されましたが、この更新が適切にブロードキャストされていません。この場合、そのノードが外部ノードからは到達不能になります。nodemanager.propertiesファイルを更新してMACBroadcastを追加するか、次のように手動でarpingを実行してください。

/sbin/arping -b -q -c 3 -A -I INTERFACE ADDRESS > $NullDevice 2>&1

ここで、INTERFACEは、仮想IPが有効化されているネットワーク・インタフェース、ADDRESSは仮想IPアドレスです。

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

問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しました。しかし、そのURLの1つに誤記がありました。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。

解決方法: 同じapp_domain名を指定してOAM構成ツールを実行すると、既存ポリシーへの新しいURLの追加のみが行われます。特定のURLを削除するには、OAMのポリシー・マネージャ・コンソールを使用してください。OAMのアクセス管理サイトにログインして、「ポリシー・ドメイン」→「SOA_EDG」(作成済のポリシー・ドメイン)→「リソース」タブをクリックし、誤ったURLを削除します。

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

問題: Oracle WebLogic管理コンソールにアクセスするためにOHSおよびLBRを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。

解決方法: これは、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、コンソールがその変更を反映しようとすると発生します。変更内容によっては、コンソールが管理サーバーのリスニング・アドレスにリダイレクトされることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、URLをwcc.mycompany.com/console/console.portalに変更すれば、管理コンソールのホーム・ページに直接アクセスできます。

注意:

この項で説明されている変更の追跡を無効にしてある場合は、この問題は発生しません。

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

問題: OAMを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻りません)。

解決方法: これは、OAM SSOが構成され、管理コンソールが構成の変更を反映するように設定されている場合に発生することが予想されます(リダイレクトはなんらかの変更をアクティブ化する際に管理コンソールによって実行されます)。このリダイレクトにかかわらず、アクティブ化は完了します。連続して変更を行ってもリダイレクトされないようにするには、管理コンソールにアクセスして、「プリファレンス」→「共有プリファレンス」を選択し、「構成変更の追跡」チェック・ボックスの選択を解除します。

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

問題: Javaオブジェクト・キャッシュを使用している管理対象サーバー(OWSM管理対象サーバーなど)を起動しようとしましたが、失敗しました。次のエラーがログに表示されます。

J2EE JOC-058 distributed cache initialization failure
J2EE JOC-043 base exception:
J2EE JOC-803 unexpected EOF during read.

解決方法: JOCが取得しようとしているポートを別のプロセスが使用しています。そのプロセスを停止するか、このクラスタのJOCを再構成して、推奨されるポート範囲内で別のポートを使用するようにします。

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

問題: Oracle WebCenter Content: Imagingが、起動中に資格証明のアクセス権限を作成し、system-jazn-data.xmlファイルのローカル・ドメイン・ディレクトリ・コピーを更新します。LDAPポリシー・ストアが構成されていない状態で環境をテストしている間に、Oracle WebCenter Content: Imagingサーバーの存在しているドメイン・ディレクトリに、system.jazn-data.xmlファイルへの手動の更新を管理サーバーがプッシュする可能性があります。これによって、ファイルのコピーが上書きされたり、Oracle WebCenter Content: 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()

注意:

接続時には、管理サーバー用の資格証明とアドレスを指定してください。

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

問題: ホスト名ベースのセキュリティ・フィルタがOracle WebCenter Content(config.cfgファイル)で使用されている場合、Oracle WebCenter Content: ImagingからOracle WebCenter Contentに情報量の多いドキュメントをアップロードする際に、大きな遅延とパフォーマンスへの影響がシステム内に発生する可能性があります。この問題の原因は、Imagingサーバーからの接続を許可するためにOracle WebCenter Contentで必要とされるDNSの逆引き参照です。

解決方法: 災害からの保護および異なるホストへのリストアのためにシステム構成を準備する場合、ホスト名ベースのセキュリティ・フィルタを使用することをお薦めします(ホスト名ベースのセキュリティ・フィルタ使用時は、使用される構成がIPにとらわれないものになるため)。ただし、アップロードのパフォーマンスを向上させる必要がある場合は、ホスト名ベースのフィルタのかわりにIPベースのセキュリティ・フィルタを使用できます。

Oracle WebCenter Contentでホスト名ベースのセキュリティ・フィルタをIPベースのフィルタに変更する手順は次のとおりです。

1. テキスト・エディタで、ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfgのファイルを開きます。

2. 次の2行を削除またはコメント・アウトします。

SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|wcchost1vhn1|wcchost2vhn1
AlwaysReverseLookupForHost=Yes

3. WLS_IMG1およびWLS_IMG2管理対象サーバー(それぞれWCCHOST1VHN1およびWCCHOST2VHN1)の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_IMG1とWLS_IMG2のリスニング・アドレスです。(同様に、127.0.0.1がこのリストに含まれている必要があります。)

4. 変更されたconfig.cfgファイルを保存して、Oracle WebCenter Contentのサーバーを再起動し、変更を有効にします。

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

問題: 管理対象サーバーでメモリー不足の問題が発生します。

解決方法: Java VMに割り当てられているメモリー・ヒープのサイズを少なくとも1GBに増やします。

1. Oracle WebLogic管理コンソールにログインします。

2. 「環境」をクリックし、「サーバー」をクリックします。

3. 管理対象サーバー名をクリックします。

4. 「構成」タブを開きます。

5. 2列目にある「サーバーの起動」タブを開きます。

6. 「引数」ボックスでメモリー・パラメータを追加します。例:

-Xms256m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m

注意:

メモリー・パラメータ要件は、各種のJVM(Sun、JRockitなど)ごとに異なる可能性があることに注意してください。詳細は、『Oracle WebCenter Contentインストレーション・ガイド』の管理対象サーバーのJava VMヒープ・サイズの増加に関する項を参照してください。

7. 構成の変更を保存します。

8. 実行されているすべての管理対象サーバーを再起動します。

16.11.16 Oracle WebCenter Contentサーバーのマスター・パスワードを再生成する

Oracle WebCenter Content管理対象サーバーのドメイン・ホームのcwallet.ssoファイルがクラスタ間で不整合を生じたり、ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfigディレクトリにおける無効なコピーによってこのcwallet.ssoファイルが削除または誤って上書きされたりする場合は、次の手順を実行して、このファイルを再生成できます。

1. すべてのOracle WebCenter Content Server管理対象サーバー(WLS_WCCx)を停止します。

2. ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfigのcwallet.ssoファイルを削除します。

3. ORACLE_BASE/admin/domain_name/aserver/wcc_cluster_name/cs/config/privateのpassword.hdaファイルを削除します。

4. WCCHOST1でWLS_WCC1サーバーを起動します。

5. ORACLE_BASE/admin/domain_name/aserver/wcc_cluster_name/cs/config/privateにあるpassword.hdaファイルの作成と同様に、ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfigにあるcwallet.ssoファイルの作成または更新も検証します。

6. Oracle WebCenter Contentのシステム・プロパティのコマンドライン・ツールを使用して、データベースのパスワードを更新します。

7. スタンドアロンのOracle WebCenter Contentアプリケーション(Batchloader、システム・プロパティなど)が正しく機能しているか検証します。

8. cwallet.ssoファイルをORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfigから、ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfigの管理サーバーのドメイン・ディレクトリにコピーします。

9. 2台目のOracle WebCenter Contentのサーバーを起動し、更新されたcwallet.ssoファイルを、管理サーバーがWCCHOST2におけるORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfigにプッシュし、そのファイルがWCCHOST1上のOracle WebCenter Contentのサーバーによって作成または更新されたのと同じファイルであることを検証します。

10. スタンドアロンのOracle WebCenter Contentアプリケーション(Batchloader、システム・プロパティなど)が正しく機能しているか検証します。

11. スタンドアロンのOracle WebCenter Contentアプリケーションが両方のノードで同時に正しく機能することを検証します。

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

Oracle Access Managerのシングル・サインオン(SSO)を使用してWebLogic Serverの管理コンソールにログインする場合、ログアウトボタンをクリックしても、ユーザー・セッションが終了しません。これは、SSOのログアウトのガイドラインに従って、OAMログイン・ページにリダイレクトされるのではなく、ホームページがリロードされるからです。本当にログアウトするには、WebブラウザのCookieを手動で消去する必要があります。

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

新規のOracle RACアプリケーションを開発する場合は、GridLinkデータ・ソースの使用をお薦めします。ただし、GridLinkデータ・ソースをサポートしないレガシー・アプリケーションおよびデータベースを使用している場合は、この付録の情報を参照してください。

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

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

- 付録A.2「EDGトポロジでマルチ・データ・ソースを構成するための標準的な手順」

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

マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。通常、このようなマルチ・データ・ソースへの接続リクエストはすべて、リストの先頭のデータ・ソースによって処理されます。データベース接続テストが失敗して接続を置き換えられなかった場合、またはデータ・ソースが中断された場合は、リストの次のデータ・ソースから順番に接続が検索されます。

Oracle RACでのマルチ・データ・ソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のOracle RACでのマルチ・データ・ソースの使用に関する項を参照してください。

A.2 EDGトポロジでマルチ・データ・ソースを構成するための標準的な手順

ドメインを構成するときにデータ・ソースを構成します。たとえば、エンタープライズ・デプロイメントの参照用トポロジの最初の管理ドメインを構成するときに、構成ウィザードを使用して、ドメインの特性とともにデータ・ソースも定義します。

このエンタープライズ・デプロイメント・ガイド内のトポロジの構成手順には、Oracle RACでGridLinkデータ・ソースを定義するための具体的な手順が含まれています。GridLinkデータ・ソースではなくマルチ・データ・ソースを使用する場合は、GridLinkの手順を次の手順に置き換えてください。

1. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

1. 適切なスキーマを選択します。

2. 「コンポーネント・スキーマのRAC構成」については、「RACマルチ・データ・ソースへ変換」を選択します。

3. リポジトリ作成ユーティリティを実行すると、スキーマの接頭辞とともに次のデータ・ソースが画面に表示されることを確認します。

4. 「次へ」をクリックします。

2. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面(図A-1)が表示されます。

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

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

この画面で、次の手順を実行します。

1. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。

- サービス名: データベースのサービス名を入力します。

- ユーザー名: 対応するコンポーネントのデータベース・スキーマの所有者の完全なユーザー名を入力します。
このガイドでは、データベース・スキーマのユーザー名の接頭辞としてDEVを使用しています。

- パスワード: スキーマへのアクセスに使用するパスワードを入力します。

2. ホスト名、インスタンス名およびポートを入力します。

3. 「追加」をクリックします。

4. この手順をOracle RACインスタンスごとに実行します。

5. 「次へ」をクリックします。

3. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

索引

A B C D E F G H I J K L M N O P R S T U V W X

A

OAMのアクセス・ファイル, 15.4.4.6

アクセス・ゲート, 15.3.3.4

アクセス・サーバー, 15.3.3.8

アダプタ

Oracleファイル・アダプタの高可用性化, 9.11

Oracle FTPアダプタの高可用性化, 9.11

Oracleデータベース・アダプタのスケーリング, 9.12

アドレス・セキュリティ・フィルタ, 10.8, 11.15, 12.8.1, 16.11.14 管理ロール, 15.2.2.2.2 管理ユーザーと管理グループ, 15.2.2.2.1 admin.conf, 8.5.1 管理コンソール

ドメインの作成, 8

変更をアクティブ化するときのエラー, 16.11.6

ホーム・ページへのリダイレクト, 16.11.11

ログイン画面へのリダイレクト, 16.11.10

管理サーバー, 14.4

アプリケーション・ディレクトリの場所, 4.3

ドメインのバックアップ, 8.6

SOAHOST1のboot.properties, 8.4.2

--用のOracle HTTP Serverの構成, 8.5.1

--を使用したドメインの作成, 8.3

cwalletファイル, 10.9, 16.11.16

ホスト名検証の無効化, 8.4.6

SOAHOST1上でのADMINVHNの有効化, 8.2

SOAHOST1へのフェイルオーバー, 8.5.6.3

SOAHOST2へのフェイルオーバー, 8.5.6

リスニング・アドレス, 8.3

リスニング・ポート, 8.3

ポート, 3.5

再起動, 10.7, 11.10, 12.6

フロントエンドURLの設定, 8.5.4

起動の失敗, 16.11.5

SOAHOST1での起動, 8.4.4

検証, 8.4.5

admin.mycompany.com, 3.2.2 ADMINVHN, 3.4

SOAHOST1での--の有効化, 8.2

WebGateのエージェント, 15.4.4 アプリケーション層, 2.1.4, 4.3 アーティファクト, 16.3 Inbound Refineryサーバーと仮想ホストの関連付け, 12.2 Oracle Web層とWebLogicドメインの関連付け, 7.4 attachHome.shスクリプト, 4.3 OIDの属性, 15.2.4.1 認証スキーム, 15.4.4.4 オーセンティケータ

LDAP, 15.2.2.1

OID, 15.2.2.1

OVD, 15.2.2.1

認証プロバイダ, 15.3.6, 15.4.5 認可スキーム, 15.3.3.5, 15.4.4.4

B

バックアップ

管理サーバーを含むドメインの作成後, 8.6

Oracle SOA Suiteを含むドメインの拡張後, 9.15

Oracle WebCenter Contentを含むドメインの拡張後, 10.17

Oracle WebCenter Content: Imagingを含むドメインの拡張後, 11.24

Oracle Fusion Middlewareのインストール後, 6.3.3

データベースへのメタデータ・リポジトリのロード後, 5.5

Oracle HTTP Serverの設定後, 6.2.3

バックアップ

構成ファイル, 15.3.6.1, 15.4.5.1

ドメイン, 9.3

エンタープライズ・デプロイメント, 16.8

インストール, 15.6

OAM 11g用のCookieを使用しない基本スキーム, 15.4.4.5 ベスト・プラクティス

SQLNet接続のタイムアウト, 16.9

管理サーバーのboot.properties, 8.4.2, 15.2.2.2.3 BPEL CSF資格証明, 11.17

C

OIDの属性のカタログ化, 15.2.4.1

証明書

ホスト名の検証, 13.3

自己署名, 13.3.1

クロックの同期, 2.3 クラスタ・エージェント, 1.3 クラスタ通信, 2.1.6 クラスタ

フロントエンドHTTPホストとポート, 9.8, 11.20

ノード間でのマスター・パスワードの共有, 10.9, 16.11.16

クラスタウェア, 1.3 コンポジット, 9.4, 16.3 構成

BPEL CSF資格証明, 11.17

ドメインの作成, 8

資格証明ストア, 15.2, 15.2.2

ノード・マネージャのカスタム・キーストア, 13.3.4

データベース, 5.2

Oracle WebCenter Content: Imaging用のデフォルトのJMS永続ストア, 11.8

デフォルトの永続ストア, 9.10, 11.9

委任フォーム認証, 15.3.3.9

環境変数, 4.2

Inbound Refineryを含むドメインの拡張, 12

Oracle SOA Suiteコンポーネントを含むドメインの拡張, 9

Oracle WebCenter Contentを含むドメインの拡張, 10

Oracle WebCenter Content: Imagingを含むドメインの拡張, 11

フロントエンドHTTPホストとポート, 9.8, 11.20

管理コンソールのフロントエンドURL, 8.5.4

GDFontPath MBean, 11.13

Imaging用の入力ディレクトリ, 11.13

IP検証, 15.3.5

Javaオブジェクト・キャッシュ, 9.6

使用JOCポート, 16.11.12

LDAP, 3.6

ロード・バランサ, 3.3

ノード・マネージャ, 13

WLS_IMG管理対象サーバー用のノード・マネージャ, 10.16, 11.22

WLS_SOA管理対象サーバー用のノード・マネージャ, 9.13

WLS_WCC管理対象サーバー用のノード・マネージャ, 10.16

Oracle Coherence, 9.4

Oracle HTTP Server, 7.5

管理サーバー用のOracle HTTP Server, 8.5.1

WLS_IMG管理対象サーバー用のOracle HTTP Server, 11.19

WLS_SOA管理対象サーバー用のOracle HTTP Server, 9.7

WLS_WCC管理対象サーバー用のOracle HTTP Server, 10.14

ポリシー・ストア, 15.2, 15.2.3

ドメイン構成の伝播, 9.5.6.1, 10.6, 10.10, 11.7, 12.5

Imaging用のサンプル・ディレクトリ, 11.13

サーバー移行, 14

WLS_IMG管理対象サーバー用のサーバー移行, 11.23

WLS_SOA管理対象サーバー用のサーバー移行, 9.14

Oracle WebCenter Contentのサービス再試行, 10.13

共有記憶域, 4.4

サーバー移行のターゲット, 14.7

UMSドライバ, 16.5

仮想ホスト, 7.6

Web層, 7

Webゲート, 15.3.4

WLS_WCC1管理対象サーバー, 10.8

WLS_WCC2管理対象サーバー, 10.11

ワークフロー接続, 11.18

構成MBean, 11.13 構成ウィザード

管理サーバーを含むドメインの作成, 8.3

Oracle SOA Suiteコンポーネントを含むドメインの拡張, 9.3

Oracle WebCenter Contentを含むドメインの拡張, 10.3

Oracle WebCenter Content: Imagingを含むドメインの拡張, 10.3

Oracle WebCenter Content: Inbound Refineryを含むドメインの拡張, 12.3

「GridLink RACコンポーネント・スキーマの構成」画面, 9.3, 10.3, 11.3 configure-joc.py, 9.6 Oracle WebCenter ContentへのImagingの接続, 11.16 コンテンツ・サーバー

Inbound Refineryコンポーネントの有効化, 12.8.3.2

変換ジョブ、Inbound Refinery、設定, 12.8.3 OAM 11g用のCookieを使用しないスキーム, 15.4.4.5 createCentralInventory.shスクリプト, 6.2.2, 6.3.2.1 ドメインの作成, 8 Fusion Middlewareホームの作成, 6.3.1 資格証明ストア, 3.6, 15.2, 15.2.2, 15.2.2.3, 15.2.4, 16.11.13 CredentialAccessPermissions, 16.11.13 Oracle WebCenter Content: Imagingの資格証明, 11.17 Oracle WebCenter Content: ImagingのCSF資格証明, 11.17 CUSTDBHOST, 2.1.5, 5.4

要件, 5.2.1

カスタム・キーストア, 13.3.4, 13.3.5 cwallet.sso, 10.9, 16.11.16

D

データ・ソース, 14.3

データ・ソース, A.2

データ層, 2.1.5, 5.2.1

データベース, 2.1.5

バックアップ, 5.5

コンポーネント, 5.4

接続, 5.4

ホストの要件, 5.2.1

初期化パラメータ, 5.2.3

メタデータ・リポジトリのロード, 5.4

プロセスの最大数, 16.11.4

ポート, 3.5

スキーマの接頭辞, 5.4

サービス, 5.3

設定, 5.2

サポートされているバージョン, 5.2.2

データベース・リスナー・ポート, 2.1.5 データベースのmutexロック, 9.11 委任フォーム認証, 15.3.3.9 コンポジットのデプロイ, 9.4 コンポジットとアーティファクトのデプロイ, 16.3 ディレクトリ環境変数, 4.2 ディレクトリ構造, 4.3

アプリケーション・ディレクトリ(管理サーバー), 4.3

アプリケーション・ディレクトリ(管理対象サーバー), 4.3

図, 4.3

ドメイン・ディレクトリ, 4.3

Imagingのイメージ, 4.3

Imagingの入力ファイル, 4.3

Inbound Refinery, 4.3

JMSファイル・ストア, 4.3

MW_HOME, 4.3

Oracle WebCenter Contentボールト, 4.3

ORACLE_BASE, 4.3

ORACLE_COMMON_HOME, 4.3

ORACLE_HOME, 4.3, 4.3

ORACLE_INSTANCE, 4.3

Tlogs, 4.3

WL_HOME, 4.3

ホスト名検証の無効化

管理サーバー, 8.4.6

WLS_IMG管理対象サーバー用, 11.4

WLS_SOA管理対象サーバー用, 9.5.1

ドメイン

バックアップ, 9.3

ドメインの作成, 8

Oracle SOA Suiteコンポーネントを含むドメインの拡張, 9

Oracle WebCenter Contentを含むドメインの拡張, 10, 12

Oracle WebCenter Content: Imagingを含むドメインの拡張, 11

ドメイン構成の伝播, 9.5.6.1, 10.6, 10.10, 11.7, 12.5

ドメイン構成

伝播, 9.5.4

ドメイン・ディレクトリ, 4.2

adminディレクトリ, 4.3

管理対象サーバーのディレクトリ, 4.3

ドメインのポリシー・ストア, 15.2.3.2

E

ECM、「Oracle WebCenter Content」を参照

SOAHOST1上でのADMINVHNの有効化, 8.2

Oracle WebCenter ContentでのImagingの有効化, 11.14

Enterprise Content Management、「Oracle WebCenter Content」を参照

エンタープライズ・デプロイメント

バックアップとリカバリ, 16.8

利点, 1.4

資格証明ストア, 3.6

ディレクトリ構造, 4.3

環境変数, 4.2

高可用性, 1.4.2

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

LDAP, 3.6

概要, 1.1

ポリシー・ストア, 3.6

セキュリティ, 1.4.1

ソフトウェア, 2.4

用語,1.3

トポロジ, 2.1

環境権限, 14.6 環境変数, 4.2 ドメインの拡張

Inbound Refinery, 12

Oracle SOA Suiteコンポーネント, 9

Oracle WebCenter Content, 10

Oracle WebCenter Content: Imaging, 11

F

フェイルバック, 1.3

SOAHOST1への管理サーバーのフェイルオーバー, 8.5.6.3

SOAHOST2への管理サーバーのフェイルオーバー, 8.5.6

ファイルオーバー, 1.3, 16.11.5, 16.11.7

ファイル形式, Inbound Refinery変換用の選択, 12.8.3.3

ファイアウォール, 3.5

FMW、「Oracle Fusion Middleware (FMW)」を参照

フロントエンドHTTPホストとポート, 9.8, 11.20

管理コンソールのフロントエンドURL, 8.5.4

G

GCCライブラリ, 15.4.3.1

GDFontPath MBean, 11.13

自己署名証明書の生成, 13.3.1

GridLinkデータ・ソース, 14.3

構成, 9.3, 10.3, 11.3

構成の確認, 9.5.3, 10.5, 11.6

GridLink RACコンポーネント・スキーマ, 9.3, 10.3, 11.3

H

ハードウェア要件, 2.2

高可用性, 1.4.2, 9.11

ホーム・ページ、リダイレクト, 16.11.11

ホスト識別子, 15.3.3.6

ホスト名に基づくセキュリティ・フィルタ, 11.15

ホスト名の検証

ノード・マネージャの証明書, 13.3

管理サーバーに対する--の無効化, 8.4.6

WLS_IMG管理対象サーバーに対する--の無効化, 11.4

WLS_SOA管理対象サーバーに対する--の無効化, 9.5.1

管理対象サーバー, 13.3.6

ホスト名

ネットワーク, 1.3

Oracle Coherence, 9.4.2

物理, 1.3

仮想, 1.3

ホスト

データベース, 5.2.1

httpd.conf, 7.6.1

I

IDアサータ, 15.3.6.2, 15.4.5.2

アイデンティティ・キーストア, 13.3.2

IDM、「Oracle Identity Management(IDM)」を参照

Imaging, 1.2

Inbound Refinery, 1.2

仮想ホストとの関連付け, 12.2

構成, 12.8

Content Server, 変換用ジョブの設定, 12.8.3

変換ジョブ

Content Serverから, 12.8.3.1

設定, 12.8.3

ディレクトリの場所, 4.3 Content Serverでのコンポーネントの有効化, 12.8.3.2 ドメインの拡張, 12.3 Content Serverからの送信プロバイダ, 12.8.3.1 変換のファイル形式の選択, 12.8.3.3 起動, 12.7 未完のポリシー移行, 16.11.3 誤ったURL, 16.11.9 増分エンタープライズ・デプロイメント, 2.5.3 Oracle SOA Suiteのインフラストラクチャ・データベース, 16.4 データベースの初期化パラメータ, 5.2.3 Oracle WebCenter Content: Imaging用の入力ディレクトリ, 11.13 Oracle WebCenter Content: Imaging用の入力ファイル戦略, 16.2 inspection.wsil, 15.4.4.4 インストール

ドメインの作成, 8

Oracle SOA Suiteコンポーネントを含むドメインの拡張, 9

Oracle WebCenter Contentを含むドメインの拡張, 10, 12

Oracle WebCenter Content: Imagingを含むドメインの拡張, 11

Fusion Middlewareホーム, 6.3.1

モジュラ・アプローチ, 2.5.3

Oracle Fusion Middleware, 6.3

Oracle Fusion Middlewareのコンポーネント, 6.3.2

Oracle HTTP Server, 6.2

Oracle WebCenter Content, 6.3.2.1, 6.3.2.2

Oracle WebLogic Server, 6.3.1, 6.3.1, 6.3.1

手順, 2.5

ソフトウェア, 6.1

Web層の検証, 7.3

Webゲート, 15.3.4, 15.4.3.2

インストールするコンポーネント, 2.4

統合

Oracle Access Manager 10g, 15.3

Oracle Access Manager 11g, 15.4

IP検証, 15.3.5 IPに基づくセキュリティ・フィルタ, 16.11.14 I/PM、「Oracle WebCenter Content: Imaging」を参照 IP

物理, 1.3, 3.4

仮想, 1.3, 3.4

J

Javaオブジェクト・キャッシュ, 9.6, 16.11.12

Java VM、--のメモリー・ヒープ, 16.11.15

JMSファイル・ストア

場所, 4.3

JMS永続ストア

Oracle WebCenter Content: Imaging, 11.8

JOCポート, 16.11.12

K

キーストア

カスタム, 13.3.4, 13.3.5

アイデンティティ, 13.3.2

信頼, 13.3.3

keytoolユーティリティ, 13.3.3

L

LDAP, 3.6, 15.2.1

管理グループへの管理ロールの割当て, 15.2.2.2.2

WebLogic管理者の移動, 15.2.2.2

管理ユーザーと管理グループのプロビジョニング, 15.2.2.2.1

LDAP認証プロバイダ, 15.2.2.1 サーバー移行用のリース・テーブル, 14.2 leasing.ddlスクリプト, 14.2 リスニング・アドレス

管理サーバー, 8.3

Oracle WebCenter Content: Imaging, 11.15

WLS_IMG管理対象サーバー, 11.3, 11.15

WLS_SOA管理対象サーバー, 9.3

WLS_WCC管理対象サーバー, 10.3, 12.3

リスニング・ポート

管理サーバー, 8.3

WLS_IMG管理対象サーバー, 11.3

WLS_SOA管理対象サーバー, 9.3

WLS_WCC管理対象サーバー, 10.3, 12.3

リスナー・ポート, 2.1.5 ロード・バランサ, 1.4.1

構成, 3.3

Oracle HTTP Serverを使用した構成, 7.5

ポート, 3.5

要件, 2.1.3, 3.3

仮想サーバー, 3.3

データベースへのメタデータ・リポジトリのロード, 5.4 ノード・マネージャのログ・ファイル, 13.1, 13.2 ログイン画面、リダイレクト, 16.11.10 OAMのログアウトのガイドライン, 15.3.3.3 ログアウトURL, 15.3.3.3

M

管理対象サーバー

既存のノードへの追加(Oracle SOA Suite), 16.6.3

既存のノードへの追加(Oracle WebCenter Content: Imaging), 16.6.2

既存のノードへの追加(WebCenter Content), 16.6.1

既存のノードへの追加(WebCenter Content: Imaging), 16.6.2

新規のノードへの追加(Oracle SOA Suite), 16.7.3

新規のノードへの追加(Oracle WebCenter Content), 16.7.1

新規のノードへの追加(Oracle WebCenter Content: Imaging), 16.7.2, 16.7.2

アプリケーション・ディレクトリの場所, 4.3

カスタム・キーストア, 13.3.5

ホスト名検証の無効化, 9.5.1, 11.4

ホスト名の検証, 13.3.6

Java VMのメモリー・ヒープ, 16.11.15

メモリー不足の問題, 16.11.15

ドメイン変更の伝播, 9.5.4

WLS_IMG, 10.16, 11.3, 11.11, 11.19, 11.22, 11.23

WLS_SOA, 9.3, 9.7, 9.13, 9.14

WLS_WCC, 10.3, 10.14, 10.16, 12.3

SOAインフラストラクチャ・データベースでの領域の管理, 16.4 トポロジの管理, 16 手動フェイルオーバー, 16.11.5 仮想IPのマッピング, 3.4 マスター・パスワード, 10.9, 16.11.16 MBean

config, 11.13

GDFontPath, 11.13

Java VMのメモリー・ヒープ, 16.11.15 メタデータ・リポジトリ, 5.4 Middlewareホーム, 1.3 ポリシーの移行, 16.11.3 サーバーの移行、「サーバー移行」を参照, 14 トポロジの監視, 16.1 共有記憶域の場所のマウント, 4.4 mutexロック, 9.11 MW_HOME(アプリケーション層), 4.2, 4.3 MW_HOME (web tier), 4.2

N

Oracle WebCenter Contentのネイティブ・ファイル・リポジトリの場所, 4.3

ネットワーク

ファイアウォール, 3.5

物理IP, 3.4

ポート, 3.5

仮想IP(VIP), 3.4

仮想サーバー名, 3.2

ネットワーク・ホスト名, 1.3 ノード・マネージャ, 13.3.1, 14.4

WLS_IMG管理対象サーバー用の構成, 10.16, 11.22

WLS_SOA管理対象サーバー用の構成, 9.13

WLS_WCC管理対象サーバー用の構成, 10.16

カスタム・キーストア, 13.3.4

ホスト名検証証明書, 13.3

アイデンティティ・キーストア, 13.3.2

管理サーバーに対するリスニング・アドレス, 8.3

SOAHOSTに対するリスニング・アドレス, 9.3, 11.3

WCCHOSTに対するリスニング・アドレス, 10.3, 11.3, 12.3

ログ・ファイル, 13.1, 13.2

ポート, 3.5

プロパティ・ファイル, 14.5

設定, 13

起動, 13.4

SOAHOST1での起動, 8.4.3

SOAHOST2での起動, 9.5.2

WCCHOSTでの起動, 10.4, 11.5, 12.4

信頼キーストア, 13.3.3

ノード

既存の--へのサーバーの追加(Oracle SOA Suite), 16.6.3

既存の--へのサーバーの追加(WebCenter Content), 16.6.1

既存の--へのサーバーの追加(WebCenter Content: Imaging), 16.6.2

新規の--へのサーバーの追加(Oracle SOA Suite), 16.7.3

新規の--へのサーバーの追加(WebCenter Content), 16.7.1

新規の--へのサーバーの追加(Oracle WebCenter Content: Imaging), 16.7.2

1次, 1.3

2次, 1.3

O

OAM、「Oracle Access Manager(OAM)」を参照

OAM11gRequest.xml, 15.4.4.2

OAMCFGツール

情報の収集, 15.3.3.1

実行, 15.3.3.2

OAMHOST, 2.1.3 oamregツール, 15.4.4.3 OHS、「Oracle HTTP Server(OHS)」を参照 OIDの属性, 15.2.4.1 OID認証プロバイダ, 15.2.2.1 Oracle Access Manager(OAM) 10gの統合, 15.3

アクセス・サーバーの追加, 15.3.3.8

OAMCFGツールで使用する情報の収集, 15.3.3.1

構成, 15.3.3

委任フォーム認証, 15.3.3.9

IDアサータ, 15.3.6.2

IP検証, 15.3.5

ログアウトのガイドライン, 15.3.3.3

プロバイダの順序, 15.3.6.3

概要, 15.3.1

前提条件, 15.3.2

OAMCFGツールの実行, 15.3.3.2

WebGateの設定, 15.4.3

ホスト識別子の更新, 15.3.3.6

Webゲート・プロファイルの更新, 15.3.3.7

検証, 15.5

アクセス・ゲートの検証, 15.3.3.4

ポリシー・ドメインの検証, 15.3.3.4

認証スキームの確認, 15.3.3.5

Webゲート, 15.3.4

WebLogic認証プロバイダ, 15.3.6

Oracle Access Manager(OAM) 11gの統合, 15.4

アクセス・ファイル, 15.4.4.6

Cookieを使用しない基本スキーム, 15.4.4.5

GCCライブラリ, 15.4.3.1

IDアサータ, 15.4.5.2

inspection.wsil, 15.4.4.4

WebGateのインストール, 15.4.3.2

oamregツール, 15.4.4.3

プロバイダの順序, 15.4.5.3

概要, 15.4.1

前提条件, 15.4.2

WebGateエージェントの登録, 15.4.4

RREGツール, 15.4.4.1

OAM11gRequestファイルの更新, 15.4.4.2

検証, 15.5

WebLogic認証プロバイダ, 15.4.5

Oracle BI EE

アップグレード・ロードマップ表, 2.5.2

Oracle Coherence, 9.4, 16.11.2 Oracle Commonホーム, 1.3 Oracleデータベース・アダプタ, 9.12 Oracleファイル・アダプタ

--に対する高可用性の有効化, 9.11

Oracle FTPアダプタ

--に対する高可用性の有効化, 9.11

Oracle Fusion Middleware (FMW)

バックアップ, 6.3.3

FMWホームの作成, 6.3.1

FMWコンポーネントのインストール, 6.3.2

Oracle WebLogic Serverのインストール, 6.3.1

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

Oracleホーム, 1.3 Oracle HTTP Server(OHS), 2.1.3

バックアップ, 6.2.3

構成, 7.5

管理サーバーに対する--の構成, 8.5.1

WLS_IMG管理対象サーバーに対する--の構成, 11.19

WLS_SOA管理対象サーバーに対する--の構成, 9.7

WLS_WCC管理対象サーバーに対する--の構成, 10.14

インストール, 6.2

ロード・バランサ, 3.3, 7.5

場所, 6.2.2

ポート, 3.5, 6.2.1

Oracle WebLogic Serverへの--の登録, 8.5.3

管理サーバーへのアクセスの検証, 8.5.5, 8.5.6.2

Oracle SOA Suiteサーバーへのアクセスの検証, 9.9

Oracle WebCenter Contentサーバーへのアクセスの検証, 10.15

Oracle WebCenter Content: Imagingサーバーへのアクセスの検証, 11.21

SSOの検証, 15.5

Oracle Identity Management(IDM)

概要, 2.1.2

Oracleインスタンス, 1.3 Oracle Notification Service

構成, 9.3, 10.3, 11.3

構成の確認, 9.5.3, 10.5, 11.6

Oracle SOA Suite

ドメインのバックアップ, 9.15

--を含むドメインの拡張, 9, 9.3

インストール, 6.3.2.1

ポート, 3.5

Oracle UCM、「Oracle WebCenter Content」を参照 Oracle Web Services Manager(WSM), 2.1.4, 9.6, 16.10 Oracle WebCenter Content, 1.2, 1.2

ドメインのバックアップ, 10.17

Imagingの接続の作成, 11.16

Imagingの有効化, 11.14

--を含むドメインの拡張, 10, 10.3, 12

Imagingを含むドメインの拡張, 11.3

Inbound Refineryを含むドメインの拡張, 12.3

インストール, 6.3.2.2

ネイティブ・ファイル・リポジトリの場所, 4.3

ポート, 3.5

Webサービスのセキュリティ, 16.10

サービス再試行, 10.13

ボールトの場所, 4.3

Oracle WebCenter Content: Imaging, 1.2

Oracle WebCenter Contentセキュリティ・フィルタへのImagingサーバーのリスニング・アドレスの追加, 11.15

ドメインのバックアップ, 11.24

BPEL CSF資格証明の構成, 11.17

ワークフロー接続の構成, 11.18

Oracle WebCenter Contentへの接続の作成, 11.16

Oracle WebCenter Contentでの--の有効化, 11.14

--を含むドメインの拡張, 11

ファイルの場所, 4.3

IPに基づくセキュリティ・フィルタ, 16.11.14

入力ファイルを最適化する戦略, 16.2

ポート, 3.5

資格証明ストアからの資格証明の読取り, 16.11.13

Webサービスのセキュリティ, 16.10

Oracle WebCenter Content: Inbound Refinery, 1.2 Oracle WebLogic Scripting Tool(WLST)

管理サーバーの起動, 8.4.4

Oracle WebLogic Server(WLS), 2.1.4

Oracle Web層との関連付け, 7.4

インストール, 6.3.1

ログアウト, 16.11.17

--へのOracle HTTP Serverの登録, 8.5.3

ORACLE_BASE, 4.2, 4.3 ORACLE_COMMON_HOME, 4.2, 4.3 ORACLE_HOME, 4.2, 4.3 ORACLE_HOME(Web層), 4.3 ORACLE_INSTANCE, 4.2, 4.3 oracleRoot.shスクリプト, 6.2.2 Content ServerからInbound Refineryへの送信プロバイダ, 12.8.3.1 メモリー不足の問題, 16.11.15 OVD認証プロバイダ, 15.2.2.1

P

データベースのパラメータ, 5.2.3

永続ストア, 9.10, 11.9

Oracle WebCenter Content: Imaging, 11.8

物理ホスト名, 1.3 物理IP, 1.3 ポリシー・ドメイン, 15.3.3.4 ポリシー移行, 16.11.3 ポリシー・ストア, 3.6, 15.2

構成, 15.2.3

再関連付け, 15.2.2.3, 15.2.4

再関連付け, 15.2.3.2

ポート, 3.5

管理サーバー, 3.5

データベース, 3.5

フロントエンドHTTPポート, 9.8, 11.20

Imaging, 3.5

使用JOCポート, 16.11.12

ロード・バランサ, 3.5

ノード・マネージャ, 3.5

Oracle HTTP Server, 3.5, 6.2.1

Oracle SOA Suite, 3.5

Oracle WebCenter Content, 3.5

データベース・スキーマの接頭辞, 5.4 1次ノード, 1.3 データベースでのプロセス, 5.2.3, 16.11.4 ドメイン変更の伝播, 9.5.4 ドメイン構成の伝播, 9.5.6.1, 10.6, 10.10, 11.7, 12.5 ノード・マネージャのプロパティ・ファイル, 14.5 保護URL, 15.4.4.2 OAMのプロバイダの順序, 15.3.6.3, 15.4.5.3

R

RACデータベース, 2.1.5, 5.4, A.2

RACデータベース、「データベース」も参照

RCU、「リポジトリ作成ユーティリティ(RCU)」を参照

--の再関連付け, 15.2.2.3, 15.2.4

資格証明ストアの再関連付け, 15.2.2.3, 15.2.4

ドメイン・ポリシー・ストアの再関連付け, 15.2.3.2

ポリシー・ストアの再関連付け, 15.2.2.3, 15.2.4

エンタープライズ・デプロイメントのリカバリ, 16.8

ホーム・ページへのリダイレクト, 16.11.11

ログイン画面へのリダイレクト, 16.11.10

WebLogic ServerへのOracle HTTP Serverの登録, 8.5.3

WebGateエージェントの登録, 15.4.4

リポジトリ作成ユーティリティ(RCU), 5.1

FMWメタデータ・リポジトリのロード, 5.4

要件

クラスタ通信, 2.1.6

データベース・ホスト, 5.2.1

ハードウェア, 2.2

ロード・バランサ, 2.1.3, 3.3

ソフトウェア, 2.4, 6.1

ユニキャスト通信, 2.1.6

再開

管理サーバー, 10.7, 11.10, 12.6

Oracle WebCenter Contentサービスの再試行, 10.13 RREGツール, 15.4.4.1

S

Oracle WebCenter Content: Imaging用のサンプル・ディレクトリ, 11.13

トポロジのスケール・アウト, 16.7

Oracle SOA Suite, 16.7.3

Oracle WebCenter Content, 16.7.1

Oracle WebCenter Content: Imaging, 16.7.2, 16.7.2

Oracleデータベース・アダプタのスケーリング, 9.12 トポロジのスケール・アップ, 16.6

Oracle SOA Suite, 16.6.3

Oracle WebCenter Content, 16.6.1

Oracle WebCenter Content: Imaging, 16.6.2, 16.6.2

画面

GridLink RACコンポーネント・スキーマの構成, 9.3, 10.3, 11.3

スクリプト

attachHome.sh, 4.3

createCentralInventory.sh, 6.2.2, 6.3.2.1

leasing.ddl, 14.2

oracleRoot.sh, 6.2.2

setNMProps.sh, 8.4.3

wlsifconfig.sh, 14.6

2次ノード, 1.3 セキュリティ, 1.4.1 セキュリティ・フィルタ, 10.8, 11.15, 12.8.1, 16.11.14 セキュリティ・ポリシー, 16.10 自己署名証明書, 13.3.1 サーバー移行, 14

WLS_IMG管理対象サーバー用の構成, 11.23

WLS_SOA管理対象サーバー用の構成, 9.14

ターゲットの構成, 14.7

GridLinkデータ・ソースの作成, 14.3

ノード・マネージャのプロパティ・ファイルの編集, 14.5

SSL通信の有効化, 14.4

GridLinkデータ・ソース, 14.3

leasing表, 14.2

環境とスーパー・ユーザー権限の設定, 14.6

ユーザーと表領域の設定, 14.2

テスト, 14.8

トラブルシューティング, 16.11.7, 16.11.8

Oracle WebCenter Contentのサービス再試行, 10.13 ServiceAllowRetry, 10.13 データベースのサービス, 5.3 setNMProps.shスクリプト, 8.4.3 ノード・マネージャの設定, 13 WebLogic認証プロバイダの設定, 15.3.6, 15.4.5 共有記憶域, 1.3

構成, 4.4

図, 4.3, 4.3

構成例, 4.3, 4.3

マウント場所, 4.4

シングル・サインオン検証, 15.5 SOAインフラストラクチャ・データベース, 16.4 SOAHOST, 2.1.4

管理サーバーのboot.properties, 8.4.2

管理サーバーを含むドメインの作成, 8.3

Fusion Middlewareホームの作成, 6.3.1

--でのADMINVHNの有効化, 8.2

SOAHOSTnVHNnの有効化, 9.2

Imagingを含むドメインの拡張, 11.3

Inbound Refineryを含むドメインの拡張, 12.3

Oracle SOA Suiteコンポーネントを含むドメインの拡張, 9.3

Oracle WebCenter Contentを含むドメインの拡張, 10.3

管理サーバーのフェイルオーバー, 8.5.6, 8.5.6.3

Oracle SOA Suiteのインストール, 6.3.2.1

Oracle WebLogic Serverのインストール, 6.3.1

共有記憶域の場所のマウント, 4.4

ドメイン構成の伝播, 9.5.6.1

管理サーバーの起動, 8.4.4

ノード・マネージャの起動, 8.4.3, 9.5.2

WLS_SOA管理対象サーバーの起動, 9.5.5, 9.5.6.2

SOAHOST1VHN1, 3.4

SOAHOST1での--の有効化, 9.2

SOAHOST2VHN1, 3.4

SOAHOST2での--の有効化, 9.2

soa-infraアプリケーション, 16.11.1, 16.11.2 soainternal.mycompany.com, 3.2.3 ソフトウェア

データベース, 5.2.2

インストール, 6.1

Oracle Fusion Middleware, 6.3

Oracle HTTP Server, 6.2

Oracle WebLogic Server, 6.3.1

要件, 2.4, 6.1

バージョン, 2.4, 6.1

SOAインフラストラクチャ・データベースでの領域, 16.4 SQLNet接続、タイムアウト, 16.9 SSL通信, 14.4 SSO検証, 15.5 開始

SOAHOST1での管理サーバー, 8.4.4

ノード・マネージャ, 13.4

SOAHOST1でのノード・マネージャ, 8.4.3

SOAHOST2でのノード・マネージャ, 9.5.2

WCCHOSTでのノード・マネージャ, 10.4, 11.5, 12.4

Oracle WebCenter Content: Imaging, 11.11

WLS_SOA1管理対象サーバー, 9.5.5

WLS_SOA2管理対象サーバー, 9.5.6.2

WLS_WCC1管理対象サーバー, 10.8

WLS_WCC2管理対象サーバー, 10.11

スーパーユーザー権限, 14.6 スイッチバック, 1.3 スイッチオーバー, 1.3 クロックの同期, 2.3 Oracle WebCenter Content: Imaging用のシステムMBean, 11.13

T

サーバー移行の表領域, 14.2

サーバー移行のターゲット, 14.7

用語,1.3

サーバー移行のテスト, 14.8

SQLNet接続のタイムアウト, 16.9

Tlogs

場所, 4.3

トポロジ, 2.1

アプリケーション層, 2.1.4

資格証明ストア, 3.6

データ層, 2.1.5

ディレクトリ構造, 4.3

環境変数, 4.2

ソフトウェアのインストール, 6

管理, 16

監視, 16.1

Oracle Identity Management(IDM), 2.1.2

ポリシー・ストア, 3.6

スケール・アウト, 16.7

スケール・アウト(Oracle SOA Suite), 16.7.3

スケール・アウト(Oracle WebCenter Content), 16.7.1

スケール・アウト(Oracle WebCenter Content: Imaging), 16.7.2, 16.7.2

スケール・アップ, 16.6

スケール・アップ(Oracle SOA Suite), 16.6.3

スケール・アップ(Oracle WebCenter Content), 16.6.1

スケール・アップ(Oracle WebCenter Content: Imaging), 16.6.2, 16.6.2

ソフトウェア, 2.4

Web層, 2.1.3

トランザクション・リカバリ, 9.10, 11.9 トラブルシューティング

管理サーバーでの変更のアクティブ化, 16.11.6

Coherence, 16.11.2

デプロイメント・フレームワークの問題(Coherence), 16.11.2

未完のポリシー移行, 16.11.3

誤ったURL, 16.11.9

WLS管理コンソールからのログアウト, 16.11.17

手動フェイルオーバー, 16.11.5

データベースの最大プロセス数, 16.11.4

Java VMのメモリー・ヒープ, 16.11.15

soa-infraアプリケーションにロード・バランサ経由でアクセスできない, 16.11.1

メモリー不足の問題, 16.11.15

ホーム・ページへのリダイレクト, 16.11.11

ログイン画面へのリダイレクト, 16.11.10

Oracle WebCenter Contentサーバーのマスター・パスワードの再生成, 16.11.16

セキュリティ・フィルタ, 16.11.14

サーバー移行, 16.11.7, 16.11.8

soa-infraアプリケーション, 16.11.1, 16.11.2

信頼キーストア, 13.3.3

U

UCM、「Oracle WebCenter Content」を参照

UMSドライバ, 16.5

ユニキャスト通信, 2.1.6, 9.4

ホスト識別子の更新, 15.3.3.6

Webゲート・プロファイルの更新, 15.3.3.7

URL、保護されている--, 15.4.4.2

utils.CertGenユーティリティ, 13.3.1

utils.ImportPrivateKeyユーティリティ, 13.3.2

V

検証

Oracle HTTP Serverを使用した管理サーバーへのアクセス, 8.5.5, 8.5.6.2

管理サーバー, 8.4.5

OAM統合, 15.5

Oracle HTTP Serverを介したOracle SOA Suiteサーバーへのアクセス, 9.9

Oracle HTTP Serverを使用したOracle WebCenter Contentサーバーへのアクセス, 10.15

Oracle HTTP Serverを使用したOracle WebCenter Content: Imagingサーバーへのアクセス, 11.21

サーバー移行, 14.8

Oracle HTTP Serverを使用したSSO, 15.5

Web層のインストール, 7.3

WLS_SOA1管理対象サーバー, 9.5.5

WLS_SOA2管理対象サーバー, 9.5.6.2

Oracle WebCenter Contentのボールトの場所, 4.3 認証スキームの確認, 15.3.3.5 ソフトウェアのバージョン, 2.4, 6.1

データベース, 5.2.2

VIP、「仮想IP(VIP)」を参照 仮想ホスト名, 1.3 仮想ホスト

ADMINVHN, 3.4

構成, 7.6

SOAHOST1VHN1, 3.4

SOAHOST2VHN1, 3.4

WCCHOST1VHN1, 3.4

WCCHOST2VHN1, 3.4

仮想IP(VIP), 1.3, 3.4

ADMINVHN, 8.2

説明, 3.4

マッピング, 3.4

SOAHOST1VHN1, 9.2

SOAHOST2VHN1, 9.2

VIP4およびVIP5, 11.2

WCCHOST1VHN1, 10.2

WCCHOST2VHN1, 10.2

仮想サーバー

admin.mycompany.com, 3.2.2

ロード・バランサ, 3.3

soainternal.mycompany.com, 3.2.3

wccinternal.mycompany.com, 3.2.4

wcc.mycompany.com, 3.2.1

httpd.confの<VirtualHost>エントリ, 7.6.1

W

wccedg.mycompany.com, 5.3, 5.4

WCCHOST, 2.1.4

VIP4とVIP5の無効化, 11.2

WCCHOSTnVHNnの有効化, 10.2

Oracle WebCenter Contentのインストール, 6.3.2.2

ドメイン構成の伝播, 10.6, 10.10, 11.7, 12.5

ノード・マネージャの起動, 10.4, 11.5, 12.4

Oracle WebCenter Content: Imagingの起動, 11.11

WLS_WCC管理対象サーバーの起動, 10.8, 10.11

WCCHOST1VHN1, 3.4

WCCHOST1での--の有効化, 10.2

WCCHOST2VHN1, 3.4

WCCHOST2での--の有効化, 10.2

wccinternal.mycompany.com, 3.2.4 wcc.mycompany.com, 3.2.1 Webサービス, 16.10 Web層, 2.1.3, 4.3

WebLogicドメインとの関連付け, 7.4

構成, 7

インストールの検証, 7.3

WebCenter Content, 1.2 WebCenter Content、「Oracle WebCenter Content」を参照 Webゲート, 2.1.3

構成, 15.3.5

インストール, 15.3.4, 15.4.3.2

エージェントの登録, 15.4.4

設定, 15.4.3

Webゲート・プロファイル, 15.3.3.7 WEBHOST, 2.1.3

admin.conf, 8.5.1

Web層とWebLogicドメインの関連付け, 7.4

ロード・バランサとOHSの構成 7.5

管理サーバー用のOracle HTTP Serverの構成, 8.5.1

Web層の構成, 7.2

Oracle HTTP Serverのインストール, 6.2.2

ロード・バランサ, 3.3

WebLogic ServerへのOracle HTTP Serverの登録, 8.5.3

Oracle HTTP Serverを使用した管理サーバーへのアクセスの検証, 8.5.5, 8.5.6.2

Oracle HTTP Serverを介したOracle SOA Suiteサーバーへのアクセスの検証, 9.9

Oracle HTTP Serverを使用したOracle WebCenter Contentサーバーへのアクセスの検証, 10.15

Oracle HTTP Serverを使用したOracle WebCenter Content: Imagingサーバーへのアクセスの検証, 11.21

Oracle HTTP Serverを使用したSSOの検証, 15.5

WebLogic管理者、LDAPへの移動, 15.2.2.2 WebLogic認証プロバイダ, 15.3.6, 15.4.5 WebLogicプラグイン有効化フラグ, 8.5.2 WebLogic Serverホーム, 1.3 WebLogic Server、「Oracle WebLogic Server(WLS)」を参照 WL_HOME, 4.2, 4.3 WLS、「Oracle WebLogic Server(WLS)」を参照 WLS_IMG管理対象サーバー, 11.3

Oracle WebCenter Contentへのリスニング・アドレスの追加, 11.15

ノード・マネージャの構成, 10.16, 11.22

Oracle HTTP Serverの構成, 11.19

サーバー移行の構成, 11.23

ホスト名検証の無効化, 11.4

起動, 11.11

WLS_SOA管理対象サーバー, 9.3

ノード・マネージャの構成, 9.13

Oracle HTTP Serverの構成, 9.7

サーバー移行の構成, 9.14

ホスト名検証の無効化, 9.5.1

起動, 9.5.5, 9.5.6.2

WLS_WCC管理対象サーバー, 10.3, 12.3

ノード・マネージャの構成, 10.16

Oracle HTTP Serverの構成, 10.14

起動, 10.8, 10.11

wlsifconfig.shスクリプト, 14.6 Oracle WebCenter Content: Imagingのワークフロー接続, 11.18 WSM,、「Oracle Web Services Manager(WSM)」を参照

X

XWindows環境, 11.13

Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved.