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

11g リリース1(11.1.1.6.0)

B55900-06(原本部品番号:E12037-07)

目次

タイトルと著作権情報

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

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

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

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

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

- 1.3.1 組込みセキュリティ

- 1.3.2 高可用性

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

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

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

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

- 2.1.3 Web層ノードについて

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

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

- 2.1.5 データ層について

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

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

- 2.3 クロックの同期

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

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

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

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

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

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

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

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

- 3.2.1 wcp.mycompany.com

- 3.2.2 admin.mycompany.com

- 3.2.3 wcpinternal.mycompany.com

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

- 3.4 IPおよび仮想IPについて

- 3.5 ファイアウォールとポートについて

- 3.6 資格証明ストアとポリシー・ストアとしてのLDAPについて

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

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

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

- 4.3 各種ディレクトリの推奨場所について

- 4.4共有記憶域の構成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 7.1 Web層構成の概要

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

- 7.3 Oracle HTTP Serverの構成の検証

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

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

- 7.6 仮想ホストの構成

- 7.6.1 httpd.confファイルの編集

- 7.6.2 両方のOHSサーバーの再起動

- 7.6.3 構成の検証

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

- 8.1 ドメイン作成の概要

- 8.2 SOAHOST1でのVIP1の有効化

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

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

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

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

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

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

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

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

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

- 8.4.8 管理サーバーおよびWLS_WSM1管理対象サーバーに対するホスト名の検証の無効化

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

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

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

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

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

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

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

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

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

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

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

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

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

- 8.6.6 SOAHOST2への管理サーバーの手動フェイルオーバー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 9.5.3 Oracle SOA SuiteのためのGridLinkデータ・ソース構成およびONS構成の検証

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

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

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

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

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

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

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

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

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

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

- 9.9 Oracleアダプタの構成

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

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

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

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

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

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

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

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

- 10.3 構成後のタスク

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

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

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

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

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

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

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

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

- 10.4.5 WC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの検証

- 10.4.6 WCPHOST2でのWC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの起動

- 10.4.7 WC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの検証

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

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

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

- 10.8 Analyticsの構成

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

- 10.10 REST APIの構成

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

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

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

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

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

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

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

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

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

- 11.3 SOAHOST1およびWCPHOST1でのノード・マネージャに対するホスト名検証証明書の有効化

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

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

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

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

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

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

- 11.5 SOAHOST2およびWCPHOST2でのノード・マネージャに対するホスト名検証証明書の有効化

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

- 11.5.2 utils.ImportPrivateKeyユーティリティを使用したIDキー・ストアの作成

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

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

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

12 エンタープライズ・デプロイメント用の外部WebCenter Portalサービスの構成

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

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

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

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

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

- 12.3.1 開始前の準備

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

- 12.3.3 WLSTを使用したワークリストとワークフローの構成

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

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

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

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

- 12.6 検索サービスの構成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 13.16.1 必須のコンテンツ・サーバー・コンポーネント(Folders_gおよびWebCenterConfigure)の有効化

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

- 13.16.3 その他のコンテンツ・サーバー機能の追加構成

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

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

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

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

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

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

- 13.18.5 Inbound Refineryの構成

- 13.18.5.1 Inbound Refineryの設定の構成

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

- 13.18.5.3 Inbound RefineryのOracle WebCenter Contentへの構成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 15.4 資格証明とポリシーの再関連付け

- 15.5 Oracle Access Manager 10gの統合

- 15.5.1 Oracle Access Managerの統合の概要

- 15.5.2 Oracle Access Managerの前提条件

- 15.5.3 OAM構成ツールの使用

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

- 15.5.3.2 OAM構成ツールの実行

- 15.5.3.3 RESTポリシーの更新

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

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

- 15.5.3.6 ホスト識別子の更新

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

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

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

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

- 15.5.5 WebgateのIP検証の構成

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

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

- 15.5.6.2 OAM IDアサータの設定

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

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

- 15.6 Oracle Access Manager 11gの統合

- 15.6.1 Oracle Access Managerの統合の概要

- 15.6.2 Oracle Access Managerの前提条件

- 15.6.3 WebGateのインストール

- 15.6.3.1 GCCライブラリのインストールの前提条件

- 15.6.3.2 WebGateのインストール

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

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

- 15.6.4.1 RREGツール

- 15.6.4.2 OAM11gRequestファイルの更新

- 15.6.4.3 oamregツールの実行

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

- 15.6.4.5 RESTポリシーの更新

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

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

- 15.6.5.2 OAM IDアサータの設定

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

- 15.6.6 OAM11gでの仮想ホストの構成

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

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

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

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

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

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

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

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

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

- 15.8.1 認証プロバイダの検証

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

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

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

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

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

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

- 16.3 UMSドライバの構成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 16.8.8 JMS構成の復元

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

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

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

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

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

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

索引

Oracle® Fusion Middleware

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

11g リリース1(11.1.1.6.0)

B55900-06(原本部品番号:E12037-07)

2012年3月

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

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

B55900-06

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

原本著者: Rosie Harvey、Janga Aliminati、Richard Delval

原本協力者: Roy Sandjaja

協力者: Fermin Castro Alonso、Pradeep Bhat、Martin Frys

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

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

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次の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 USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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

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

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

はじめに

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

対象読者

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

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

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

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧だけを行に記述する必要があります。しかし一部のJAWSは括弧だけの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

Oracleサポートへのアクセス

Oracleカスタマは、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/support/contact.htmlまたはhttp://www.oracle.com/accessibility/support.html(聴覚障害者向け)を参照してください。

関連ドキュメント

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

- 『Oracle Application Server管理者ガイド』

- 『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』

表記規則

このドキュメントでは、次の表記規則を使用します。

規則

意味

太字

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

イタリック

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

固定幅フォント

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

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

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

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

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

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

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

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

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

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

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

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

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

- ベスト・プラクティスと推奨アーキテクチャが使用されます。それらは、ハードウェアとオペレーティング・システムには依存していません。

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

仮想ホスト名の用語がこのドキュメントで使用されるときは必ず、仮想IPアドレスで割り当てられることが前提になります。IPアドレスが必要とされたり使用される場合、明示的に言及します。

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

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

1.3 Oracle推奨事項のメリット

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

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

- 第1.3.2項「高可用性」

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

1.3.1 組込みセキュリティ

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

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

注意:

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

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

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

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

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

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

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

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

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

1.3.2 高可用性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

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

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

2.1.2 Oracle Identity Managementの統合について

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

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

2.1.3 Web層ノードについて

Web層のノードはDMZパブリック・ゾーンにあります。

この層では、WEBHOST1とWEBHOST2という2つのノードが、WebGateおよびmod_wl_ohsとともに構成されているOracle HTTP Serverを実行します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

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

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

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

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

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

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

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

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

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

2.1.5 データ層について

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サーバー

ディスク

メモリー

TMPディレクトリ

スワップ

データベース

nXm

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

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

6～8GB

デフォルト

デフォルト

WEBHOSTn

10GB

4GB

デフォルト

デフォルト

SOAHOSTn

10GB脚注 1

10GB

デフォルト

デフォルト

WCPHOSTn

10GB

10GB

デフォルト

デフォルト

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

2.3 クロックの同期

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

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

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

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

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

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

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

コンポーネント

配布メディア

Oracle Database 10gまたは11g

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

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

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

Repository Creation Utility(RCU)

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

Oracle WebLogic Server(WLS)

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 Portal

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

Oracle WebCenter Content

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

Oracle Access Manager (OAM) WebGate

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

Oracle Virtual Directory(OVD)

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

Oracle Internet Directory(OID)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

手順

説明

詳細

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

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

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

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

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

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

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

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

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

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

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

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

Web層の構成

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

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

ドメインの作成

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

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

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

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

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

WebCenter Portalのためのドメインの拡張

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

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

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

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

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

外部WebCenter Portalサービスの構成

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

第12章「エンタープライズ・デプロイメント用の外部WebCenter Portalサービスの構成」

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

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

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

サーバー移行の構成

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

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

Identity Managementとの統合

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 第3.4項「IPおよび仮想IPについて」

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

- 第3.6項「資格証明ストアとポリシー・ストアとしてのLDAPについて」

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

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

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

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

- 第3.2.1項「wcp.mycompany.com」

- 第3.2.2項「admin.mycompany.com」

- 第3.2.3項「wcpinternal.mycompany.com」

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

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

注意:

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

3.2.1 wcp.mycompany.com

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

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

3.2.2 admin.mycompany.com

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

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

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

3.2.3 wcpinternal.mycompany.com

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

クライアントからの入力トラフィックは、SSL対応ではありません。クライアントはwcpinternal.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. ロード・バランサにwcp.mycompany.com:443の仮想サーバーを構成し、この仮想サーバーに対して次のルールを定義します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ヒント:

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

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

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

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

3.4 IPおよび仮想IPについて

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

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

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

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

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

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

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

表3-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)で有効化されます。

3.5 ファイアウォールとポートについて

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

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

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

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

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

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

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

注意:

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

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

タイプ

ファイアウォール

ポートとポート範囲

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

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

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

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

FW0

80

HTTP/ロード・バランサ

インバウンド

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

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

FW0

443

HTTPS/ロード・バランサ

インバウンド

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

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

FW1

80

HTTPS/ロード・バランサ

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

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

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

FW1

443

HTTPS/ロード・バランサ

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

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

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

FW1

80

HTTPS/ロード・バランサ

アウトバウンド

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

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

FW1

443

HTTPS/ロード・バランサ

アウトバウンド

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

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

該当なし

7777

HTTP

該当なし

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

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

FW1

7001

HTTP/t3

インバウンド

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

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

FW1

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

それぞれTCPとHTTP

アウトバウンド

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

WSM-PMのアクセス

FW1

7010

範囲: 7010から7999

HTTP/WLS_WSM-PMn

インバウンド

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

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

該当なし

7010

TCP/IPユニキャスト

該当なし

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

Spaces_Clusterメンバー間の通信

該当なし

9000

TCP/IPユニキャスト

該当なし

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

Portlet_Clusterメンバー間の通信

該当なし

9001

TCP/IPユニキャスト

該当なし

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

Collab_Clusterメンバー間の通信

該当なし

9002

TCP/IPユニキャスト

該当なし

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

Utilities_Clusterメンバー間の通信

該当なし

9003

TCP/IPユニキャスト

該当なし

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

WebCenter Contentアクセス

FW1

16200

HTTP / WLS_WCCn

インバウンド

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

WCC_Clusterメンバー間の通信

該当なし

16200

TCP/IPユニキャスト

該当なし

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

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

該当なし

該当なし

該当なし

該当なし

該当なし

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

FW1

7001

HTTP/管理サーバーとEnterprise Manager

t3

両方

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

ノード・マネージャ

該当なし

5556

TCP/IP

該当なし

該当なし

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

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

FW1

6021 (OAM 10g)

5575 (OAM 11g)

OAP

インバウンド

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

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

FW1

6022

OAP

インバウンド

データベースのアクセス

FW2

1521

SQL*Net

両方

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

Oracle Internet Directoryのアクセス

FW2

389

LDAP

インバウンド

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

Oracle Internet Directoryのアクセス

FW2

636

LDAP SSL

インバウンド

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

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

FW2

4444

TCP/IPソケット

該当なし

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

Inbound RefineryへのWebCenter Portalのアクセス

FW2

5555

TCP/IPソケット

該当なし

該当なし

OWSM用JOC

該当なし

9991

TCP/IP

該当なし

該当なし

デプロイメントの一貫性

該当なし

8088

範囲: 8000から8090

該当なし

該当なし

3.6 資格証明ストアとポリシー・ストアとしてのLDAPについて

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

注意:

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

Oracle Fusion Middleware WebCenter Portalのエンタープライズ・デプロイメント・トポロジでは、第4章「各種ディレクトリの推奨場所について」の説明のとおり、管理サーバーと管理対象サーバーに対して異なるドメイン・ホームが使用されます。そのため、整合性と一貫性を保持するため、Oracle Fusion Middleware WebCenter Portalのエンタープライズ・デプロイメント・トポロジのコンテキストでは、LDAPをポリシー・ストアおよび資格証明ストアとして使用する必要があります。

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

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

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

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

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

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

- 第4.3項「各種ディレクトリの推奨場所について」

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

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

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

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

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

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

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

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

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

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

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

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

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

ヒント:

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

4.3 各種ディレクトリの推奨場所について

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

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

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

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

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

複数のローカル・ドメインに該当するすべての手順は、1つの共有ドメインにも該当します。したがって、ノードごとにドメイン・ディレクトリが1つ使用されるモデルが、このエンタープライズ・デプロイメント・ガイドで使用されています。このディレクトリは、ローカルにも共有記憶域にも配置できます。

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

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

ORACLE_BASE:

/u01/app/oracle

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

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

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

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

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

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

ORACLE_BASE/admin/domain_name/mserver/domain_name

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

注意:

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

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

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

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

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

- マウント元: Oracle SOA Suiteが稼働するすべてのノードでは、別のノードへのサーバー移行が発生したときにトランザクション・ログおよびJMSストアを使用できるように、この共有記憶域の場所をマウントする必要があります。

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

ORACLE_BASE/admin/domain_name/aserver/applications

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

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

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

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

ORACLE_BASE/admin/domain_name/mserver/applications

注意:

このディレクトリは、SOAエンタープライズ・デプロイメントではローカルになります。

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

ORACLE_BASE/product/fmw

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

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

注意:

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

- マウント元: 少なくとも半分のノードで一方のインストールを使用し、もう半分で他方のインストールを使用できるように、ノードではVOL1とVOL2を互換的にマウントします。
WebCenter Portalエンタープライズ・デプロイメント・トポロジでは、SOAHOST1とWCPHOST1は、VOL1をマウントし、SOAHOST2とWCPHOST2はVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域において、考えられる2つのディレクトリを互換的にマウントします。たとえば、SOAHOST1ではORACLE_BASE/product/fmw1、SOAHOST2ではORACLE_BASE/product/fmw2を、それぞれ共有記憶域の場所として使用します。

ORACLE_HOME (Web層):

ORACLE_BASE/product/fmw/web

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

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

注意:

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

このエンタープライズ・デプロイメント・ガイドでは、Oracle Web Tierがローカル・ディスクにインストールされると想定しています。Oracle Web Tierのバイナリ(およびORACLE_INSTANCE)を共有ディスクにインストールすることもできます。その場合は、共有ディスクがアプリケーション層に使用されるものとは別になっている必要があります。

- マウント元: 共有記憶域のインストールでは、少なくとも半分のノードで一方のインストールを使用し、もう半分で他方のインストールを使用できるように、ノードではVOL1とVOL2を互換的にマウントします。
WebCenter Portalエンタープライズ・デプロイメント・トポロジでは、WEBHOST1は、VOL1をマウントし、WEBHOST2はVOL2をマウントします。使用可能なボリュームが1つのみの場合は、ノードは共有記憶域において、考えられる2つのディレクトリを互換的にマウントします。たとえば、WEBHOST1ではORACLE_BASE/product/fmw1、WEBHOST2ではORACLE_BASE/product/fmw2を、それぞれ共有記憶域の場所として使用します。

WL_HOME:

MW_HOME/wlserver_10.3

ORACLE_HOME:

- MW_HOME/wc (WebCenter PortalのOracleホーム)

- MW_HOME/soa (SOA SuiteのOracleホーム)

- MW_HOME/wcc (WebCenter ContentのOracleホーム)

ORACLE_COMMON_HOME:

MW_HOME/oracle_common

ORACLE_INSTANCE(OHSインスタンス):

ORACLE_BASE/admin/instance_name

- 共有ディスクを使用する場合、マシンのマウント・ポイントは次のとおりです。

ORACLE_BASE/admin/instance_name

マウント先:

ORACLE_BASE/admin/instance_name (VOL1)

注意:

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

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

図4-1 ディレクトリ構造

「図4-1 ディレクトリ構造」の説明

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

表4-1は、図において様々な色で識別されている要素の意味に関する説明が記載されています。

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

要素

説明

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

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

固定名です。

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

図4-2は、WebCenter Portal用に複数のボリュームを持つ共有記憶域の構成例を示しています。この例では、SOAHOST1とSOAHOST2を示しています。これに加え、WCPHOST1とWCPHOST2上の管理対象サーバーのディレクトリが、VOL1とVOL2に示されています。

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

表4-2は、ドメインのディレクトリ構造をまとめたものです。この表の各項目は、次のとおりです。

- WLS_WCPは、WC_Spaces、WC_Portlet、WC_Utilities、WC_CollaborationのすべてのWebCenter Portal管理対象サーバーです。

- WLS_WCCは、WLS_IBRを含むWebCenter Content管理対象サーバーであるWLS_WCCです。

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

サーバー

データのタイプ

共有記憶域のボリューム

ディレクトリ

ファイル

WLS_SOA1

Txログ

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

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

WLS_SOA2

Txログ

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

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

WLS_SOA1

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

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

WLS_SOA2

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

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

WLS_SOA1

WLSインストール

VOL1

MW_HOME

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA2

WLSインストール

VOL2

MW_HOME

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP1

WLSインストール

VOL1

MW_HOME

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP2

WLSインストール

VOL2

MW_HOME

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA1

SOAインストール

VOL1

MW_HOME/soa

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA2

SOAインストール

VOL2

MW_HOME/soa

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP1

WebCenter Portalインストール

VOL1

MW_HOME/wc

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP2

WebCenter Portalインストール

VOL2

MW_HOME/wc

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCC1

WebCenter Contentインストール

VOL1

MW_HOME/wcc

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCC2

WebCenter Contentインストール

VOL2

MW_HOME/wcc

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA1

ドメイン構成

VOL1

ORACLE_BASE/admin/domain_name/aserver/domain_name

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

WLS_SOA1

ドメイン構成

VOL1

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_SOA2

ドメイン構成

VOL2

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP1

ドメイン構成

VOL1

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCP2

ドメイン構成

VOL2

ORACLE_BASE/admin/domain_name/mserver/domain_name

各ボリューム内で個別のファイル(ただし、両方のサーバーからは同じディレクトリ構造に見えます)

WLS_WCC1

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

VOL3

ORACLE_BASE/admin/domain_name/wcc_cluster_name/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 共有記憶域の構成

SOAHOST1、SOAHOST2、WCPHOST1、WCPHOST2が2つの別々のボリュームのバイナリ・インストール用に同じ場所を参照できるように、次のコマンドを使用して、共有記憶域の場所を作成しマウントします。

注意:

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

nasfilerは共有記憶域ファイラです。

SOAHOST1とWCPHOST1から:

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

SOAHOST2とWCPHOST2から:

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

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

SOAHOST1から:

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

SOAHOST2から:

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

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

mount nasfiler:/vol/vol1/ORACLE_BASE/stores/soadomain/soa_cluster/tlogs
ORACLE_BASE/stores/soadomain/soa_cluster/tlogs -t nfs

mount nasfiler:/vol/vol1/ORACLE_BASE/stores/soadomain/soa_cluster/tlogs
ORACLE_BASE/stores/soadomain/soa_cluster/tlogs -t nfs

WCPHOST1とWCPHOST2から:

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

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

mount nasfiler:/vol/vol3/ORACLE_BASE/admin/wcdomain/ibr_cluster/
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

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

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

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

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

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

- 第5.2項「データベース要件について」

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

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

- 第5.5項「ランザクション・リカバリ権限のSOAスキーマの構成」

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

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

データベースには、WebCenter Portalエンタープライズ・トポロジ用に、WebCenter PortalコンポーネントやOWSMなどの様々なOracle Fusion Middlewareコンポーネントによって使用される、スキーマのコレクションであるOracle Fusion Middleware Repositoryが用意されています。このデータベースはアイデンティティ管理データベースとは別になっています。これは、Oracle Internet DirectoryやDIPなどのコンポーネントによってアイデンティティ管理のエンタープライズ・デプロイメントで使用されます。

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

後でWebCenter Portalコンポーネントを構成する際には、構成ウィザードによってメタデータ・リポジトリを含むデータベースに接続するための情報の入力が求められます。

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

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

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

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

- 第5.2.3項「初期化パラメータについて」

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

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

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

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

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

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

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

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

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

SQL> SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE PRODUCT LIKE 'Oracle%';

注意:

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

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

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

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

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

構成

パラメータ

必要な値

パラメータ・クラス

SOA

PROCESSES

300以上

静的

WebCenter Portal

PROCESSES

300以上

静的

SOAおよびWebCenter Portal

PROCESSES

600以上

静的

SOA、WebCenter Portal、およびWebCenter Content

PROCESSES

700以上

静的

SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。

SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。

SQL> SHOW PARAMETER processes

次のコマンドを使用して初期化パラメータを設定します。

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE;

データベースを再起動します。

注意:

パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイル、サーバー・パラメータ・ファイル、およびパラメータ値の変更方法の詳細は、Oracle Database管理者ガイドを参照してください。

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

複数の製品スイートで同じデータベースを共有している場合でも、製品スイートごとに別のデータベース・サービスを構成することをお薦めします。また、デフォルトのデータベース・サービスとは別のデータベース・サービスを使用することもお薦めします。

サービスを使用したOracle Databaseへの接続の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドのサービスおよびVIPアドレスを使用したOracle Databaseへの接続の概要に関する説明を参照してください。データベース・サービスを作成および管理する完全に手順については、Oracle Real Application Clusters管理およびデプロイメント・ガイドの 自動ワークロード管理の概要に関する説明を参照してください。

実行時接続ロード・バランシングでは、ロード・バランシングが有効になっている各サービスのサービス・レベルの目標を使用してOracle RACロード・バランシング・アドバイザを構成する必要があります。Oracle RACロード・バランシング・アドバイザには、SERVICE_TIMEまたはTHROUGHPUTを構成できます。接続のロード・バランシングの目標は「短い」に設定します。10gと11gリリース1データベースについては、この変更にDBMS_SERVICEパッケージを使用します。11gリリース2には、かわりにsrvctlコマンド・ユーティリティを使用します。

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

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

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

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

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

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

sqlplus "sys/password as sysdba"

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

注意:

Oracle RACデータベースのサービス名と、それに続けてドメイン名を小文字で入力します。次に例を示します。

wcpedg.mycompany.com

注意:

示したEXECUTE DBMS_SERVICEコマンドは1行に入力します。

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

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

srvctl add service -d wcdb -s wcpedg.mycompany.com -r wcdb1,wcdb2

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

srvctl start service -d wcdb -s wcpedg.mycompany.com

注意:

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

4. 適切なサービス目標に合わせサービスを変更します。

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

または、

SQL>EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'wcpedg.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ユーティリティを使用します。

1. sqlplusにログオンし、サービスを作成します。

sqlplus "sys/password as sysdba"

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

注意:

Oracle RACデータベースのサービス名と、それに続けてドメイン名を小文字で入力します。次に例を示します。

wcpedg.mycompany.com

注意:

示したEXECUTE DBMS_SERVICEコマンドは1行に入力します。

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

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

srvctl add service -d wcdb -s wcpedg.mycompany.com -r wcdb1,wcdb2

注意:

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

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

srvctl start service -d wcdb -s wcpedg.mycompany.com

4. 適切なサービス目標に合わせサービスを変更します。

srvctl modify service -d wcdb -s wcpedg.mycompany.com -B SERVICE_TIME -j SHORT

または、

srvctl modify service -d wcdb -s wcpedg.mycompany.com -B THROUGHPUT  -j SHORT

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

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

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

1. Repository Creation Utility (RCU)のディストリビューションを開きます。

2. RCUホーム・ディレクトリのbinディレクトリからRCUを起動します。
cd RCU_Home/bin

./rcu

3. 「ようこそ」画面で「次へ」をクリックします。

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

5. 「データベース接続の詳細」画面で、データベースの情報を正しく入力します。

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

- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名またはノード名のいずれかをホスト名(CUSTDBHOST1-VIP)として指定します。

- ポート: データベースのポート番号を入力します: 1521

- サービス名: データベースのサービス名(wcpedg.mycompany.com)を入力します。

- ユーザー名: SYS

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

- ロール: SYSDBA

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

6. 接続しているデータベースにUTF8以外のCharsetが含まれていることを示す警告メッセージが表示された場合、多言語をサポートするためにこのデータベースを使用すると、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
「無視」または「停止」をクリックします。

7. 「コンポーネントの選択」画面で、次の手順を実行します。

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

2. 後で使用するため、スキーマ名をメモします。

3. 次を選択します。

- AS共通スキーマ
- Metadata Services

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

- ユーザー・メッセージング・サービス

- WebCenter Portal(すべてのスキーマを選択):
- Spacesおよびサービス

- ポートレット・プロデューサ

- アクティビティ・グラフおよびAnalytics

- ディスカッション

注意:

これによってMetadata Servicesも自動的に選択されます。

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

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

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

ヒント:

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

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

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

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

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

ORACLE_HOME/bin/sqlplus

たとえば、WCPEDG_WEBCENTERユーザーとしてログインし、パスワードを入力します。スキーマ・バージョンのレジストリを検索することで、簡単な確認を実行できます。

-bash-3.00$ $ORACLE_HOME/bin/sqlplus WCPEDG_WEBCENTER/password as SYSDBA
SQL> SELECT version, status FROM schema_version_registry where owner = 'WCPEDG_WEBCENTER';

VERSION STATUS-----------------------------------------11.1.1.6.0 VALID

Oracle WSMポリシーとOWSM MDSスキーマについて

Oracle WSMがWebCenter Portalエンタープライズ・デプロイメントの一部として存在する場合、Oracle WSMポリシーの保存にアイデンティティ管理データベースを使用することをお薦めします。OWSM MDSスキーマに、他のSOAやWebCenter Portalスキーマに使用される情報ではなく、IMデータベース接続情報を使用します。データベースで必要なスキーマを作成するには、IMデータベース情報を使用して前述の手順を繰り返します(RCUを再度実行します)。ただし、手順7の「コンポーネントの選択」画面では「AS共通スキーマ: Metadata Services」のみを選択します。Oracle WSMポリシーの格納にアイデンティティ管理データベースを使用する方法の詳細は、第15項「エンタープライズ・デプロイメントとOracle Identity Managementの統合」を参照してください。

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

WebLogic Serverコンテナのクラッシュ後、進行中のトランザクションをリカバリする際に、Oracle WebLogic Serverトランザクション・マネージャでトランザクション状態の情報を問い合せて該当するコマンド(commitやrollbackなど)を発行するには、適切なデータベース権限が必要です。

これらの権限は、RCU操作で決定されるsoainfraスキーマの所有者に付与する必要があります。

トランザクション・リカバリ権限用のSOAスキーマを構成するには:

1. sysdba権限が付与されたユーザーとしてsqlplusにログオンします。次に例を示します。

sqlplus "/ as sysdba"

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

SQL> Grant select on sys.dba_pending_transactions to wcpedg_soainfra_soainfra;

Grant succeeded.

SQL> Grant force any transaction to wcpedg_soainfra_soainfra;

Grant succeeded.

SQL>

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

データベースにメタデータ・リポジトリをロードした後は、まずバックアップを実行し、その後でエンタープライズ・デプロイメント用ソフトウェアをインストールする必要があります。

データベースのバックアップは、今後の手順で問題が発生した場合に迅速なリカバリを行うために明示的に行います。この目的のためにデータベースのバックアップ計画を使用することも、オペレーティング・システムのツールやRMANを使用して単純にバックアップすることもできます。特にデータベースがOracle ASMを使用して作成された場合は、データベースにOracle Recovery Managerを使用することをお薦めします。可能な場合、オペレーティング・システムのツール(tarなど)を使用してコールド・バックアップも実行できます。

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

この章では、Oracle WebCenter Portalのエンタープライズ・デプロイメントの参照用トポロジに必要なソフトウェアをインストールする手順を説明します。Oracle HTTP Serverをインストールした後に、Oracle Fusion Middlewareをインストールします。

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

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

- 第6.2項「Oracle HTTP Serverのインストール」

- 第6.3項「Oracle Fusion Middlewareのインストール」

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

エンタープライズ・デプロイメントのソフトウェアのインストールは、2つの部分に分割できます。最初の部分では必要なWeb層のインストールについて説明し、2番目の部分では必要なFusion Middleware (FMW)コンポーネントについて説明します。以降の章では、Oracle WebCenter Portalの参照用トポロジを作成するために必要な構成手順を説明します。

ソフトウェアの入手

ソフトウェアを入手する場所の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のOracle Fusion Middlewareソフトウェアの入手に関する項を参照してください。

いずれかのダウンロード場所を選択して、Oracle WebCenter Portalをダウンロードします。.zipアーカイブ・ファイルがシステムに保存されます。

アーカイブ・ファイルをダウンロードした後、インストールを実行するマシン上の任意のディレクトリにアーカイブ・ファイルを解凍します。

インストールするソフトウェア

表6-1に、各ホストにインストールする必要があるソフトウェアまたは各ホストからアクセス可能なソフトウェアを示します。

表6-1 各ホストにインストールする必要があるソフトウェアまたは各ホストからアクセス可能なソフトウェア

ホスト

Oracle
HTTP
Server

Oracle WebLogic Server

Oracle
SOA
Suite

Oracle WebCenter Portal

Oracle WebCenter Content

WEBHOST1

X

WEBHOST2

X

SOAHOST1

X

X

X

X

SOAHOST2

X

X

X

X

WCPHOST1

X

X

X

X

WCPHOST2

X

X

X

X

6.2 Oracle HTTP Serverのインストール

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

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

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

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

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

Oracle HTTP Server (OHS)をインストールする前に、ご使用のマシンが次の要件を満たしていることを確認します。

- 『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』で指定されているように、システム、パッチ、カーネルおよびその他の要件が満たされていることを確認します。

- Oracle HTTP Serverはデフォルトではポート7777にインストールされるので、ノード上のどのサービスでもポート7777を使用していないことを確認する必要があります。このポートが使用中かどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。

netstat -an | grep 7777

ポート7777が使用されている場合は解放する必要があります。

- Linuxプラットフォームで、/etc/oraInst.locファイルが存在する場合はその内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、およびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locが存在しない場合は、この手順を省略してもかまいません。

- インストールを開始する前に、次の環境変数が設定されていないことを確認します。

- LD_ASSUME_KERNEL

- ORACLE_INSTANCE

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

第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

Oracle HTTP ServerをWEBHOST1およびWEBHOST2にインストールするには:

1. Oracle HTTP Serverのインストーラを次のインストール・メディアから起動します。
./runInstaller

2. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. 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のインストール後、ORACLE_HOMEディレクトリに次のディレクトリが表示されることを確認し、インストールが成功したことを確認します。

- oracle_common

- web

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

この時点でFusion Middlewareホームをバックアップする必要があります(この時点ですべてのサーバーが停止していることを確認します)。

WEBHOST1> tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw HOME/oraInventory

6.3 Oracle Fusion Middlewareのインストール

この項では、Oracle WebCenter Portalのエンタープライズ・デプロイメントの参照用トポロジに必要なOracle Fusion Middlewareソフトウェアをインストールする方法を説明します。インストールするソフトウェア・コンポーネントは、Oracle WebLogic Serverホーム(WL_HOME)およびOracleホーム(ORACLE_HOME)です。第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のとおり、冗長性を確保するため、Oracle Fusion Middlewareを記憶域上の少なくとも2つの場所にインストールします。

注意:

セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

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

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

- 第6.3.2項「Oracle Fusion Middlewareコンポーネントのインストール」

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

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

SOAHOST1、SOAHOST2、WCPHOST1およびWCPHOST2にOracle WebLogic Serverをインストールします。

注意:

WebLogic Serverを、64ビットJDKを使用して64ビット・プラットフォームにインストールする場合は、この項の手順ではなく、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』の64ビットJDKを使用した64ビット・プラットフォームへのWebLogic Serverのインストールに関する項を参照してください。

Oracle WebLogic Serverをインストールするには:

1. Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。

$ ./wls1036_linux32.bin

2. 「ようこそ」画面で、「次へ」をクリックします。

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、次の手順を実行します。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します

注意:

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

ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。このディレクトリは/u01/app/oracleとすることをお薦めします。詳細は、第4.3項「各種ディレクトリの推奨場所について」を参照してください。

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

4. 「セキュリティ更新のための登録」画面で、セキュリティ更新の通知を受け取る連絡先の情報を入力して、「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「カスタム」を選択し、「次へ」をクリックします。

6. 「製品とコンポーネントの選択」画面で「次へ」をクリックします。

7. 「JDKの選択」画面で、「Oracle JRockit 1.6.0_<version> SDK」のみを選択して「次へ」をクリックします。

8. 「製品インストール・ディレクトリの選択」画面で、ORACLE_BASE/product/fmw/wlserver_10.3とORACLE_BASE/product/fmw/coherence_3.7を受け入れ、「次へ」をクリックします。

9. 「インストールの概要」画面で「次へ」をクリックします。
Oracle WebLogic Serverソフトウェアがインストールされます。

10. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

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

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

- 第6.3.2.1項「Oracle SOA Suiteのインストール」

- 第6.3.2.2項「Oracle WebCenter Portalのインストール」

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

6.3.2.1 Oracle SOA Suiteのインストール

Oracle SOA SuiteをSOAHOST1、SOAHOST2、WCPHOST1およびWCPHOST2にインストールするには、次の手順を実行します。

注意:

インストールは共有記憶域で実行されるため、MW_HOMEは、WCPHOST1とWCPHOST2のOracle WebCenter Portalによってアクセスおよび使用が可能です。

1. Linuxプラットフォームで、/etc/oraInst.locファイルが存在する場合はその内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、およびそのディレクトリに対する書込み権限があることを確認します。/etc/oraInst.locが存在しない場合は、この手順を省略してもかまいません。

2. Oracle SOA Suiteのインストーラをインストール・メディアから起動します。

./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します(例: ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version)。詳細は、第6.3.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」を参照してください。

3. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

2. インストールを実行しているユーザーの「オペレーティング・システム・グループ」名を入力します。

3. 「OK」をクリックします。

画面上の指示に従い、root権限で/createCentralInventory.shを実行します。「OK」をクリックします。

注意:

「インベントリ・ディレクトリの指定」画面は、UNIXオペレーティング・システムで、Oracle Universal Installerによる初めてのインストール時のみ表示されます。インストーラは、インベントリ・ディレクトリを使用して、マシンにインストールしたすべてのOracle製品を追跡します。

4. 「ようこそ」画面で、「次へ」をクリックします。

5. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

6. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「OK」をクリックします。

7. 「インストール場所の指定」画面で、Oracle SOA Suiteのインストール場所を指定します。すでにインストールされているOracleミドルウェア・ホームをドロップダウン・リストから選択します。Oracleホーム・ディレクトリには、SOA Suiteのディレクトリ名(soa)を入力します。

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

「図6-1 インストーラ・ウィザードの「インストール場所の指定」画面」の説明

完了したら、「次へ」をクリックします。

8. Application Server画面で、WebLogic Serverを選択し、「次へ」をクリックします。

9. 「インストールの概要」画面で「インストール」をクリックします。
Oracle Fusion Middleware SOA Suiteソフトウェアがインストールされます。

10. 「インストール完了」画面で「終了」をクリックします。

11. Oracle WebLogic SeverおよびOracle SOA Suiteの両方のインストールが完了したら、ORACLE_HOMEディレクトリに次のファイルとディレクトリが表示されることを確認し、インストールを確認します。

- coherence_X.X

- jrockit-jdkY.Y

- modules

- oracle_common

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- soa

- wlserver_10.3

6.3.2.2 Oracle WebCenter Portalのインストール

Oracle WebCenter PortalをSOAHOST1、SOAHOST2、WCPHOST1およびWCPHOST2にインストールするには、次の手順を実行します。

1. Oracle WebCenter Portalのインストーラを起動します。

./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します(例: ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version)。詳細は、第6.3.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」を参照してください。

2. 「インベントリ・ディレクトリの指定」画面で、次の手順を実行します。

1. HOME/oraInventoryと入力します。ここでHOMEは、インストールを実行しているユーザーのホーム・ディレクトリです(推奨の場所)。

2. インストールを実行しているユーザーの「オペレーティング・システム・グループ」名を入力します。

3. 「OK」をクリックします。

注意:

「インベントリ・ディレクトリの指定」画面は、UNIXオペレーティング・システムで、Oracle Universal Installerによる初めてのインストール時のみ表示されます。インストーラは、インベントリ・ディレクトリを使用して、マシンにインストールしたすべてのOracle製品を追跡します。

3. 「ようこそ」画面で、「次へ」をクリックします。

4. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

5. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「OK」をクリックします。

6. 「インストール場所の指定」画面で、Oracle WebCenter Portalのインストール場所を指定します。すでにインストールされているOracleミドルウェア・ホームをドロップダウン・リストから選択します。Oracleホーム・ディレクトリには、WebCenter Portalのディレクトリ名(wc)を入力します。
「次へ」をクリックします。

7. Application Server画面で、WebLogic Serverを選択し、「次へ」をクリックします。

8. 「インストールの概要」画面で「インストール」をクリックします。
Oracle WebCenter Portalソフトウェアがインストールされました。

9. 「インストール完了」画面で「終了」をクリックします。

10. Oracle WebLogic Sever、Oracle SOA Suite、Oracle WebCenter Portalのインストールが完了したら、ORACLE_HOMEディレクトリに次のディレクトリとファイルが表示されることを確認し、インストールを確認します。

- coherence_version

- jrockit-jdkversion

- modules

- oracle_common

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- soa

- wc

- wlserver_10.3

6.3.2.3 Oracle WebCenter Contentのインストール

Oracle WebCenter ContentをSOAHOST1、SOAHOST2、WCPHOST1およびWCPHOST2にインストールするには、次の手順を実行します。

1. Oracle WebCenter Contentのインストーラを起動します。

./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します(例: ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version)。詳細は、第6.3.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」を参照してください。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ソフトウェア更新のインストール」画面で、「ソフトウェアの更新のスキップ」を選択して、「次へ」をクリックします。

4. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

5. 「インストール場所の指定」画面で、Oracle WebCenter Contentをインストールする場所を指定します。すでにインストールされているOracleミドルウェア・ホームをドロップダウン・リストから選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(wcc)を入力します。
完了したら、「次へ」をクリックします。

6. 「アプリケーション・サーバー」画面で、「WebLogic Server」が選択されていること(デフォルト)を確認してから「次へ」をクリックします。

7. 「インストールの概要」画面で「インストール」をクリックします。
Oracle WebCenter Contentソフトウェアがインストールされます。

8. 「インストール完了」画面で「終了」をクリックします。

9. Oracle WebLogic Sever、Oracle Fusion Middleware for SOA、Oracle WebCenter PortalおよびOracle WebCenter Contentのインストールが完了したら、ORACLE_HOMEディレクトリに次のディレクトリとファイルが表示されることを確認し、インストールを確認します。

- coherence_version

- jrockit-jdkversion

- modules

- oracle_common

- registry.xml

- utils

- domain-registry.xml

- logs

- ocm.rsp

- registry.dat

- soa

- wc

- wlserver_10.3

- wcc

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

この時点でSOAHOST1からFusion Middlewareホームをバックアップする必要があります(まず、サーバーが停止していることを確認します)。

tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw

これによって、Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントの両方のインストール・ファイルのバックアップが作成されます。

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

この章では、Oracle Fusion Middleware WebCenter Portalの実装をサポートするOracle Web層の構成方法を説明します。

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

- 第7.1項「Web層構成の概要」

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

- 第7.3項「Oracle HTTP Serverの構成の検証」

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

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

- 第7.6項「仮想ホストの構成」

7.1 Web層構成の概要

Oracle Web層ソフトウェアを構成する前に、第6.2項「Oracle HTTP Serverのインストール」の説明に従ってこのソフトウェアをWEBHOST1とWEBHOST2にインストールする必要があります。構成ウィザードを実行して、インスタンス・ホーム、インスタンス名およびOracle HTTP Serverコンポーネント名を定義します。

この章では、Oracle Web層をWebLogic Serverドメインに関連付ける方法についても説明します。Web層をWebLogic Serverに関連付けすると、Oracle Fusion Middlewareコンソールを使用してWeb層を監視できるようになります。

その後、すべてのHTTPリクエストをWEBHOST1およびWEBHOST2にルーティングするようロード・バランサを構成します。

最後の項では、両方のOHSサーバーで、httpd.confファイルの<VirtualHost>セクションのディレクティブを定義する方法を説明します。これらの仮想ホスト名は、第3.3項「ロード・バランサの構成」でロード・バランサを構成したときに作成したものです。

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

Oracle Web層の構成手順は、WEBHOST1とWEBHOST2で同じです。

Oracle Web層を構成する手順は次のとおりです。

1. Oracle Fusion Middleware構成ウィザードの場所にディレクトリを変更します。

WEBHOST1> cd ORACLE_COMMON_HOME/common/bin

2. 構成ウィザードを起動します。

WEBHOST1> ./config.sh

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「コンポーネントの構成」画面で「Oracle HTTP Server」を選択し、「選択されたコンポーネントとWebLogicドメインの関連付け」の選択を解除します。「Oracle Web Cache」は選択されていないことを確認します。
「次へ」をクリックします。

5. 「コンポーネントの詳細の指定」画面で、次の値を指定します。

- インスタンス・ホームの場所: /u01/app/oracle/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の構成の検証

インストールが完了したら、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の両方で実行します。

WEBHOSTn> cd ORACLE_BASE/admin/instance_name/bin
WEBHOSTn> ./opmnctl registerinstance -adminHost ADMINVHN  -adminPort 7001 -adminUsername weblogic

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

Oracle HTTP Server(WEBHOST1、WEBHOST2)を実行するホストへすべてのHTTPリクエストをルーティングするようロード・バランサを構成できます。Oracle HTTP ServerがフロントエンドのOracle WebLogic Serverである場合は、ロード・バランサでスティッキー・セッション(クッキーの挿入)を有効にする必要はありません。このドキュメントで説明するトポロジには該当しませんが、ロード・バランサからOracle WebLogic Serverに直接移動する場合にはスティッキー・セッションが必要です。

使用するロード・バランサによって、構成手順は異なります。具体的な手順は、ロード・バランサのドキュメントを参照してください。

7.6 仮想ホストの構成

仮想ホストを構成するには、次の3つのタスクを実行します。

- 両方のOHSサーバーで、httpd.confファイルの<VirtualHost>セクションのディレクティブを定義します。

- 両方のOHSサーバーを再起動します。

- 構成を検証するために仮想ホストのURLにアクセスします。

7.6.1 httpd.confファイルの編集

両方のOHSサーバーで、httpd.confファイルの<VirtualHost>セクションのディレクティブを定義します。このファイルは、ORACLE_BASE/admin/instance_name/config/OHS/ohs1 (またはohs2)ディレクトリにあります。次のエントリをこのファイルに追加します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://wcp.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 wcpinternal.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

7.6.2 両方のOHSサーバーの再起動

httpd.confファイルを変更した後で両方のOHSサーバーを再起動します。

WEBHOST> cd ORACLE_BASE/admin/<instance_name>/bin
WEBHOST> opmnctl stopall
WEBHOST> opmnctl startall

7.6.3 構成の検証

次のURLにアクセスして、ロード・バランサとOracle HTTP Serverが正しく構成されていることを確認します。

- https://wcp.mycompany.com/index.html

- http://admin.mycompany.com/index.html

- http://wcpinternal.mycompany.com/index.html

これらのURLにアクセスできない場合は、第3.3項「ロード・バランサの構成」の手順を正しく実行していることを確認してください。

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

この章では、構成ウィザード、Oracle WebLogic Server管理コンソール、Oracle Enterprise ManagerおよびOracle WSM Policy Managerを使用してドメインを作成する方法を説明します。ドメインを拡張してWebCenter Portalコンポーネントを追加できます。

注意:

セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

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

- 第8.1項「ドメイン作成の概要」

- 第8.2項「SOAHOST1でのVIP1の有効化」

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

- 第8.4項「構成後タスクおよび検証タスク」

- 第8.5項「SOAHOST2へのドメイン構成の伝播」

- 第8.6項「WebLogicドメインのOracle HTTP Serverの構成」

- 第8.7項「WebLogicドメイン構成のバックアップ」

8.1 ドメイン作成の概要

表8-1に、構成後タスクを含む、WebLogicドメインの作成手順を示します。

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

手順

説明

詳細

SOAHOST1でのVIP1の有効化

SOAHOST1ホスト名に対しVIP1を有効にします。

第8.2項「SOAHOST1でのVIP1の有効化」

WebLogicドメインの作成

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

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

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

構成後タスクおよび検証タスクの手順に従います。

第8.4項「構成後タスクおよび検証タスク」

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

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第8.5項「SOAHOST2へのドメイン構成の伝播」

WebLogicドメインでのOracle HTTP Serverの構成

Oracle HTTP ServerをWebLogicドメインを使用して構成し、構成を検証します。

第8.6項「WebLogicドメインのOracle HTTP Serverの構成」

ドメインのバックアップ

新しく構成したWebLogicドメインをバックアップします。

第8.7項「WebLogicドメイン構成のバックアップ」

このドメインを作成し構成したら、ドメインを拡張し、次の章で説明するとおり、Oracle WebCenter Portalコンポーネント、Oracle SOA Suite、Oracle WebCenter Contentなどを含めることができます。

8.2 SOAHOST1でのVIP1の有効化

SOAがインストールされているかどうかにかかわらず、この手順は管理サーバーのフェイルオーバーを可能にするために必要です。

管理サーバーは仮想ホスト名(ADMINVHN)に関連付けます。仮想ホスト名は、DNSサーバーとカスタムの/etc/hostエントリのいずれかによって、適切なVIP(VIP1)にマップする必要があります。SOAトポロジの必要なノードで、名前解決システム(DNSサーバー、/etc/hosts)に従ってADMINVHNが使用可能であることを確認します。この仮想ホスト名(ADMINVHN)に関連付けられたVIP(VIP1)は、SOAHOST1で有効になっている必要があります。

Linuxで仮想IPを有効にする手順は次のとおりです。

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

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

次に例を示します。

/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_COMMON_HOMEディレクトリから構成ウィザードを実行し、管理サーバーとOracle Web Services Managerを含むドメインを作成できます。その後、ドメインを拡張してWebCenter Portal、SOAおよびWebCenter Contentコンポーネントを含めることができます。

ドメインを作成する手順:

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておく必要があります。

2. SOAHOST1で、ディレクトリを次の構成ウィザードの場所に変更します。

cd ORACLE_COMMON_HOME/common/bin

3. Oracle Fusion Middleware構成ウィザードを開始します。

./config.sh

4. 「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

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 WSM Policy Manager 11.1.1.0 [oracle_common]

- Oracle JRF - 11.1.1.0 [oracle_common](これは自動的に選択されます)

いくつかのターゲットを間違って選択解除した場合は、この画面で次の項目が選択されていることを確認します。

- Oracle Enterprise Manager

- Oracle WSM Policy Manager

- Oracle JRF

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

注意:

複数のOracleホームがインストールされている場合(たとえば、WebCenter PortalホームとSOAホーム)、どちらのホームについても、使用可能な製品が表示されます。この手順では、WebCenter Portalホーム(wc)の製品のみを選択します。これは、たとえば、Oracle JRF - 11.1.1.0 [wc]のように、製品名の末尾に角かっこで囲んで示されます。

6. 「ドメイン名と場所の指定」画面でドメイン名(wcpedg_domain)を入力します。
ドメイン・ディレクトリが第3項「エンタープライズ・デプロイメント用のネットワークの準備」で推奨しているディレクトリと共有ストレージのマウント・ポイントと一致することを確認します。

ドメイン・ディレクトリに、次を入力します。

ORACLE_BASE/admin/domain_name/aserver

アプリケーション・ディレクトリに、次を入力します(このディレクトリは共有記憶域内のものである必要があります)。

ORACLE_BASE/admin/domain_name/aserver/applications

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

8. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者が使用するユーザー名とパスワードを入力します。
「次へ」をクリックします。

9. 「サーバーの起動モードおよびJDKの構成」画面で、次の手順を実行します。

- 「WebLogicドメインの起動モード」には、「本番モード」を選択します。

- 「JDKの選択」では、「JROCKIT SDK1.6.0_<version>」を選択します。

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

10. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. OWSM MDSスキーマを選択します。

2. RACの構成には、(付録A「Oracle RACでのマルチ・データ・ソースの使用」で説明した)「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます。
ここの手順では、「GridLinkへ変換」を選択します。

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

11. 「GridLink RACコンポーネント・スキーマの構成」画面(図8-2)が表示されます。

図8-2 GridLink RACコンポーネント・スキーマの構成

「図8-2 GridLink RACコンポーネント・スキーマの構成」の説明

この画面で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「OracleのGridLinkConnectionsドライバ(Thin)、バージョン: 10以降」を選択します。

- サービス名: Oracle RACデータベースのサービス名と、続けてドメイン名を小文字で入力します。たとえば、wcpedg.mycompany.comです。

- ユーザー名: 対応するコンポーネントのデータベースのスキーマ所有者の完全な名前(接頭辞を含む)を入力します。

- パスワード: データベース・スキーマ所有者のパスワードを入力します。

- 「FANの有効化」を選択します。

- 「SSLの有効化」のチェックが選択解除されていることを確認します(または、ONS通知の暗号化にSSLが選択されている場合、適切なウォレットとウォレット・パスワードを入力します)。

- サービス・リスナー: 使用しているOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。このプロトコルは、TCPである必要があります。
Oracle RACノードの追加または削除時にSCANアドレスを含むGridLinkデータ・ソースを更新する必要がないよう、サービス・リスナー(とOSNホスト)の指定にはSCANアドレスを使用することをお薦めします。SCANアドレスを判断するには、TCPプロトコルを使用し、データベースのremote_listenerパラメータを問い合わせます。

SQL>show parameter remote_listener;

NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      db-scan.mycompany.com:1521

注意:

データベース・バージョンがSCANをサポートしない場合は次を実行します。

- Oracle Database 11gリリース1 (11.1)の場合、各データベースのインスタンス・リスナーの仮想IPとポートを次のように入力します。
custdbhost1-vip.mycompany.com (Port 1521)

および

custdbhost2-vip.mycompany.com (Port 1521)

- Oracle Database 10gの場合、マルチ・データ・ソースを使用し、Oracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: データベースからの通知のとおり、Oracle RACデータベースとONSリモート・ポートのSCANアドレスを入力します。

[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 (Port 6200)

12. 「JDBCデータ・ソースのテスト」画面で、各接続のテストが自動的に行われます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

13. 「詳細構成の選択」画面で、次の項目を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

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

14. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: ADMINVHN

- リスニング・ポート: 7001

- SSLリスニング・ポート: 該当なし

- SSL有効: 選択解除

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

15. 「管理対象サーバーの構成」画面で、「追加」をクリックして次の管理対象サーバーを追加します。

表8-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_WSM1

SOAHOST1

7010

該当なし

いいえ

WLS_WSM2

SOAHOST2

7010

該当なし

いいえ

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

16. 「クラスタの構成」画面で、「追加」をクリックして次のクラスタを追加します。

表8-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

WSM-PM_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

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

17. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- WSM-PM_Cluster:

- WLS_WSM1

- WLS_WSM2

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

18. 「マシンの構成」画面で、次の手順を実行します。

- 「UNIXマシン」タブをクリックし、「追加」をクリックして次のマシンを追加します。

注意:

「名前」には任意の一意な文字列を指定できます。「ノード・マネージャ・リスニング・アドレス」には解決可能なホスト名を指定する必要があります。

表8-4 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

localhost

その他すべてのフィールドはデフォルト値のままにします。

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

19. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- SOAHOST1: WLS_WSM1

- SOAHOST2: WLS_WSM2

- ADMINHOST: AdminServer

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

20. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、wsm-pmアプリケーションのターゲットがWSM-PM_Clusterのみであることを確認します。その他すべてのデプロイメントが「AdminServer」にターゲット設定されていることを確認します。「次ヘ」をクリックします。

21. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のように選択します。

- 左側で「WSM-PM_Cluster」を選択します。右側で「JDBCシステム・リソース」を選択します。これにより、すべてのwsmデータソース(mds-owsm)を自動的に選択できます。

- 左側で「管理サーバー」を選択します。右側で「JDBCシステム・リソース」を選択します。これにより、すべてのwsmデータソース(mds-owsm)を自動的に選択できます。

すべてのJDBCシステム・リソースが管理サーバーとWSM-PM_Clusterの両方にターゲット設定されている必要があります。

- 残りすべてのサービスが「管理サーバー」にターゲット設定されていることを確認します。

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

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

23. 「ドメインの作成」画面で「完了」をクリックします。

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

構成ウィザードでドメインを構成した後は、次の手順に従って構成後タスクと検証タスクを実行します。

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

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

- 第8.4.2項「SOAHOST1でのノード・マネージャの起動」

- 第8.4.3項「SOAHOST1での管理サーバーの起動」

- 第8.4.4項「GridLinkデータ・ソースの構成の検証」

- 第8.4.5項「管理サーバー構成の検証」

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

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

- 第8.4.8項「管理サーバーおよびWLS_WSM1管理対象サーバーに対するホスト名の検証の無効化」

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

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

SOAHOST1上で管理サーバーのboot.propertiesファイルを作成します。ノード・マネージャを使用して管理サーバーを起動するには、この手順を必ず実行する必要があります。

管理サーバーのboot.propertiesファイルを作成する手順は次のとおりです。

1. 次のディレクトリ構造を作成します。

mkdir -p ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security

2. テキスト・エディタで、次の行を記述したboot.propertiesというファイルを、前の手順で作成した最後のディレクトリに作成します。

username=Admin_Username
password=Password

注意:

管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で起動します。

セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を短くする必要があります。ファイルを編集した後、できるだけ速やかにサーバーを起動し、エントリを暗号化してください。

3. ファイルを保存してエディタを閉じます。

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

初めてノード・マネージャを起動する場合、StartScriptEnabledプロパティを'true'に設定し、startNodeManager.shを使用してノード・マネージャを起動します。

SOAHOST1でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを初めて起動する場合、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティを'true'に設定します。

cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

注意:

クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを設定する必要があります(これは1度しか実行する必要はありません)。

2. ノード・マネージャを起動します。

cd WL_HOME/server/bin
export JAVA_OPTIONS="-DDomainRegistrationEnabled=true"
./startNodeManager.sh

注意:

ノード・マネージャの起動時には必ず-DDomainRegistrationEnabled=trueを設定し、AdminServerが管理されるようにすることが重要です。これは、AdminServerドメイン・ホームがノード・マネージャ・ドメイン・ファイルになく、ドメインの動的な登録を使用する必要があるためです。ここで示している例を除き、このパラメータを使用することはお薦めしません。

このマシンにAdminServerが存在せず、このマシンがAdminServerフェイルオーバー・ノードでない場合は、次の方法でノード・マネージャを起動できます。

./startNodeManager.sh

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

管理サーバーは、ノード・マネージャを使用して起動および停止します。ただし、初めてノード・マネージャで管理サーバーを起動するときに、構成ウィザードによりノード・マネージャにデフォルトで設定されているユーザー名とパスワードを変更する必要があります。そのため、管理サーバーの初回の起動時に起動スクリプトを使用します。

最初の起動操作には手順1から4が必要ですが、2回目以降の起動には手順4のみが必要です。

ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。

1. SOAHOST1上のドメイン・ディレクトリの起動スクリプトを使用して、管理サーバーを起動します。

cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin
./startWebLogic.sh

2. 管理コンソールを使用してノード・マネージャの資格証明を更新します。

1. ブラウザで、次のURLにアクセスします。
http://ADMINVHN:7001/console

2. 管理者としてログインします。

3. 「ロックして編集」をクリックします。

4. 「domain_name」→「セキュリティ」→「一般」をクリックして、一番下にある「詳細」オプションを開きます。

5. ノード・マネージャの新しいユーザー名を入力するか、既存のユーザー名を書き留めておいてノード・マネージャのパスワードを更新します。

6. 変更を保存してアクティブ化します。

3. 管理サーバーのプロセスが起動したシェルで[Ctrl]キーを押しながら[C]キーを押すか、プロセスを確認してkillコマンドを使用し、管理サーバーを停止します。

4. WLSTを起動して、nmconnectと前の手順で設定した資格証明により、ノード・マネージャに接続し、nmstartを使用して管理サーバーを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルを起動したら、次のように指定します。

wls:/offline>nmConnect("Admin_User","Admin_Password",
"SOAHOST1","5556","domain_name","/ORACLE_BASE/admin/domain_name/aserver/domain_name")

wls:/nm/domain_name nmStart("AdminServer")

注意:

このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/nodemanager

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

サーバーを起動したら、MDSスキーマ用にGridLinkデータ・ソースが正しく構成され、ONS設定が正しいことを確認します。この手順を、作成した各GridLinkデータ・ソースで実行します。

GridLinkデータ・ソースの構成を検証するには、次の手順を実行します。

1. Oracle WebLogic管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 新しいデータ・ソースの1つをクリックします。

4. 「テスト」タブをクリックし、サーバーの1つを選択して「データ・ソースのテスト」をクリックします。

5. 「監視」タブをクリックし、サーバの1つを選択します。

6. 「ONS」→「テスト」タブをクリックします。

7. サーバーを選択し、「ONSのテスト」をクリックします。
両方のテストが成功する場合、正しく構成されています。ONSのテストが失敗する場合、Oracle RACデータベース・ノードでONSサービスが実行されていることを確認します。

orcl@db-scan1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node db-scan1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node db-scan2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node db-scan2

[orcl@db-scan1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: db-scan1
ONS daemon is running on node: db-scan2

データ・ソースを使用するすべてのWebLogic Serverで、ONSテストを実行します。

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

ドメインに作成した管理サーバーが正しく構成されているかどうかを確認するため、Oracle WebLogic Server管理コンソールにログインして管理対象サーバーとクラスタが表示されることを確認し、その後Oracle Enterprise Managerにログインします。

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. ブラウザで、次のURLにアクセスします。

http://ADMINVHN:7001/console

2. 管理者としてログインします。

3. 管理対象サーバーとして、WLS_WSM1とWLS_WSM2が表示されていることを確認します。

4. WSM-PM_Clusterが表示されていることを確認します。

5. 次のURLのOracle Enterprise Managerにアクセスできることを確認します。

http://ADMINVHN:7001/em

6. 第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してEnterprise Managerコンソールにログインします。

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

packコマンドおよびunpackコマンドを使用して、管理サーバーが使用するドメイン・ディレクトリを、SOAHOST1で管理対象サーバーが使用するドメイン・ディレクトリから分離します(ディレクトリを分離するこの処理は、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されています)。

unpackスクリプトを実行する前に、第4章にある「各種ディレクトリの推奨場所について」に示すとおりORACLE_BASE/admin/domain_name/mserverディレクトリが存在することを確認してください。

独立ドメイン・ディレクトリを作成する手順は次のとおりです。

1. 次のように、packコマンドをSOAHOST1上で実行してテンプレート・パックを作成します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=wcdomaintemplate.jar -template_name=wcdomaintemplate

2. 次のように、unpackコマンドをSOAHOST1上で実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-template=wcdomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackコマンドを実行する前に、/ORACLE_BASE/admin/domain_nameディレクトリに対する書込み権限が必要です。たとえば、次のディレクトリに対してです。

/ORACLE_BASE/admin/wcpedg_domain/

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

構成ウィザードを使用してドメインが作成された後、WebLogic Serverのインストールに含まれていない多数のリソースをWSM-PM_Clusterにターゲット設定する必要があります。

これらのリソースをターゲット設定するには:

1. 第8.4.1項「SOAHOST1での管理サーバー用boot.propertiesの作成」で指定したユーザー名とパスワードを使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。

2. 左側のナビゲーション・ツリーで、「Farm_domain_name」→「WebLogicドメイン」→「domain_name」を開き、「WSM-PM_Cluster」を選択します。

3. 右側で「JRFテンプレートの適用」をクリックします。

4. 画面に確認メッセージが表示されるのを待ちます。
このメッセージは、JRFテンプレートがWSM-PM_Clusterクラスタに正常に適用されたことを確認するものです。

8.4.8 管理サーバーおよびWLS_WSM1管理対象サーバーに対するホスト名の検証の無効化

この手順は、管理サーバーで様々なノードを認証するための適切な証明書をまだ設定していない場合に必要です(第11章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このエラーを回避するには、トポロジの設定と検証を行う際にホスト名の検証を無効にし、第11章「エンタープライズ・デプロイメント用のノード・マネージャの設定」の説明に従ってエンタープライズ・デプロイメント・トポロジの構成を完了した後に再びホスト名の検証を有効にします。

ホスト名検証を無効化するには:

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

5. 表の「名前」列の「AdminServer(admin)」を選択します。「AdminServer(admin)」の「設定」ページが表示されます。

6. 「SSL」タブをクリックします。

7. 「詳細」をクリックします。

8. 「ホスト名の検証」を「なし」に設定します。

9. 「保存」をクリックします。

10. WLS_WSM1サーバーについてステップ4から8を繰り返します。

11. 変更を保存してアクティブ化します。

12. 変更を有効にするには、管理サーバーを再起動します。

1. 「サーバーの概要」画面で、「制御」タブを選択します。

2. 表で「AdminServer(admin)」を選択して、「停止」をクリックします。

3. 管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して再度起動します。

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

管理対象サーバーの構成後、正常に実行されているかどうかを確認します。Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーを起動しそのステータスを確認できます。

WLS_WSM1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は次のとおりです。

1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_WSM1管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

2. 「サーバー」を選択します。「サーバーの概要」ページが表示されます。

3. 「制御」タブをクリックします。

4. 「WLS_WSM1」を選択して、「起動」をクリックします。

2. 管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.8項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

3. 次のURLにアクセスします。

http://SOAHOST1:7010/wsm-pm

4. 「ポリシー・マネージャの検証」をクリックします。
構成が正しい場合は、データ・ストアで使用できるポリシーとアサーション・テンプレートのリストが表示されます。ポリシーやアサーション・テンプレートがまったく表示されない場合は、構成が正しくありません。

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

SOAHOST1の構成が完了したら、unpackユーティリティを使用してSOAHOST2に構成を伝播し、伝播した構成を検証します。

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

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

- 第8.5.2項「WLS_WSM2管理対象サーバーに対するホスト名検証の無効化」

- 第8.5.3項「SOAHOST2でのノード・マネージャの起動」

- 第8.5.4項「WLS_WSM2管理対象サーバーの起動と検証」

- 第8.5.5項「Oracle WSMについてのJavaオブジェクト・キャッシュの構成」

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

unpackユーティリティを使用してドメイン構成を伝播します。unpackスクリプトを実行する前に、第4.3項「各種ディレクトリの推奨場所について」の説明のとおり次のディレクトリが存在することを確認してください。

ORACLE_BASE/admin/domain_name/mserver

ドメイン構成を伝播する手順は次のとおりです。

1. 次のコマンドをSOAHOST1上で実行して、前の手順で作成したテンプレート・ファイルをコピーします。

cd ORACLE_COMMON_HOME/common/bin

scp wcdomaintemplate.jar oracle@SOAHOST2:/ORACLE_COMMON_HOME/common/bin

2. SOAHOST2のWL_HOME/common/binディレクトリではなく、ORACLE_COMMON_HOME/common/binディレクトリからunpackコマンドを実行し、伝播するテンプレートを解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-template=wcdomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

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

この手順は、管理サーバーで様々なノードを認証するための適切な証明書をまだ設定していない場合に必要です(第11章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照)。サーバー証明書を構成していないと、様々なWebLogicサーバーを管理する際にエラーが発生します。このエラーを回避するには、トポロジの設定と検証を行う際にホスト名の検証を無効にし、第11章「エンタープライズ・デプロイメント用のノード・マネージャの設定」の説明に従ってエンタープライズ・デプロイメント・トポロジの構成を完了した後に再びホスト名の検証を有効にします。

ホスト名検証を無効化するには:

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

5. 表の「名前」列の「WLS_WSM2」を選択します。「AdminServer(admin)」の「設定」ページが表示されます。

6. 「SSL」タブをクリックします。

7. 「詳細」をクリックします。

8. 「ホスト名の検証」を「なし」に設定します。

9. 変更を保存してアクティブ化します。

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

ドメイン構成を伝播しホスト名検証を無効にしたら、StartNodeManager.shスクリプトを使用してノード・マネージャを起動します。

SOAHOST2でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

注意:

クラスのロード失敗などの問題を回避するために、StartScriptEnabledプロパティを使用する必要があります。

2. ノード・マネージャを起動します。

cd WL_HOME/server/bin
./startNodeManager.sh

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

管理コンソールを使用して、WLS_WSM2管理対象サーバーを起動して検証します。

WLS_WSM2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は次のとおりです。

1. 管理コンソールを使用してWLS_WSM2管理対象サーバーを起動します。

2. 管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.8項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

3. 次のURLにアクセスします。

http://SOAHOST2:7010/wsm-pm

4. 「ポリシー・マネージャの検証」をクリックします。

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

Javaオブジェクト・キャッシュ(JOC)は、Oracle WSMが実行されているすべてのサーバーに構成する必要があります。このローカル・キャッシュは、Oracle WSMのパフォーマンスを高めるために提供されています。

Javaオブジェクト・キャッシュは、次のディレクトリにあるconfigure-joc.pyスクリプトを使用して構成します。

MW_HOME/oracle_common/bin/

これは管理対象サーバーでのJOCの構成に使用できるPythonスクリプトです。このスクリプトはWLSTオンライン・モードで実行され、管理サーバーが稼働していることを前提としています。

JOCポートをOracle製品に対して構成する場合、9988から9998の範囲のポートを使用することをお薦めします。

注意:

wlstコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成した後は、影響を受けるすべての管理対象サーバーを再起動して、構成を有効にする必要があります。

Oracle WSMのJavaオブジェクト・キャッシュを構成する手順は次のとおりです。

1. コマンドラインのOracle WebLogic Scripting Tool(WLST)を使用して管理サーバーに接続します。例:

MW_HOME/wc/common/bin/wlst.sh
$ connect()

Oracle WebLogicの管理ユーザー名とパスワードの入力を求められたら、これらを入力します。

2. wlstを使用して管理サーバーに接続したら、execfileコマンドを使用してスクリプトを起動します。

wls:/mydomain/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")

3. 特定のクラスタのすべての管理対象サーバー用のJOCの構成
クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたら'y'を入力し、プロンプトが表示されたらクラスタ名と検出ポートを指定します。これにより、指定されたクラスタのすべての管理対象サーバーが検出され、JOCが構成されます。検出ポートはクラスタのJOC構成全体で共通です。次に例を示します。

Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : WSM-PM_Cluster
Enter Discover Port : 9991

configure-joc.pyをHA環境で使用するための手順は、次のとおりです。

execfile("MW_HOME/oracle_common/bin/configure-joc.py")
.
Enter Hostnames (eg host1,host2) : SOAHOST1,SOAHOST2
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : WSM-PM_Cluster
.
Enter Discover Port : 9991
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n

このスクリプトを使用すると、次のJOCの構成も実行できます。

- 指定されたすべての管理対象サーバー用のJOCの構成
クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたら'n'を入力し、プロンプトが表示されたら管理対象サーバーと検出ポートを指定します。次に例を示します。

Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WLS_WSM1:9998, WLS_WSM1:9998) : WLS_WSM1:9991,WLS_WSM2:9991

- 一部の管理対象サーバー用のJOC構成の除外
このスクリプトでは、JOC構成のDistributeModeを'false'に設定する管理対象サーバーのリストを指定できます。JOC構成から除外するサーバーがあるかどうかを尋ねるプロンプトが表示されたら'y'を入力し、プロンプトが表示されたら除外する管理対象サーバー名を入力します。次に例を示します。

Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
Exclude Managed Server List (eg Server1,Server2) : WLS_WSM1,WLS_WSM3

- すべての管理対象サーバーに対して分散モードを無効にします。
このスクリプトでは、指定されたクラスタのすべての管理対象サーバーに対する分散を無効にできます。分散モードに関するプロンプトが表示されたら'false'を指定します。デフォルトでは、分散モードは'true'に設定されています。

CacheWatcherユーティリティを使用してJOCの構成を確認します。『Oracle Fusion Middleware高可用性ガイド』を参照してください。

『Oracle Fusion Middleware高可用性ガイド』で説明しているように、Oracle WebLogic管理コンソールで「HAパワー・ツール」タブを使用してJavaオブジェクト・キャッシュ(JOC)を構成できます。

8.6 WebLogicドメインのOracle HTTP Serverの構成

この項では、WebLogicドメインのOracle HTTP Serverの構成タスクと、構成の検証タスクについて説明します。

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

- 第8.6.1項「管理サーバーとWLS_WSMn管理対象サーバーについてのOracle HTTP Serverの構成」

- 第8.6.2項「WebLogicプラグイン有効化フラグの有効化」

- 第8.6.3項「WebLogic ServerへのOracle HTTP Serverの登録」

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

- 第8.6.5項「Oracle HTTP Serverを介したアクセスの検証」

- 第8.6.6項「SOAHOST2への管理サーバーの手動フェイルオーバー」

- 第8.6.7項「Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証」

- 第8.6.8項「SOAHOST1への管理サーバーのフェイルバック」

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

WLS_WSMn管理対象サーバーが属するWSM-PM_Clusterと管理サーバーにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定する必要があります。

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サーバー・プラグインの使用』ガイドを参照してください。

WebLogicClusterパラメータを設定する手順は次のとおりです。

1. WEBHOST1およびWEBHOST2で、次のディレクトリにあるmod_wl_ohs.confファイルに行を追加します。

ORACLE_BASE/admin/instance_name/config/OHS/component_name/

次の行を追加します。

# The admin URLs should only be accessible via the admin virtual host

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName admin.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WeblogicPort 7001
</Location>
</VirtualHost>

# Virtual host entry for external https URL configured at the Load Balancer

<VirtualHost *:7777>
ServerName https://wcp.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

</VirtualHost>

# Virtual host entry for internal http URL

<VirtualHost *:7777
<VirtualHost *:7777>
ServerName wcpinternal.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

</VirtualHost>

注意:

ここで挙げている7777、admin.mycompany.com:80、you@your.addressなどの値は、単なる例です。これらのかわりに、実際の環境に基づいた値を入力してください。

2. WEBHOST1およびWEBHOST2の両方で、Oracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

8.6.2 WebLogicプラグイン有効化フラグの有効化

セキュリティのため、またロード・バランサがSSLリクエストを終了するため(Oracle HTTP ServerはリクエストをWebLogic Serverに非SSLとしてルーティングします)、ロード・バランサにSSLを構成した場合、そのドメインに対しWebLogicプラグイン有効化フラグをオンにする必要があります。

WebLogicプラグイン有効化フラグを有効にする手順は次のとおりです。

1. 管理コンソールにログオンします。

2. 左のナビゲーション・ツリーでドメイン名をクリックします。

3. 「Webアプリケーション」タブをクリックします。

4. 「ロックして編集」をクリックします。

5. 「WebLogicプラグインの有効化」チェック・ボックスを選択します。

6. 変更を保存してアクティブ化します。

8.6.3 WebLogic ServerへのOracle HTTP Serverの登録

Oracle WebLogicドメインが作成されると、Oracle Web層をドメインに接続できます。これには、Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Web層を管理および監視できるというメリットがあります。

Oracle Web TierをWebLogicドメインに関連付けるには、次のコマンドを使用します。

WEBHOST1> cd ORACLE_BASE/admin/instance_name/bin

WEBHOST1> ./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic

このコマンドは、OHS2に対してWEBHOST2からも実行する必要があります。

Oracle HTTP Serverの登録後、Oracle Enterprise Managerコンソールで管理可能なターゲットとして表示されます。これを確認するには、Enterprise Managerコンソールにログインします。ナビゲーション・ツリーにある「WebTier」項目に、該当のOracle HTTP Serverが登録されていることが示されます。

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

ロード・バランサを使用してOracle WebLogic Server管理コンソールにアクセスする場合、管理サーバーのフロントエンドURLを変更し、ユーザーのブラウザが適切なロード・バランサ・アドレスにリダイレクトされるようにする必要があります。

Oracle WebLogic Server管理コンソール・アプリケーションでは、コンソールを使用して、ポート、チャネル、セキュリティに対する変更を追跡します。コンソールを使用して行われた変更をアクティブ化するとき、コンソールは現在のリスニング・アドレス、ポートおよびプロトコルを検証します。このリスニング・アドレス、ポートおよびプロトコルがまだ有効の場合、コンソールはHTTPリクエストをリダイレクトし、ホストとポートの情報を管理サーバーのリスニング・アドレスとポートに置き換えます。

管理サーバーのフロントエンドURLを変更する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックして、「サーバーの概要」ページを開きます。

5. 表の「名前」列で「管理サーバー」を選択します。「AdminServer(admin)」の「設定」ページが表示されます。

6. 「プロトコル」タブをクリックします。

7. 「HTTP」タブをクリックします。

8. 「フロントエンド・ホスト」を「admin.mycompany.com」に設定し、「フロントエンドHTTPポート」を「80」に設定します(管理URLにHTTPSを使用する場合は、適宜変更します)。

9. 変更を保存してアクティブ化します。

10. 変更がアクティブ化されたときにコンソールで構成ページがリロードされないように、Oracle WebLogic Server管理コンソールで構成変更の追跡を無効にします。

1. Oracle WebLogic Server管理コンソールにログインします。

2. バナー内の「プリファレンス」リンクをクリックします。

3. 「共有プリファレンス」タブをクリックします。

4. 「構成変更の追跡」チェック・ボックスの選択を解除します。

注意:

フロントエンド・ホストやポートの設定を変更した後、構成の変更をアクティブ化できない場合は、第16.8.2項「管理コンソールで変更をアクティブ化した後にユーザーがログイン画面にリダイレクトされる」を参照してください。

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

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.8項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

次のURLを使用し、両方のOracle HTTP Serverを介してWSM-PM_Clusterを検証します。

- http://WEBHOST1:7777/wsm-pm

- http://WEBHOST2:7777/wsm-pm

- http://WEBHOST1:7777/console

- http://WEBHOST2:7777/console

- http://WEBHOST1:7777/em

- http://WEBHOST2:7777/em

- https://wcp.mycompany.com/wsm-pm

- http://admin.mycompany.com/console

- http://admin.mycompany.com/em

フロントエンドURLをロード・バランサのアドレスに設定すると、WEBHOSTnアドレスを介したコンソールへのアクセスはコンソールによってフロントエンドURLにリダイレクトされるため、Oracle HTTP Serverとロード・バランサの両方の構成が正しいことを検証できます。

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

第8.6.3項「WebLogic ServerへのOracle HTTP Serverの登録」の説明に従ってOracle HTTP Serverを登録すると、そのOracle HTTP Serverは管理可能なターゲットとしてOracle Enterprise Manager Consoleに表示されます。これを確認するには、Enterprise Manager Consoleにログインします。ナビゲーション・ツリーにある「WebTier」項目に、該当のOracle HTTP Serverが登録されていることが示されます。

8.6.6 SOAHOST2への管理サーバーの手動フェイルオーバー

ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをSOAHOST1からSOAHOST2にフェイルオーバーする方法を説明します。

前提条件

- 管理サーバーを、任意のアドレスではなくADMINVHN上でリッスンするように構成します。第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順14を参照してください。

- これらの手順では、2つのノードがそれぞれ別々のドメイン・ディレクトリを使用していることおよびこれらのディレクトリがローカル記憶域または別のボリュームにある共有記憶域に配置されていることを想定しています。

- 管理サーバーは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)にフェイルオーバーしたうえで、同じWebLogic Serverマシン(これは物理マシンではなく論理マシンです)を引き続きその管理サーバーで使用する方法を示しています。

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 10.0.0.1 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、SOAHOST2で使用可能なネットワーク構成と一致している必要があります。

3. 次の例のようにarpingを使用してルーティング表を更新します。

SOAHOST2> /sbin/arping -b -A -c 3 -I eth0 10.0.0.1

4. SOAHOST2上の管理サーバーを、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順に従って起動します。

5. 次の方法でSOAHOST2上の管理サーバーにアクセスできることをテストします。

1. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。

http://ADMINVHN:7001/console

2. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。

http://ADMINVHN:7001/em

注意:

管理サーバーは、フェイルオーバーにノード・マネージャを使用しません。手動フェイルオーバー後、サーバーの管理コンソールの「現在のマシン」フィールドに表示されるマシン名は、SOAHOST1です。フェイルオーバー・マシンのSOAHOST2ではありません。ノード・マネージャは管理サーバーを監視しないため、「現在のマシン」フィールドに表示されるマシン名は、無関係であり、無視できます。

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

第8.6.5項「Oracle HTTP Serverを介したアクセスの検証」と同じ手順を実行します。この目的は、SOAHOST2で実行している管理サーバーにもアクセスできることを確認することです。

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

この手順では、管理サーバーをフェイルバックできることを確認します。フェイルバックとは、SOAHOST2で実行している管理サーバーを停止し、ADMINVHNをSOAHOST1ノードに戻して、SOAHOST1で再び管理サーバーを実行することです。

ADMINVHNをSOAHOST1に戻す手順は次のとおりです。

1. 管理サーバーが起動されていないことを確認します。

2. 次のコマンドをSOAHOST2上で実行します。

/sbin/ifconfig ethZ:N down

3. 次のコマンドをSOAHOST1上で実行します。

/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクとインタフェースは、SOAHOST1で使用可能なネットワーク構成と一致している必要があります。

4. arpingを使用してルーティング表を更新します。次のコマンドをSOAHOST1から実行します。

/sbin/arping -b -A -c 3 -I ethZ 100.200.140.206

5. 第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用して、SOAHOST1上の管理サーバーを再度起動します。

cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin
./startWebLogic.sh

6. 次のURLを使用してOracle WebLogic Server管理コンソールにアクセスできることをテストします。

http://ADMINVHN:7001/console

7. 次のURLを使用してOracle Enterprise Managerにアクセスおよびコンポーネントのステータスを確認できることを確認します。

http://ADMINVHN:7001/em

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

バックアップを実行してドメイン構成を保存します。最初にサーバーが停止していることを確認します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/admin/domain_name

ドメイン構成をバックアップするには、SOAHOST1で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

次のコマンドを使用して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

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

この章では、構成ウィザードを使用して、SOAコンポーネントを扱うことができるようにドメインを拡張する方法を説明します。ドメインは第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成しました。

注意:

セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

注意:

SOAHOST1とSOAHOST2でSOAコンポーネントを実行する場合にのみ、この章の手順に従ってください。WebCenter PortalトポロジでSOAコンポーネントを実行しない場合は、この章は省略できます。

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

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

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

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

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

- 第9.5項「構成後タスクおよび検証タスク」

- 第9.6項「SOAHOST2へのドメイン構成の伝播」

- 第9.7項「拡張したドメインでのOracle HTTP Serverの構成」

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

- 第9.9項「Oracleアダプタの構成」

- 第9.10項「SOA構成のバックアップ」

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

Oracle SOAコンポーネントを追加するためのWebLogicドメインを拡張します。表9-1に、Oracle SOAの構成手順と、Oracle SOAコンポーネントを使用するためのドメインの拡張に必要なタスクを示します。

表9-1 SOAコンポーネントを使用するためのドメインの拡張の手順

手順

説明

詳細

SOAコンポーネントを使用するためのドメインの拡張の準備

各ホスト名のVIPマッピングを有効化します。

第9.2.1項「SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化」

SOAコンポーネントを使用するためのドメインの拡張

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogicドメインを拡張します。

第9.3項「構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張」

コンポジットをデプロイするためのOracle Coherenceの構成

コンポジットのデプロイにユニキャスト通信を使用するためOracle Coherenceを構成します。

第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」

構成後タスクおよび検証タスク

構成後タスクおよび検証タスクの手順に従います。

第9.5項「構成後タスクおよび検証タスク」

SOAHOST1へのドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第9.5.4項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」

拡張したドメインでのOracle HTTP Serverの構成

管理対象サーバーとともにOracle HTTP Serverを構成し、アクセスの検証、フロントエンドHTTPのホストおよびポートの設定およびSOA_ClusterのWLSクラスタ・アドレスを設定します。

第9.7項「拡張したドメインでのOracle HTTP Serverの構成」

デフォルト永続ストアの構成

トランザクション・リカバリのためのデフォルトの永続ストアを構成します。

第9.8項「トランザクション・リカバリ用デフォルト永続ストアの構成」

Oracleアダプタの構成

OracleファイルおよびFTPアダプタの高可用性およびOracle JMSアダプタの高可用性を有効化し、Oracle Databaseアダプタをスケーリングします。

第9.9項「Oracleアダプタの構成」

SOA構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第9.10項「SOA構成のバックアップ」

9.2 Oracle SOAコンポーネント用のドメインの拡張の準備

構成ウィザードを実行し、ドメインを拡張する前に、2つのSOAマシン上で各ホスト名のVIPマッピングを有効化します。

この項の内容は次のとおりです。

- 第9.2.1項「SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化」

9.2.1 SOAHOST1でのVIP2およびSOAHOST2でのVIP3の有効化

SOAドメインでは、SOA管理対象サーバー用リスニング・アドレスに仮想ホスト名を使用します。2つのSOAマシン上にこれらのホスト名をそれぞれマップするVIP(SOAHOST1上のVIP2およびSOAHOST2上のVIP3)を有効化し、トポロジが使用するネットワーク・システムの仮想ホスト名を(DNSサーバーまたはホスト解決によって)正しく解決する必要があります。

VIPを有効にするには、第8.2項「SOAHOST1でのVIP1の有効化」の手順を実行します。これらのVIPおよびVHNは、SOAサーバーのサーバーの移行を可能にするために必要です。サーバー移行は、高可用性を実現するために、SOAシステムに対して構成する必要があります。SOAサーバーのサーバーの移行の構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の第9章「サーバーの移行」を参照してください。

9.3 構成ウィザードを使用したSOAコンポーネントを使用するためのドメインの拡張

構成ウィザードを使用して、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを、SOAコンポーネントを使用できるように拡張します。

この項では、SOAデプロイメントが、WebCenter Portalデプロイメントと同じデータベース・サービス(wcpedg.mycompany.com)を使用することを前提としています。ただし、デプロイメントではSOA専用の別のデータベース・サービス(soaedg.mycompany.comなど)の使用を選択することもできます。

注意:

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインをバックアップしていない場合は、SOAコンポーネントを使用するためにドメインを拡張する前に、現在のドメインをバックアップします。ドメインの拡張時になんらかのエラーが発生した場合は、このバックアップを使用してリカバリできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

構成ウィザードを使用してドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内の管理対象サーバーをすべてシャットダウンします。

3. 構成ウィザードの場所にディレクトリを変更します。これは共通のOracleホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するSOAHOST1から実行することに注意してください)。

cd ORACLE_COMMON_HOME/common/bin

4. 構成ウィザードを開始します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. 「WebLogicドメイン・ディレクトリ」画面で、WebLogicドメイン・ディレクトリを選択します。

ORACLE_BASE/admin/domain_name/aserver/domain_name

「次へ」をクリックします。

7. 「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。

- Oracle SOA Suite 11.1.1.0

次の製品はすでに選択されてグレー表示されています。これらは、第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順でドメインを作成したときに選択したものです。

- WebLogic Serverの基本ドメイン

- Oracle Enterprise Manager

- Oracle WSM Policy Manager

- Oracle JRF

「次へ」をクリックします。

8. このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。

9. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. 画面下部の表に表示されるすべてのコンポーネント・スキーマ(「SOAインフラストラクチャ、「ユーザー・メッセージング・サービス、「SOA MDSスキーマ」)を選択します。

2. RACの構成には、(付録A「Oracle RACでのマルチ・データ・ソースの使用」で説明した)「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます。
ここの手順では、「GridLinkへ変換」を選択します。

3. 「次へ」をクリックします。

10. 「GridLink RACコンポーネント・スキーマの構成」画面で(図9-1)、次の手順を実行します。

図9-1 GridLink RACコンポーネント・スキーマの構成

「図9-1 GridLink RACコンポーネント・スキーマの構成」の説明

1. 表で「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」および「SOA MDSスキーマ」を選択します。

2. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「OracleのGridLinkConnectionsドライバ(Thin)、バージョン: 10以降」を選択します。

- サービス名: Oracle RACデータベースのサービス名と、続けてドメイン名を小文字で入力します。たとえば、wcpedg.mycompany.comです。

- FANの有効化: このオプションを選択します。

- SSLの有効化: このオプションを選択解除します。
Oracle Notification Service (ONS)の通知の暗号化するためにSSLが選択されている場合は、「ウォレット・ファイル」と「ウォレット・パスワード」に適切な詳細を入力します。

- サービス・リスナー: 使用しているOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。このプロトコルは、TCPである必要があります。
Oracle RACノードの追加または削除時にSCANアドレスを含むGridLinkデータ・ソースを更新する必要がないよう、サービス・リスナー(とOSNホスト)の指定にはSCANアドレスを使用することをお薦めします。SCANアドレスを判断するには、データベースに対してremote_listenerパラメータを問い合わせます。

SQL>show parameter remote_listener;

NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      db-scan.mycompany.com:1521

注意:

データベース・バージョンがSCANをサポートしない場合は次を実行します。

- Oracle Database 11gリリース1 (11.1)の場合、各データベースのインスタンス・リスナーの仮想IPとポートを次のように入力します。
custdbhost1-vip.mycompany.com (Port 1521)

および

custdbhost2-vip.mycompany.com (Port 1521)

- Oracle Database 10gの場合、マルチ・データ・ソースを使用し、Oracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: データベースからの通知のとおり、Oracle RACデータベースとONSリモート・ポートのSCANアドレスを入力します。

[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 (Port 6200)

3. 「SOAインフラストラクチャ」のみを選択し、このデータベース・スキーマのユーザー名とパスワードを入力します。

- ユーザー名: 対応するコンポーネントのデータベースのスキーマ所有者の完全な名前(接頭辞を含む)を入力します。

- パスワード: データベース・スキーマ所有者のパスワードを入力します。

4. 「ユーザー・メッセージング・サービス」、「SOA MDSスキーマ」には、手順cを繰り返します。

5. すべてのSOAスキーマの値が正しい場合、(「SOAインフラストラクチャ」、「ユーザー・メッセージング・サービス」および「SOA MDSスキーマ」)、「次へ」をクリックします。

11. 「JDBCデータ・ソースのテスト」画面で、テストするスキーマを選択し(または「すべて選択」をクリックし)、「接続のテスト」をクリックします。
「接続結果ログ」に結果が表示されます。スキーマを含むデータベースに正常に接続できたことを確認します。できなかった場合は、「前」をクリックし、前の画面に戻り、入力を修正し、テストを再試行します。

すべての接続に成功したら「次へ」をクリックします。

12. 「オプションの構成を選択」画面で、次の項目を選択します。

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

- JMSファイル・ストア

「次へ」をクリックします。

13. 「JMS分散宛先タイプの選択」画面で次の操作を行います。

- UMSJMSystemResourceのドロップダウン・リストから「UDD」を選択します。

- SOAJMSModuleのドロップダウン・リストから「UDD」を選択します。

14. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
soa_server1というサーバーが自動的に作成されます。このサーバーの名前をWLS_SOA1に変更して、表9-2に示す属性をこのサーバーに割り当てます。続いて、WLS_SOA2という新しいサーバーを追加します。管理対象サーバーであるWLS_WSM1とWLS_WSM2は、拡張するドメインに属しているのですでに存在しています。最終的に、管理対象サーバーのリストは表9-2のリストと一致する必要があります。

表9-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_SOA1

SOAHOST1VHN1

8001

該当なし

いいえ

WLS_SOA2

SOAHOST2VHN1

8001

該当なし

いいえ

WLS_WSM1

SOAHOST1

7010

該当なし

いいえ

WLS_WSM2

SOAHOST2

7010

該当なし

いいえ

「次へ」をクリックします。

15. 「クラスタの構成」画面で、次のクラスタを追加します。

表9-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

SOA_Cluster

ユニキャスト

該当なし

該当なし

SOAHOST1VHN1:8001,SOAHOST2VHN1:8001

WSM-PM_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

注意:

直接バインディングを介してリクエスト/レスポンスが非同期でやり取りされるようにするため、SOAコンポジットでは、JNDIプロバイダURLを提供して、呼び出されたサービスが、コールバックするBeanを検索できるようにする必要があります。

soa-infraの構成プロパティは指定されていないがWebLogic Serverクラスタ・アドレスが指定されている場合は、JNDIプロバイダURLのクラスタ・アドレスが使用されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名を指定することも、サーバーip:portのカンマ区切りリストを指定することもできます。また、ユーザーが明示的に設定していれば、soa-infraの構成プロパティJndiProviderURL/SecureJndiProviderURLを同じ目的に使用することもできます。

「次へ」をクリックします。

16. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- SOA_Cluster:

- WLS_SOA1

- WLS_SOA2

- WSM-PM_Cluster:

- WLS_WSM1

- WLS_WSM2

「次へ」をクリックします。

17. 「マシンの構成」画面で、次の手順を実行します。

- デフォルトで表示される「LocalMachine」を削除します。

- 「Unixマシン」タブをクリックします。次のエントリが表示されます(表9-4)。

表9-4 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

localhost

その他すべてのフィールドはデフォルト値のままにします。

「次へ」をクリックします。

18. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- ADMINHOST:

- AdminServer

- SOAHOST1:

- WLS_SOA1

- WLS_WSM1

- SOAHOST2:

- WLS_SOA2

- WLS_WSM2

「次へ」をクリックします。

19. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定する必要があります(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。

- oracle.sdp.*およびoracle.soa.*の各ライブラリは、SOA_Clusterにのみターゲット設定する必要があります。

- oracle.rules.*ライブラリは、管理サーバーおよびSOA_Clusterにのみターゲット設定する必要があります。

- wsm-pmアプリケーションは、WSM-PM_Clusterにのみターゲット設定する必要があります。

「次へ」をクリックします。

20. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- mds-owsmをWSM-PM_ClusterとAdminServerの両方のターゲットとします。

「次へ」をクリックします。

21. 「JMSファイル・ストアの構成」画面で、第4.3項「各種ディレクトリの推奨場所について」での推奨に従ってJMSストアに指定した共有ディレクトリの場所を入力します。次に例を示します。

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

「次へ」をクリックします。

22. 「構成のサマリー」画面で「拡張」をクリックします。

注意:

ドメイン構成ポートがホスト・ポートと競合していることを警告するダイアログが表示されますが、「OK」をクリックして閉じてください。この警告は、すでにインストールされているWSM-PMが原因で表示されます。

23. 「ドメインの拡張」画面で、「完了」をクリックします。
この構成を有効にするには、管理サーバーを起動する必要があります。

24. 管理サーバーを、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で起動します。

9.4 コンポジットをデプロイするためのOracle Coherenceの構成

コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。

ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

注意:

デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムを実行するネットワーク環境に応じて、デプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。

9.4.1 ユニキャスト通信を使用したデプロイメントの通信の有効化

tangosol.coherence.wka<n>システム・プロパティを使用してノードを指定します。<n>は、1から9の数字です。「Well Knownアドレス」には、最大9つのノードを指定できますが、クラスタ内には9以上のノードを含めることが可能です。番号は、1から開始します。この番号付けは、連続的で間隙を含まないようにする必要があります。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHN1とSOAHOST2VHN1)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します(図9-2)。

ヒント:

SOAコンポジットのデプロイ時に高可用性を確保するには、適切な数のノードを指定して、どの時点でもそのうちのいずれかが必ず稼働しているようにします。

注意:

SOAHOST1VHN1は、SOAHOST1でWLS_SOA1がリッスンする仮想IPにマップされる仮想ホスト名です。SOAHOST2VHN1は、SOAHOST2でWLS_SOA2がリッスンする仮想IPにマップされる仮想ホスト名です。

図9-2 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定

「図9-2 Oracle WebLogic Server管理コンソールの「サーバーの起動」タブを使用したホスト名の設定」の説明

9.4.2 Oracle Coherenceで使用するホスト名の指定

Oracle Coherenceで使用するホスト名を追加するには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列にハイパーリンクで表示されているサーバーの名前(WLS_SOA1またはWLS_SOA2)をクリックします。選択したサーバーの「設定」ページが表示されます。

5. 「ロックして編集」をクリックします。

6. 「サーバーの起動」タブをクリックします(図9-2を参照)。

7. WLS_SOA1とWLS_SOA2について、「引数」フィールドに次の値を入力します。

注意:

異なる -D パラメータの間には、空白の行を入れないでください。テキストは、前述の場所からコピーして管理コンソールの引数テキスト・フィールドに貼り付けないでください。貼り付けると、Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。

注意:

デプロイメントに使用されるCoherenceクラスタは、デフォルトでポート8088を使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。次に例を示します。

WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。

WLS_SOA1については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1

WLS_SOA2については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST2VHN1
-Dtangosol.coherence.wka2=SOAHOST1VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1

8. 「保存」→「変更のアクティブ化」をクリックします。

注意:

これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります(これらの変数はサーバーの出力ログに記録されます)。Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。

注意:

このマルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用するものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタおよびコンポジットのデプロイ先グループ)の通信プロトコルが異なる場合でも、単一のWebLogic Serverクラスタの各メンバーにコンポジットを確実にデプロイできます。

9.5 構成後タスクおよび検証タスク

構成ウィザードでドメインを拡張し、Oracle Coherenceを構成したら、次の手順に従って、構成後タスクと検証を行います。

この項の内容は次のとおりです。

- 第9.5.1項「WLS_SOAn管理対象サーバーに対するホスト名検証の無効化」

- 第9.5.2項「SOAHOST1でのノード・マネージャの再起動」

- 第9.5.3項「Oracle SOA SuiteのためのGridLinkデータ・ソース構成およびONS構成の検証」

- 第9.5.4項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更内容の伝播」

- 第9.5.5項「WLS_SOA1管理対象サーバーの起動と検証」

9.5.1 WLS_SOAn管理対象サーバーに対するホスト名検証の無効化

このガイドで説明するエンタープライズ・デプロイメントでは、Oracle SOAを使用するためのドメイン拡張手順を実行した後、適切な証明書を設定して管理サーバーで様々なノードを認証できるようにします。そのため、WLS_SOAn管理対象サーバーのホスト名検証を無効化して、様々なWebLogic Serverを管理するときにエラーが出ないようにします。エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第11.5項「SOAHOST2およびWCPHOST2でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

ホスト名検証を無効化するには:

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

5. 表の「名前」列で「WLS_SOA1」(これはハイパーリンクとして表示されています)を選択します。「設定」ページが表示されます。

6. 「SSL」タブを選択します。

7. 表示されたページの「詳細」セクションを開きます。

8. 「ホスト名の検証」を「なし」に設定します。

9. 「保存」をクリックします。

10. WLS_SOA2管理対象サーバーについてこの手順を繰り返します。

11. 変更を保存してアクティブ化します。

12. この変更内容を有効にするには、管理サーバーおよびノード・マネージャを再起動する必要があります。

1. 管理サーバーを再起動する手順は、第8章「SOAHOST1での管理サーバーの起動」を参照してください。

2. SOAHOST1でノード・マネージャを再起動するには、第9章「SOAHOST1でのノード・マネージャの再起動」を参照してください。
SOAHOST2のノード・マネージャに繰り返します。

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 Oracle SOA SuiteのためのGridLinkデータ・ソース構成およびONS構成の検証

WLS_SOA1の伝播を行う前に、前に作成したGridLinkデータ・ソースの構成とOracle Notification Service (ONS)の設定がデータ・ソースに対して正しいことを検証する必要があります。

Oracle SOA SuiteのGridLinkデータ・ソースとONSの構成を確認するには、次の手順を実行します。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 作成済のGridLinkデータ・ソース名をクリックします。

4. 「テスト」タブをクリックし、「WLS_SOA1」を選択して「データ・ソースのテスト」をクリックします。

図9-3 GridLinkデータ・ソースのテスト

構成が正しい場合、テストは成功します。

5. GridLinkデータ・ソースを使用する各SOA管理対象サーバーに、テストを繰り返します。

6. 「監視」タブをクリックし、サーバー名の1つをクリックします。

7. 「ONS」→「テスト」タブをクリックします。

8. 「WLS_SOA1」を選択し、「ONSのテスト」をクリックします。

図9-4 ONSの設定のテスト

構成が正しい場合、ONSのテストは成功します。ONSのテストが失敗する場合、Oracle RACデータベース・ノードでONSサービスが実行されていることを確認します。

[orcl@db-scan1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node db-scan1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node db-scan2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node db-scan3

[orcl@db-scan1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: db-scan1
ONS daemon is running on node: db-scan2

9. GridLinkデータ・ソースを使用する各管理対象サーバーに、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=soadomaintemplateExtSOA.jar -template_name=soa_domain_templateExtSOA

3. 次のようにunpackコマンドをSOAHOST1上で実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-overwrite_domain=true -template=soadomaintemplateExtSOA.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

9.5.5 WLS_SOA1管理対象サーバーの起動および検証

管理コンソールを使用してWLS_SOA1管理対象サーバーを起動して、検証します。

SOAHOST1でWLS_SOA1管理対象サーバーを起動する手順は次のとおりです。

1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。

1. 次のURLの管理コンソールにアクセスします。

http://ADMINVHN:7001/console

ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。
「サーバーのサマリー」画面が表示されます。

4. 「制御」タブをクリックします。

5. 「WLS_SOA1」を選択して、「起動」をクリックします。

2. サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.8項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

3. 次のURLにアクセスして、WLS_SOA1のステータスを確認します。

http://SOAHOST1VHN1:8001/soa-infra/

次のURLにアクセスして、ワークリスト・アプリケーションのステータスを確認します。

http://SOAHOST1VHN1:8001/integration/worklistapp/

次のURLにアクセスして、コンポーザ・アプリケーションのステータスを確認します。

http://SOAHOST1VHN1:8001/soa/composer/

アクセスが許可されていることを確認する前に、管理対象サーバーWLS_WSM1が稼動していることを確認します。

9.6 SOAHOST2へのドメイン構成の伝播

SOAHOST1の構成が完了したら、unpackユーティリティを使用してSOAHOST2に構成を伝播し、伝播した構成を検証します。

この項の内容は次のとおりです。

- 第9.6.1項「unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」

- 第9.6.2項「WLS_SOA2管理対象サーバーの起動と検証」

9.6.1 unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播

unpackユーティリティを使用して、構成したドメインをSOAHOST2に伝播します。

ドメイン構成を伝播する手順は次のとおりです。

1. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします。

cd ORACLE_COMMON_HOME/common/bin

scp soadomaintemplateExtSOA.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin

2. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh
-domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/
-template=soadomaintemplateExtSOA.jar -overwrite_domain=true
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

9.6.2 WLS_SOA2管理対象サーバーの起動と検証

管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。soa-infraおよびworklistappのURLにアクセスして検証します。

WLS_SOA2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

1. 管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。

2. 管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.8項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

3. 次のURLでsoa-infraにアクセスします。

http://SOAHOST2VHN1:8001/soa-infra

4. 次のURLにアクセスして、ワークリスト・アプリケーションのステータスを確認します。

http://SOAHOST2VHN1:8001/integration/worklistapp/

アクセスが許可されていることを確認する前に、少なくとも1つの管理対象サーバー(WLS_WSM1またはWLS_WSM2)が稼動していることを確認します。

注意:

WLS_SOA1サーバーが稼働していても、一部のアプリケーションが失敗した状態になることがあります。そのため、前述のURLを検証し、個別のアプリケーションに関するエラーがないか、サーバーの出力ファイルで確認することをお薦めします。

5. 次のURLにアクセスして、コンポーザ・アプリケーションのステータスを確認します。

http://SOAHOST2VHN1:8001/soa/composer/

9.7 拡張したドメインでのOracle HTTP Serverの構成

ドメイン構成をSOAHOST2に伝播した後、拡張したドメインでOracle HTTP Serverを構成します。

この項の内容は次のとおりです。

- 第9.7.1項「WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成」

- 第9.7.2項「Oracle HTTP Serverを介したアクセスの検証」

- 第9.7.3項「フロントエンドHTTPホストおよびポートの設定」

9.7.1 WLS_SOAn管理対象サーバーについてのOracle HTTP Serverの構成

WebLogicClusterパラメータで指定したサーバーは、起動時のプラグインに対してのみ重要な役割を持ちます。このノードのリストには、実行しているクラスタ・メンバーを1つ以上記述しておく必要があります。記述しておかないと、このプラグインで他のクラスタ・メンバーを検出できません。Oracle HTTP Serverの起動時には、リストに記述したクラスタ・メンバーを実行している必要があります。Oracle WebLogic Serverとこのプラグインの連携により、クラスタに発生した新規のクラスタ・メンバー、失敗したクラスタ・メンバーおよびリカバリしたクラスタ・メンバーを反映してサーバーのリストが自動的に更新されます。

次に例を示します。

- 例1: 2つのノードで構成したクラスタに3番目のメンバーを追加する場合、そのメンバーを追加するために構成を更新する必要はありません。3番目のメンバーは、実行時にその場で検出されます。

- 例2: クラスタは3つのノードで構成されていても、構成に記述されているノードはそのうちの2つのみであるとします。Oracle HTTP Serverを起動するときにこの2つのノードが両方とも停止していると、プラグインはクラスタを検出できません。Oracle HTTP Serverを起動するときは、リストに記述したノードを1つ以上実行している必要があります。
クラスタのメンバーをすべてリストに記述した場合は、Oracle HTTP Serverの起動時にそのうちの1つ以上を実行しておくことで、クラスタに確実に到達できます。

WebLogic Serverプラグインの構成の詳細は、『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』ガイドを参照してください。

WLS_SOAn管理対象サーバーが属するSOA_ClusterにOracle HTTP Serverからルーティングできるようにするには、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

/workflowのエントリは省略可能です。これは、Oracle ADFタスク・フォームと関連付けられたワークフロー・タスク用です。/workflowのURL自体は、フォームに応じた別の値とすることができます。

Oracle HTTP ServerでSOA_Clusterへのルーティングを有効化する手順は次のとおりです。

1. WEBHOST1とWEBHOST2上のORACLE_BASE/ admin/instance_name/config/OHS/component_name/mod_wl_ohs.confファイルに、次の行を追加します。

# SOA soa-infra app
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# UMS WS
<Location /ucs/messaging/webservice>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA composer application
<Location /soa/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

2. WEBHOST1およびWEBHOST2で、Oracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1
WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

9.7.2 Oracle HTTP Serverを介したアクセスの検証

管理コンソールに表示されるサーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.8項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

次のURLにアクセスできることを確認します。webhostNには、各Oracle HTTP Serverホストの名前を指定します(WEBHOST1やWEBHOST2など)。

- http://webhostN:7777/soa-infra

- http://webhostN:7777/integration/worklistapp

- http://webhostN:7777/sdpmessaging/userprefs-ui

- http://webhostN:7777/soa/composer

両方のOracle HTTP ServerインスタンスからSOA_Clusterを検証します。

ロード・バランサを介したシステム・アクセスの構成の詳細は、第3.3項「ロード・バランサの構成」を参照してください。

9.7.3 フロントエンドHTTPホストおよびポートの設定

管理コンソールを使用し、フロントエンドHTTPホストを設定し、サーバーを再起動します。

Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定する手順は次のとおりです。

1. WebLogic Server管理コンソールの「チェンジ・センター」セクションの「ロックして編集」をクリックします。

2. 左ペインの「ドメイン構造」ウィンドウで「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. SOA_Clusterクラスタを選択します。

4. 「HTTP」を選択します。

5. 次の値を設定します。

- フロントエンド・ホスト: wcp.mycompany.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80

6. 「保存」をクリックします。

7. 変更を有効にするために、管理コンソールの「チェンジ・センター」セクションの「変更のアクティブ化」をクリックします。

8. サーバーを再起動して、クラスタのフロントエンド・ホストの指定を有効化します。

注意:

ロード・バランサでHTTPSが有効になっており、SSLがロード・バランサで終了する場合(SOAサーバーはHTTPSではなくHTTPリクエストのみを受信します)、ここに示しているように、Webサービスのエンドポイント・プロトコルはhttpに設定されます。ロード・バランサはHTTPをHTTPSにリダイレクトするため、Oracle Enterprise Manger Fusion Middleware ControlでWebサービスの機能をテストすると、次の例外が発生します。

(javax.xml.soap.SOAPException: oracle.j2ee.ws.saaj.ContentTypeException)

この例外を解決するには、URLエンドポイントを更新します。

Enterprise Managerの「テスト」ページで、エンドポイントURLの編集を確認します。

「エンドポイントURL」ページで、次の操作を実行します。

- httpをhttpsに変更します。

- 初期設定のポート番号(80など)をSSLポート(443など)に変更します。

コールバックURL

SOAシステムでは、次のようにコールバックURLを計算します。

- SOAへのリクエストが外部または内部のサービスから発行された場合、SOAはクライアントで指定されたコールバックURLを使用します。

- 外部または内部の非同期サービスへのリクエストがSOAから発行された場合は、次の方法でコールバックURLが決定されます。ここでは決定方法の優先度が高い順に示しています。

1. 特定の参照用のバインド・プロパティとして指定されたcallbackServerURLを使用します(このプロパティは、コンポジットのモデリング時または実行時にMBeansを使用して設定できます)。これにより、サービス呼び出しごとに異なるコールバックURLを割り当てることができます。つまり、外部サービスからのコールバックURLには、内部サービスへのコールバックURLとは異なる値を設定できます。エンタープライズ・デプロイメント・アーキテクチャでの一般的なコールバックURLは、外部サービスについてはwcp.mycompany.com(443/https)、内部サービスについてはwcpinternal.mycompany.com(7777/http)です。このプロパティは、システムMBeanブラウザに対応するバインドmbeanを通じ、実行時にシステムMBeanブラウザを使用して設定します。特定のURLを追加するには、そのProperties属性にcallbackServerURLプロパティを追加してから保存操作を実行します。

2. soa-infra-config.xmlで指定したコールバックURLを使用します。この場合、指定できるアドレスは1つのみです。外部サービスと内部サービスの両方を組み合せて呼び出し可能な場合は、エンタープライズ・デプロイメント・アーキテクチャでこのアドレスをwcp.mycompany.com(443/https)に設定する必要があります。内部サービスのみを呼び出す場合は、このアドレスをwcpinternal.mycompany.com(7777/http)に設定します。

3. SOA_ClusterのWLSで指定するフロントエンド・ホストとして、このコールバックURLを使用します。この場合も指定できるアドレスは1つのみなので、soa-infra-config.xmlの場合と同じ処理をお薦めします。

4. WLS MBean APIで指定されたローカル・ホスト名を使用します。エンタープライズ・デプロイメントのような高可用性環境では、この方法はお薦めできません。

9.8 トランザクション・リカバリ用デフォルト永続ストアの構成

各サーバーには、サーバーがコーディネートした、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログが用意されています。WebLogic Serverでは、システム・クラッシュやネットワーク障害からのリカバリ時にこのトランザクション・ログを使用します。クラスタにあるサーバーに対してトランザクション・リカバリ・サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセスできる場所にトランザクション・ログを格納します。

注意:

デュアルポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)をこの場所とすることをお薦めします。

デフォルト永続ストアの場所を設定するには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」ノードをクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列にあるサーバーの名前(ハイパーリンクとして表示されています)をクリックします。選択したサーバーの「設定」ページが表示され、デフォルトで「構成」タブが選択状態になります。

5. 「サービス」タブをクリックします。

6. 表示されたページの「デフォルト・ストア」セクションで、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。このパスのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

7. 「保存」をクリックします。

8. WLS_SOA1およびWLS_SOA2の再起動後、次のファイルがORACLE_BASE/admin/domain_name/soa_cluster_name/tlogsディレクトリに作成されていることを確認します。

- _WLS_WLS_SOA1000000.DAT

- _WLS_WLS_SOA2000000.DAT

注意:

トランザクション・リカバリ・サービスの移行を有効にするには、クラスタにある他のサーバーが使用できる永続記憶域ソリューションの場所を指定します。WLS_SOA1とWLS_SOA2の両方からこのディレクトリにアクセスできる必要があります。また、サーバーを再起動する前に、このディレクトリが存在している必要があります。

9.9 Oracleアダプタの構成

Oracleファイル、FTPおよびデータベース・アダプタを、拡張したSOAドメイン用に構成します。

この項の内容は次のとおりです。

- 第9.9.1項「OracleファイルとFTPアダプタの高可用性化」

- 第9.9.2項「Oracle JMSアダプタの高可用性化」

- 第9.9.3項「Oracle Databaseアダプタのスケーリング」

9.9.1 OracleファイルとFTPアダプタの高可用性化

OracleファイルおよびFTPアダプタを使用すると、ローカル・ファイル・システムやリモート・ファイル・システムのファイルをFTP(ファイル転送プロトコル)を使用してBPELプロセスまたはOracle Mediatorで読取りまたは書込みできるようになります。これらのアダプタは、Oracle BPEL Process ManagerおよびOracle Mediatorサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能を、インバウンドおよびアウトバウンドの両方の操作でサポートしています。Oracle File AdapterとOracle FTP Adapterがアウトバウンド操作に対する高可用性を備えるようにするには、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のアウトバウンド操作での高可用性に関する項を参照してください。データベースのmutex lock操作を使用すると、複数の参照から同じディレクトリへの書込みが発生しても、これらのアダプタでは相互の上書きを防止できます。

注意:

前述の操作は、これらのアダプタがアプリケーションで必要になる場合にのみ実行する必要があります。

注意:

ファイル・アダプタは、インバウンド・ディレクトリからファイルを取得して処理し、出力ディレクトリにファイルを出力します。ファイル・アダプタでの処理はトランザクション方式ではないので、ファイルは2回処理できます。この結果として、RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生したときに、重複するファイルが得られる可能性があります。

9.9.1.1 データベースのmutex lock操作の使用

データベース表をコーディネータとして使用することで、アウトバウンドのOracleファイルやFTPアダプタのサービスに高可用性を実現します。そのためには次の手順を実行します。

注意:

データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトの値を大きくする必要があります。

1. データベース表の作成
データベース・スキーマはsoainfraの一部として事前に作成済なので、この手順を実行する必要はありません。

2. Oracleファイル・アダプタのデプロイメント・ディスクリプタの変更
eis/HAFileAdapterに対応する接続インスタンスについて、Oracle WebLogic ServerコンソールからOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。

1. Oracle WebLogic Serverコンソールにログインします。このコンソールにアクセスするには、http://servername:portnumber/consoleにアクセスします。

2. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

3. 右ペインの「デプロイメントの概要」で「FileAdapter」をクリックします。

4. 「構成」タブをクリックします。

5. 「アウトバウンド接続プール」タブをクリックして「javax.resource.cci.ConnectionFactory」を開き、構成済の接続ファクトリを表示します。

6. 「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。

7. 図9-5に示すように、接続ファクトリのプロパティが表示されます。

図9-5 Oracle WebLogic Serverコンソール - 「javax.resource.cci.Connectionfactoryの設定」ページ

「図9-5 Oracle WebLogic Serverコンソール - 「javax.resource.cci.Connectionfactoryの設定」ページ」の説明

「ロックして編集」をクリックします。これにより、プロパティ値の列が編集可能になります(「プロパティ値」列で任意の行をクリックしてその値を変更できます)。

OracleファイルとFTPアダプタの接続ファクトリの新しいパラメータは次のとおりです。

controlDir: 制御ファイルを格納するディレクトリ構造に設定します。1つのクラスタの中で複数のWebLogic Serverインスタンスを実行する場合は、この値を共有場所に設定する必要があります。この共有記憶域のディレクトリは次のような構造にします。

ORACLE_BASE/admin/domain_name/cluster_name/fadapter

inboundDataSource: jdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。事前作成スキーマはORACLE_HOME/ rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。別のスキーマを選択する場合は、それに応じてinboundDataSourceプロパティを設定する必要があります。

outboundDataSource: jdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。事前作成スキーマはORACLE_HOME/ rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。事前作成スキーマを別の場所で作成する場合は、このスクリプトを使用します。その場合は、outboundDataSourceプロパティを設定する必要があります。

outboundDataSourceLocal: jdbc/SOALocalTxDataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータソースです。

outboundLockTypeForWrite: Oracle Databaseを使用している場合は、この値をoracleに設定します。デフォルトでは、OracleファイルとFTPアダプタはメモリー内mutexを使用してアウトバウンドの書込み操作をロックします。書込み操作を同期化するには、次の値のいずれかを選択する必要があります。

memory: OracleファイルとFTPアダプタはメモリー内mutexを使用してファイル・システムへのアクセスを同期化します。

oracle: アダプタはOracle Databaseシーケンスを使用します。

db: アダプタは事前作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用している場合にのみ使用します。

user-defined: アダプタはユーザー定義のmutexを使用します。ユーザー定義のmutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutexを実装し、新しいバインド・プロパティoracle.tip.adapter.file.mutexを構成して、その値にアウトバウンド参照のmutexの完全修飾クラス名を指定します。

8. これらのプロパティを更新した後、「保存」をクリックします。「デプロイメント・プランの保存」ページが表示されます。

9. デプロイメント・プランの共有記憶域場所を入力します。そのディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/cluster_name/dp/Plan.xml

10. 「保存してアクティブ化」をクリックします。

11. 次の例(バインディング・コンポーネント用コンポジットに含まれるjcaファイル)に示すように、BPEL Processまたは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.9.2 Oracle JMSアダプタの高可用性化

Oracle JMSアダプタがクラスタ内の複数のサーバーと通信する場合、アダプタの通信ファクトリのプロパティFactoryPropertiesに使用可能なサーバーがリストされている必要があります。サーバーがリストされない場合、ランダムな1サーバーとの接続が確立されます。そのサーバーが停止しても、追加のメッセージは処理されません。

eis/wls/Queueなど、使用するアダプタのJCA接続ファクトリの確認には、次の必須プロパティが含まれます。

1. Oracle WebLogic Serverコンソールにログインします。コンソールにアクセスするには、次にナビゲートします。

http://servername:portnumber/console

2. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

3. 右ペインの「デプロイメントのサマリー」でJMSAdapterをクリックします。

4. 「構成」タブをクリックします。

5. 「アウトバウンド接続プール」タブをクリックしてoracle.tip.adapter.jms.IJmsConnectionFactoryを開き、構成済の接続ファクトリを表示します。

6. 使用中の特定のインスタンス(例: eis/wls/Queue)をクリックします。接続ファクトリの「アウトバウンド接続のプロパティ」が開きます。

7. 「ロックして編集」をクリックします。

8. FactoryPropertiesフィールドで(「プロパティ」値の該当するセルをクリックして)、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;
java.naming.security.credentials=weblogic1

9. 「入力」をクリックし、変更内容を保存してアクティブ化します。

コンソールでデプロイメントを更新します。

1. 「デプロイメント」をクリックしてJMSアダプタを選択します。

2. 「ロックして編集」をクリックし、「更新」をクリックします。

3. 新規デプロイメント・プランの変更(デプロイメント・プランはこのオプションで指定)を含め、このアプリケーションの「更新」を選択し、共有記憶域の場所に保存されたデプロイメント・プランを選択すると、クラスタ内のすべてのサーバーは、このプランにアクセス可能になります。

4. 「終了」をクリックして変更内容をアクティブ化します。

9.9.3 Oracle Databaseアダプタのスケーリング

論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。

以前は、複数のOracle BPEL Process ManagerノードまたはOracle Mediatorノードにデプロイする複数のOracle Databaseアダプタ・プロセス・インスタンスにおける最善の手法は、基本的に、ポーリング・ノードごとに一意のMarkReservedValueを設定し、さらにMaxTransactionSizeを設定して、LogicalDeletePollingStrategyまたはDeletePollingStrategyを使用することでした。

ただし、今回のリリースでロックのスキップが導入されたため、そのアプローチは破棄されました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)消去するだけです。それによってロックが自動的にスキップされるようになります。

予約された値に対してロックのスキップを使用することには、次のような利点があります。

- ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。

- (更新/予約の次にコミットを行ってから新しいトランザクションで選択するのとは反対に)すべての作業が1つのトランザクションで行われるため、高可用性環境でリカバリ不能な状況に直面するリスクが最小に抑えられます。

- 一意のMarkReservedValueを指定する必要がありません。以前は、そのようにするためには、R${weblogic.Name-2}-${IP-2}-${instance}のように、複雑な変数を構成することが必要でした。

詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』の、スケーラビリティに関する項およびポーリング方式に関する項を参照してください。

9.10 SOA構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

ドメイン構成をバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl startall

2. データベースのバックアップを取ります。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/admin/domain_name

管理サーバーをバックアップするには、SOAHOST1で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

10 WebCenter Portalコンポーネントを使用するためのドメインの拡張

この章では、WebCenter Portalコンポーネントを含めるために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを構成ウィザードを使用して拡張する方法を説明します。

注意:

セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

この章の内容は次のとおりです。

- 第10.1項「WebCenter Portalコンポーネントを使用するためのドメインの拡張の概要」

- 第10.2項「WebCenter Portalコンポーネントを使用するための構成ウィザードを使用したドメインの拡張」

- 第10.3項「構成後のタスク」

- 第10.4項「SOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」

- 第10.5項「Spaces_Cluster用のJavaオブジェクト・キャッシュの構成」

- 第10.6項「マルチキャストからユニキャストへのディスカッションの変換」

- 第10.7項「ディスカッション・サーバーでのクラスタリングの構成」

- 第10.8項「Analyticsの構成」

- 第10.9項「アクティビティ・グラフの構成」

- 第10.10項「REST APIの構成」

- 第10.11項「拡張したドメインでのOracle HTTP Serverの構成」

- 第10.12項「WebCenter Portalの構成のバックアップ」

10.1 WebCenter Portalコンポーネントを使用するためのドメインの拡張の概要

WebLogicドメインを拡張して、Oracle WebCenter Portalコンポーネントを追加することができます。表10-1には、WebCenter Portalコンポーネント用にドメインを拡張するために、WebCenter Portalを構成する手順と、その他の必要なタスクを示しています。

表10-1 WebCenter Portalコンポーネントを使用するためのドメインの拡張の手順

手順

説明

詳細

WebCenter Portalコンポーネントを使用するためのドメインの拡張

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogicドメインを拡張します。

第10.2項「WebCenter Portalコンポーネントを使用するための構成ウィザードを使用したドメインの拡張」

WebCenter Portal管理対象サーバーのホスト名の検証の無効化

ホスト名の検証を無効にします。

第10.3.1項「WebCenter Portal管理対象サーバーに対するホスト名検証の無効化」

構成後のタスクの実行

構成後タスクの手順に従います。

第10.3項「構成後のタスク」

ドメイン構成の管理対象サーバーのドメイン・ディレクトリへの伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第10.3.3項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更の伝播」

ドメイン構成のSOAHOST2、WCPHOST1、WCPHOST2への伝播

その他すべての管理対象サーバーにドメイン構成を伝播します。

第10.4.1項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」

Javaオブジェクト・キャッシュの構成

Javaオブジェクト・キャッシュを構成し、Spacesアプリケーションのパフォーマンスを向上させます。

第10.5項「Spaces_Cluster用のJavaオブジェクト・キャッシュの構成」

WebCenter Portalサービスの構成

ディスカッション、Analytics、アクティビティ・グラフおよびREST APIサービスを構成します。

第10.6項「マルチキャストからユニキャストへのディスカッションの変換」

第10.7項「ディスカッション・サーバーでのクラスタリングの構成」

第10.8項「Analyticsの構成」

第10.9項「アクティビティ・グラフの構成」

第10.10項「REST APIの構成」

拡張したドメインでのOracle HTTP Serverの構成

管理対象サーバーにOracle HTTP Serverを構成し、アクセスを検証します。

第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」

WebCenter Portalの構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第10.12項「WebCenter Portalの構成のバックアップ」

10.2 WebCenter Portalコンポーネントを使用するための構成ウィザードを使用したドメインの拡張

WebCenter Portalコンポーネントを含めるために、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを、構成ウィザードを使用して拡張できます。

注意:

ドメインを拡張する前に、現在のドメインをバックアップする必要があります。ドメインの拡張時になんらかのエラーが発生した場合は、このバックアップを使用してリカバリできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

構成ウィザードを使用してドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内の管理対象サーバーをすべてシャットダウンします。

3. 構成ウィザードの場所にディレクトリを変更します。これは共通のOracleホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するSOAHOST1から実行することに注意してください)。

cd ORACLE_COMMON_HOME/common/bin

4. 構成ウィザードを開始します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. 「WebLogicドメイン・ディレクトリ」画面で、WebLogicドメイン・ディレクトリを選択します。

ORACLE_BASE/admin/domain_name/aserver/domain_name

「次へ」をクリックします。

7. 「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。

- Oracle WebCenter Spaces

- Oracle WebCenterサービス・ポートレット

- Oracle WebCenterページレット・プロデューサ

- Oracleポートレット・プロデューサ

- Oracle WebCenterディスカッション・サーバー

- Oracle WebCenterアクティビティ・グラフ・エンジン

- Oracle WebCenterパーソナライズ

- Oracle Webcenter Analyticsコレクタ

次の製品はすでに選択されてグレー表示されています。これらは、第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」の手順でドメインを作成したときに選択したものです。

- WebLogic Serverの基本ドメイン

- Oracle JRF

- Oracle WSM Policy Manager

「次へ」をクリックします。

8. このドメインではOracle JRFが定義済であることを示す「競合の検出」メッセージが表示された場合は、「既存のコンポーネントを保持する」オプションを選択して、「OK」をクリックします。

9. 「JDBCデータ・ソースの構成」画面で、次の手順を実行します。

1. 次のデータソースが画面に表示されることを確認します。表10-2に示すユーザー名は、RCUでスキーマを作成する際に接頭辞としてwcpedgが使用されていると想定しています。

表10-2 データソースの値

データ・ソース

ユーザー名

WebCenterDSスキーマ

wcpedg_webcenter

ActivitiesDSスキーマ

wcpedg_activities

DiscussionDSスキーマ

wcpedg_discussions

PersonalizationDSスキーマ

wcpedg_webcenter

PortletDSスキーマ

wcpedg_portlet

Portlet-ServicesProducerDS

wcpedg_portlet

WC-ServicesProducerDS

wcpedg_webcenter

WebCenterMDSスキーマ

wcpedg_mds

PersonalizationMDSスキーマ

wcpedg_mds

mds-PageletProducerDSスキーマ

wcpedg_mds

mds-ServicesProducerDSスキーマ

wcpedg_mds

2. 表10-2のコンポーネント・スキーマの横のすべてのチェック・ボックスを選択します。

3. RACの構成には、(付録A「Oracle RACでのマルチ・データ・ソースの使用」で説明した)「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます。
ここの手順では、「GridLinkへ変換」を選択します。

4. 「次へ」をクリックします。

10. 「GridLink RACコンポーネント・スキーマの構成」画面で、次の手順を実行します。

1. 最初のGridLinkデータ・ソース・スキーマである、WebCenterDSスキーマを選択します。

2. 次の各フィールドに値を入力して、RCUでシードされたGridLink Oracle RACデータベースの接続情報を指定します。

- ドライバ: 「OracleのGridLinkConnectionsドライバ(Thin)、バージョン: 10以降」を選択します。

- サービス名: Oracle RACデータベースのサービス名と、続けてドメイン名を小文字で入力します。たとえば、wcpedg.mycompany.comです。

- ユーザー名: データベースのスキーマ所有者の完全な名前(接頭辞を含む)を入力します。表10-2に示すユーザー名は、RCUでスキーマを作成する際に接頭辞としてwcpedgが使用されていると想定しています。

- パスワード: データベース・スキーマ所有者のパスワードを入力します。

- FANの有効化: このオプションを選択します。

- SSLの有効化: このオプションを選択解除します。
Oracle Notification Service (ONS)の通知の暗号化するためにSSLが選択されている場合は、「ウォレット・ファイル」と「ウォレット・パスワード」に適切な詳細を入力します。

- サービス・リスナー: 使用しているOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。このプロトコルは、TCPである必要があります。
Oracle RACノードの追加または削除時にSCANアドレスを含むGridLinkデータ・ソースを更新する必要がないよう、サービス・リスナー(とOSNホスト)の指定にはSCANアドレスを使用することをお薦めします。SCANアドレスを判断するには、データベースに対してremote_listenerパラメータを問い合わせます。

SQL>show parameter remote_listener;

NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      db-scan.mycompany.com:1521

注意:

データベース・バージョンがSCANをサポートしない場合は次を実行します。

- Oracle Database 11gリリース1 (11.1)の場合、各データベースのインスタンス・リスナーの仮想IPとポートを次のように入力します。
custdbhost1-vip.mycompany.com (Port 1521)

および

custdbhost2-vip.mycompany.com (Port 1521)

- Oracle Database 10gの場合、マルチ・データ・ソースを使用し、Oracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: データベースからの通知のとおり、Oracle RACデータベースとONSリモート・ポートのSCANアドレスを入力します。

[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 (Port 6200)

3. たとえば、次のActivitiesDSスキーマを選択し、適切な詳細を指定します。
表10-2のすべてのWebCenter Portalスキーマに、GridLink情報が入力されていることを確認します。

4. 「次へ」をクリックします。

11. 「JDBCデータ・ソースのテスト」画面で、テストするスキーマを選択し(または「すべて選択」をクリックし)、「接続のテスト」をクリックします。
「接続結果ログ」に結果が表示されます。スキーマを含むデータベースに正常に接続できたことを確認します。できなかった場合は、「前」をクリックし、前の画面に戻り、入力を修正し、テストを再試行します。

すべての接続に成功したら「次へ」をクリックします。

12. 「オプションの構成を選択」画面で、次の項目を選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

13. 「管理対象サーバーの構成」画面で、次の管理対象サーバー(表10-3)を追加します。

表10-3 管理対象サーバー

名前

サーバー

リスニング・ポート

SSLリスニング・ポート

SSL有効

WC_Spaces1

WCPHOST1

9000

該当なし

いいえ

WC_Spaces2

WCPHOST2

9000

該当なし

いいえ

WC_Portlet1

WCPHOST1

9001

該当なし

いいえ

WC_Portlet2

WCPHOST2

9001

該当なし

いいえ

WC_Collaboration1

WCPHOST1

9002

該当なし

いいえ

WC_Collaboration2

WCPHOST2

9002

該当なし

いいえ

WC_Utilities1

WCPHOST1

9003

該当なし

いいえ

WC_Utilities2

WCPHOST2

9003

該当なし

いいえ

注意:

管理対象サーバーの名前をここで変更できますが、このページにある元の管理対象サーバーのいずれをも削除しないようにしてください。

注意:

クラスタ・モードがユニキャストの場合、リスニング・アドレスの指定は必須です。

「次へ」をクリックします。

14. 「クラスタの構成」画面で、4つ新しいクラスタ(表10-4)を追加します。

注意:

WSM-PM_Clusterはリストにすでにあるはずです。

表10-4 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

Spaces_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

Portlet_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

Collab_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

Utilities_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

「次へ」をクリックします。

15. 「サーバーのクラスタへの割当」画面で、次のようにサーバーをクラスタに割り当てます。

- Spaces_Cluster:

- WC_Spaces1

- WC_Spaces2

- Portlet_Cluster:

- WC_Portlet1

- WC_Portlet2

- Collab_Cluster:

- WC_Collaboration1

- WC_Collaboration2

- Utilities_Cluster:

- WC_Utilities1

- WC_Utilities2

「次へ」をクリックします。

16. 「マシンの構成」画面で「Unixマシン」タブをクリックし、次の4つのエントリがあることを確認します。

表10-5 マシン

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1

SOAHOST1は、第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」で構成ウィザードを実行したときにすでに構成されています。

SOAHOST2

SOAHOST2

SOAHOST2は、第8.3項「SOAHOST1での構成ウィザードを使用したドメインの作成」で構成ウィザードを実行したときにすでに構成されています。

WCPHOST1

WCPHOST1

WCPHOST2

WCPHOST2

その他すべてのフィールドはデフォルト値のままにします。

「次へ」をクリックします。

17. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- ADMINHOST:

- AdminServer

- SOAHOST1:

- WLS_WSM1

- SOAHOST2:

- WLS_WSM2

- WCPHOST1:

- WC_Spaces1

- WC_Portlet1

- WC_Collaboration1

- WC_Utilities1

- WCPHOST2:

- WC_Spaces2

- WC_Portlet2

- WC_Collaboration2

- WC_Utilities2

注意:

構成ウィザードにデフォルトで表示される元のサーバーの名前を変更することはできますが、絶対に削除はしないでください。

「次へ」をクリックします。

18. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- wsm-pmアプリケーションは、WSM-PM_Clusterにのみターゲット設定する必要があります。

「次へ」をクリックします。

19. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- mds-owsmをWSM-PM_ClusterとAdminServerの両方のターゲットとします。

「次へ」をクリックします。

20. 「構成サマリー」画面では、(ドメインを拡張しているので)画面に表示される情報は変更しないようにしてください。「拡張」をクリックします。

21. 「ドメインの拡張」画面で、「完了」をクリックします。
この構成を有効にするには、管理サーバーを起動する必要があります。

22. 管理サーバーを、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で起動します。

10.3 構成後のタスク

構成ウィザードでドメインを拡張した後は、次の手順に従って構成後タスクを実行します。

この項の内容は次のとおりです。

- 第10.3.1項「WebCenter Portal管理対象サーバーに対するホスト名検証の無効化」

- 第10.3.2項「SOAHOST1でのノード・マネージャの起動」

- 第10.3.3項「管理対象サーバーのドメイン・ディレクトリへのドメイン変更の伝播」

10.3.1 WebCenter Portal管理対象サーバーに対するホスト名検証の無効化

このマニュアルでは、WebCenter Portalを使用するためのドメインの拡張手順の完了後、管理サーバーで様々なノードを認証するために適切な証明書を設定します。そのため、WebCenter Portalの管理対象サーバーのホスト名検証を無効化して、様々なWebLogicサーバーを管理するときにエラーが出ないようにします。エンタープライズ・デプロイメントのトポロジ構成が完了したときに、ホスト名検証を再び有効化します。詳細は、第11.5項「SOAHOST2およびWCPHOST2でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

ホスト名検証を無効化するには:

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」を選択します。「サーバーの概要」ページが表示されます。

5. 表の「名前」列で「WC_Spaces1」(これはハイパーリンクとして表示されています)を選択します。「設定」ページが表示されます。

6. 「SSL」タブを選択します。

7. 表示されたページの「詳細」セクションを開きます。

8. 「ホスト名の検証」を「なし」に設定します。

9. これらの手順を、管理対象サーバーWC_Spaces2、WC_Portlet1、WC_Portlet2、WC_Collaboration1、WC_Collaboration2、WC_Utilities1およびWC_Utilities2に対して繰り返します。

10. 変更を保存してアクティブ化します。

11. この変更内容を有効にするには、管理サーバーおよびノード・マネージャを再起動する必要があります。

1. 管理サーバーを再起動する手順は、第8章「SOAHOST1での管理サーバーの起動」を参照してください。

2. SOAHOST1でノード・マネージャを再起動するには、第10章「SOAHOST1でのノード・マネージャの起動」を参照してください。

10.3.2 SOAHOST1でのノード・マネージャの起動

startNodeManager.shスクリプトを使用してノード・マネージャを再起動します。

SOAHOST1でノード・マネージャを再起動するには:

1. ノード・マネージャに関係付けられたプロセスを停止することで、ノード・マネージャを停止します。

- シェルのフォアグラウンドで実行されている場合は、[Ctrl]を押しながら[C]を押します。

- シェルのバックグラウンドで実行されている場合は、関連付けられたプロセスを見つけ、killコマンドを使用して停止します。次に例を示します。

ps -ef | grep NodeManager
orcl      9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh

kill -9 9139

2. ノード・マネージャを起動します。

cd WL_HOME/server/bin
./startNodeManager.sh

10.3.3 管理対象サーバーのドメイン・ディレクトリへのドメイン変更の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

起動スクリプトとクラスパス構成を伝播する手順は次のとおりです。

1. 管理対象サーバーのドメイン・ディレクトリと管理対象サーバーのアプリケーション・ディレクトリのコピーを作成します。

2. 次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=wcdomaintemplate.jar -template_name=wcdomaintemplate

3. 次のようにunpackコマンドをSOAHOST1上で実行して、伝播されたテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

./unpack.sh
-domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-template=wcdomaintemplate.jar
-overwrite_domain=true
-app_dir=ORACLE_BASE/admin/domain_name/mserver/apps

注意:

unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に再適用する必要があります。

10.4 SOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播

SOAHOST1の構成が完了したら、unpackユーティリティを使用してSOAHOST2、WCPHOST1およびWCPHOST2に構成を伝播し、伝播した構成を検証します。

この項の内容は次のとおりです。

- 第10.4.1項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」

- 第10.4.2項「WCPHOST1およびWCPHOST2でのノード・マネージャの起動」

- 第10.4.3項「WCPHOST1でのWC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの起動」

- 第10.4.4項「WebCenter PortalのためのGridLinkデータ・ソース構成およびONS構成の検証」

- 第10.4.5項「WC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの検証」

- 第10.4.6項「WCPHOST2でのWC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの起動」

- 第10.4.7項「WC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの検証」

10.4.1 unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播

構成したばかりのドメインをSOAHOST2、WCPHOST1およびWCPHOST2にunpackユーティリティを使用して伝播できます。

注意:

システム間でミドルウェア・ホームが共有されている場合は、ドメイン・テンプレートが適切なディレクトリに存在しているはずなので、次のステップ1を省略できます。

ドメイン構成を伝播する手順は次のとおりです。

1. SOAHOST1で次のコマンドを実行し、すでに作成されているテンプレート・ファイルをSOAHOST2、WCPHOST1およびWCPHOSTにコピーします。

scp wcdomaintemplate.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin

scp wcdomaintemplate.jar oracle@WCPHOST1:ORACLE_COMMON_HOME/common/bin

scp wcdomaintemplate.jar oracle@WCPHOST2:ORACLE_COMMON_HOME/common/bin

2. unpackコマンドをSOAHOST2、WCPHOST1とWCPHOST2で実行し、伝播されたテンプレートを解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh
-domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/
-template=wcdomaintemplate.jar
-overwrite_domain=true
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

3. WCPHOST1およびWCPHOST2に対し、前述の手順を繰り返します。

10.4.2 WCPHOST1およびWCPHOST2でのノード・マネージャの起動

startNodeManager.shスクリプトを使用し、ノード・マネージャを起動します。

WCPHOST1とWCPHOST2でノード・マネージャを起動するには、次の手順を実行します。

1. WCPHOST1とWCPHOST2の両方でノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティを'true'に設定します。

WCPHOSTn> cd ORACLE_COMMON_HOME/common/bin
WCPHOSTn> ./setNMProps.sh

注意:

WebCenter Portalサーバーが、(第3章「エンタープライズ・デプロイメント用のネットワークの準備」のとおり、)MiddlewareホームをSOAとローカルまたは共有記憶域で共有し、SOAがすでに構成されている場合、手順1は省略できます。このインスタンスでは、setNMProps.shは再度実行する必要がなく、ノード・マネージャはすでにSOAHOST1およびSOAHOST2で実行されています。

2. WCPHOST1およびWCPHOST2の両方で次のコマンドを実行し、ノード・マネージャを起動します。

WCPHOST1> cd WL_HOME/server/bin
WCPHOST1> ./startNodeManager.sh

WCPHOST2> cd WL_HOME/server/bin
WCPHOST2> ./startNodeManager.sh

10.4.3 WCPHOST1でのWC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの起動

管理コンソールを使用し、WC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーを起動するには、次の手順を実行します。

1. 管理コンソール(http://ADMINVHN:7001/console)にアクセスします。
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 「制御」タブを開きます。

5. 「WC_Spaces1」、「WC_Portlet1」、「WC_Utilities1」および「WC_Collaboration1」を選択します。

6. 「起動」をクリックします。

10.4.4 WebCenter PortalのためのGridLinkデータ・ソース構成およびONS構成の検証

WC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1の伝播を行う前に、前に作成したGridLinkデータ・ソースの構成とOracle Notification Service (ONS)の設定がデータ・ソースに対して正しいことを検証する必要があります。

GridLinkデータ・ソースとWebCenter Portalの構成を確認するには、次の手順を実行します。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 作成済のGridLinkデータ・ソース名をクリックします。

4. 「テスト」タブをクリックし、WebCenter Portal管理対象サーバーの1つを選択して「データ・ソースのテスト」をクリックします。
構成が正しい場合、テストは成功します。

5. GridLinkデータ・ソースを使用する各WebCenter管理対象サーバーに、テストを繰り返します。

6. 「監視」タブをクリックし、サーバー名の1つをクリックします。

7. 「ONS」→「テスト」タブをクリックします。

8. たとえば、WC_Spaces1など、WebCenter Portal管理対象サーバーの1つを選択し、「ONSのテスト」をクリックします。
構成が正しい場合、ONSのテストは成功します。ONSのテストが失敗する場合、Oracle RACデータベース・ノードでONSサービスが実行されていることを確認します。

[orcl@db-scan1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node db-scan1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node db-scan2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node db-scan3

[orcl@db-scan1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: db-scan1
ONS daemon is running on node: db-scan2

9. GridLinkデータ・ソースを使用する各WebCenter Portal管理対象サーバーに、ONSテストを繰り返します。

10.4.5 WC_Spaces1、WC_Portlet1、WC_Utilities1およびWC_Collaboration1管理対象サーバーの検証

WCPHOST1上のすべてのWebCenter Portal管理対象サーバーが起動され稼働中であることを確認するには、次の手順を実行します。

1. 次のURLをテストして、管理対象サーバーがアクセス可能であることを確認します。

- http://WCPHOST1:9000/webcenter

- http://WCPHOST1:9000/webcenterhelp

- http://WCPHOST1:9000/rss

- http://WCPHOST1:9000/rest

- http://WCPHOST1:9001/pagelets

- http://WCPHOST1:9001/portalTools

- http://WCPHOST1:9001/wsrp-tools

- http://WCPHOST1:9002/owc_discussions

- http://WCPHOST1:9003/activitygraph-engines/Login.jsp

- http://WCPHOST1:9003/wcps/api/property/resourceIndex

2. すべてのデプロイメントがアクティブであることを確認します。管理コンソールで、「デプロイ」を選択します。
いずれかに障害が発生した場合は、ログ・ファイルでエラーを確認します。ログ・ファイルは次の場所にあります。

ORACLE_BASE/admin/domain_name/mserver/domain_home/servers/server_name/logs

10.4.6 WCPHOST2でのWC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの起動

管理コンソールを使用し、WC_Spaces2、WC_Portlet2、WC_Utilities2および WC_Collaboration2管理対象サーバーを起動するには、次の手順を実行します。

1. 管理コンソール(http://ADMINVHN:7001/console)にアクセスします。
ADMINVHNは、SOAHOST1で管理サーバーがリスニングする仮想IPにマップされる仮想ホスト名です。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 「制御」タブを開きます。

5. 「WC_Spaces2」、「WC_Portlet2」、「WC_Utilities2」および「WC_Collaboration2」を選択します。

6. 「起動」をクリックします。

10.4.7 WC_Spaces2、WC_Portlet2、WC_Utilities2およびWC_Collaboration2管理対象サーバーの検証

WCPHOST2上のすべてのWebCenter Portal管理対象サーバーが起動され稼働中であることを確認するには、次の手順を実行します。

1. 次のURLをテストして、管理対象サーバーがアクセス可能であることを確認します。

- http://WCPHOST2:9000/webcenter

- http://WCPHOST2:9000/webcenterhelp

- http://WCPHOST2:9000/rss

- http://WCPHOST2:9000/rest

- http://WCPHOST2:9001/pagelets

- http://WCPHOST2:9001/portalTools

- http://WCPHOST2:9001/wsrp-tools

- http://WCPHOST2:9002/owc_discussions

- http://WCPHOST2:9003/wcps/api/property/resourceIndex

2. すべてのデプロイメントがアクティブであることを確認します。管理コンソールで、「デプロイ」を選択します。
いずれかに障害が発生した場合は、ログ・ファイルでエラーを確認します。ログ・ファイルは次の場所にあります。

ORACLE_BASE/admin/domain_name/mserver/domain_home/servers/server_name/logs

10.5 Spaces_Cluster用のJavaオブジェクト・キャッシュの構成

Spaces_Cluster内のすべての管理対象サーバーのJavaオブジェクト・キャッシュ(JOC)を構成できます。このローカル・キャッシュは、Spacesアプリケーションのパフォーマンスを向上させるために提供されています。

Javaオブジェクト・キャッシュはMW_HOME/oracle_common/bin/configure-joc.pyスクリプトを使用して構成できます。これは管理対象サーバーでのJOCの構成に使用できるPythonスクリプトです。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが稼働中であることが求められます。WLSTオンライン・モードの詳細は、『Oracle Application Server管理者ガイド』のOracle WebLogic Scripting Tool (WLST)の使用に関するスタート・ガイドを参照してください。

注意:

WLSTコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成したら、影響を受ける管理対象サーバーをすべて再起動して、その構成を有効にする必要があります。

WebCenter Portal管理対象サーバー用のJavaオブジェクト・キャッシュを構成するには、次の手順を実行します。

1. たとえば、次のようにWLSTを使用し管理サーバーに接続します。

MW_HOME/wc/common/bin/wlst.sh
$ connect()

Oracle WebLogicの管理ユーザー名とパスワードの入力を求められたら、これらを入力します。

2. WLSTを使用して管理サーバーに接続後、execfileコマンドを使用してスクリプトを開始します。たとえば、次のようにします。

wls:/mydomain/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")

3. 特定のクラスタのすべての管理対象サーバー用のJOCの構成
クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたら'y'を入力し、プロンプトが表示されたらクラスタ名と検出ポートを指定します。これによって、指定したクラスタの管理対象サーバーがすべて検出され、JOCが構成されます。検出ポートはクラスタのJOC構成全体で共通です。

注意:

検出ポートには任意の空きポートを指定できます。

高可用性環境でconfigure-joc.pyを使用する場合の手順を次に示します。

execfile("MW_HOME/oracle_common/bin/configure-joc.py")
.
Enter Hostnames (eg host1,host2) : WCPHOST1,WCPHOST2
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : Spaces_Cluster
.
Enter Discover Port : 9988
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n

このスクリプトを使用すると、次のJOCの構成も実行できます。

- 指定されたすべての管理対象サーバー用のJOCの構成
クラスタ名を指定するかどうかを尋ねるプロンプトが表示されたら'n'を入力し、プロンプトが表示されたら管理対象サーバーと検出ポートを指定します。次に例を示します。

Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WC_Spaces1:9988,WC_Spaces2:9988) : WC_Spaces1:9988,WC_Spaces2:9988

- 一部の管理対象サーバー用の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) : WC_Spaces1,WC_Spaces2

- すべての管理対象サーバーに対して分散モードを無効にします。
このスクリプトでは、指定されたクラスタのすべての管理対象サーバーに対する分散を無効にできます。分散モードに関するプロンプトが表示されたら'false'を指定します。デフォルトでは、分散モードは'true'に設定されています。

CacheWatcherユーティリティを使用してJOCの構成を確認します。『Oracle Fusion Middleware高可用性ガイド』を参照してください。

『Oracle Fusion Middleware高可用性ガイド』で説明しているように、Oracle WebLogic管理コンソールで「HAパワー・ツール」タブを使用してJavaオブジェクト・キャッシュ(JOC)を構成できます。

10.6 マルチキャストからユニキャストへのディスカッションの変換

(Collab_Cluster内のすべての管理対象サーバー上の)ディスカッションをマルチキャストからユニキャストに変換するには、関係する起動パラメータを追加します。

1. Oracle WebLogic Server管理コンソールで、「サーバー」→「WC_Collaboration1」→「構成」→「サーバーの起動」を選択します。

2. 「 引数 」ボックスに次の引数を追加します。

-Dtangosol.coherence.wka1=WCPHOST1
-Dtangosol.coherence.wka2=WCPHOST2
-Dtangosol.coherence.localhost=WCPHOST1
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
-Dtangosol.coherence.localport=8089

ここで、WCPHOST1は、WC_Collaboration1が実行されているホストになります。

ポート8089は、WebCenter Coherenceの通信用に予約されているポートです。

3. WCPHOST1をWCPHOST2に、WCPHOST2をWCPHOST1に替えて、WC_Collaboration2に対して手順1と2を繰り返します。

-Dtangosol.coherence.wka1=WCPHOST2
-Dtangosol.coherence.wka2=WCPHOST1
-Dtangosol.coherence.localhost=WCPHOST2
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
-Dtangosol.coherence.localport=8089

4. WC_Collaborationサーバーを再起動します。

10.7 ディスカッション・サーバーでのクラスタリングの構成

ユニキャスト・クラスタの場合は、まず、第10.6項「マルチキャストからユニキャストへのディスカッションの変換」の手順をすべて完了します。

ディスカッション・クラスタ内のすべてのメンバーが互いに通信できるようにするには、次の手順を実行します。

1. 次の場所にあるクラスタ内の各メンバー用のディスカッション・サーバーの管理コンソールにログインします。

http://host:port/owc_discussions/admin

2. 「キャッシュ設定」を選択します。

図10-1 「キャッシュ設定」セクション

「図10-1 「キャッシュ設定」セクション」の説明

3. 「キャッシュ機能」セクションで、「クラスタリング」が「有効」に設定されていることを確認します。
サーバーは、クラスタを結合すると、画面の上部に表示されます。

4. 「ツール」セクションで、「クラスタ・メンバーをすべてリセット」と「キャッシュ・ウォームアップ・タスクの開始」を選択します。クラスタのすべてのメンバーで、キャッシュのウォームアップ・タスクを繰り返します。

図10-2 キャッシュ・ツールセクション

「図10-2 キャッシュ・ツールセクション」の説明

5. クラスタのすべてのメンバーに対して、手順1から4を繰り返します。
サーバーは、クラスタを結合すると、画面の上部に表示されます。

10.8 Analyticsの構成

Analyticsコレクタは、デフォルトでローカルのSpacesアプリケーションと1対1の関係で通信できるよう構成されています(コレクタはlocalhostをリスニングします)。Analyticsコレクタは、別途構成する必要はありません。

ただし、localhostにイベント・メッセージを送信するよう、Spacesアプリケーションを構成する必要があります。

注意:

クラスタ化されたAnalyticsコレクタでは、WebCenter Portalのイベントの収集はサポートしていません。

SpacesアプリケーションをAnalyticsコレクタに接続するには、次の手順を実行します。

1. Spacesアプリケーションが実行されている管理対象サーバーに、WLSTを使用し、たとえば次のように接続します。

MW_HOME/wc/common/bin/wlst.sh
connect("weblogic_admin_username", "weblogic_admin_pwd", "WCPHOST1:9000")

WC_Spacesサーバーのホストとポートに接続します。

2. SpacesアプリケーションとAnalyticsコレクタ間に接続を作成し、それをデフォルトの接続にします(default=1)。
次に例を示します。

createAnalyticsCollectorConnection(appName="webcenter", name="HAConn1", isUnicast=1,
collectorHost="localhost", collectorPort=31314, isEnabled=1, timeout=30, default=1)

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのcreateAnalyticsCollectorConnectionに関する説明も参照してください。

3. 変更を確認します。

listDefaultAnalyticsCollectorConnection(appName="webcenter")

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのlistDefaultAnalyticsCollectorConnectionに関する説明も参照してください。

10.9 アクティビティ・グラフの構成

アクティビティ・グラフはシングルトンとして実行する必要があります。クラスタ環境では、すべてのアクティビティ・グラフ・エンジン・アプリケーションのインスタンスは1つを除いてすべて無効化する必要があります。

アクティビティ・グラフ・エンジン・アプリケーションを無効化する手順は次のとおりです。

1. 管理コンソールにログインします。

2. WC_Utilities1とWC_Utilities2サーバーをシャットダウンします。

3. 「デプロイメント」を選択します。

4. 「ロックして編集」をクリックします。

5. これらの各デプロイメントのターゲットを変更します。

- activitygraph-engines (11.1.1.6.0)

- oracle.webcenter.activitygraph.enginelib(11.1.1,11.1.1)

- oracle.webcenter.activitygraph.lib(11.1.1,11.1.1)

1. デプロイメントを選択します。

2. 「ターゲット」タブを選択します。

3. 「ターゲットの変更」をクリックします。

4. Utilities_Clusterのデプロイメントのターゲットが、クラスタの一部/管理対象サーバーの1つのみになっていることを確認します。その他のサーバーおよびクラスタのターゲットは変更しないでください。

5. 「OK」をクリックして変更を保存します。

6. 3つのデプロイメントのすべての手順を完了したら、「すべての変更のアクティブ化」をクリックします。

7. WC_Utilities1サーバーとWC_Utilities2サーバーを起動します。

アクティビティ・グラフは1つのノードでのみ実行されているので、このノードが失われたり、管理対象サーバーが使用不可能であったりすると、アクティビティ・グラフが使用不可能になります。ノードに障害が発生した場合は、アクティビティ・グラフをクラスタ内で使用可能な他のいずれかの管理対象サーバーに手動でデプロイできます。

注意:

アクティビティ・グラフはフェイルオーバーできない他のコンポーネントと同じサーバー上にあるため、サーバーの移行をアクティビティ・グラフには構成しないことをお薦めします。サーバーの移行の詳細は、第14章「エンタープライズ・デプロイメント用のサーバーの移行の構成」を参照してください。

10.10 REST APIの構成

WebCenter Portal REST APIを使用する場合、この項で説明するサーバー側の構成を実行する必要があります。

RESTセキュリティ・トークンを正しく機能させる、資格証明ストア内のエントリをシードするには、次の手順を実行します。

1. コマンドラインのOracle WebLogic Scripting Tool(WLST)を使用して管理サーバーに接続します。例:

MW_HOME/wc/common/bin/wlst.sh

2. 次のWLSTのコマンドを実行して、資格証明ストアを構成します。

createCred(map="o.webcenter.jf.csf.map", key="keygen.algorithm",
user="keygen.algorithm", password="AES")
createCred(map="o.webcenter.jf.csf.map", key="cipher.transformation",
user="cipher.transformation", password="AES/CBC/PKCS5Padding")

後でOAMのRESTポリシーを構成する必要があります(第15章「RESTポリシーの更新」)。

REST APIの詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドを参照してください。

10.11 拡張したドメインでのOracle HTTP Serverの構成

この項の内容は次のとおりです。

- 第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」

- 第10.11.2項「Oracle HTTP Serverを介したアクセスの検証」

- 第10.11.3項「ロード・バランサを介したアクセスの検証」

10.11.1 WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成

Oracle HTTP ServerがWebCenter Portalクラスタにルーティングできるようにするには、クラスタ内のノードのリストをWebLogicClusterパラメータに設定する必要があります。次の行をすべてのWEBHOSTマシンのOHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに追加します。管理サーバーとSOAサーバーの以前の設定をすべて保持しておきます。完了したら、すべてのHTTP Serversを再起動します。

# Virtual Host for wcp.mycompany.com holds all the external URLs. The Virtual Host should already exist
# and any existing Location blocks should be kept.

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://wcp.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# Spaces Application
<Location /webcenter>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /webcenterhelp>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /rss>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /rest>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Discussions
<Location /owc_discussions>
WebLogicCluster WCPHOST1:9002,WCPHOST2:9002
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Portlets

<Location /pagelets>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /portalTools>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /wsrp-tools>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Personalization

<Location /wcps>
WebLogicCluster WCPHOST1:9003,WCPHOST2:9003
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#Activity Graph
#The WebLogicHost below should be set to the Host on which ActivityGraph is running.

<Location /activitygraph-engines>
WebLogicHost WCPHOST1
WebLogicPort 9003
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
</VirtualHost>

# Virtual host entry for internal http URL.
# This should already be in the config file. The new Location blocks go inside of it

NameVirtualHost *:7777

<VirtualHost *:7777>
ServerName wcpinternal.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

# Portlet Internal access

<Location  /pagelets>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
</Location>

<Location /portalTools>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
</Location>

<Location /wsrp-tools>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9001
SetHandler weblogic-handler
</Location>

# Discussions Internal access
<Location /owc_discussions>
WebLogicCluster WCPHOST1:9001,WCPHOST2:9002
SetHandler weblogic-handler
</Location>

</VirtualHost>

#Virtual host for SharePoint access
<VirtualHost *:7777>
ServerName wcp-spaces.mycompany.com
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

#SharePoint entry point
<Location />
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Spaces Application
<Location /webcenter>
Deny from all
</Location>

<Location /webcenterhelp>
Deny from all
</Location>

<Location /rss>
Deny from all
</Location>

<Location /rest>
Deny from all
</Location>

</VirtualHost>

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サーバー・プラグインの使用』ガイドを参照してください。

10.11.1.1 Microsoftクライアントの構成

Microsoftクライアントの組込みについては、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドの概要および詳細な手順を参照してください。

具体的には、これらのクライアントに別のコンテキスト・ルートを提供するには、別に仮想ホストを作成する必要があります。手順については、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドの仮想ホストでのSSOの構成に関する説明を参照してください。

Windows認証サービスを正しく構成する手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのMicrosoftクライアント用のSSOの構成に関する手順を参照してください。

10.11.2 Oracle HTTP Serverを介したアクセスの検証

次のURLにアクセスできることを確認します。

- http://WEBHOSTn:7777/webcenter

- http://WEBHOSTn:7777/webcenterhelp

- http://WEBHOSTn:7777/rss

- http://WEBHOSTn:7777/rest

- http://WEBHOSTn:7777/pagelets

- http://WEBHOSTn:7777/portalTools

- http://WEBHOSTn:7777/wsrp-tools

- http://WEBHOSTn:7777/owc_discussions

- http://WEBHOSTn:7777/activitygraph-engines/Login.jsp

- http://WEBHOSTn:7777/wcps/api/property/resourceIndex

ここで、WEBHOSTnは各Oracle HTTP Serverホスト(たとえば、WEBHOST1、WEBHOST2)です。

10.11.3 ロード・バランサを介したアクセスの検証

次のURLにアクセスできることを確認します。

- https://wcp.mycompany.com/webcenter

- https://wcp.mycompany.com/webcenterhelp

- https://wcp.mycompany.com/rss

- https://wcp.mycompany.com/rest

- https://wcp.mycompany.com/pagelets

- https://wcp.mycompany.com/portalTools

- https://wcp.mycompany.com/wsrp-tools

- https://wcp.mycompany.com/owc_discussions

- https://wcp.mycompany.com/activitygraph-engines/Login.jsp

- https://wcp.mycompany.com/wcps/api/property/resourceIndex

10.12 WebCenter Portalの構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『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. データベースのバックアップを取ります。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップします。バックアップを実行してドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/admin/domain_name

管理サーバーをバックアップするには、SOHOST1で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

11 エンタープライズ・デプロイメント用のノード・マネージャの設定

この章では、エンタープライズ・デプロイメントの推奨事項に従ってノード・マネージャを構成する方法を説明します。

この章の項目は次のとおりです。

- 第11.1項「ノード・マネージャの概要」

- 第11.2項「ノード・マネージャのログの場所の変更」

- 第11.3項「SOAHOST1およびWCPHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」

- 第11.4項「SOAHOST1でのノード・マネージャの起動」

- 第11.5項「SOAHOST2およびWCPHOST2でのノード・マネージャに対するホスト名検証証明書の有効化」

- 第11.6項「SOAHOST2でのノード・マネージャの起動」

- 第11.7項「カスタム・キーストアを使用するためのWebLogic Serverの構成」

11.1 ノード・マネージャの概要

ノード・マネージャを使用すると、管理サーバーおよび各管理対象サーバーの起動と停止が可能です。

オラクル社では、ノード・マネージャと管理サーバー間の通信にホスト名を使用した検証を使用することを推奨しています。このホスト名検証には、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。この章では、ホスト名検証に使用する証明書をSOAHOST1およびSOAHOST2に構成する手順を説明します。WCPHOST1とWCPHOST2についても同様の手順が必要です。その手順ではWCPHOST1とWCPHOST2に応じたホスト名の変更が必要ですが、一連の手順や構文はまったく同じです。

11.2 ノード・マネージャのログの場所の変更

Oracle Fusion Middlewareデプロイメントのノード・マネージャのログ・ファイルは、デフォルト(ノード・マネージャが存在するMW_Home内)以外の場所に置くことをお薦めします。

ノード・マネージャのログの場所を変更するには、次のディレクトリにあるnodemanager.propertiesファイルを編集します。

MW_HOME/wlserver_10.3/common/nodemanager

このファイルは、MW_HOMEディレクトリでなく、デプロイメントのadminディレクトリ内に置くことをお薦めします。

nodemanager.propertiesに次の行を追加します。

LogFile=ORACLE_BASE/admin/nodemanager.log

ノード・マネージャを再起動して、変更を有効にします。

11.3 SOAHOST1およびWCPHOST1でのノード・マネージャに対するホスト名検証証明書の有効化

ホスト名検証はノード・マネージャと管理サーバー間の通信を可能にするものです。この検証では、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。

この項の内容は次のとおりです。

- ステップ1: utils.CertGenユーティリティを使用した自己署名証明書の生成

- ステップ2: utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

- ステップ3: Keytoolユーティリティを使用した信頼キーストアの作成

- ステップ4: カスタム・キーストアを使用するためのノード・マネージャの構成

- ステップ5: 共通または共有記憶域インストールの使用

11.3.1 utils.CertGenユーティリティを使用した自己署名証明書の生成

この項では、SOAHOST1.mycompany.comに自己署名証明書を作成する手順を説明します。これらの証明書はネットワーク名/別名を使用して作成します。

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的(HTTPを起動するためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、SOAHOST2、WCPHOST1およびWCPHOST2では、SOAHOST1の証明書用に作成されたcertディレクトリを使用します。

自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。

パスワードについて

このガイドで使用するパスワードはあくまでも一例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字を含むパスワードを使用します。

自己署名証明書を作成する手順は次のとおりです。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。
Bourneシェルの場合、SOAHOST1上で次のコマンドを実行します。

. setWLSEnv.sh

CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

2. 証明書用のユーザー定義ディレクトリを作成します。

mkdir certs

3. ディレクトリをユーザー定義ディレクトリに変更します。

cd certs

4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、SOAHOST1、SOAHOST1VHN VIP、Admin VIPおよびWCPHOST1に対する証明書を作成します。
構文:

java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]

SOAHOST1からコマンド例を示します。

java utils.CertGen welcome1 SOAHOST1.mycompany.com_cert SOAHOST1.mycompany.com_key domestic SOAHOST1.mycompany.com

java utils.CertGen welcome1 SOAHOST1VHN1.mycompany.com_cert SOAHOST1VHN1.mycompany.com_key domestic SOAHOST1VHN1.mycompany.com

java utils.CertGen welcome1 ADMINVHN.mycompany.com_cert ADMINVHN.mycompany.com_key domestic ADMINVHN.mycompany.com

java utils.CertGen welcome1 WCPHOST1.mycompany.com_cert WCPHOST1.mycompany.com_key domestic WCPHOST1.mycompany.com

11.3.2 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

前の項で説明されている手順では、アイデンティティ・キーストアを作成してそれを共有記憶域に配置しました。この項では、SOAHOST1およびWCPHOST1用の新しい鍵をそのストアに追加します。SOAHOST1、SOAHOST1VHN1、ADMINVHNおよびWCPHOST1の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

次の手順に従って、SOAHOST1にアイデンティティ・キーストアを作成します。

1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreという名前の新しいアイデンティティ・キーストアを作成します。このキーストアの作成場所は、証明書と同じディレクトリ(ORACLE_BASE/admin/domain_name/cert)とします。

注意:

utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートする際、アイデンティティ・ストアが1つも存在しない場合は、新しく作成されます。

2. SOAHOST1、SOAHOST1VHN VIP、Admin VIPおよびWCPHOSTの証明書と秘密鍵をアイデンティティ・ストアにインポートします。必ず、インポートする証明書と鍵のペアごとに異なる別名を使用してください。
構文(すべてを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/SOAHOST1.mycompany.com_cert.pem
ORACLE_BASE/admin/domain_name/cert/SOAHOST1.mycompany.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity2 welcome1
ORACLE_BASE/admin/domain_name/cert/SOAHOST1VHN1.mycompany.com_cert.pem
ORACLE_BASE/admin/domain_name/cert/SOAHOST1VHN1.mycompany.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity3 welcome1
ORACLE_BASE/admin/domain_name/cert/ADMINVHN.mycompany.com_cert.pem
ORACLE_BASE/admin/domain_name/cert/ADMINVHN.mycompany.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity4 welcome1
ORACLE_BASE/admin/domain_name/cert/WCPHOST1.mycompany.com_cert.pem
ORACLE_BASE/admin/domain_name/cert/WCPHOST1.mycompany.com_key.pem

11.3.3 Keytoolユーティリティを使用した信頼キーストアの作成

SOAHOST1.mycompany.comに信頼キーストアを作成する手順は次のとおりです。

1. 新しい信頼キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJava信頼キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアのCA証明書を、証明書のあるディレクトリにコピーします。次に例を示します。

cp WL_HOME/server/lib/cacerts
ORACLE_BASE/admin/domain_name/aserver/domain_namecerts/appTrustKeyStore.jks

2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは常に変更することをお薦めします。これを実行するには、HOST上でkeytoolユーティリティを使用します。構文は、次のとおりです。

keytool -storepasswd -new NewPassword -keystore TrustKeyStore -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 AliasName
-file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password

次に例を示します。

keytool -import -v -noprompt -trustcacerts -alias clientCACert -file
WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass welcome1

11.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成するには、WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity KeyStore
CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd
CustomIdentityAlias=Identity Key Store Alias
CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate

各ノードに個々に割り当てられたカスタム・アイデンティティの別名が、各ノードのCustomIdentityAlias値に正しく使用されていることを確認します。たとえば、SOAHOST1では、第11.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」の手順に従ってappIdentity1を使用します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=welcome1
CustomIdentityAlias=appIdentity1
CustomIdentityPrivateKeyPassPhrase=welcome1

第11.4項「SOAHOST1でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

11.3.5 共通または共有記憶域インストールの使用

共通記憶域または共有記憶域のインストールをMW_HOMEに指定している場合、ノード・マネージャは同じ基本構成(nodemanager.properties)を使用してそれぞれのノードから起動します。第11.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」の説明のとおり、新しいノードの証明書を作成しappIdentityKeyStore.jksにインポートする方法で、バイナリを共有するすべてのノードの証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加します。このストアで証明書が使用できるようになった時点で、各ノード・マネージャはそれぞれのアイデンティティ別名を指定して、正しい証明書を管理サーバーに送信する必要があります。

各ノードでノード・マネージャを起動する前に、別の環境変数を設定する例を示します。

SOAHOST1> cd WL_HOME/server/bin
SOAHOST1>export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1

SOAHOST2> cd WL_HOME/server/bin
SOAHOST2> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST2

WCPHOST1> cd WL_HOME/server/bin
WCPHOST1> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityWCPHOST1

WCPHOST2> cd WL_HOME/server/bin
WCPHOST2> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityWCPHOST2

11.4 SOAHOST1でのノード・マネージャの起動

startNodeManager.shスクリプトを使用してSOAHOST1でノード・マネージャを起動します。

注意:

ノード・マネージャが未構成で、まだ起動もしていない場合は、第8.4.2項「SOAHOST1でのノード・マネージャの起動」の説明に従ってsetNMProps.shスクリプトを実行してください。これにより、SOAに必要な起動スクリプトを使用できるようになります。

SOAHOST1でノード・マネージャを起動する手順は次のとおりです。

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX
./startNodeManager.sh

注意:

各ホストに明確に割り当てられているカスタムのアイデンティティ別名を指定してください。つまり、...HOST1にはappIdentity1、...HOST2にはappIdentity2を指定します。

11.5 SOAHOST2およびWCPHOST2でのノード・マネージャに対するホスト名検証証明書の有効化

ホスト名検証はノード・マネージャと管理サーバー間の通信を可能にするものです。この検証では、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。

ノード・マネージャと管理サーバー間のSSL通信を設定するには、次の手順を実行します。

- ステップ1: utils.CertGenユーティリティを使用した自己署名証明書の生成

- ステップ2: utils.ImportPrivateKeyユーティリティを使用したIDキー・ストアの作成

- ステップ3: Keytoolユーティリティを使用した信頼キーストアの作成

- ステップ4: カスタム・キーストアを使用するためのノード・マネージャの構成

11.5.1 utils.CertGenユーティリティを使用した自己署名証明書の生成

この項では、SOAHOST2およびWCPHOST2に自己署名証明書を作成する手順を説明します。これらの証明書はネットワーク名/別名を使用して作成します。

キーストアおよび信頼キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、管理サーバー、SOAサーバー、WCPサーバーが(手動またはサーバー移行により)フェイルオーバーしたときに、ノードが適切な証明書にアクセスできるようにする必要があります。この場合、SOAHOST2では、SOAHOST1の証明書用に作成されたcertディレクトリを使用し、WCPHOST2では、WCPHOST1の証明書用に作成されたcertディレクトリを使用します。複製されたストアを保持している場合は、証明書用のユーザー定義ディレクトリを作成します。

ネットワーク名/別名を使用して、untils.CertGenユーティリティで自己署名証明書を作成します。

自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。

SOAHOST2およびWCPHOST2に自己署名証明書を作成する手順は次のとおりです。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。
Bourneシェルで次のコマンドを実行します。

. setWLSEnv.sh

CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

2. 証明書用のユーザー定義ディレクトリを作成します。

mkdir certs

3. ディレクトリをユーザー定義ディレクトリに変更します。

cd certs

4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、SOAHOST2、SOAHOST2VHN1、WCPHOST2に対する証明書を作成します。

構文:

java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [host_name]

例:

java utils.CertGen welcome1 SOAHOST2_cert SOAHOST2_key
domestic SOAHOST2.mycompany.com

java utils.CertGen welcome1 SOAHOST2VHN1_cert SOAHOST2VHN1_key
domestic SOAHOST2VHM1.mycompany.com

java utils.CertGen welcome1 WCPHOST2_cert WCPHOST2_key
domestic WCPHOST1.mycompany.com

11.5.2 utils.ImportPrivateKeyユーティリティを使用したIDキー・ストアの作成

前の項で説明されている手順では、アイデンティティ・キーストアを作成してそれを共有記憶域に配置しました。この項では、SOAHOST2およびWCPHOST2用の新しい鍵をそのストアに追加します。SOAHOST2、SOAHOST2VHN1、WCPHOST2の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

次の手順に従って、SOAHOST2.mycompany.comにアイデンティティ・キーストアを作成します。

1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreという名前の新しいアイデンティティ・キーストアを作成します。このキーストアの作成場所は、証明書と同じディレクトリ(ORACLE_BASE/admin/domain_name/cert)とします。

注意:

utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートする際、アイデンティティ・ストアが1つも存在しない場合は、新しく作成されます。

2. SOAHOST21、SOAHOST2VHN1、WCPHOST2の証明書と秘密鍵をアイデンティティ・ストアにインポートします。必ず、インポートする証明書と鍵のペアごとに異なる別名を使用してください。
構文(すべてを1行で入力します):

java utils.ImportPrivateKey Keystore_File Keystore_Password
Certificate_Alias_to_Use Private_Key_Passphrase
Certificate_File
Private_Key_File
[Keystore_Type]

例:

java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity1 welcome1
ORACLE_BASE/admin/domain_name/cert/SOAHOST2.mycompany.com_cert.pem
ORACLE_BASE/admin/domain_name/cert/SOAHOST2.mycompany.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity2 welcome1
ORACLE_BASE/admin/domain_name/cert/SOAHOST2VHN1.mycompany.com_cert.pem
ORACLE_BASE/admin/domain_name/cert/SOAHOST2VHN1.mycompany.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1
appIdentity4 welcome1
ORACLE_BASE/admin/domain_name/cert/WCPHOST2.mycompany.com_cert.pem
ORACLE_BASE/admin/domain_name/cert/WCPHOST2.mycompany.com_key.pem

11.5.3 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成する手順は次のとおりです。

1. WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity KeyStore
CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd
CustomIdentityAlias=Identity Key Store Alias
CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate

各ノードでCustomIdentityAliasの正しい値を使用してください。

SOAHOST2でappIdentity3を使用する例を次に示します

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=welcome1
CustomIdentityAlias=appIdentity3
CustomIdentityPrivateKeyPassPhrase=welcome1

注意:

第11.6項「SOAHOST2でのノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリは暗号化されます。

セキュリティ上の理由から、nodemanager.propertiesファイルのエントリが暗号化されていない時間を可能なかぎり短くする必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化してください。

11.6 SOAHOST2でのノード・マネージャの起動

startNodeManager.shスクリプトを使用してSOAHOST2でノード・マネージャを起動できます。

注意:

ノード・マネージャが未構成で、まだ起動もしていない場合は、第8.4.2項「SOAHOST1でのノード・マネージャの起動」の説明に従ってsetNMProps.shスクリプトを実行してください。これにより、SOAに必要な起動スクリプトを使用できるようになります。

SOAHOST2でノード・マネージャを起動する手順は次のとおりです。

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX
./startNodeManager.sh

注意:

各ホストに明確に割り当てられているカスタムのアイデンティティ別名を指定してください。つまり、...HOST1にはappIdentity1、...HOST2にはappIdentity2を指定します。

11.7 カスタム・キーストアを使用するためのWebLogic Serverの構成

Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。この手順を、管理サーバーおよびすべての管理対象サーバー(WLS_WSMn、WLS_SOAn、WC_Spacesn、WC_Collaborationn、WC_UtilitiesnおよびWC_Portletn)に対して完了します。

手順6のディレクトリ・パスは例です。キーストアは、aserverディレクトリではなく共有記憶域に配置することをお薦めします。証明書用のディレクトリとは別のディレクトリに配置する方がより適切です。

アイデンティティ・キーストアおよび信頼キーストアを構成する手順は次のとおりです。

1. 管理コンソールにログインして「ロックして編集」をクリックします。

2. 左ペインで「環境」を開き、「サーバー」を選択します。

3. アイデンティティ・キーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。

4. 「構成」を選択して、「キーストア」を選択します。

5. 「キーストア」フィールドで、秘密鍵/デジタル証明書の組合せおよび信頼できるCA証明書の格納および管理に使用するための「カスタムIDとカスタム信頼」方法を選択します。

6. 「ID」セクションで、アイデンティティ・キーストアの属性を定義します。

1. カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。

ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks

2. カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

3. カスタムIDキーストアのパスフレーズ: 第11.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します。
この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

7. 「信頼」セクションで、信頼キーストアのプロパティを定義します。

1. カスタム信頼キーストア: 信頼キーストアの完全修飾パスを入力します。

ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appTrustKeyStore.jks

2. カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

3. カスタム信頼キーストアのパスフレーズ: 第11.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワードNew_Password。
前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。

8. 「保存」をクリックします。

9. これらの変更を有効にするために、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。

10. 「ロックして編集」をクリックします。

11. 「構成」をクリックし、「SSL」をクリックします。

12. 「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第11.3.3項「Keytoolユーティリティを使用した信頼キーストアの作成」で作成したキーストアのパスワードを入力します。

13. 「保存」をクリックします。

14. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

15. 変更を適用したサーバーを再起動します。

16. この手順を、管理サーバーおよびすべての管理対象サーバー(WLS_WSMn、WLS_SOAn、WC_Spacesn、WC_Collaborationn、WC_UtilitiesnおよびWC_Portletn)に対して繰り返します。

17. ホスト名検証を有効化して、ノード・マネージャ、管理サーバーおよび管理対象サーバー間の通信が正しいことを検証します。

1. 各サーバーの管理コンソールで、「構成」、「SSL」、「詳細」、「ホスト名の検証」、「BEAホスト名の検証」を選択します。

2. 管理コンソールを使用してサーバーを再起動します。

12 エンタープライズ・デプロイメント用の外部WebCenter Portalサービスの構成

この章では、Fusion Middleware ControlまたはWLSTコマンドを使用して、WebCenter Portalアプリケーション用に外部サービスを構成する方法を説明します。多くの外部サービスでは、WebCenter Portalアプリケーションとバックエンド・サーバー間に接続を設定する必要があります。

この章の内容は次のとおりです。

- 第12.1項「ディスカッション・サーバーの接続の構成」

- 第12.2項「インスタント・メッセージおよびプレゼンス(IMP)サーバー接続の構成」

- 第12.3項「ワークリストおよびワークフロー用のBPELサーバー接続の構成」

- 第12.4項「ポートレット・プロデューサの登録」

- 第12.5項「ページレット・プロデューサの登録」

- 第12.6項「検索サービスの構成」

- 第12.7項「通知用のメール・サーバーの構成」

12.1 ディスカッション・サーバーの接続の構成

WebCenter Portalアプリケーションでディスカッションまたはお知らせサービスを提供するには、アプリケーションをディスカッション・サーバーに接続する必要があります。WebCenter Portalエンタープライズ・デプロイメントで接続を構成するには、次の値が必要です。

- サーバーURL: http://wcpinternal.mycompany.com/owc_discussions

- 管理ユーザー: ディスカッション・サーバーの管理ユーザー名

- 管理パスワード: ディスカッション・サーバーの管理パスワード

ディスカッション・サーバーには、次に従ってFusion Middleware ControlまたはWLSTコマンドを使用して接続できます。

- 第12.1.2項「WLSTを使用したディスカッション・サーバーの接続の作成」

- 第12.1.1項「Fusion Middleware Controlを使用したディスカッション・サーバーの接続の作成」

詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのお知らせおよびディスカッション・サービスの管理に関する説明を参照してください。

12.1.1 Fusion Middleware Controlを使用したディスカッション・サーバーの接続の作成

ディスカッション・サーバーにFusion Middleware Controlを使用してWebCenter Portalアプリケーションを接続するには、次の手順を実行します。

1. アプリケーションがデプロイされている管理対象サーバーが最低1つは起動され稼働していることを確認します。
たとえば、Spacesアプリケーションでは、WC_Spaces管理対象サーバーの1つです。

2. http://SOAHOST1:7001/emでEnterprise Manager Fusion Middleware Control Consoleにログオンします。

3. WebCenter Portalアプリケーションのホーム・ページに移動します。
たとえば、Spacesアプリケーションのホーム・ページに移動するには、「Farm_wcpedg_domain」→「WebCenter」→「Portal」→「Spaces」→「webcenter (WC_Spaces1)」を展開します。

4. WebCenter Portalのドロップダウン・メニューから、「設定」→「サービス構成」を選択します。

5. 「ディスカッションおよびお知らせ」をクリックし、「追加」をクリックします。

6. 「ディスカッションおよびお知らせ接続の追加」画面で、次のように設定します。

- 接続名: DFConnection

- アクティブな接続: 接続を有効にするチェック・ボックスを選択します

- サーバーURL: http://wcpinternal.mycompany.com/owc_discussions

- 管理者ユーザー名: 管理者権限を持つディスカッション・サーバー・ユーザーの名前

7. 「OK」をクリックして設定を保存します。

8. アプリケーションがデプロイされている管理対象サーバーを再起動します。
Spacesアプリケーションについては、Spaces_Cluster内の管理対象サーバーをすべて再起動します。

12.1.2 WLSTを使用したディスカッション・サーバーの接続の作成

WebLogic Scripting Toolを使用し、WebCenter Portalアプリケーションをディスカッション・サーバーに接続するには、次の手順を実行します。

1. WebLogic Scripting Toolを起動します。

WCPHOST1> MW_HOME/wc/common/bin/wlst.sh

2. WLSTで、管理者として接続します。
次に例を示します。

connect("weblogic","admin password","ADMINVHN:7001")

3. createDiscussionForumConnectionコマンドを使用し、ディスカッション・サーバーに接続します。
次に例を示します。

createDiscussionForumConnection(appName="webcenter",name="DFConnection",
url="http://wcpinternal.mycompany.com/owc_discussions",
adminUser="myDS_admin",default=1,server="WC_Spaces1")

ここで、webcenterは、WC_Spaces1にデプロイされたSpacesアプリケーションです。

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのcreateDiscussionForumConnectionに関する説明も参照してください。

4. アプリケーションがデプロイされている管理対象サーバーを再起動します。
Spacesアプリケーションについては、Spaces_Cluster内の管理対象サーバーをすべて再起動します。

12.2 インスタント・メッセージおよびプレゼンス(IMP)サーバー接続の構成

インスタント・メッセージングおよびプレゼンス・サーバーの構成方法の手順は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのインスタント・メッセージおよびプレゼンス・サーバーの登録に関する説明を参照してください。

12.3 ワークリストおよびワークフロー用のBPELサーバー接続の構成

Spacesメンバーシップ・ワークフローなどのワークリスト・サービスやワークフローでは、BPELサーバーへの接続が必要です。WebCenter Portalエンタープライズ・デプロイメントの接続を構成するには、次の値が必要です。

- SOAPサーバーURL: http://wcpinternal.mycompany.com

BPELサーバーには、次に従って、Fusion Middleware ControlまたはWLSTコマンドを使用して接続します。

- 第12.3.1項「開始前の準備」

- 第12.3.2項「Fusion Middleware Controlを使用したワークリストおよびワークフローの構成」

- 第12.3.3項「WLSTを使用したワークリストとワークフローの構成」

12.3.1 開始前の準備

ワークリストとワークフロー・アプリケーションをホストするBPELサーバーに、WebCenter Portalアプリケーションを接続する前に、次の手順を実行する必要があります。

1. ワークリスト・サービスの前提条件の手順を完了します。
詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』のワークリスト・サービスのバックエンド要件に関する説明を参照してください。

2. (Spacesアプリケーションのみ) Spacesワークフローの前提条件の手順を完了します。
詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』のWebCenter Portal: Spacesのバックエンド要件に関する説明を参照してください。

12.3.2 Fusion Middleware Controlを使用したワークリストおよびワークフローの構成

Fusion Middleware Controlを使用しWebCenter PortalアプリケーションをBPELサーバーに接続するには、次の手順を実行する必要があります。

1. アプリケーションがデプロイされている管理対象サーバーが最低1つは起動され稼働していることを確認します。
たとえば、Spacesアプリケーションでは、WC_Spaces管理対象サーバーの1つです。

2. http://SOAHOST1:7001/emでEnterprise Manager Fusion Middleware Control Consoleにログオンします。

3. WebCenter Portalアプリケーションのホーム・ページに移動します。
たとえば、Spacesアプリケーションのホーム・ページに移動するには、「Farm_wcpedg_domain」→「WebCenter」→「Portal」→「Spaces」→「webcenter (WC_Spaces1)」を展開します。

4. ワークリスト接続を構成するには、次の手順を実行します。

1. WebCenter Portalのドロップダウン・メニューから、「設定」→「サービス構成」を選択します。

2. 「ワークリスト」→「追加」をクリックします。

3. 「ワークリスト接続の追加」画面で、次のように設定します。
接続名: WorklistConnection

アクティブな接続: ワークリスト・サービスの接続を有効にするチェック・ボックスを選択します

BPEL SOAP URL: http://wcpinternal.mycompany.com

4. 「OK」をクリックして設定を保存します。

5. (Spacesアプリケーションのみ) SpacesワークフローをホストするBPELサーバーを指定するには、次の手順を実行します。

1. WebCenter Portalのドロップダウン・メニューから、「設定」→「アプリケーション構成」を選択します。

2. 「接続名」ドロップダウンで、ワークフローがデプロイされているBPELサーバー接続を選択します。
希望のBPELサーバーがリストにない場合、手順4に従って接続を設定します。

3. 「OK」をクリックして設定を保存します。

6. アプリケーションがデプロイされている管理対象サーバーを再起動します。
Spacesアプリケーションについては、Spaces_Cluster内の管理対象サーバーをすべて再起動します。

12.3.3 WLSTを使用したワークリストとワークフローの構成

WebCenter PortalアプリケーションをBPELサーバーに接続し、WLSTを使用してワークリスト・サービスおよびSpacesワークフロー用のBPELサーバーを指定するには、次の手順を実行します。

1. WebLogic Scripting Toolを起動します。

WCPHOST1> MW_HOME/wc/common/bin/wlst.sh

2. WLSTで、管理者として接続します。
次に例を示します。

connect("weblogic","admin password","ADMINVHN:7001")

3. 次のようにBPELサーバー接続を構成します。
次に例を示します。

createBPELConnection(appName="webcenter", name="WorklistConnection", url="http://wcpinternal.mycompany.com",server="WC_Spaces1")

ここで、webcenterは、WC_Spaces1にデプロイされたSpacesアプリケーションです。

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのcreateBPELConnectionに関する説明を参照してください。

4. 次のようにBPEL接続を使用するようワークリスト・サービスを構成します。
次に例を示します。

addWorklistConnection(appName="webcenter", name="WorklistConnection", verbose=1,server="WC_Spaces1")

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのaddWorklistConnectionに関する説明を参照してください。

5. (Spacesアプリケーションのみ)SpacesワークフローがデプロイされているBPELサーバーをポイントする接続を指定します。
次に例を示します。

setSpacesWorkflowConnectionName(appName="webcenter", name="WorklistConnection",server="WC_Spaces1")

getSpacesWorkflowConnectionName(appName="webcenter",server="WC_Spaces1")

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのsetSpacesWorklfowConnectionNameに関する説明を参照してください。

6. アプリケーションがデプロイされている管理対象サーバーを再起動します。
Spacesアプリケーションについては、Spaces_Cluster内の管理対象サーバーをすべて再起動します。

12.4 ポートレット・プロデューサの登録

WebCenter Portalアプリケーションに、すぐに使用できるいくつかのポートレット・プロデューサを登録できます。WebCenter Portalエンタープライズ・デプロイメントでは、必要なプロデューサのURLは次のとおりです。

- WSRPプロデューサのURL: http://wcpinternal.mycompany.com/wsrp-tools/portlets/wsrp2?WSDL

- WebClippingプロデューサのURL: http://wcpinternal.mycompany.com/portalTools/webClipping/providers

- OmniPortletプロデューサのURL: http://wcpinternal.mycompany.com/portalTools/omniPortlet/providers

ポートレット・プロデューサは、次に従ってFusion Middleware ControlまたはWLSTコマンドを使用して登録できます。

- 第12.4.1項「Fusion Middleware Controlを使用したすぐに使用できるポートレット・プロデューサの登録」

- 第12.4.2項「WLSTを使用したすぐに使用できるポートレット・プロデューサの登録」

12.4.1 Fusion Middleware Controlを使用したすぐに使用できるポートレット・プロデューサの登録

Fusion Middleware Controlを使用したポートレット・プロデューサの登録の詳細については、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのポートレット・プロデューサの管理に関する説明を参照してください。

12.4.2 WLSTを使用したすぐに使用できるポートレット・プロデューサの登録

WLSTを使用し、すぐに使用できるポートレット・プロデューサを登録するには、次の手順を実行します。

1. WebLogic Scripting Toolを起動します。

WCPHOST1> MW_HOME/wc/common/bin/wlst.sh

2. WLSTで、管理者として接続します。
次に例を示します。

connect("weblogic","admin password","ADMINVHN:7001",server="WC_Spaces1")

3. すぐに使用できる3つのWSRPおよびPDK-Javaプロデューサをすべて登録します。
次に例を示します。

registerOOTBProducers(producerHost='wcpinternal.mycompany.com',producerPort=80, appName='webcenter', server=WC_Spaces1')

ここで、webcenterは、WC_Spaces1にデプロイされたSpacesアプリケーションです。

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのregisterOOTBProducersに関する説明も参照してください。

12.5 ページレット・プロデューサの登録

WSRP、Oracle JPDKポートレット、OpenSocialガジェットをWebCenter Portalアプリケーションでページレットとして公開するには、ページレット・プロデューサを登録する必要があります。WebCenter Portalエンタープライズ・デプロイメントでは、必要なページレット・プロデューサのURLは次のとおりです。

http://wcpinternal.mycompany.com/pagelets

ページレット・プロデューサは、Fusion Middleware ControlまたはWLSTコマンドを使用して登録できます。手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドで次を参照してください。

- Fusion Middleware Controlを使用したWebCenter Portalアプリケーション用のページレット・プロデューサの登録に関する説明

- WLSTを使用したWebCenter Portalアプリケーション用のページレット・プロデューサの登録に関する説明

12.6 検索サービスの構成

Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのWebCenter PortalでのOracle SES検索の管理の手順を使用して、Oracle Secure Enterprise Search (Oracle SES)とクローラを構成できます。

次のことを確認します。

- Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのOracle SES: 構成に関する説明のとおり、Oracle Secure Enterprise SearchはOracle Internet Directoryに登録され、WebCenter PortalアプリケーションはOracle SESの信頼できるエンティティとして構成されています。

- Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのOracle SES接続に関する説明のとおり、WebCenter PortalアプリケーションとOracle Secure Enterprise Search間に接続があります。

すべての新しいURLが、次のように、両方のWEBHOST Oracle HTTP Server構成に追加されていることを確認します。

<Location /rsscrawl>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
</Location>

<Location /sesUserAuth>
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
</Location>

第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」も参照してください。

12.7 通知用のメール・サーバーの構成

WebCenter Portalアプリケーションの通知サービスの設定方法の詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドの通知の設定に関する説明を参照してください。

WebCenter Portalエンタープライズ・デプロイメントで、メールを使用して通知を送信するよう選択した場合、メール通知に設定されたすべての「送信者のメール・アドレス」(つまり「送信者」フィールド)をオーバーライドする、mail.user.emailAddressというプロパティをメール・サーバー接続に追加設定する必要があります。このプロパティを追加設定しない場合には、sender_mail_address@server1などのように、クラスタ内のサーバー名の1つが送信者のメール・アドレスに追加されます。

Fusion Middleware ControlまたはWLSTを使用すると、メール・サーバー接続用にプロパティを追加設定できます。詳細は、次を参照してください。

- Fusion Middleware Controlを使用したメール・サーバーの登録(表17-7)

- WLSTを使用したメール・サーバーの登録

たとえば、WLSTを使用し、次を行います。

setMailConnectionProperty(appName='webcenter', name='myMail_Server_Connection_Name', key='mail.user.emailAddress', value='myShared_User_Email_Address')

説明:

myMail_Server_Connection_Name: 通知サービスで使用するメール・サーバー接続の名前。

myShared_User_Email_Address: 共有メール・アドレス。これは、外部アプリケーションの共有資格証明に指定されたユーザーに関連付けられたメール・アドレスです。このメール・アドレスを使用してメール・サーバーにログインできることを確認します。

13 Oracle WebCenter Contentを追加するためのドメインの拡張

この章では、Oracle WebCenter ContentをWebCenter Portalエンタープライズ・デプロイメントで使用するために、ドメインを拡張および構成する手順について説明します。

この章の内容は次のとおりです。

- 第13.1項「Oracle WebCenter Contentを追加するためのドメイン拡張の概要」

- 第13.2項「Oracle WebCenter Contentを追加するためのドメインの拡張」

- 第13.3項「unpackユーティリティを使用したWCPHOST1およびWCPHOST2へのドメイン構成の伝播」

- 第13.4項「WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成」

- 第13.5項「WCPHOST1およびWCPHOST2でのノード・マネージャの起動」

- 第13.6項「管理サーバーの再起動」

- 第13.7項「WLS_WCC1管理対象サーバーの起動」

- 第13.8項「WebCenter ContentのためのGridLinkデータ・ソース構成およびONS構成の検証」

- 第13.9項「(WLS_WCC1管理対象サーバー上の)コンテンツ・サーバーの構成」

- 第13.10項「管理サーバーのcwalletファイルの更新」

- 第13.11項「WLS_WCC2管理対象サーバーの起動および構成」

- 第13.12項「Oracle WebCenter Contentのサービス再試行の構成」

- 第13.13項「WLS_WCC管理対象サーバー用のOracle HTTP Serverの構成」

- 第13.14項「Oracle HTTP Serverを介したアクセスの検証」

- 第13.15項「インストールのバックアップ」

- 第13.16項「Oracle WebCenter Portal用のOracle WebCenter Contentの構成」

- 第13.17項「Oracle WebCenter PortalのアプリケーションへのOracle WebCenter Contentの登録」

- 第13.18項「Inbound Refineryのインストールおよび構成」

注意:

セットアップのプロセスを開始する前に、Oracle Fusion Middlewareリリース・ノートを読み、インストールとデプロイメントに関する追加情報を確認してください。

13.1 Oracle WebCenter Contentを追加するためのドメイン拡張の概要

Oracle WebCenter Contentシステムは、第6章「エンタープライズ・デプロイメント用のソフトウェアのインストール」で作成された、共有記憶域でのWL_HOMEおよびORACLE_HOMEの場所を使用してインストールされます。WCPHOST1およびWCPHOST2では、MW_HOMEをマウントし、既存のOracle Weblogic Server、Oracle SOA Suite、Oracle WebCenter PortalおよびOracle WebCenter Contentバイナリ・インストールを使用します。

まだインストールしていない場合は、Oracle WebCenter Contentをドメインに追加する前にOracle WebCenter ContentバイナリをMiddlewareホームにインストールします。詳細は、第6.3.2.3項「Oracle WebCenter Contentのインストール」を参照してください。

Oracle WebCenter Contentを追加するためのドメインを拡張します。表13-1に、WebCenter Contentを構成する手順と、WebCenter Content管理対象サーバーを含むドメインを拡張するために必要なタスクを示します。

表13-1 WebCenter Contentを含むドメインの拡張手順

手順

説明

詳細

WebCenter Contentを使用するためのドメインの拡張

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogicドメインを拡張します。

第13.2項「Oracle WebCenter Contentを追加するためのドメインの拡張」

ドメイン構成の伝播

起動スクリプトとクラスパス構成を管理サーバーのドメイン・ディレクトリから管理対象サーバーのドメイン・ディレクトリに伝播します。

第13.3項「unpackユーティリティを使用したWCPHOST1およびWCPHOST2へのドメイン構成の伝播」

WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成

WebCenter Contentトラフィックをルーティングする方法を指定するルールを、ロード・バランサに構成します。

第13.4項「WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成」

WCPHOST1およびWCPHOST2でのノード・マネージャの起動

WCPHOST1およびWCPHOST2でノード・マネージャを起動します。

第13.5項「WCPHOST1およびWCPHOST2でのノード・マネージャの起動」

ドメインの管理サーバーの再起動

管理サーバーを停止し、再起動します。

第13.6項「管理サーバーの再起動」

1台目のWebCenter Content管理対象サーバーの起動およびコンテンツ・サーバーのインスタンスの構成

WLS_WCC1管理対象サーバーの起動およびコンテンツ・サーバーの初期構成の完了

第13.7項「WLS_WCC1管理対象サーバーの起動」

cwallet.ssoファイルの変更を元の管理サーバーに伝播

更新されたcwallet.ssoファイルを管理サーバー・ディレクトリにコピーします。

第13.10項「管理サーバーのcwalletファイルの更新」

2台目のWebCenter Content管理対象サーバーの起動およびコンテンツ・サーバーのインスタンスの構成

WLS_WCC2管理対象サーバーを構成し、コンテンツ・サーバーの初期構成を完了します。

第13.11項「WLS_WCC2管理対象サーバーの起動および構成」

Oracle RACフェイルオーバー後のサービス再試行の有効化

コンテンツ・サーバーのconfig.cfgファイルでServiceAllowRetry構成パラメータをtrueに設定します。

第13.12項「Oracle WebCenter Contentのサービス再試行の構成」

拡張したドメインでのOracle HTTP Serverの構成

管理対象サーバーとともにOracle HTTP Serverを構成し、フロントエンドHTTPのホストおよびポートの設定およびWCC_ClusterのWLSクラスタ・アドレスを設定します。

第13.13項「WLS_WCC管理対象サーバー用のOracle HTTP Serverの構成」

Oracle HTTP Serverを介したWebCenter Contentへのアクセスの検証

URLを検証し、Oracle HTTP ServerからWCC_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

第13.14項「Oracle HTTP Serverを介したアクセスの検証」

WebCenter Content構成のバックアップ

新しく拡張したドメイン構成をバックアップします。

第13.15項「インストールのバックアップ」

Oracle WebCenter Portalで使用するためのOracle WebCenter コンテンツ・サーバーの設定

SpacesなどのOracle WebCenter Portalアプリケーションで使用するためにOracle WebCenter コンテンツ・サーバーを設定します。

第13.16項「Oracle WebCenter Portal用のOracle WebCenter Contentの構成」

コンテンツ・サーバーのWebCenter Portalのアプリケーションへの登録

SpacesなどのWebCenter Portalアプリケーションをコンテンツ・サーバーに接続します。

第13.17項「Oracle WebCenter PortalのアプリケーションへのOracle WebCenter Contentの登録」

Inbound Refineryを使用するためのドメインの拡張

第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したWebLogicドメインを拡張します。

第13.18項「Inbound Refineryのインストールおよび構成」

13.2 Oracle WebCenter Contentを追加するためのドメインの拡張

Oracle WebCenter Contentを追加するには、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを拡張する必要があります。オプションで、Oracle WebCenter Contentのみを含む新しいドメインを作成することもできます。

注意:

これらの手順を実行する前に、Oracle Fusion Middleware管理者ガイドの説明に従ってドメインをバックアップしてください。

Oracle WebCenter Contentを追加するためにドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内の管理対象サーバーをすべてシャットダウンします。

3. ディレクトリをOracle Fusion Middleware構成ウィザードの場所に変更します。これは共通のOracleホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するSOAHOST1から実行することに注意してください)。

cd ORACLE_COMMON_HOME/common/bin

4. 構成ウィザードを起動します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. 「WebLogicドメイン・ディレクトリ」画面で、WebLogicドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name)を選択し、「次へ」をクリックします。

7. 図13-1に示すとおり、「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。

- Oracle Universal Content Management - Content Server - 11.1.1.0 wcc

「次へ」をクリックします。

注意:

Oracle Universal Content Management - Inbound Refinery - 11.1.1.0は選択しないでください。この機能は、第13.18.5項「Inbound Refineryの構成」の説明に従って、後で構成します。

図13-1 Oracle WebCenter Contentの「拡張ソースの選択」画面

「図13-1 Oracle WebCenter Contentの「拡張ソースの選択」画面」

8. 「JDBCコンポーネント・スキーマの構成」画面(図13-2)で次を実行します。

1. 「UCMスキーマ」を選択します。

2. RACの構成には、(付録A「Oracle RACでのマルチ・データ・ソースの使用」で説明した)「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択できます。
ここの手順では、「GridLinkへ変換」を選択します。

3. 「次へ」をクリックします。

図13-2 Oracle WebCenter Contentの「JDBCコンポーネント・スキーマの構成」画面

「図13-2 Oracle WebCenter Contentの「JDBCコンポーネント・スキーマの構成」画面」の説明

9. 「GridLink RACコンポーネント・スキーマの構成」画面で(図13-3)、次を実行します。

1. 「UCMスキーマ」を選択します。その他のSOAとWebCenter Portalデータ・ソースはそのままにします。

2. 次の各フィールドに値を入力して、RCUでシードされたOracle GridLink RACデータベースの接続情報を指定します。

- ドライバ: 「OracleのGridLinkConnectionsドライバ(Thin)、バージョン: 10以降」を選択します。

- サービス名: Oracle RACデータベースのサービス名と、続けてドメイン名を小文字で入力します。たとえば、wcpedg.mycompany.comです。

- ユーザー名: データベースのスキーマ所有者の完全な名前(接頭辞を含む)を入力します。

- パスワード: データベース・スキーマ所有者のパスワードを入力します。

- FANの有効化: このオプションを選択します。

- SSLの有効化: このオプションを選択解除します。
Oracle Notification Service (ONS)の通知の暗号化するためにSSLが選択されている場合は、「ウォレット・ファイル」と「ウォレット・パスワード」に適切な詳細を入力します。

- サービス・リスナー: 使用しているOracle RACデータベースのOracle Single Client Access Name (SCAN)のアドレスとポートを入力します。このプロトコルは、TCPである必要があります。
Oracle RACノードの追加または削除時にSCANアドレスを含むGridLinkデータ・ソースを更新する必要がないよう、サービス・リスナー(とOSNホスト)の指定にはSCANアドレスを使用することをお薦めします。SCANアドレスを判断するには、データベースに対してremote_listenerパラメータを問い合わせます。

SQL>show parameter remote_listener;

NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      db-scan.mycompany.com:1521

注意:

データベース・バージョンがSCANをサポートしない場合は次を実行します。

- Oracle Database 11gリリース1 (11.1)の場合、各データベースのインスタンス・リスナーの仮想IPとポートを次のように入力します。
custdbhost1-vip.mycompany.com (Port 1521)

および

custdbhost2-vip.mycompany.com (Port 1521)

- Oracle Database 10gの場合、マルチ・データ・ソースを使用し、Oracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: データベースからの通知のとおり、Oracle RACデータベースとONSリモート・ポートのSCANアドレスを入力します。

[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 (Port 6200)

図13-3 Oracle WebCenter Contentの「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

「図13-3 Oracle WebCenter Contentの「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

その他のすべてのSOAとWebCenter Portalスキーマはそのままにします。

10. 「次へ」をクリックします。

11. 「JDBCデータ・ソースのテスト」画面で、UCMスキーマを選択し(または「すべて選択」をクリックし)、「接続のテスト」をクリックします。
「接続結果ログ」に結果が表示されます。スキーマを含むデータベースに正常に接続できたことを確認します。できなかった場合は、「前」をクリックし、前の画面に戻り、入力を修正し、テストを再試行します。

すべての接続に成功したら「次へ」をクリックします。

12. 「オプションの構成」画面で、次の項目を選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

13. 「管理対象サーバーの構成」画面で、「追加」をクリックし、表13-2に示す必須の管理サーバーを追加します。画面に表示されている他のサーバーは変更せず、そのままにしておきます。

表13-2 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_WCC1

WCPHOST1

16200

該当なし

いいえ

WLS_WCC2

WCPHOST2

16200

該当なし

いいえ

「次へ」をクリックします。

14. 「クラスタの構成」画面で、「追加」をクリックし、表13-3に示すクラスタを追加します。画面に表示されている他のクラスタは変更せず、そのままにしておきます。

表13-3 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

WCC_Cluster

ユニキャスト

該当なし

該当なし

空白のままにします。

「次へ」をクリックします。

15. 「サーバーのクラスタへの割当」画面で、次の項目を追加します。この画面に表示されている他の割当ては、このまま変更しません。

- WCC_Cluster

- WLS_WCC1

- WLS_WCC2

「次へ」をクリックします。

16. 「マシンの構成」画面で「Unixマシン」タブをクリックし、次の2つのマシンを新規追加します。

表13-4 マシン

名前

ノード・マネージャのリスニング・アドレス

WCPHOST1

WCPHOST1

WCPHOST2

WCPHOST2

その他すべてのフィールドはデフォルト値のままにします。「次へ」をクリックします。

17. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- WLS_WCC1をWCPHOST1に割り当てます。

- WLS_WCC2をWCPHOST2に割り当てます。
「次へ」をクリックします。

18. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

19. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

20. 「構成のサマリー」画面で、「拡張」をクリックします。

21. ドメインのポートの競合に関する警告ダイアログで「OK」をクリックします。

22. 「ドメインの作成中」画面で、「完了」をクリックします。

23. 管理サーバーを起動し、これらの変更を反映します。第13.6項「管理サーバーの再起動」を参照してください。

13.3 unpackユーティリティを使用したWCPHOST1およびWCPHOST2へのドメイン構成の伝播

ドメイン構成を伝播する手順は次のとおりです。

1. 次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true -domain=ORACLE_BASE/admin/
domain_name/aserver/domain_name -template=edgdomaintemplateWCC.jar -template_name=edgdomaintemplateWCC

2. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・パックをWCPHOST1とWCPHOST2にコピーします。

注意:

WCPHOST1がORACLE_HOMEをWCPHOST2と共有していると仮定した場合、テンプレートは、WCPHOST2の同一のディレクトリに存在します(そうでなければ、これもWCPHOST2にコピーします)。

scp edgdomaintemplateWCC.jar oracle@WCPHOST1:ORACLE_BASE/product/fmw/oracle_common/common/bin

scp edgdomaintemplateWCC.jar oracle@WCPHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin

3. unpackコマンドをWCPHOST1とWCPHOST2で実行し、伝播されたテンプレートを解凍します。

注意:

unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

WCPHOST1> cd ORACLE_COMMON_HOME/common/bin
WCPHOST1> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name -template=edgdomaintemplateWCC.jar -app_dir=ORACLE_BASE
/admin/domain_name/mserver/applications

WCPHOST2> cd ORACLE_COMMON_HOME/common/bin
WCPHOST2> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name -template=edgdomaintemplateWCC.jar -app_dir=ORACLE_BASE
/admin/domain_name/mserver/applications

注意:

unpackを実行する前に、ORACLE_BASE/admin/domain_name/mserverディレクトリが存在している必要があります。また、ORACLE_BASE/admin/domain_name/mserver/applicationsが空である必要があります。

13.4 WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成

このWebCenter Portalエンタープライズ・デプロイメントでは、ロード・バランサが両方のコンテンツ・サーバー間のトラフィックの負荷を分散します。ロード・バランサは、WebCenter Portalアプリケーションから(WCPHOST1上またはWCPHOST2上の)コンテンツ・サーバーのいずれかに、ソケット接続を転送します。接続は永続的であるため、1台のコンテンツ・サーバーが、トラフィックのすべてではなくてもほとんどを受信します。プライマリ・サーバーが使用できなくなった場合に、もう1台のコンテンツ・サーバーが、フェイルオーバー・サーバーとして機能します。

WebCenter Contentトラフィックをルーティングする方法を指定するルールによって、ロード・バランサを構成する必要があります。次に例を示します。

- (LBR)10.110.10.135:4444 -> 10.110.10.23:4444 (WCPHOST1) -> 10.110.10.24:4444 (WCPHOST2)

13.5 WCPHOST1およびWCPHOST2でのノード・マネージャの起動

ノード・マネージャが起動されていない場合、次の手順を実行し、WCPHOST1とWCPHOST2上のノード・マネージャを起動します。

1. ノード・マネージャを起動する前に、WCPHOST1およびWCPHOST2の両方で、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティを'true'に設定します。

WCPHOSTn> cd ORACLE_COMMON_HOME/common/bin
WCPHOSTn> ./setNMProps.sh

注意:

クラスのロード失敗などの問題を回避するために、StartScriptEnabledプロパティを使用する必要があります。

注意:

第3章「エンタープライズ・デプロイメント用のネットワークの準備」の共有記憶域構成で示しているように、Oracle WebCenterコンテンツ・サーバーがローカル記憶域または共有記憶域でSOAおよびWebCenter PortalとMW_HOMEを共有している場合には、setNMProps.shを再度実行する必要はありません。この場合、ノード・マネージャはすでに起動スクリプトを使用するように構成されています。

2. WCPHOST1およびWCPHOST2の両方で次のコマンドを実行し、ノード・マネージャを起動します。

WCPHOSTn> cd WL_HOME/server/bin
WCPHOSTn> ./startNodeManager.sh

13.6 管理サーバーの再起動

加えた変更を有効にするために管理サーバーを再起動します。管理サーバーを再起動するには、最初に管理コンソールを使用してサーバーを停止し、次に第8章「SOAHOST1での管理サーバーの起動」の説明に従って再起動します。

13.7 WLS_WCC1管理対象サーバーの起動

この項では、新しいWLS_WCC1管理対象サーバーを起動する方法について説明します。

WLS_WCC1管理対象サーバーを起動する手順は次のとおりです。

1. 次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_WCC1管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

4. 「WLS_WSM1」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.8項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

13.8 WebCenter ContentのためのGridLinkデータ・ソース構成およびONS構成の検証

コンテンツ・サーバーの構成やWLS_WCC1の伝播を行う前に、前に作成したGridLinkデータ・ソースの構成とOracle Notification Service (ONS)の設定がデータ・ソースに対して正しいことを検証する必要があります。

WebCenter Content用のGridLinkデータ・ソースの構成とONSの構成を検証するには、次の手順を実行します。

1. WebLogicサーバーの管理コンソールにログインします。

2. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

3. 作成されたGridLinkデータ・ソース名をクリックします。

4. 「テスト」タブをクリックし、「WLS_WCC1」を選択して「データ・ソースのテスト」をクリックします。
構成が正しい場合、テストは成功します。

5. 「監視」タブをクリックし、「WLS_WCC1」をクリックします。

6. 「ONS」→「テスト」タブをクリックします。

7. サーバーを選択し、「ONSのテスト」をクリックします。
構成が正しい場合、ONSのテストは成功します。ONSのテストが失敗する場合、Oracle RACデータベース・ノードでONSサービスが実行されていることを確認します。

[orcl@db-scan1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node db-scan1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node db-scan2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node db-scan3

[orcl@db-scan1 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

[orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: db-scan1
ONS daemon is running on node: db-scan2

GridLinkデータ・ソースを使用するすべてのWebLogic Serverインスタンスで、ONSテストを繰り返します。

13.9 (WLS_WCC1管理対象サーバー上の)コンテンツ・サーバーの構成

この項では、WebCenter Portalエンタープライズ・デプロイメントに、コンテンツ・サーバー(WLS_WCC1上)を構成する方法を説明します。

注意:

このWebCenter Portalエンタープライズ・デプロイメントでは、ロード・バランサが両方のコンテンツ・サーバー間のトラフィックの負荷を分散します。まだ実行していない場合は、WebCenter Contentのトラフィックのルーティング方法を指定するルールをロード・バランサに構成する必要があります。詳細は、第13.4項「WebCenter Contentトラフィックをルーティングするためのロード・バランサの構成」を参照してください。

コンテンツ・サーバーを構成するには、次の手順を実行します。

1. Oracle WebLogicの管理ユーザー名とパスワードを使用し、http://wcpinternal.mycompany.com/csのコンテンツ・サーバーにログインし、構成ページを表示します。

注意:

Oracle WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Portalのエンタープライズ・デプロイメントでは、共有ディスクの場所はORACLE_BASE/admin/wc_domain/WCC_Clusterです。

2. サーバー構成ページで次の値を変更します(すべてのオプションを参照するには、「コンテンツ・サーバーの新規インスタンス」チェック・ボックスを選択してください)。

- コンテンツ・サーバーのインスタンス・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/csに設定します。

- ネイティブ・ファイル・リポジトリの場所: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/cs/vaultに設定します。

- Webレイアウト・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/cs/weblayoutに設定します。

- ユーザー・プロファイル・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/cs/data/users/profilesに設定します。

- サーバーのソケット・ポート: これを4444に設定します。

- ソケット接続アドレス・セキュリティ・フィルタを着信中: これを次に示すとおりローカル・ホストおよびサーバーのIPのパイプ区切り一覧に設定します。
127.0.0.1|WCPHOST1_IP_Address|WCPHOST2_IP_Address|WEBHOST1_IP_Address|WEBHOST2_IP_Address

注意:

この手順では、ホスト名ではなくIPアドレスを使用します。

- WebサーバーのHTTP/HTTPSアドレス: これをwcpinternal.mycompany.comに設定します。
/csへのリクエストで利用可能なすべてのコンテンツ・サーバー・ノードを使用できるように、ここにロード・バランサのアドレスを入力します。

注意:

まだ実行していない場合、WebCenter Contentトラフィックをルーティングする方法のルールを、次のようにロード・バランサに追加します。

- (LBR)10.110.10.135:4444 -> 10.110.10.23:4444 (WCPHOST1) -> 10.110.10.24:4444 (WCPHOST2)

- HTTPSのWebアドレス: このチェック・ボックスを選択解除します。

- コンテンツ・サーバーのインスタンス・ラベル: これをWCC_Cluster1に設定します。

- サーバー・インスタンスの説明: これをCluster WCC_Cluster1に設定します。

- 自動採番接頭辞: これをWCC_Cluster1-に設定します。

3. 完了したら「送信」をクリックし、Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを再起動します。

13.10 管理サーバーのcwalletファイルの更新

Oracle WebCenterコンテンツ・サーバーは、起動時にORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfigにあるcwallet.ssoファイルを更新します。この変更を管理サーバーに伝播して戻す必要があります。これを行うには、次のコマンド(全部で1行)を使用して、ファイルをSOAHOST1のORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfigにコピーします。

WCPHOST1> scp ORACLE_BASE/admin/domain_name/mserver/
domain_name/config/fmwconfig/cwallet.sso oracle@SOAHOST1:ORACLE_BASE
/admin/domain_name/aserver/domain_name/config/fmwconfig/

注意:

WLS_WCCnサーバーでORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfigディレクトリにあるcwallet.ssoファイルを変更する操作を行った場合は、SOAHOST1の管理サーバー・ドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig)にそのファイルをすぐにコピーする必要があります。

13.11 WLS_WCC2管理対象サーバーの起動および構成

管理対象サーバーWLS_WCC2の起動

次の手順に従い、Oracle WebLogic Server管理コンソールを使用してWLS_WCC2管理対象サーバーを起動します。

1. Oracle WebLogic Server管理コンソールを使用して次の操作を実行します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「サマリー」ページまたは「サーバー」ページで、「制御」タブをクリックします。

4. 「WLS_WCC2」を選択して、「起動」をクリックします。

2. 管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。考えられる原因については、第16.8項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」を参照してください。

WLS_WCC2管理対象サーバーの構成

WLS_WCC2管理対象サーバーを構成するには、次の手順を実行します。

1. http://WCPHOST2:16200/csでOracle WebLogicの管理ユーザー名とパスワードを使用してWLS_WCC2にログインし、構成ページを表示します。

注意:

WebCenter Content構成ファイルは、クラスタのすべてのメンバーがアクセスできるように共有ディスクにあります。Oracle WebCenter Portalのエンタープライズ・デプロイメントでは、共有ディスクの場所はORACLE_BASE/admin/wc_domain/WCC_Clusterです。

2. 「サーバーの構成」ページで次の値を変更します。

- コンテンツ・サーバーのインスタンス・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/csに設定します。

- ネイティブ・ファイル・リポジトリの場所: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/cs/vaultに設定します。

- Webレイアウト・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/cs/weblayoutに設定します。

- ユーザー・プロファイル・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/cs/data/users/profilesに設定します。

3. 「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。

4. 完了したら「送信」をクリックし、Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを再起動します。

13.12 Oracle WebCenter Contentのサービス再試行の構成

Oracle RACのフェイルオーバー時にログインの再試行を可能にするため、Oracle Content Serverのconfig.cfgファイル内の次のパラメータを設定します。

ServiceAllowRetry=true

この値が設定されていない場合、フェイルオーバーが開始されたときに、処理中の任意の操作を手動で再試行する必要があります。

Oracle WebCenter Content用のServiceAllowRetry構成パラメータを追加する手順は次のとおりです。

1. Oracle WebCenter ContentのWebLogic Server管理コンソール(http://WCPHOST1:16200/cs)にアクセスし、Oracle WebLogicの管理ユーザー名とパスワードを使用してログインします。

2. 「管理」ページを開き、「管理サーバー」を選択します。

3. 「コンテンツ管理サーバー」ページで、左側の「一般構成」をクリックします。

4. 「一般構成」ページで、「追加の構成変数」ボックスに、次のパラメータを追加します。

ServiceAllowRetry=true

5. 「保存」をクリックし、すべてのWebCenter Content管理対象サーバー(WLS_WCCn)を再起動します。

注意:

新しいパラメータはconfig.cfgファイルに含まれます。このファイルは次の場所にあります。

ORACLE_BASE/admin/wc_domain/WCC_Cluster/cs/config/config.cfg

このファイルをテキスト・エディタで直接編集することもできます。WebCenter Content管理対象サーバーもすべて忘れずに起動します。

13.13 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ファイルに次の行を追加します。
#Oracle WebCenter Content

<Location /cs>
WebLogicCluster WCPHOST1:16200,WCPHOST2:16200
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /adfAuthentication>
WebLogicCluster WCPHOST1:16200,WCPHOST2:16200
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /_ocsh>
WebLogicCluster WCPHOST1:16200,WCPHOST2:16200
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

2. WEBHOST1およびWEBHOST2の両方で、Oracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

13.14 Oracle HTTP Serverを介したアクセスの検証

次のURLを検証し、Oracle HTTP ServerからWCC_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

1. WLS_WCC2が稼動している状態で、Oracle WebLogic Server管理コンソールを使用してWLS_WCC1を停止します。

2. http://WEBHOST1:7777/csにアクセスし、正しく動作していることを確認します。

3. Oracle WebLogic Server管理コンソールでWLS_WCC1を起動します。

4. Oracle WebLogic Server管理コンソールでWLS_WCC2を停止します。

5. http://WEBHOST1:7777/csにアクセスし、正しく動作していることを確認します。

13.15 インストールのバックアップ

拡張したドメインが正常に動作していることを確認した後、そのインストール内容をバックアップします。これは、以降の手順で問題が発生した場合に短時間でリストアできることを考慮した迅速なバックアップです。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメントの設定が完了すれば、このバックアップは破棄してかまいません。その時点では、デプロイメント固有の定期的なバックアップ手順とリカバリ手順を実行できるようになっています。詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。バックアップおよびリストアを必要とするOracle HTTP Serverのデータの詳細は、そのガイドでOracle HTTP Serverのバックアップとリカバリの推奨事項に関する項を参照してください。コンポーネントのリカバリ方法に関する詳細は、そのガイドでコンポーネントのリカバリに関する項およびコンポーネントが失われた後のリカバリに関する項を参照してください。ホストが失われた場合のリカバリに固有の推奨事項は、そのガイドで別のホストへのOracle HTTP Serverのリカバリに関する項を参照してください。データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』も参照してください。

インストールをバックアップするには、次の手順を実行します。

1. Web層をバックアップします。SOAHOST1からコマンドを実行します。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドを実行して、Web層のOracleインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

cd ORACLE_BASE/admin/instance_name/bin
opmnctl startall

2. データベースのバックアップを取ります。これは、Oracle Recovery Manager(推奨)またはtarなどのオペレーティング・システム・ツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。オペレーティング・システム・ツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは、すべてORACLE_BASE/admin/ domain_nameディレクトリの下にあります。
次のコマンドを実行してバックアップを作成します。

SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

13.16 Oracle WebCenter Portal用のOracle WebCenter Contentの構成

この項では、Oracle WebCenter Portalで使用するOracle WebCenter コンテンツ・サーバーを構成するための必須タスクについて説明します。この項の項目は次のとおりです。

- 第13.16.1項「必須のコンテンツ・サーバー・コンポーネント(Folders_gおよびWebCenterConfigure)の有効化」

- 第13.16.2項「Dynamic Converterコンポーネントの有効化および構成」

- 第13.16.3項「その他のコンテンツ・サーバー機能の追加構成」

13.16.1 必須のコンテンツ・サーバー・コンポーネント(Folders_gおよびWebCenterConfigure)の有効化

必須

WebCenter Portalで、次のコンテンツ・サーバー・コンポーネントを有効にします。

- Folders_g: コンテンツ・サーバー内のコンテンツに対して階層フォルダ・インタフェースを提供します。

- WebCenterConfigure: WebCenter Portalアプリケーション用のコンテンツ・サーバーのインスタンスが構成されます。

WebCenter Portalでは、次のコンテンツ・サーバー・コンポーネントを無効にします。

- FrameworkFolders: このコンポーネントはFolders_gとは互換性がありません。

詳細な手順は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドの必須コンポーネントの有効化に関する説明を参照してください。

注意:

Folder_gが無効の場合、次の例外が表示されます。

SEVERE: UCM feature folders is not installed on server. at
oracle.webcenter.content.integration.spi.ucm.UCMBridge.getBridge(UCMBridge.java:349) ....

必須コンポーネントを有効にするには、次の手順を実行します。

1. 「Oracle WebCenterコンテンツ管理」にログインします。

2. 「管理」→「管理サーバー」→「コンポーネント・マネージャ」に移動し、有効、無効にします。

3. 「FrameworkFolders」を無効にします。

4. 「Folders_g」と「WebCenterConfigure」を有効にします。

5. 下の保存/更新をクリックします。

6. コンテンツ・サーバーを再起動します。オプションで、すべての構成手順が完了したらコンテンツ・サーバーを再起動するようにもできます。

13.16.2 Dynamic Converterコンポーネントの有効化および構成

オプションであるが強く推奨

この構成は、Dynamic Converterによってオンザフライで生成される、HTMLレンディションが利用される、WebCenter PortalのSlide Previewer機能で必要です。

Dynamic Converterは、Dynamic Converterを有効にし、Dynamic Converterを使用するファイルの種類を定義する2つ手順で構成します。詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのDynamic Converterコンポーネントの構成に関する説明を参照してください。

13.16.3 その他のコンテンツ・サーバー機能の追加構成

他にもいくつか、WebCenter Portalアプリケーションに機能を追加する必須ではないコンテンツ・サーバー機能があります。たとえば、Site Studio、OracleTextSearchなどの機能を有効にすることも可能です。詳細および手順は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのコンテンツ・サーバーの構成のロードマップに関する説明を参照してください。

13.17 Oracle WebCenter PortalのアプリケーションへのOracle WebCenter Contentの登録

Oracle WebCenterコンテンツ・サーバーをSpacesなどのWebCenter Portalアプリケーションに追加するには、次の手順を実行します。

注意:

コンテンツ・サーバーの登録の詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのコンテンツ・リポジトリの登録に関する説明を参照してください。

1. Enterprise Manager Fusion Middleware Controlにログインし、アプリケーションのホーム・ページに移動します。
たとえば、Spacesのホーム・ページに移動するには、「WebCenter」→「Portal」→「Spaces」を展開します。

2. 「WebCenter Portal」メニューから、「設定」→「サービス構成」を選択します。

3. 「WebCenterサービス構成」ページのサービスのリストから、「コンテンツ・リポジトリ」を選択します。

4. 新しいコンテンツ・リポジトリに接続するには、「追加」をクリックします。

5. この接続の一意の名前を入力し、コンテンツ・リポジトリ・タイプを指定します。また、この接続がアプリケーションのアクティブな(デフォルトの)接続であるかどうかを指定します。

- 接続名
コンテンツ・リポジトリ接続に一意の名前を入力します。この名前は、WebCenter Portalアプリケーション内のすべての接続タイプ間で一意である必要があります。

- リポジトリ・タイプ
接続先のリポジトリのタイプとして「Oracle Content Server」を選択します。

- アクティブな接続
これをWebCenter Portalアプリケーションのデフォルトのコンテンツ・リポジトリにします。

WebCenter Portalアプリケーションを複数のコンテンツ・リポジトリに接続して、すべての接続を使用することができます。1つの接続をデフォルト(またはアクティブな)接続に指定する必要があります。

6. Spacesアプリケーションの場合のみ、次のコンテンツ・リポジトリの詳細を追加入力します。

- コンテンツ管理者
このコンテンツ・サーバー・インスタンスに対する管理者権限を持つユーザー名を入力します。このユーザーは、Spacesコンテンツのフォルダの作成と維持や、コンテンツ・アクセス権限の管理に使用されます。デフォルトはsysadminです。スペース・ユーザーにかわって操作を実行するには、この接続に対する管理権限が必要です。

- ルート・フォルダ
すべてのSpacesコンテンツが保存されているルート・フォルダを入力します。まだ存在しないコンテンツ・リポジトリ・フォルダを指定するには、/foldernameの形式を使用します。たとえば、/MyWebCenterSpacesです。ルート・フォルダは、ルート自体である/にはできず、アプリケーション全体で一意である必要があります。指定したフォルダはアプリケーションの起動時に作成されます。

- アプリケーション名
コンテンツ・リポジトリ内のこのSpacesアプリケーションに一意の名前を入力します。たとえば、MySpacesAppです。

名前は、先頭がアルファベットで、その後はアルファベットまたはアンダースコアの任意の組合せである必要があります。文字列は、30文字以下である必要があります。

この名前は、複数のスペース・アプリケーションが同じコンテンツ・リポジトリを共有している場合にデータを区別するために使用され、アプリケーション間で一意であることが必要です。

7. コンテンツ・リポジトリの接続の詳細を入力します。

- RIDCソケット・タイプ
「ソケット」を選択すると、コンテンツ・サーバーとの接続に、intradocソケットが使用されます。コンテンツ・サーバーの認証アドレスのリストにクライアントIPアドレスを追加する必要があります。この場合、クライアントは、Oracle WebCenter Portalが実行されているマシンです。

- サーバー・ホスト
/csへのリクエストで利用可能なすべてのコンテンツ・サーバー・ノードを使用できるように、ここにはwcpinternal.mycompany.comのロード・バランサのアドレスを入力します。

注意:

まだ実行していない場合、WebCenter Contentトラフィックをルーティングする方法のルールを、次のようにロード・バランサに追加します。

- (LBR)10.110.10.135:4444 -> 10.110.10.23:4444 (WCPHOST1) -> 10.110.10.24:4444 (WCPHOST2)

- サーバー・ポート
コンテンツ・サーバーがリスニングするポート4444を入力します。

- 接続タイムアウト(ミリ秒)
接続タイムアウト・メッセージを発行するまで、コンテンツ・サーバーへのログインを許可する時間の長さ(ミリ秒)を指定します。タイムアウトが設定されていない場合、ログイン操作の時間制限はありません。環境に応じた適切なタイムアウトを選択します。たとえば、30000です。

- 認証方式
「アイデンティティ伝播」を選択します。このエンタープライズ・デプロイメントでは、コンテンツ・サーバーとWebCenter Portalアプリケーションは、ユーザーの認証に同じアイデンティティ・ストアを使用します。

- Webコンテキスト・ルート
コンテンツ・サーバーのWebサーバー・コンテキスト・ルートとして/csを入力します。

8. 「OK」をクリックしてこの接続を保存します。

9. 新しい(アクティブな)接続の使用を開始するには、WebCenter Portalアプリケーションがデプロイされている管理対象サーバーを再起動する必要があります。

13.18 Inbound Refineryのインストールと構成

Inbound Refinery (IBR)は、Oracle WebCenter Contentがドキュメント変換を行う際に必要になります。

可用性の観点から、少なくとも2つのInbound Refineryをそれぞれ別のマシンにインストールすることをお薦めします。WebCenter Portalエンタープライズ・デプロイメント・トポロジでは、Inbound RefineryはOracle Webcenterコンテンツ・サーバーと同じマシンにインストールされます。

Inbound Refineryを含むドメインの拡張プロセスでクラスタを作成しても、Inbound Refineryインスタンスがすべて完全に独立していることに注意してください。クラスタリングは、管理のみの目的で使用されます。

この項の内容は次のとおりです。

- 第13.18.1項「Inbound Refineryを追加するためのドメインの拡張」

- 第13.18.2項「unpackユーティリティを使用したWCPHOST1およびWCPHOST2へのドメイン構成の伝播」

- 第13.18.3項「管理サーバーの再起動」

- 第13.18.4項「Inbound Refinery管理対象サーバーの起動」

- 第13.18.5項「Inbound Refineryの構成」

13.18.1 Inbound Refineryを追加するためのドメインの拡張

Oracle WebCenter Content: Inbound Refineryを追加するには、第8章「エンタープライズ・デプロイメント用のドメインの作成」で作成したドメインを拡張する必要があります。

注意:

これらの手順を実行する前に、Oracle Fusion Middleware管理者ガイドの説明に従ってドメインをバックアップしてください。

Oracle WebCenter Content: Inbound Refineryを追加するためにドメインを拡張する手順は次のとおりです。

1. リポジトリをインストールしたデータベースを実行していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておくことをお薦めします。

2. ドメイン内の管理対象サーバーをすべてシャットダウンします。

3. ディレクトリをOracle Fusion Middleware構成ウィザードの場所に変更します。これは共通のOracleホーム・ディレクトリ内にあります(ドメインの拡張は、管理サーバーが存在するSOAHOST1から実行することに注意してください)。

cd ORACLE_COMMON_HOME/common/bin

4. 構成ウィザードを起動します。

./config.sh

5. 「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。

6. WebLogicドメイン・ディレクトリ画面で、WebLogicドメイン・ディレクトリ(ORACLE_BASE/admin/domain_name/aserver/domain_name)を選択し、「次へ」をクリックします。

7. 「拡張ソースの選択」画面で、次の手順を実行します。

- 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択します。

- 次の製品を選択します。

- Oracle Universal Content Management - Inbound Refinery - 11.1.1.0 [wcc]

「次へ」をクリックします。

8. 「JDBCコンポーネント・スキーマの構成」画面で必要な手順はありません。Inbound Refineryでは、データベースにスキーマがありません。「次へ」をクリックして続行します。

9. 「オプションの構成」画面で、次の項目を選択します。

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

「次へ」をクリックします。

10. 「管理対象サーバーの構成」画面で、必要な管理対象サーバーを追加します。
サーバーが自動的に作成されます。このサーバーの名前をWLS_IBR1に変更し、WLS_IBR2という新しいサーバーを追加します。表13-5に示す属性をこれらのサーバーに指定します。この画面に表示されている他のサーバーは変更せず、そのままにしておきます。

表13-5 管理対象サーバー

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_IBR1

WCPHOST1

16250

該当なし

いいえ

WLS_IBR2

WCPHOST2

16250

該当なし

いいえ

「次へ」をクリックします。

11. 「クラスタの構成」画面で、「追加」をクリックし、表13-6に示すクラスタを追加します。画面に表示されている他のクラスタは変更せず、そのままにしておきます。

表13-6 クラスタ

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

IBR_Cluster

ユニキャスト

該当なし

該当なし

空のままにします。

「次へ」をクリックします。

注意:

すべてのInbound Refineryインスタンスは完全に独立しています。このクラスタは、管理のみの目的で使用されます。

12. 「マシンの構成」画面で、「次へ」をクリックします。

13. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- WLS_IBR1をWCPHOST1に割り当てます。

- WLS_IBR2をWCPHOST2に割り当てます。

「次へ」をクリックします。

14. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- usermessagingserverおよびusermessagingdriver-emailは、SOA_Clusterにのみターゲット設定する必要があります(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。

- WSM-PMはSOA_Clusterにのみターゲット設定する必要があります。

- oracle.rules*、oracle.sdp.*、oracle.soa.workflow.wcおよびoracle.soa.*のデプロイメントは、SOA_Clusterのみをターゲットとする必要があります。

「次へ」をクリックします。

15. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

16. 「構成のサマリー」画面で、「拡張」をクリックします。

17. 「ドメインの作成中」画面で、「完了」をクリックします。

18. 管理サーバーを起動し、これらの変更を反映します。第8.4.3項「SOAHOST1での管理サーバーの起動」を参照してください。

13.18.2 unpackユーティリティを使用したWCPHOST1およびWCPHOST2へのドメイン構成の伝播

ドメイン構成を伝播する手順は次のとおりです。

1. 次の一連のコマンドを使用し、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=edgdomaintemplateIBR.jar -template_name=edgdomain_templateIBR

2. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・パックをWCPHOST2にコピーします。

注意:

WCPHOST1がORACLE_HOMEをSOAHOST1と共有していると仮定した場合、テンプレートは、WCPHOST1の同一のディレクトリに存在します(そうでなければ、これもWCPHOST1にコピーします)。

scp edgdomaintemplateIBR.jar oracle@WCPHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin

3. unpackコマンドをWCPHOST1で実行し、伝播されたテンプレートを解凍します。

注意:

unpackコマンドはWL_HOME/common/binから実行するのではなく、ORACLE_COMMON_HOME/common/binディレクトリから実行してください。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
-template=edgdomaintemplateIBR.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
-overwrite_domain=true

注意:

unpackを実行する前に、ORACLE_BASE/admin/domain_name/mserverディレクトリが存在している必要があります。また、ORACLE_BASE/admin/domain_name/mserver/applicationsが空である必要があります。

4. WCPHOST2に対して3の手順を繰り返します。

13.18.3 管理サーバーの再起動

管理サーバーを再起動して、ここまでの変更を有効にします。管理サーバーを再起動するには、最初に管理コンソールを使用してサーバーを停止し、第8.4.3項「SOAHOST1での管理サーバーの起動」の説明に従って再起動します。

13.18.4 Inbound Refinery管理対象サーバーの起動

WCPHOST1上のWLS_IBR1とWCPHOST2上のWLS_IBR2管理対象サーバーを起動するには、次の手順を実行します。

1. http://ADMINVHN:7001/consoleのOracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、「制御」タブを開きます。

4. 表の「サーバー」列から「WLS_IBR1」と「WLS_IBR2」を選択します。

5. 「起動」をクリックします。

13.18.5 Inbound Refineryの構成

Inbound RefineryにはHTTPを介して1回のみアクセスして、その構成を初期化する必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound Refineryは、HTTPサーバーの背面に配置することはできません。

以降のInbound Refineryに対するすべてのアクセスは、ソケット・リスナーを介して行われます。このリスナーは、次の項で構成する着信ソケット接続アドレス・セキュリティ・フィルタによって保護されます。

それぞれのOracle WebCenterコンテンツ・サーバーをすべてのInbound Refineryと連携するように構成することをお薦めします。Oracle WebCenter Contentの構成プロセスは、Inbound Refineryをプロバイダとして追加することです。Inbound Refineryのインストール後に実行する必要のあるタスクもあります。

次の項では、Inbound Refineryのインストール後の構成手順について説明します。

- 第13.18.5.1項「Inbound Refineryの設定の構成」

- 第13.18.5.2項「ドキュメント変換の構成」

- 第13.18.5.3項「Inbound RefineryのOracle WebCenter Contentへの構成」

13.18.5.1 Inbound Refineryの設定の構成

Inbound Refineryの設定を構成する手順は次のとおりです。

1. 次のURLからInbound Refineryのインストール後の構成画面にアクセスします。

http://WCPHOST1:16250/ibr/

2. 構成画面で、構成を次のとおり設定します。

- Inbound Refineryのインスタンス・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/ibr1に設定します。ディレクトリ・パスは共有ディスクに配置し、Inbound Refineryインスタンスごとに一意である必要があります。

- ネイティブ・ファイル・リポジトリの場所: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/ibr1/vaultに設定します。

- Webレイアウト・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/ibr1/weblayoutに設定します。

- ユーザー・プロファイル・フォルダ: これをORACLE_BASE/admin/wc_domain/WCC_Cluster/ibr1/data/users/profilesに設定します。

- ソケット接続アドレス・セキュリティ・フィルタ: これを、次に示すとおりローカル・ホストおよびサーバーのIPのパイプ区切り一覧に設定します。

127.0.0.1|WCPHOST1-IP|WCPHOST2-IP|WEBHOST1-IP|WEBHOST2-IP

これにより、Oracle WebCenter Content Serverから接続できるようになります。WCPHOST1-IPおよびWCPHOST2-IPの値は、Inbound Refineryにジョブを送信するOracle WebCenterコンテンツ・サーバーのインスタンスが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の構成時に必要となるため、書き留めておいてください。

構成ページの他のすべてのフィールドはそのままにします。

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管理者ガイド』のフォント・パスの指定に関する項を参照してください。

13.18.5.2 ドキュメント変換の構成

ドキュメント変換を構成する手順は次のとおりです。

1. 次のURLからInbound Refineryにログインします。

http://WCPHOST1:16250/ibr/

2. Inbound Refineryでの変換コンポーネントを有効にします。コアInbound Refineryは、ファイルをTIFF Web表示可能ファイルおよびJPEGイメージ・サムネイルに変換します。追加の変換タイプを使用するには、必要なコンポーネントを有効にする必要があります。

注意:

変換コンポーネントの詳細は、Oracle Fusion Middleware変換についての管理者ガイドのInbound Refinery変換オプションと関連コンポーネントに関する項を参照してください。

1. 「管理」トレイまたはメニューを開いて、「管理サーバー」→「サーバー機能」を選択します。

2. 目的のコンポーネントを選択します。詳細は、readmeファイルおよび各コンポーネントのドキュメントを参照してください。

3. 「更新」をクリックします。

4. 「OK」をクリックして、コンポーネントを有効にします。

5. Inbound Refinery管理対象サーバーを再起動します。

3. Inbound RefineryでPDFExportConverterを有効にします。PDFExportConverterは、Outside Inを使用して、ドキュメントを直接PDFファイルに変換します。この変換はクロス・プラットフォームにすることができ、サードパーティ製品を必要としません。Inbound Refinery用のPDFExportConverterはサービス機能として有効にできます。

1. 「管理」トレイまたはメニューを開いて、「管理サーバー」→「サーバー機能」を選択します。

2. 「PDFExportConverter」を選択します。

3. 「更新」をクリックします。

4. 「OK」をクリックして、この機能を有効にします。

5. Inbound Refinery管理対象サーバーを再起動します。

4. プライマリWeb表示可能変換をPDFエクスポートに設定します。

1. 「変換設定」→「プライマリWebレンディション」を選択します。

2. 「プライマリWeb表示可能レンディション」ページで、「PDFエクスポートによるPDFへの変換」を選択します。

3. 「更新」をクリックして変更内容を保存します。

これで、Inbound Refineryは、サードパーティ・アプリケーションを使用せずに、Outside In PDF Exportを使用してファイルをPDFに直接変換します。

5. 管理サーバーとすべてのInbound Refinery管理対象サーバーを再起動します。

13.18.5.3 Inbound RefineryのOracle WebCenter Contentへの構成

Oracle WebCenter Contentにログインします。

1. 「管理」→「プロバイダ」を選択します。

2. プロバイダ・ページの「新規プロバイダの作成」セクションで、「送信」行の「追加」をクリックします。

3. 名前、説明、ホスト、サーバー・ポート(IBR intradocポート)、コンテキスト・ルート、インスタンス名など、IBRインスタンスの詳細を入力します。

- プロバイダ名: 空白が含まれない短縮名。「インスタンス名」と同じ値を使用することをお薦めします。
IBRインスタンス名はIBRサーバーから取得されます。インスタンス名を探すには、IBRにログインし、「管理」をクリックし、次に 「インスタンスの構成」をクリックします。

注意:

この手順を実行しないと、「管理」メニューに「リファイナリ管理」メニュー・アイテムが表示されなくなります。

- プロバイダの説明: テキスト文字列。

- サーバー・ホスト名: Inbound Refineryインスタンスが実行されているホスト・マシンの名前。たとえば、WCCHOST1など。

- HTTPサーバー・アドレス: Inbound Refineryインスタンスのアドレス。たとえば、WCCHOST1: 16250など。

- サーバー・ポート: 第13.18.5.1項「Inbound Refineryの設定の構成」で指定されているInbound Refineryインスタンスの「サーバーのソケット・ポート」フィールドの値(たとえば、5555など)。これは、コンテンツ・サーバーのconfig.cfgファイルにあるIntradocServerPortの値です。

- インスタンス名: 第13.18.5.1項「Inbound Refineryの設定の構成」で指定されているInbound Refineryのサーバー・インスタンス名。これは、コンテンツ・サーバーのconfig.cfgファイルにあるIDC_Nameの値です。

- 相対Webルート: Inbound RefineryインスタンスのWebルート。たとえば、/ibr/など。

4. 「変換オプション」で、「Inbound Refinery変換ジョブの処理」を選択します。
「Inbound Refineryの読取り専用モード」は選択しないでください。

5. 「追加」をクリックします。

6. Oracle WebCenter Content Serverを再起動します。

7. IBRに送信される各ファイル・タイプを選択します。

1. 「管理」→「リファイナリ管理」→「ファイル・フォーマット・ウィザード」を選択します。

2. リファイナリに送信する適切なファイル・タイプのボックスを選択します。

WebCenterConversionsコンポーネントを介して、変換を有効にしている場合を除き、「HTML」や「Wiki」、「ブログ」は選択しないでください。Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドの変換するファイル形式の選択に関する説明も参照してください。

8. WikiとブログのPDFへの変換を有効にします。
Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのWikiとブログのPDFへの変換の有効化に関する説明を参照してください。

14 エンタープライズ・デプロイメント用のサーバー移行の構成

この章では、エンタープライズ・デプロイメント用にサーバー移行を構成する手順を説明します。

この章の内容は次のとおりです。

- 第14.1項「エンタープライズ・デプロイメント用のサーバー移行の概要」

- 第14.2項「サーバー移行リース表のユーザーと表領域の設定」

- 第14.3項「管理コンソールを使用したリース用のGridLinkデータ・ソースの作成」

- 第14.4項「SOAHOST1およびSOAHOST2と管理サーバー間でのホスト名検証証明書の有効化」

- 第14.5項「ノード・マネージャのプロパティ・ファイルの編集」

- 第14.6項「wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定」

- 第14.7項「サーバー移行ターゲットの構成」

- 第14.8項「サーバー移行のテスト」

14.1 エンタープライズ・デプロイメント用のサーバー移行の概要

管理対象サーバーWLS_SOA1およびWLS_SOA2のサーバー移行を構成します。サーバー移行が構成されていると、障害が発生したときに、WLS_SOA1管理対象サーバーがSOAHOST2で再起動し、WLS_SOA2管理対象サーバーがSOAHOST1で再起動します。WLS_SOA1およびWLS_SOA2サーバーは、Oracle WebLogic Serverによってフェイルオーバーされる特定の浮動IPをリスニングします。

次の項の手順を実行し、管理対象サーバーのサーバー移行を構成します。

14.2 サーバー移行リース表のユーザーおよび表領域の設定

create tablespace leasingコマンドを使用して、サーバー移行リース表のユーザーおよび表領域を設定します。

サーバー移行リース表のユーザーおよび表領域を設定する手順は次のとおりです。

1. leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。

SQL> create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. leasingというユーザー名を作成し、リース表領域に割り当てます。

SQL> create user leasing identified by 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スクリプトを使用してリース表を作成します。

1. 次のいずれかのディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。

WL_HOME/server/db/oracle/817
WL_HOME/server/db/oracle/920

2. leasingユーザーとしてデータベースに接続します。

3. leasing.ddlスクリプトをSQL*Plusで実行します。

SQL> @copy_location/leasing.ddl;

14.3 管理コンソールを使用したリース用のGridLinkデータ・ソースの作成

Oracle WebLogic Server管理コンソールからリース表用のGridLinkデータ・ソースを作成します。

GridLinkデータ・ソースを作成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. まだ行っていない場合は、「チェンジ・センター」で「ロックして編集」をクリックし、「次へ」をクリックします。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次を入力します。

- 「名前」フィールドにデータ・ソースの論理名を入力します。たとえば、leasingです。

- JNDIの名前を入力します。たとえば、jdbc/leasingです。

- 「データベース・ドライバ」には、「OracleのGridLink接続用ドライバ(Thin)、バージョン: 11以降」を選択します。

- 「次へ」をクリックします。

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」で「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACサービス名を入力します。次に例を示します。

wcpedg.mycompany.com

- ホスト名およびポート: 使用しているRACデータベースのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用しデータベースで適切なパラメータを問い合わせることによって特定できます。

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string db-scan.mycompany.com:1521

注意:

Oracle Database 11g R1では、次のように、各データベースのインスタンス・リスナーにVIPとポートを使用します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

- Port: データベース・サーバーが接続リクエストをリスニングするポート。

- データベース・ユーザー名: 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=wcpedg.us.oracle.com))) succeeded.

「次へ」をクリックします。

9. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- データベースよりレポートされたRACデータベースとONSリモート・ポートのSCANアドレスもここに入力し(例は下を参照)、「追加」をクリックします。

[orcl@db-scan ~]$ srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

- 「次へ」をクリックします。

注意:

Oracle Database 11g R1には、各データベースのONSサービスのホスト名とポートを次のように使用します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
正常に接続された場合の通知例を次に示します。

Connection test for db-scan.mycompany.com:6200 succeeded.

「次へ」をクリックします。

11. 「ターゲットの選択」ページで「SOA_Cluster」をターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 「変更のアクティブ化」をクリックします。

14.4 SOAHOST1およびSOAHOST2と管理サーバー間でのホスト名検証証明書の有効化

ノード・マネージャと管理サーバー間でのホスト名検証に適切な証明書を作成します。この手順の詳細は、第11.3項「SOAHOST1およびWCPHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」および第11.5項「SOAHOST2およびWCPHOST2でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

14.5 ノード・マネージャのプロパティ・ファイルの編集

サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。nodemanager.propertiesファイルは次のディレクトリにあります。

WL_HOME/common/nodemanager

次のプロパティを追加してサーバー移行が正常に動作するようにします。

- Interface

Interface=eth0

このプロパティは浮動IP(eth0など)のインタフェース名を指定します。

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

- NetMask

NetMask=255.255.255.0

このプロパティは浮動IP用インタフェースのネット・マスクを指定します。

- UseMACBroadcast

UseMACBroadcast=true

このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力結果は次のようになります。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:

サーバーのプロパティ(起動プロパティ)が設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

1. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

2. WL_HOME/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。

注意:

共有記憶域インストールからノード・マネージャを実行する場合、同じnodemanager.propertiesファイルを使用して複数のノードが起動します。ただし、NetMaskプロパティやInterfaceプロパティにはノードごとに異なる値が必要です。この場合、環境変数を使用して、ノードごとに個別にパラメータを指定します。たとえば、SOAHOSTnで異なるインタフェース(eth3)を使用するには、Interface環境変数をSOAHOSTn export JAVA_OPTIONS=-DInterface=eth3のように使用し、この変数がシェルに設定された後、ノード・マネージャを起動します。

14.6 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定するには、次の手順を実行します。

1. 表14-1に示すファイルをPATH環境変数で指定していることを確認します。

表14-1 PATH環境変数に必要なファイル

ファイル

ディレクトリの場所

wlsifconfig.sh

ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domain

WL_HOME/common/nodemanager

2. sudoの構成をwlsifconfig.shスクリプトに付与します。

- パスワードの要求がなくても動作するようにsudoを構成します。

- セキュリティ上の理由から、sudoの付与はwlsifconfig.shスクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限は次のように設定します。

1. パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

2. スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。

oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

注意:

この手順に適切なsudo権限とシステム権限については、システム管理者に問い合せてください。

14.7 サーバー移行ターゲットの構成

サーバー移行ターゲットを構成します。クラスタの移行の構成では、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。

クラスタ内の移行を構成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

http://host:adminPort/console

通常、adminPortはデフォルトの7001です。

2. 「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. 表の「名前」列で、移行を構成するクラスタ(SOA_Cluster)をクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。この場合は、「SOAHOST1」と「SOAHOST2」を選択します。

7. 自動移行に使用するデータソースを選択します。この場合は、リース・データソースを選択します。

8. 「保存」をクリックします。

9. 「変更のアクティブ化」をクリックします。

10. サーバー移行の候補となるマシンを設定します。この作業は、次の手順に従ってすべての管理対象サーバーで実行する必要があります。

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

2. 移行を構成するサーバーを選択します。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。「WLS_SOA1」に対しては「SOAHOST2」を選択します。「WLS_SOA2」に対しては「SOAHOST1」を選択します。

5. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。

6. 「変更のアクティブ化」をクリックします。

7. 管理サーバーと、サーバー移行が構成されているサーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

ヒント:

「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、実際の構成と異なる内容が表示されます。

14.8 サーバー移行のテスト

サーバーの移行が適切に行われていることを確認する手順は次のとおりです。

ノード1からテストする手順は次のとおりです。

1. WLS_SOA1管理対象サーバーを停止します。

kill -9 pid

PIDには管理対象サーバーのプロセスIDを指定します。ノード内のPIDは、次のコマンドを実行して識別できます。

ps -ef | grep WLS_SOA1

2. ノード・マネージャのコンソールを確認します。WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOA1の2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルで再び再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

ノード2からテストする手順は次のとおりです。

1. ローカル・ノード・マネージャのコンソールを確認します。ノード1でのWLS_SOA1の再起動が前回試行されてから30秒間経過した後に、WLS_SOA1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。

2. 同じIPでsoa-infraコンソールにアクセスします。

管理コンソールでの確認

管理コンソールを使用して移行を検証することも可能です。

1. 管理コンソールにログインします。

2. 左のコンソールで「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。

図14-1 管理コンソールの「移行の状態」画面

「図14-1 管理コンソールの「移行の状態」画面」の説明

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

15 エンタープライズ・デプロイメントとOracle Identity Managementの統合

この章では、Oracle WebCenter PortalをOracle Identity Managementと統合する方法について説明します。内容は次のとおりです。

- 第15.1項「Oracle Identity Managementとの統合の概要」

- 第15.2項「資格証明ストアの構成」

- 第15.3項「ポリシー・ストアの構成」

- 第15.4項「資格証明とポリシーの再関連付け」

- 第15.5項「Oracle Access Manager 10gの統合」

- 第15.6項「Oracle Access Manager 11gの統合」

- 第15.7項「SSO用のWebCenter Portalアプリケーションの構成」

- 第15.8項「WebCenter PortalおよびBPEL認証の構成」

- 第15.9項「アイデンティティ管理構成のバックアップ」

15.1 Oracle Identity Managementとの統合の概要

Oracle Fusion Middlewareエンタープライズ・デプロイメントをOracle Identity Manager 10gまたは11gと統合できます。次の項では、まず資格証明ストアとポリシー・ストアを構成する方法とそれらの資格証明ストアおよびポリシー・ストアを再関連付けする方法を説明し、Oracle Identity Manager 10gまたは11gと統合します。

表15-1は、Oracle Identity Manager 10gをOracle WebCenter Portalエンタープライズ・デプロイメントに統合するための大まかな手順を示しています。

表15-2は、Oracle Identity Manager 11gをOracle WebCenterエンタープライズ・デプロイメントに統合するための大まかな手順を示しています。

注意:

Oracle Identity Managementとの統合時には、Oracle Identity Managementサーバーで現在使用されているトランスポート・モードを使用します。たとえば、オープン、簡易、証明書などです。

表15-1 Oracle Identity Manager 10gとの統合手順

手順

説明

詳細

資格証明ストアの構成

Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成します。

第15.2項「資格証明ストアの構成」

ポリシー・ストアの構成

Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成します。

第15.3項「ポリシー・ストアの構成」

OAM構成ツールの使用

OAM構成ツール(oamcfg)を使用し、一連のスクリプトを起動し、必要なポリシーを設定します。

第15.5.3項「OAM構成ツールの使用」

WebGateのインストールと構成

各WEBHOSTnマシンにWebGateをインストールし、Web層を保護します。

第15.5.4項「WebGateのインストールと構成」

WebGateのIP検証の構成

アクセス・システム・コンソールを使用して、WebGateのIP検証を構成します。

第15.5.5項「WebGateのIP検証の構成」

WebLogic認証プロバイダの設定

構成ファイルのバックアップ、OAM IDアサータの設定およびプロバイダの順序設定によって、WebLogic認証プロバイダを設定します。

第15.5.6項「WebLogic認証プロバイダの設定」

SSO用のWebCenter Portalアプリケーションの構成

SSOのシステム・プロパティ、Spacesアプリケーションの管理者ロール、SSO用のディスカッション・サーバーを構成します。

第15.7項「SSO用のWebCenter Portalアプリケーションの構成」

WebCenter PortalおよびBPELサーバー認証の構成

WebCenter PortalとBPELサーバーを構成します。

第15.8項「WebCenter PortalおよびBPEL認証の構成」

表15-2 Oracle Identity Manager 11gとの統合手順

手順

説明

詳細

資格証明ストアの構成

Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成します。

第15.2項「資格証明ストアの構成」

ポリシー・ストアの構成

Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成します。

第15.3項「ポリシー・ストアの構成」

WebGateのインストール

HTTPサーバーがすでにインストールされている各WEBHOSTマシンにWebGateをインストールします。

第15.6.3項「WebGateのインストール」

WebGateエージェントの登録

RREGツールを使用したWebGateエージェントの登録

第15.6.4項「WebGateエージェントの登録」

WebLogic認証プロバイダの設定

構成ファイルのバックアップ、OAM IDアサータの設定およびプロバイダの順序設定によって、WebLogic認証プロバイダを設定します。

第15.6.5項「WebLogicオーセンティケータのセットアップ」

SSO用のWebCenter Portalアプリケーションの構成

SSOのシステム・プロパティ、Spacesアプリケーションの管理者ロール、SSO用のディスカッション・サーバーを構成します。

第15.7項「SSO用のWebCenter Portalアプリケーションの構成」

WebCenter PortalおよびBPEL認証の構成

WebCenter PortalとBPELサーバーを構成します。

第15.8項「WebCenter PortalおよびBPEL認証の構成」

15.2 資格証明ストアの構成

Oracle Fusion Middlewareでは、WebLogicドメインで異なるタイプの資格証明ストアとポリシー・ストアを使用できます。ドメインでは、XMLファイルに基づくストアまたは異なるタイプのLDAPプロバイダに基づくストアを使用できます。ドメインでLDAPストアを使用する場合は、すべてのポリシーと資格証明データが、中央のストアで保持および管理されます。ただし、XMLポリシー・ストアを使用すると、管理対象サーバー上で行われる変更は、管理サーバーに伝播されません(両方のサーバーが同じドメイン・ホームを使用していない場合)。Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジでは、管理サーバーと管理対象サーバーで異なるドメイン・ホームを使用するので、整合性および一貫性を保持するために、ポリシー・ストアおよび資格証明ストアとしてLDAPストアを使用する必要があります。デフォルトでは、Oracle WebLogic Serverドメインは、ポリシー・ストアにXMLファイルを使用します。次の項では、デフォルト・ストアを資格証明またはポリシー用のOracle Internet Directory LDAPに変更するために必要な手順について説明します。

注意:

ポリシー・ストアおよび資格証明ストアのバックエンド・リポジトリは、同じ種類のLDAPサーバーを使用する必要があります。この一貫性を保持するために、一方のストアを再関連付けるともう一方も再関連付けることになります。つまり、資格証明ストアとポリシー・ストアの両方の再関連付けは、Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドreassociateSecurityStoreを使用して、1つの単位として実行されます。詳細は、第15.4項「資格証明とポリシーの再関連付け」を参照してください。

資格証明ストアは、セキュリティ・データ(資格証明)のリポジトリです。資格証明には、ユーザー名とパスワードの組合せ、チケット、または公開鍵証明書が保持されます。資格証明は、認証中(プリンシパルがサブジェクトに移入されるとき)に使用され、さらに認可(サブジェクトが実行可能なアクションを決定するとき)にも使用されます。この項では、Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジの資格証明ストアとしてOracle Internet Directory LDAPを構成する手順を示します。資格証明ストアの構成の詳細は、『Oracle Containers for J2EE セキュリティ・ガイド』の「資格証明ストアの構成」の章を参照してください。

次の項では、資格証明ストアの構成について説明します。

- 第15.2.1項 LDAP認証プロバイダの作成

- 第15.2.2「WebLogic管理者のLDAPへの移行」

- 第15.2.3項「ドメイン資格証明ストアの再関連付け」

15.2.1 LDAP認証プロバイダの作成

この項では、WebLogic Server管理コンソールを使用して、LDAP認証プロバイダを作成する方法について説明します。

前提条件

LDAP認証プロバイダを作成する前に、関連構成ファイルをバックアップする必要があります。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/system-jazn-data.xml

次のディレクトリにある、管理サーバーのboot.propertiesファイルをバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security

LDAPを使用するように資格証明ストアを構成する手順は次のとおりです。

1. WebLogic Serverコンソールにログインします。

2. 左のナビゲーション・バーにある「セキュリティ・レルム」リンクをクリックします。

3. myrealmデフォルト・レルム・エントリをクリックして構成します。

4. このレルム内の「プロバイダ」タブを開きます。

5. このレルム用に構成したDefaultAuthenticatorプロバイダがあることを確認します。

6. 「ロックして編集」をクリックします。

7. 「新規」ボタンをクリックし、新しいプロバイダを追加します。

8. プロバイダの名前を入力します。たとえば、OIDAuthenticator(Oracle Internet Directoryが使用される場合)、またはOVDAuthenticator(Oracle Virtual Directoryが使用される場合)のような名前にします。

9. 認証プロバイダのリストから、OracleInternetDirectoryAuthenticator (Oracle Internet Directoryが使用される場合)、またはOracleVirtualDirectoryAuthenticator (Oracle Virtual Directoryが使用される場合)のいずれかのタイプを選択し、「OK」をクリックします。

10. 「プロバイダ」画面で、新しく作成した認証プロバイダをクリックします。

11. 「制御フラグ」を「SUFFICIENT」に設定します。このフラグは、この認証プロバイダによって正常に認証されたユーザーは、その認証を受け入れたうえで、他の認証プロバイダを呼び出さないようにすることを示しています。認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。以降のすべての認証プロバイダの制御フラグも「SUFFICIENT」に設定されていることを確認してください。特に「DefaultAuthenticator」を確認し、その制御フラグを「SUFFICIENT」に設定します。

12. 「保存」をクリックしてこの設定を保存します。

13. 「プロバイダ固有」タブを開き、LDAPサーバーの詳細情報を入力します。

14. 次の表に示されているように、使用しているLDAPサーバーに固有の詳細情報を入力します。

パラメータ

値

値の説明

ホスト

例: oid.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を指定します。

取得したユーザー名をプリンシパルとして使用する

チェック・ボックスを選択

オンにする必要があります。

完了したら「保存」をクリックします。

15. 「変更のアクティブ化」をクリックして変更を伝播します。

認証プロバイダの並替え

OID/OVD認証プロバイダおよびデフォルト認証プロバイダを並べ替えて、それぞれの認証プロバイダの制御フラグが次のように設定されていることを確認します。

認証プロバイダの順序を設定する手順は次のとおりです。

1. WebLogicコンソールにログインしていない場合は、ログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. OID/OVD認証プロバイダおよびデフォルト認証プロバイダの制御フラグが次のように設定されていることを確認し、これらの認証プロバイダを並べ替えます。

- OID LDAP認証プロバイダ(またはOVD LDAP認証プロバイダ): SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

5. 「OK」をクリックします。

6. 「変更のアクティブ化」をクリックして変更を伝播します。

7. 管理サーバーとすべての管理対象サーバーを再起動します。

15.2.2 WebLogic管理者のLDAPへの移行

この項では、Oracle Fusion MiddlewareのWebCenter Portal WebLogicドメインを管理するために、新しい管理者ユーザーおよびグループをプロビジョニングする方法の詳細について説明します。この項では、次の作業について説明します。

- 第15.2.2.1項「LDAPディレクトリでの管理ユーザーおよびグループのプロビジョニング」

- 第15.2.2.2項「管理ロールの管理グループへの割当て」

- 第15.2.2.3項「boot.propertiesファイルの更新およびシステムの再起動」

15.2.2.1 LDAPディレクトリでの管理ユーザーおよびグループのプロビジョニング

この項の概要で説明したように、複数のWebLogicドメインのユーザーおよびグループが中央のLDAPユーザー・ストアにプロビジョニングされる場合があります。そのような場合、1人のWebLogic管理ユーザーが企業内のすべてのドメインへのアクセス権を所有している可能性があります。これはお薦めしません。WebLogic管理ユーザーがすべてのドメインにアクセスできるような状況にならないようにするために、プロビジョニングされるユーザーおよびグループには、ディレクトリ・ツリー内で一意の識別名を付与しておく必要があります。このマニュアルで説明するWebCenter Portalエンタープライズ・デプロイメントのWebLogicドメインでは、管理ユーザーおよびグループは、次のDNでプロビジョニングされます。

- 管理ユーザーDN:

cn=weblogic_wc,cn=Users,dc=us,dc=mycompany,dc=com

- 管理グループDN:

cn=WC_Administrators,cn=Groups,dc=us,dc=mycompany,dc=com

管理ユーザーおよび管理グループをOracle Internet Directoryにプロビジョニングする手順は次のとおりです。

1. 次に示す内容のadmin_user.ldifという名前のldifファイルを作成して保存します。

dn: cn=weblogic_wc, cn=Users, dc=us, dc=mycompany, dc=com
orclsamaccountname: weblogic_wc
givenname: weblogic_wc
sn: weblogic_wc
userpassword: MyPassword1
mail: weblogic_wc
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
uid: weblogic_wc
cn: weblogic_wc
description: Admin User for the WebCenter Portal Domain

2. ORACLE_HOME/binディレクトリにあるldapaddコマンドを実行し、ユーザーをOracle Internet Directoryにプロビジョニングします。

注意:

ここで使用するOracleホームは、Oracle Internet Directoryが存在するアイデンティティ管理インストールのOracleホームです。ldapaddコマンドが成功するには、ORACLE_HOME環境変数を設定する必要があります。

次に例を示します(次の例では、読み易さを考慮してコマンドを2行に分けて示してありますが、実際には1行に入力する必要があります)。

OIDHOST1> ORACLE_HOME/bin/ldapadd -h oid.mycompany.com -p 389 -D
cn="orcladmin" -w welcome1 -c -v -f admin_user.ldif

3. 次に示す内容のadmin_group.ldif という名前のldifファイルを作成して保存します。

dn: cn=WC_Administrators, cn=Groups, dc=us, dc=mycompany, dc=com
displayname: WC_Administrators
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_wc,cn=users,dc=us,dc=mycompany,dc=com
cn: WC_Administrators
description: Administrators Group for the SOA Domain

4. ORACLE_HOME/bin/ディレクトリにあるldapaddコマンドを実行し、グループをOracle Internet Directoryにプロビジョニングします(次の例では、読み易さを考慮してコマンドを2行に分けて示してありますが、実際には1行に入力する必要があります)。

OIDHOST1> 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 管理ロールの管理グループへの割当て

ユーザーおよびグループをOracle Internet Directoryに追加した後、グループをWebLogicドメインのセキュリティ・レルム内の管理ロールに割り当てる必要があります。それによって、グループに属すすべてのユーザーをこのドメインの管理者にできるようになります。

管理ロールを管理グループに割り当てる手順は次のとおりです。

1. WebLogic Server管理コンソールにログインします。

2. コンソールの左ペインで、「セキュリティ・レルム」をクリックします。

3. 「セキュリティ・レルムのサマリー」ページの表「レルム」で「myrealm」をクリックします。

4. 「myrealm」の「設定」ページで、「ロールとポリシー」タブをクリックします。

5. 「レルム・ロール」ページの表「ロール」の「グローバル・ロール」エントリを開きます。すると、「ロール」のエントリが表示されます。「ロール」リンクをクリックして、「グローバル・ロール」ページを表示します。

6. 「グローバル・ロール」ページで、「管理」ロールをクリックして「グローバル・ロールの編集」ページを開きます。

1. 「グローバル・ロールの編集」ページの表「ロール条件」の「条件の追加」ボタンをクリックします。

2. 「述部の選択」ページで、条件のドロップダウン・リストから「グループ」を選択し、「次へ」をクリックします。

3. 「引数の編集」ページのグループ引数フィールドで「WC_Administrators」を指定し、「追加」をクリックします。

7. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。

8. 「ロール条件」表にWC_Administratorsグループがエントリとして表示されます。

9. 「保存」をクリックして、WC_Administratorsグループへの管理ロールの追加を終了します。

10. Webブラウザを使用してWebLogic管理サーバー・コンソールを起動し、変更が正常に完了したことを検証します。weblogic_wcユーザーの資格証明を使用してログインします。

注意:

それぞれのSOAアプリケーションには、管理および監視用に定義された、事前定義済の独自のロールとグループがあります。デフォルトでは、「管理者」グループでその作業を実行できます。ただし、「管理者」グループは広範になりすぎることもあります。たとえば、Worklistapp管理者をSOAが稼働するWebLogic Serverドメインの管理者にしたくない場合があります。そのためには、SOA管理者など、より具体的なグループを作成することもできます。様々なアプリケーションで、SOA管理者グループによって様々なシステムを管理できるようにするには、必要なアプリケーション固有のロールをSOA管理者グループに追加する必要があります。たとえば、Worklistappの管理用には、SOA管理者グループにSOAAdminロールを追加します。それぞれのケースで必要なロールについては、各コンポーネントの固有のロールを参照してください。

15.2.2.3 boot.propertiesファイルの更新およびシステムの再起動

管理サーバー用のboot.propertiesファイルは、Oracle Internet Directoryで作成されたWebLogic管理ユーザーを追加して更新する必要があります。次の手順に従って、boot.propertiesファイルを更新します。

1. SOAHOST1で、次のディレクトリに移動します。

cd ORACLE_BASE/admin/domainName/aserver/domainName/servers/
AdminServer/security

2. 既存のboot.propertiesファイルの名前を変更します。

mv boot.properties boot.properties.backup

3. テキスト・エディタを使用して、セキュリティ・ディレクトリにboot.propertiesというファイルを作成します。次の行をこのファイルに入力します。

username=weblogic_wc
password=welcome1

4. ファイルを保存します。

5. 管理サーバーを停止します。

wls:/nm/domain_name>nmKill("AdminServer")

6. 管理サーバーは、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順で再起動します。

15.2.3 ドメイン資格証明ストアの再関連付け

資格証明ストアとポリシー・ストアの構成が完了したら、再度関連付ける必要があります。資格証明ストアとポリシー・ストアは、Enterprise Manager Fusion Middleware Controlまたは、WLSTコマンド(reassociateSecurityStore)を使用して、再度関連付けます。詳細な手順は、第15.4項「資格証明とポリシーの再関連付け」を参照してください。

15.3 ポリシー・ストアの構成

ドメイン・ポリシー・ストアは、システム固有のポリシーおよびアプリケーション固有のポリシーのリポジトリです。特定のドメインには、そのドメインにデプロイされるすべてのアプリケーションが使用可能なすべてのポリシーを格納する1つのストアが存在します。この項では、Oracle Fusion Middleware WebCenter Portalエンタープライズ・デプロイメント・トポロジのポリシー・ストアとしてOracle Internet Directory LDAPを構成する手順を示します。この手順は、2つの部分で構成されています。

- サーバー・ディレクトリでのノードの設定

- ドメイン・ポリシー・ストアの再関連付け

ポリシー・ストアの構成の詳細は、『Oracle Containers for J2EE セキュリティ・ガイド』の「OPSS認証およびポリシー・ストア」の章を参照してください。

15.3.1 サーバー・ディレクトリでのノードの設定

ポリシー・ストアとして使用されるLDAPサーバー・ディレクトリ(Oracle Internet Directory)に正しくアクセスするためには、このサーバー・ディレクトリにノードを設定する必要があります。この手順はOracle Internet Directory管理者が実行する必要があります。

Oracle Internet Directoryサーバーに適切なノードを作成する手順は次のとおりです。

1. LDIFファイル(この例ではjpstestnode.ldifを想定)を作成し、次のDNエントリおよびCNエントリを指定します。

dn: cn=jpsroot_wc
cn: jpsroot_wc
objectclass: top
objectclass: OrclContainer

ルート・ノードの識別名(前述の文字列jpsroot_wc)は、他の識別名と異なっている必要があります。1つのルート・ノードを複数のWebLogicドメインが共有できます。サブツリーへの読取り権限および書込み権限がOracle Internet Directory管理者に付与されているかぎり、このノードを最上位レベルに作成する必要はありません。

2. 次の例に示すように、ldapaddコマンドを使用して、このデータをOracle Internet Directoryサーバーにインポートします(次の例では、読み易さを考慮してコマンドを2行に分けて示してありますが、実際には1行に入力する必要があります)。

OIDHOST1> ORACLE_HOME/bin/ldapadd -h ldap_host -p ldap_port -D
cn=orcladmin -w password -c -v -f jpstestnode.ldif

3. 次の例に示すように、ldapsearchコマンドを使用して、ノードが正常に挿入されたことを確認します(次の例では、読み易さを考慮してコマンドを2行に分けて示してありますが、実際には1行に入力する必要があります)。

OIDHOST1> ORACLE_HOME/bin/ldapsearch -h ldap_host -p ldap_port -D
cn=orcladmin -w password -b "cn=jpsroot_wc" objectclass="orclContainer"

4. Oracle Internet DirectoryをLDAPベースのポリシー・ストアとして使用する場合は、ユーティリティoidstats.sqlをINFRADBHOSTで実行し、最適なデータベース・パフォーマンスを実現するためのデータベース統計を生成します。

ORACLE_HOME/bin/sqlplus

ユーザー名にODSを入力します。ODSユーザーの資格証明を入力するよう求められます。sqlplusに入って、統計情報を収集する次のコマンドを入力します。

SQLPLUS> @ORACLE_HOME/ldap/admin/oidstats.sql

oidstats.sqlユーティリティは、初期プロビジョニング後に1回だけ実行する必要があります。このユーティリティの詳細は、Oracle Identity Managementユーザー・リファレンスを参照してください。

15.3.2 ドメイン・ポリシー・ストアの再関連付け

ファイルまたはLDAPベースのリポジトリから、LDAPベースのリポジトリにポリシー・データを移行して、ポリシー・ストアを再度関連付けます。再関連付けでは、格納データの整合性を維持しながらリポジトリが変更されます。ソース・ポリシー・ストアの各ポリシーに対して再関連付けを行うと、ターゲットのLDAPディレクトリが検索され、一致が見つかると、一致したポリシーが必要に応じて更新されます。何も見つからない場合は、ポリシーがそのまま移行されます。

ドメイン・ポリシー・ストアをインスタンス化したら、ファイルベースまたはLDAPベースのポリシー・ストアを、同じデータを格納するLDAPベースのポリシー・ストアにいつでも再関連付けできます。そのためには、LDAPポリシー・ストアを使用できるようにドメインが適切に構成されている必要があります。

詳細な手順は、第15.4項「資格証明とポリシーの再関連付け」を参照してください。

15.4 資格証明とポリシーの再関連付け

ポリシー・ストアおよび資格証明ストアをOracle Internet Directoryに再関連付けするには、WLSTのreassociateSecurityStoreコマンドを使用します。

ポリシー・ストアおよび資格証明ストアの再関連付け手順は次のとおりです。

1. SOAHOST1から、wlstシェルを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

2. 次に示すwlst connectコマンドを使用して、WebLogic管理サーバーに接続します。
構文:

connect("AdminUser","AdminUserPassword",t3://hostname:port)

次に例を示します。

connect("weblogic","welcome1","t3://ADMINVHN:7001")

3. 次に示すように、reassociateSecurityStoreコマンドを実行します。
構文:

reassociateSecurityStore(domain="domainName",admin="cn=orcladmin", password="orclPassword",ldapurl="ldap://LDAPHOST:LDAPPORT",servertype="OID",
jpsroot="cn=jpsroot_wc")

次に例を示します。

wls:/WCPEDGDomain/serverConfig>reassociateSecurityStore(domain="wcpedg_domain",
admin="cn=orcladmin",password="welcome1",ldapurl="ldap://oid.mycompany.com:389",servertype="OID",jpsroot="cn=jpsroot_wc")

このコマンドの出力を次に示します。

{servertype=OID,jpsroot=cn=jpsroot_wc_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 LDAP server after migration has been tested to be available
Update of jps configuration is done
Policy Store reassociation done.
Starting credential Store reassociation
LDAP server and  ServiceConfigurator setup done.
Schema is seeded into LDAP server
Data is migrated to LDAP server
Service in LDAP server after migration has been tested to be available
Update of jps configuration is done
Credential Store reassociation done
Jps Configuration has been changed. Please restart the server.

4. コマンドが正常に完了した後に、管理サーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

注意:

資格証明とポリシーの変更を有効にするには、ドメイン内のサーバーを再起動する必要があります。

Oracle Internet Directoryの属性のカタログ化

検索フィルタで使用するOracle Internet Directoryの属性に索引を付けます。索引付けは、パフォーマンス向上のためのオプションの手順です。このOracle Internet Directory内の属性への索引付けが済んでいない場合は、catalogツールを使用して索引付けます。

たとえば、orclerolescope属性に索引付けを行う場合は、次のようにします。

catalog connect="orcl" add=true attribute="orclrolescope" verbose="true"

ファイルに複数の属性名を記載してバッチとして処理すると、複数の属性名に索引を付けることができます。

orclrolescope
orclassignedroles
orclApplicationCommonName
orclAppFullName
orclCSFAlias
orclCSFKey
orclCSFName
orclCSFDBUrl
orclCSFDBPort
orclCSFCredentialType
orclCSFExpiryTime
modifytimestamp
createtimestamp
orcljpsassignee

OID属性の索引付けの詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』のタスクおよびカタログの例に関する項を参照してください。

15.5 Oracle Access Manager 10gの統合

この項では、Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのシングル・サインオン・ソリューションとしてOracle Access Manager 10gを設定する方法について説明します。

注意:

Oracle Access Manager 11gと統合する場合は、この項はスキップして第15.6項「Oracle Access Manager 11gの統合」の手順に従い、その後第15.7項「SSO用のWebCenter Portalアプリケーションの構成」に進み、本章の後半の部分を続行します。

この項の内容は次のとおりです。

- 第15.5.1項「Oracle Access Managerの統合の概要」

- 第15.5.2項「Oracle Access Managerの前提条件」

- 第15.5.3項「OAM構成ツールの使用」

- 第15.5.4項「WebGateのインストールと構成」

- 第15.5.5項「WebGateのIP検証の構成」

- 第15.5.6項「WebLogic認証プロバイダの設定」

- 第15.5.7項「OAM 10gでの仮想ホストの構成」

15.5.1 Oracle Access Managerの統合の概要

Oracle Access Manager(OAM)は、Oracle Fusion Middleware 11g リリース1において推奨されるシングル・サインオン・ソリューションです。OAMのインストールおよび構成の詳細は、Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイドを参照してください。この章では、WebCenter Portalのインストールを構成して既存のOAMインストールおよび基礎となるディレクトリ・サービスと連携させる手順について説明します。これらのディレクトリ・サービスには、Oracle Internet Directory (OID)またはOracle Virtual Directory (OVD)、またはその両方を使用することをお薦めします。

注意:

このマニュアルで説明するWebCenter Portalエンタープライズ・デプロイメント・トポロジでは、WebCenter Portalシステムとシングル・サインオン・システムの両方が、同一のネットワーク・ドメイン(mycompany.com)内に存在し、シングル・サインオン構成を使用しています。複数ドメイン構成の場合は、『Oracle Access Managerアクセス管理ガイド』の「シングル・サインオンの構成」に記載されている、必要な構成手順を参照してください。

15.5.2 Oracle Access Managerの前提条件

Oracle Access Manager (OAM)の設定では、Access Managerおよびポリシー・マネージャを保護するポリシーを完備した、OAMインストールが存在することを前提としています。OAMのインストールおよび構成の詳細は、Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイドを参照してください。この設定には、スタンドアロンのOracle Virtual Directory (OVD)構成またはその一部としてのOracle Internet Directory(OID)などのディレクトリ・サービスがあります。この章では、WebCenter Portalをインストールした環境をOIDまたはOVDを使用して構成する際に必要な手順を説明します。

さらに、OAMのインストール環境にはWebGateで構成した専用のWebサーバーが必要です。またこの項では、OAM Webサーバーを委任認証サーバーとして使用する手順についても説明します。

15.5.3 OAM構成ツールの使用

OAM構成ツール(oamcfg)は、一連のスクリプトを起動して必要なポリシーを設定します。そのためには、入力情報として様々なパラメータが必要となります。具体的には次の項目が作成されます。

1. OAMのフォーム認証スキーム

2. WebLogicサーバーでの認証を可能にするポリシー

3. Web層にあるOracle HTTP Server WebGateで構成済アプリケーションを保護できるようにOAMで指定するWebgateエントリ

4. 選択したシナリオに応じたホスト識別子(指定しない場合はデフォルトのホスト識別子が使用されます)

5. アプリケーション固有のURLを保護するポリシーおよび保護対象としないポリシー

この項の内容は次のとおりです。

- 第15.5.3.1項「OAM構成ツールの実行の前提条件」

- 第15.5.3.2項「OAM構成ツールの実行」

- 第15.5.3.3項「RESTポリシーの更新」

- 第15.5.3.4項「Oracle SESおよびポートレット用の除外ポリシーの作成」

- 第15.5.3.5項「ポリシー・ドメインおよびアクセス・ゲートを正常に作成したことの確認」

- 第15.5.3.6項「ホスト識別子の更新」

- 第15.5.3.7項「WebGateプロファイルの更新」

- 第15.5.3.8項「アクセス・サーバーの追加」

- 第15.5.3.9項「委任フォーム認証の構成」

15.5.3.1 OAM構成ツールの実行の前提条件

OAM構成ツールを実行する前に次の前提条件を確認します。

- パスワード: セキュアなパスワードを作成します。このパスワードは、この後に作成するWebGateインストールのパスワードとして使用します。

- LDAPホスト: 高可用性やエンタープライズ・デプロイメントの構成の場合は、ディレクトリ・サーバーのホスト名またはロード・バランサのアドレスを用意します。

- LDAPポート: ディレクトリ・サーバーのポートを用意します。

- LDAP USER DN: LDAP管理ユーザーのDNを用意します。これは「cn=orcladmin」などの値です。

- LDAPパスワード: LDAP管理ユーザーのパスワードを用意します。

- oam_aa_host: Oracle Access Managerのホスト名を用意します。

- oam_aa_port: Oracle Access Managerのポートを用意します。

15.5.3.2 OAM構成ツールの実行

OAM構成ツールは次の場所にあります。

ORACLE_COMMON_HOME/modules/oracle.oamprovider_11.1.1

ORACLE_COMMON_HOMEは構成ツールを実行するマシンによって異なります。このツールは、必要なインストール・ファイルがあればすべてのマシンから実行できます。この項で説明する手順では、SOAHOST1からツールを実行します。

次のようにOAM構成ツールを実行します(すべて1行のコマンド・ラインに記述します)。

MW_HOME/jrockit_160_<version>/bin/java -jar oamcfgtool.jar mode=CREATE
app_domain="WebCenter_EDG"
protected_uris="$URI_LIST"
public_uris="$PUBLIC_URI_LIST"
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

このコマンドの$URI_LIST変数と$PUBLIC_URI_LIST変数は、トポロジによって次のように異なります。

- ドメイン内のWebCenter Portal、WebCenter ContentおよびInbound Refinery
$URI_LIST="
/webcenter/adfAuthentication,
/integration/worklistapp,
/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow,
/workflow/WebCenterWorklistDetail/faces/adf.task-flow,
/workflow/sdpmessagingsca-ui-worklist,
/soa-infra,
/rss/rssservlet,
/owc_discussion/login!withRedirect.jspa,
/owc_discussions/login!default.jspa,
/owc_discussions/login.jspa,
/owc_discussions/admin,
/rest/api/resourceIndex,
/rest/api/spaces,
/rest/api/discussions,
/rest/api/tags,
/rest/api/taggeditems,
/rest/api/activities,
/rest/api/activitygraph,
/rest/api/feedback,
/rest/api/people,
/rest/api/messageBoards,
/rest/api/searchresults,
/activitygraph-engines,
/wcps/api,
/pagelets/admin,
/pagelets/authenticateWithApplicationServer,
/services-producer/adfAuthentication,
/rsscrawl,
/sesUserAuth,
/services-producer/portlets,
/wsrp-tools/portlets
/em,
/console,
/adfAuthentication,
/ibr/adfAuthentication"

$PUBLIC_URI_LIST="
/webcenter,
/owc_discussions,
/rss,
/rest/api/cmis,
/pagelets,
/services-producer,
/wsrp-tools,
/workflow,
/cs,
/ibr,
/idcnativews,
/"

- ドメイン内のWebCenter Portal、WebCenter Content、Inbound RefineryおよびSOA
$URI_LIST="
/webcenter/adfAuthentication,
/integration/worklistapp,
/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow,
/workflow/WebCenterWorklistDetail/faces/adf.task-flow,
/workflow/sdpmessagingsca-ui-worklist,
/rss/rssservlet,
/owc_discussions/login!withRedirect.jspa,
/owc_discussions/login!default.jspa,
/owc_discussions/login.jspa,
/owc_discussions/admin,
/rest/api/resourceIndex,/rest/api/spaces,/rest/api/discussions,/rest/api/tags,/rest/api/taggeditems,/rest/api/activities,
/rest/api/activitygraph,/rest/api/feedback,/rest/api/people,/rest/api/messageBoards,/rest/api/searchresults,
/activitygraph-engines,
/wcps/api,
/pagelets/admin,
/pagelets/authenticateWithApplicationServer,
/services-producer/adfAuthentication
/rsscrawl,
/sesUserAuth,
/services-producer/portlets,
/wsrp-tools/portlets,
/em,/console,/DefaultToDoTaskFlow,
/sdpmessaging/userprefs-ui,
/adfAuthentication,
/ibr/adfAuthentication,
/soa-infra,/soa/composer,/soa-infra/deployer,/soa-infra/events/edn-db-log,/soa-infra/cluster/info,/inspection.wsil"

$PUBLIC_URI_LIST="
/webcenter,
/owc_discussions,
/rss,
/workflow,
/rest/api/cmis,
/pagelets,
/services-producer,
/wsrp-tools,
/cs,
/ibr,
/idcnativews,
/,
/soa-infra/services/…/*,/soa-infra/directWSDL,/soa-infra/directWSDL/…/*,/ucs/messaging/webservice,/ucs/messaging/webservice/…/*"

注意:

- SOAを後で追加する場合または別のURLの保護が必要になった場合は、同じapp_domainを使用し、新しいURLのみではなく、保護するURLをすべて指定して、再度OAM構成ツールを実行してください。

- WebCenter Portal、SOAおよびWebCenter Contentにはそれぞれ、公開および保護されたURIの要件がリストされた.confファイルがあります。次のprotected_uris=とpublic_uris=の構文を使用して、公開および保護URIを指定するかわりに、構文uris_file=を使用して各ファイルを順に参照できます。詳細および手順は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのWebCenter Portalのポリシー・ドメインの構成に関する説明を参照してください。

コマンドが正常に実行された場合、次のような出力が得られます。

Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation
Operation Summary:
Policy Domain: WebCenter_EDG
Host Identifier: WebCenter_EDG
Access Gate ID: WebCenter_EDG_AG

15.5.3.3 RESTポリシーの更新

基本の認証を使用するようにRESTエンド・ポイントを更新するには、次の手順を実行します。

1. http://OAM_HOST:OAM_ADMINSERVER_PORT/oamconsoleにあるOracle Access Managerコンソールにログインします。

2. 前の手順で作成および検証したポリシー・ドメインを見つけ、「ポリシー」タブを開きます。
すでに作成されている2つのポリシー(Protected_JSessionId_Policyおよびデフォルト・パブリック・ポリシー)が表示されるはずです。

3. 次の値を使用して、WebCenterRESTPolicyという名前の別のポリシーを作成します。
説明: このポリシーは、WebCenter OutlookプラグインまたはiPhoneとの統合で必要なBASIC認証スキームを使用する、REST保護対象のURIを保護します。

リソース・タイプ: http

リソース操作: GET,POST

リソース: /restで始まる、/rest/cmis/repository以外のすべてのリソースを選択します。

/rest/api/resourceIndex
/rest/api/spaces
/rest/api/discussions
/rest/api/tags
/rest/api/taggeditems
/rest/api/activities
/rest/api/activitygraph
/rest/api/feedback
/rest/api/people
/rest/api/messageBoards
/rest/api/searchresults

ホスト識別子: リソースで使用するものと同じです。

4. 「保存」をクリックします。

5. 新しく作成したポリシーの「認証ルール」に移動し、認証スキームOraDefaultBasicAuthNSchemeを使用して新しいルールを追加します。

6. 「ポリシー」タブを開き、ポリシーが次の順序になっていることを確認します。
WebCenterRESTPolicy

Protected_JSessionId_Policy

デフォルトのパブリック・ポリシー

15.5.3.4 Oracle SESおよびポートレット用の除外ポリシーの作成

Oracle SES (Secure Enterprise Search)とポートレットの除外ポリシーを作成するには、次の手順を実行します。

1. 次の場所にあるOracle Access Managerコンソールにログインします。

http://OAM_HOST:OAM_ADMINSERVER_PORT/oamconsole

2. OAM 10gインストールでOraDefaultExclusionAuthNSchemeが利用可能であることを確認します。見つからない場合は、次に従ってOraDefaultExclusionAuthNSchemeを作成します。

1. 「認証管理」をクリックします。

2. 「追加」をクリックします。

3. 「名前」フィールドにOraDefaultExclusionAuthNSchemeを指定します。

4. 「説明」フィールドにTo exclude resources from being protected by OAMを入力します。

5. 「レベル」フィールドに0を入力します。

6. 「チャレンジ・メソッド」にNoneを指定します。

7. 「チャレンジ・パラメータ」フィールドに、unprotected:trueを追加します。

8. 「保存」をクリックします。

9. この認証スキームの「プラグイン」タブを開き、「変更」をクリックします。

10. ドロップ・ダウン・リストからcredential_mappingを選択します。

11. 値を次のように指定します。
obMappingBase="dc=us,dc=oracle,dc=com",obMappingFilter="(uid=OblixAnonymous)"

この値がOraDefaultAnonAuthNSchemeの対応するフィールドと一致することを確認します。

12. 「保存」をクリックします。

13. 再度「一般」タブを開き、「変更」をクリックします。

14. 「有効」に対しYesを選択します。

15. 「保存」をクリックします。

3. Exclusion Schemeという新しいポリシーを作成するには、次の手順を実行します。

1. ポリシー・ドメインを探します。
WebCenterRESTPolicy、Protected_JSessionId_PolicyおよびDefault Public Policyの3つのポリシーが表示されます。

2. 次に示す値を使用し、Exclusion Schemeという新しいポリシーを作成します。
説明: This policy excludes SES and portlet end points.

リソース・タイプ: http

リソース操作: GET,POST

リソース: 次のリソースを選択します。

/rsscrawl
/sesUserAuth
/services-producer/portlets
/wsrp-tools/portlets

ホスト識別子: リソースで使用するものと同じです。

3. 「保存」をクリックします。

4. 新しく作成したポリシーの「認証ルール」に移動し、認証スキームOraDefaultExclusionAuthNSchemeを使用して新しいルールを追加します。

5. 「保存」をクリックします。

4. 「ポリシー」タブを開き、ポリシーが次の順序になっていることを確認します。
WebCenterRESTPolicy

Exclusion Scheme

Protected_JSessionId_Policy

デフォルトのパブリック・ポリシー

15.5.3.5 ポリシー・ドメインおよびアクセス・ゲートを正常に作成したことの確認

ポリシー・ドメインとAccessGateの作成を検証する手順は2つの部分で構成されます。

ポリシー・ドメインを検証する手順は次のとおりです。

1. 次のURLを使用してアクセス・システム・コンソールにログオンします。

http://OAMADMINHOST:port/access/oblix

2. 「ポリシー・マネージャ」をクリックします。

3. 左側のパネルで「ポリシー・ドメイン」リンクをクリックします。
すべてのポリシー・ドメインのリストが表示されます。先ほど作成したドメインがここに表示されます。その接尾辞は_PD(たとえば、WebCenter_EDG_PD)となります。3番目の列「URL接頭辞」には、このドメインの作成時に指定したURIが表示されます。

4. 先ほど作成したポリシー・ドメインのリンクをクリックします。
このリンクから、このドメインの「一般」エリアに移動できます。

5. 「リソース」タブをクリックします。
指定したURIが表示されます。他のタブをクリックし、他の設定を表示することもできます。

AccessGate構成を検証する手順は次のとおりです。

1. 右上にある「アクセス・システム・コンソール」リンクをクリックします。
これはトグルのように機能し、クリックすると「ポリシー・マネージャ」リンクに切り替わります。

2. 「アクセス・システム構成」タブをクリックします。

3. 左のパネルにある「アクセス・ゲート構成」リンクをクリックします。

4. 検索条件にWebCenter_EDGと入力し(または第15.5.3.2項「OAM構成ツールの実行」でapp_domain名として使用した他のサブストリングなどを入力)、「実行」をクリックします。

5. 作成したドメインのアクセス・ゲートが表示されたら(アクセス・ゲートの接尾辞は_AGであるため、たとえばWebCenter_EDG_AGなど)、それをクリックすると作成したばかりのアクセス・ゲートの詳細が表示されます。

15.5.3.6 ホスト識別子の更新

OAM構成ツールは、app_domainパラメータの値を使用して(例: WebCenter_EDG)ポリシー・ドメインのホスト識別子を作成します。構成が正常に機能するためには、ホストに対するすべてのホスト名バリエーションを反映してホスト識別子を更新する必要があります。OAM構成ツールで作成したホスト識別子を更新する手順は次のとおりです。

1. 次のURLを使用してアクセス・システム・コンソールにログインします。

http://OAMADMINHOST:port/access/oblix

ここで、OAMADMINHOSTにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. ユーザー名とパスワードの入力を求められたら、管理者としてログインします。「OK」をクリックします。

3. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックします。

4. 「アクセス・システム・コンソール」ページで、「アクセス・システム構成」タブをクリックします。

5. 「アクセス・システム構成」ページで、左下にある「ホスト識別子」をクリックします。

6. 「すべてのホスト識別子をリスト」ページで、OAM構成ツールで作成したホスト識別子をクリックします。たとえば、「WebCenter_EDG」を選択します。

7. 「ホスト識別子詳細」ページで「変更」をクリックします。

8. アクセス・システム構成で使用される「優先HTTPホスト」の値を追加します。次のリストは、SSO/WebGateを使用する可能性のあるすべてのホスト名のバリエーションを示しています。

- webhost1.mydomain.com:7777

- webhost2.mydomain.com:7777

- wcphost1:9000

- wcphost2:9000

- wcphost1:9001

- wcphost2:9001

- wcphost1:9002

- wcphost2:9002

- wcphost1:9003

- wcphost2:9003

- admin.mycompany.com

- adminvhn.mycompany.com:7001

- soahost1vhn1:8001

- soahost2vhn1:8001

- soahost1vhn1:8010

- soahost2vhn1:8010

- adminvhn:7001

9. 「キャッシュの更新」の横にあるチェック・ボックスを選択し、「保存」をクリックします。
次のメッセージ・ボックスが表示されます: 「時点でキャッシュを更新すると、システム内のすべてのキャッシュがフラッシュされます。よろしいですか。」。

「OK」をクリックして、構成変更の保存を終了します。

10. 「ホスト識別子詳細」ページで変更内容を確認します。

15.5.3.7 WebGateプロファイルの更新

OAM構成ツールでは、app_domainパラメータの値で作成したWebGateプロファイルのPreferred_HTTP_Hostおよびホスト名属性に値が移入されます。正しく機能する構成とするには、この2つの属性の両方を適切な値で更新する必要があります。OAM CFGツールで作成したWebGateプロファイルを更新する手順は次のとおりです。

1. 次のURLを使用してアクセス・システム・コンソールにログインします。

http://OAMADMINHOST:port/access/oblix

ここで、OAMADMINHOSTにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。

3. 「アクセス・システム・コンソール」メイン・ページで、「アクセス・システム構成」をクリックし、左ペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

4. 適切な検索条件を入力して、「実行」をクリックし、アクセス・ゲートのリストを表示します。

5. OAM構成ツールで作成したアクセス・ゲートを選択します。たとえば、WebCenter_EDG_AGを選択します。

6. 「アクセス・ゲート詳細」ページで、「変更」を選択し、「アクセス・ゲートの変更」ページを表示します。

7. 「アクセス・ゲートの変更」ページで、次のように更新します。

- ホスト名: WebGateを実行しているコンピュータの名前にホスト名を更新します(webhost1.mycompany.comなど)。

- 優先HTTPホスト: 前述の項で指定したホスト名バリエーションの1つにPreferred_HTTP_Hostを更新します(admin.mycompany.com:80など)。

- プライマリHTTP Cookieドメイン: ドメインの接尾辞がホスト識別子(例: mycompany.com)であるプライマリHTTP Cookieドメインを更新します。

8. 「保存」をクリックします。「これらの変更をコミットしますか。」という内容のメッセージ・ボックスが表示されます。

9. 「OK」をクリックして、構成の更新を終了します。

10. 「アクセス・ゲートの詳細」ページに表示される値を確認し、正常に更新されたことを確認します。

15.5.3.8 アクセス・サーバーの追加

アクセス・サーバーをWebGateに割り当てるには:

1. 次のURLを使用し、Oracle Access Managerに管理者としてログインします。

http://OAMADMINHOST:port/access/oblix

ここで、OAMADMINHOSTにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 必要に応じて、「アクセス・ゲート」ページの「詳細」に移動します。「アクセス・システム・コンソール」から、「アクセス・システム構成」→「アクセス・ゲート構成」→WebGateへのリンク(WebCenter_EDG_AG)を選択します。

3. 「アクセス・ゲート」ページの「詳細」で、「アクセス・サーバーをリスト」をクリックします。

4. このWebGateに現在構成されているプライマリ・アクセス・サーバーまたはセカンダリ・アクセス・サーバーを示すページが表示されます。
「追加」をクリックします。

5. 「新規アクセス・サーバーの追加」ページで、「サーバーの選択」リストから「アクセス・サーバー」を選択して、「プライマリ・サーバー」を指定し、WebGateの「接続数」を増やします。たとえば接続数を1から2に増やします。

注意:

「接続数」は、アクセス・サーバーの総数以上である必要があります。アクセス・サーバーを追加するたびに、接続数を1ずつ増やします。

「追加」ボタンをクリックして関連付けを完了します。

6. アクセス・サーバーとWebGateの関連を示すページが表示されます。リンクをクリックしてサマリーを表示し、後で使用するためにこのページを印刷します。

7. 手順3から6を繰り返し、WebGateに定義したすべてのアクセス・サーバーを関連付けます。

15.5.3.9 委任フォーム認証の構成

OAMインストールとともにインストールしたWebGateにリダイレクトするようにフォーム認証を構成する手順は次のとおりです。

1. 「アクセス・システム・コンソール」を開きます。

2. 「アクセス・システム構成」画面で、左側のバーから「認証管理」を選択します。

3. 「OraDefaultFormAuthNScheme」を選択します。

4. 「変更」をクリックします。

5. 「チャレンジ・リダイレクト」フィールドで、IDMインストール用のOracle HTTP Serverのホストとポートを入力します(http://sso.mycompany.com:7777など)。

WebGateはIDMのインストール時にすでにインストールされているはずです。詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のWebGateのインストールおよび構成に関する説明を参照してください。

15.5.4 WebGateのインストールと構成

各WEBHOSTnマシンにWebGateをインストールし、Web層を保護するには、次の手順を実行します。

1. 次のコマンドを使用して、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: OAMアクセス・サーバー構成から報告されたID

- アクセス・サーバーのホスト名: OAMアクセス・サーバー構成から報告された名前

- アクセス・サーバーのポート番号: OAMアクセス・サーバー構成から報告された番号

注意:

アクセス・サーバーのID、ホスト名およびポートは、すべて入力が必須の項目です。

これらの詳細は、Oracle Access Manager管理者から取得できます。「次へ」をクリックして続行します。

図15-5 アクセス・サーバー構成画面

「図15-5 アクセス・サーバー構成画面」の説明

10. 「Webサーバーの構成」画面で「はい」をクリックすると、自動的にWebサーバーが更新されます。「次へ」をクリックして続行します。

11. 表示された「Webサーバーの構成」画面で、httpd.confファイルが格納されているディレクトリのフルパスを指定します。このファイルは、次のディレクトリにあります。

ORACLE_BASE/admin/OHS_Instance/config/OHS/OHS_ComponentName

次に例を示します。

ORACLE_BASE/admin/ohs_instance2/config/OHS/ohs2/httpd.conf

「次へ」をクリックして続行します。

12. 表示された「Webサーバーの構成」ページに、Webサーバー構成がWebGate向けに変更されたことを示すメッセージが示されます。「はい」をクリックして確認します。

13. Webサーバーをいったん停止してから再起動し、構成の更新を有効にします。「次へ」をクリックして続行します。

14. 表示された「Webサーバーの構成」画面に、次のメッセージが示されます: 「WebサーバーをSSLモードで設定する場合、SSL関連パラメータを使用してhttpd.confファイルを構成する必要があります。SSL構成を手動で調整するには、表示される指示に従ってください。」。「次へ」をクリックして続行します。

15. 表示された「Webサーバーの構成」画面に、製品設定とWebサーバーの構成の残りの部分に関する情報が記載されているドキュメントの場所を示すメッセージが表示されます。「いいえ」を選択し、「次へ」をクリックして続行します。

16. 最後の「Webサーバーの構成」画面が表示されます。Webサーバーの構成に関する詳細情報を得るには、手動でブラウザを起動し、該当のHTMLドキュメントを開くように指示するメッセージが表示されます。「次へ」をクリックして続行します。

17. 「Oracle COREid Readme」画面が表示されます。画面の情報を確認し、「次へ」をクリックして続行します。

18. 正常にインストールが完了したことを示すメッセージが、インストールの詳細とともに表示されます。

15.5.5 WebgateのIP検証の構成

IP検証により、クライアントのIPアドレスが、シングル・サインオン用に生成されてObSSOCookieに格納されたIPアドレスと同じかどうかが判定されます。IPターミネーションを実行するように構成されたロード・バランサ・デバイスを使用しているシステムにおいては、また認証するWebGateのフロントエンドのロード・バランサがエンタープライズ・デプロイメントのフロントエンドのロード・バランサと異なる場合は、IP検証で問題が発生することがあります。

このような場合に検証が行われないようにロード・バランサを構成する手順は次のとおりです。

1. 次のURLを使用して、アクセス・システム・コンソールに移動します。

http://OAMADMINHOST:port/access/oblix

OAMADMINHOSTにはWebPass Oracle HTTP Serverインスタンスを実行しているホストを指定し、portにはOracle HTTP ServerインスタンスのHTTPポートを指定します。

2. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。

3. 「アクセス・システム・コンソール」メイン・ページで、「アクセス・システム構成」をクリックし、左ペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

4. 適切な検索条件を入力して、「実行」をクリックし、アクセス・ゲートのリストを表示します。

5. Oracle Access Manager構成ツールで作成したアクセス・ゲートを選択します。

6. ページの一番下にある「変更」をクリックします。

7. 「IPValidationException」フィールドに、デプロイメントのフロントエンドに位置するロード・バランサのアドレスを入力します。

8. ページの一番下にある「保存」をクリックします。

15.5.6 WebLogic認証プロバイダの設定

この項では、WebLogic認証プロバイダの設定方法を説明します。

前提条件

LDAP認証プロバイダをまだ作成していない場合は、この項の作業を進める前に作成しておいてください。LDAP認証プロバイダを設定するには、第15.2.1項「LDAP認証プロバイダの作成」の手順を実行します。

この項の内容は次のとおりです。

- 第15.5.6.1項「構成ファイルのバックアップ」

- 第15.5.6.2項「OAM IDアサータの設定」

- 第15.5.6.3項「プロバイダの順序の設定」

15.5.6.1 構成ファイルのバックアップ

安全を期して、まず該当の構成ファイル(WebCenter Portalの管理サーバー・ディレクトリ下に格納)をバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/system-jazn-data.xml

管理サーバーのboot.propertiesファイルもバックアップします。

15.5.6.2 OAM IDアサータの設定

WebLogic Server管理コンソールを使用し、OAM IDアサータを構成します。

OAM IDアサータを設定するには:

1. WebLogic Serverの管理コンソールに管理者としてログインします。

2. 次の場所に移動します。

SecurityRealms\Default_Realm_Name\Providers

3. 「新規」をクリックし、ドロップダウン・メニューからOAMアイデンティティ・アサータを選択します。

4. アサータの名前(OAM ID Asserterなど)を入力し、「保存」をクリックします。

5. 新しく追加したアサータをクリックし、OAMアイデンティティ・アサータの構成画面を確認します。

6. 「制御フラグ」を「REQUIRED」に設定して、「保存」をクリックします。

7. 「選択したタイプ」にOAM_REMOTE_USERおよびObSSOCookieが設定されていることを確認します。

8. 設定を保存します。

15.5.6.3 プロバイダの順序の設定

プロバイダの順序を設定する手順は次のとおりです。

1. Oracle WebLogic Serverの管理コンソールに管理者としてログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. OAMアイデンティティ・アサータ、OID/OVD認証プロバイダおよびデフォルト認証プロバイダの制御フラグが次のように設定されていることを確認し、これらの認証プロバイダを並べ替えます。

- OAMアイデンティティ・アサータ: REQUIRED

- OID LDAP認証プロバイダ(またはOVD LDAP認証プロバイダ): SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

5. 「OK」をクリックします。

6. 「変更のアクティブ化」をクリックして変更を伝播します。

7. 管理サーバーとすべての管理対象サーバーを再起動します。

15.5.7 OAM 10gでの仮想ホストの構成

仮想ホスト用にOAM 10gを構成するには、基本的な認証のみをサポートする、またはシングル・サインオンを必要としないアプリケーションのみでシングル・サインオンをバイパスします。

詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドの仮想ホストでのSSOの構成に関する説明と10g用の『Oracle Access Managerアクセス管理者ガイド』のWebGateと特定の仮想ホスト、ディレクトリまたはファイルの関連付けに関する説明を参照してください。

1. httpd.confから次の構成を見つけ、コメント・アウトします。

#<LocationMatch "/*">
#AuthType Oblix
#require valid-user
#</LocationMatch>

このエントリによって、WebGateはすべての要求をインターセプトし、処理するようになります。

2. 仮想ホストの構成セクションを次のとおり編集します。

NameVirtualHost *:7777

<VirtualHost *:7777>
ServerName https://wcp.mycompany.com:443
<LocationMatch "/*">
AuthType Oblix
require valid-user
</LocationMatch>
</VirtualHost>

<VirtualHost *:7777>
ServerName admin.mycompany.com:80
<LocationMatch "/*">
AuthType Oblix
require valid-user
</LocationMatch>
</VirtualHost>

<VirtualHost *:7777>
ServerName wcpinternal.mycompany.com:80
<LocationMatch "/*">
AuthType Oblix
require valid-user
</LocationMatch>
</VirtualHost>

#Virtual host for SharePoint access
<VirtualHost *:7777>
ServerName wcp-spaces.mycompany.com
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

#SharePoint entry point
<Location />
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Spaces Application
<Location /webcenter>
Deny from all
</Location>

<Location /webcenterhelp>
Deny from all
</Location>

<Location /rss>
Deny from all
</Location>

<Location /rest>
Deny from all
</Location>

</VirtualHost>

3. Oracle HTTP Serverを再起動します。

15.6 Oracle Access Manager 11gの統合

この項では、Oracle WebCenter Portalエンタープライズ・デプロイメント・トポロジのシングル・サインオン・ソリューションとしてOracle Access Manager 11gを設定する方法について説明します。

この章の項目は次のとおりです。

- 第15.6.1項「Oracle Access Managerの統合の概要」

- 第15.6.2項「Oracle Access Managerの前提条件」

- 第15.6.3項「WebGateのインストール」

- 第15.6.4項「WebGateエージェントの登録」

- 第15.6.5項「WebLogicオーセンティケータのセットアップ」

- 第15.6.6項「OAM11gでの仮想ホストの構成」

15.6.1 Oracle Access Managerの統合の概要

Oracle Access Manager(OAM)は、Oracle Fusion Middleware 11g リリース1において推奨されるシングル・サインオン・ソリューションです。OAMのインストールおよび構成の詳細は、Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイドを参照してください。この項では、WebCenter Portalのインストールを構成して既存のOAM 11gインストールおよび基礎となるディレクトリ・サービスと連携させる手順について説明します。これらのディレクトリ・サービスには、Oracle Internet Directory (OID)またはOracle Virtual Directory (OVD)、またはその両方を使用することをお薦めします。

注意:

このマニュアルで説明するWebCenter Portalトポロジでは、WebCenter Portalシステムとシングル・サインオン・システムの両方が同じネットワーク・ドメイン(mycompany.com)にある、シングル・サインオン構成を使用します。マルチ・ドメイン構成については、『Oracle Access Managerアクセス管理ガイド』のシングル・サインオン構成に関する項に記載されている、必須の構成手順を参照してください。

15.6.2 Oracle Access Managerの前提条件

Oracle Access Manager(OAM)は、Oracle Fusion Middleware 11g リリース1において推奨されるシングル・サインオン・ソリューションです。OAMのインストールおよび構成の詳細は、Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイドを参照してください。この項では、WebCenter Portalのインストールを既存のOAM 11gインストールおよび基礎となるディレクトリ・サービスと構成する手順について説明します。これらのディレクトリ・サービスには、Oracle Internet Directory (OID)またはOracle Virtual Directory (OVD)、またはその両方を使用することをお薦めします。

注意:

このマニュアルで説明するWebCenter Portalトポロジでは、WebCenter Portalシステムとシングル・サインオン・システムの両方が同じネットワーク・ドメイン(mycompany.com)にある、シングル・サインオン構成を使用します。マルチ・ドメイン構成については、『Oracle Access Managerアクセス管理ガイド』のシングル・サインオン構成に関する項に記載されている、必須の構成手順を参照してください。

15.6.3 WebGateのインストール

この項では、HTTPサーバーがすでにインストールされている各WEBHOSTマシンにWebGateをインストールする方法を説明します。

- GCCライブラリのインストールの前提条件

- WebGateのインストール

- インストール後の手順

15.6.3.1 GCCライブラリのインストールの前提条件

WebGateをインストールする前に、マシンにサード・パーティ製GCCライブラリをダウンロードおよびインストールする必要があります。次のサードパーティWebサイトから該当するGCCライブラリをダウンロードできます。

http://gcc.gnu.org/

32ビットのLinuxの場合、必要なライブラリはバージョン3.3.2のlibgcc_s.so.1およびlibstdc++.so.5です。表15-3は、LinuxおよびSolarisのGCCサード・パーティ製ライブラリのバージョンを示しています。

表15-3 LinuxおよびSolarisのGCCサードパーティ製ライブラリのバージョン

オペレーティング・システム

アーキテクチャ

GCCライブラリ

必要なライブラリ・バージョン

Linux 32ビット

x86

libgcc_s.so.1

libstdc++.so.5

3.3.2

Linux 64ビット

x64

libgcc_s.so.1

libstdc++.so.6

3.4.6

Solaris 64ビット

SPARC

libgcc_s.so.1

libstdc++.so.5

3.3.2

15.6.3.2 WebGateのインストール

この項では、WebGateのインストール手順について説明します。

Oracle HTTP Server 11g Webgate for Oracle Access Managerのインストーラ・プログラムはwebgate.zipファイルに含まれています。

WebGateをインストールする手順は次のとおりです。

1. webgate.zipファイルのコンテンツを、ディレクトリに解凍します。
デフォルトでは、このディレクトリはwebgateと名前が付けられています。

2. webgateディレクトリの下のDisk1ディレクトリに移動します。

3. MW_HOME環境変数をWeb層のミドルウェア・ホームに設定します。

export MW_HOME=ORACLE_BASE/product/fmw/web

4. 次のコマンドを使用してインストーラを起動します。

$ ./runInstaller -jreLoc MW_HOME/jdk

注意:

Oracle HTTP Serverをインストールするときに、WebTier_Homeディレクトリの下にjdkディレクトリが作成されます。インストーラを起動するときに、このJDKの中にあるJREフォルダの絶対パスを入力する必要があります。

インストーラが起動すると、「ようこそ」画面が表示されます。

5. 「ようこそ」画面で、「次へ」をクリックします。

6. 「前提条件のチェック」画面で、「次へ」をクリックします。

7. 「インストール場所の指定」画面で、Oracleミドルウェア・ホームとOracleホームの場所を指定します。

- ORACLE_BASE/product/fmw

- Oracle_OAMWebGate1 (デフォルト名のまま)

注意:

ミドルウェア・ホームには、Oracle Web層のOracleホームが含まれます。このOracleホーム・ディレクトリのデフォルト名はOracle_OAMWebGate1で、これはミドルウェア・ホームの下に作成されます。

「次へ」をクリックします。

8. GCCライブラリの指定画面で、GCCライブラリが含まれているディレクトリを指定し、「次へ」をクリックします。

9. 「インストール・サマリー」画面で、画面に表示される情報を確認し、「インストール」をクリックしてインストールを開始します。

10. 「インストールの進行状況」画面で、ファイルおよびディレクトリに適切な権限を設定するために、ORACLE_HOME/oracleRoot.shスクリプトを実行するように求められる場合があります。
「次へ」をクリックして続行します。

11. 「インストール完了」画面で、「終了」をクリックし、インストーラを終了します。

15.6.3.3 インストール後の手順

Oracle HTTP Server 11g Webgate for Oracle Access Managerのインストール後に次の手順を実行します。

1. WebgateのOracleホームの下にある次のディレクトリに移動します。

$ cd Webgate_Oracle_Home/webgate/ohs/tools/deployWebGate

Webgate_Oracle_Homeは、次の例のように、Oracle HTTP Server Webgateをインストールし、WebgateのOracleホームとして作成したディレクトリです。

MW_HOME/Oracle_OAMWebGate1

2. コマンド・ラインで次のコマンドを実行し、Webgate_Oracle_HomeディレクトリからWebgateインスタンスの場所に必要なエージェント・ビットをコピーします。

$ ./deployWebGateInstance.sh -w ORACLE_BASE/admin/webN/config/OHS/ohsN
-oh Webgate_Oracle_Home

ORACLE_BASE/admin/webN/config/OHS/ohsNディレクトリは、Oracle HTTP Serverのインスタンス・ホームになります(Nはインストールごとに付される連番で、1番目はWEBHOST1、2番目はWEBHOST2などとなります)。

注意:

Oracle HTTP Serverのインスタンス・ホームは、Oracle HTTP Serverを構成した後に作成されます。

3. 次のコマンドを実行し、LD_LIBRARY_PATH変数にOracle_Home_for_Oracle_HTTP_Server/libが含まれるようにします。

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:ORACLE_BASE/product/fmw/webN/lib

注意:

Oracle_Home_for_Oracle_HTTP_ServerはMW_HOME(Web層)です。

ORACLE_BASE/product/fmw/webN

ここでNは、WEBHOST1には1、WEBHOST2には2などインストール上の連番を示します。

4. 現在の作業ディレクトリから1つ上のディレクトリに移動します。

$ cd Webgate_Oracle_Home/webgate/ohs/tools/setup/InstallTools

5. コマンド・ラインで次のコマンドを実行して、Webgate_Oracle_HomeディレクトリからWebgateインスタンスの場所にapache_webgate.templateをコピーし(名前がwebgate.confに変更されます)、httpd.confファイルを更新してwebgate.confの名前が含まれる1つの行を追加します。

$ ./EditHttpConf -w ORACLE_BASE/admin/webN/config/OHS/ohsN [-oh Webgate_Oracle_Home] [-o output_file]

注意:

-oh WebGate_Oracle_Homeおよび-o output_fileパラメータはオプションです。

ここでWebGate_Oracle_Homeは、Oracle HTTP Server Webgate for Oracle Access Managerをインストールし、WebgateのOracleホームを作成したディレクトリです。次に例を示します。

MW_HOME/Oracle_OAMWebGate1

ORACLE_BASE/admin/webN/config/OHS/ohsNディレクトリは、Oracle HTTP Serverのインスタンス・ホームになります(Nはインストールごとに付される連番で、1番目はWEBHOST1、2番目はWEBHOST2などとなります)。

output_fileはツールによって使用される一時出力ファイルの名前です。次に例を示します。

Edithttpconf.log

15.6.4 WebGateエージェントの登録

この項では、WebGateエージェントの登録手順について説明します。

- RREGツール

- OAM11gRequestファイルの更新

- oamregツールの実行

- WEBHOSTへのアクセス・ファイルのコピー

- RESTポリシーの更新

15.6.4.1 RREGツール

RREGツールはOAM 11gのインストールの一部です。見つからない場合は、次の手順を使用して抽出します。

1. Oracle Access Managerのインストールおよび構成が終わった後、次の場所に移動します。

IDM_Home/oam/server/rreg/client

2. 次の例に示すように、コマンド・ラインでgunzipを使用してRREG.tar.gzファイルを展開します。

gunzip RREG.tar.gz

tar -xvf RREG.tar

エージェントを登録するためのツールは次の場所にあります。

RREG_Home/bin/oamreg.sh

RREG_Homeは、RREG.tar.gz/rregの内容を展開したディレクトリです。

oamreg.shまたはoamreg.batスクリプトの次の環境変数を設定します。

- OAM_REG_HOME - この変数を、RREG.tar/rregの中身を展開したディレクトリへの絶対パスに設定します。

- JDK_HOME - この変数を、JavaまたはJDKがマシンにインストールされているディレクトリへの絶対パスに設定します。

15.6.4.2 OAM11gRequestファイルの更新

RREG_Home/inputディレクトリの中に、OAM11gRequest.xmlという名前のテンプレート・ファイルがあります。このファイルをコピーおよび編集して、WebCenter Portalインストールのポリシーを作成します。

1. RREG_Home/inpuにあるテンプレートOAM11gRequest.xmlファイルを開きます。

2. 例15-1のWebCenter Portalエンタープライズ・デプロイメントに必要なポリシーをコピーします。

3. 次の値を置き換えます。

- $$webtierhost$$、$$oamadminserverport$$および$$oamhost$$を、実際のインストールのホスト名に置換します。

- ipvalidationExceptions値をロード・バランサのIPアドレスにします。

注意:

このマニュアルでは、Oracle Access Manager 11g (11.1.1.2)以降のリクエスト・ファイルの検証フィールドのエントリについて説明します。以前のバージョンのOracle Access Manager 11gでは、検証例外リストの定義方法が異なります。以前のバージョンでは、前のテキストに示されているように<ValList>エントリを使用するかわりに、</publicResourcesList>エントリの後で次の構文を使用します。

<userDefinedParameters>
<userDefinedParam>
<name>ipValidationExceptions</name>
<value>10.1.1.1</value>
</userDefinedParam>
</userDefinedParameters>

IP検証例外の追加の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』を参照してください。

4. 変更を保存します。

5. oamreg.shスクリプトの実行権限を追加します。

chmod u+x /RREG_Home/bin/oamreg.sh

例15-1 WebCenter Portalエンタープライズ・デプロイメント用のOAM11gRequest.xml

OAM11gRequest.xmlの編集後、ファイルには次が含まれている必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
NAME: OAM11GRequest_short.xml - Template for OAM 11G Agent Registration request file
(Shorter version - Only mandatory values - Default values will be used for all other fields)
DESCRIPTION: Modify with specific values and pass file as input to the tool.
-->
<OAM11GRegRequest>
<serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress>
<hostIdentifier>$$webtierhost$$_webcenter</hostIdentifier>
<agentName>$$webtierhost$$_webcenter</agentName>
<applicationDomain>$$webtierhost$$_webcenter</applicationDomain>
<ipValidation>1</ipValidation>
<ValList ListName="ipValidationExceptions">
<ValListMember Value="10.1.1.1"/>
<logOutUrls>
<url>/oamsso/logout.html</url>
</logOutUrls>
<protectedResourcesList>
<resource>/webcenter/adfAuthentication</resource>
<resource>/integration/worklistapp</resource>
<resource>/integration/worklistapp/.../*</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow</resource>
<resource>/workflow/WebCenterWorklistDetail/faces/adf.task-flow</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist</resource>
<resource>/workflow/sdpmessagingsca-ui-worklist/.../*</resource>
<resource>/sdpmessaging/userprefs-ui</resource>
<resource>/sdpmessaging/userprefs-ui/.../*</resource>
<resource>/rss/rssservlet</resource>
<resource>/owc_discussions/login!withRedirect.jspa</resource>
<resource>/owc_discussions/login!default.jspa</resource>
<resource>/owc_discussions/login.jspa</resource>
<resource>/owc_discussions/admin</resource>
<resource>/owc_discussions/admin/.../*</resource>
<resource>/rest/api/resourceIndex</resource>
<resource>/rest/api/spaces</resource>
<resource>/rest/api/spaces/.../*</resource>
<resource>/rest/api/discussions</resource>
<resource>/rest/api/discussions/.../*</resource>
<resource>/rest/api/tags</resource>
<resource>/rest/api/tags/.../*</resource>
<resource>/rest/api/taggeditems</resource>
<resource>/rest/api/taggeditems/.../*</resource>
<resource>/rest/api/activities</resource>
<resource>/rest/api/activities/.../*</resource>
<resource>/rest/api/activitygraph</resource>
<resource>/rest/api/activitygraph/.../*</resource>
<resource>/rest/api/feedback</resource>
<resource>/rest/api/feedback/.../*</resource>
<resource>/rest/api/people</resource>
<resource>/rest/api/people/.../*</resource>
<resource>/rest/api/messageBoards</resource>
<resource>/rest/api/messageBoards/.../*</resource>
<resource>/rest/api/searchresults</resource>
<resource>/rest/api/searchresults/.../*</resource>
<resource>/activitygraph-engines</resource>
<resource>/activitygraph-engines/.../*</resource>
<resource>/wcps/api</resource>
<resource>/wcps/api/.../*</resource>
<resource>/adfAuthentication</resource>
<resource>/pagelets/admin</resource>
<resource>/pagelets/admin/.../*</resource>
<resource>/pagelets/authenticateWithApplicationServer</resource>
<resource>/services-producer/adfAuthentication</resource>
<resource>/em</resource>
<resource>/em/…/*</resource>
<resource>/console</resource>
<resource>/console/…/*</resource>
<resource>/soa/composer</resource>
<resource>/soa/composer/…/*</resource>
<resource>/soa-infra</resource>
<resource>/soa-infra/deployer</resource>
<resource>/soa-infra/deployer/…/*</resource>
<resource>/soa-infra/events/edn-db-log</resource>
<resource>/soa-infra/events/edn-db-log/…/*</resource>
<resource>/soa-infra/cluster/info</resource>
<resource>/soa-infra/cluster/info/…/*</resource>
<resource>/inspection.wsil</resource>
<resource>/cs/idcplg</resource>
<resource>/cs/idcplg/…/*</resource>
<resource>/cs/groups</resource>
<resource>/cs/groups/…/*</resource>
<resource>/ibr/adfAuthentication</resource>
<resource>/ibr/adfAuthentication/…/*</resource>
</protectedResourcesList>
<publicResourcesList>
<resource>/webcenter</resource>
<resource>/webcenter/…/*</resource>
<resource>/owc_discussions</resource>
<resource>/owc_discussions/…/*</resource>
<resource>/rss</resource>
<resource>/rss/…/*</resource>
<resource>/workflow</resource>
<resource>/workflow/…/*</resource>
<resource>/rest/api/cmis/…/*</resource>
<resource>/pagelets</resource>
<resource>/services-producer</resource>
<resource>/wsrp-tools</resource>
<resource>/cs</resource>
<resource>/cs/…/*</resource>
<resource>/ibr</resource>
<resource>/ibr/…/*</resource>
<resource>/soa-infra/services/…/*</resource>
<resource>/soa-infra/directWSDL</resource>
<resource>/integration/services</resource>
<resource>/integration/services/…/*</resource>
<resource>/ucs/messaging/webservice</resource>
<resource>/ucs/messaging/webservice/…/*</resource>
<resource>/wsm-pm</resource>
<resource>/wsm-pm/.../*</resource>
</publicResourcesList>
<excludedResourcesList>
<resource>/rsscrawl*</resource>
<resource>/rsscrawl/.../*</resource>
<resource>/sesUserAuth*</resource>
<resource>/sesUserAuth/.../*</resource>
<resource>/services-producer/portlets*</resource>
<resource>/services-producer/portlets/.../*</resource>
<resource>/wsrp-tools/portlets*</resource>
<resource>/wsrp-tools/portlets/.../*</resource>
</excludedResourcesList>

</OAM11GRegRequest>

注意:

WebCenter Portal、SOAおよびWebCenter Contentにはそれぞれ、公開および保護されたURIの要件がリストされた.confファイルがあります。次のprotected_uris=とpublic_uris=の構文を使用して、公開および保護URIを指定するかわりに、構文uris_file=を使用して各ファイルを順に参照できます。詳細および手順は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのWebCenter Portalのポリシー・ドメインの構成に関する説明を参照してください。

15.6.4.3 oamregツールの実行

1. 次のコマンドを使用し、oamregツールを実行します。

$ ./RREG_Home/bin/oamreg.sh inband input/WebCenterOAM11GRequest.xml

2. エージェントの資格証明が求められたら、自身のOAM管理者資格証明を入力します。
実行時の出力は次のようになります。

------------------------------------------------
Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: MW_HOME/Oracle_IDM1/oam/server/rreg/input/WebCenterOAM11gRequest.xml
Enter your agent username:weblogic
Username: weblogic
Enter agent password:
Do you want to enter a Webgate password?(y/n):
y
Enter webgate password:
Enter webgate password again:
Password accepted. Proceeding to register..
Aug 16, 2010 1:22:30 AM oracle.security.am.engines.rreg.client.handlers.request.OAM11GRequestHandler getWebgatePassword
INFO: Passwords matched and accepted.
Do you want to import an URIs file?(y/n):
n
----------------------------------------
Request summary:
OAM11G Agent Name:WEBHOST1_webcenter
URL String:WEBHOST1_webcenter
Registering in Mode:inband
Your registration request is being been sent to the Admin server at: http://oamserver.mycompany.com:7001
----------------------------------------
Inband registration process completed successfully! Output artifacts are created in the output folder.

15.6.4.4 WEBHOSTへのアクセス・ファイルのコピー

RREG_Home/output/$$webtierhost$$_webcenterの中に次の2つのファイルが生成されます。

- ObAccessClient.xml

- cwallet.sso

両方のファイルをWEBHOST1およびWEBHOST2上のWebGateインスタンスにコピーするには、次の手順を実行します。

1. ObAccessClient.xmlおよびcwallet.ssoをWEBHOST1とWEBHOST2上のWebGateインスタンス・ディレクトリにコピーします。
次に例を示します。

scp ObAccessClient.xml oracle@WEBHOSTN:ORACLE_BASE/admin/webN/config/OHS/ohsN/webgate/config/

ここでNは、WEBHOST1には1、WEBHOST2には2などインストール上の連番を示します。

2. Oracle HTTP Serverを再起動します。

15.6.4.5 RESTポリシーの更新

OutlookプラグインやiPhoneアプリケーションなどの外部クライアントが、SSOで保護されているWebCenter RESTに接続することができるよう、RESTはBASIC認証スキームに従う必要があります。

基本の認証を使用するようにRESTエンド・ポイントを構成するには、次の手順を実行します。

1. http://OAM_HOST:OAM_ADMINSERVER_PORT/oamconsoleにあるOracle Access Managerコンソールにログインします。

2. 前の手順で作成および検証したポリシー・ドメインを見つけ、「ポリシー」タブを開きます。

3. 「アプリケーション・ドメイン」→「$$webtierhost$$_webcenter」→「認証ポリシー」に移動します。

4. 「WebCenter REST Auth Policy」という新しいポリシーを作成し、基本スキームとして「認証スキーム」を選択します。

5. 「アプリケーション・ドメイン」→「$$webtierhost$$_webcenter」→「リソース」に移動します。

6. すべてのRESTリソースを検索します。/rest*と「リソースURL」フィールドに入力し、「検索」をクリックします。

7. /rest/api/cmisエントリを除く各RESTリソースを編集し、「認証ポリシー」を「保護されたリソース・ポリシー」から「WebCenter RESET認証ポリシー」に変更します。

図15-6 基本認証を使用したRESTエンド・ポイントの構成

次のエントリを確認できます。

/rest/api/resourceIndex
/rest/api/resourceIndex/.../*
/rest/api/spaces
/rest/api/spaces/.../*
/rest/api/discussions
/rest/api/discussions/.../*
/rest/api/tags
/rest/api/tags/.../*
/rest/api/taggeditems
/rest/api/taggeditems/.../*
/rest/api/activities
/rest/api/activities/.../*
/rest/api/activitygraph
/rest/api/activitygraph/.../*
/rest/api/feedback
/rest/api/feedback/.../*
/rest/api/people
/rest/api/people/.../*
/rest/api/messageBoards
/rest/api/messageBoards/.../*
/rest/api/searchresults
/rest/api/searchresults/.../*

15.6.5 WebLogic認証プロバイダの設定

構成ファイルのバックアップ、OAM IDアサータの設定およびプロバイダの順序設定によって、WebLogic認証プロバイダを設定します。

前提条件

WebLogicの認証プロバイダを設定する前に、第15.2.1項「LDAP認証プロバイダの作成」の手順に従ってLDAP認証プロバイダをすでに設定している必要があります。まだLDAP認証プロバイダを作成していない場合は、それを作成してからこの項の続きを実行してください。

この項の内容は次のとおりです。

- 第15.6.5.1項「構成ファイルのバックアップ」

- 第15.6.5.2項「OAM IDアサータの設定」

- 第15.6.5.3項「プロバイダの順序の設定」

15.6.5.1 構成ファイルのバックアップ

安全を期して、まず該当の構成ファイル(WebCenter Portalの管理サーバー・ディレクトリ下に格納)をバックアップします。

ORACLE_BASE/admin/domain_name/aserver/domain_name/config/config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig/jps-config.xml
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fwmconfig/system-jazn-data.xml

また、管理サーバーのboot.propertiesファイルもバックアップします。

15.6.5.2 OAM IDアサータの設定

OAM IDアサータを設定するには:

1. Oracle WebLogicコンソールの管理者としてログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→「Default Realm Name」→「プロバイダ」に移動します。

4. 「新規」をクリックし、ドロップダウン・メニューから「OAMアイデンティティ・アサータ」を選択します。

5. アサータの名前(OAM ID Asserterなど)を入力し、「保存」をクリックします。

6. 新しく追加したアサータをクリックし、OAMアイデンティティ・アサータの構成画面を確認します。

7. 制御フラグを「必須」に設定します。

8. 「選択済み」タイプで「ObSSOCookie」および「OAM_REMOTE_USER」の2つのオプションを選択します。

9. 設定を保存します。

10. 「変更の適用」をクリックします。

11. 最後に、WLSTを使用しWebLogicドメインに接続し、次のコマンドを実行してOAM SSOプロバイダを追加します。

addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", logouturi="oamsso/logout.html")

15.6.5.3 プロバイダの順序の設定

WebLogic管理コンソールを使用してプロバイダの順序を設定します。

プロバイダの順序を設定する手順は次のとおりです。

1. Oracle WebLogicコンソールの管理者としてログインします。

2. 「ロックして編集」をクリックします。

3. 「SecurityRealms」→デフォルト・レルム名→「Providers」に移動します。

4. OAMアイデンティティ・アサータ、OID/OVD認証プロバイダおよびデフォルト認証プロバイダの制御フラグが次のように設定されていることを確認し、これらの認証プロバイダを並べ替えます。

- OAMアイデンティティ・アサータ: REQUIRED

- OID LDAP認証プロバイダ(またはOVD LDAP認証プロバイダ): SUFFICIENT

- デフォルト認証プロバイダ: SUFFICIENT

5. 「OK」をクリックします。

6. 「変更のアクティブ化」をクリックして変更を伝播します。

7. 管理サーバーとすべての管理対象サーバーを再起動します。

15.6.6 OAM11gでの仮想ホストの構成

仮想ホスト用にOAM 11gを構成するには、基本認証のみをサポートする、またはシングル・サインオンを必要としないアプリケーションのみでシングル・サインオンをバイパスします。

OAM 11gで仮想ホストを構成するには:

1. webgate.confから次の場所を見つけ、コメント・アウトします。

#<LocationMatch "/*">
#AuthType Oblix
#require valid-user
#</LocationMatch>

このエントリによって、WebGateはすべての要求をインターセプトし、処理するようになります。

2. "Default Login page alias"のエントリがwebgate.confにある場合、これもコメント・アウトします。

#*******Default Login page alias***
#Alias /oamsso "${ORACLE_HOME}/oamsso"
#<LocationMatch "/oamsso/*">
#Satisfy any
#</LocationMatch>
#**********************************

3. 仮想ホストの構成セクションを次のとおり編集します。

NameVirtualHost *:7777

<VirtualHost *:7777>
ServerName https://wcp.mycompany.com:443
<LocationMatch "/*">
AuthType Oblix
require valid-user
</LocationMatch>
</VirtualHost>

<VirtualHost *:7777>
ServerName admin.mycompany.com:80
<LocationMatch "/*">
AuthType Oblix
require valid-user
</LocationMatch>
</VirtualHost>

<VirtualHost *:7777>
ServerName wcpinternal.mycompany.com:80
<LocationMatch "/*">
AuthType Oblix
require valid-user
</LocationMatch>
</VirtualHost>

#Virtual host for SharePoint access
<VirtualHost *:7777>
ServerName wcp-spaces.mycompany.com
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

#SharePoint entry point
<Location />
WebLogicCluster WCPHOST1:9000,WCPHOST2:9000
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Spaces Application
<Location /webcenter>
Deny from all
</Location>

<Location /webcenterhelp>
Deny from all
</Location>

<Location /rss>
Deny from all
</Location>

<Location /rest>
Deny from all
</Location>

</VirtualHost>

4. Oracle HTTP Serverを再起動します。

15.7 SSO用のWebCenter Portalアプリケーションの構成

この項の内容は次のとおりです。

- 第15.7.1項「WebCenter Portal: Spaces用のシステム・プロパティの構成」

- 第15.7.2項「WebCenter Portal: Spaces管理者ロールの構成」

- 第15.7.3項「ディスカッション・サーバーでSSOプロバイダとしてOAMを使用するための設定」

15.7.1 WebCenter Portal: Spaces用のシステム・プロパティの構成

EXTRA_JAVA_PROPERTIESに設定を追加し、SSO用にSpacesアプリケーションを構成します。

システム・プロパティoracle.webcenter.spaces.ossoにより、アプリケーションがSSOモードで構成されているために特殊な処理が必要であることをWebCenter PortalとADFは通知されます。次のシステム・プロパティが必要です。

表15-4 システム・プロパティ

プロパティ

値

コメント

oracle.webcenter.spaces.osso

true

このフラグは、SSOが使用されているためにデフォルトのランディング・ページにログイン・フォームが表示されないことをWebCenter Portalに通知します。かわりに、ユーザーがクリックするとSSO認証が起動するログイン・リンクが表示されます。

WCPHOST1およびWCPHOST2でSpacesアプリケーション用にこのプロパティを設定するには、managedserver_domain_home/binディレクトリにあるsetDomainEnv.shスクリプトを編集します。次のように、このプロパティをEXTRA_JAVA_PROPERTIES変数に追加します。

EXTRA_JAVA_PROPERTIES="-Doracle.webcenter.spaces.osso=true ${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES

15.7.2 WebCenter Portal: Spaces管理者ロールの構成

SpacesアプリケーションでOracle Internet DirectoryまたはOracle Virtual DirectoryをSpacesアプリケーションのプライマリ認証プロバイダに構成したら、デフォルトのweblogicユーザーはSpaces管理者として使用しないようにする必要があります。Oracle Internet Directoryにユーザーを作成し、WLSTまたはEnterprise Managerを使用して、そのユーザーをSpaces管理者にします。

- 第15.7.2.1項「WLSTを使用したSpaces管理者ロールの付与」

- 第15.7.2.2項「Fusion Middleware Controlを使用したSpaces管理者ロールの付与」

15.7.2.1 WLSTを使用したSpaces管理者ロールの付与

WLSTを使用してSpaces管理者ロールを付与する手順は、次のとおりです。

1. WebCenter Portal Oracleホーム・ディレクトリに移動し、WLSTスクリプトを起動します。
(UNIX) MW_HOME/wc/common/bin/wlst.sh

(Windows) MW_HOME\wc\common\bin\wlst.cmd

2. 次のコマンドを使用し、ターゲット・ドメインの管理サーバーに接続します。

wls:/offline>connect("user_name","password", "host_name:port_number")

説明:

- user_nameは、管理サーバーにアクセスするユーザーのアカウント名です(例: weblogic)

- passwordは、管理サーバーにアクセスするパスワードです

- host_idは、管理サーバーのホストIDです

- portは、管理サーバーのポート番号です(例: 7001)

3. LDAPストアにWCAdminという名前のユーザーを作成します。
このユーザーに、Spaces管理者ロールが付与されます。

4. grantAppRoleコマンドを使用し、LDAPのユーザーにSpaces管理者アプリケーション・ロールを付与します。
次に例を示します。

grantAppRole(appStripe="webcenter", appRoleName="s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator",
principalClass="weblogic.security.principal.WLSUserImpl", principalName="WCAdmin")

ここで、WCAdminは管理者アカウントの名前です。

注意:

grantAppRoleが呼び出される前に、LDAPにはWCAdminが存在している必要があります。ユーザーの作成に関する詳細は、第15.2.2.1項「LDAPディレクトリでの管理ユーザーおよびグループのプロビジョニング」を参照してください。

5. 新しいアカウントをテストするには、新しいアカウント名を使用してSpacesにログインします。
「管理」リンクが表示され、すべての管理操作を実行できるようになります。

15.7.2.2 Fusion Middleware Controlを使用したSpaces管理者ロールの付与

この項では、デフォルトのweblogicアカウント以外のユーザー・アカウントにSpaces管理者ロールを付与する方法を説明します。

Fusion Middleware Controlを使用してSpaces管理者ロールを付与するには、次の手順を実行します。

1. Fusion Middleware Controlにログインし、Spacesのホーム・ページに移動します。

2. 「WebCenter Portal」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。
「アプリケーション・ロール」ページが表示されます。

3. Spaces管理者ロールを検索します。

1. 「検索するアプリケーション・ストライプの選択」チェック・ボックスを選択します。

2. webcenter (Spacesアプリケーションの名前)を選択します。

3. 「ロール名」フィールドにs8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administratorと入力し、「検索」(矢印)アイコンをクリックします。

4. 「ロール名」列で管理者ロール名(s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator)をクリックします。
「アプリケーション・ロールの編集」ページが表示されます。

5. 「ユーザーの追加」をクリックします。
「ユーザーの追加」ポップアップが表示されます。

6. 検索機能を使用して、管理者ロールを割り当てるユーザーを検索します。

7. 矢印キーを使用して、「使用可能なユーザー」列から「選択したユーザー」列にユーザーを移動し、「OK」をクリックします。

8. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

9. WC_Spaces管理対象サーバーを再起動します。
Spacesアプリケーションにログインすると、管理のためのリンクが表示され、管理操作をすべて実行できるようになります。

15.7.3 ディスカッション・サーバーでSSOプロバイダとしてOAMを使用するための設定

この項の内容は次のとおりです。

- 第15.7.3.1項「ディスカッション・サーバーでの管理者権限の付与」

- 第15.7.3.2項「ディスカッション・サーバー用のシステム・プロパティの構成」

15.7.3.1 ディスカッション・サーバーでの管理者権限の付与

ドメインをAdministratorsグループを含まないアイデンティティ・ストアに関連付ける場合、ディスカッション・サーバー用に他の有効なユーザーまたはグループを割り当てる必要があります。

addDiscussionsServerAdminのWLSTコマンドを使用すると、ユーザーまたはグループにディスカッション・サーバーのシステム管理者権限を付与できます。コマンド構文や例の詳細は、Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのaddDiscussionsServerAdminに関する説明を参照してください。

次に例を示します。

1. 管理サーバーに接続します。
次に例を示します。

cd MW_HOME/wc/common/bin/
./wlst.sh

connect("weblogic","weblogic", "ADMINHOST:7001")

2. ユーザーまたはグループに管理者権限を付与します。

addDiscussionsServerAdmin(appName='owc_discussions', name='weblogic_wc', type='USER', server='wc_collaboration1')

または、

addDiscussionsServerAdmin(appName='owc_discussions', name='discussions-admin-group', type='GROUP', server='wc_collaboration1')

ここで、weblogic_wcとdiscussions-admin-groupは、ディスカッション・サーバーに割り当てる管理者ロールのユーザーおよびグループ例です。

コマンド構文や例の詳細は、Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのaddDiscussionsServerAdminに関する説明を参照してください。

15.7.3.2 ディスカッション・サーバー用のシステム・プロパティの構成

Oracle WebCenterディスカッション・サーバーをOAMシングル・サインオン用に構成するには:

1. 次の場所でOracle WebCenterディスカッション・サーバーの管理コンソールにログインします。
http://wcpinternal.mycompany.com/owc_discussions/admin

2. 「システム・プロパティ」ページを開き、「owc_discussions.sso.mode」プロパティを編集(このプロパティがすでに存在する場合)または追加して、その値を「true」に設定します。

3. SSOサーバーのWeb層のベースURLをポイントするjiveURLプロパティを編集または追加します。次に例を示します。

jiveURL = idmhost.example.com:8890/owc_discussions

15.8 WebCenter PortalおよびBPEL認証の構成

この項の内容は次のとおりです。

- 第15.8.1項「認証プロバイダの検証」

- 第15.8.2項「soa-infraのBPMWorkflowAdminアプリケーション・ロールのロール・メンバーの設定」

- 第15.8.3項「SOAコールバックURLの構成」

15.8.1 認証プロバイダの検証

SOAドメインでWebCenter Portalドメインと同じ認証プロバイダが使用され、OAM認証が構成されていることを検証します。

15.8.2 soa-infraのBPMWorkflowAdminアプリケーション・ロールのロール・メンバーの設定

デフォルト・ユーザーweblogicを含まないアイデンティティ・ストアにドメインを関連付ける場合、他の有効なユーザーをアプリケーション・ロール、BPMWorkflowAdminに割り当てる必要があります。

BPMWorkflowAdminを有効なユーザーに割り当てるには、次の手順を実行します。

1. LDAPストアに、ロールの割り当てを行うユーザー(この例では、WCAdmin)を作成します。

2. WLSTを使用し、BPMWorkflowAdminロールを割り当てます。この作業は、SOAのOracleホームからWLSTを使用して実行できます。
次に例を示します。

cd ORACLE_HOME/common/bin/
wlst.sh

connect("weblogic","weblogic", "ADMINHOST:7001")
revokeAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin",
principalClass="oracle.security.jps.service.policystore.ApplicationRole", principalName="SOAAdmin")
grantAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin",
principalClass="weblogic.security.principal.WLSUserImpl", principalName="WCAdmin")

15.8.3 SOAコールバックURLの構成

Oracle Access Managerが有効な時にワークリスト・サービスが正常に機能するには、SOAコールバックURLが必ず正しく構成されている必要があります。コールバックURLの詳細は、第9.7.3項「フロントエンドHTTPホストおよびポートの設定」を参照してください。

SOAアプリケーションについては、次のコールバックURLがhttp://wcpinternal.mycompany.comに設定されている必要があります。

- コールバック・サーバーURL

- サーバーURL

Fusion Middleware Controlを使用し、これらのURLを変更するには、次の手順を実行します。

1. 「Farm_wcpedg_domain」→「SOA」→「soa-infra (wls_soa1)」→「SOA」→「インフラストラクチャ」→「SOA管理」→「共通プロパティ」を選択します。

2. http://wcpinternal.mycompany.comと入力します。

3. SOAサーバーを再起動します。

15.9 アイデンティティ管理構成のバックアップ

拡張したドメインが正常に動作していることを確認した後、そのドメイン構成をバックアップします。このバックアップは、この後の手順でエラーが発生した場合にすぐにリストアできるようにすることが目的です。構成をローカル・ディスクにバックアップします。エンタープライズ・デプロイメントが完了すれば、このバックアップは破棄してかまいません。エンタープライズ・デプロイメントが完了すれば、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

環境のバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。情報のリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

この時点で構成をバックアップする手順は次のとおりです。

1. Web層をバックアップする手順は次のとおりです。

1. opmnctlを使用してインスタンスを停止します。

ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

2. 次のコマンドをroot権限で実行して、Web層のミドルウェア・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

3. 次のコマンドをroot権限で実行して、Web層のインスタンス・ホームをバックアップします。

tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE

4. opmnctlを使用してインスタンスを起動します。

ORACLE_BASE/admin/instance_name/bin/opmnctl startall

2. データベースのバックアップを取ります。これは、Oracle Recovery Manager(推奨)またはtarなどのOSツールを使用したデータベース全体のホット・バックアップまたはコールド・バックアップです。OSツールを使用する場合は、可能なかぎりコールド・バックアップをお薦めします。

3. 管理サーバーのドメイン・ディレクトリをバックアップしてドメイン構成を保存します。構成ファイルは次のディレクトリにあります。

ORACLE_BASE/ admin/domain_name

管理サーバーをバックアップするには、SOHOST1で次のコマンドを実行します。

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

16 エンタープライズ・デプロイメント用のトポロジの管理

この章では、トポロジを設定した後に実行できる操作について説明します。この操作には、トポロジの監視、スケーリングおよびバックアップがあります。

この章の内容は次のとおりです。

- 第16.1項「トポロジの管理および監視の概要」

- 第16.2項「SOAインフラストラクチャ・データベースでのスペースの管理」

- 第16.3項「UMSドライバの構成」

- 第16.4項「トポロジのスケール・アップ(管理対象サーバーを既存ノードに追加)」

- 第16.5項「トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)」

- 第16.6項「WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行」

- 第16.7項「SQLNet接続のタイムアウト防止」

- 第16.8項「Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング」

16.1 トポロジの管理および監視の概要

WebCenter Portalエンタープライズ・デプロイメントを構成したら、この章の情報を使用してトポロジを管理します。

トポロジの監視とWebCenter Portalアプリケーションの詳細は、Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイドのOracle WebCenter Portalのパフォーマンスの監視に関する説明を参照してください。

スケール・アップやスケール・アウトなどの方法で、トポロジの拡張が必要になることがあります。スケール・アップとスケール・アウトの違いおよびこれらのタスクの実行方法の詳細は、第16.4項「トポロジのスケール・アップ(管理対象サーバーを既存ノードに追加)」および第16.5項「トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)」を参照してください。

構成の変更前後にはトポロジをバックアップします。構成変更後の問題発生に対応するためバックアップしておく必要のあるディレクトリとファイルについては、第16.6項「WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行」で説明します。

この章では、トポロジの構成後に発生する可能性のある既知の問題の解決方法も示します。

16.2 SOAインフラストラクチャ・データベースでのスペースの管理

すべてのコンポジットでデータベースが頻繁に使用されるわけではありませんが、サービス・エンジンは大量のデータをCUBE_INSTANCEスキーマとMEDIATOR_INSTANCEスキーマで生成します。データベースの領域が不足していると、SOAコンポジットが機能しなくなる可能性があります。

SOAインフラストラクチャ・データベースでスペースを管理する手順は次のとおりです。

- Oracle Enterprise Manager Fusion Middleware Controlコンソール(のダッシュボードなど)で"Oracle.fabric.common.FabricInvocationException"などの汎用エラーがないか確認します。

- SOAサーバーのログで次のようなエラーを検索します。

Error Code: 1691
...
ORA-01691: unable to extend lob segment
SOAINFRA.SYS_LOB0000108469C00017$$ by 128 in tablespace SOAINFRA

これらのメッセージは通常、データベースの領域の問題を示しています。たとえば、既存のファイルにデータ・ファイルまたは領域を追加する必要があるような場合です。SOAデータベース管理者は、領域の追加で使用される拡張方針とパラメータを決定する必要があります。

- 古いコンポジット・インスタンスをパージしてSOAインフラストラクチャ・データベースのサイズを縮小します。このタイプの操作に、Oracle Enterprise Manager Fusion Middleware Controlを使用することはお薦めしません。操作でトランザクション・タイム・アウトが高い確率で発生します。リポジトリ作成ユーティリティでは、インスタンスを消去するための特別なパッケージが提供されています。次に例を示します。

DECLARE
FILTER INSTANCE_FILTER := INSTANCE_FILTER();

MAX_INSTANCES NUMBER;
DELETED_INSTANCES NUMBER;
PURGE_PARTITIONED_DATA BOOLEAN := TRUE;
BEGIN
.
FILTER.COMPOSITE_PARTITION_NAME:="default";
FILTER.COMPOSITE_NAME := "FlatStructure";
FILTER.COMPOSITE_REVISION := "10.0";
FILTER.STATE := fabric. STATE_UNKNOWN;
FILTER.MIN_CREATED_DATE := to_timestamp("2010-09-07","YYYY-MM-DD");
FILTER.MAX_CREATED_DATE := to_timestamp("2010-09-08","YYYY-MM-DD");
MAX_INSTANCES := 1000;
.
DELETED_INSTANCES := FABRIC.DELETE_COMPOSITE_INSTANCES(
FILTER => FILTER,
MAX_INSTANCES => MAX_INSTANCES,
PURGE_PARTITIONED_DATA => PURGE_PARTITIONED_DATA
);

これにより、2010-09-07から2010-09-08までの間に作成されたUNKNOWN状態のFlatStructureコンポジット(バージョン10)の最初の1000個のインスタンスが削除されます。提供されるSQLパッケージに含まれている可能性のある操作の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のSOAコンポジット・アプリケーションの管理に関する項を参照してください。必ず、適切に消去できるようにするために提供されているスクリプトを使用してください。composite_dn表からのみ行を削除すると、Oracle Fusion Middleware SOAインフラストラクチャが使用するその他の表の参照が解決されなくなる場合があります。

16.3 UMSドライバの構成

UMSドライバの構成情報は、SOAクラスタに自動的には伝播されません。UMSドライバの構成をクラスタに伝播する手順は次のとおりです。

- UMSドライバの構成を、そのドライバを使用するエンタープライズ・デプロイメント・トポロジ内のすべてのサーバーに適用します。

- サーバー移行を使用する場合、サーバーは別のノードのドメイン・ディレクトリに移動します。フェイルオーバー・ノード内でUMSドライバ構成をあらかじめ作成しておきます。UMSドライバの構成ファイルは、次のディレクトリにあります。

ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml

*は、デプロイ中にOracle WebLogic Serverによってランダムに生成されるディレクトリ名を表します。たとえば、3682yqなどです。

フェイルオーバーに備え、強制的にサーバー移行を実行しファイルをソース・ノードからコピーする方法でUMSドライバ構成ファイルを作成します。

これまでに行った変更を有効にする(変更後の構成情報をドライバに読み取らせる)ためにドライバを再起動する必要があります。ドライバを再起動する手順は次のとおりです。

1. Oracle WebLogic管理コンソールにログインします。

2. ナビゲーション・ツリーの環境ノードを開きます。

3. 「デプロイメント」をクリックします。

4. ドライバを選択します。

5. 「停止」→「作業完了時」をクリックして、操作を確定します。

6. ドライバの状態が「準備完了」に変化するまで待ちます(必要に応じて、管理コンソール・ページを更新します)。

7. ドライバをもう一度選択し、「起動」→「すべてのリクエストを処理」をクリックして、操作を確定します。

ドライバのプロパティが保持されていることを、Oracle Enterprise Manager Fusion Middleware Controlで確認します。

16.4 トポロジのスケール・アップ(管理対象サーバーを既存ノードに追加)

トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。新しい管理対象サーバーを作成する場合は、このような既存のノード・インストール(WebLogic Serverホーム、Oracle Fusion Middlewareホーム、ドメイン・ディレクトリなど)を使用します。WebLogic Server、SOAまたはWebCenter Portalのバイナリを新しい場所にインストールしたり、packとunpackを実行したりする必要はありません。

サーバー移行を使用してサーバーのスケール・アップを行う場合は、必要となる容量およびリソース割当てについて計画します。例として、次のシナリオについて考えてみます。

- サーバー1がノード1上にあり、このサーバーはノード2上のサーバー2を使用するクラスタ内サーバー移行を使用します。

- スケールアップ操作によって、ノード1のクラスタにサーバー3が追加されます。これもサーバー移行を使用します。

このシナリオでは、ノード1またはノード2のいずれかですべてのサーバー(サーバー1、サーバー2、サーバー3および管理サーバー)が実行される恐れがあります。つまり、サーバー移行を使用するすべてのサーバーが1つのノード上(サーバー移行候補マシンの構成で定義される)で実行される最悪のケースに対応できるように、各ノードを十分なリソースで設計する必要があるということです。

注意:

intradoc.cfgなどのドメイン内のいくつかのファイルは、各ノードに固有なため、WebCenterコンテンツ・サーバーの管理対象サーバーではドメイン・ディレクトリを共有できません。ノード固有のファイルの問題を防ぐには、各WebCenter ContentおよびInbound Refinery管理対象サーバーにローカル(ノードごと)のドメイン・ディレクトリを使用します。

この項の内容は次のとおりです。

- 第16.4.1項「Oracle SOA (WSMを含む)のスケール・アップ」

- 第16.4.2項「Oracle WebCenter Portalのスケール・アップ」

- 第16.4.3項「Oracle WebCenter Contentのスケール・アップ」

16.4.1 Oracle SOA (WSMを含む)のスケール・アップ

SOAトポロジ(WSMを含む)をスケール・アップするには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成するには:

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

2. 「ロックして編集」をクリックして、クローニングする管理対象サーバー(たとえばWLS_SOA1)を選択します。

3. 「クローンの作成」をクリックします。

4. 新しい管理対象サーバーの名前をWLS_SOAnにします。nは、新しい管理対象サーバーの識別番号です。ここでは、WLS_SOA1が実行されていたノード1に新しいサーバーを追加します。

以降の手順は、新しいサーバーをSOAHOST1に追加します。このホストではすでにWLS_SOA1が実行されています。

2. リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを指定します。推奨されているとおりにサーバー移行を使用する場合、サーバーを別のノードに移動できるようにVIP(浮動IPとも呼ばれる)を指定します。このVIPは、実行されている管理対象サーバーとは別のものを使用してください。

3. WLS_WSMサーバーの場合は、第8.5.5項「Oracle WSMについてのJavaオブジェクト・キャッシュの構成」で説明されているように、Javaオブジェクト・キャッシュの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。同じノードの複数のWLS_WSMサーバー用に同じディスカバリ・ポートを使用できます。第8.5.5項「Oracle WSMについてのJavaオブジェクト・キャッシュの構成」の手順をWLS_WSMサーバーごとに繰り返すと、サーバー・リストが更新されます。

4. SOA用およびUMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。

1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_N

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

2. SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

3. 新しいUMS JMSサーバー用の新しい永続ストアを作成し(UMS JMSサーバーの作成方法は後述します)、UMSJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_N

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

注意:

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

4. UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

5. BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

SOAJMSFileStore_Nを新しいBPM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

6. BPMシステムの場合のみ: BPM用の新しいJMSサーバー(たとえばBPMJMSServer_N)を作成します。このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

7. UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。

8. SOA、UMSおよび(適用可能な場合)BPM JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BPM: BPMJMSMOdule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

注意:

このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。「保存してアクティブ化」をクリックします。

5. 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順は、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。

注意:

変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。

Dtangosol.coherence.localhost=SOAHOST1VHNn

6. 新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

7. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAN管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。

1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

4. 表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

8. 新しい管理対象サーバー用のサーバー移行を構成します。Oracle WebLogic Server管理コンソールを使用してサーバー移行を構成する手順は次のとおりです。

注意:

これはスケールアップ操作であるため、ノードにノード・マネージャが存在していること、およびサーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済であることが必要です。新しいSOA管理対象サーバー用の浮動IPも、すでに存在している必要があります。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

2. 表の「名前」列で、移行を構成するサーバーの名前(ハイパーリンクとして表示される)をクリックします。選択したサーバーの「設定」ページが表示されます。

3. 「移行」サブタブをクリックします。

4. 「移行の構成」セクションで、移行に参加するサーバーを「使用可能」ウィンドウから選択して右向き矢印をクリックします。ノード上に存在するサーバーと同じ移行ターゲットを選択してください。
たとえば、SOAHOST1(すでにWLS_SOA1を実行している)の新しい管理対象サーバーの場合、SOAHOST2を選択します。SOAHOST2(すでにWLS_SOA2を実行している)の新しい管理対象サーバーの場合、SOAHOST1を選択します。

注意:

移行時に複数の管理対象サーバーを同時に実行するには、十分な空きリソースを確保しておく必要があります。

5. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。

6. 「保存」をクリックします。

7. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

9. 新しいサーバーを含むように、クラスタのアドレスを更新します。

1. 管理コンソールで、「環境」を選択し、「クラスタ」を選択します。

2. SOA_Clusterサーバーをクリックします。
SOA_Clusterの「設定」画面が表示されます。

3. 「ロックして編集」をクリックします。

4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。たとえば、ADMINVHN:8011,SOAHOST2VHN1:8011,SOAHOST1VHN1:8001と入力します。

5. 変更を保存してアクティブ化します。

10. この新しいサーバー用のサーバー移行をテストします。移行をテストするには、新しいサーバーを追加したノードで次の手順を実行します。

1. WLS_SOAn管理対象サーバーを停止します。
停止するには、run kill -9 <pid>を管理対象サーバーのPIDに対して実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを実行します。

2. ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

16.4.2 Oracle WebCenter Portalのスケール・アップ

WebCenter Portalトポロジをスケール・アップするには、次の手順を実行します。

注意:

1つのノード上における複数の管理対象サーバーの実行は、WC_SpacesおよびWC_Portletサーバーに対してのみサポートされています。

1. WebLogic Server管理コンソールを使用して、WC_Spaces1またはWC_Portlet1のクローンを作成し、新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成するには:

1. 管理コンソールで、「環境」を選択し、「サーバー」を選択します。

2. 「ロックして編集」をクリックします。

3. クローンを作成する管理対象サーバー(WC_Spaces1やWC_Portlet1など)を選択します。

4. 「クローン」を選択します。

5. 新しい管理対象サーバーにWC_SERVERNAMEnという名前を付けます(ここで、nは新しい管理対象サーバーを識別する番号です)。

以降の手順では、すでにWC_Spaces1またはWC_Portlet1が実行されている新しいサーバーにWCPHOST1を追加します。

2. リスニング・アドレスには、この新しい管理対象サーバーに使用するホスト名またはIPアドレス(既存サーバーと同じもの)を割り当てます。
この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。

3. 新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します。詳細は、第10.5項「Spaces_Cluster用のJavaオブジェクト・キャッシュの構成」を参照してください。

4. Oracle HTTP Serverモジュールをクラスタの新規メンバーで再構成します。詳細は、第10.11.1項「WC_Spacesn、WC_Portletn、WC_UtilitiesnおよびWC_Collaborationn管理対象サーバーのためのOracle HTTP Serverの構成」を参照してください。WebLogicClusterパラメータの終わりに、新しいサーバーのホストとポートを追加します。

- WC_Spacesの場合は、メンバーを/webcenter、/webcenterhelp、/rss、/restのLocationブロックに追加します。

- WC_Portletの場合は、メンバーを/portalTools、/wsrp-tools、/pageletsのLocationブロックに追加します。

16.4.3 Oracle WebCenter Contentのスケール・アップ

1つのドメイン、1つのノードに対して、Oracle WebCenter Content管理対象サーバー1台のみが、Oracle Fusion Middlewareによってサポートされます。Oracle WebCenter Content管理対象サーバーを追加するには、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteエンタープライズ・デプロイメント・ガイドのOracle WebCenter Contentのスケールアウト手順に関する説明に従って、Oracle WebCenter Content管理対象サーバーを新しいノードに追加します。

16.5 トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)

トポロジをスケール・アウトするには、SOA、WebCenter PortalまたはWebCenter Contentを構成した新しい管理対象サーバーを新しいノードに追加します。

この項の内容は次のとおりです。

- 第16.5.1項「Oracle SOA (WSMを含む)のスケール・アウト」

- 第16.5.2項「Oracle WebCenter Portalのスケール・アウト」

- 第16.5.3項「Oracle WebCenter Contentのスケール・アウト」

16.5.1 Oracle SOA (WSMを含む)のスケール・アウト

トポロジをスケールアウトするには、SOAまたはWSM-PMを構成した新しい管理対象サーバーを新しいノードに追加します。

この項の手順を実行する前に、次の要件が満たされていることを確認してください。

前提条件

- SOAまたはWSM-PMを構成した管理対象サーバーが、トポロジ内の既存のノードで実行されている必要があります。

- 新しいノードが、WebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerやSOAのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpackとunpackを実行してドメイン構成をブートストラップする必要はあります)。

- ORACLE_HOMEまたはWL_HOMEが別のノード上の複数のサーバーで共有されている場合、パッチのインストールと適用の一貫性を維持するために、これらのノードにあるOracleインベントリおよびミドルウェア・ホーム・リストを常に最新にしておきます。ノード内のoraInventoryを更新し、これに共有記憶域のインストールをアタッチするには、次の場所でattachHome.shスクリプトを使用します。

ORACLE_HOME/oui/bin/

ミドルウェア・ホーム・リストを更新してWL_HOMEを追加または削除するには、次のディレクトリにあるbeahomelistファイルを編集します。

user_home/bea/

トポロジをスケール・アウトするには:

1. 新しいノード上に、既存のMW_Home(SOAインストールとドメイン・ディレクトリが存在する)をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、SOAHOSTnで次のコマンドを実行します。

cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh
./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>

ミドルウェア・ホーム・リストを更新するには、$HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合は、このファイルを編集)、MW_HOMEをこのファイルに追加します。

3. Oracle WebLogic管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

5. マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのIPをマッピングします。

6. Oracle WebLogic Server管理コンソールを使用し、WLS_SOA1またはWLS_WSM1をクローニングして新しい管理対象サーバーを作成します。この管理対象サーバーには、WLS_SOAnまたはWLS_WLS_WSMnという名前を付けます(nは番号です)。

注意:

この手順では、管理対象サーバーが1つも実行されていないノードnに、新しいサーバーを追加することを想定しています。

7. 新しい管理対象サーバーのリスニング・アドレスとして使用するホスト名またはIPを指定します。
このサーバーでサーバー移行を実行する場合(推奨)、ここでサーバーのVIP(浮動IPとも呼ばれる)を指定します。このVIPは、既存の管理対象サーバーとは別のものを使用してください。

8. WLS_WSMサーバーの場合は、第8.5.5項「Oracle WSMでのJava Object Cacheの構成」で説明されているように、Java Object Cacheの構成ユーティリティをもう一度実行して、JOC分散キャッシュにこの新しいサーバーを追加します。

9. SOA用、BPM用および(適用可能な場合)UMS用のJMSサーバーを、新しい管理対象サーバー上に作成します。

注意:

この手順は、WLS_SOA管理対象サーバーの場合にのみ実行し、WLS_WSM管理対象サーバーをスケール・アウトする場合は不要です。

SOA用およびUMS用のJMSサーバーを作成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServer用の新しい永続ストアを作成し(SOAJMSServerの作成方法は後述)、SOAJMSFileStore_Nなどの名前を付けます。JMS永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているストアのパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_N

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

2. SOA用の新しいJMSサーバーを作成し、SOAJMSServer_Nなどの名前を付けます。SOAJMSFileStore_Nは、このJMSサーバーで使用します。SOAJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

3. 新しいUMSJMSServer用の新しい永続ストアを作成し、UMSJMSFileStore_Nなどの名前を付けます。永続ストアのディレクトリとして、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」でJMS永続ストアのディレクトリとして推奨されているパスを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore _N

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

注意:

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

4. UMS用の新しいJMSサーバーを作成し、UMSJMSServer_Nなどの名前を付けます。UMSJMSFileStore_Nは、このJMSサーバーで使用します。UMSJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

5. BPMシステムの場合のみ: 新しいBPMJMSServer用の新しい永続ストア(たとえばBPMJMSFileStore_N)を作成します。このストアのパスを指定します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているような、共有記憶域上のディレクトリである必要があります。
ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N

注意:

このディレクトリが管理対象サーバーの起動時に存在していなければ、起動操作は失敗します。

SOAJMSFileStore_Nを新しいBPM JMSサーバーのストアとして割り当てることも可能です。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

6. BPMシステムの場合のみ: BPM用の新しいJMSサーバー(たとえばBPMJMSServer_N)を作成します。このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーのターゲットとして、前述の手順で作成した管理対象サーバー(WLS_SOAn)を指定します。

7. SOA JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したSOA JMSサーバーを追加します。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModuleUDDs」をクリックします(表の「名前」列にハイパーリンクとして表示されます)。SOAJMSModuleUDDsの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。SOAJMSSubDMサブデプロイメントが表示されます。

注意:

このサブデプロイメント・モジュールは、最初の2つのサーバー(WLS_SOA1およびWLS_SOA2)のJMS構成を共通分散宛先(UDD)スクリプト(soa-createUDD.py)によって更新した結果作成されたものです。このスクリプトは、エンタープライズ・デプロイメント・トポロジの初期設定に必要です。

このサブデプロイメントをクリックします。SOA用の新しいJMSサーバーSOAJMSServer_Nを、このサブデプロイメントに追加します。「保存」をクリックします。

8. UMSJMSSystemResourceのターゲットとしてSOA_Clusterを指定します(拡張操作のときに変更された可能性があるため)。そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSytemResource」をクリックし、「ターゲット」タブを開きます。SOA_Cluster内のすべてのサーバー(クローニングで作成されたWLS_SOAnも含む)が選択されていることを確認してください。

9. SOA、UMSおよび(適用可能な場合)BPM JMSモジュールのサブデプロイメント・ターゲットを更新し、作成したJMSサーバーを追加します。
そのためには、「サービス」→「メッセージング」の各ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。表の「名前」列で、ハイパーリンクとして表示されているJMSモジュール(SOA: SOAJMSModule用、BPM: BPMJMSMOdule用およびUMS: UMSSYtemResource用)をクリックします。モジュールの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。デプロイメント・モジュールのサブデプロイメントが表示されます。

注意:

このサブデプロイメント・モジュールの名前は、SOAJMSServerXXXXXX、UMSJMSServerXXXXXXまたはBPMJMSServerXXXXXXの形式によるランダムな名前であり、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)に対する構成ウィザードのJMS構成から生成されます。

このサブデプロイメントをクリックします。新しいJMSサーバーを追加します(UMSの場合はUMSJMSServer_Nを追加し、SOAの場合はSOAJMSServer_Nを追加します)。「保存してアクティブ化」をクリックします。

10. 次のように、SOAHOST1でpackコマンドを実行してテンプレート・パックを作成します。

cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

SOAHOST1で次のコマンドを実行し、テンプレート・ファイルをSOAHOSTnにコピーします。

SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_COMMON_HOME/common/bin

次のように、unpackコマンドをSOAHOSTnで実行して、このテンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name/
-template=soadomaintemplateScale.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/apps

11. 新しいサーバーにコンポジットをデプロイするようにOracle Coherenceを構成します。手順は、第9.4項「コンポジットをデプロイするためのOracle Coherenceの構成」を参照してください。

注意:

変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。

Dtangosol.coherence.localhost=SOAHOST1VHNn

12. 新しいサーバー用の永続ストアを構成します。これは、第4章「エンタープライズ・デプロイメント用のファイル・システムの準備」で推奨されているように、他のノードから参照可能な場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「ディレクトリ」の「デフォルト・ストア」で、デフォルトの永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

13. 新しい管理対象サーバー用のホスト名検証を無効にします。WLS_SOAn管理対象サーバーを起動および検証する前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとSOAHOSTnのノード・マネージャとの通信用のサーバー証明書構成が完了したら、ホスト名検証を再度有効にすることができます。
新しいサーバーのクローニング元となっているサーバーでホスト名検証がすでに無効になっている場合は、これらの手順は不要です(ホスト名検証の設定はクローニング後のサーバーに伝播されます)。ホスト名検証を無効にする手順は次のとおりです。

1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。
「サーバーの概要」ページが表示されます。

4. 表の「名前」列の「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

14. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、既存のノードの共有記憶域内にあるインストールを使用してから、次のように新しいノードのホスト名をパラメータとして渡します。

SOAHOSTN> WL_HOME/server/bin/startNodeManager

15. Oracle WebLogic Server管理コンソールで、新しい管理対象サーバーを起動してテストします。

1. 新たに作成した管理対象サーバー、WLS_SOAnが実行されていることを確認します。

2. ロード・バランサ上(https://soa.mycompany.com/soa-infra)のアプリケーションにアクセスします。アプリケーションが機能している必要があります。

注意:

トポロジ内のHTTP Serverでは、新たに追加されたサーバーへのリクエストをラウンド・ロビン方式で処理する必要があります(新しいリクエストは、クラスタ内のサーバー数に応じて、新しいサーバーにヒットする必要があります)。クラスタ内のすべてのサーバーをOracle HTTP Serverのmod_wl_ohs.confファイルのWebLogicClusterディレクティブに追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

16. 新しい管理対象サーバー用のサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールが使用されるため、このノードにはノード・マネージャが存在しています。また、サーバー移行用の環境(ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限など)が構成済です。新しいSOA管理対象サーバー用の浮動IPも、新しいノードにすでに存在します。

Oracle WebLogic Server管理コンソールにログインし､サーバーの移行を構成します。

1. 「ドメイン構造」ウィンドウの「環境」ノードを開き、「サーバー」を選択します。「サーバーの概要」ページが表示されます。

2. 表の「名前」列で、移行を構成するサーバー(ハイパーリンクとして表示される)を選択します。そのサーバーの「設定」ページが表示されます。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。

注意:

マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要な容量計画をあらかじめ行ってください。

5. 「サーバーの自動移行を有効化」を選択します。これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。

6. 「保存」をクリックします。

7. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。

17. 新しいサーバーを含むように、クラスタのアドレスを更新します。

1. 管理コンソールで、「環境」を選択し、「クラスタ」を選択します。

2. SOA_Clusterサーバーをクリックします。
SOA_Clusterの「設定」画面が表示されます。

3. 「ロックして編集」をクリックします。

4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。たとえば、ADMINVHN:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8001と入力します。

5. 変更を保存してアクティブ化します。

18. この新規サーバーを追加したノードから、新規サーバーのサーバー移行をテストします。

1. 管理対象サーバーのPID (プロセスID)で次のコマンドを実行して、WLS_SOAn管理対象サーバーを停止します。

kill -9 pid

ノードのPIDは次のコマンドで特定できます。

ps -ef | grep WLS_SOAn

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。次に例を示します。

taskkill /f /pid pid

pidは、管理対象サーバーのプロセスIDを表します。

WLS_SOAn管理対象サーバーのプロセスIDを確認するには、次のコマンドを実行します。

MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v

2. ノード・マネージャのコンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルで再び再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

16.5.2 Oracle WebCenter Portalのスケール・アウト

トポロジのスケール・アウトでは、Oracle WebCenter Portalアプリケーションを使用して構成されている新しい管理対象サーバーを新しいノードに追加します。

この項の手順を実行する前に、次の要件が満たされていることを確認してください。

前提条件

- WebCenter Portalで構成された管理対象サーバーを実行しているノードがトポロジ内に存在しています。

- 新しいノードは、WebLogic ServerおよびOracle WebCenter Portal用の既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerまたはWebCenter Portalのバイナリを新しい場所にインストールする必要はありませんが、packとunpackを実行して管理対象サーバーのドメインを作成する必要があります。

- WC_SpacesとWC_Utilitiesサーバーは、どちらも新しいノードでスケール・アウトされるか、どちらもスケール・アウトされない必要があります。これは、WebCenter Portal: SpacesとAnalyticsアプリケーションの間のローカル・アフィニティによるものです。

トポロジをスケール・アウトするには:

1. 新しいノードで、WebCenter Portalのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するために、次のコマンドを実行します。

WCPHOSTn> cd ORACLE_BASE/product/fmw/wc/
WCPHOSTn> ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>

Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。

3. Oracle WebLogic管理コンソールにログインします。

4. 新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。

5. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。

6. Oracle WebLogic Server管理コンソールを使用して、WC_Spaces1、WC_Portlet1、WC_Collaboration1またはWC_Utilities1のクローンを新しい管理対象サーバーに作成します。それにWC_XXXnという名前を付けます(nはその新しいマシンに割り当てる番号です)。

7. リスニング・アドレスには、新しい管理対象サーバーに使用するホスト名またはIPを割り当てます。次の手順に従って、管理対象サーバーのリスニング・アドレスを設定します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

5. 表の「名前」列で、リスニング・アドレスを変更する管理対象サーバーを選択します。その管理対象サーバーの「設定」ページが表示されます。

6. 「リスニング・アドレス」をWCPHOSTnに設定します(ここで、WCPHOSTnは、新しいマシンのDNS名です)。

7. 「保存」をクリックします。

8. 変更を保存してアクティブ化します。
変更内容は、管理対象サーバーが再起動されるまでは有効になりません。

8. packコマンドをSOAHOST1上で実行してテンプレート・パックを作成し、WCPHOSTnに解凍します。
これらの手順は、第10.4.1項「unpackユーティリティを使用したSOAHOST2、WCPHOST1およびWCPHOST2へのドメイン構成の伝播」に記載されています。

9. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。

WCPHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip

10. 新しい管理対象のCollaborationサーバーの場合:

1. 第10.7項「ディスカッション・サーバーでのクラスタリングの構成」の手順に従って新しいディスカッション・サーバーのクラスタリングを構成します。

2. また、第10.6項「マルチキャストからユニキャストへのディスカッションの変換」の手順を、coherence.localhostパラメータに新しいホストのホスト名を使用して実行済であることも確認します。

11. これが新しいユーティリティ管理対象サーバーである場合は、第10.9項「アクティビティ・グラフの構成」の手順に従ってアクティビティ・グラフを無効化済であることを確認します。また、ユーティリティとローカルSpacesサーバー用に、第10.8項「Analyticsの構成」の新しいAnalyticsコレクタの構成手順が実行済であることも確認します。

12. Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. 新たに作成した管理対象サーバー、WLS_SOAnが実行されていることを確認します。

2. ロード・バランサ上(https://soa.mycompany.com/soa-infra)のアプリケーションにアクセスします。アプリケーションが機能している必要があります。

注意:

トポロジ内のHTTP Serverでは、新たに追加されたサーバーへのリクエストをラウンド・ロビン方式で処理する必要があります(新しいリクエストは、クラスタ内のサーバー数に応じて、新しいサーバーにヒットする必要があります)。クラスタ内のすべてのサーバーをOracle HTTP Serverのmod_wl_ohs.confファイルのWebLogicClusterディレクティブに追加する必要はありません。ただし、クラスタ内の新しいサーバーへのルーティングが行われるのは、WebLogicClusterディレクティブにリストされているサーバーのうちの少なくとも1台が実行されている場合のみです。

16.5.3 Oracle WebCenter Contentのスケール・アウト

Oracle WebCenter Content管理対象サーバーを追加するには、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteエンタープライズ・デプロイメント・ガイドのOracle WebCenter Contentのスケールアウト手順に関する説明に従って、Oracle WebCenter Content管理対象サーバーを新しいノードに追加します。

16.6 WebCenter Portalデプロイメントにおけるバックアップとリカバリの実行

表16-1は、WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。

表16-1 WebCenter Portal (11g)エンタープライズ・デプロイメントでバックアップする静的アーティファクト

タイプ

ホスト

場所

層

ORACLEホーム(DB)

RACデータベース・ホスト: CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

データ層

Oracleホーム(OHS)

WEBHOST1およびWEBHOST2

ORACLE_BASE/admin/instance_name

Web層

MWホーム(SOAおよびWC)

SOAHOST1およびSOAHOST2: SOA

WCPHOST1とWCPHOST2 - WC

すべてのホスト上のMW_HOME

アプリケーション層

ORACLE HOME (WCC)

WCPHOST1とWCPHOST2

共有ディスク上: /share/oracle/wcc

各ホストのORACLE_HOME/wccにあるローカル・ファイル

アプリケーション層

インストール関連ファイル

OraInventory

user_home/bea/beahomelist, oraInst.loc, oratab

表16-2は、WebCenter Portalエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。

表16-2 WebCenter Portal (11g)エンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト

タイプ

ホスト

場所

層

ドメイン・ホーム

SOAHOST1

SOAHOST2

WCPHOST1

WCPHOST2

ORACLE_BASE/admin/domain_name/ mserver/domain_name

アプリケーション層

アプリケーション・アーティファクト(earおよびwarファイル)

SOAHOST1

SOAHOST2

WCPHOST1

WCPHOST2

管理コンソールですべてのデプロイメントを確認し、すべてのアプリケーション・アーティファクトをバックアップする

アプリケーション層

OHSインスタンス・ホーム

WEBHOST1およびWEBHOST2

ORACLE_BASE/admin/instance_name

Web層

OHS WCC構成ファイル

WEBHOST1およびWEBHOST2

各ホストの/share/oracle/wcc(ローカル・ファイル・システム)

Web層

RACデータベース

CUSTDBHOST1およびCUSTDBHOST2

ユーザー定義

データ層

Oracle WebCenter Contentリポジトリ

データベース・ベース

データ層

Oracle Fusion Middlewareのコンポーネントのバックアップとリカバリの詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。

16.7 SQLNet接続のタイムアウト防止

エンタープライズ・デプロイメントの本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Cluster(Oracle RAC)については、データベース接続はOracle RAC VIPとデータベース・リスナー・ポートを使用して確立されます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。このような構成が不可能である場合は、次のディレクトリにあるsqlnet.oraファイル内の*SQLNET.EXPIRE_TIME=n*パラメータを設定します。

ORACLE_HOME/network/admin

nは分単位の時間です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。

16.8 Oracle WebCenter Portalエンタープライズ・デプロイメントのトラブルシューティング

この項では、WebCenter Portalエンタープライズ・デプロイメントで発生する可能性のある問題を示し、その解決方法を提案します。

この項の内容は次のとおりです。

- 第16.8.1項「管理コンソールで変更をアクティブ化するときにエラーが発生する」

- 第16.8.2項「管理コンソールで変更をアクティブ化した後にユーザーがログイン画面にリダイレクトされる」

- 第16.8.3項「OAMに対する変更をアクティブ化した後でユーザーが管理コンソールのホーム・ページにリダイレクトされる」

- 第16.8.4項「ドメインの伝播後WC_Spaces Serverが起動しない」

- 第16.8.5項「手動フェイルオーバー後に管理サーバーの起動に失敗する」

- 第16.8.6項「データベースのフェイルオーバー後にポートレットが使用できなくなる」

- 第16.8.7項「構成済のJOCポートがすでに使用中」

- 第16.8.8項「JMS構成の復元」

- 第16.8.9項「OAM構成ツール実行時にURLが削除されない」

- 第16.8.10項「RESTポリシーの構成後に2次認証を無効にする」

- 第16.8.11項「サーバー移行時にSudoエラーが発生する」

16.8.1 管理コンソールで変更をアクティブ化するときにエラーが発生する

問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。

An error occurred during activation of changes, please see the log for details.
[Management:141190]The commit phase of the configuration update failed with an exception:
In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean

解決方法: このエラーが発生するのは、サーバーの起動パラメータが管理コンソールで変更された場合です。この場合は、構成を変更しようとしていたサーバーの起動構成の一部であるユーザー名/パスワードの情報を管理コンソールで指定するか、<password-encrypted></password-encrypted>エントリをconfig.xmlファイルから削除してください(管理サーバーの再起動が必要)。

16.8.2 管理コンソールで変更をアクティブ化した後にユーザーがログイン画面にリダイレクトされる

問題: Oracle WebLogic管理コンソールにアクセスするためにOHSおよびロード・バランサを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。

解決方法: この問題は、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、管理コンソールがその変更を反映しようとすると発生します。変更内容によっては、管理サーバーのリスニング・アドレスにリダイレクトすることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、URLをwcp.mycompany.com/console/console.portalに変更すれば、管理コンソールのホーム・ページに直接アクセスできます。

注意:

この項で説明する変更の追跡を無効にしている場合、この問題は発生しません。

16.8.3 OAMに対する変更をアクティブ化した後でユーザーが管理コンソールのホーム・ページにリダイレクトされる

問題: OAMを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻りません)。

解決方法: これは、OAM SSOが構成済のときに発生する現象で、管理サーバーによってリダイレクトが実行された結果です。このリダイレクトにかかわらず、アクティブ化は完了します。必要であれば、ユーザーは手動で目的のコンテキスト・メニューに戻ることができます。

16.8.4 ドメインの伝播後WC_Spaces Serverが起動しない

問題: unpackユーティリティを使用し、SOAHOST2、WCPHOST1およびWCPHOST2にドメイン構成を伝播した後、WC_Spacesサーバーを起動できません。

[Deployer:149158]No application files exist at '/u01/app/oracle/admin/wcpedg_domain/apps/wcpedg_domain/custom.webcenter.spaces.fwk'...

解決方法: 管理対象サーバー・アプリケーションの場所から、管理対象サーバーのデプロイヤが期待している場所にすべてのファイルをコピーします。次に例を示します。

cp /u01/app/oracle/admin/wcpedg_domain/mserver/apps/* /u01/app/oracle/admin/wcpedg_domain/apps/wcpedg_domain/

注意:

コンテンツのコピー前に/u01/app/oracle/admin/wcpedg_domain/apps/wcpedg_domain/が存在することを確認します。

16.8.5 手動フェイルオーバー後に管理サーバーの起動に失敗する

問題: 管理サーバー・ノードに障害が発生して別のノードへの手動フェイルオーバーが実行された後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。

<Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory:
ORACLE_BASE/admin/soadomain/aserver/soadomain/servers/AdminServer/data/ldap/ldapfiles.
Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

解決方法: ノードの障害発生後にノードを復旧させるときに、ドメイン・ディレクトリに共有記憶域が使用されている場合、ロック・クリーンアップの失敗が原因で、管理サーバーのログにこのエラーが記録されることがあります。このエラーを解決するには、ファイルを削除します。

ORACLE_BASE/ admin/domain_name/aserver/domain_name/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lok

16.8.6 データベースのフェイルオーバー後にポートレットが使用できなくなる

問題: Spaces内でページを作成しているときに、そのページにポートレットを追加した後でデータベース・フェイルオーバーが発生すると、エラーがあるコンポーネントがページに表示されます。

"Error"
"Portlet unavailable"

このメッセージは、ページをリフレッシュしたり、いったんログアウトしてページを再表示してもなくなりません。

解決方法: この問題を解決するには、該当のコンポーネントを削除してからもう一度追加します。

16.8.7 構成済のJOCポートがすでに使用中

問題: Javaオブジェクト・キャッシュ(OWSM、WebCenter Portal管理対象サーバーなど)を使用している管理対象サーバーの起動に失敗します。次のエラーがログに表示されます。

J2EE JOC-058 distributed cache initialization failure
J2EE JOC-043 base exception:
J2EE JOC-803 unexpected EOF during read.

解決方法: JOCが取得しようとしているポートと同じポートを別のプロセスが使用しています。このプロセスを停止するか、または推奨ポート範囲内の別のポートを使用するようにこのクラスタのJOCを再構成します。

16.8.8 JMS構成の復元

問題: soa-createUDD.pyスクリプトに渡されたパラメータに誤りがあるか、別の誤りによってSOAクラスタのJMS構成で障害が発生しています。

解決方法: soa-createUDD.pyを使用して、構成をリストアします。

SOAクラスタがOracle Fusion Middleware構成ウィザードから作成された後でsoa-createUDD.pyスクリプトを実行しているときに、なんらかの誤りが生じた(誤ったオプションが使用された、ターゲットが変更された、またはモジュールが間違って削除された)場合。このような状況では、soa-createUDD.pyスクリプトを使用し、次の手順で適切なJMS構成をリストアできます。

1. 既存のSOA JMSリソース(SOAインフラストラクチャ・システムが所有するJMSモジュール)を削除します。

2. soa-createUDD.pyを再実行します。このスクリプトは、SOA用に作成されたJMSサーバーが保持され、SOA用の共通分散送り先を使用するために必要な宛先とサブデプロイメント・モジュールが作成されることを想定しています。この場合、オプション--soaclusterを指定してスクリプトが実行される必要があります。スクリプトを再実行後、WebLogic Server管理コンソールから次のアーティファクト(ドメイン構造、サービス、メッセージング、JMSモジュール)が存在することを確認します。

SOAJMSModuleUDDs        ---->SOAJMSSubDM targeted to SOAJMSServer_auto_1 and SOAJMSServer_auto_2
UMSJMSSystemResource    ---->UMSJMSSubDMSOA targeted to UMSJMSServer_auto_1 and UMSJMSServer_auto_2

16.8.9 OAM構成ツール実行時にURLが削除されない

問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しました。1つ以上のURLが不正です。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。

解決方法: 同じapp_domain名を指定してOAM構成ツールを実行したときは、既存ポリシーへの新しいURLの追加のみが行われます。特定のURLを削除するには、OAMのポリシー・マネージャ・コンソールを使用してください。OAMのアクセス管理サイトにログインして、「ポリシー・ドメイン」をクリックし、作成されたポリシー・ドメイン(WCP_EDG)→「リソース」タブをクリックし、誤ったURLを削除します。

16.8.10 RESTポリシーの構成後に2次認証を無効にする

問題: RESTポリシーの構成後、その後の認証でもOAMを介した外部のクライアントの認証が要求されます。

解決方法: 2次認証はWebLogicに由来しています。WebLogicの資格証明の要求を無効にするには、次のようにセキュリティ・ポリシーを更新する必要があります。

1. 次のファイルを探します。

/aserver/domain_name/config/config.xml

2. セキュリティの構成の終わりの部分で(つまり</security-configuration>の前に)、次の行を追加します。

<enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credenti als>

3. ドメイン内のすべてのサーバーを再起動します。

16.8.11 サーバー移行時にSudoエラーが発生する

問題: サーバー移行のためwlsifconfigを実行すると、次の警告が表示されます。

sudo: sorry, you must have a tty to run sudo

解決方法: WebLogicユーザー('oracle')がバックグラウンドでsudoを実行できません。この問題を解決するには、次の行を/etc/sudoersに追加します。

Defaults:oracle !requiretty

詳細は、第14.6項「wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定」を参照してください。

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. Repository Creation Utilityを実行したときに、次のデータ・ソースがスキーマ接頭辞とともに画面に表示されることを確認します。

4. 「次へ」をクリックします。

2. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面が表示されます(図A-1)。

図A-1 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

この画面で、次の手順を実行します。

1. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。

- サービス名: データベースのサービス名を入力します。

- ユーザー名: データベース・スキーマの完全なユーザー名(接頭辞を含む)を入力します。

- パスワード: スキーマへのアクセスに使用するパスワードを入力します。

2. ホスト名、インスタンス名およびポートを入力します。

3. 「追加」をクリックします。

4. この手順をOracle RACインスタンスごとに実行します。

5. 「次へ」をクリックします。

3. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常に確立したことを確認してください。正常に接続できない場合は、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続に成功したら「次へ」をクリックします。

索引

A B C D E F G H I J K L M N O P R S T U V W

A

アクセス・ゲート, 15.5.3.5

クラスタの追加, 9.3, 10.2

管理対象サーバーの追加, 9.3, 10.2

管理対象サーバーの既存ノードへの追加, 16.4

管理対象サーバーの新しいノードへの追加, 16.5

アドレス・セキュリティ・フィルタ, 13.18.5.1

管理コンソール

フロントエンドURL, 8.6.4

ホーム・ページへのリダイレクト, 16.8.3, 16.8.7

ログイン画面へのリダイレクト, 16.8.2

サーバー移行の検証, 14.8

管理サーバー, 8.4.1, 8.4.6, 8.6.1, 14.4

フェイルオーバー, 8.6.6, 8.6.8

ホスト名の検証, 8.4.8, 8.5.2

再起動, 13.18.3

SSL通信, 11.3, 11.5

起動, 8.4.3

検証, 8.4.5

WebCenter Portal Spacesの管理者ロール, 15.7.2 admin.mycompany.com, 3.2.2 アプリケーション層, 2.1.4 arping, 8.2 ASM、「自動ストレージ管理(ASM)」を参照 サーバーのクラスタへの割当て, 9.3, 10.2 サーバーのマシンへの割当て, 9.3, 10.2 Oracle Web層とWebLogicドメインの関連付け, 7.4 認証プロバイダ, 15.5.6, 15.6.5, 15.8.1 自動ストレージ管理(ASM), 5.2.1

B

バックアップ

Oracle HTTP Serverの設定後, 6.2.3

構成ファイル, 15.2.1, 15.5.6.1, 15.6.5.1

コンテンツ・サーバー, 13.12, 13.15

データベース, 5.6

ドメイン, 9.3, 10.2

エンタープライズ・デプロイメント, 16.6

インストール, 6.3.3, 8.7, 9.10, 10.12, 15.9

Oracle HTTP Server, 6.2.3

ベスト・プラクティス

SQLNet接続のタイムアウト, 16.7

boot.properties, 8.4.1 BPEL認証, 15.8 BPMWorkflowAdminアプリケーション・ロール, 15.8.2 組込みセキュリティ, 1.3.1

C

Javaオブジェクト・キャッシュ, 10.5

コールバックURL, 9.7.3

クラスタ・エージェント, 1.2

クラスタ, 1.2, 8.3

追加, 9.3, 10.2

サーバーの割当て, 9.3, 10.2

クラスタウェア, 1.2 Coherence、「Oracle Coherence」を参照 構成

データベース, 5.1

委任フォーム認証, 15.5.3.9

ディレクトリ構造, 4.1

ディスカッション・サーバー, 12.1

SOAHOST1上のドメイン, 8.3

フロントエンドHTTPホストとポート, 9.7.3

Oracleファイル/FTPアダプタの高可用性, 9.9.1

インスタント・メッセージおよびプレゼンス(IMP), 12.2

ロード・バランサ, 3.3

ネットワーク, 3

Oracle Coherence, 9.4

Oracle HTTP Server, 7.5, 8.6.1

WLS管理対象サーバーのOracle HTTP Server, 9.7.1, 10.11.1

ページレット・プロデューサ, 12.5

トランザクション・リカバリ用の永続ストア, 9.8

ポートレット・プロデューサ, 12.4

ドメイン構成の伝播, 13.18.2

Oracle Databaseアダプタのスケーリング, 9.9.3

共有JMS永続ストア, 9.3

共有ストレージ, 4.1, 4.4

サーバー移行のターゲット, 14.7

UMSドライバ, 16.3

カスタム・キーストアの使用, 11.3.4, 11.5.3

OAM用のWebCenter Portalアプリケーション, 15.7

WebGate, 15.5.4

ワークフロー, 12.3

ワークリスト, 12.3

構成ウィザード, 8.3, 9.3, 10.2 configure-joc.pyスクリプト, 8.5.5, 10.5 接続ファクトリのパラメータ, 9.9.1.1 接続

ディスカッション・サーバー, 12.1

インスタント・メッセージおよびプレゼンス(IMP), 12.2

ワークフロー, 12.3

ワークリスト, 12.3

コンテンツ・サーバー, 2.1.4

バックアップ, 13.12, 13.15

createCentralInventory.shスクリプト, 6.2.2, 6.3.2.1 アイデンティティ・キーストアの作成, 11.3.2, 11.5.2 信頼キーストアの作成, 11.3.3 CUSTDBHOSTノード, 2.1.5, 5.2.1 カスタム・キーストア, 11.3.4, 11.5.3

D

データ・ソース, 8.3, 14.3, A.2

データ層, 2.1.5

データベース

バックアップ, 5.6

CREATE_SERVICE, 5.3

ホストの要件, 5.2.1

初期化パラメータ, 5.2.3

リポジトリのロード, 5.4

mutexロック, 9.9.1.1

サービス, 5.3

設定, 5.2

サポートされているバージョン, 5.2.2

データベース・リスナー・ポート, 2.1.5 データベースの事前構成, 5.1 トランザクション・リカバリ用のデフォルト永続ストア, 9.8 委任フォーム認証, 15.5.3.9 ディレクトリ構造, 4.1, 4.3, 4.3, 4.3 ホスト名の検証の無効化, 8.4.8, 8.5.2, 9.5.1, 10.3.1 ディスカッション・サーバー, 12.1 DMZ, 1.3.1, 2.1.3, 2.1.4 ドメイン

バックアップ, 9.3, 10.2

SOAHOST1上での作成, 8.3

SOAコンポーネント用に拡張, 9, 9.3

WebCenter Portalコンポーネントのための拡張, 10, 10.2

ドメイン構成の伝播, 13.18.2

ドメイン構成

伝播, 8.5.1, 9.5.4, 9.6.1, 10.3.3, 10.4.1

ドメイン・ディレクトリ, 4.2 ドメイン・ディレクトリ, 8.4.6

E

SOAHOST1上でのADMINVHNの有効化, 8.2

エンタープライズ・デプロイメント, 1.1

バックアップとリカバリ, 16.6

トポロジ, 2.1

環境権限, 14.6 ドメインの拡張

SOAコンポーネント, 9, 9.3

WebCenter Portalコンポーネント, 10, 10.2

ドメインの拡張, WebCenter Contentコンポーネント, 13 外部通信, 1.3.1 外部サービス

ディスカッション・サーバー, 12.1

インスタント・メッセージおよびプレゼンス(IMP), 12.2

ページレット・プロデューサ, 12.5

ポートレット・プロデューサ, 12.4

ワークリスト, 12.3

EXTRA_JAVA_PROPERTIES, 15.7.1

F

フェイルバック, 1.2

フェイルオーバー, 1.2, 16.8.5

管理サーバーのフェイルオーバー, 8.6.6, 8.6.8

ファイアウォール, 3.5

フロントエンドHTTPホストとポート, 9.7.3

管理コンソールのフロントエンドURL, 8.6.4

Fusion Middleware、「Oracle Fusion Middleware」を参照

G

自己署名証明書の生成, 11.3.1, 11.5.1

Spaces管理者ロールの付与, 15.7.2

グリッド・サーバー, 1.1

GridLinkデータ・ソース

構成, 10.2

構成の検証, 9.5.3, 10.4.4, 13.8

H

ハードウェア・クラスタ, 1.2

ハードウェア要件, 2.2

高可用性, 1.1, 1.3.2, 9.4.1

Oracleファイル/FTPアダプタ, 9.9.1

ホーム・ページ、リダイレクト, 16.8.3, 16.8.7 ホスト識別子, 15.5.3.6 ホスト名, 9.4.2

ネットワーク, 1.2

物理, 1.2

仮想, 1.2

ホスト名の検証, 8.4.8, 8.5.2, 9.5.1, 10.3.1 HTTPポート, 2.1.3 httpd.conf, 7.6.1 HTTPSポート, 2.1.3

I

IDアサータ, 15.5.6.2, 15.6.5.2

アイデンティティ・キーストア, 11.3.2, 11.5.2

ifconfig, 8.2

IMP、「インスタント・メッセージおよびプレゼンス(IMP)」を参照

Inbound Refinery

構成, 13.18.5

ドメインの拡張, 13.18

起動, 13.18.4

誤ったURL, 16.8.9 データベースの初期化パラメータ, 5.2.3 インストール

Oracle Fusion Middleware, 6.3.2.2

Oracle Fusion Middlewareのコンポーネント, 6.3.2

Oracle Fusion Middlewareホーム, 6.3

Oracle HTTP Server, 6.2.2

Oracle WebCenter Content, 6.3.2.1

Oracle WebLogic Server, 6.3.1

手順, 2.5

計画, 2.5.3

Web層の検証, 7.3

WebGate, 15.5.4

インストールするコンポーネント, 2.4

インスタント・メッセージおよびプレゼンス(IMP), 12.2 IP, 3.4, 3.4

J

Javaオブジェクト・キャッシュ, 10.5

JDK, 6.3.1

JMS永続ストア, 9.3

JRockit, 6.3.1

K

キーストア

カスタム, 11.3.4, 11.5.3

アイデンティティ, 11.3.2, 11.5.2

信頼, 11.3.3

keytoolユーティリティ, 11.3.3

L

LDAP

WebLogic管理者の移動, 15.2.2

leading.ddlスクリプト, 14.2 サーバー移行用のリース表, 14.2 リスニング・アドレス

WLS_WCC管理対象サーバー, 13.18.1

リスニング・ポート

WLS_WCC管理対象サーバー, 13.18.1

ロード・バランサ, 2.1.3, 7.6

構成, 3.3

Oracle HTTP Serverを使用した構成, 7.5

要件, 2.1.3.1

アクセスの検証, 10.11.3

ディレクトリの場所, 4.3, 4.3, 4.3 ログイン画面、リダイレクト, 16.8.2

M

管理対象サーバー, 8.3, 8.4.6

追加, 9.3, 10.2

既存ノードへの追加, 16.4

既存のノードへの追加(WebCenter Content), 16.4.3, 16.5.3

新しいノードへの追加, 16.5

ドメイン変更の伝播, 9.5.4, 10.3.3

検証, 9.5.5, 9.6.2

WC_Collaboration, 10.4.3, 10.4.5, 10.4.6, 10.4.7, 10.11.1

WC_Portlet, 10.4.3, 10.4.5, 10.4.6, 10.4.7, 10.11.1

WC_Spaces, 10.4.3, 10.4.5, 10.4.6, 10.4.7, 10.11.1

WC_Utilities, 10.4.3, 10.4.5, 10.4.6, 10.4.7, 10.11.1

WebCenter Portal, 10.3.1

WLS_SOA, 9.5.1, 9.5.5, 9.6.2

WLS_WCC, 13.18.1

WLS_WSM, 8.4.1, 8.4.8, 8.4.9, 8.5.2, 8.5.4, 8.6.1

トポロジの管理, 16 手動フェイルオーバー, 16.8.5 管理サーバーの手動フェイルオーバー, 8.6.6 IPとVIPのマッピング, 3.4, 3.4 ミドルウェア・ホーム, 1.2 サーバーの移行、「サーバー移行」も参照, 14 mod_wl_ohs.confファイル, 8.6.1 トポロジの監視, 16.1 マルチデータ・ソース, 14.3 mutexロック, 9.9.1.1 MW_HOME, 4.2

N

仮想サーバーの名前, 3.2

ネットワーク

ファイアウォール, 3.5

IP, 3.4

ロード・バランサ, 3.3

ポート, 3.5

共有記憶域, 4.3

仮想IP (VIP), 3.4

仮想サーバー, 3.2

ネットワーク・ホスト名, 1.2 ネットワーク事前構成, 3 ノード・マネージャ, 14.4

プロパティ・ファイル, 14.5

再起動, 9.5.2

設定, 11

SSL通信, 11.3, 11.5

起動, 8.4.2, 8.5.3, 10.3.2, 10.4.2, 11.4, 11.6, 13.5

カスタム・キーストアの使用, 11.3.4, 11.5.3

ノード

サーバーの既存ノードへの追加, 16.4

既存の--へのサーバーの追加(WebCenter Content), 16.4.3, 16.5.3

サーバーの新しいノードへの追加, 16.5

アプリケーション層, 2.1.4

CUSTDBHOST, 2.1.5, 5.2.1

データ層, 2.1.5

1次, 1.2

2次, 1.2

SOAHOST, 8.2, 8.3, 8.4.1, 8.4.2, 8.5.3, 9.5.2, 10.3.2, 13.5

WCPHOST, 10.3.2, 10.4.2

Web層, 2.1.3

WEBHOST, 2.1.3, 6.2.2

O

OAM、「Oracle Access Manager(OAM)」を参照

OAMCFGツール, 16.8.9

概要, 15.5.3, 15.5.3.1

実行, 15.5.3.2

OAPポート, 2.1.4 OID認証プロバイダ, 15.2.1 OIDポート, 2.1.5 OmniPortlet URL, 12.4 Oracle Access Manager, 2.1.3 Oracle Access Manager(OAM)

BPEL認証, 15.8

WebCenter Portalアプリケーションの構成, 15.7

委任フォーム認証, 15.5.3.9

IDアサータ, 15.5.6.2, 15.6.5.2

OAMCFGツール, 15.5.3, 15.5.3.1

プロバイダの順序, 15.5.6.3, 15.6.5.3

概要, 15.5.1, 15.6.1

前提条件, 15.5.2, 15.6.2

ホスト識別子の更新, 15.5.3.6

WebGateプロファイルの更新, 15.5.3.7

アクセス・ゲートの検証, 15.5.3.5

ポリシー・ドメインの検証, 15.5.3.5

WebGate, 15.5.4

WebLogic認証プロバイダ, 15.5.6, 15.6.5

Oracle Access Protocol(OAP), 2.1.3 Oracle Coherence, 9.4

ホスト名の指定, 9.4.2

Oracle Databaseアダプタ、スケーリング, 9.9.3 Oracleファイル/FTPアダプタ, 9.9.1 Oracle Fusion Middleware

インストール, 6.3.2.2

ホームのインストール, 6.3

Oracle WebLogic Serverのインストール, 6.3.1

Oracle Fusion Middleware (FMW)

FMWコンポーネントのインストール, 6.3.2

Oracle Fusion Middleware構成ウィザード, 8.3 Oracleホーム, 1.2 Oracle HTTP Server

バックアップ, 6.2.3

構成, 8.6.1

WLS管理対象サーバーの構成, 10.11.1

インストール, 6.2.2

登録, 8.6.3

アクセスの検証, 8.6.5, 8.6.7, 9.7.2, 10.11.2

検証, 7.6

Oracle HTTP Server(OHS)

バックアップ, 6.2.3

構成, 7.5

ロード・バランサ, 7.5

ポート, 6.2.1

Oracleインスタンス, 1.2 Oracle Notification Service

構成, 10.2

構成の検証, 9.5.3, 10.4.4, 13.8

Oracle SOA Suite

インストール, 6.3.2.1

Oracle WebCenter Content, 2.1.4

ポート, 3.5, 3.5, 3.5

Oracle WebCenter Portal

Analyticsの構成, 10.8

コレクタ・クラスタの構成, 10.8

WC_Spacesサーバーの構成, 10.8

Oracle WebLogic Server

インストール, 6.3.1

Oracle HTTP Serverの登録, 8.6.3

Oracle WebLogic Server(WLS)

Oracle Web層との関連付け, 7.4

Oracle WebLogic Server管理コンソール, 14.3 ORACLE_BASE, 4.2 ORACLE_HOME, 4.2 ORACLE_INSTANCE, 4.2 oracleRoot.shスクリプト, 6.2.2

P

ページレット・プロデューサ, 12.5

接続ファクトリのパラメータ, 9.9.1.1

パフォーマンス、エンタープライズ・デプロイメント, 1.1

永続ストア

共有JMS, 9.3

トランザクション・リカバリ, 9.8

物理ホスト名, 1.2 物理IP, 1.2 ポリシー・ドメイン, 15.5.3.5 ポートレット・プロデューサ, 12.4 ポートレット, 16.8.6 ポート

データベース・リスナー, 2.1.5

フロントエンドのHTTP, 9.7.3

HTTP, 2.1.3

HTTPS, 2.1.3

Oracle HTTP Server, 6.2.1

Oracle Internet Directory(OID), 2.1.5

Oracle WebCenter Content, 3.5, 3.5, 3.5

トポロジでの使用, 3.5

事前構成

データベース, 5.1

ディレクトリ構造, 4.1

ネットワーク, 3

共有記憶域, 4.1

1次ノード, 1.2 データベースのPROCESSESパラメータ, 5.2.3 ドメイン変更の伝播, 9.5.4, 10.3.3 ドメイン構成の伝播, 8.5.1, 9.6.1, 10.4.1, 13.18.2 ノード・マネージャのプロパティ・ファイル, 14.5 OAMのプロバイダの順序, 15.5.6.3, 15.6.5.3

R

RACデータベース, 2.1.5, 8.3, A.2

エンタープライズ・デプロイメントのリカバリ, 16.6

ホーム・ページへのリダイレクト, 16.8.3, 16.8.7

ログイン画面へのリダイレクト, 16.8.2

参照トポロジ, 2.1

Oracle HTTP Serverの登録, 8.6.3

ページレット・プロデューサの登録, 12.5

ポートレット・プロデューサの登録, 12.4

リポジトリ作成ユーティリティ(RCU), 5.1, 5.4

要件

データベース・ホスト, 5.2.1

ロード・バランサ, 2.1.3.1

要件、ハードウェア, 2.2 再開

管理サーバー, 13.18.3

ノード・マネージャの再起動, 9.5.2

S

Oracle Databaseアダプタのスケーリング, 9.9.3

トポロジのスケール・アウト, 16.5

トポロジのスケール・アップ, 16.4

Oracle WebCenter Content, 16.4.3, 16.5.3

スクリプト

configure-joc.py, 8.5.5, 10.5

createCentralInventory.sh, 6.2.2, 6.3.2.1

leasing.ddl, 14.2

oracleRoot.sh, 6.2.2

setDomainEnv.sh, 15.7.1

setNMProps.sh, 8.4.2, 8.5.3

wlsifconfig.sh, 14.6, 14.6

2次ノード, 1.2 セキュリティ, 1.3.1 セキュリティ・フィルタ, 13.18.5.1 自己署名証明書, 11.3.1, 11.5.1 サーバーの移行, 14

ターゲットの構成, 14.7

マルチデータ・ソースの作成, 14.3

ノード・マネージャのプロパティ・ファイルの編集, 14.5

SSL通信の有効化, 14.4

リース表, 14.2

マルチデータ・ソース, 14.3

環境とスーパー・ユーザー権限の設定, 14.6

ユーザーと表領域の設定, 14.2

テスト, 14.8

管理コンソールからの検証, 14.8

サーバー, 8.3

クラスタへの割当て, 9.3, 10.2

マシンへの割当て, 9.3, 10.2

サービス・レベル合意, 1.1 setDomainEnv.shスクリプト, 15.7.1 setNMProps.shスクリプト, 8.4.2, 8.5.3 Javaオブジェクト・キャッシュの設定, 10.5 ノード・マネージャの設定, 11 WebLogic認証プロバイダの設定, 15.5.6, 15.6.5 共有JMS永続ストア, 9.3 共有記憶域, 1.2, 4.1, 4.3

構成, 4.4

SOAHOSTノード, 8.2, 8.3, 8.4.1, 8.4.2, 8.5.3, 9.5.2, 10.3.2, 13.5

Oracle SOA Suiteのインストール, 6.3.2.1

SOAHOST1VHn仮想ホスト, 9.4.1 Spaces

ディスカッション・サーバー, 12.1

SQLNet接続、タイムアウト, 16.7 SSLの高速化, 2.1.3.1 SSL通信, 11.3, 11.5, 14.4 SSOモード, 15.7.1 管理サーバーの起動, 8.4.3 ノード・マネージャの起動, 8.4.2, 8.5.3, 10.3.2, 10.4.2, 11.4, 11.6, 13.5 WC_Collaboration管理対象サーバーの起動, 10.4.3, 10.4.6 WC_Portlet管理対象サーバーの起動, 10.4.3, 10.4.6 WC_Spaces管理対象サーバーの起動, 10.4.3, 10.4.6 WC_Utilities管理対象サーバーの起動, 10.4.3, 10.4.6 WLS_SOA管理対象サーバーの起動, 9.5.5, 9.6.2 WLS_WSM管理対象サーバーの起動, 8.4.9, 8.5.4 記憶域, 4.1, 4.3 インストールの計画, 2.5.3 スーパーユーザー権限, 14.6 サポートされているデータベース・バージョン, 5.2.2 スイッチバック, 1.2 スイッチオーバー, 1.2

T

ターゲット指定されるアプリケーション, 9.3

デプロイメントのターゲット設定, 8.3

サーバー移行のターゲット, 14.7

サーバー移行のテスト, 14.8

SQLNet接続のタイムアウト, 16.7

トポロジ, 2.1

アプリケーション層, 2.1.4

データ層, 2.1.5

データベース, 5.1

ディレクトリ構造, 4.1

管理, 16

監視, 16.1

ネットワーク, 3

スケール・アウト, 16.5

スケール・アップ, 16.4

スケール・アップ(Oracle WebCenter Content), 16.4.3, 16.5.3

共有記憶域, 4.1

Web層, 2.1.3

トランザクション・リカバリ, 9.8 トラブルシューティング

管理サーバーでの変更のアクティブ化, 16.8.1

誤ったURL, 16.8.9

手動フェイルオーバー, 16.8.5

使用不可のポートレット, 16.8.6

ホーム・ページへのリダイレクト, 16.8.3, 16.8.7

ログイン画面へのリダイレクト, 16.8.2

信頼キーストア, 11.3.3

U

UMSドライバ, 16.3

ユニキャスト通信, 2.1.6, 9.4

unpackユーティリティ, 8.5.1, 9.6.1, 10.4.1

ホスト識別子の更新, 15.5.3.6

WebGateプロファイルの更新, 15.5.3.7

URL、コールバック, 9.7.3

utils.CertGenユーティリティ, 11.3.1, 11.5.1

utils.ImportPrivateKeyユーティリティ, 11.3.2, 11.5.2

V

検証

ロード・バランサを使用したアクセス, 10.11.3

Oracle HTTP Serverを使用したアクセス, 8.6.5, 8.6.7, 9.7.2, 10.11.2

管理サーバー, 8.4.5

Oracle HTTP Server, 7.6

サーバーの移行, 14.8

WC_Collaboration管理対象サーバー, 10.4.5, 10.4.7

WC_Portlet管理対象サーバー, 10.4.5, 10.4.7

WC_Spaces管理対象サーバー, 10.4.5, 10.4.7

WC_Utilities管理対象サーバー, 10.4.5, 10.4.7

Web層のインストール, 7.3

WLS_SOA管理対象サーバー, 9.5.5, 9.6.2

WLS_WSM管理対象サーバー, 8.4.9, 8.5.4, 9.5.5

ホスト名の検証, 8.4.8, 8.5.2, 9.5.1, 10.3.1 VIP, 3.4, 3.4

SOAHOST1上でのADMINVHNの有効化, 8.2

仮想ホスト名, 1.2 仮想IP, 1.2, 1.2 仮想IP (VIP), 3.4, 3.4 仮想サーバー名, 3.2 仮想サーバー, 2.1.3.1

admin.mycompany.com, 3.2.2

wcpinternal.mycompany.com, 3.2.3

wcp.mycompany.com, 3.2.1

httpd.confの<VirtualHost>エントリ, 7.6.1

W

WC_Collaboration管理対象サーバー, 10.4.3, 10.4.5, 10.4.6, 10.4.7, 10.11.1

WC_Portlet管理対象サーバー, 10.4.3, 10.4.5, 10.4.6, 10.4.7, 10.11.1

WC_Spaces管理対象サーバー, 10.4.3, 10.4.5, 10.4.6, 10.4.7, 10.11.1

WC_Utilities管理対象サーバー, 10.4.3, 10.4.5, 10.4.6, 10.4.7, 10.11.1

WCPHOST

ドメイン構成の伝播, 13.18.2

WCPHOSTノード, 10.3.2, 10.4.2 wcpinternal.mycompany.com, 3.2.3 wcp.mycompany.com, 3.2.1 Web層, 2.1.3

WebLogicドメインとの関連付け, 7.4

インストールの検証, 7.3

WebCenter Portal

認証, 15.8

OAM用のアプリケーションの構成, 15.7

ホスト名検証の無効化, 10.3.1

ドメインの拡張, 10, 10.2

Oracle Fusion Middlewareのインストール, 6.3.2.2

WebCenter Portal Spaces

管理者ロール, 15.7.2

Javaオブジェクト・キャッシュ, 10.5

ポートレット・プロデューサ, 12.4.1

SSOモード, 15.7.1

ワークフロー, 12.3.2

ワークリスト, 12.3.2

WebClipping URL, 12.4 WebGate, 2.1.3, 15.5.4 WebGateプロファイル, 15.5.3.7 WEBHOST

Web層とWebLogicドメインの関連付け, 7.4

ロード・バランサとOHSの構成 7.5

Web層の構成, 7.2

WEBHOSTノード, 2.1.3, 6.2.2 WebLogic管理者、LDAPへの移動, 15.2.2 WebLogic認証プロバイダ, 15.5.6, 15.6.5 WebLogic構成ウィザード, 8.3 WebLogic Scripting Tool(WLST)

ディスカッション・サーバー, 12.1.2

ポートレット・プロデューサ, 12.4.2

ワークフロー, 12.3.3

ワークリスト, 12.3.3

WebLogic Serverホーム, 1.2 WebLogic Server、「Oracle WebLogic Server」を参照 WL_HOME, 4.2 WLS_SOA

ホスト名検証の無効化, 9.5.1

WLS_WCC管理対象サーバー, 13.18.1 WLS_WSM, 8.4.1, 8.6.1, 8.6.1

ホスト名検証の無効化, 8.4.8, 8.5.2

起動, 8.4.9, 8.5.4

検証, 8.4.9, 8.5.4

wlsifconfig.shスクリプト, 14.6, 14.6 WLST、「WebLogic Scripting Tool」を参照 ワークフロー, 12.3 ワークリスト, 12.3

Copyright © 2009, 2012, Oracle and/or its affiliates. All rights reserved.