Fusion Middleware 高可用性ガイド

11g リリース1(11.1.1)

B55898-07(原本部品番号:E10106-20)

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

1 高可用性の概要

- 1.1 高可用性とは

- 1.1.1 高可用性の問題

- 1.1.2 高可用性ソリューション

- 1.2 他のドキュメントで提供される高可用性情報

2 Oracle Fusion Middlewareの高可用性フレームワーク

- 2.1 Oracle Fusion Middlewareの主要概要の理解

- 2.1.1 WebLogic Serverドメインとは

- 2.1.1.1 管理サーバーとは

- 2.1.1.2 管理対象サーバーおよび管理対象サーバー・クラスタの理解

- 2.1.1.3 ノード・マネージャとは

- 2.1.2 システム・コンポーネント・ドメインとは

- 2.1.3 Middlewareホームとは

- 2.1.4 Oracleホームとは

- 2.1.4.1 Oracle共通ホームとは

- 2.1.5 WebLogic Serverホームとは

- 2.2 Oracle Fusion Middlewareの高可用性の用語

- 2.3 Oracle Fusion Middlewareの高可用性ソリューション

- 2.3.1 ローカル高可用性

- 2.3.2 Oracle Fusion Middlewareの高可用性テクノロジ

- 2.3.2.1 サーバーのロード・バランシング

- 2.3.3 アクティブ/パッシブ・デプロイメント

- 2.3.4 アクティブ/アクティブおよびアクティブ/パッシブ・ソリューションについて

- 2.3.5 障害時リカバリ

- 2.4 計画停止および計画外停止からの保護

3 WebLogic Serverの高可用性

- 3.1 WebLogic Serverクラスタとは

- 3.2 WebLogic ServerクラスタとWebLogic Serverドメイン

- 3.3 クラスタリングの利点

- 3.4 クラスタの主要機能

- 3.4.1 アプリケーションのフェイルオーバー

- 3.4.2 サーバーの移行

- 3.4.3 ロード・バランシング

- 3.5 クラスタ化可能なオブジェクトのタイプ

- 3.6 クラスタ内の通信

- 3.7 クラスタワイドのJNDIネーミング・サービス

- 3.8 クラスタ内のフェイルオーバーとレプリケーション

- 3.8.1 セッション・レプリケーション

- 3.9 サーバー全体の移行

- 3.9.1 サーバー全体の移行におけるノード・マネージャの役割

- 3.9.2 サーバー移行処理と通信

- 3.9.2.1 移行可能なサーバーを含むクラスタでの起動プロセス

- 3.9.2.2 サーバー全体の自動移行処理

- 3.9.2.3 サーバー全体の手動移行処理

- 3.9.2.4 サーバー全体の移行における管理サーバーの役割

- 3.9.2.5 クラスタ内の移行可能なサーバーの動作

- 3.9.2.6 サーバー全体の移行におけるクラスタ・マスターの役割

- 3.10 JMSおよびJTAの高可用性

- 3.10.1 ユーザー優先サーバーと候補サーバー

- 3.10.2 NFSでのファイル・ストアの使用に関する考慮事項

- 3.11 管理サーバーおよびノード・マネージャの高可用性

- 3.11.1 管理サーバーの障害

- 3.11.2 ノード・マネージャの障害

- 3.12 ロード・バランシング

- 3.13 GridLinkデータ・ソース

- 3.14 マルチ・データ・ソース

- 3.15 クラスタの構成とconfig.xml

- 3.16 シングルトン・サービスについて

- 3.17 WebLogic ServerおよびLDAPの高可用性

4 可用性の高いOracle Databaseアクセスの考慮事項

- 4.1 Oracle Real Application ClustersとFusion Middleware

- 4.1.1 Oracle WebLogic ServerにデプロイされるJavaベースのOracle Fusion Middlewareコンポーネント

- 4.1.2 GridLinkデータ・ソースおよびOracle RAC

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

- 4.1.3.1 MDSリポジトリのためのマルチ・データ・ソースの構成

- 4.1.3.2 Oracle RACの構成要件

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

- 4.1.4 Oracle RACでのGridLinkデータ・ソースの構成

- 4.1.5 Oracle RACでのマルチ・データ・ソースの構成

- 4.1.6 JDBCクライアント

- 4.1.7 システム・クライアント

- 4.1.7.1 Oracle Internet Directory

- 4.1.7.2 Oracle Forms

- 4.1.7.3 Oracle Portal

- 4.1.7.4 Oracle ReportsとOracle Discoverer

- 4.2 ファイアウォールのタイムアウトからのアイドル接続の保護

- 4.3 トラブルシューティング

- 4.4 Oracle Database 11g (11.2)でのSCANアドレスの使用

5 Oracle SOA Suiteの高可用性の構成

- 5.1 Oracle SOA Suiteの概要

- 5.2 Oracle SOAサービス・インフラストラクチャの高可用性

- 5.2.1 Oracle SOAサービス・インフラストラクチャの単一インスタンスの特性

- 5.2.1.1 Oracle SOAサービス・インフラストラクチャ・アプリケーションの特性

- 5.2.1.2 Oracle SOAサービス・インフラストラクチャの起動とシャットダウンのライフサイクル

- 5.2.1.3 Oracle SOAサービス・インフラストラクチャの外部依存性

- 5.2.1.4 Oracle SOAサービス・インフラストラクチャのプロセスの起動とシャットダウン

- 5.2.1.5 Oracle SOAサービス・インフラストラクチャの構成アーティファクト

- 5.2.1.6 Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所

- 5.2.2 Oracle SOAサービス・インフラストラクチャの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.2.2.1 Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作

- 5.2.2.1.1 WebLogic Serverの障害

- 5.2.2.1.2 ノード障害

- 5.2.2.1.3 データベース障害

- 5.2.2.2 Oracle SOAサービス・インフラストラクチャのクラスタワイドのデプロイメント

- 5.2.2.3 クラスタ内でのOracle SOAサービス・インフラストラクチャ・コンポジットのオンライン再デプロイメント

- 5.2.2.4 Oracle SOAサービス・インフラストラクチャのクラスタワイドの構成変更

- 5.3 Oracle BPEL Process Managerと高可用性の概要

- 5.3.1 Oracle BPEL Process Managerの単一インスタンスの特性

- 5.3.1.1 BPEL Process Managerのコンポーネントの特性

- 5.3.1.2 Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル

- 5.3.1.3 Oracle BPEL Process Managerのリクエスト・フローとリカバリ

- 5.3.1.4 Oracle BPEL Process Managerの構成アーティファクト

- 5.3.2 Oracle BPEL Process Managerの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.3.2.1 Oracle BPEL Process Managerの障害からの保護および予想される動作

- 5.3.2.1.1 失敗したBPELインスタンスおよびMediatorインスタンスのリカバリ

- 5.3.2.2 Oracle BPEL Process Managerのクラスタワイドの構成変更

- 5.4 Oracle BPM Suiteと高可用性の概要

- 5.4.1 Oracle BPM Suiteの単一インスタンスの概要

- 5.4.1.1 Oracle BPM Suiteのコンポーネントの特性

- 5.4.1.2 Oracle BPM Suiteのコンポーネントの相互作用

- 5.4.1.3 Oracle BPM Suiteの起動とシャットダウンのライフサイクル

- 5.4.1.4 Oracle BPM Suiteの構成アーティファクト

- 5.4.2 Oracle BPMNサービス・エンジンの高可用性

- 5.4.2.1 Oracle BPMNサービス・エンジンの単一インスタンスの特性

- 5.4.2.1.1 Oracle BPMNサービス・エンジンの単一インスタンス・アーキテクチャ

- 5.4.2.1.2 Oracle BPMNサービス・エンジンの外部依存性

- 5.4.2.1.3 Oracle BPMNサービス・エンジンの起動とシャットダウンのライフサイクル

- 5.4.2.1.4 Oracle BPMNサービス・エンジンのログ・ファイル

- 5.4.2.2 Oracle BPMNサービス・エンジンの高可用性に関する考慮事項

- 5.4.2.2.1 Oracle BPMNサービス・エンジンの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.4.2.2.2 高可用性のためのOracle BPMNサービス・エンジンの構成

- 5.4.2.2.3 Oracle BPMNサービス・エンジンのクラスタワイドの構成変更

- 5.4.3 Oracle Business Process Webアプリケーションの高可用性

- 5.4.3.1 Oracle Business Process Webアプリケーションの単一インスタンスの特性

- 5.4.3.1.1 Oracle Business Process Webアプリケーションの単一インスタンス・アーキテクチャ

- 5.4.3.1.2 Oracle Business Process Webアプリケーションの外部依存性

- 5.4.3.1.3 Oracle Business Process Webアプリケーションの起動とシャットダウンのライフサイクル

- 5.4.3.1.4 Oracle Business Process Webアプリケーションのログ・ファイル

- 5.4.3.2 Oracle Business Process Webアプリケーションの高可用性に関する考慮事項

- 5.4.3.2.1 Oracle Business Process Webアプリケーションの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.4.3.2.2 高可用性のためのOracle Business Process Webアプリケーションの構成

- 5.4.3.2.3 Oracle Business Process Webアプリケーションのクラスタワイドの構成変更

- 5.4.4 Oracle Business Process Analyticsの高可用性

- 5.4.4.1 Oracle Business Process Analyticsの単一インスタンスの特性

- 5.4.4.1.1 Oracle Business Process Analyticsの単一インスタンス・アーキテクチャ

- 5.4.4.1.2 Oracle Business Process Analyticsの外部依存性

- 5.4.4.1.3 Oracle Business Process Analyticsの起動とシャットダウンのライフサイクル

- 5.4.4.1.4 Oracle Business Process Analyticsのログ・ファイル

- 5.4.4.2 Oracle Business Process Analyticsの高可用性に関する考慮事項

- 5.4.4.2.1 Oracle Business Process Analyticsの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.4.4.2.2 高可用性のためのOracle Business Process Analyticsの構成

- 5.4.4.2.3 Oracle Business Process Analyticsのクラスタワイドの構成変更

- 5.5 Oracle Mediatorと高可用性の概要

- 5.5.1 Oracle Mediatorの単一インスタンスの特性

- 5.5.1.1 Oracle Mediatorのコンポーネントの特性

- 5.5.1.2 Oracle Mediatorの起動とシャットダウンのライフサイクル

- 5.5.1.3 Oracle Mediatorのリクエスト・フロー

- 5.5.1.4 Oracle Mediatorの構成アーティファクト

- 5.5.2 Oracle Mediatorの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.5.2.1 Oracle Mediatorの障害からの保護および予想される動作

- 5.5.2.1.1 失敗したMediatorインスタンスのリカバリ

- 5.5.2.1.2 Oracle Mediatorのクラスタでの再順序付け

- 5.5.2.2 Oracle Mediatorの高可用性のトラブルシューティング

- 5.6 Oracle Human Workflowと高可用性の概要

- 5.6.1 Oracle Human Workflowの単一インスタンスの特性

- 5.6.1.1 Oracle Human Workflowの起動とシャットダウンのライフサイクル

- 5.6.1.2 Oracle Human Workflowのリクエスト処理

- 5.6.1.3 Oracle Human Workflowの構成アーティファクト

- 5.6.1.3.1 ヒューマン・タスク・サービス・コンポーネントのタスク詳細アプリケーションのURIの管理

- 5.6.2 Oracle Human Workflowの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.6.2.1 Oracle Human Workflowの障害からの保護および予想される動作

- 5.6.2.2 拒否メッセージ表でのHuman Workflowタスクに必要な手動リカバリ

- 5.6.3 Oracle Human Workflowの高可用性のトラブルシューティング

- 5.7 Oracle B2Bと高可用性の概要

- 5.7.1 Oracle B2Bの単一インスタンスの特性

- 5.7.1.1 Oracle B2Bのコンポーネントの特性

- 5.7.1.2 Oracle B2Bの起動とシャットダウンのライフサイクル

- 5.7.1.3 Oracle B2Bのリクエスト・フロー

- 5.7.1.4 Oracle B2Bの構成アーティファクト

- 5.7.2 Oracle B2Bの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.7.2.1 Oracle B2Bの障害からの保護および予想される動作

- 5.7.2.2 Oracle B2Bのクラスタワイドの構成変更

- 5.7.2.3 クラスタ内へのOracle B2Bのデプロイメント

- 5.7.2.4 Oracle B2Bのアクティブ/アクティブ構成のトラブルシューティング

- 5.7.2.4.1 B2Bメタデータのパージ、インポートまたはデプロイメント

- 5.7.2.4.2 Oracle B2Bのドキュメント定義取得時のエラー

- 5.8 Oracle Web Service Managerと高可用性の概要

- 5.8.1 Oracle WSMの単一インスタンスの特性

- 5.8.1.1 Oracle WSMのコンポーネントの特性

- 5.8.1.2 Oracle WSMの起動とシャットダウンのライフサイクル

- 5.8.1.3 Oracle WSMのリクエスト・フロー

- 5.8.1.4 Oracle WSMの構成アーティファクト

- 5.8.2 Oracle WSMの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.8.2.1 Oracle WSMの障害からの保護および予想される動作

- 5.8.2.2 Oracle WSMのクラスタワイドの構成変更

- 5.8.2.3 Oracle WSMのJavaオブジェクト・キャッシュの構成

- 5.8.2.4 MDSリポジトリに対する分散通知の構成

- 5.9 Oracle User Messaging Serviceと高可用性の概要

- 5.9.1 Oracle User Messaging Serviceの単一インスタンスの特性

- 5.9.1.1 Oracle User Messaging Serviceのコンポーネントの特性

- 5.9.1.2 Oracle User Messaging Serviceの起動とシャットダウンのライフサイクル

- 5.9.1.3 Oracle User Messaging Serviceのリクエスト・フロー

- 5.9.1.4 Oracle User Messaging Serviceの構成アーティファクト

- 5.9.2 Oracle User Messaging Serviceの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.9.2.1 Oracle User Messaging Serviceの障害からの保護および予想される動作

- 5.9.2.2 Oracle User Messaging Serviceのクラスタワイドの構成変更

- 5.10 Oracle JCAアダプタと高可用性の概要

- 5.10.1 Oracle JCAアダプタの単一インスタンスの特性

- 5.10.1.1 Oracle JCAアダプタのコンポーネントのライフサイクル

- 5.10.1.2 Oracle JCAアダプタの信頼性とトランザクションの動作

- 5.10.1.3 Oracle JCAアダプタ: 拒否メッセージの処理

- 5.10.2 Oracle JCAアダプタの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.10.2.1 Oracle JCAアダプタの高可用性に関するエラーの処理

- 5.10.2.2 Oracle File AdapterとOracle FTP Adapterの高可用性

- 5.10.2.3 Oracle Databaseアダプタの高可用性

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

- 5.10.2.4.1 メッセージ再配信

- 5.10.2.4.2 WebLogic Server分散宛先の使用

- 5.10.2.5 Oracle JCAアダプタのログ・ファイルの場所

- 5.11 Oracle Business Activity Monitoringと高可用性の概要

- 5.11.1 Oracle Business Activity Monitoringの単一インスタンスの特性

- 5.11.1.1 Oracle Business Activity Monitoringのコンポーネントの特性

- 5.11.1.2 Oracle Business Activity Monitoringの起動とシャットダウンのライフサイクル

- 5.11.1.3 Oracle Business Activity Monitoringのプロセスの起動とシャットダウン

- 5.11.1.4 Oracle Business Activity Monitoringの構成アーティファクト

- 5.11.2 Oracle Business Activity Monitoringの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.11.2.1 Oracle Business Activity Monitoringの障害からの保護および予想される動作

- 5.11.2.2 Oracle Business Activity Monitoringのクラスタワイドの構成変更

- 5.11.2.3 BAMクライアントの再試行に関する考慮事項

- 5.12 Oracle Service Busと高可用性の概要

- 5.12.1 Oracle Service Busの単一ノードの特性

- 5.12.1.1 Oracle Service Busのセッション状態

- 5.12.1.2 Oracle Service Bus外部依存性

- 5.12.1.3 Oracle Service Busの構成アーティファクト

- 5.12.1.4 Oracle Service Busのデプロイメント・アーティファクト

- 5.12.1.5 Oracle Service Busの起動とシャットダウン

- 5.12.1.6 Oracle Service Busのログ・ファイルの場所

- 5.12.2 Oracle Service Busの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 5.12.2.1 Oracle Service Busの障害からの保護および予想される動作

- 5.12.2.1.1 WebLogic Serverの障害

- 5.12.2.1.2 ノード障害

- 5.12.2.1.3 データベース障害

- 5.12.2.2 Oracle Service Busのクラスタワイドのデプロイメント

- 5.12.2.3 クラスタ内のOracle Service Busのオンライン再デプロイメント

- 5.12.2.4 Oracle Service Busのクラスタワイドの構成変更

- 5.13 Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成

- 5.13.1 環境の準備: SOAの高可用性構成の設定前に必要な手順

- 5.13.1.1 データベースに関する前提条件

- 5.13.1.2 VIPとIPに関する前提条件

- 5.13.1.3 共有記憶域に関する前提条件

- 5.13.1.4 LDAPプロバイダのインストールと構成

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

- 5.13.1.6 ディレクトリおよびディレクトリ環境変数の用語

- 5.13.1.7 データベース・リポジトリのインストールと構成

- 5.13.1.8 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード

- 5.13.1.8.1 RCUの実行

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

- 5.13.1.9 ロード・バランサの仮想サーバー名とポートの構成

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

- 5.13.1.10.1 Oracle HTTP Serverの検証

- 5.13.2 Oracle Fusion Middlewareホームのインストール

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

- 5.13.2.2 Oracle SOA用Oracle Fusion Middlewareのインストール

- 5.13.3 SOAHOST1のVIP1およびSOAHOST2のVIP2の有効化

- 5.13.4 SOAのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行

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

- 5.13.6 SOAHOST1での管理サーバーの起動と検証

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

- 5.13.6.2 管理サーバーの検証

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

- 5.13.8 コンポジットのデプロイでのOracle Coherenceの構成

- 5.13.9 SOAHOST1でのシステムの起動

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

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

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

- 5.13.11 第2ノードのXEngineファイルの抽出

- 5.13.12 SOAHOST2でのシステムの起動

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

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

- 5.13.13 Oracle HTTP Serverの管理サーバーおよびWLS_SOAn管理対象サーバーの構成

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

- 5.13.15 サーバー間で共有するJMS永続ストアの構成

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

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

- 5.13.18 コンポジットへの直接バインディング/RMI呼出しのためのWLSクラスタ・アドレスの設定

- 5.13.19 アプリケーションのデプロイ

- 5.13.20 WLS_SOAサーバーのサーバー移行の構成

- 5.13.20.1 サーバー移行leasing表のユーザーと表領域の設定

- 5.13.20.2 Oracle WebLogic管理コンソールを使用したGridLinkデータ・ソースまたはマルチ・データ・ソースの作成

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

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

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

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

- 5.13.21 トポロジのスケーリング

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

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

- 5.14 Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンを使用するOracle Service Busの高可用性の構成

- 5.14.1 環境の準備: SOAの高可用性構成の設定前に必要な手順

- 5.14.1.1 データベースに関する前提条件

- 5.14.1.2 VIPとIPに関する前提条件

- 5.14.1.3 共有記憶域に関する前提条件

- 5.14.1.4 LDAPプロバイダのインストールと構成

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

- 5.14.1.6 ディレクトリおよびディレクトリ環境変数の用語

- 5.14.1.7 データベース・リポジトリのインストールと構成

- 5.14.1.8 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード

- 5.14.1.8.1 RCUの実行

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

- 5.14.1.9 ロード・バランサの仮想サーバー名とポートの構成

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

- 5.14.1.10.1 Oracle HTTP Serverの検証

- 5.14.2 Oracle Fusion Middlewareホームのインストール

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

- 5.14.2.2 Oracle SOA用Oracle Fusion Middlewareのインストール

- 5.14.2.3 Oracle Service Busのインストール

- 5.14.3 SOAHOST1のVIP1とVIP3およびSOAHOST2のVIP2とVIP4の有効化

- 5.14.4 SOAとOSBのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行

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

- 5.14.6 SOAHOST1での管理サーバーの起動と検証

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

- 5.14.6.2 管理サーバーの検証

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

- 5.14.8 コンポジットのデプロイでのOracle Coherenceの構成

- 5.14.9 Oracle Service Busの結果キャッシュのOracle Coherenceの構成

- 5.14.10 B2Bキューの接続宛先識別子の設定

- 5.14.11 SOAHOST1でのシステムの起動

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

- 5.14.11.2 管理対象サーバーWLS_SOA1の起動と確認

- 5.14.12 pack/unpackユーティリティを使用したSOAHOST2、OSBHOST1およびOSBHOST2へのドメイン構成の伝播

- 5.14.13 第2ノードのXEngineファイルの抽出

- 5.14.14 SOAHOST2、OSBHOST1およびOSBHOST2でのシステムの起動

- 5.14.14.1 SOAHOST2、OSBHOST1およびOSBHOST2でのノード・マネージャの起動

- 5.14.14.2 管理対象サーバーWLS_SOA2、WLS_OSB1およびWLS_OSB2の起動と検証

- 5.14.15 管理サーバーおよび管理対象サーバーWLS_SOAnとWLS_OSBnのOracle HTTP Serverの構成

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

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

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

- 5.14.19 アプリケーションのデプロイ

- 5.14.20 WLS_SOAサーバーのサーバー移行の構成

- 5.14.21 WLS_OSBサーバーのサーバー移行の構成

- 5.14.22 トポロジのスケーリング

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

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

- 5.15 Oracle BAMの高可用性の構成

- 5.15.1 環境の準備: Oracle BAMの高可用性構成の設定前に必要な手順

- 5.15.1.1 データベースに関する前提条件

- 5.15.1.2 VIPとIPに関する前提条件

- 5.15.1.3 データベース・リポジトリのインストールと構成

- 5.15.1.4 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したOracle Fusion Middlewareスキーマのロード

- 5.15.1.4.1 RCUの実行

- 5.15.1.5 ロード・バランサの仮想サーバー名とポートの構成

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

- 5.15.2.1 Oracle HTTP Serverの検証

- 5.15.3 Oracle Fusion Middlewareホームのインストール

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

- 5.15.3.2 Oracle SOA Suiteインストーラを使用したOracle BAMのインストール

- 5.15.4 BAMHOST1でのVIP0とVIP1の有効化

- 5.15.5 WebLogic ServerのOracle BAMドメインを作成するためのBAMHOST1でのOracle Fusion Middleware構成ウィザードの実行

- 5.15.6 BAMHOST1での管理サーバー用およびWLS_BAM1用boot.propertiesの作成

- 5.15.7 BAMHOST1での管理サーバーの起動

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

- 5.15.9 BAM UMS用のJMS永続ストアの構成

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

- 5.15.11 BAMHOST2からのBAM Serverシステムのターゲット指定解除

- 5.15.12 pack/unpackユーティリティを使用したBAMHOST1からのドメイン構成の伝播

- 5.15.13 BAMHOST1およびBAMHOST2でのノード・マネージャの起動

- 5.15.14 Oracle BAMシステムの起動

- 5.15.15 WLS_BAMサーバーのOracle RACフェイルオーバーの構成

- 5.15.16 BAMHOST1でBAM Serverを使用するためのBAM Webアプリケーションの構成

- 5.15.17 Oracle HTTP Serverの管理サーバーおよびWLS_BAMn管理対象サーバーの構成

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

- 5.15.19 WLS_BAMサーバーのサーバー移行の構成

- 5.15.19.1 サーバー移行leasing表のユーザーと表領域の設定

- 5.15.19.2 管理コンソールからのGridLinkデータ・ソースまたはマルチ・データ・ソースの作成

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

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

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

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

- 5.15.20 BAMシステムに接続するクライアントの構成

6 Oracle ADFおよびWebCenterポータル・アプリケーションの高可用性の構成

- 6.1 Oracle ADFと高可用性の概要

- 6.1.1 Oracle ADFの理解

- 6.1.1.1 Oracle ADFコンポーネント

- 6.1.1.1.1 ADFビジネス・コンポーネント

- 6.1.1.1.2 ADF Modelレイヤー

- 6.1.1.1.3 ADF Controller

- 6.1.1.1.4 ADF Faces Rich Client

- 6.1.1.2 Oracle ADFの単一ノード・アーキテクチャ

- 6.1.1.3 Oracle ADFの外部依存性

- 6.1.1.4 Oracle ADFのログ・ファイル

- 6.1.2 Oracle ADFの高可用性に関する考慮事項

- 6.1.2.1 Oracle ADFのスコープとセッションの状態

- 6.1.2.2 Oracle ADFのフェイルオーバーおよび予想される動作

- 6.1.2.3 Oracle ADFのアクティブ・データ・サービス

- 6.1.2.4 Oracle RAC用ADFアプリケーション・モジュールの構成

- 6.1.3 高可用性のためのOracle ADFの構成

- 6.1.3.1 アプリケーション・モジュールの構成

- 6.1.3.2 weblogic.xmlの構成

- 6.1.3.3 adf-config.xmlの構成

- 6.1.3.4 org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONの構成

- 6.1.4 Oracle ADFの高可用性のトラブルシューティング

- 6.1.4.1 Oracle ADFの開発に関する問題のトラブルシューティング

- 6.1.4.2 Oracle ADFのデプロイメントに関する問題のトラブルシューティング

- 6.1.4.3 Oracle ADFのレプリケーションおよびフェイルオーバーに関する問題のトラブルシューティング

- 6.2 Oracle ADFの高可用性デプロイメントの構成

- 6.2.1 ディレクトリおよびディレクトリ環境変数の用語

- 6.2.2 RCUを使用したデータベースへのFusion Middlewareスキーマのロード

- 6.2.2.1 RCUの実行

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

- 6.2.3.1 Oracle HTTP Serverの検証

- 6.2.4 Oracle Fusion Middlewareホームのインストール

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

- 6.2.4.2 Oracle ADFアプリケーション用Oracle Fusion Middlewareのインストール

- 6.2.5 管理サーバーの高可用性

- 6.2.6 WebLogic ServerのADFドメインを作成するためのAPPHOST1での構成ウィザードの実行

- 6.2.6.1 APPHOST1での管理サーバーおよび管理対象サーバー用boot.propertiesの作成

- 6.2.7 APPHOST1でのシステムの起動

- 6.2.7.1 APPHOST1での管理サーバーの起動

- 6.2.7.2 管理サーバーの検証

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

- 6.2.7.4 APPHOST1でのノード・マネージャの起動

- 6.2.8 APPHOST2へのOracle WebLogic ServerとOracle ADFのインストール

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

- 6.2.9.1 APPHOST2での管理サーバーおよび管理対象サーバー用boot.propertiesの作成

- 6.2.9.2 APPHOST2でのノード・マネージャの起動

- 6.2.9.3 ADFアプリケーションのレプリケーションの構成

- 6.2.9.4 ADFアプリケーションのデプロイ

- 6.2.9.5 Oracle HTTP Serverの管理サーバーおよびWebCenterポータル管理対象サーバーの構成

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

- 6.2.10 トポロジのスケーリング

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

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

- 6.3 WebCenterポータルと高可用性の概要

- 6.3.1 WebCenterポータルの理解

- 6.3.1.1 WebCenterポータル・コンポーネント

- 6.3.1.2 WebCenterポータルの単一ノード・アーキテクチャ

- 6.3.1.3 WebCenterポータル: 状態と構成の永続性

- 6.3.1.4 WebCenterポータルのログ・ファイルの場所

- 6.3.2 WebCenterの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 6.3.2.1 WebCenterポータル・アプリケーション

- 6.3.2.2 Oracle WebCenterの起動順序

- 6.3.2.3 クラスタへのWebCenterポータル・アプリケーションのデプロイ

- 6.3.2.4 WebCenterポータルのAnalyticsコレクタ

- 6.3.2.5 WebCenterポータルの状態のレプリケーション

- 6.3.2.6 分散Javaオブジェクト・キャッシュの理解

- 6.3.2.7 WebCenterポータルのフェイルオーバーによる保護および予想される動作

- 6.3.2.8 アプリケーションのフェイルオーバーで予想される動作

- 6.3.2.9 アプリケーション・デプロイメントのロギングの監視

- 6.3.2.10 WebCenterポータルのクラスタワイドの構成変更

- 6.3.2.11 クラスタ環境での構成の保持

- 6.4 WebCenterポータルの高可用性の構成

- 6.4.1 環境の準備: WebCenterポータルの高可用性構成の設定前に必要な手順

- 6.4.1.1 データベースに関する前提条件

- 6.4.1.2 VIPとIPの前提条件

- 6.4.1.3 データベース・リポジトリのインストールと構成

- 6.4.1.4 LDAPプロバイダのインストールと構成

- 6.4.1.5 ディレクトリおよびディレクトリ環境変数の用語

- 6.4.1.6 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード

- 6.4.1.6.1 RCUの実行

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

- 6.4.2.1 Oracle HTTP Serverの検証

- 6.4.3 Oracle Fusion Middlewareホームのインストール

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

- 6.4.3.2 WebCenterポータル用のOracle Fusion Middlewareのインストール

- 6.4.4 管理サーバーのVIPの有効化

- 6.4.5 WebLogic Server WebCenterのドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行

- 6.4.6 APPHOST1での管理サーバーおよび管理対象サーバー用boot.propertiesの作成

- 6.4.7 APPHOST1でのシステムの起動

- 6.4.7.1 APPHOST1での管理サーバーの起動

- 6.4.7.2 管理サーバーの検証

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

- 6.4.7.4 APPHOST1でのノード・マネージャの起動

- 6.4.8 APPHOST2でのWebLogic ServerおよびWebCenterポータルのインストール

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

- 6.4.10 APPHOST2でのノード・マネージャの起動

- 6.4.11 Oracle HTTP Serverの管理サーバーおよびWebCenterポータル管理対象サーバーの構成

- 6.4.11.1 Oracleページレット・プロデューサおよびSharepointの仮想ホストの構成

- 6.4.11.1.1 仮想ホストの要件

- 6.4.11.1.2 追加の構成

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

- 6.4.12 APPHOST2への管理サーバーの手動フェイルオーバーの構成

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

- 6.4.14 MDSリポジトリに対する分散通知の構成

- 6.4.15 WebCenterポータルのレプリケーションの構成

- 6.4.16 Analyticsの構成

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

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

- 6.4.19 トポロジのスケーリング

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

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

- 6.4.20 WebCenterポータルの高可用性のトラブルシューティング

- 6.4.20.1 WebCenterポータルのデプロイメントに関する問題のトラブルシューティング

- 6.4.20.2 WebCenterポータルのレプリケーションおよびフェイルオーバーに関する問題のトラブルシューティング

- 6.4.20.3 ポリシーの変更が失われた場合のトラブルシューティング

- 6.4.20.4 JOC構成のトラブルシューティング

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

- 6.5 WebCenterポータル・アプリケーションの高可用性の構成

- 6.5.1 WebCenterポータル・アプリケーションに対するクラスタの構成

- 6.5.2 WebCenterポータル・アプリケーション・サーバーの追加

- 6.5.3 MDSリポジトリに対する分散通知の構成

7 Oracle Data Integratorの高可用性

- 7.1 Oracle Data Integratorの概要

- 7.2 Oracle Data Integratorの単一インスタンスの特性

- 7.2.1 Oracle Data Integratorセッションのライフサイクルとリカバリ

- 7.2.1.1 セッションの中断

- 7.2.1.2 セッションのリカバリ

- 7.2.2 エージェントの起動とシャットダウンのサイクル

- 7.2.3 Oracle Data Integratorの外部依存性

- 7.2.4 Oracle Data Integratorの起動およびシャットダウン・プロセス

- 7.2.5 Oracle Data Integratorの構成アーティファクト

- 7.2.5.1 Java EEエージェントの構成

- 7.2.5.2 スタンドアロン・エージェント構成

- 7.2.5.3 Oracle Data Integratorコンソールの構成

- 7.2.5.4 Oracle Data Integratorのログの場所と構成

- 7.2.5.4.1 Oracle Data Integratorのセッション・ログ

- 7.2.5.4.2 Java EEエージェントのログ・ファイル

- 7.2.5.4.3 スタンドアロン・エージェントのログ・ファイル

- 7.2.5.4.4 Oracle Data Integratorコンソールのログ・ファイル

- 7.3 Oracle Data Integratorの高可用性とフェイルオーバーに関する考慮事項

- 7.3.1 Oracle Data Integratorのクラスタ・デプロイメント

- 7.3.2 OPMNを使用したスタンドアロン・エージェントの高可用性

- 7.3.3 障害からのOracle Data Integratorの保護および必要な対応

- 7.3.3.1 WebLogic Serverまたはスタンドアロン・エージェントのクラッシュ

- 7.3.3.2 リポジトリ・データベースの障害

- 7.3.3.3 スケジューラ・ノードの障害

- 7.4 Oracle Data Integratorの高可用性の構成

- 7.4.1 マスター・リポジトリと作業リポジトリを作成するためのRCUの実行

- 7.4.2 最初のOracle Data Integratorホストのインストールと構成

- 7.4.2.1 APPHOST1へのOracle WebLogic Serverのインストール

- 7.4.2.2 APPHOST1へのOracle Data Integratorのインストール

- 7.4.2.3 高可用性ドメインの作成

- 7.4.2.4 管理サーバーの起動

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

- 7.4.2.5.1 WLSTを使用した資格証明の構成

- 7.4.2.5.2 Enterprise Managerを使用した資格証明の構成

- 7.4.2.6 デフォルト・エージェントの構成

- 7.4.2.7 クラスタのCoherenceの構成

- 7.4.2.8 ノード・マネージャの構成とodi_server1の起動

- 7.4.2.9 Oracle Data Integratorエージェントが実行されていることの確認

- 7.4.3 2つ目のOracle Data Integratorホストのインストールと構成

- 7.4.3.1 APPHOST2へのOracle WebLogic Serverのインストール

- 7.4.3.2 APPHOST1からAPPHOST2へのドメインのパックと解凍

- 7.4.3.3 ノード・マネージャの構成とodi_server2の起動

- 7.4.3.4 Oracle Data Integratorエージェントが実行されていることの確認

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

- 7.4.4.1 Oracle HTTP Server Oracleホームのアップグレード

- 7.4.4.2 Oracle HTTP Serverの構成

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

- 7.4.4.4 Oracle Data Integratorエージェントが実行されていることの確認

- 7.4.4.5 エージェントの再構成

8 Identity Managementコンポーネントの高可用性の構成

- 8.1 Identity Management製品のコンポーネントと高可用性の概要

- 8.1.1 11g Oracle Identity Management製品について

- 8.2 Oracle Identity Managementの高可用性構成のための前提条件

- 8.2.1 Oracleホームの要件

- 8.2.2 データベースに関する前提条件

- 8.2.3 データベース・リポジトリのインストールと構成

- 8.2.4 リポジトリ作成ユーティリティ・ソフトウェアの取得

- 8.2.4.1 リポジトリ作成ユーティリティの実行

- 8.2.5 Oracle Fusion Middleware 11gメタデータのデータベースの構成

- 8.2.5.1 この章で使用するデータベースの例

- 8.2.5.2 データベース・サービス

- 8.2.5.3 透過的アプリケーション・フェイルオーバー(TAF)の検証

- 8.2.5.4 ロード・バランサの仮想サーバー名とポートの構成

- 8.2.5.4.1 ロード・バランサ

- 8.2.5.4.2 仮想サーバー名

- 8.3 Oracle Internet Directoryの高可用性

- 8.3.1 Oracle Internet Directoryコンポーネント・アーキテクチャ

- 8.3.1.1 Oracle Internet Directoryコンポーネントの特性

- 8.3.1.1.1 ランタイム・プロセス

- 8.3.1.1.2 プロセスのライフサイクル

- 8.3.1.1.3 リクエスト・フロー

- 8.3.1.1.4 構成アーティファクト

- 8.3.1.1.5 外部依存性

- 8.3.1.1.6 Oracle Internet Directoryのログ・ファイル

- 8.3.2 Oracle Internet Directoryの高可用性の概要

- 8.3.2.1 Oracle Internet Directoryの高可用性アーキテクチャ

- 8.3.2.1.1 クラスタの起動と停止

- 8.3.2.1.2 クラスタワイドの構成変更

- 8.3.2.2 障害からの保護および予想される動作

- 8.3.2.2.1 Oracle Internet Directoryプロセスの障害

- 8.3.2.2.2 障害発生時に必要なクライアント・アプリケーションの動作

- 8.3.2.2.3 外部依存性の障害

- 8.3.2.3 Oracle Internet Directoryの前提条件

- 8.3.2.3.1 Oracle Internet Directoryノード間での時間の同期

- 8.3.2.3.2 RCUを使用したリポジトリへのOracle Internet Directoryスキーマの作成

- 8.3.2.3.3 Oracle Internet Directory用のロード・バランサの仮想サーバー名

- 8.3.3 Oracle Internet Directoryの高可用性の構成手順

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

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

- 8.3.3.1.2 アイデンティティ管理用のOracle Fusion Middlewareのインストール

- 8.3.3.1.3 Oracle Identity Managementのアップグレード

- 8.3.3.2 WebLogicドメインを使用しないOracle Internet Directoryの構成

- 8.3.3.2.1 OIDHOST1でのOracle Internet Directoryの構成

- 8.3.3.2.2 Oracle Identity Managementのインストーラによって割り当てられるOracle Internet Directoryのコンポーネント名

- 8.3.3.2.3 OIDHOST2でのOracle Internet Directoryの構成

- 8.3.3.2.4 WebLogicドメインへのOracle Internet Directoryの登録

- 8.3.3.3 WebLogicドメインを使用したOracle Internet Directoryの構成

- 8.3.3.3.1 OIDHOST1でのOracle Internet Directoryの構成

- 8.3.3.3.2 OIDHOST1での管理サーバー用boot.propertiesの作成

- 8.3.3.3.3 OIDHOST2でのOracle Internet Directoryの構成

- 8.3.4 Oracle Internet Directoryの高可用性の検証

- 8.3.5 Oracle Internet Directoryのフェイルオーバーおよび予想される動作

- 8.3.5.1 Oracle Internet Directoryのフェイルオーバーの実行

- 8.3.5.2 Oracle RACフェイルオーバーの実行

- 8.3.6 Oracle Internet Directoryの高可用性のトラブルシューティング

- 8.3.7 Oracle Internet Directoryの高可用性に関するその他の問題

- 8.3.7.1 Oracle Internet Directoryで使用されるODSスキーマのパスワードの変更

- 8.4 Oracle Virtual Directoryの高可用性

- 8.4.1 Oracle Virtual Directoryコンポーネント・アーキテクチャ

- 8.4.1.1 Oracle Virtual Directoryランタイムの考慮事項

- 8.4.1.2 Oracle Virtual Directoryコンポーネントの特性

- 8.4.1.2.1 Oracle Virtual Directoryのログ・ファイル

- 8.4.2 Oracle Virtual Directoryの高可用性の概要

- 8.4.2.1 Oracle Virtual Directoryの高可用性アーキテクチャ

- 8.4.2.1.1 Oracle Virtual Directoryの高可用性の接続機能

- 8.4.2.2 Oracle Virtual Directoryの前提条件

- 8.4.2.2.1 Oracle Virtual Directory用のロード・バランサの仮想サーバー名

- 8.4.3 Oracle Virtual Directoryの高可用性の構成手順

- 8.4.3.1 WebLogicドメインを使用しないOracle Virtual Directoryの構成

- 8.4.3.1.1 OVDHOST1でのOracle Virtual Directoryの構成

- 8.4.3.1.2 OVDHOST2でのOracle Virtual Directoryの構成

- 8.4.3.1.3 WebLogicドメインへのOracle Virtual Directoryの登録

- 8.4.3.2 WebLogicドメインを使用したOracle Virtual Directoryの構成

- 8.4.3.2.1 OVDHOST1でのOracle Virtual Directoryの構成

- 8.4.3.2.2 OVDHOST1での管理サーバー用boot.propertiesの作成

- 8.4.3.2.3 OVDHOST2でのOracle Virtual Directoryの構成

- 8.4.3.3 可用性の高いデータ・ソースを使用したOracle Virtual Directoryの構成

- 8.4.3.3.1 Oracle RACデータベースを使用したOracle Virtual Directoryの構成

- 8.4.3.3.2 LDAPを使用したOracle Virtual Directoryの構成

- 8.4.4 Oracle Virtual Directoryの高可用性の検証

- 8.4.4.1 SSLを使用したOracle Virtual Directoryの高可用性の検証

- 8.4.5 Oracle Virtual Directoryのフェイルオーバーおよび予想される動作

- 8.4.5.1 Oracle Virtual Directoryのフェイルオーバーの実行

- 8.4.5.2 Oracle RACフェイルオーバーの実行

- 8.4.6 Oracle Virtual Directoryの高可用性のトラブルシューティング

- 8.4.6.1 LDAPアダプタ作成のトラブルシューティング

- 8.5 Oracle Directory Integration Platformの高可用性

- 8.5.1 Oracle Directory Integration Platformコンポーネント・アーキテクチャ

- 8.5.1.1 Oracle Directory Integration Platformコンポーネントの特性

- 8.5.1.1.1 ランタイム・プロセス

- 8.5.1.1.2 プロセスのライフサイクル

- 8.5.1.1.3 リクエスト・フロー

- 8.5.1.1.4 構成アーティファクト

- 8.5.1.1.5 外部依存性

- 8.5.1.1.6 Oracle Directory Integration Platformのログ・ファイル

- 8.5.2 Oracle Directory Integration Platformの高可用性の概要

- 8.5.2.1 Oracle Directory Integration Platformの高可用性アーキテクチャ

- 8.5.2.1.1 クラスタの起動と停止

- 8.5.2.1.2 クラスタワイドの構成変更

- 8.5.2.2 障害からの保護および予想される動作

- 8.5.2.2.1 プロセス障害

- 8.5.2.2.2 障害発生時に予想されるクライアント・アプリケーションの動作

- 8.5.2.2.3 外部依存性の障害

- 8.5.2.3 Oracle Directory Integration Platformの前提条件

- 8.5.3 Oracle Directory Integration PlatformおよびOracle Directory Services Managerの高可用性の構成手順

- 8.5.3.1 IDMHOST1でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成

- 8.5.3.2 IDMHOST1での管理サーバー用boot.propertiesの作成

- 8.5.3.3 IDMHOST2でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成

- 8.5.3.4 Oracle Directory Integration PlatformとOracle Directory Services Managerのインストール後の手順

- 8.5.3.4.1 IDMHOST1からIDMHOST2へのOracle Directory Integration Platformの構成のコピー

- 8.5.3.4.2 クラスタ内のIDMHOST2での管理対象サーバーの再起動

- 8.5.3.5 WEBHOST1およびWEBHOST2へのOracle Fusion Middlewareコンポーネントのインストール

- 8.5.3.5.1 Web Tier用のOracle HTTP Serverのインストール

- 8.5.3.5.2 Oracle HTTP Server Oracleホームのパッチ・セット3へのアップグレード

- 8.5.3.6 WEBHOST1およびWEBHOST2でのOracle HTTP Serverの構成

- 8.5.3.6.1 Oracle Directory Services ManagerのためのOracle HTTP Serverの高可用性の構成

- 8.5.4 Oracle Directory Integration Platformのフェイルオーバーおよび予想される動作

- 8.5.5 Oracle Directory Integration Platformの高可用性のトラブルシューティング

- 8.5.5.1 Oracle RACフェイルオーバー時にOracle Directory Integration Platformに関して受信される管理対象サーバー・ログ・ファイルの例外

- 8.5.5.2 WebLogicノード・マネージャの起動後に受信されたエラー・メッセージの処理

- 8.5.5.3 WebLogicノード・マネージャが起動しない場合

- 8.5.5.4 構成の変更が高可用性トポロジのすべてのOracle Directory Integration Platformインスタンスに自動的に伝播されない場合

- 8.5.5.5 不明なエラー・メッセージのため操作を完了できない場合

- 8.6 Oracle Directory Services Managerの高可用性

- 8.6.1 Oracle Directory Services Managerコンポーネント・アーキテクチャ

- 8.6.1.1 Oracle Directory Services Managerコンポーネントの特性

- 8.6.1.1.1 ライフサイクルの管理

- 8.6.1.1.2 Oracle Directory Services Managerのログ・ファイル

- 8.6.2 Oracle Directory Services Managerの高可用性の概要

- 8.6.2.1 Oracle Directory Services Managerの高可用性アーキテクチャ

- 8.6.2.1.1 クラスタの起動と停止

- 8.6.2.2 障害からの保護および予想される動作

- 8.6.2.2.1 プロセス障害

- 8.6.2.2.2 障害発生時に予想されるクライアント・アプリケーションの動作

- 8.6.2.2.3 予想される依存性の障害

- 8.6.2.3 Oracle Directory Services Managerの前提条件

- 8.6.3 Oracle Directory Services Managerの高可用性の構成手順

- 8.6.4 Oracle Directory Services Managerの高可用性の検証

- 8.6.4.1 WebLogic Serverインスタンスのフェイルオーバーの実行

- 8.6.4.2 Oracle RACデータベースのフェイルオーバーの実行

- 8.6.5 Oracle Directory Services Managerのフェイルオーバーおよび予想される動作

- 8.6.5.1 Oracle Directory Services Managerを使用した管理対象サーバーのフェイルオーバーの検証

- 8.6.5.2 Oracle Directory Services Managerを使用したOracle Internet Directoryインスタンスのフェイルオーバーの検証

- 8.6.5.3 Oracle Directory Services Managerを使用したOracle RACのフェイルオーバーの検証

- 8.6.6 Oracle Directory Services Managerのトラブルシューティング

- 8.6.6.1 WebLogicノード・マネージャの起動後に受信されたエラー・メッセージの処理

- 8.6.6.2 WebLogicノード・マネージャが起動しない場合

- 8.6.6.3 Oracle HTTP Serverを使用したOracle Directory Services Managerのフェイルオーバーが透過的に行われない

- 8.6.6.4 Oracle Internet Directoryのフェイルオーバー時に、メッセージ「LDAPサーバーが停止しています。」がOracle Directory Services Managerに表示される

- 8.6.6.5 Oracle RACフェイルオーバー時のOracle Directory Services Managerの一時的な接続の消失

- 8.6.7 Oracle Directory Services Managerの高可用性に関するその他の考慮事項

- 8.7 コロケート・アーキテクチャの高可用性

- 8.7.1 コロケート・アーキテクチャの概要

- 8.7.2 コロケート・アーキテクチャの高可用性デプロイメント

- 8.7.2.1 コロケート・アーキテクチャの前提条件

- 8.7.2.2 高可用性のためのコロケートされたコンポーネントの構成

- 8.7.3 コロケート・コンポーネントの高可用性の検証

- 8.7.3.1 検証テスト

- 8.7.3.2 障害および予想される動作

- 8.7.4 コロケート・コンポーネント・マネージャの高可用性のトラブルシューティング

- 8.7.5 コロケート・コンポーネントの高可用性に関するその他の考慮事項

- 8.8 Oracle Access Managerの高可用性

- 8.8.1 Oracle Access Managerコンポーネント・アーキテクチャ

- 8.8.1.1 Oracle Access Managerコンポーネントの特性

- 8.8.1.1.1 Oracle Access Managerの状態情報

- 8.8.1.1.2 Oracle Access Managerのリクエスト・フロー

- 8.8.1.1.3 Oracle Access Managerプロセスのライフサイクル

- 8.8.1.1.4 Oracle Access Managerの構成アーティファクト

- 8.8.1.1.5 Oracle Access Managerの外部依存性

- 8.8.1.1.6 Oracle Access Managerのログ・ファイルの場所

- 8.8.2 Oracle Access Managerの高可用性の概要

- 8.8.2.1 Oracle Access Managerの高可用性アーキテクチャ

- 8.8.2.1.1 クラスタの起動と停止

- 8.8.2.1.2 クラスタワイドの構成変更

- 8.8.2.2 障害からの保護および予想される動作

- 8.8.2.2.1 WebLogic Serverのクラッシュ

- 8.8.2.2.2 ノード障害

- 8.8.2.2.3 データベース障害

- 8.8.3 Oracle Security Token Serviceの高可用性

- 8.8.3.1 Oracle Security Token Serviceの高可用性アーキテクチャ

- 8.8.3.1.1クライアントとクライアント接続

- 8.8.3.1.2 クラスタワイドの構成変更

- 8.8.3.2 Oracle Security Token Serviceコンポーネントの特性

- 8.8.3.2.1 Oracle Security Token Serviceコンポーネントのライフサイクル

- 8.8.3.2.2 ランタイム・プロセス

- 8.8.3.2.3 Oracle Security Token Serviceの起動と停止

- 8.8.3.2.4 J2EEのコンポーネントとサブコンポーネント

- 8.8.3.2.5 セッションの状態情報

- 8.8.3.2.6 構成アーティファクト

- 8.8.3.2.7 外部依存性

- 8.8.3.3 Oracle Security Token Serviceの高可用性の構成手順

- 8.8.3.4 Oracle Security Token Serviceの高可用性の検証

- 8.8.3.5 Oracle Security Token Serviceのフェイルオーバーと予想される動作

- 8.8.3.5.1 障害検出と再起動

- 8.8.3.5.2 ノード障害

- 8.8.3.6 Oracle Security Token Serviceの有効化および無効化

- 8.8.3.7 Oracle Security Token Serviceのトラブルシューティング

- 8.8.3.8 ログ・ファイルの場所

- 8.8.3.9 その他の考慮事項

- 8.8.4 Oracle Access Managerの高可用性の構成手順

- 8.8.4.1 Oracle Access Managerの構成のための前提条件

- 8.8.4.2 データベースにOAMスキーマを作成するためのリポジトリ作成ユーティリティの実行

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

- 8.8.4.4 Oracle Access Manager Application Tierのインストールと構成

- 8.8.4.4.1 アイデンティティ管理用のOracle Fusion Middlewareのインストール

- 8.8.4.4.2 OAMHOST1でのOracle Identity Managementの構成

- 8.8.4.5 OAMHOST1での管理サーバー用boot.propertiesの作成

- 8.8.4.6 OAMHOST1の起動

- 8.8.4.6.1 OAMHOST1でのノード・マネージャ・プロパティ・ファイルの作成

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

- 8.8.4.6.3 OAMHOST1上のOracle Access Managerの起動

- 8.8.4.7 OAMHOST1の検証

- 8.8.4.8 OAMHOST2でのOAMの構成

- 8.8.4.9 OAMHOST2の起動

- 8.8.4.9.1 OAMHOST2でのノード・マネージャ・プロパティ・ファイルの作成

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

- 8.8.4.9.3 OAMHOST2上のOracle Access Managerの起動

- 8.8.4.10 OAMHOST2の検証

- 8.8.4.11 Oracle HTTP Serverと連携するためのOracle Access Managerの構成

- 8.8.4.11.1 Oracle HTTP Server構成の更新

- 8.8.4.11.2 Oracle HTTP Serverの再起動

- 8.8.4.11.3 Oracle Access Manager Serverにロード・バランサを認識させる

- 8.8.4.12 外部LDAPストアを使用するためのOracle Access Managerの構成

- 8.8.4.12.1 Oracle Access Manager用のディレクトリ・スキーマの拡張

- 8.8.4.12.2 LDAPでのユーザーとグループの作成

- 8.8.4.12.3 ユーザー・アイデンティティ・ストアの作成

- 8.8.4.12.4 システム・ストアおよびデフォルト・ストアへのLDAPの設定

- 8.8.4.12.5 外部LDAPを使用する認証の設定

- 8.8.4.13 Oracle Access Managerの構成の検証

- 8.8.4.14 構成ファイルの同期を保つためのOracle Coherenceの構成

- 8.8.4.15 Oracle Access Managerトポロジのスケール・アップとスケール・アウト

- 8.8.4.15.1 Oracle Access Managerのスケール・アップ

- 8.8.4.15.2 Oracle Access Managerのスケール・アウト

- 8.9 Oracle Identity Managerの高可用性

- 8.9.1 Oracle Identity Managerコンポーネント・アーキテクチャ

- 8.9.1.1 Oracle Identity Managerコンポーネントの特性

- 8.9.1.2 ランタイム・プロセス

- 8.9.1.3 コンポーネントとプロセスのライフサイクル

- 8.9.1.4 Oracle Identity Managerの起動と停止

- 8.9.1.5 構成のアーティファクト

- 8.9.1.6 外部依存性

- 8.9.1.7 Oracle Identity Managerのログ・ファイルの場所

- 8.9.2 Oracle Identity Managerの高可用性の概要

- 8.9.2.1 Oracle Identity Managerの高可用性アーキテクチャ

- 8.9.2.2 Oracle Identity Managerクラスタの起動と停止

- 8.9.2.3 クラスタワイドの構成変更

- 8.9.2.4 LDAPとの同期に関する考慮事項

- 8.9.3 Oracle Identity Managerの高可用性の構成手順

- 8.9.3.1 Oracle Identity Managerの構成のための前提条件

- 8.9.3.1.1 データベースにOIMスキーマを作成するためのRCUの実行

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

- 8.9.3.1.3 OIMHOST1およびOIMHOST2へのOracle SOA Suiteのインストール

- 8.9.3.1.4 OIMHOST1およびOIMHOST2へのOracle Identity Managerのインストール

- 8.9.3.2 OIMHOST1でのOIMとSOAのためのWebLogicドメインの作成と構成

- 8.9.3.3 OIMHOST1でのインストール後の手順

- 8.9.3.3.1 OIMHOST1での管理サーバー用boot.propertiesの作成

- 8.9.3.3.2 OIMHOST1でのノード・マネージャの更新

- 8.9.3.3.3 OIMHOST1でのノード・マネージャの起動

- 8.9.3.3.4 OIMHOST1での管理サーバーの起動

- 8.9.3.4 OIMHOST1でのOracle Identity Managerの構成

- 8.9.3.4.1 Oracle Identity Managerの構成のための前提条件

- 8.9.3.4.2 Oracle Identity Management構成ウィザードの実行

- 8.9.3.5 管理対象サーバーに対する構成後の手順

- 8.9.3.5.1 OIMHOST1でのWLS_SOA1およびWLS_OIM1管理対象サーバーの起動

- 8.9.3.5.2 CoherenceクラスタのためのCoherenceの構成の更新

- 8.9.3.6 OIMHOST1でのOracle Identity Managerインスタンスの検証

- 8.9.3.7 OIMHOST2へのOracle Identity Managerの伝播

- 8.9.3.8 OIMHOST2でのインストール後の手順

- 8.9.3.8.1 OIMHOST2でのノード・マネージャの更新

- 8.9.3.8.2 OIMHOST2でのノード・マネージャの起動

- 8.9.3.8.3 OIMHOST2でのWLS_SOA2およびWLS_OIM2管理対象サーバーの起動

- 8.9.3.9 OIMHOST2でのOracle Identity Managerインスタンスの検証

- 8.9.3.10 LDAP構成ポストセットアップ・スクリプトを使用したOracle Internet Directoryの構成

- 8.9.3.11 OIMおよびSOA管理対象サーバーに対するサーバーの移行の構成

- 8.9.3.11.1 サーバー移行leasing表のユーザーと表領域の設定

- 8.9.3.11.2 Oracle WebLogic管理コンソールを使用したマルチ・データ・ソースの作成

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

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

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

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

- 8.9.3.12 共有JMS永続ストアの構成

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

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

- 8.9.3.15 Web Tierと連携するためのOracle Identity Managerの構成

- 8.9.3.15.1 前提条件

- 8.9.3.15.2 OIMおよびSOA管理対象サーバーのフロントエンドに使用できるようにするためのOracle HTTP Serverの構成

- 8.9.3.16 Oracle HTTP Serverの構成の検証

- 8.9.3.17 Oracle Identity Managerのフェイルオーバーおよび予想される動作

- 8.9.3.18 Oracle Identity Managerの高可用性のトラブルシューティング

- 8.9.3.19 Oracle Identity Managerトポロジのスケール・アップとスケール・アウト

- 8.9.3.19.1 Oracle Identity Managerのスケール・アップ

- 8.9.3.19.2 Oracle Identity Managerのスケール・アウト

- 8.10 認可ポリシー・マネージャの高可用性

- 8.11 Oracle Identity Navigatorの高可用性

- 8.12 Oracle Adaptive Access Managerの高可用性

- 8.12.1 Oracle Adaptive Access Managerコンポーネント・アーキテクチャ

- 8.12.1.1 Oracle Adaptive Access Managerコンポーネントの特性

- 8.12.1.1.1 Oracle Adaptive Access Managerの状態情報

- 8.12.1.1.2 Oracle Adaptive Access Managerランタイム・プロセス

- 8.12.1.1.3 Oracle Adaptive Access Managerプロセスのライフサイクル

- 8.12.1.1.4 Oracle Adaptive Access Managerの構成アーティファクト

- 8.12.1.1.5 Oracle Adaptive Access Managerのデプロイメント・アーティファクト

- 8.12.1.1.6 Oracle Adaptive Access Managerの外部依存性

- 8.12.1.1.7 Oracle Adaptive Access Managerのログ・ファイルの場所

- 8.12.2 Oracle Adaptive Access Managerの高可用性の概要

- 8.12.2.1 Oracle Adaptive Access Managerの高可用性アーキテクチャ

- 8.12.2.1.1 クラスタの起動と停止

- 8.12.2.1.2 クラスタワイドの構成変更

- 8.12.2.2 障害からの保護および予想される動作

- 8.12.3 Oracle Adaptive Access Managerの高可用性の構成手順

- 8.12.3.1 Oracle Adaptive Access Managerの構成のための前提条件

- 8.12.3.2 データベースにOAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行

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

- 8.12.3.4 Oracle Adaptive Access Manager Application Tierのインストールと構成

- 8.12.3.5 OAAMHOST1での管理サーバー用boot.propertiesの作成

- 8.12.3.6 Oracle Adaptive Access Manager管理ユーザーの作成

- 8.12.3.7 OAAMHOST1の起動

- 8.12.3.7.1 OAAMHOST1でのノード・マネージャ・プロパティ・ファイルの作成

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

- 8.12.3.7.3 OAAMHOST1でのOracle Adaptive Access Managerの起動

- 8.12.3.8 OAAMHOST1の検証

- 8.12.3.9 OAAMHOST2でのOracle Adaptive Access Managerの構成

- 8.12.3.10 OAAMHOST2の起動

- 8.12.3.10.1 OAAMHOST2でのノード・マネージャ・プロパティ・ファイルの作成

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

- 8.12.3.10.3 OAAMHOST2でのOracle Adaptive Access Managerの起動

- 8.12.3.11 OAAMHOST2の検証

- 8.12.3.12 Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成

- 8.12.3.12.1 Oracle HTTP Server構成の更新

- 8.12.3.12.2 Oracle HTTP Serverの再起動

- 8.12.3.12.3 WebLogicにおけるホスト・アサーションの変更

- 8.12.3.13 Oracle Adaptive Access Managerの構成の検証

- 8.12.3.14 Oracle Adaptive Access Managerトポロジのスケール・アップとスケール・アウト

- 8.12.3.14.1 Oracle Adaptive Access Managerのスケール・アップ

- 8.12.3.14.2 Oracle Adaptive Access Managerのスケール・アウト

- 8.13 Oracle Identity Federationの高可用性

- 8.13.1 Oracle Identity Federationコンポーネント・アーキテクチャ

- 8.13.1.1 Oracle Identity Federationコンポーネントの特性

- 8.13.1.1.1 ランタイム・プロセス

- 8.13.1.1.2 プロセスのライフサイクル

- 8.13.1.1.3 リクエスト・フロー

- 8.13.1.1.4 構成アーティファクト

- 8.13.1.1.5 外部依存性

- 8.13.1.1.6 Oracle Identity Federationのログ・ファイルの場所

- 8.13.2 Oracle Identity Federationの高可用性の概要

- 8.13.2.1 Oracle Identity Federationの高可用性アーキテクチャ

- 8.13.2.1.1 クラスタの起動と停止

- 8.13.2.1.2 クラスタワイドの構成変更

- 8.13.2.2 Oracle Access Managerとの統合における高可用性の考慮事項

- 8.13.2.3 Oracle Identity Federationの前提条件

- 8.13.2.3.1 RCUを使用したリポジトリへのOracle Identity Federationスキーマの作成

- 8.13.3 Oracle Identity Federationの高可用性の構成手順

- 8.13.3.1 OIFHOST1でのOracle Identity Federationの構成

- 8.13.3.2 OIFHOST1での管理サーバー用boot.propertiesの作成

- 8.13.3.3 OIFHOST2でのOracle Identity Federationの構成

- 8.13.3.4 Oracle Identity Federationのインストール後の手順

- 8.13.3.4.1 OIFHOST1からOIFHOST2へのOracle Identity Federation構成ディレクトリのコピー

- 8.13.3.4.2 クラスタ内のOIFHOST2での管理対象サーバーの起動

- 8.13.3.4.3 Oracle HTTP Serverの構成

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

- 8.13.3.5.1 ロード・バランサの仮想サーバー名の設定

- 8.13.3.5.2 Oracle Identity Federationの構成

- 8.13.3.6 Oracle Identity Federationの高可用性の検証

- 8.13.3.7 Oracle Identity Federationと可用性の高いLDAPサーバーとの統合

- 8.13.4 Oracle Identity Federationのフェイルオーバーおよび予想される動作

- 8.13.4.1 Oracle Identity Federationのフェイルオーバーの実行

- 8.13.4.2 Oracle RACフェイルオーバーの実行

- 8.13.5 Oracle Identity Federationの高可用性のトラブルシューティング

- 8.14 コンポーネントの起動と停止

9 Web層コンポーネントの高可用性の構成

- 9.1 Web層について

- 9.2 Oracle HTTP Serverと高可用性の概要

- 9.2.1 Oracle HTTP Serverの単一インスタンスの特性

- 9.2.1.1 Oracle HTTP ServerとOracle WebLogic Server

- 9.2.1.2 Oracle HTTP Serverの外部依存性

- 9.2.2 Oracle HTTP Serverの起動とシャットダウンのライフサイクル

- 9.2.3 Oracle HTTP Serverの起動と停止

- 9.2.3.1 PIDファイルの理解

- 9.2.3.2 Oracle Fusion Middleware Controlを使用したOracle HTTP Serverの起動と停止

- 9.2.3.3 opmnctlを使用したOracle HTTP Serverの起動と停止

- 9.2.4 Oracle HTTP Serverの構成アーティファクト

- 9.2.5 Oracle HTTP Serverログ・ファイルの場所

- 9.2.6 Oracle HTTP Serverの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

- 9.2.7 Oracle HTTP Serverの障害からの保護および予想される動作

- 9.2.8 Oracle HTTP Serverのクラスタワイドの構成変更

- 9.2.9 高可用性のためのOracle HTTP Serverの構成

- 9.2.9.1 前提条件

- 9.2.9.1.1 ロード・バランサ

- 9.2.9.1.2 Oracle HTTP ServerとWebLogicドメインとの関連付け

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

- 9.2.9.2.1 仮想ホストの構成

- 9.2.9.2.2 mod_wl_ohsの構成

- 9.2.9.2.3 Oracle HTTP Serverの再起動

- 9.2.9.2.4 Oracle HTTP Serverの構成の検証

- 9.2.9.3 WEBHOST2へのOracle HTTP Serverのインストール

- 9.2.9.3.1 仮想ホストの構成

- 9.2.9.3.2 mod_wl_ohsの構成

- 9.2.9.3.3 Oracle HTTP Serverの再起動

- 9.2.9.3.4 Oracle HTTP Serverの構成の検証

- 9.3 Oracle Web Cacheと高可用性の概要

- 9.3.1 Oracle Web Cacheの単一ノードの特性

- 9.3.1.1 Oracle Web Cacheコンポーネントの特性

- 9.3.1.2 Oracle Web Cacheのプロセス監視

- 9.3.1.3 Oracle Web Cacheの起動とシャットダウンのライフサイクル

- 9.3.1.4 Oracle Web Cacheのリクエスト・フロー

- 9.3.1.5 Oracle Web Cacheの構成アーティファクト

- 9.3.1.6 ログ・ファイルの場所

- 9.3.2 Oracle Web Cacheの高可用性に関する考慮事項

- 9.3.2.1 Oracle Web Cacheのステートレス・ロード・バランシング

- 9.3.2.2 Oracle Web Cacheのバックエンドのフェイルオーバー

- 9.3.2.3 Oracle Web Cacheのセッション・バインディング

- 9.3.2.4 Oracle Web Cacheのクラスタワイドの構成変更

- 9.3.2.5 ソフトウェア・ロード・バランサとしてのOracle Web Cache

- 9.3.3 Oracle Web Cacheの高可用性ソリューションの構成

- 9.3.3.1 Oracle Web Cacheのセッション・バインディングの構成

- 9.3.3.2 キャッシュ・クラスタの構成

- 9.3.3.2.1 構成の前提条件

- 9.3.3.2.2 フェイルオーバーのしきい値および容量設定の理解

- 9.3.3.2.3 タスク1: クラスタへのキャッシュの追加とプロパティの構成

- 9.3.3.2.4 作業2: セッション・バインディングのトラッキングの有効化

- 9.3.3.2.5 タスク3: クラスタ・メンバーへの構成の同期化

- 9.3.3.2.6 クラスタからのキャッシュ・メンバーの削除

- 9.3.3.2.7 管理および無効化専用のクラスタの構成

- 9.3.3.3 ソフトウェア・ロード・バランサとしてのOracle Web Cacheの構成

10 高可用性を最大化するIdentity Managementの構成

- 10.1 高可用性を最大化するIdentity Managementデプロイメントの概要

- 10.2 レプリケーションの概要

- 10.3 マルチマスター・レプリケーションの設定

- 10.3.1 LDAPマルチマスター・レプリケーションの設定

- 10.3.1.1 LDAPマルチマスター・レプリケーションへのノードの追加

- 10.3.1.2 LDAPマルチマスター・レプリケーションからのノードの削除

- 10.3.2 Oracle Advanced Databaseマルチマスター・レプリケーションの設定

- 10.3.2.1 Oracle Advanced Databaseマルチマスター・レプリケーションへのノードの追加

- 10.3.2.2 Oracle Advanced Databaseマルチマスター・レプリケーションでのノードの削除

11 WebCenter Contentの高可用性の構成

- 11.1 Oracle WebCenter Content: Imagingの高可用性

- 11.1.1 Imagingコンポーネントのアーキテクチャ

- 11.1.1.1 Imagingコンポーネントの特性

- 11.1.1.1.1 Imagingの状態情報

- 11.1.1.1.2 Imagingのランタイム・プロセス

- 11.1.1.1.3 Imagingプロセスのライフサイクル

- 11.1.1.1.4 Imagingの構成アーティファクト

- 11.1.1.1.5 Imagingの外部依存性

- 11.1.1.1.6 Imagingのログ・ファイルの場所

- 11.1.2 Imagingの高可用性の概要

- 11.1.2.1 Imagingの高可用性アーキテクチャ

- 11.1.2.1.1 クラスタの起動と停止

- 11.1.2.1.2 クラスタワイドの構成変更

- 11.1.2.2 障害からの保護および予想される動作

- 11.1.2.3 クラスタでのImagingアーティファクトの作成

- 11.1.2.4 Imagingのトラブルシューティング

- 11.2 Oracle WebCenter Contentの高可用性

- 11.2.1 Oracle WebCenter Contentコンポーネント・アーキテクチャ

- 11.2.1.1 WebCenter Contentコンポーネントの特性

- 11.2.1.1.1 WebCenter Contentの状態情報

- 11.2.1.1.2 WebCenter Contentのラインタイム・プロセス

- 11.2.1.1.3 WebCenter Contentプロセスのライフサイクル

- 11.2.1.1.4 WebCenter Contentの構成アーティファクト

- 11.2.1.1.5 WebCenter Contentのデプロイメント・アーティファクト

- 11.2.1.1.6 WebCenter Contentの外部依存性

- 11.2.1.1.7 WebCenter Contentのログ・ファイルの場所

- 11.2.2 WebCenter Contentの高可用性の概要

- 11.2.2.1 WebCenter Contentの高可用性アーキテクチャ

- 11.2.2.1.1 クラスタの起動と停止

- 11.2.2.1.2 クラスタワイドの構成変更

- 11.2.2.2 WebCenter ContentおよびInbound Refineryの高可用性アーキテクチャ

- 11.2.2.2.1 Content ServerとInbound Refineryの通信

- 11.2.2.2.2 Content ServerクラスタおよびInbound Refineryインスタンス

- 11.2.2.2.3 Inbound Refineryインスタンスとロード・バランサ

- 11.2.2.2.4 Inbound Refineryの可用性

- 11.2.2.3 Recordsの高可用性

- 11.2.2.4 障害からの保護および必要な対応

- 11.2.2.5 WebCenter Contentの高可用性のトラブルシューティング

- 11.3 Oracle WebCenter Contentの高可用性の構成手順

- 11.3.1 共有記憶域

- 11.3.2 Oracle Databaseの構成

- 11.3.3 WCCHOST1のインストールと構成

- 11.3.3.1 WCCHOST1へのOracle WebLogic Serverのインストール

- 11.3.3.2 WCCHOST1へのOracle WebCenter Contentのインストール

- 11.3.3.3 高可用性のドメインの作成

- 11.3.3.4 WCCHOST1での管理サーバーおよび管理対象サーバーの起動

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

- 11.3.3.6 WLS_UCM1管理対象サーバーの構成

- 11.3.3.7 WLS_URM1管理対象サーバーの構成

- 11.3.4 WEBHOST1のインストールと構成

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

- 11.3.4.2 WEBHOST1でのOracle HTTP Serverの構成

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

- 11.3.6 WCCHOST2のインストールと構成

- 11.3.6.1 WCCHOST2へのOracle WebLogic Serverのインストール

- 11.3.6.2 WCCHOST2へのWCCのインストール

- 11.3.6.3 packおよびunpackを使用したWCCHOST1のドメインへの参加

- 11.3.6.4 WCCHOST2でのノード・マネージャおよびWLS_UCM2サーバーの起動

- 11.3.6.5 WCCHOST2での管理対象サーバーの起動

- 11.3.6.6 WLS_UCM2管理対象サーバーの構成

- 11.3.6.7 WLS_URM2管理対象サーバーの構成

- 11.3.7 WEBHOST2のインストールと構成

- 11.3.7.1 WEBHOST2へのOracle HTTP Serverのインストール

- 11.3.7.2 WEBHOST2でのOracle HTTP Serverの構成

- 11.3.8 Imaging管理対象サーバーの構成

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

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

- 11.3.8.3 WebCenter ContentでのImagingの構成

- 11.3.8.3.1 UCMでのImagingの有効化

- 11.3.8.3.2 デフォルトのファイル・ストアのアップグレード

- 11.3.8.3.3 UCMの許可されたホストのリストへのImagingサーバーのリスニング・アドレスの追加

- 11.3.8.3.4 UCMシステムへの接続の作成

- 11.3.8.4 BPEL CSF資格証明の構成

- 11.3.8.5 BPEL接続の構成

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

- 11.3.8.7 Imagingインスタンスのサーバー移行の構成

- 11.3.8.7.1 サーバー移行の構成について

- 11.3.8.7.2 Oracle WebLogic管理コンソールを使用したGridLinkデータ・ソースまたはマルチ・データ・ソースの作成

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

- 11.3.9 Inbound Refineryインスタンスの構成

- 11.3.9.1 Inbound RefineryとInbound Refineryクラスタの概要

- 11.3.9.2 Content ServerとInbound Refineryの構成

- 11.3.9.3 Inbound RefineryインスタンスとOracle HTTP Server

12 Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ

- 12.1 Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジの概要

- 12.2 アクティブ/パッシブ・デプロイメントのためのOracle Fusion Middlewareの構成

- 12.2.1 コールド・フェイルオーバー・クラスタの要件

- 12.2.2 ディレクトリおよび環境変数の用語

- 12.2.3 Oracle Fusion Middlewareインフラストラクチャ・コンポーネントの変換

- 12.2.3.1 管理サーバーのトポロジ1

- 12.2.3.2 トポロジ1のインストール手順

- 12.2.3.3 管理サーバーのトポロジ2

- 12.2.3.4 トポロジ2のインストール手順

- 12.2.3.5 コールド・フェイルオーバー・クラスタ用の管理サーバーの変換

- 12.2.3.6 Oracle WebLogic管理対象サーバーの変換

- 12.2.3.6.1 Fusion Middleware管理コンソールによるOracle WebLogic管理対象サーバーの変換

- 12.2.3.6.2 WLSTコマンドラインによるOracle WebLogic管理対象サーバーの変換

- 12.2.3.7 ノード・マネージャの変換

- 12.2.3.8 Oracle Process Management and Notification Serverの変換

- 12.2.3.9 OracleインスタンスのOracle Enterprise Managerの変換

- 12.2.3.10 Web層のコンポーネントとクライアントの変換

- 12.2.3.10.1 Oracle HTTP Serverの変換

- 12.2.3.10.2 Oracle Web Cacheの変換

- 12.2.3.11 インスタンス固有の考慮事項

- 12.2.3.11.1 UNIXプラットフォーム

- 12.2.3.11.2 Windowsプラットフォーム

- 12.2.4 Oracle Fusion Middlewareコンポーネントの変換

- 12.2.4.1 Oracle Internet Directoryおよびそのクライアントの変換

- 12.2.4.1.1 Transforming Oracle Internetの変換

- 12.2.4.1.2 Transforming Oracle Internet Directoryクライアントの変換

- 12.2.4.2 Oracle Virtual Directoryおよびそのクライアントの変換

- 12.2.4.2.1 Oracle Virtual Directoryの変換

- 12.2.4.2.2 Oracle Virtual Directoryクライアントの変換

- 12.2.4.3 Oracle Directory Integration PlatformおよびOracle Directory Services Managerとそれぞれのクライアントの変換

- 12.2.4.3.1 Oracle Directory Integration PlatformとOracle Directory Services Managerの変換

- 12.2.4.3.2 Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントの変換

- 12.2.4.4 Oracle Identity Federationおよびそのクライアントの変換

- 12.2.4.4.1 Oracle Identity Federationの変換

- 12.2.4.4.2 Oracle Identity Federationクライアントの変換

- 12.2.4.5 Oracle SOA Suiteの変換

- 12.2.4.6 Oracle Access Managerおよびそのクライアントの変換

- 12.2.4.6.1 Oracle Access Managerの変換

- 12.2.4.6.2 Oracle Access Managerクライアントの変換

- 12.2.4.7 Oracle Adaptive Access Managerおよびそのクライアントの変換

- 12.2.4.7.1 Oracle Adaptive Access Managerの変換

- 12.2.4.7.2 Oracle Adaptive Access Managerクライアントの変換

- 12.2.4.8 Oracle Identity Managerおよびそのクライアントの変換

- 12.2.4.8.1 Oracle Identity Managerの変換

- 12.2.4.8.2 Oracle Identity Managerクライアントの変換

- 12.2.4.9 Oracle WebCenterポータルSuiteの変換

- 12.2.4.10 Oracle Portal、Forms、ReportsおよびDiscovererの変換

- 12.2.4.10.1 コールド・フェイルオーバー・クラスタ用のOracle Formsの変換

- 12.2.4.10.2 コールド・フェイルオーバー・クラスタ用のOracle Reportsの変換

- 12.2.4.10.3 コールド・フェイルオーバー・クラスタ用のOracle Discovererの変換

- 12.2.4.10.4 コールド・フェイルオーバー・クラスタ用のOracle Portalの変換

- 12.2.4.10.5 Oracle Business Activity Management(BAM)の変換

- 12.2.4.10.6 カスタムADFデプロイメントの変換

- 12.2.4.11 Oracle WebCenter Contentの変換

- 12.2.4.12 Oracle Business Intelligenceの変換

- 12.2.4.12.1 Oracle Business Intelligence Enterprise Editionおよびそのクライアントの変換

- 12.2.4.12.2 Oracle Business Intelligence Publisherおよびそのクライアントの変換

- 12.2.4.12.3 Oracle Real-Time Decisionsおよびそのクライアントの変換

- 12.2.4.13 Oracle BI for Microsoft Officeおよびそのクライアントの変換

- 12.2.4.14 シングル・サインオンの再登録(必要な場合)

- 12.2.5 Oracle Databaseの変換

- 12.2.5.1 データベース・インスタンス・プラットフォーム固有の考慮事項

- 12.3 Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジ例

- 12.3.1 トポロジ例1

- 12.3.2 トポロジ例2

- 12.3.3 トポロジ例3

- 12.4 コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換

- 12.4.1 変換後トポロジ

- 12.4.2 コールド・フェイルオーバー・クラスタ変換の手順

13 Oracle Cluster Ready Servicesの使用

- 13.1 Oracle Clusterwareの概要

- 13.2 Cluster Ready ServicesとOracle Fusion Middleware

- 13.3 CRSでのOracle Clusterwareのインストールと構成

- 13.3.1 古いバージョンから現在のバージョンへのASCRSのアップグレード

- 13.3.2 ASCRSのインストール

- 13.3.3 Oracle Fusion MiddlewareでのASCRSの構成

- 13.4 ASCRSを使用したリソースの管理

- 13.4.1 CRS管理対象リソースの作成

- 13.4.1.1 仮想IPリソースの作成

- 13.4.1.2 共有ディスク・リソースの作成

- 13.4.1.3 Oracle Databaseリスナー・リソースの作成

- 13.4.1.4 Oracle Databaseリソースの作成

- 13.4.1.5 Middlewareリソースの作成

- 13.4.1.5.1 OPMN管理対象コンポーネントのリソースの作成

- 13.4.1.5.2 WebLogic Serverのリソースの作成

- 13.4.2 リソースの更新

- 13.4.3 リソースの起動

- 13.4.4 リソースの停止

- 13.4.5 リソースのスイッチオーバー

- 13.4.6 リソースの削除

- 13.4.7 リソース・ステータスのチェック

- 13.4.8 ヘルス・モニターの構成および使用

- 13.5 トポロジの例

- 13.6 Oracle CRSのトラブルシューティング

- 13.6.1 仮想IPリソースに依存するOPMNリソース

- 13.6.2 ASCRSロギング

14 Oracle Portal、Forms、ReportsおよびDiscovererの高可用性の構成

- 14.1 Oracle Portal、Forms、ReportsおよびDiscovererの概要

- 14.1.1 Oracle Portal、Forms、ReportsおよびDiscovererのアーキテクチャ

- 14.1.2 共通ログ・ファイル

- 14.1.3 一般的なコンポーネント障害および予想される動作

- 14.1.3.1 Oracle Web CacheおよびOracle HTTP Serverのプロセス障害

- 14.1.3.2 一般的なコンポーネント・ノード障害

- 14.1.3.3 一般的なコンポーネントのWebLogic管理対象サーバーの障害

- 14.1.3.4 一般的なコンポーネントのデータベースの障害

- 14.1.4 Oracle Portal、Forms、ReportsおよびDiscovererのクラスタワイドの構成変更

- 14.1.5 一般的なコンポーネント・ログ・ファイル情報

- 14.2 Oracle Portalと高可用性の概要

- 14.2.1 Oracle Portalの単一インスタンスの特性

- 14.2.1.1 Oracle Portalのリクエスト・フロー

- 14.2.1.2 Oracle Portalコンポーネントの特性

- 14.2.1.3 Oracle Portalのプロセスの起動と停止およびライフサイクル

- 14.2.1.4 Oracle Portalのデプロイメント・アーティファクト

- 14.2.1.5 Oracle Portalの構成情報

- 14.2.1.6 Oracle Portalのロギングおよびログ構成

- 14.2.1.6.1 Oracle Portalのログ・ファイル

- 14.2.1.7 Oracle Portalの外部依存性

- 14.2.2 Oracle Portalの障害からの保護および予想される動作

- 14.2.2.1 Oracle Portalプロセスの障害

- 14.2.2.2 Oracle Portalノードの障害

- 14.2.2.3 Oracle Portal WebLogic管理対象サーバーの障害

- 14.2.2.4 データベース障害からのOracle Portalの保護

- 14.3 Oracle Reportsと高可用性の概要

- 14.3.1 Oracle Reportsの単一インスタンスの特性

- 14.3.1.1 Oracle Reportsの状態情報

- 14.3.1.2 Oracle Reportsの外部依存性

- 14.3.1.3 Oracle Reports固有の構成ファイル

- 14.3.1.4 Oracle Reportsの接続の再試行

- 14.3.1.5 Oracle Reportsのプロセス・フロー

- 14.3.1.6 Oracle Reportsのログ・ファイル

- 14.3.2 障害からのOracle Reportsの保護および必要な対応

- 14.3.2.1 Oracle Reportsプロセスの障害

- 14.3.2.2 Oracle Reportsノードの障害

- 14.3.2.3 Oracle Reports WebLogic管理対象サーバーの障害

- 14.3.2.4 Oracle Reportsデータベースの障害

- 14.4 Oracle Formsと高可用性の概要

- 14.4.1 Oracle Formsの単一インスタンス・コンポーネントの特性

- 14.4.1.1 Oracle Formsの状態情報

- 14.4.1.2 Oracle Formsデータベースの要件

- 14.4.1.3 Oracle Formsのリクエスト・フロー

- 14.4.1.4 Oracle Forms構成の永続性

- 14.4.1.5 Oracle Formsランタイムの考慮事項

- 14.4.1.6 Oracle Formsのプロセス・フロー

- 14.4.1.7 Oracle Formsの構成ファイル

- 14.4.1.8 Oracle Formsの外部依存性

- 14.4.1.9 Oracle Formsのログ・ファイル

- 14.4.2 Oracle Formsのフェイルオーバーによる保護および予想される動作

- 14.4.2.1 Oracle Forms N+1の冗長性

- 14.4.2.2 Oracle Forms N+Mの冗長性

- 14.4.2.3 Oracle Formsの仮想マシン

- 14.4.2.4 Oracle Forms構成のクローニング

- 14.4.2.5 Oracle Formsプロセスの障害

- 14.4.2.6 Oracle Formsノードの障害

- 14.4.2.7 Oracle Forms WebLogic管理対象サーバーの障害

- 14.4.2.8 Oracle Formsデータベースの障害

- 14.5 Oracle Discovererと高可用性の概要

- 14.5.1 Oracle Discovererの単一インスタンスの特性

- 14.5.1.1 Oracle Discovererランタイムの考慮事項

- 14.5.1.2 Oracle Discoverer ViewerおよびWeb Cache

- 14.5.1.3 Oracle Discoverer構成の考慮事項

- 14.5.1.4 Oracle Discovererデプロイメントの考慮事項

- 14.5.1.5 Oracle Discovererのログ・ファイルの場所

- 14.5.1.6 Discovererのログ・ファイル

- 14.5.2 Oracle Discovererの障害からの保護および予想される動作

- 14.5.2.1 プリファレンス・サーバーのフェイルオーバー

- 14.5.2.2 セッション状態レプリケーションとフェイルオーバー

- 14.5.2.3 パフォーマンス上の推奨事項

- 14.5.2.4 クラスタ間の構成変更の伝播

- 14.5.2.5 クラスタワイドのアプリケーションのデプロイメント

- 14.5.2.6 オンライン・アプリケーションのデプロイメント

- 14.5.2.7 Oracle Discovererプロセスの障害

- 14.5.2.8 Oracle Discovererノードの障害

- 14.5.2.9 Oracle Discoverer WebLogic管理対象サーバーの障害

- 14.5.2.10 Oracle Discovererデータベースの障害

- 14.6 高可用性のためのOracle Portal、Forms、ReportsおよびDiscovererの構成

- 14.6.1 前提条件

- 14.6.1.1 依存性

- 14.6.1.2 ネットワークの要件

- 14.6.1.2.1 ロード・バランサ

- 14.6.1.2.2 ロード・バランサの構成: 仮想サーバー名とポート

- 14.6.1.3 データベース

- 14.6.1.4 共有ディレクトリ

- 14.6.1.5 管理対象ポートの番号

- 14.6.1.6 サイト名

- 14.6.2 前提事項

- 14.6.2.1 ポート

- 14.6.3 メタデータ・リポジトリの作成

- 14.6.3.1 リポジトリ作成ユーティリティ(RCU)のインストール

- 14.6.3.2 リポジトリ作成ユーティリティの実行

- 14.6.4 APPHOST1におけるアプリケーション層のインストールと構成

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

- 14.6.4.2 Oracle Portal、Forms、ReportsおよびDiscovererのインストール

- 14.6.4.3 Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成

- 14.6.4.4 検証

- 14.6.4.5 汎用構成

- 14.6.4.5.1 管理サーバーのリスニング・アドレスの設定

- 14.6.4.5.2 仮想ホストの構成

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

- 14.6.4.5.4 sqlnet.oraの構成

- 14.6.4.5.5 Web Cacheの構成

- 14.6.4.5.6 Web Cacheパスワードの変更

- 14.6.4.5.7 Web層(Oracle HTTP ServerおよびWeb Cache)の再起動

- 14.6.4.5.8 シングル・サインオン・サーバーでの登録

- 14.6.4.5.9 WebLogicプラグインの有効化

- 14.6.4.5.10 WebLogicにおけるホスト・アサーションの変更

- 14.6.4.6 高可用性のためのOracle Portalの構成

- 14.6.4.6.1 Portalリポジトリのリワイヤ

- 14.6.4.6.2 ロード・バランサでのParallel Page Engineループバックの構成

- 14.6.4.6.3 データベース・ウォレットとポータル

- 14.6.4.6.4 すべてのコンポーネントの再起動

- 14.6.4.6.5 Oracle RACでのポータルのインストールに対するインストール後の手順

- 14.6.4.6.6 構成の検証

- 14.6.4.7 高可用性のためのOracle Formsの構成

- 14.6.4.7.1 カスタマ・データベースのTNSNAMESエントリの作成

- 14.6.4.7.2 WLS_FORMSの再起動

- 14.6.4.7.3 構成の検証

- 14.6.4.8 高可用性のためのOracle Reportsの構成

- 14.6.4.8.1 データベースにおけるレポート・キューの作成

- 14.6.4.8.2 レポート・キューのTNSNAMESエントリの作成

- 14.6.4.8.3 レポート・キューのセキュリティ・キーの作成

- 14.6.4.8.4 インプロセスReports Serverのデータベース・ジョブ・リポジトリの構成

- 14.6.4.8.5 共有出力ディレクトリにアクセスするためのReports Serverの構成

- 14.6.4.8.6 WLS_REPORTSの再起動

- 14.6.4.8.7 構成の検証

- 14.6.4.9 高可用性のためのOracle Discovererの構成

- 14.6.4.9.1 カスタマ・データベースのTNSNAMESエントリの作成

- 14.6.4.9.2 configuration.xmlの更新

- 14.6.4.9.3 Discoverer ViewerおよびWeb Cache

- 14.6.4.9.4 シングル・サインオンの有効化

- 14.6.4.9.5 すべてのコンポーネントの再起動

- 14.6.4.9.6 構成の検証

- 14.6.5 APPHOST2におけるアプリケーション層のインストールと構成

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

- 14.6.5.2 Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアのインストール

- 14.6.5.3 Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成

- 14.6.5.4 汎用構成

- 14.6.5.4.1 APPHOST1からの構成情報のコピー

- 14.6.5.4.2 仮想ホストの構成

- 14.6.5.4.3 クラスタ対応にするためのOracle HTTP Server構成の更新

- 14.6.5.4.4 Web Cacheパスワードの変更

- 14.6.5.4.5 Web Cacheの構成

- 14.6.5.4.6 APPHOST1およびAPPHOST2上のWebプロセスの再開

- 14.6.5.5 高可用性のためのOracle Portalの構成

- 14.6.5.5.1 APPHOST1からの構成情報のコピー

- 14.6.5.5.2 Portalディレクトリの作成

- 14.6.5.5.3 インスタンス・パスの更新

- 14.6.5.5.4 Webプロセスの再開

- 14.6.5.5.5 WLS_PORTAL1の起動

- 14.6.5.5.6 構成の検証

- 14.6.5.5.7 ベスト・プラクティス

- 14.6.5.6 高可用性のためのOracle Formsの構成

- 14.6.5.6.1 カスタマ・データベースのTNSNAMESエントリの作成

- 14.6.5.6.2 Forms構成ファイルのコピー

- 14.6.5.6.3 default.envの更新

- 14.6.5.6.4 WLS_FORMS1の再起動

- 14.6.5.6.5 構成の検証

- 14.6.5.6.6 ベスト・プラクティス

- 14.6.5.7 高可用性のためのOracle Reportsの構成

- 14.6.5.7.1 カスタマ・データベースのTNSNAMESエントリの作成

- 14.6.5.7.2 共有出力ディレクトリにアクセスするためのReports Serverの構成

- 14.6.5.7.3 インプロセスReports Serverのデータベース・ジョブ・リポジトリの構成

- 14.6.5.7.4 Oracle Reports Serverクラスタの作成

- 14.6.5.7.5 WLS_REPORTSとWLS_REPORTS1の再起動

- 14.6.5.7.6 構成の検証

- 14.6.5.7.7 Oracle Reportsサービスの接続可用性の管理

- 14.6.5.8 高可用性のためのOracle Discovererの構成

- 14.6.5.8.1 カスタマ・データベースのTNSNAMESエントリの作成

- 14.6.5.8.2 Discoverer構成ファイルのコピー

- 14.6.5.8.3 configuration.xmlの更新

- 14.6.5.8.4 プリファレンス・ストアの変更

- 14.6.5.8.5 WLS_DISCOおよびWLS_DISCO1の再起動

- 14.6.5.8.6 構成の検証

- 14.6.5.8.7 プリファレンス・サーバーのフェイルオーバー

- 14.6.5.8.8 クラスタ環境でのDiscoverer WSRPポートレット・プロデューサの設定

- 14.6.5.8.9 ベスト・プラクティス

- 14.6.6 デプロイメントのスケール・アウト

15 Oracle Business IntelligenceおよびEPMの高可用性の構成

- 15.1 Oracle Business Intelligence Enterprise EditionおよびEnterprise Performance Managementの高可用性

- 15.1.1 Oracle BI EEのコンポーネント・アーキテクチャ

- 15.1.1.1 Oracle BI EEコンポーネントの特性

- 15.1.1.1.1 プロセスのライフサイクル

- 15.1.1.1.2 外部依存性

- 15.1.1.1.3 構成アーティファクト

- 15.1.1.1.4 デプロイメント・アーティファクト

- 15.1.1.1.5 ログ・ファイルの場所

- 15.1.2 Oracle BI EEの高可用性の概要

- 15.1.2.1 Oracle BI EEおよびEPMの高可用性アーキテクチャ

- 15.1.2.1.1 Webサーバーの高可用性の考慮事項

- 15.1.2.1.2 Oracle BIプレゼンテーション・サービスプラグインの高可用性の考慮事項

- 15.1.2.1.3 プレゼンテーション・サービスの高可用性の考慮事項

- 15.1.2.1.4 BI Cluster Controllerの高可用性の考慮事項

- 15.1.2.1.5 BI Serverの高可用性の考慮事項

- 15.1.2.1.6 管理ツールの高可用性の考慮事項

- 15.1.2.1.7 Oracle BIスケジューラの高可用性の考慮事項

- 15.1.2.1.8 BI JavaHostの高可用性の考慮事項

- 15.1.2.2 共有されたファイルとディレクトリ

- 15.1.2.2.1 Oracle BIプレゼンテーション・カタログの共有ファイル

- 15.1.2.2.2 リポジトリ公開ディレクトリの共有ファイル

- 15.1.2.2.3 グローバル・キャッシュの共有ファイル

- 15.1.2.2.4 Oracle BIスケジューラ・スクリプトの共有ファイル

- 15.1.2.3 クラスタの起動と停止

- 15.1.2.4 クラスタワイドの構成変更

- 15.1.2.5 障害からの保護および予想される動作

- 15.1.2.5.1 マシンの障害

- 15.1.2.5.2 WebLogic管理サーバーの障害

- 15.1.2.5.3 WebLogic管理対象サーバーの障害

- 15.1.2.5.4 Oracle BIスケジューラの障害

- 15.1.2.5.5 Cluster Controllerの障害

- 15.1.2.5.6 プレゼンテーション・サービスの障害

- 15.1.2.5.7 BI Serverの障害

- 15.1.2.5.8 Oracle BI EEのトラブルシューティング

- 15.1.3 Oracle Essbaseのコンポーネント・アーキテクチャ

- 15.1.3.1 Oracle Essbaseコンポーネントの特性

- 15.1.3.1.1 状態情報

- 15.1.3.1.2 ランタイム・プロセス

- 15.1.3.1.3 プロセスのライフサイクル

- 15.1.3.1.4 リクエスト・フロー

- 15.1.3.1.5 外部依存性

- 15.1.3.1.6 構成アーティファクト

- 15.1.3.1.7 デプロイメント・アーティファクト

- 15.1.3.1.8 ログ・ファイル

- 15.1.4 Oracle Essbaseの高可用性の概要

- 15.1.4.1 Oracle Essbaseの高可用性アーキテクチャ

- 15.1.4.1.1 共有されたファイルとディレクトリ

- 15.1.4.1.2 クラスタワイドの構成変更

- 15.1.4.2 障害からの保護および予想される動作

- 15.1.4.3 トラブルシューティング

- 15.1.5 Oracle Essbaseのクラスタリングの構成

- 15.1.5.1 前提条件

- 15.1.5.2 共有ARBORPATHの構成

- 15.1.5.3 Essbaseエージェントのセカンダリ・インスタンスの構成

- 15.1.6 Oracle Hyperion Provider Servicesのコンポーネント・アーキテクチャ

- 15.1.6.1 Oracle Hyperion Provider Servicesコンポーネントの特性

- 15.1.6.1.1 状態情報

- 15.1.6.1.2 ランタイム・プロセス

- 15.1.6.1.3 プロセスのライフサイクル

- 15.1.6.1.4 リクエスト・フロー

- 15.1.6.1.5 外部依存性

- 15.1.6.1.6 構成アーティファクト

- 15.1.6.1.7 デプロイメント・アーティファクト

- 15.1.6.1.8 ログ・ファイル

- 15.1.7 Oracle Hyperion Provider Servicesの高可用性の概要

- 15.1.7.1 Oracle Hyperion Provider Servicesの高可用性アーキテクチャ

- 15.1.7.1.1 Provider ServicesクラスタのHyperion Registry構造

- 15.1.7.1.2 クラスタワイドの構成変更

- 15.1.7.1.3 OPMN Essbaseのクラスタ・サポート

- 15.1.7.1.4 Provider ServicesによるEssbaseデータベースのクラスタ化

- 15.1.7.2 障害からの保護および予想される動作

- 15.1.8 Oracle EPM Workspaceのコンポーネント・アーキテクチャ

- 15.1.8.1 Workspaceコンポーネントの特性

- 15.1.8.1.1 状態情報

- 15.1.8.1.2 ランタイム・プロセス

- 15.1.8.1.3 プロセスのライフサイクル

- 15.1.8.1.4 リクエスト・フロー

- 15.1.8.1.5 外部依存性

- 15.1.8.1.6 構成アーティファクト

- 15.1.8.1.7 デプロイメント・アーティファクト

- 15.1.8.1.8 ログ・ファイル

- 15.1.9 Oracle EPM Workspaceの高可用性の概要

- 15.1.9.1 Workspaceの高可用性アーキテクチャ

- 15.1.9.1.1 共有されたファイルとディレクトリ

- 15.1.9.1.2 クラスタワイドの構成変更

- 15.1.9.2 障害からの保護および予想される動作

- 15.1.9.3 トラブルシューティング

- 15.1.10 Oracle Hyperion Financial Reportingのコンポーネント・アーキテクチャ

- 15.1.10.1 Oracle Hyperion Financial Reportingコンポーネントの特性

- 15.1.10.1.1 状態情報

- 15.1.10.1.2 ランタイム・プロセス

- 15.1.10.1.3 外部依存性

- 15.1.10.1.4 構成アーティファクト

- 15.1.10.1.5 デプロイメント・アーティファクト

- 15.1.10.1.6 ログ・ファイル

- 15.1.11 Oracle Hyperion Financial Reportingの高可用性の概要

- 15.1.11.1 Oracle Hyperion Financial Reportingの高可用性アーキテクチャ

- 15.1.11.1.1 共有されたファイルとディレクトリ

- 15.1.11.1.2 クラスタワイドの構成変更

- 15.1.11.2 障害からの保護および予想される動作

- 15.1.12 Allocation Managerのコンポーネント・アーキテクチャと特性

- 15.1.13 Oracle BI EEの高可用性の構成手順

- 15.1.13.1 Oracle BI Enterprise EditionおよびBI Publisherの高可用性構成の設定前に必要な手順

- 15.1.13.1.1 データベースに関する前提条件

- 15.1.13.1.2 VIPとIPに関する前提条件

- 15.1.13.1.3 共有記憶域に関する前提条件

- 15.1.13.1.4 クロックの同期

- 15.1.13.1.5 データベース・リポジトリのインストールと構成

- 15.1.13.1.6 RCUを使用したデータベースへのBusiness Intelligenceスキーマのロード

- 15.1.13.1.7 ロード・バランサの仮想サーバー名とポートの構成

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

- 15.1.13.1.9 Oracle HTTP Serverの検証

- 15.1.13.2 高可用性のためのOracle Business Intelligence Enterprise Editionのインストール

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

- 15.1.13.2.2 Business Intelligence Enterprise EditionおよびOracle BI Publisher用のOracle Fusion Middlewareのインストール

- 15.1.13.3 APPHOST1のVIP1およびAPPHOST2のVIP2の有効化

- 15.1.13.4 管理サーバーと1つ目のBI_SERVER1管理対象サーバーが含まれたドメインの作成

- 15.1.13.5 APPHOST1での管理サーバーのboot.propertiesの作成

- 15.1.13.6 APPHOST1での管理サーバーの起動と検証

- 15.1.13.6.1 APPHOST1での管理サーバーの起動

- 15.1.13.6.2 管理サーバーの検証

- 15.1.13.7 BI_SERVER1管理対象サーバーのリスニング・アドレスの設定

- 15.1.13.7.1 Oracle BI Publisher Schedulerの構成の更新

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

- 15.1.13.9 APPHOST1でのシステムの起動

- 15.1.13.9.1 APPHOST1でのノード・マネージャの起動

- 15.1.13.9.2 BI_SERVER1管理対象サーバーの起動と検証

- 15.1.13.9.3 APPHOST1でのBI EEシステム・コンポーネントの起動と検証

- 15.1.13.10 Oracle BI EEの構成

- 15.1.13.10.1 共有Oracle BIリポジトリの場所の設定

- 15.1.13.10.2 BI Serverの共有グローバル・キャッシュの設定

- 15.1.13.10.3 Schedulerスクリプト・パスとデフォルト・スクリプト・パスの設定

- 15.1.13.10.4 共有Oracle BIプレゼンテーション・カタログの場所の設定

- 15.1.13.11 サーバー構成オプションの設定

- 15.1.13.12 APPHOST2でのBIシステムのスケール・アウト

- 15.1.13.13 BIシステム・コンポーネントのスケール・アウト

- 15.1.13.14 シングルトン・コンポーネントのアクティブ/パッシブ化

- 15.1.13.15 BI_SERVER2管理対象サーバーのリスニング・アドレスの設定

- 15.1.13.15.1 APPHOST1およびAPPHOST2でのOracle BI Publisher Schedulerの構成の更新

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

- 15.1.13.17 Oracle BI for Microsoft OfficeのSSOプロパティの構成

- 15.1.13.17.1 Oracle BI for Microsoft Officeの構成の検証

- 15.1.13.18 Oracle BI Publisherの構成

- 15.1.13.18.1 Oracle BIプレゼンテーション・サービスのオプションの設定

- 15.1.13.18.2 スケジューラ構成オプションの設定

- 15.1.13.18.3 Oracle BI EEデータ・ソースの設定

- 15.1.13.18.4 Oracle BI Publisher用のJMSの構成

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

- 15.1.13.19 APPHOST2でのシステムの起動

- 15.1.13.19.1 APPHOST2でのノード・マネージャの起動

- 15.1.13.19.2 BI_SERVER2管理対象サーバーの起動と検証

- 15.1.13.19.3 Business Intelligence Enterprise Editionシステム・コンポーネントの起動と検証

- 15.1.13.20 BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成

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

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

- 15.1.13.22 BI_SERVERnサーバーのサーバー移行の構成

- 15.1.13.22.1 サーバー移行leasing表のユーザーと表領域の設定

- 15.1.13.22.2 管理コンソールによるマルチ・データ・ソースの作成/GridLinkデータ・ソースの作成

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

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

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

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

- 15.1.13.23 Oracle BI EEトポロジのスケール・アップ

- 15.1.13.24 新しいノード(APPHOST3)へのOracle BI EEトポロジのスケール・アウト

- 15.2 Oracle Business Intelligence Publisherの高可用性

- 15.2.1 Oracle BI Publisherのコンポーネント・アーキテクチャ

- 15.2.1.1 Oracle BI Publisherコンポーネントの特性

- 15.2.1.1.1 状態情報

- 15.2.1.1.2 ランタイム・プロセス

- 15.2.1.1.3 プロセスのライフサイクル

- 15.2.1.1.4 リクエスト・フロー

- 15.2.1.1.5 外部依存性

- 15.2.1.1.6 構成アーティファクト

- 15.2.1.1.7 デプロイメント・アーティファクト

- 15.2.1.1.8 ログ・ファイル

- 15.2.2 Oracle BI Publisherの高可用性の概要

- 15.2.2.1 Oracle BI Publisherの高可用性アーキテクチャ

- 15.2.2.1.1 共有されたファイルとディレクトリ

- 15.2.2.1.2 クラスタワイドの構成変更

- 15.2.2.2 障害からの保護および予想される動作

- 15.2.2.3 トラブルシューティング

- 15.2.3 Oracle BI Publisherの高可用性の構成手順

- 15.2.3.1 環境の準備: Oracle BI Publisherの高可用性構成の設定前に必要な手順

- 15.2.3.1.1 データベースに関する前提条件

- 15.2.3.1.2 VIPとIPに関する前提条件

- 15.2.3.1.3 共有記憶域に関する前提条件

- 15.2.3.1.4 クロックの同期

- 15.2.3.1.5 データベース・リポジトリのインストールと構成

- 15.2.3.1.6 RCUを使用したデータベースへのBusiness Intelligenceスキーマのロード

- 15.2.3.1.7 ロード・バランサの仮想サーバー名とポートの構成

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

- 15.2.3.1.9 Oracle HTTP Serverの検証

- 15.2.3.2 Oracle Fusion Middlewareホームのインストール

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

- 15.2.3.2.2 BI Publisher用のOracle Fusion Middlewareのインストール

- 15.2.3.3 APPHOST1のVIP1およびAPPHOST2のVIP2の有効化

- 15.2.3.4 管理サーバーと1つ目のBI_SERVER1管理対象サーバーが含まれたドメインの作成

- 15.2.3.5 APPHOST1での管理サーバーのboot.propertiesの作成

- 15.2.3.6 APPHOST1での管理サーバーの起動と検証

- 15.2.3.6.1 APPHOST1での管理サーバーの起動

- 15.2.3.6.2 管理サーバーの検証

- 15.2.3.7 BI_SERVER1管理対象サーバーのリスニング・アドレスの設定

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

- 15.2.3.9 APPHOST1でのシステムの起動

- 15.2.3.9.1 APPHOST1でのノード・マネージャの起動

- 15.2.3.9.2 BI_SERVER1管理対象サーバーの起動と検証

- 15.2.3.10 APPHOST2でのBIシステムのスケール・アウトの前提条件

- 15.2.3.10.1 サーバー構成オプションの設定

- 15.2.3.10.2 スケジューラ構成オプションの設定

- 15.2.3.10.3 Oracle BI Publisher Schedulerの構成の更新

- 15.2.3.11 APPHOST2でのBIシステムのスケール・アウト

- 15.2.3.12 BI_SERVER2管理対象サーバーのリスニング・アドレスの設定

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

- 15.2.3.14 Oracle BI Publisherの構成

- 15.2.3.14.1 BI Publisher用のJMS永続ストアの構成

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

- 15.2.3.15 APPHOST2でのシステムの起動

- 15.2.3.15.1 APPHOST2でのノード・マネージャの起動

- 15.2.3.15.2 BI_SERVER2管理対象サーバーの起動と検証

- 15.2.3.16 BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成

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

- 15.2.3.18 BI_SERVERnサーバーのサーバー移行の構成

- 15.2.3.19 新しいノード(APPHOST3)へのOracle BI Publisherトポロジのスケール・アウト

- 15.3 Oracle Real-Time Decisionsの高可用性

- 15.3.1 Oracle RTDのコンポーネント・アーキテクチャ

- 15.3.1.1 Oracle RTDコンポーネントの特性

- 15.3.1.1.1 コンポーネントのライフサイクル

- 15.3.1.1.2 プロセス・フロー

- 15.3.1.1.3 外部依存性

- 15.3.1.1.4 構成アーティファクト

- 15.3.1.1.5 デプロイメント・アーティファクト

- 15.3.1.1.6 ログ・ファイルの場所

- 15.3.2 Oracle RTDの高可用性の概要

- 15.3.2.1 Oracle RTDの高可用性アーキテクチャ

- 15.3.2.1.1 クラスタの起動と停止

- 15.3.2.1.2 クラスタワイドの構成変更

- 15.3.2.2 障害からの保護および予想される動作

- 15.3.2.2.1 Decision Serverの障害

- 15.3.2.2.2 クラスタ・コーディネータの障害

- 15.3.2.2.3 学習サービスの障害

- 15.3.2.2.4 Decision Centerの障害

- 15.3.2.2.5 バッチ・マネージャの障害

- 15.3.3 Oracle RTDの高可用性の構成手順

- 15.3.3.1 Oracle RTDの高可用性構成の設定前に必要な手順

- 15.3.3.1.1 データベースに関する前提条件

- 15.3.3.1.2 データベース・リポジトリのインストールと構成

- 15.3.3.1.3 RCUを使用したデータベースへのBusiness Intelligenceスキーマのロード

- 15.3.3.1.4 ロード・バランサの仮想サーバー名とポートの構成

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

- 15.3.3.1.6 Oracle HTTP Serverの検証

- 15.3.3.2 Oracle Fusion Middlewareホームのインストール

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

- 15.3.3.2.2 Oracle RTDのインストール

- 15.3.3.3 APPHOST1のVIP1およびAPPHOST2のVIP2の有効化

- 15.3.3.4 管理サーバーと1つ目のBI_SERVER1管理対象サーバーが含まれたドメインの作成

- 15.3.3.5 APPHOST1での管理サーバーのboot.propertiesの作成

- 15.3.3.6 APPHOST1での管理サーバーの起動と検証

- 15.3.3.6.1 APPHOST1での管理サーバーの起動

- 15.3.3.6.2 管理サーバーの検証

- 15.3.3.7 BI_SERVER1管理対象サーバーのリスニング・アドレスの設定

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

- 15.3.3.9 APPHOST1でのシステムの起動

- 15.3.3.9.1 APPHOST1でのノード・マネージャの起動

- 15.3.3.9.2 BI_SERVER1管理対象サーバーの起動と検証

- 15.3.3.10 APPHOST2でのBIシステムのスケール・アウト

- 15.3.3.11 BI_SERVER2管理対象サーバーのリスニング・アドレスの設定

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

- 15.3.3.13 Oracle RTDの構成

- 15.3.3.13.1 RTDクラスタ固有プロパティの構成

- 15.3.3.14 APPHOST2でのシステムの起動

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

- 15.3.3.14.2 APPHOST2でのノード・マネージャの起動

- 15.3.3.14.3 BI_SERVER2管理対象サーバーの起動と検証

- 15.3.3.15 BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成

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

- 15.3.3.17 BI_SERVERnサーバーのサーバー移行の構成

- 15.3.3.18 新しいノード(APPHOST3)へのOracle RTDトポロジのスケール・アウト

16 HAパワー・ツールの使用

- 16.1 Oracle WebLogic管理コンソールでのHAパワー・ツールの有効化

- 16.2 HAパワー・ツールを使用したクラスタのJavaオブジェクト・キャッシュの構成

- 16.3 HAパワー・ツールを使用した管理対象サーバーのJavaオブジェクト・キャッシュの構成

A Oracle RACデータベース・ストアを使用した監査の設定

- A.1 WebLogic Serverを使用した監査データ・ソースおよびマルチ・データ・ソースの構成

- A.2 監査ローダーのJDBC文字列の構成

B 推奨されるマルチ・データ・ソース

- B.1 JDBC Multi Data Source-0

- B.2 JDBC Data Source-0(非XA)

- B.3 JDBC Data Source-0(XA)

C Windowsでのサーバー全体の移行

- C.1 Windowsコントロール・パネルの使用

- C.2 netshコマンドラインの使用

D コンポーネントのワークブック

- D.1 Oracle SOA Suiteのワークブック

- D.1.1 Oracle SOA Suiteのワークブック表

- D.2 Oracle Identity Managementのワークブック

- D.2.1 Oracle Identity Managementのワークブック表

- D.3 Oracle WebCenterポータルのワークブック

- D.3.1 Oracle WebCenterポータルのワークブック表

- D.4 Oracle Portal、Forms、ReportsおよびDiscovererのワークブック

- D.4.1 Oracle Portal、Forms、ReportsおよびDiscovererのワークブック表

- D.5 Oracle WebCenter Contentのワークブック

- D.5.1 Oracle WebCenter Contentのワークブック表

- D.6 Oracle Data Integratorのワークブック

- D.6.1 Oracle Data Integratorのワークブック表

- D.7 Oracle Business Intelligence Platformのワークブック

- D.7.1 Oracle Business Intelligence Platformのワークブック表

E ascrsctlのオンライン・ヘルプ

- E.1 start

- E.2 stop

- E.3 status

- E.4 switch

- E.5 delete

- E.6 create/disk

- E.7 update/disk

- E.8 create/vip

- E.9 update/vip

- E.10 create/dblsnr

- E.11 update/dblsnr

- E.12 create/db

- E.13 update/db

- E.14 create/as

- E.15 update/as

F 分散Javaオブジェクト・キャッシュの構成

- F.1 Javaオブジェクト・キャッシュの構成

- F.2 CacheWatcherの実行

G MDSに対する分散通知の構成

例一覧

- 6-1 viewScope内のオブジェクトを変更するコード

- 6-2 オブジェクトの変更をOracle ADFに通知するための追加のコード

図一覧

- 1-1 アクティブ/アクティブおよびアクティブ/パッシブの高可用性ソリューション

- 2-1 Oracle Fusion Middleware環境

- 2-2 Oracle WebLogic Serverドメイン

- 2-3 Oracle Fusion Middlewareのエンタープライズ・デプロイメント・アーキテクチャ

- 2-4 アクティブ/パッシブ・コールド・フェイルオーバー・クラスタ・デプロイメントの例

- 2-5 Oracle Fusion Middlewareの障害時リカバリ・トポロジでの本番サイトとスタンバイ・サイト

- 3-1 移行可能なサーバーを含むクラスタの起動

- 3-2 障害が発生したサーバーの自動移行

- 3-3 サーバー全体の手動移行

- 4-1 マルチ・データ・ソース構成

- 5-1 Oracle SOA Suiteとコンポーネント

- 5-2 Oracle SOAインフラストラクチャ・スタックの図

- 5-3 Oracle SOAサービス・インフラストラクチャの基本的な単一ノード・アーキテクチャ

- 5-4 Oracle SOAサービス・インフラストラクチャ・アプリケーションの起動とシャットダウンのライフサイクル

- 5-5 Oracle SOAサービス・インフラストラクチャの高可用性アーキテクチャ

- 5-6 Oracle SOA Suiteコンポジットのクラスタワイドのデプロイメント

- 5-7 Oracle BPEL PMの単一インスタンス・アーキテクチャ

- 5-8 Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル

- 5-9 Oracle Enterprise Manager BPEL PMエンジンのリカバリ

- 5-10 Oracle BPEL PMの構成プロパティ

- 5-11 Oracle Enterprise Managerを使用したBPEL PMインスタンスのリカバリ

- 5-12 BPM Suiteの単一インスタンス・アーキテクチャ

- 5-13 BPM Suiteインフラストラクチャ・スタックの図

- 5-14 BPM Suiteのコンポーネントとインタフェース

- 5-15 BPMNサービス・エンジンの「プロパティ」ページの表示

- 5-16 BPMN MBeanブラウザの起動

- 5-17 Oracle BPMNサービス・エンジンの単一インスタンス・アーキテクチャ

- 5-18 Oracle BPMNサービス・エンジンの起動とシャットダウンのライフサイクル

- 5-19 Enterprise ManagerにおけるBPMNサービス・エンジンのホーム・ページ

- 5-20 Enterprise ManagerにおけるBPMNサービスの「リカバリ」ページ

- 5-21 Oracle BPM Suite Webアプリケーション

- 5-22 Oracle BPM Suite分析インフラストラクチャ

- 5-23 Oracle Mediatorの起動のライフサイクル

- 5-24 Oracle Enterprise Managerを使用したMediatorインスタンスのリカバリ

- 5-25 Oracle B2Bのリクエスト・フロー

- 5-26 Oracle WSMの単一インスタンス・アーキテクチャ

- 5-27 Oracle User Messaging Serviceの単一インスタンス・アーキテクチャ

- 5-28 Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle User Messaging Serviceの構成

- 5-29 Oracle JCAアダプタの単一インスタンス・アーキテクチャ

- 5-30 Oracle Business Activity Monitoringの単一インスタンス・アーキテクチャ

- 5-31 Oracle Business Activity Monitoringの起動とシャットダウンのライフサイクル

- 5-32 WebLogic Serverを使用したOracle Business Activity Monitoringの起動とシャットダウン

- 5-33 Fusion Middleware Controlを使用したOracle Business Activity Monitoringの起動とシャットダウン

- 5-34 Oracle Enterprise Manager Fusion Middleware Control

- 5-35 Oracle Business Activity Monitoringの構成

- 5-36 Oracle Business Activity Monitoringの構成プロパティ

- 5-37 Oracle BAMの高可用性アーキテクチャ

- 5-38 Oracle Service Busの機能

- 5-39 Oracle Service Busの単一インスタンス・アーキテクチャ

- 5-40 Oracle Service Busの高可用性アーキテクチャ

- 5-41 Oracle SOAサービス・インフラストラクチャの高可用性アーキテクチャ

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

- 5-43 GridLink RACコンポーネント・スキーマの構成

- 5-44 「サーバーのマシンへの割当」画面

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

- 5-46 管理コンソールの「移行の状態」画面

- 5-47 Oracle SOAサービス・インフラストラクチャ、コンポーネント・サービス・エンジンおよびOracle Service Busの高可用性アーキテクチャ

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

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

- 5-50 「サーバーのマシンへの割当」画面

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

- 図5-52 管理コンソールの「移行の状態」画面

- 図5-53 管理コンソールの「移行の状態」画面

- 5-54 Oracle BAMの高可用性アーキテクチャ

- 5-55 JDBCコンポーネント・スキーマの構成

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

- 5-57 GridLink RACコンポーネント・スキーマの構成

- 6-1 Oracle ADFアーキテクチャの概要

- 6-2 シンプルなOracle ADFアーキテクチャ

- 6-3 Oracle ADFの基本的な単一ノード・アーキテクチャ

- 6-4 WebCenterポータルの基本的な単一ノード・アーキテクチャ

- 6-5 WebCenterポータルの2ノードの高可用性アーキテクチャ

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

- 6-7 GridLink RACコンポーネント・スキーマの構成

- 6-8 「サーバーのマシンへの割当」画面

- 7-1 Oracle Data Integratorの単一インスタンス・アーキテクチャ

- 7-2 Oracle Data Integratorエージェントの起動のサイクル

- 7-3 Oracle Data Integrator Studioに表示されるマスター・リポジトリのエージェント構成

- 7-4 Oracle Data Integratorの高可用性アーキテクチャ

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

- 7-6 GridLink RACコンポーネント・スキーマの構成

- 8-1 Oracle Fusion Middleware 11g Oracle Identity Managementの高可用性アーキテクチャ

- 8-2 非高可用性アーキテクチャのOracle Internet Directory

- 8-3 Oracle Internet Directoryクラスタ構成の高可用性アーキテクチャ

- 8-4 非高可用性アーキテクチャのOracle Virtual Directory

- 8-5 高可用性環境のOracle Virtual Directory

- 8-6 Oracle Directory Integration Platformのアーキテクチャ

- 8-7 高可用性アーキテクチャのOracle Directory Integration PlatformとOracle Directory Services Manager

- 8-8 Oracle Directory Services Managerのアーキテクチャ

- 8-9 高可用性アーキテクチャのOracle Directory Services ManagerとOracle Directory Integration Platform

- 8-10 コロケート・コンポーネント・アーキテクチャ

- 8-11 高可用性アーキテクチャにコロケートされたコンポーネント

- 8-12 Oracle Access Managerの単一インスタンス・アーキテクチャ

- 8-13 Oracle Access Managerの高可用性アーキテクチャ

- 8-14 Oracle Security Token Serviceの高可用性アーキテクチャ

- 8-15 Oracle Security Token Serviceのランタイム・プロセス

- 8-16 Oracle Identity Managerコンポーネント・アーキテクチャ

- 8-17 Oracle Identity Managerの高可用性アーキテクチャ

- 8-18 Oracle Adaptive Access Managerの単一インスタンス・アーキテクチャ

- 8-19 Oracle Adaptive Access Managerの高可用性アーキテクチャ

- 8-20 非高可用性アーキテクチャのOracle Identity Federation

- 8-21 高可用性アーキテクチャのOracle Identity Federation

- 9-1 Oracle HTTP Serverアーキテクチャ

- 9-2 Oracle HTTP Serverの高可用性アーキテクチャ

- 9-3 Webサーバーのアクセラレーション

- 9-4 Web層内でのOracle Web Cacheへのリクエスト・フロー

- 9-5 ロード・バランシング

- 9-6 フェイルオーバー

- 9-7 セッション・バインディング

- 9-8 Oracle Web Cacheのクラスタ・アーキテクチャ

- 10-1 高可用性を最大化するマルチマスター・レプリケーション・デプロイメント

- 11-1 単一インスタンスのImagingコンポーネント

- 11-2 Imagingの高可用性アーキテクチャの図

- 11-3 Oracle WebCenter Contentの単一インスタンス・アーキテクチャ

- 11-4 Oracle WebCenter Content 2ノード・クラスタ

- 11-5 Oracle WebCenter Contentの高可用性アーキテクチャ

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

- 11-7 GridLink RACコンポーネント・スキーマの構成

- 12-1 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ1

- 12-2 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ2

- 12-3 コールド・フェイルオーバー・クラスタのトポロジ例1

- 12-4 コールド・フェイルオーバー・クラスタのトポロジ例2

- 12-5 コールド・フェイルオーバー・クラスタのトポロジ例3

- 12-6 コールド・フェイルオーバー・クラスタの開始トポロジ例

- 12-7 変換後の可能なトポロジ

- 13-1 CRSトポロジの例1

- 13-2 CRSトポロジの例2

- 14-1 Oracle Portal、Forms、ReportsおよびDiscovererのアーキテクチャ

- 14-2 Oracle Portalの高可用性デプロイメント

- 14-3 Oracle Reportsの高可用性デプロイメント

- 14-4 Oracle Formsの高可用性デプロイメント

- 14-5 単一インスタンスのDiscovererトポロジ

- 14-6 複数のDiscovererコンポーネント間において実行時に行われる相互作用

- 14-7 複数インスタンスのDiscovererトポロジ

- 15-1 Oracle BI EEの単一インスタンス・アーキテクチャ

- 15-2 Oracle BI EEおよびEPMの高可用性デプロイメント

- 15-3 Oracle Essbaseの単一インスタンス・アーキテクチャ

- 15-4 Provider Servicesの単一インスタンス・アーキテクチャ

- 15-5 Workspaceの単一インスタンス・アーキテクチャ

- 15-6 Financial Reportingの単一インスタンス・アーキテクチャ

- 15-7 「Oracle BI EE Officeサーバーについて」ページ

- 15-8 Oracle BI for Microsoft Officeの「新規接続」ダイアログ

- 15-9 Microsoft Excel内の「Oracle BIタスク・ペイン」

- 15-10 Oracle BI Publisherの単一インスタンス・アーキテクチャ

- 15-11 Oracle BI Publisherの高可用性アーキテクチャ

- 15-12 Oracle RTDの単一インスタンス・アーキテクチャ

- 15-13 Oracle RTDの高可用性アーキテクチャ

表一覧

- 1-1 可用性の割合と対応する停止時間の値

- 1-2 Oracle Fusion Middlewareドキュメントで提供される高可用性情報

- 2-1 計画停止のソリューション

- 2-2 計画外停止のソリューション

- 4-1 推奨されるマルチ・データ・ソース構成

- 4-2 XAデータ・ソース構成

- 4-3 XA以外のデータ・ソース構成

- 4-4 OIDのデータベース・サービス・プロパティ設定

- 4-5 Oracle Formsのデータベース・サービス・プロパティ設定

- 4-6 SCANの実行時の内容と制限

- 5-1 BPMNプロセスの実行時にBPM Suiteコンポーネントによって実行されるタスク

- 5-2 仮想ホスト

- 5-3 共有記憶域の内容

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

- 5-5 外部ロード・バランサの仮想サーバー名

- 5-6 データ・ソースの値の構成

- 5-7 管理対象サーバーの構成

- 5-8 マシンの構成

- 5-9 PATH環境変数に必要なファイル

- 5-10 仮想ホスト

- 5-11 共有記憶域の内容

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

- 5-13 外部ロード・バランサの仮想サーバー名

- 5-14 データ・ソースの値の構成

- 5-15 管理対象サーバーの構成

- 5-16 SOAクラスタとOSBクラスタの追加

- 5-17 マシンの構成

- 5-18 JMSファイル・ストアの構成

- 5-19 仮想ホスト

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

- 5-21 BAMの外部ロード・バランサの仮想サーバー名とポート

- 5-22 データ・ソースの値の構成

- 5-23 管理対象サーバーの構成

- 5-24 マシンの構成

- 5-25 oracle-bamコンポーネントのターゲット・タイプ

- 5-26 PATH環境変数に含める必要のあるファイル

- 6-1 CHECK_STATE_SERIALIZATIONのオプション

- 6-2 WebCenterポータルの管理対象サーバーとアプリケーション

- 6-3 WebCenterポータルのJavaオブジェクト・キャッシュ用のオブジェクト・タイプ

- 6-4 WebCenterポータルのトラブルシューティングのシナリオ

- 6-5 WebCenterポータルでの予想される動作に対する例外

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

- 6-7 Oracle WebCenterポータルのデータ・ソース

- 6-8 管理対象サーバーの構成

- 6-9 マシンの構成

- 7-1 データ・ソースの値の構成

- 8-1 11g Identity Managementコンポーネントおよび製品スイート

- 8-2 アイデンティティ管理で使用されるデータベースの構成例

- 8-3 外部ロード・バランサの仮想サーバー名

- 8-4 Oracle Internet Directoryのノード

- 8-5 Oracle Internet Directoryのプロセス・ログ・ファイルの場所

- 8-6 Directory Integration Platformの起動に必要な構成パラメータ

- 8-7 各マルチ・データ・ソース・スキーマのスキーマ所有者とパスワードの入力

- 8-8 JMSシステム・リソースに対して選択する値

- 8-9 PATH環境変数に必要なファイル

- 8-10 WLS_OIM1、WLS_OIM2、WLS_SOA1、WLS_SOA2サーバー移行

- 8-11 Oracle Identity Federationのデプロイメント・オプションに対応する一時データ・ストアのタイプ

- 8-12 Oracle Identity Federationのデプロイメント・オプションに対応する構成データ・ストアのタイプ

- 8-13 Oracle Identity Federationのデプロイメント・オプションに対応するフェデレーション・データ・ストアのタイプ

- 10-1 Oracle Databaseアドバンスト・マルチマスター・レプリケーションの設定手順

- 10-2 Oracle Databaseアドバンスト・レプリケーションでのノードの追加手順

- 10-3 Oracle Advanced Databaseレプリケーションでのノードの削除手順

- 11-1 データ・ソースの値の構成

- 14-1 Portalの構成ファイル

- 14-2 Oracle Reportsコンポーネント

- 15-1 Oracle BI EEシステム・コンポーネントのログ・ファイル

- 15-2 Essbaseの構成アーティファクト

- 15-3 BI EEの仮想ホスト

- 15-4 BI EEの共有記憶域の内容

- 15-5 bioffice.xmlに含まれるOracle BI for Microsoft Officeのプロパティ

- 15-6 PATH環境変数に必要なファイル

- 15-7 BI Publisherの仮想ホスト

- 15-8 BI Publisherの共有記憶域の内容

- 15-9 Oracle RTD MBeanに設定する属性値

- C-1 アプリケーションのURL

- D-1 アプリケーションのURL

- D-2 仮想IPアドレス

- D-3 ファイルの場所: アプリケーション層

- D-4 ファイルの場所: Web層

- D-5 Identity Managementの詳細

- D-6 データベース情報: メタデータ・リポジトリ

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

- D-8 ポート情報

- D-9 アプリケーションのURL

- D-10 仮想IPアドレス

- D-11 汎用ファイルの場所

- D-12 IDMHOSTnのファイルの場所

- D-13 OIDHOSTnのファイルの場所

- D-14 OVDHOSTnのファイルの場所

- D-15 OAMHOSTnのファイルの場所

- D-16 OIMHOSTnのファイルの場所

- D-17 OAAMHOSTnのファイルの場所

- D-18 OIFHOSTnのファイルの場所

- D-19 Web層のファイルの場所

- D-20 Identity Managementのアーティファクト

- D-21 Oracle Identity Federation用の認証LDAPのアーティファクト

- D-22 Oracle Identity Federation用のLDAPユーザー・データ・ストアのアーティファクト

- D-23 Oracle Identity Federation用のLDAPフェデレーション・データ・ストアのアーティファクト

- D-24 Oracle Identity Federation用のRDBMSユーザー・データ・ストアのアーティファクト

- D-25 Oracle Identity Federation用のRDBMSフェデレーション・データ・ストアのアーティファクト

- D-26 Oracle Identity Federation用のRDBMS一時データ・ストアのアーティファクト

- D-27 メタデータ・リポジトリのデータベース情報

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

- D-29 ポート情報

- D-30 アプリケーションのURL

- D-31 仮想IPアドレス

- D-32 ファイルの場所: アプリケーション層

- D-33 ファイルの場所: Web層

- D-34 Identity Managementの詳細

- D-35 データベース情報: メタデータ・リポジトリ

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

- D-37 ポート情報

- D-38 アプリケーションのURL

- D-39 仮想IPアドレス

- D-40 ファイルの場所

- D-41 データベース情報: メタデータ・リポジトリ

- D-42 データベース情報: メタデータ・リポジトリ

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

- D-44 ポート情報

- D-45 アプリケーションのURL

- D-46 仮想IPアドレス

- D-47 ファイルの場所: アプリケーション層

- D-48 ファイルの場所: Web層

- D-49 データベース情報: メタデータ・リポジトリ

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

- D-51 ポート情報

- D-52 アプリケーションのURL

- D-53 仮想IPアドレス

- D-54 ファイルの場所: アプリケーション層

- D-55 ファイルの場所: Web層

- D-56 データベース情報: メタデータ・リポジトリ

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

- D-58 ポート情報

- D-59 アプリケーションのURL

- D-60 仮想IPアドレス

- D-61 ファイルの場所: アプリケーション層

- D-62 ファイルの場所: Web層

- D-63 データベース情報

- D-64 ロード・バランシングの構成

- D-65 ポート情報

- E-1 createコマンドのリソース値

- E-2 updateコマンドのリソース値

Oracle® Fusion Middleware

高可用性ガイド

11g リリース1(11.1.1)

B55898-07(原本部品番号:E10106-20)

2012年4月

管理者や開発者など、高可用性を扱う方を対象としており、高可用性の概要について説明し、また高可用性を目的としてOracle Fusion Middlewareをデプロイおよび管理するための管理手順と構成手順についても説明します。

Oracle Fusion Middleware高可用性ガイド, 11g リリース1(11.1.1)

B55898-07

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

原本著者: Christine Ford

原本協力者: Fermin Castro、Michael Blevins、Pradeep Bhat、Susan Kornberg、Joe Paul、Pramodini Gattu、Gururaj BS

協力者: Christelle Balon

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

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

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次の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 Fusion Middlewareをデプロイおよび管理することを役割としている方を対象としています。

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

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

Oracleサポートへのアクセス

お客様は、My Oracle Supportを使用して電子サポートにアクセスできます。詳細は、http://www.oracle.com/support/contact.htmlを参照してください。聴覚障害のあるお客様は、http://www.oracle.com/accessibility/support.htmlを参照してください。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

- 『Oracle Fusion Middleware概要』

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

表記規則

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

規則

意味

太字

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

イタリック

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

固定幅

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

1 高可用性の概要

高可用性アーキテクチャは、エンタープライズ・デプロイメントの主要な要件の1つです。Oracle Fusion Middlewareは、計画外停止からそのコンポーネントとアプリケーションを保護し、計画停止を最小限に抑える広範な高可用性機能を備えています。

このマニュアルで説明するソリューションと手順は、Oracle Fusion Middlewareコンポーネントのシングル・ポイント障害をなくし、停止時間をなくすか、または最小限に抑えるように設計されています。これらのソリューションを使用すると、Oracle Fusion Middlewareにデプロイされているアプリケーションがビジネス目標の達成に必要な可用性を実現できるようになります。

このマニュアルでは、Oracle Fusion Middlewareコンポーネントのアーキテクチャ、相互作用および依存関係について、またこれらを高可用性アーキテクチャにどのようにデプロイできるのかについて説明します。

この章では、高可用性とその重要性についてOracle Fusion Middlewareの観点から説明します。この章の項目は次のとおりです。

- 第1.1項「高可用性とは」

- 第1.2項「他のドキュメントで提供される高可用性情報」

1.1 高可用性とは

高可用性とは、サービスを中断することなくユーザーがシステムにアクセスできることを指します。高可用性システムを配置すると、システムの停止時間つまり使用不可の時間が最小化され、システムの稼働時間つまり使用可能な時間が最大化されます。この項では、問題解決の観点から高可用性の概要を示します。この項の内容は次のとおりです。

- 第1.1.1項「高可用性の問題」

- 第1.1.2項「高可用性ソリューション」

1.1.1 高可用性の問題

ミッション・クリティカルなコンピュータ・システムは、24時間365日利用可能である必要があります。しかし、計画停止または計画外停止では、システムの一部またはすべてを停止することがあります。システムの可用性は、システム導入後の合計時間のうちのサービス提供時間の割合で測定されます。表1-1に、例を示します。

表1-1 可用性の割合と対応する停止時間の値

可用性の割合

年間停止時間の概算

95%

18日

99%

4日

99.9%

9時間

99.99%

1時間

99.999%

5分

システムの停止は、計画または計画外に分類できます。計画外停止は、なんらかの種類の予期しない障害です。計画停止とは、前もって知らされていて、システムを使用不可と解釈するスケジュール済操作を指します。計画停止がエンド・ユーザーに与える影響は通常、システム・トラフィックが遅いときに操作ウィンドウをスケジュールすることによって最小化されます。計画外停止はピーク時間に発生するため、計画停止より影響が大きくなって、システム・ユーザーに与えるインパクトが大きくなる場合があります。

停止のこれら2つのタイプ(計画停止と計画外停止)は通常、システムの可用性要件の設計時には別々に扱われます。システムの要件は、計画外停止に関しては非常に制限的な場合がありますが、計画停止に関しては非常にフレキシブルな場合があります。これは、営業時間には負荷がピークに達するが、夜間と週末にはほとんど非アクティブなままであるアプリケーションの場合に当てはまります。対応中の障害のタイプに応じて、別の高可用性機能を選択することもできます。

1.1.2 高可用性ソリューション

高可用性ソリューションは、1つのデータ・センター配置における高可用性を実現するローカル高可用性ソリューションと、通常は地理的に分散配置されていて、洪水や地域的なネットワークの停止などの災害からアプリケーションを保護する、障害時リカバリ・ソリューションに分類できます。

想定される障害タイプのうち、プロセス障害、ノード障害、メディア障害および人為ミスは、ローカル高可用性ソリューションで保護できます。データ・センター全体に影響を与えるローカルの物理的な障害については、地理的に分散された障害時リカバリ・ソリューションで保護できます。

高可用性の問題を解決するには、いくつかのテクノロジとベスト・プラクティスが必要になります。その中で最も重要なメカニズムは冗長性です。高可用性は、システムとコンポーネントに冗長性を持たせることによって実現されます。ローカル高可用性ソリューションは、冗長性のレベルによってアクティブ/アクティブ・ソリューションとアクティブ/パッシブ・ソリューションに分類されます(図1-1を参照)。

- アクティブ/アクティブ・ソリューションは、複数のアクティブなシステムのインスタンスをデプロイし、スケーラビリティの向上のほか、高可用性の提供に使用できます。アクティブ/アクティブ・デプロイでは、すべてのインスタンスは、同時にリクエストを処理します。

- アクティブ/パッシブ・ソリューションでは、リクエストを処理するアクティブ・インスタンスと、スタンバイ状態のパッシブ・インスタンスをデプロイします。さらに、この2つのインスタンスの間にハートビート・メカニズムが設定されます。このメカニズムは、オペレーティング・システムのベンダー固有のクラスタウェアで提供および管理されます。通常、ベンダー固有のクラスタ・エージェントでは、クラスタ・ノード間の監視とフェイルオーバーを自動的に行うことも可能なため、アクティブ・インスタンスに障害が発生した場合には、エージェントがそのアクティブ・インスタンスを完全に停止して、パッシブ・インスタンスをアクティブ化します。アプリケーション・サービスは、処理を再開できます。その結果、アクティブ/パッシブの役割が切り替わります。計画停止または計画外停止の場合は、この同じ手順を手動で行えます。アクティブ/パッシブ・ソリューションは一般に、コールド・フェイルオーバー・クラスタとも呼ばれます。
Oracle Cluster Ready Services(CRS)を使用すると、Fusion Middlewareのアクティブ/パッシブ(CFC)ソリューションを管理できます。

図1-1 アクティブ/アクティブおよびアクティブ/パッシブの高可用性ソリューション

「図1-1 アクティブ/アクティブおよびアクティブ/パッシブの高可用性ソリューション」の説明

包括的な高可用性システムでは、アーキテクチャの冗長性に加えて、次のローカル高可用性テクノロジも必要です。

- プロセス障害の検出と自動再起動
構成やソフトウェアに障害が発生したため、予期しないときにプロセスが停止する場合があります。プロセスの監視と再起動が適切に行われるシステムでは、すべてのシステム・プロセスが常時監視され、障害がある場合にそれらが再起動されます。

システム・プロセスは、特定の時間間隔における再起動の回数も記録している必要があります。短期間に何度も再起動を行うと他の障害を引き起こすことがあるため、これも重要な機能です。したがって、特定の時間間隔における再起動や再試行の回数の上限も指定しておく必要があります。

- クラスタリング
システムのコンポーネントをまとめてクラスタリングすることにより、クライアント側は、ランタイム処理と管理性の観点から、これらのコンポーネントを機能的に1つのエンティティとみなすことができます。クラスタは、1つのコンピュータ、または同じワークロードを共有する複数のコンピュータ上で実行される一連のプロセスです。クラスタリングと冗長性には密接な関係があります。クラスタは、システムの冗長性を実現します。

クラスタ環境でトランザクション中にフェイルオーバーが発生した場合、クラスタ内に使用可能なインスタンスが1つでも残っているかぎり、セッション・データは保持されます。

- 状態のレプリケーションとルーティング
ステートフル・アプリケーションでは、これらのリクエストを処理しているプロセスに障害が発生した場合、リクエストのステートフル・フェイルオーバーを有効にするためにクライアント状態をレプリケートできます。

- フェイルオーバー
ロード・バランシング・メカニズムが利用されると、インスタンスは冗長になります。いずれかのインスタンスに障害が発生した場合、そのインスタンスに対するリクエストを、障害の発生していないインスタンスに送信できます。

- サーバーのロード・バランシング
同じサーバー・コンポーネントの複数のインスタンスを使用できる場合、これらのコンポーネントに対するクライアント・リクエストは、各インスタンスのワークロードがほぼ同一になるようにロード・バランシングされます。

- サーバーの移行
一部のサービスでは、常に1つのインスタンスしか実行できません。アクティブ・インスタンスが使用できなくなった場合、サービスは別のクラスタ・メンバー上で自動的に開始されます。または、サーバー・プロセス全体をクラスタ内の別のシステム上で自動的に開始できます。

- 統合された高可用性
コンポーネントは、他のコンポーネントに依存してサービスを提供します。サービスを中断させることなく依存コンポーネントの障害からこのコンポーネントをリカバリできることが必要です。

- ローリング・パッチ適用
多くの場合、製品バイナリにパッチを適用するには、停止時間が必要になります。実行中のクラスタにローリング形式でパッチを適用すると停止時間を回避できます。同様に、パッチはローリング形式でアンインストールできます。

- 構成管理
類似したコンポーネントを1つのグループにクラスタリングすると、多くの場合、共通の構成を共有する必要があります。適切な構成管理によって、コンポーネントは同じ着信リクエストに対して同じ応答を返し、コンポーネントの構成の同期化が可能になり、管理目的の停止時間を短縮する可用性の高い構成管理を実現できます。

- バックアップとリカバリ
ユーザー・エラーによってシステムが誤作動することがあります。特定の状況下では、コンポーネントまたはシステムの障害が修復不可能なこともあります。そのため、バックアップとリカバリの機能を使用してシステムを一定の間隔でバックアップし、修復不可能な障害が発生したときにバックアップをリストアできるようにする必要があります。

1.2 他のドキュメントで提供される高可用性情報

表1-2に、高可用性情報について記述しているOracle Fusion Middlewareのガイド(このガイド以外)を示します。この情報は、Oracle Fusion Middlewareの各種コンポーネントの高可用性に関連するものです。

表1-2 Oracle Fusion Middlewareドキュメントで提供される高可用性情報

コンポーネント

情報の場所

Oracle SOA Suite

Oracle Fusion Middleware Oracle SOA Suite管理者ガイド

Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド

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

Oracle WebCenterポータル

Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイド

Oracle Fusion Middleware Oracle WebCenterインストレーション・ガイド

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

Oracle ADF

Oracle Fusion Middleware Oracle Application Development FrameworkのためのFusion開発者ガイド

Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド

Oracle Data Integrator

Oracle Fusion Middleware Oracle Data Integrator開発者ガイド

Oracle Fusion Middleware Oracle Data Integrator接続およびナレッジ・モジュール・ガイド

Oracle Fusion Middleware Oracle Data Integratorナレッジ・モジュール開発者ガイド

Oracle WebLogic Serverクラスタ

Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用

Oracle Fusion Middlewareのバックアップとリカバリ

Oracle Fusion Middleware管理者ガイド

Oracle Web Cache

Oracle Fusion Middleware Oracle Web Cache管理者ガイド

Oracle Identity Management

Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド

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

Oracle Virtual Directory

Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド

Oracle HTTP Server

Oracle Fusion Middleware Oracle HTTP Server管理者ガイド

Oracle Internet Directory

Oracle Fusion Middleware Oracle Internet Directory管理者ガイド

Oracle Access Manager

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

Oracle Authorization Policy Manager

Oracle Fusion Middleware Authorization Policy Manager管理者ガイド

Oracle Identity Manager

Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイド

Oracle Adaptive Access Manager

Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド

Oracle Real Application Clusters(Oracle RAC)

Oracle Real Application Clustersインストレーション・ガイド

Oracle WebCenter Content

Oracle Fusion Middleware Oracle Enterprise Content Management概要ガイド

Oracle WebCenter Content: Imaging

Oracle WebCenter Content Imaging管理者ガイド

Oracle WebCenter Content

Oracle WebCenter Content Content Serverシステム管理者ガイド

Oracle WebCenter Content: Records

Oracle Fusion Middleware Universal Records Management管理者ガイド

Oracleリポジトリ作成ユーティリティ(RCU)

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

Oracle Portal

Oracle Fusion Middleware Oracle Portal管理者ガイド

Oracle Forms

Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド

Oracle Reports

Oracle Fusion Middleware Oracle Reportsレポート作成のためのユーザーズ・ガイド

Oracle Business Intelligence Discoverer

Oracle Fusion Middleware Oracle Business Intelligence Discoverer管理者ガイド

Oracle Business Intelligence Enterprise Edition

Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド

Oracle Real-Time Decisions

Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド

2 Oracle Fusion Middlewareの高可用性フレームワーク

この章では、高可用性トポロジにおいて重要となるOracle Fusion Middlewareの機能について説明します。次の項目が含まれます。

- 第2.1項「Oracle Fusion Middlewareの概要の理解」

- 第2.2項「Oracle Fusion Middlewareの高可用性の用語」

- 第2.3項「Oracle Fusion Middlewareの高可用性ソリューション」

- 第2.4項「計画停止および計画外停止からの保護」

2.1 Oracle Fusion Middlewareの主要概念の概要

Oracle Fusion Middlewareには、次の2種類のコンポーネントが用意されています。

- Javaコンポーネント: Javaコンポーネントは、システム・コンポーネントと対等なものですが、1つ以上のJava EEアプリケーションおよび一連のリソースとしてデプロイされます。Javaコンポーネントは、ドメイン・テンプレートの一部としてOracle WebLogic Serverドメインにデプロイされます。Javaコンポーネントの例としては、Oracle SOA SuiteおよびOracle WebCenterポータル: Spacesがあります。

- システム・コンポーネント: システム・コンポーネントは、Javaアプリケーションとしてデプロイされない管理可能なプロセスです。システム・コンポーネントは、Oracle Process Manager and Notification(OPMN)で管理されます。システム・コンポーネントの例には、Oracle HTTP ServerおよびOracle Internet Directoryが含まれます。

Javaコンポーネントとシステム・コンポーネントはピアです。

Oracle Fusion Middlewareをインストールして構成すると、Oracle Fusion Middleware環境には、次が含まれます。

- Oracle WebLogic Serverドメイン: 1つの管理サーバーと1つまたは複数の管理対象サーバーが含まれます。

- 1つ以上のシステム・コンポーネント・ドメイン(環境にシステム・コンポーネントが含まれている場合)。

- Oracle Metadata Repository(インストールしたコンポーネントで必要な場合)。たとえば、Oracle SOA SuiteにはOracle Metadata Repositoryが必要です。

図2-1に、Oracle Fusion Middlewareの環境(1つの管理サーバーと2つの管理対象サーバーを含むOracle WebLogic Serverドメイン、システム・コンポーネント・ドメイン、およびOracle Metadata Repositoryで構成されています)を示します。

図2-1 Oracle Fusion Middleware環境

「図2-1 Oracle Fusion Middleware環境」の説明

環境には、Middlewareホームも含まれます。これは、Oracle WebLogic Serverホーム、および必要に応じて1つ以上のOracleホームで構成されます。

2.1.1 WebLogic Serverドメインとは

WebLogic Server管理ドメインは、論理的に関連するJavaコンポーネントのグループです。ドメインには、管理サーバーと呼ばれる特別なWebLogic Serverインスタンスが含まれます。これは、ドメインのすべてのリソースを構成して管理する中核部分です。通常、管理対象サーバーと呼ばれるWebLogic Serverの追加インスタンスを含めて、ドメインを構成します。管理対象サーバーには、Webアプリケーション、EJB、WebサービスなどのJavaコンポーネントやその他のリソースをデプロイして、管理サーバーは構成および管理の目的にのみ使用します。

ドメイン内の管理対象サーバーは、クラスタにグループ化できます。

Oracle WebLogic Serverドメインは、システム・コンポーネント・ドメインと同格です。どちらにも、Oracleホームの外部に固有の構成があります。

WebLogic Serverドメインのディレクトリ構造とWebLogic Serverホームのディレクトリ構造は別です。場所はどこでもよく、Middlewareホーム・ディレクトリ内にある必要はありません。

図2-2に、1つの管理サーバー、3つのスタンドアロンの管理対象サーバー、およびクラスタ化された3つの管理対象サーバーで構成されるOracle WebLogic Serverドメインを示します。

図2-2 Oracle WebLogic Serverドメイン

「図2-2 Oracle WebLogic Serverドメイン」の説明

関連項目:

ドメイン構成の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverのドメイン構成の理解を参照してください。

次の項では、ドメインのエンティティについて説明します。

- 管理サーバーとは

- 管理対象サーバーおよび管理対象サーバー・クラスタの理解

- ノード・マネージャとは

2.1.1.1 管理サーバーとは

管理サーバーは、ドメイン全体を構成するための集中管理エンティティとして動作します。ここにはドメインの構成ドキュメントが保持され、構成ドキュメントの変更がここから管理対象サーバーに配布されます。管理サーバーは、ドメイン内のリソースをすべて監視するための中央拠点として使用できます。

WebLogic Serverのドメインごとに、管理サーバーとして動作するサーバー・インスタンスが1つ必要です。

管理サーバーと対話するために、Oracle WebLogic Server管理コンソールであるOracle WebLogic Scripting Tool(WLST)を使用するか、または独自のJMXクライアントを作成できます。また、一部のタスクには、Oracle Enterprise Manager Fusion Middleware Controlを使用することもできます。

Fusion Middleware ControlとWebLogic管理コンソールは、管理サーバーで稼働します。Fusion Middleware Controlは、Oracle Fusion Middlewareの管理に使用するWebベースの管理コンソールであり、Oracle Fusion Middlewareには、Oracle HTTP Server、Oracle SOA Suite、Oracle WebCenterポータルなどのコンポーネント、Oracle Portal、Forms、Reports、Discoverer、およびOracle Identity Managementコンポーネントが含まれています。Oracle WebLogic Server管理コンソールは、ドメイン内の管理サーバーや管理対象サーバーなど、Oracle WebLogic Serverドメイン内のリソースの管理に使用されるWebベースの管理コンソールです。

2.1.1.2 管理対象サーバーおよび管理対象サーバー・クラスタの理解

管理対象サーバーでは、ビジネス・アプリケーション、アプリケーション・コンポーネント、Webサービス、およびそれらに関係するリソースがホストされます。パフォーマンスを最適化するために、管理対象サーバーには、ドメインの構成ドキュメントの読取り専用のコピーが保持されます。管理対象サーバーが起動すると、ドメインの管理サーバーに接続して、その構成ドキュメントと管理サーバーに保持されているドキュメントが同期化されます。

ドメインの作成時には、特定のドメイン・テンプレートを使用して作成します。そのテンプレートでは、特定のコンポーネントまたはOracle SOA Suiteのようなコンポーネントのグループがサポートされます。ドメイン内の管理対象サーバーは、それらの特定のOracle Fusion Middlewareシステム・コンポーネントをホストすることのみを目的として作成されます。

JavaベースのOracle Fusion Middlewareシステム・コンポーネント(Oracle SOA Suite、Oracle WebCenterポータル、一部のIdentity Managementコンポーネントなど)は、顧客が開発したアプリケーションとともに、ドメイン内の管理対象サーバーにデプロイされます。

別のコンポーネントをサポートするテンプレートを使用して作成されたドメインに、Oracle WebCenterポータルなど、他のコンポーネントを追加する場合には、ドメイン内に追加の管理対象サーバーを作成し、追加するコンポーネント用のドメイン・テンプレートを使用して、ドメインを拡張できます。

アプリケーションのパフォーマンス、スループットまたは高可用性の向上が要求される本番環境では、クラスタとして動作するように複数の管理対象サーバーを構成できます。クラスタとは、同時に稼働し、協調動作によってスケーラビリティと信頼性の向上を実現する、WebLogic Serverの複数のサーバー・インスタンスの集合です。クラスタでは、(単一の管理対象サーバーでなく)管理対象サーバーごとに、ほとんどのリソースおよびサービスがまったく同じようにデプロイされるため、フェイルオーバーとロード・バランシングが可能になります。1つのドメインには、複数のWebLogic Serverクラスタが存在していても、クラスタとして構成されていない複数の管理対象サーバーが存在していてもかまいません。管理対象サーバーがクラスタ化されている場合とされていない場合の重要な違いは、フェイルオーバーとロード・バランシングに対するサポートです。これらの機能は、管理対象サーバーがクラスタ化されている場合にのみ利用できます。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のWebLogic Serverのクラスタリングに関する項

2.1.1.3 ノード・マネージャとは

ノード・マネージャは、Oracle WebLogic Serverとは別のプロセスとして稼働するJavaユーティリティであり、これを使用すると、管理サーバーを基準とした場所に関係なく、管理対象サーバーに対して共通操作を実行できます。ノード・マネージャを使用するかどうかはオプションですが、高可用性を要求するアプリケーションがWebLogic Server環境でホストされている場合には、ノード・マネージャを使用すると貴重な利点が得られます。

管理対象サーバーをホストするシステムでノード・マネージャを実行する場合、管理コンソールまたはコマンドラインを使用して、管理対象サーバーをリモートで起動または停止できます。ノード・マネージャを使用して、予期しない障害が発生した後に、管理対象サーバーを自動的に再起動することもできます。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』

2.1.2 システム・コンポーネント・ドメインとは

システム・コンポーネント・ドメインには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどのシステム・コンポーネントが1つ以上含まれています。システム・コンポーネント・ドメイン内のシステム・コンポーネントは、同じシステム上にある必要があります。システム・コンポーネント・ドメイン・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルが格納されています。

システム・コンポーネント・ドメインは、Oracle WebLogic Serverドメインと同格です。どちらにも、Oracleホームの外部に固有の構成があります。

システム・コンポーネント・ドメインのディレクトリ構造とOracleホームのディレクトリ構造は別です。場所はどこでもよく、Middlewareホーム・ディレクトリ内にある必要はありません。

2.1.3 Middlewareホームとは

Middlewareホームは、Oracle WebLogic Serverホーム、およびオプションで1つ以上のOracleホームから構成されています。

Middlewareホームは、ローカル・ファイル・システム上、またはNFS経由でアクセスできるリモート共有ディスク上に配置できます。

Oracleホームの詳細は、第2.1.4項「Oracleホームとは」を参照してください。Oracle WebLogic Serverホームの詳細は、第2.1.1項「WebLogic Serverドメインとは」を参照してください。

複数のホストがクラスタ化されている高可用性インストールでは、Middlewareホームのバイナリを、クラスタ内のすべてのホスト上で同一ディレクトリ・パスのディレクトリにインストールする必要があります。

2.1.4 Oracleホームとは

Oracleホームには、特定の製品をホストするために必要なインストール済ファイルが含まれています。たとえば、SOA Oracleホームには、Oracle SOA Suiteのバイナリ・ファイルおよびライブラリ・ファイルで構成されるディレクトリが含まれています。

Oracleホームは、Middlewareホームのディレクトリ構造の中にあります。それぞれのOracleホームには、複数のシステム・コンポーネント・ドメインまたはOracle WebLogic Serverドメインを関連付けることができます。

複数のホストがクラスタ化されている高可用性インストールでは、Oracleホームのバイナリを、クラスタ内のすべてのホスト上で同一ディレクトリ・パスのディレクトリにインストールする必要があります。

2.1.4.1 Oracle共通ホームとは

Oracle共通ホームには、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)で必要なバイナリおよびライブラリ・ファイルが含まれています。それぞれのMiddlewareホーム内のOracle共通ホームは、1つに限られます。

2.1.5 WebLogic Serverホームとは

WebLogic Serverホームには、WebLogic Serverのホスティングに必要なファイルがインストールされています。WebLogic Serverホームのディレクトリは、Oracleホームのディレクトリのピアであり、Middlewareホームのディレクトリ構造の中に存在します。

2.2 Oracle Fusion Middlewareの高可用性の用語

この項で一覧表示されている用語の定義は、このマニュアルで説明されている概念の理解に役立ちます。

- フェイルオーバー: 高可用性システムのメンバーに予期しない障害(計画外停止)が発生した場合、コンシューマへのサービス提供を継続するために、フェイルオーバー操作が実行されます。アクティブ/アクティブ・システムの場合、ロード・バランサのエンティティがアクティブ・メンバーにリクエストを配信することにより、フェイルオーバーが実行されます。アクティブ・メンバーに障害が発生すると、ロード・バランサにより障害が検出され、障害メンバーへのリクエストが、正常に動作しているアクティブ・メンバーに自動的にリダイレクトされます。
アクティブ/パッシブ・システムの場合、フェイルオーバー操作によってパッシブ・メンバーがアクティブになり、コンシューマはそのメンバーに接続されます。フェイルオーバー・プロセスは手動で実行できますが、障害を検出したらクラスタのリソースを障害ノードからスタンバイ・ノードに移動するようハードウェア・クラスタ・サービスを設定することにより、フェイルオーバー操作を自動化することもできます。

- フェイルバック: 計画外停止後に計画されている操作です。システムがフェイルオーバー操作に成功した後、障害が発生した元のメンバーを修復して、スタンバイ・メンバーとしてシステムに再導入できます。フェイルバック・プロセスを開始して、このメンバーをアクティブにし、別のメンバーを非アクティブにすることができます。このプロセスによって、システムが障害発生前の構成に戻されます。

- 共有記憶域: クラスタ内の各ノードが、各自のプロセス・セットを実行するスタンドアロン・サーバーの場合でも、クラスタ内のすべてのノードから統一アクセスが必要なファイル・システム・ベースのデータおよび構成要素があります。共有記憶域とは、クラスタ内のいずれかのノードから同じ記憶域(通常はディスク)にアクセスできるクラスタの機能のことです。
SANベースのデプロイメントでは、OCFSなど、クラスタ化されたファイル・システムが必要になる場合もあります。この使用例として、JMSファイル・ベースの永続ストア、トランザクション・ログ永続ストア、コールド・フェイルオーバー・クラスタ設定時のドメイン構成などがあります。

- 1次ノード: クラスタ内で常にOracle Fusion Middlewareをアクティブに実行しているノードです。このノードで障害が発生すると、Oracle Fusion Middlewareは2次ノードにフェイルオーバーされます。1次ノードではアクティブなOracle Fusion Middlewareインストールが実行されているため、このノードで障害が発生すると、Oracle Fusion Middlewareは2次ノードにフェイルオーバーされます。この項の2次ノードの定義を参照してください。

- 2次ノード: アクティブなOracle Fusion Middlewareインストールが実行されている1次ノードで障害が発生すると、Oracle Fusion Middlewareはこのノードにフェイルオーバーされます。この項の1次ノードの定義を参照してください。

- ネットワーク・ホスト名: /etc/hostsファイル(UNIXの場合)、C:\WINDOWS\system32\drivers\etc\hostsファイル(Windowsの場合)またはDNS解決のいずれかで指定される、IPアドレスに割り当てられる名前です。この名前は、システムが接続しているネットワークで参照可能です。多くの場合、ネットワーク・ホスト名と物理ホスト名は同じものを指します。しかし、各システムが持つ物理ホスト名は1つのみですが、ネットワーク・ホスト名は複数持つことができます。したがって、システムのネットワーク・ホスト名が常に物理ホスト名になるわけではありません。

- 物理ホスト名: このマニュアルでは、物理ホスト名とネットワーク・ホスト名の用語が区別されます。このマニュアルでは、物理ホスト名は、現行システムの内部名を表すために使用されます。UNIXでは、hostnameコマンドにより返される名前です。

- スイッチオーバーとスイッチバック: 計画された操作です。通常の運用時に、システムのアクティブ・メンバーのメンテナンスまたはアップグレードが必要になることがあります。スイッチオーバー・プロセスを開始して、メンテナンス、アップグレードまたはなんらかの計画停止が必要なメンバーによって処理されているワークロードを、他のメンバーに引き継がせることができます。スイッチオーバー操作によって、システムのコンシューマにサービスを継続して提供できます。
メンテナンスやアップグレードが完了すると、スイッチバック操作を実行して、アップグレードしたメンバーをアクティブ化し、スイッチオーバー前のシステム構成に戻すことができます。

- 仮想IP: ネットワーク・クライアントに対してクラスタの単一システム・ビューを提供するために、クラスタのメンバーであるサーバーのグループに対して、仮想IPはエントリ・ポイントのIPアドレスとして機能します。仮想IPは、サーバーのロード・バランサまたはハードウェア・クラスタに割り当てることができます。
また、ロード・バランサも一連のサーバーのエントリ・ポイントとして仮想IPを使用します。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーに割り当てられるのではなく、サーバーとクライアントの間のプロキシとして機能するロード・バランサに割り当てられます。

- 仮想ホスト名: クラスタで、クラスタ内のいずれかのノードに常時バインドされた仮想IPに割り当てられるネットワーク・ホスト名です。

注意:

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

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

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

- クラスタウェア: クラスタ・メンバーの操作をシステムとして管理するソフトウェアです。これにより、クラスタ・メンバー間のハートビート・メカニズムを使用して、監視対象のリソースとサービスのセットを定義したり、これらのリソースとサービスをクラスタ内の別のメンバーにできるだけ効率的かつ透過的な方法で移動できます。

2.3 Oracle Fusion Middlewareの高可用性ソリューション

この項では、ローカル高可用性の概要およびOracle Fusion Middlewareの高可用性テクノロジについて説明します。この項の項目は次のとおりです。

- 第2.3.1項「ローカル高可用性」

- 第2.3.2項「Oracle Fusion Middlewareの高可用性テクノロジ」

- 第2.3.3項「アクティブ/パッシブ・デプロイメント」

- 第2.3.4項「アクティブ/アクティブおよびアクティブ/パッシブ・ソリューションについて」

- 第2.3.5項「障害時リカバリ」

2.3.1 ローカル高可用性

ローカル高可用性ソリューションは、アクティブ/アクティブとアクティブ/パッシブいずれかのソリューションに分類できます。Oracle Fusion Middlewareでは、アクティブ/アクティブ・デプロイメントもアクティブ/パッシブ・デプロイメントもサポートされます。

図2-3に、Oracle Fusion Middlewareの高可用性のアクティブ/アクティブ・デプロイメント・トポロジを示します。

図2-3 Oracle Fusion Middlewareのエンタープライズ・ デプロイメント・アーキテクチャ

「図2-3 Oracle Fusion Middlewareのエンタープライズ・デプロイメント・アーキテクチャ」の説明

図2-3に示すように、このトポロジは複数層アーキテクチャを表しています。ユーザーはクライアント層からシステムにアクセスします。リクエストはハードウェア・ロード・バランサを通過し、そこで、Web層のOracle HTTP ServerおよびOracle Web Cacheが稼働しているWebサーバー・クラスタにルーティングされます。Webサーバーでは、プロキシ・プラグイン(mod_wl_ohs)を使用して、リクエストをアプリケーション層のWebLogicクラスタにルーティングします。次に、アプリケーション層のWebLogicクラスタで稼働しているアプリケーションが、データ層のデータベース・クラスタと対話して、リクエストに応じます。

アーキテクチャ全体で、シングル・ポイント障害はありません。第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」で説明しているように、WebLogic管理サーバーは、コールド・フェイルオーバー・クラスタ・モードで構成され、外部のクラスタウェアを使用して保護されます。

2.3.2 Oracle Fusion Middlewareの高可用性テクノロジ

Oracle Fusion Middlewareインフラストラクチャには、次の高可用性機能があります。

- プロセス障害の検出と自動再起動
WebLogic Serverで稼働するJava EEコンポーネントの場合、ノード・マネージャで管理対象サーバーを監視します。管理対象サーバーが停止すると、ノード・マネージャは、構成された回数にわたって、管理対象サーバーの再起動を試行します。

システム・コンポーネントの場合、OPMNでプロセスを監視します。システム・コンポーネント・プロセスが停止すると、OPMNは、構成された回数、再起動を試行します。

- クラスタリング
Oracle Fusion MiddlewareのJava EEコンポーネントは、クラスタリングを実現するための基盤となる優れたWebLogic Serverクラスタリング機能を活用しています。Oracle Fusion Middlewareでは、冗長性、フェイルオーバー、セッション状態レプリケーション、クラスタワイドのJNDIサービス、サーバー全体の移行、クラスタワイドの構成など、WebLogicが持つクラスタリング機能を使用します。

これらの機能により、クライアントに透過的なすべてのJava EE Oracle Fusion Middlewareシステム・コンポーネントのシームレスなフェイルオーバーが実現し、セッションおよびトランザクションのデータが保持され、データの整合性も保証されます。これらの機能の詳細は、第3章「WebLogic Serverの高可用性」を参照してください。

システム・コンポーネントは、実行時クラスタにデプロイすることもできます。これらのフロントエンドには通常、トラフィックをルーティングするロード・バランサが配置されます。

- 状態のレプリケーションとルーティング
Oracle WebLogic Serverは、ステートフル・アプリケーションの状態をレプリケートするように構成できます。そのためには、クラスタ・メンバーである別の管理対象サーバー上で状態情報のレプリカを保持します。ADFやWebCenterなど、ステートフルなOracle Fusion Middlewareコンポーネントは、この機能を活用して、クラスタの他のメンバーに対するシームレスなフェイルオーバーを保証します。

Oracle Internet Directory、Oracle HTTP Server、Oracle Web Cacheなどのシステム・コンポーネントはステートレスです。

Oracle FormsやOracle Reportsなど、いくつかのOracle Fusion Middlewareコンポーネントには、Cで実装された機能の一部があります。それらはステートフルであり、状態のレプリケーション機能はありません。これらのコンポーネントのフェイルオーバーの詳細は、次のパラグラフを参照してください。

- フェイルオーバー
一般的には、Oracle Fusion MiddlewareのJava EEコンポーネントが稼働する管理対象サーバーには、Oracle HTTP ServerなどのWebサーバーがあり、管理対象サーバーの前面にクラスタ化されています。Webサーバーのプロキシ・プラグイン(mod_wl_ohs)は、様々な管理対象サーバーの実行時の可用性、および状態のレプリカが保持される管理対象サーバーの場所を認識しています。プライマリ管理対象サーバーが使用できなくなると、プラグインによって、アプリケーションが使用可能なサーバーにリクエストがルーティングされます。Oracle ADFやOracle WebCenterポータルなどのステートフル・アプリケーションの場合、新しい管理対象サーバーへのルーティング時にレプリカの場所も考慮されます。

ステートレス・システム・コンポーネントの場合、それらの複数のインスタンスは実行時クラスタとして、ロード・バランサの背後にデプロイされます。ロード・バランサは、コンポーネント・インスタンスの定期的なヘルス・チェックを実行するように構成します。インスタンスが使用できない場合、ロード・バランサは後続のリクエストを別の使用可能なインスタンスにルーティングして、フェイルオーバーをシームレスに行います。

Cをベースとした部品を持ち、状態のレプリケーションを持たないステートフル・コンポーネントの場合、スティッキーなルーティングにより、状態が最初に確立されたクラスタ・メンバーに後続のリクエストが送信されるようになります。これは、Webサーバーのプロキシ・プラグインおよびコンポーネントのJava EE部品により保証されます。コンポーネント・インスタンスに障害が発生すると、後続のリクエストは、クラスタ内の別の使用可能なメンバーにルーティングされます。このような状況では、状態情報は失われ、ユーザーはセッションを再作成する必要があります。

一部のコンポーネントの内部実装はEJBを使用します。EJBフェイルオーバーは、レプリカ対応のWebLogic Serverスタブでシームレスに処理されます。

必要に応じて、コンポーネントはJTAに準拠し、フェイルオーバーの場合にデータの整合性が保持されます。

シングルトン・サービスは、シングルトンSOAアダプタなどの組込みフェイルオーバー機能を活用するか、または、サーバー全体の移行など、基礎となるWebLogic Serverインフラストラクチャを使用します。

- サーバーの移行
SOAなど、Oracle Fusion Middlewareのコンポーネントは、JMSやJTAなどの固定サービスを使用し、WebLogic Serverの機能を活用して、フェイルオーバー時に別のクラスタ・メンバー上で自動的に再起動できます。

- 統合された高可用性
Oracle Fusion Middlewareには、Oracle RACデータベースの可用性およびスケーラビリティを活用するため、ロード・バランシングおよびフェイルオーバーの周囲に総合的な機能セットがあります。Oracle Fusion Middlewareのすべてのコンポーネントには、計画停止または計画外停止によってOracle RACインスタンスが使用できなくなったことが原因で発生した、サービス、データまたはトランザクションの消失に対する組込みの保護が用意されています。これを実現するには、Oracle WebLogic Serverのマルチ・データ・ソースを使用します。また、障害発生時に進行中のトランザクションをシームレスにフェイルオーバーするために、コンポーネントには適切な例外処理および構成可能な再試行ロジックが用意されています。

Oracle SOAコンポーネントなど、XAに準拠したアプリケーションでは、WebLogic Serverはトランザクション・コーディネータとして機能し、トランザクションのすべてのブランチが、Oracle RACインスタンスのいずれかに固定されるようになります。

管理対象サーバーに障害が発生した場合には、トランザクション・サービスはクラスタ内の別のノードに自動的に移行され、トランザクションのリカバリが実行されます。

Webサーバーとアプリケーション・サーバー間の通信において、プロキシ・プラグインには、組込みのロード・バランシングおよびフェイルオーバーの機能があり、使用可能なクラスタ・メンバーにクライアントのリクエストがシームレスに再ルーティングされます。

- ローリング・パッチ適用
Oracle WebLogic Serverでは、ローリング・パッチを使用できます。ローリング・パッチでは、クラスタ全体を停止することなく、マイナーなメンテナンス・パッチをローリング形式で製品バイナリに適用できます。

クラスタにローリング・パッチを適用する際は、クラスタ内の各サーバーで個別にパッチを適用して再起動する一方、クラスタ内の他のサーバーではアプリケーションを引き続きホストします。パッチ、メンテナンス・パック、またはマイナー・リリースを、ローリング形式でアンインストールすることもできます。

- 構成管理
Oracle Fusion Middlewareコンポーネントのほとんどは、クラスタ・レベルで構成できます。Oracle Fusion Middlewareでは、データ・ソース、EJB、JMSなど、サーバーを構成するためのWebLogic Serverのクラスタワイドの構成機能、およびコンポーネントのアプリケーション・アーティファクト、ADFおよびWebCenterのカスタム・アプリケーションを使用します。

- バックアップとリカバリ
Oracle Fusion Middlewareのバックアップとリカバリは、中間層コンポーネントのファイル・システム・コピーに基づく単純なソリューションです。Oracle DatabaseにはRMANが使用されます。オンライン・バックアップのサポートもあります。Oracle Fusion Middlewareを使用すると、バックアップとリカバリを行う既存のツールに統合するか、またはOracle Fusion Middleware Enterprise Managerまたはcronジョブを介して、スケジュールされたバックアップ・タスクを使用できます。

2.3.2.1 サーバーのロード・バランシング

通常、Oracle Fusion Middlewareの高可用性デプロイメントのフロントエンドにはロード・バランサが配置され、様々なアルゴリズムを使用して受信したリクエストを分散するように構成できます。

Oracle Fusion Middlewareには、コンポーネント内で対話するための組込みのロード・バランシング機能もあります。たとえば、Webサーバーとアプリケーション・サーバーやアプリケーション・サーバーとデータベース・サーバーで対話できます。

Oracle Fusion Middleware 11gでは、外部ロード・バランサは提供されていません。使用する外部ロード・バランサとOracle Fusion Middlewareとの互換性を保証するには、その外部ロード・バランサが次に示す要件を満たしていることを確認してください。

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

- ロード・バランサには複数の仮想サーバーを構成できる必要があります。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、Oracle Fusion Middleware Identity Managementの場合は、HTTP / HTTPSトラフィック用の1つの仮想サーバーとポート、およびLDAPとLDAPSトラフィック用の個別の仮想サーバーとポートでロード・バランサを構成する必要があります。

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

- 永続性/振分け: 一部のOracle Fusion Middlewareコンポーネントでは、外部ロード・バランサの永続性や振分けを使用します。使用する外部ロード・バランサで、Cookieの永続性をURIレベルで設定できない場合は、Cookieの永続性をすべてのHTTPトラフィックに設定します。いずれの場合も、ブラウザのセッションが失効するときにCookieも失効するように設定します。詳細は、使用する外部ロード・バランサのドキュメントを参照してください。
Oracle Fusion Middlewareでは、Oracle HTTP ServerのフロントエンドとしてWeb層にロード・バランサ、Oracle HTTP Serverのバックエンドとしてアプリケーション層にOracle WebLogic Serverを配置するアーキテクチャをお薦めします。

Oracle WebLogic ServerをWeb層のロード・バランサの直後に配置する場合は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のロード・バランサとWebLogicセッションCookieの項の説明を確認してください。これは、Oracle Fusion Middlewareで推奨されるデプロイメント・アーキテクチャではありません。

- リソースの監視/ポートの監視/プロセス障害検出: 外部ロード・バランサを、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへのトラフィック送信を停止するように構成します。外部ロード・バランサによっては、障害の自動検出機能を備えているものもあります。
たとえば、Oracle Fusion Middleware Identity Managementでは、外部ロード・バランサでOracle Internet Directory、Oracle Fusion Middleware Single Sign-OnおよびOracle Delegated Administration Serviceを監視する必要があります。これらのコンポーネントを監視するには、次のプロトコルのモニターを設定します。

- LDAPおよびLDAPS用リスニング・ポート

- HTTPおよびHTTPS用リスニング・ポート(デプロイメント・タイプによる)

これらのモニターは個別のプロトコルを使用してサービスを監視します。つまり、LDAPポートにはLDAP、LDAP SSLポートにはSSL経由のLDAP、Oracle HTTP ServerポートにはHTTP/HTTPSを使用します。外部ロード・バランサがこれらのモニターを提供していない場合は、そのロード・バランサのドキュメントを参照し、着信リクエストが使用不可のサービスに自動ルーティングされないようにするための最適な構成方法を確認してください。

- ネットワーク・アドレス変換(NAT): ロード・バランサには、クライアントからOracle Fusion Middlewareのノードにルーティングされるトラフィックに対するネットワーク・アドレス変換(NAT)機能が必要です。

- ポート変換の構成: ロード・バランサには、1つのポートで受信した受信リクエストを別のポートで実行されているサーバー・プロセスにルーティングできるポート変換機能が必要です。たとえば、ポート80で受信したリクエストをポート7777にルーティングできます。

- プロトコル変換: ロード・バランサには、異なるプロトコルを実行するシステム間のプロトコル変換機能が必要です。これにより、発行元デバイスとターゲット指定されたホストに関連付けられているネイティブ・プロトコル・スタックが異なる場合も、あるネットワークに接続しているユーザーが別のネットワーク上のホストにアクセスできます。たとえば、HTTPSリクエストを受信して、HTTPリクエストを送信することができます。
この機能は推奨されますが、必須ではありません。

- SSLアクセラレーション: SSLアクセラレーションは、SSLトランザクションで実行され、プロセッサを集中的に使用する公開鍵暗号化アルゴリズムを、ハードウェア・アクセラレータにオフロードする方法です。
この機能は推奨されますが、必須ではありません。

- フォルト・トレラント・モード: ロード・バランサがシステムのシングル・ポイント障害にならないように、ロード・バランサをフォルト・トレラント・モードで構成することを強くお薦めします。これにより、単一のプロセス/インターセプタに基づくほとんどのソフトウェア・ロード・バランサは、信頼できるソリューションから除外されます。

- クライアントIPアドレス保持機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入する機能またはクライアントIPアドレスを保持する同様の機能が必要です。

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

前述のすべての要件を満たす必要はありません。外部ロード・バランサの要件は、検討しているトポロジ、およびロード・バランシングを行うOracle Fusion Middlewareコンポーネントにより異なります。

2.3.3 アクティブ/パッシブ・デプロイメント

Oracle Fusion Middlewareは、Oracle Fusion Middleware Cold Failover Clustersを使用して、すべてのコンポーネントにアクティブ/パッシブ・モデルを提供します。Oracle Fusion Middleware Cold Failover Cluster構成では、複数のアプリケーション・サーバー・インスタンスが同じアプリケーション・ワークロードを提供するように構成されますが、アクティブとなるインスタンスは常に1つのみです。

図2-4に、アクティブ/パッシブ・デプロイメントの例を示します。

図2-4 アクティブ/パッシブ・コールド・フェイルオーバー・クラスタ・デプロイメントの例

「図2-4 アクティブ/パッシブ・コールド・フェイルオーバー・クラスタ・デプロイメントの例」の説明

図2-4では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。Middlewareホームとドメイン・ディレクトリは、ある時点でノード1またはノード2にマウントされている共有ディスク上にあります。Middlewareホームとドメイン・ディレクトリは両方とも、同じ共有ディスク上、またはいっしょにフェイルオーバーできる複数の共有ディスク上にあります。複数のアプリケーションまたは環境用に複数のFusion Middlewareドメインがある企業では、管理サーバーの高可用性にはこのトポロジが最適です。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。それぞれの管理サーバーでは、その仮想IPおよび一連の共有ディスクを使用して、ドメイン・サービスの高可用性を実現できます。

アクティブ/パッシブの概要およびOracle Cold Failover Clustersの構成手順の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。

2.3.4 アクティブ/アクティブおよびアクティブ/パッシブ・ソリューションについて

可能な場合は、 アクティブ/アクティブ・ソリューションの使用をお薦めします。これは最大限の可用性を実現するための第一の推奨事項です。アクティブ/アクティブ・ソリューションは、ノード、インスタンスおよびコンポーネントの障害に対して、迅速なフェイルオーバー、スケーラビリティ、および保護を提供します。さらに、アクティブ/アクティブ・ソリューションでは、透過的なフェイルオーバーが可能となり、垂直および水平スケーリングのためのリソースの追加も容易です。

Oracle Fusion Middlewareの高可用性ソリューションを設計するときは、スケーラビリティに関する要件が重要な検討事項になります。アクティブ/アクティブ・ソリューションは、同一ノード内にインスタンスやコンポーネントを追加することで(垂直に)スケール・アップします。

同一ノードに複数の冗長なサービスを追加するとシステムの可用性は向上しますが、これはノード障害ではなくインスタンス障害に対してのみ有効です。さらに、第2.3.2項「Oracle Fusion Middlewareの高可用性テクノロジ」で説明されているように、Oracle Fusion Middlewareには、コンポーネントの障害検出機能と自動再起動機能も用意されています。アクティブ/アクティブの高可用性ソリューションには、異なるノードにインストールされた複数のアクティブ・インスタンスが含まれます。その結果、1つのノードが完全に失われた場合でも、他のインスタンスが使用できるため、システムは絶え間なく稼働し続けます。異なるノードで複数のインスタンスを使用することにより、水平スケーラビリティ、すなわちスケール・アウトが提供されます。

アクティブ/アクティブ・ソリューションには、アクティブなOracle Fusion Middlewareインスタンスの間でリクエストのロード・バランシングやフェイルオーバーを行うためのロジックが必要です。ロード・バランシングは、着信リクエストを異なる複数のサービス・プロバイダに分散させることにより実現します。フェイルオーバーは、これらのサービス・プロバイダで障害を検出し、リクエストを他の使用可能なサービス・プロバイダに再ルーティングすることにより実現します。このロジックは様々な方法で実装されます。

- 直接的な実装: クライアントがシステムにリクエストすることによって直接実装されます。たとえば、JDBCクライアントは、Oracle Database(Real Application Cluster)の複数のインスタンスに接続するロード・バランシングおよびフェイルオーバーのロジックを実装します。外部ハードウェアのロード・バランサで実装することも可能です。

- サード・パーティによる実装: クライアントのリクエストを捕捉し複数のOracleインスタンスに負荷を分散するサード・パーティのコンポーネントによって実装されます。複数のOracleインスタンスがグループ化されて連動する場合、これらのインスタンスはシステムへの単一の仮想エントリ・ポイントとして機能します。これにより複数のインスタンスの構成は隠ぺいされます。外部ロード・バランサは、クラスタ内のどのアプリケーション・サーバー・インスタンスにもリクエストを送信できます。これは、いずれのインスタンスもすべてのリクエストを処理できるためです。

アクティブ/アクティブ構成のスケーラビリティ特性とは異なり、アクティブ/パッシブ構成ではパッシブ・コンポーネントはアクティブ・コンポーネントに障害が発生したときのみ使用されます。アクティブ/アクティブ・ソリューションでは、すべてのインスタンスがリクエストを並行に処理します。その結果、アクティブ/アクティブ・システムでは、アクティブ/パッシブ・システムよりも高い透過性と優れたスケーラビリティが提供されます。

アクティブ/パッシブ・ソリューションは、1つのノードのみがアクティブな状態で維持される垂直スケーラビリティに制限されます。アクティブ/パッシブ・ソリューションでは、障害発生時に暗黙のフェイルオーバー時間も発生します。通常、このフェイルオーバー時間は、障害後アクティブになったノードにおいてコンポーネントの再起動にかかる時間によって決まります。一方、アクティブ/パッシブ・モデルの運用コストやライセンス費用はアクティブ/アクティブ・デプロイメントよりも安価です。

状況によっては、アクティブ/パッシブ・ソリューションが適している場合があります。次のシナリオでは、ハードウェア・クラスタベースのアクティブ/パッシブ・ソリューションを使用することをお薦めします。

- ロード・バランサのライセンス取得、管理、および所有権にかかわる総費用の面からアクティブ/アクティブ・ソリューションが除外される場合。特に、使用可能なハードウェア・クラスタがある場合。ハードウェア・クラスタには、2つのノード、ノードを接続するスイッチ、および両方のハードウェア・ノードから到達可能な共有記憶域が必要です。

- シングルトン・サービスを保護する場合に検討すべき点について次に示します。シングルトン・サービスを使用する場合、実行時に存続できるアクティブ・インスタンスは1つだけです。シングルトン・サービスは他のコンポーネントに対して重要な場合があります。シングルトン・サービスは通常、複数のコンポーネントに対して基本的なサービスを提供するため、使用不可の場合は他の多くのサービスやプロセスが使用できなくなる可能性があります。シングルトン・サービスを保護する場合に検討すべき点について次に示します。

- リカバリ時間: シングルトン・サービスまたはシングルトン・コンポーネントは、アクティブ/アクティブ構成では実行できません。クライアントのリクエストは、サービスの複数インスタンスに対して透過的にロード・バランシングされません。これは、障害が発生した場合、暗黙的なリカバリ時間を要することを意味します。このリカバリ時間は、採用するシングルトン保護モデルのタイプにより異なります。

- 障害検出における信頼性: 偽陽性を防止する必要があります。ほとんどのシングルトン・サービスはデータ・リポジトリにアクセスしますが、データ・リポジトリは、同時アクセス用に設計されている場合とそうでない場合があります。シングルトン・サービスが動作不能と報告され、システムが別のインスタンスを起動しようとした場合、スプリット・ブレインのシナリオが生じる可能性があります。動作不能となったサービスについては、同時実行性の影響、および障害検出のメカニズムに基づいて誤判定が生じる可能性を分析する必要があります。

- 再起動時のサービスの一貫性: シングルトン・コンポーネントはフェイルオーバー後も一貫したサービスを提供する必要があります。これらのコンポーネントは障害からのリカバリ後も同じ動作を持続することが要求されます。サービスで使用する構成および永続リポジトリは、障害時も使用可能でなければなりません。さらに、起動がフェイルオーバーに依存している必要があります。たとえば、シングルトン・サービスの再起動が必要となった場合、その再起動は他のサービスに依存している場合があるため、それらのサービスを維持する必要があります。

- コスト(必要なハードウェア/ソフトウェア・リソース): 様々な保護メカニズムにより、純粋なソフトウェア・ベースのソリューションまたは暗黙のコストを伴うハードウェア・ベースのソリューションが必要になる場合があります。

- インストール/構成/管理: シングルトン・サービス用の様々な保護メカニズムを使用することで、システムの複雑性が増加しないようにする必要があります。

- メンテナンス(パッチ、アップグレード): シングルトン・サービス用の保護モデルでは、パッチやアップグレードの適用が容易にかつ最小限のダウンタイムで行われる必要があります。

これらの条件に基づき、Oracle Fusion Middleware Singleton Componentsでは、特定のシングルトン・サービスに関する要件に応じて、次のようなソリューションを使用できます。

- コールド・フェイルオーバー・クラスタ・ソリューション: このソリューションでは、共有記憶域とハードウェア障害検出用の接続が必要です。フェイルオーバー・プロシージャを介したVHNの移行によるリクエストの再ルーティングには、クライアントやロード・バランサのインテリジェント機能は必要ありません。

- サーバー全体の移行: 障害が発生した場合に、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを別の場所に移動するプロセスです。サーバー全体の移行の場合は、障害が発生すると、サーバー・インスタンスが物理的に別のシステムに移行されます。サービスレベルの移行の場合は、サービスをクラスタ内の別のサーバー・インスタンスに移動します。

- ソフトウェア・ブロッキング・メカニズムに基づくカスタム・アクティブ/パッシブ・モデル: このロジックは、同じコンポーネントの他のインスタンスが同時にアクティブになるのを防止するコンポーネントに含まれます。一般的なソリューションでは、データベースでロックを使用するか、同時実行性を防止するメモリー内のアクティブな通知をカスタマイズします。

多くの場合、障害検出の信頼性は、1つのソリューションを別のソリューションに採用する上で重要な要因となります。これは、特に同時実行性によりシングルトン・サービスで使用されるリソースに破損が生じるような場合に当てはまります。通常、ファイルは異なるアクティブ・インスタンスで同時に書き込まれる可能性があります。

この項で説明した問題には、各種のコンポーネントに別のソリューションを採用することもできます。

2.3.5 障害時リカバリ

図2-5に、障害時リカバリ用に構成されたOracle Fusion Middlewareのアーキテクチャを示します。Oracle Fusion Middlewareの製品バイナリ、構成ファイルおよびメタデータ・ファイルの場合、ディスク・レプリケーション・ベースのソリューションでは、NAS/SANデバイスにOracle Fusion Middlewareがデプロイされます。Oracleホームに格納されている製品バイナリおよび構成データは、ホスト・システムからマウントされた場所を使用して、NAS/SANデバイスに格納されます。また、ディスク・レプリケーション・テクノロジを使用して、本番サイトの共有記憶域システムからスタンバイ・サイトの共有記憶域システムに定期的に製品バイナリおよび構成をレプリケートします。スタンバイ・サイトのサーバーも、スタンバイ・サイトのディスクにマウントされます。本番(アクティブ)サイトに障害または計画停止が発生すると、スタンバイ(パッシブ)サイトへのレプリケーションは停止されます。その後、サービスおよびアプリケーションが、スタンバイ・サイトで開始されます。それ以降、ネットワーク・トラフィックはスタンバイ・サイトにルーティングされます。

Oracle Fusion Middlewareコンポーネントの障害時リカバリの詳細は、『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』を参照してください。

図2-5 Oracle Fusion Middlewareの障害時リカバリ・トポロジでの本番サイトとスタンバイ・サイト

「図2-5 Oracle Fusion Middlewareの障害時リカバリ・トポロジでの本番サイトとスタンバイ・サイト」の説明

2.4 計画停止および計画外停止からの保護

次の表に、発生しうる計画停止および計画外停止と、それぞれに対してお薦めするソリューションを一覧表示します。表2-1は、計画停止についての説明です。

表2-1 計画停止のソリューション

操作

ソリューション

アプリケーションのデプロイと再デプロイ

ホット・デプロイ

パッチ適用

ローリング・パッチ適用

構成の変更

構成のオンライン変更

変更の通知

変更のバッチ処理

アクティブ化の延期

スケーラビリティおよびトポロジの拡張

クラスタのスケールアウト

表2-2は、計画外停止についての説明です。

表2-2 計画外停止のソリューション

障害

ソリューション

ソフトウェア障害

Java EEコンポーネントにはノード・マネージャ、システム・コンポーネントにはOPMNを使用した障害検出および再起動

サーバー・クラスタ&ロード・バランシング

コールド・フェイルオーバー・クラスタ

サーバーの移行

サービスの移行

状態のレプリケーションおよびレプリカ対応スタブ

ハードウェア障害

サーバー・クラスタ&ロード・バランシング

サーバーの移行

クラスタウェアの統合

データ障害

人為的なエラー

バックアップとリカバリ

サイト障害

Oracle Fusion Middlewareの障害時リカバリ・ソリューション

注意:

このガイドで定義されているアーキテクチャとデプロイメント手順を使用することにより、単純なクラスタ・デプロイメントを実現できます。各章に記載されている手順は、このトポロジおよび他の類似する高可用性トポロジを、該当するFusion Middlewareコンポーネントで実現する場合の基礎的要素として使用できます。また、本番デプロイメントでは、セキュリティ・ポリシーと一元的なLDAPサーバーを関連付けるなど、この他にも必要な手順を使用することが予想されます。セキュアな複数層アーキテクチャおよびデプロイメント手順の詳細は、構成対象のコンポーネントのエンタープライズ・デプロイメント・ガイドを参照してください。

3 WebLogic Serverの高可用性

この章では、Oracle Fusion Middlewareの高可用性を実現するOracle WebLogic Serverの高可用性機能について説明します。

- 第3.1項「WebLogic Serverクラスタとは」

- 第3.2項「WebLogic ServerクラスタとWebLogic Serverドメイン」

- 第3.3項「クラスタリングの利点」

- 第3.4項「クラスタの主要機能」

- 第3.5項「クラスタ化可能なオブジェクトのタイプ」

- 第3.6項「クラスタ内の通信」

- 第3.7項「クラスタワイドのJNDIネーミング・サービス」

- 第3.8項「クラスタ内のフェイルオーバーとレプリケーション」

- 第3.9項「サーバー全体の移行」

- 第3.10項「JMSおよびJTAの高可用性」

- 第3.11項「管理サーバーおよびノード・マネージャの高可用性」

- 第3.12項「ロード・バランシング」

- 第3.13項「GridLinkデータ・ソース」

- 第3.14項「マルチ・データ・ソース」

- 第3.15項「クラスタの構成とconfig.xml」

- 第3.16項「シングルトン・サービスについて」

- 第3.17項「WebLogic ServerおよびLDAPの高可用性」

Oracle WebLogic Serverのクラスタリングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

3.1 WebLogic Serverクラスタとは

WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。クラスタを構成する複数のサーバー・インスタンスは同じシステム上で実行することも、複数のシステムに配置することもできます。クラスタの能力は、既存のシステム上のクラスタにサーバー・インスタンスを追加することによって強化できます。また、新たにサーバー・インスタンスを配置するためのシステムをクラスタに追加することもできます。クラスタ内の各サーバー・インスタンスでは、同じバージョンのWebLogic Serverが動作している必要があります。

3.2 WebLogic ServerクラスタとWebLogic Serverドメイン

クラスタとは、特定のWebLogic Serverドメインの一部です。ドメインとは、1つのユニットとして管理されるWebLogic Serverリソースの相互に関係するセットです。ドメインには1つ以上のWebLogic Serverインスタンスが含まれ、それらのインスタンスは、クラスタ化することもしないことも、あるいはその両方を混在させることもできます。1つのドメインに複数のクラスタを含めることができます。また、ドメインには、そのドメインにデプロイされたアプリケーション・コンポーネント、それらのアプリケーション・コンポーネントに必要なリソースとサービス、およびドメインのサーバー・インスタンスも含まれています。アプリケーションおよびサーバー・インスタンスで使用するリソースとサービスの例には、システムの定義、オプションのネットワーク・チャネル、コネクタおよび起動クラスなどがあります。

各ドメインでは、1つのWebLogic Serverインスタンスが管理サーバー(ドメイン内のその他すべてのサーバー・インスタンスおよびリソースを構成、管理および監視するサーバー・インスタンス)として動作します。各管理サーバーは、1つのドメインのみを管理します。ドメインに複数のクラスタが含まれている場合は、ドメイン内の各クラスタは同じ管理サーバーを持つことになります。

クラスタ内のサーバー・インスタンスはすべて、同じドメイン内にある必要があります。複数のドメインにまたがってクラスタを分割することはできません。同様に、構成されたリソースやサブシステムをドメイン間で共有することはできません。たとえば、あるドメインにJDBC接続プールを作成する場合、それを別のドメインのサーバー・インスタンスやクラスタで使用することはできませんかわりに、2番目のドメインに同様の接続プールを作成する必要があります。

クラスタ化されたWebLogic Serverインスタンスは、フェイルオーバーおよびロード・バランシングが可能になること以外は、クラスタ化されていないインスタンスと同様に動作します。クラスタ化されたWebLogic Serverインスタンスを構成するために使用するプロセスおよびツールは、クラスタ化されていないインスタンスを構成するものと同じです。ただし、クラスタ化によって可能になるロード・バランシングおよびフェイルオーバーの利点を実現するには、クラスタ構成の特定のガイドラインに従う必要があります。

3.3 クラスタリングの利点

WebLogic Serverクラスタを利用することによってもたらされる利点には、次のものがあります。

- スケーラビリティ
WebLogic Serverクラスタにデプロイされるアプリケーションの能力を、必要に応じて動的に増強することができます。サービスを中断させることなく、すなわち、クライアントおよびエンド・ユーザーへ影響を与えることなくアプリケーションの動作を維持しながら、クラスタにサーバー・インスタンスを追加できます。

- 高可用性
WebLogic Serverクラスタでは、サーバー・インスタンスで障害が発生してもアプリケーションの処理を継続できます。アプリケーション・コンポーネントのクラスタ化は、クラスタ内の複数のサーバー・インスタンス上にコンポーネントをデプロイすることによって行います(このため、コンポーネントが動作しているサーバー・インスタンスに障害が発生した場合、このコンポーネントがデプロイされている別のサーバー・インスタンスがアプリケーションの処理を継続できます)。

WebLogic Serverインスタンスのクラスタ化は、アプリケーション開発者およびクライアントからは意識されません。ただし、クラスタ化を可能にする技術インフラストラクチャを理解しておくことは、プログラマおよび管理者が、各自が扱うアプリケーションのスケーラビリティと可用性を最大限に高める上で役立ちます。

3.4 クラスタの主要機能

この項では、スケーラビリティおよび高可用性を実現するための主要なクラスタリング機能を定義します。この項の項目は次のとおりです。

- 3.4.1項「アプリケーションのフェイルオーバー」

- 第3.4.2項「サーバーの移行」

- 第3.4.3項「ロード・バランシング」

3.4.1 アプリケーションのフェイルオーバー

フェイルオーバーとは、特定のジョブ(処理するタスクのなんらかのセット)を実行するアプリケーション・コンポーネント(以降、オブジェクトと一般的に呼びます)がなんらかの理由で使用できなくなった場合に、障害の発生したオブジェクトのコピーがジョブを終了することです。

障害の発生したオブジェクトを新しいオブジェクトが引き継げるようにするには、次の条件が必要です。

- ジョブを引き継ぐために、障害の発生したオブジェクトのコピーが使用可能である必要があります。

- すべてのオブジェクトの場所および操作ステータスを定義する情報が、他のオブジェクトおよびフェイルオーバーを管理するプログラムで使用できる必要があり、これによって、そのジョブが終了する前に、最初のオブジェクトに障害が発生したことが確認できます。

- 処理中のジョブの進捗に関する情報が、他のオブジェクトおよびフェイルオーバーを管理するプログラムで使用できる必要があり、これによって、中断されたジョブを引き継ぐオブジェクトは、最初のオブジェクトが失敗する前に完了したジョブ数を認識できます。例として、変更されたデータや、プロセスにおける完了したステップが挙げられます。

WebLogic Serverは標準ベースの通信手法および機能(IPソケットやJava Naming and Directory Interface(JNDI)など)を使用して、クラスタ内のオブジェクトの可用性に関する情報を共有および保持します。これらの手法により、ジョブを終了する前にオブジェクトが停止したこと、および中断したジョブを完了するためのオブジェクトのコピーがある場所を、WebLogic Serverで判別できます。

ジョブに対して何が実行されたかに関する情報は、状態と呼ばれています。WebLogic Serverでは、セッション・レプリケーションおよびレプリカ対応スタブと呼ばれる手法を使用して、状態の情報を保持します。オブジェクトでジョブの実行が予期せず停止すると、レプリケーション手法によって、障害の発生したオブジェクトが停止した箇所をオブジェクトのコピーで特定し、ジョブを終了できます。

3.4.2 サーバーの移行

WebLogic Serverでは、あるシステムから別のシステムに、クラスタ化されたサーバー・インスタンスを自動または手動で移行できます。サーバー移行処理では、事前定義された使用可能なホスト・システムのいずれかに、管理対象サーバーが(IPアドレスやホストするアプリケーションを含めて)そっくりそのまま再配置されます。この機能は、高可用性が要求される環境向けに設計されています。サーバー移行は、次の点で有用です。

- シングルトン・サービス(ホストとして機能しているサーバー・インスタンスで障害が発生した場合に、常に1つのサーバー・インスタンス上でのみ実行される必要があるサービス)の、継続的な可用性の確保。障害が発生した場合、自動移行が構成されている管理対象サーバーは別のシステムに自動的に移行されます。

- (計画的なシステム管理プロセスの一環として)管理対象サーバーとそれがホストするすべてのサービスの再配置プロセスの簡略化。管理コンソールまたはコマンドラインから管理対象サーバーの移行を開始します。

3.4.3 ロード・バランシング

ロード・バランシングとは、環境内のコンピューティングおよびネットワーキング・リソース全体において、ジョブとそれに関係する通信を均等に分散することです。ロード・バランシングの要件は次となります。

- 特定のジョブを実行できるオブジェクトの複数のコピー。

- すべてのオブジェクトの場所および操作ステータスに関する情報。
WebLogic Serverを使用すると、代替オブジェクトで同じジョブを実行できるように、オブジェクトをクラスタ化できます(複数のサーバー・インスタンスにデプロイできます)。WebLogic Serverでは、ユニキャスト、IPソケットおよびJNDIを使用して、デプロイされたオブジェクトの可用性および場所が共有および保持されます。

3.5 クラスタ化可能なオブジェクトのタイプ

クラスタ化されたアプリケーションまたはアプリケーション・コンポーネントは、クラスタ内の複数のWebLogic Serverインスタンスで使用できます。オブジェクトがクラスタ化されていると、そのオブジェクトのフェイルオーバーおよびロード・バランシングが可能になります。クラスタ内のすべてのサーバー・インスタンスにオブジェクトを均一にデプロイして、クラスタの管理、保守およびトラブルシューティングを簡略化します。

Webアプリケーションは、 Enterprise Java Bean(EJB)、サーブレット、 Java Server Page(JSP)など、様々なタイプのオブジェクトで構成できます。それぞれのオブジェクト・タイプには、制御、起動、およびアプリケーション内での動作方法に関連して、一意の動作セットがあります。そのため、WebLogic Serverがクラスタリングをサポートして、ロード・バランシングおよびフェイルオーバーを実現するために使用する方法は、オブジェクトのタイプによって異なります。WebLogic Serverデプロイ時に、このようなオブジェクト・タイプをクラスタ化できます。

- サーブレット

- JSP

- EJB

- リモート・メソッド呼出し(RMI)オブジェクト

- Java Messaging Service(JMS)宛先

異なるオブジェクト・タイプにおいて、一部の動作は共通になることがあります。この場合、類似のオブジェクト・タイプに関するクラスタリングのサポートおよび実装の考慮事項は、同じとなる可能性があります。次の各項では、このようなオブジェクトの説明および手順を組み合わせています。

- サーブレットとJSP

- EJBとRMIオブジェクト

3.6 クラスタ内の通信

クラスタ内のWebLogic Serverインスタンスは、次の2つの基本的なネットワーク・テクノロジを使用して、相互に通信します。

- IPソケット。これは、クラスタ化されたサーバー・インスタンス間のピアツーピア通信のパイプです。

- IPのユニキャストまたはマルチキャスト。これらは、サービスの可用性、および継続的な可用性を示すハートビートをブロードキャストするために、サーバー・インスタンスによって使用されます。クラスタを新規作成する場合は、クラスタ内のメッセージングにユニキャストを使用することをお薦めします。以前のバージョンのWebLogic Serverとの下位互換性を保つには、クラスタ間の通信にマルチキャストを使用する必要があります。

注意:

WebLogic Serverクラスタでユニキャスト・プロトコルを使用する場合、クラスタの一部であるサーバーでは、リスニング・アドレスを指定する必要があります。サーバーは、ANYでリスニングすることはできません(これは、管理コンソールの「リスニング・アドレス」フィールドが空白のままになっている場合と同じです)。

3.7 クラスタワイドのJNDIネーミング・サービス

クラスタ化されていないWebLogic Serverサーバー・インスタンスのクライアントは、JNDIに準拠したネーミング・サービスを使用してオブジェクトおよびサービスにアクセスします。JNDIネーミング・サービスには、サーバー・インスタンスが提供する公開サービスのリストがツリー構造の形で含まれています。WebLogic Serverインスタンスで新しいサービスを提供するには、そのサービスを表す名前をJNDIツリーにバインドします。クライアントがそのサービスを取得するには、そのサーバー・インスタンスに接続し、バインドされたサービスの名前を検索します。

クラスタ内のサーバー・インスタンスは、クラスタワイドのJNDIツリーを利用します。クラスタワイドのJNDIツリーは、使用可能なサービスのリストをツリーが格納しているという点では、1つのサーバー・インスタンスのJNDIツリーに似ています。ただし、クラスタワイドのJNDIツリーには、ローカル・サービスの名前以外に、クラスタ内の他のサーバー上にあるクラスタ化されたオブジェクト(EJBやRMIクラス)が提供するサービスも格納されています。

クラスタ内のWebLogic Serverインスタンスはそれぞれ、クラスタワイドの論理JNDIツリーのローカル・コピーを作成して保持します。クラスタワイドのJNDIツリーを作成するには、まずローカルJNDIツリーに各サーバー・インスタンスをバインドします。サーバー・インスタンスが起動すると(または新しいサービスが、稼働中のサーバー・インスタンスに動的にデプロイされると)、まずそれらのサービスの実装がローカルJNDIツリーにバインドされます。同じ名前の他のサービスが他に存在しなければ、その実装がJNDIツリーにバインドされます。

サーバー・インスタンスでローカルJNDIツリーへのサービスのバインドに成功すると、レプリカ対応スタブを使用するクラスタ化されたオブジェクトに対して追加の手順が実行されます。クラスタ化されたオブジェクトの実装をローカルJNDIツリーにバインドした後、サーバー・インスタンスはオブジェクトのスタブをクラスタの他のメンバーに送信します。クラスタの他のメンバーは、マルチキャスト・アドレスまたはユニキャスト・アドレスを監視し、リモート・サーバー・インスタンスが新しいサービスを提供したときに検出します。

3.8 クラスタ内のフェイルオーバーとレプリケーション

クラスタで高可用性を実現するには、サービスの障害からリカバリ可能である必要があります。クラスタ内のWebLogic Serverインスタンスは、ピア・サーバー・インスタンスの障害を検出するために次を監視します。

- ピア・サーバーへのソケット接続
WebLogic Serverインスタンスは、障害を直ちに検出するために、ピア・サーバー・インスタンス間でIPソケットが使用されているかを監視します。サーバーがクラスタ内のピアのいずれかに接続し、ソケットを使用してデータ転送を始めた場合、そのソケットが突然クローズされると、ピア・サーバーが「エラー」としてマークされ、その関連サービスがJNDIネーミング・ツリーから削除されます。

- 定期的な サーバーのハートビート・メッセージ
クラスタ化されたサーバー・インスタンスで、ピアツーピア通信用にソケットが開いていない場合には、障害が発生したサーバーは、WebLogic Serverのハートビートを使用して検出することもできます。クラスタ内のサーバー・インスタンスはすべて、マルチキャストまたはユニキャストを使用して、定期的なサーバーのハートビート・メッセージをクラスタの他のメンバーにブロードキャストします。

それぞれのハートビート・メッセージには、メッセージの送信元サーバーを一意に識別するデータが含まれています。サーバーは、自身のハートビート・メッセージを10秒間隔でブロードキャストします。クラスタ内の各サーバーはそれを受けて、マルチキャスト・アドレスまたはユニキャスト・アドレスを監視して、すべてのピア・サーバーのハートビート・メッセージが送信されていることを確認します。

マルチキャスト・アドレスまたはユニキャスト・アドレスを監視中のサーバーにピア・サーバーからのハートビートが3回届かなかった場合(つまり、監視中のサーバーが送信元サーバーから30秒以上ハートビートを受信していない場合)には、監視側のサーバーはピア・サーバーを「エラー」としてマークします。次に、必要に応じてローカルJNDIツリーを更新して、障害が発生したサーバーでホストされていたサービスを取り消します。

3.8.1 セッション・レプリケーション

ユーザーのセッション・データは、ステートフル・セッションEJBまたはHTTPセッションという標準的な2つの方法で、Java EEアプリケーションに格納できます。それらの方法自体がクラスタのスケーラビリティに影響することはほとんどありません。ただし、高可用性を実現するために必要な セッション・レプリケーション・メカニズムとともに使用すると、ボトルネックが発生します。Java EEアプリケーションにWebコンポーネントおよびEJBコンポーネントがある場合には、ユーザーのセッション・データはHTTPセッションで格納する必要があります。

- HTTPセッション管理には、レプリケーション、共有データベース、ファイルなど、フェイルオーバーを処理するオプションがさらに用意されています。

- スケーラビリティが優れています。

- HTTPセッション状態のレプリケーションは、トランザクションの外側で実行されます。ステートフル・セッションBeanのレプリケーションは、より多くのリソースが集中するトランザクションで実行されます。

- HTTPセッション・レプリケーション・メカニズムは、ステートフル・セッションBeanレプリケーションと比較すると、より洗練されていて、より多様な状況で最適化されます。

3.9 サーバー全体の移行

WebLogic Serverクラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバー・インスタンスに均一にデプロイされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMSやJTAトランザクション・リカバリ・システムなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにターゲット指定されます - WebLogic Serverは、これらのサービスに対して、フェイルオーバーではなく、移行による障害回復をサポートしています。

WebLogic Serverにおける移行とは、クラスタ化されたWebLogic Serverインスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスです。サーバー全体の移行の場合は、障害が発生すると、サーバー・インスタンスが物理的に別のシステムに移行されます。サービスレベルの移行の場合は、サービスをクラスタ内の別のサーバー・インスタンスに移動します。WebLogic Serverには、JMSやJTAトランザクション・システムの可用性を高めるための機能(移行可能なサーバー)が用意されています。移行可能なサーバーは、サービスレベルではなく、サーバーレベルで自動または手動で移行できます。

移行可能なサーバーがなんらかの理由(ハング、ネットワークからの切断、ホスト・システムの障害など)で使用できなくなると、自動的に移行が行われます。障害が発生した場合、移行可能なサーバーは、可能であれば同じシステム上で自動的に再起動されます。障害が発生した同じシステム上で再起動できないときは、別のシステムに移行されます。また、管理者は手動でサーバー・インスタンスの移行を開始することもできます。

3.9.1 サーバー全体の移行におけるノード・マネージャの役割

サーバー移行にはノード・マネージャが必要です。ノード・マネージャは、それをホストするか、またはホストすることを目的とした各システムで実行する必要があります。

ノード・マネージャでは、サーバーの移行が次のようにサポートされます。

- 移行可能なサーバーの最初の起動には、ノード・マネージャを使用する必要があります。
管理コンソールから管理対象サーバーの起動を開始すると、管理サーバーでは、サーバー・インスタンスの起動にノード・マネージャが使用されます。スタンドアロンのノード・マネージャ・クライアントを使用し、ノード・マネージャを起動してサーバー・インスタンスを開始することもできます。ただし、管理対象サーバーが管理サーバーの構成を取得できるように、管理サーバーが使用可能になっている必要があります。

注意:

最初にノード・マネージャで開始されていないサーバー・インスタンスは、移行できなくなります。

- 移行可能なサーバーの中断、停止、または停止の強制には、ノード・マネージャを使用する必要があります。

- ノード・マネージャは、リース期間が切れた移行可能なサーバーを、障害の発生時にそのサーバーが稼働していたシステムで再起動しようとします。
ノード・マネージャは、カスタマイズ可能なシェル・スクリプトを実行して、サーバー移行処理のステップを実行します。このスクリプトはWebLogic Serverに同梱されていて、サーバーの起動、再起動および停止を行い、IPアドレスを移行し、ディスクのマウントおよびアンマウントを行うものです。このスクリプトは、Solaris版とLinux版が用意されています。

- 自動移行では、移行を実行するために、クラスタ・マスターによってノード・マネージャが起動されます。

- 手動移行では、移行を実行するために、管理サーバーによってノード・マネージャが起動されます。

3.9.2 サーバー移行処理と通信

次の項では、移行可能なサーバーを含むクラスタでの主要な処理について説明します。

- 第3.9.2.1項「移行可能なサーバーを含むクラスタでの起動プロセス」

- 第3.9.2.2項「サーバー全体の自動移行処理」

- 第3.9.2.3項「サーバー全体の手動移行処理」

- 第3.9.2.4項「サーバー全体の移行における管理サーバーの役割」

- 第3.9.2.5項「クラスタ内の移行可能なサーバーの動作」

- 第3.9.2.6項「サーバー全体の移行におけるクラスタ・マスターの役割」

3.9.2.1 移行可能なサーバーを含むクラスタでの起動プロセス

図3-1に、移行可能なサーバーを含むクラスタの起動時に発生する処理および通信を示します。

例のクラスタには、2つの管理対象サーバーが含まれていて、どちらのサーバーも移行可能です。管理サーバーと2つの管理対象サーバーは、それぞれ異なるマシンで稼働しています。4番目のマシンは、移行可能なサーバーのいずれかに障害が発生した場合にバックアップとして使用できます。ノード・マネージャは、バックアップ・マシンおよび移行可能なサーバーが稼働している各マシンで稼働しています。

図3-1 移行可能なサーバーを含むクラスタの起動

「図3-1 移行可能なサーバーを含むクラスタの起動」の説明

図3-1に示されているクラスタの起動時に発生する主要な手順は、次のとおりです。

1. 管理者がクラスタを起動します。

2. 管理サーバーがマシンBおよびCでノード・マネージャを起動し、それぞれ管理対象サーバー1および2を起動します。第3.9.2.4項「サーバー全体の移行における管理サーバーの役割」を参照してください。

3. 各マシンのノード・マネージャは、そこで稼働する管理対象サーバーを起動します。第3.9.1項「サーバー全体の移行におけるノード・マネージャの役割」を参照してください。

4. 管理対象サーバー1および2は、その構成を管理サーバーに問い合せます。第3.9.2.5項「クラスタ内の移行可能なサーバーの動作」を参照してください。

5. 管理対象サーバー1および2は、起動した構成をキャッシュします。

6. 管理対象サーバー1および2はそれぞれ、移行可能なサーバーのリースをリース表から取得します。管理対象サーバー1は、最初に起動するためクラスタ・マスターのリースも取得します。第3.9.2.6項「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください。

7. 管理対象サーバー1および2は、リース表のリースを定期的に更新して、ヘルスおよび稼働状況を証明します。

3.9.2.2 サーバー全体の自動移行処理

図3-2に、管理対象サーバー2をホストするマシンに障害が発生した後の自動移行処理を示します。

図3-2 障害が発生したサーバーの自動移行

「図3-2 障害が発生したサーバーの自動移行」の説明

1. 管理対象サーバー2をホストするマシンCに障害が発生します。

2. リース表の次回の定期確認時に、クラスタ・マスターは管理対象サーバー2のリース期限が切れていることを検出します。第3.9.2.6項「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください。

3. クラスタ・マスターが、マシンCのノード・マネージャにアクセスして管理対象サーバー2の再起動を試行しますが、マシンCにアクセスできないため失敗します。

注意:

管理対象サーバー2のリース期限切れの原因が管理対象サーバー2のハングだけで、マシンCにはアクセス可能な場合は、クラスタ・マスターはノード・マネージャを使用して、マシンCの管理対象サーバー2を再起動します。

4. クラスタ・マスターが、マシンDのノード・マネージャにアクセスします。マシンDは、クラスタ内の移行可能なサーバーに使用可能なホストとして構成されています。

5. マシンDのノード・マネージャによって、管理対象サーバー2が起動されます。第3.9.1項「サーバー全体の移行におけるノード・マネージャの役割」を参照してください。

6. 管理対象サーバー2が起動し、管理サーバーにアクセスして、その構成を取得します。

7. 管理対象サーバー2が、起動時に使用した構成をキャッシュします。

8. 管理対象サーバー2が、移行可能なサーバーのリースを取得します。

移行する管理対象サーバーのクライアントでは、移行時にサービスが短時間中断することがあり、その場合は再接続する必要があります。オペレーティング・システムがSolarisおよびLinuxの場合は、ifconfigコマンドを使用して再接続できます。移行されるサーバーのクライアントは、移行先のマシンを認識する必要はありません。

移行されたサーバー・インスタンスを以前ホストしていたマシンが再度使用可能になると、移行処理が戻されます(サーバー・インスタンスを元のホスト・マシンに移行します)。これをフェイルバックと呼びます。WebLogic Serverでは、フェイルバックの処理は自動化されません。そのサーバー・インスタンスを元のホストに手動で戻すことにより、フェイルバックを実現できます。

サーバーを元のホストに戻すための一般的な手順は、次のとおりです。

- サーバーの新しいインスタンスを正常に停止します。

- 障害の発生したマシンを再起動したら、ノード・マネージャと管理対象サーバーを再起動します。

実際に行う詳細な手順は、サーバーとネットワーク環境によって異なります。

3.9.2.3 サーバー全体の手動移行処理

図3-3に、移行可能なサーバーを管理者が手動で移行する際の処理を示します。

図3-3 サーバー全体の手動移行

「図3-3 サーバー全体の手動移行」の説明

1. 管理者は管理コンソールを使用して、マシンCからマシンBへの管理対象サーバー2の移行を開始します。

2. 管理サーバーが、マシンCのノード・マネージャにアクセスします。第3.9.2.4項「サーバー全体の移行における管理サーバーの役割」を参照してください。

3. マシンCのノード・マネージャによって、管理対象サーバー2が停止されます。

4. 管理対象サーバー2によって、リース表から対象の行が削除されます。

5. 管理サーバーによって、マシンBのノード・マネージャが起動されます。

6. マシンBのノード・マネージャによって、管理対象サーバー2が起動されます。

7. 管理対象サーバー2が、管理サーバーからその構成を取得します。

8. 管理対象サーバー2が、起動時に使用した構成をキャッシュします。

9. 管理対象サーバー2によって、リース表に行が追加されます。

3.9.2.4 サーバー全体の移行における管理サーバーの役割

移行可能なサーバーを含むクラスタにおいて、管理サーバーは各システムの、次のノード・マネージャを起動します。

- 移行可能なサーバーを起動するクラスタ・メンバーをホストしているノード・マネージャ。これは、サーバーを移行する際の前提条件です。最初にノード・マネージャでサーバー・インスタンスを起動しないと、サーバーを移行できません。

- 移行可能なサーバーをいったん停止して起動する手動移行処理に関わるノード・マネージャ。

- 正常停止時にサーバー・インスタンスを停止するクラスタ・メンバーをホストしているノード・マネージャ。これは、サーバーを移行する際の前提条件です - ノード・マネージャを使用しないでサーバー・インスタンスを直接停止した場合、サーバー・インスタンスが稼働していないことがクラスタ・マスターで検出されると、ノード・マネージャが呼び出されて、そのサーバー・インスタンスが再起動してしまいます。

また、管理サーバーには通常のドメイン管理機能が用意されています。これは、管理者が発行した構成の更新を永続的に保持し、ドメインに含まれる移行可能なサーバーを含め、ドメインの実行時ビューを表示できます。

3.9.2.5 クラスタ内の移行可能なサーバーの動作

移行可能なサーバーは、移行可能として構成された、クラスタ化された管理対象サーバーです。移行可能なサーバーの主要な動作は、次のとおりです。

- リース情報の管理にデータベースを使用している場合、ノード・マネージャによる起動および再起動時に、移行可能なサーバーによってリース表に行が追加されます。移行可能なサーバーの行には、タイムスタンプおよびそのサーバーが稼働しているマシンが含まれています。

- リース情報の管理にデータベースを使用すると、移行可能なサーバーは起動の結果としてデータベースに行を追加し、クラスタ・マスターの役割を担当しようとします。このサーバーがクラスタに参加する最初のサーバー・インスタンスであれば成功します。

- サーバーは定期的に、リース表のタイムスタンプを更新することで、その「リース」を更新します。
デフォルトでは、移行可能なサーバーは30,000ミリ秒ごとにそのリースを更新します。この値は次の2つのServerMBeanプロパティの積です。

- HealthCheckIntervalMillis: デフォルトでは10,000です。

- HealthCheckPeriodsUntilFencing: デフォルトでは3です。

- 移行可能なサーバーがリース表にアクセスできず、リースの期限が切れる前にそのリースを更新できないと、Java System.exitを使用して迅速に終了します。その場合、リース表にはそのサーバー・インスタンスの行が残ります。これが自動移行にどのように関連しているかの詳細は、第3.9.2.6項「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください。

- 運用時には、移行可能なサーバーが、クラスタ・マスターからのハートビートをリスニングします。クラスタ・マスターがハートビートを送信していないことを検出すると、クラスタ・マスターの役割を引き継ごうとします。その役割を主張するサーバー・インスタンスが他になければ成功します。

3.9.2.6 サーバー全体の移行におけるクラスタ・マスターの役割

移行可能なサーバーを含むクラスタにおいて、1つのサーバー・インスタンスがクラスタ・マスターとして動作します。その役割は、サーバー移行処理を調整することです。クラスタ内の任意のサーバー・インスタンスが、クラスタ・マスターの機能を果たすことができます。移行可能なサーバーを含むクラスタを起動すると、クラスタに最初に参加したサーバーがクラスタ・マスターになり、クラスタ・マネージャのサービスを開始します。移行可能なサーバーがクラスタに1つも含まれていない場合、クラスタ・マスターは不要であり、クラスタ・マスターのサービスは開始されません。クラスタ・マスターがなくても、移行可能なサーバーは引き続き稼働できますが、サーバーの移行はできません。主なクラスタ・マスターの機能は次となります。

- クラスタ内の他のサーバーにハートビートを定期的に発行します。

- リース表を定期的に読み取り、それぞれの移行可能なサーバーに最新のリースがあることを確認します。期限切れのリースがあると、移行可能なサーバーを再起動する必要があることがクラスタ・マスターに示されます。

- 移行可能なサーバーのリースの期限が切れていると判断された時点で、ClusterMBeanのFencingGracePeriodMillisで指定された期間にわたって待機した後、リースの期限が切れた移行可能なサーバーをホストするマシンのノード・マネージャのプロセスを起動して、移行可能なサーバーの再起動を試行します。

- 現在のマシンでリース期間が切れた移行可能なサーバーを再起動できない場合、クラスタ・マスターは次のようにターゲット・マシンを選択します。

- 移行可能なサーバーの優先的な移行先マシンのリストを構成する場合、クラスタ・マスターは、そのリストに表示されている順にマシンを選択します。そのリストを構成していない場合、クラスタ・マスターは、クラスタ内の移行可能なサーバーのホストに使用できるように構成されているマシンのリストからマシンを選択します。
移行可能なサーバーをホストできるマシンのリストは、「クラスタ全体」と「個々の移行可能なサーバー」という2つのレベルで構成できます。マシンのリストは、両方のレベルで定義できます。マシンのリストは、少なくとも1つのレベルで定義する必要があります。

- 新しいマシンへのサーバー・インスタンスを移行するには、クラスタ・マスターでターゲット・マシンのノード・マネージャ・プロセスを起動して、サーバー・インスタンスのプロセスを作成します。
移行の実行に必要な時間は、サーバーの構成および起動時間によって異なります。

- 移行可能なサーバーをクラスタ・マスターによって再起動するときの最大所要時間は、(HealthCheckPeriodsUntilFencing * HealthCheckIntervalMillis)+FencingGracePeriodMillisです。

- クライアントのリクエストに対してサーバーを使用できるようになるまでの合計時間は、サーバーの起動時間とアプリケーションのデプロイ所要時間によって異なります。

3.10 JMSおよびJTAの高可用性

移行可能ターゲット(クラスタ内のサーバーから別のサーバーに移行できる特別なターゲット)を使用すると、JMSサービスやJTAサービスを構成して可用性を高めることができます。移行可能ターゲットを使用することにより、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能ターゲットを移行すると、その対象によってホストされているすべてのサービスも移行されます。

移行可能なJMSサービスを移行できるように構成するには、そのサービスを移行可能ターゲットにデプロイする必要があります。移行可能ターゲットでは、ターゲットをホストできるサーバーのセットを指定します。必要に応じて、そのサービスを優先的にホストするサーバーを指定したり、その優先サーバーで障害が発生した場合のバックアップ・サーバー候補を順序付けしたリストを指定したりできます。ただし、移行可能ターゲットを同時に複数のサーバーでホストすることはできません。

移行可能ターゲットを使用するようにサービスを構成すると、そのサービスは、現時点でそれをホストしているサーバー・メンバーから独立した存在になります。たとえば、JMSキューがデプロイされているJMSサーバーを、移行可能ターゲットを使用するように構成した場合、そのキューは、特定のサーバー・メンバーが使用可能かどうかに依存せずに動作します。つまり、このキューは、移行可能ターゲットがクラスタ内のいずれかのサーバーでホストされているかぎり、常に使用できます。

管理者は、サーバーの障害への対応として、または定期的に計画されるメンテナンスの一環として、固定された移行可能サービスをクラスタ内のサーバー・インスタンスから別のサーバー・インスタンスに手動で移行できます。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内のどのWebLogic Serverインスタンスにも移行できます。

3.10.1 ユーザー優先サーバーと候補サーバー

JMSサービスを移行可能ターゲットにデプロイする際は、サービスをホストするユーザー優先サーバー(UPS: User-Preferred Server)のターゲットを選択できます。また、移行可能ターゲットを構成する場合は、ユーザー優先サーバーで障害が発生したときにサービスをホストできる控えの候補サーバー(CCS: Constrained Candidate Server)を指定することもできます。移行可能ターゲットに控えの候補サーバーが指定されていない場合、JMSサーバーをクラスタ内で使用可能な任意のサーバーに移行できます。

WebLogic Serverでは、JMSサービスごとに別々の移行可能ターゲットを作成できます。これにより、必要に応じて、クラスタ内の別々のサーバーで常に各サービスを実行し続けることが可能になります。また逆に、JTAとJMS両方の控えの候補サーバーとして同じサーバー群を選択し、両方のサービスが確実にクラスタ内の同じサーバーに配置されるように構成することもできます。

3.10.2 NFSでのファイル・ストアの使用に関する考慮事項

JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している場合、予期しないマシン障害の後にサーバーの再起動の動作を確認することを強くお薦めします。NFSの実装に応じて、フェイルオーバーおよび再起動後に異なる問題が発生する可能性があります。

サーバーの再起動の動作を確認するには、WebLogic Serverの実行時に、それらのサーバーをホストするノードを異常停止させます。

- サーバーをサーバー移行用に構成した場合、フェイルオーバー期間の経過後に、サーバーはフェイルオーバー・ノードで自動的に起動します。

- サーバーをサーバー移行用に構成しなかった場合、ノードが完全に再起動した後、同じホスト上でWebLogic Serverを手動で再起動できます。

予期しないマシン障害後にOracle WebLogic Serverが再起動しない場合、サーバー・ログ・ファイルに次のエラー・エントリが表示されます。

<MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent
store "_WLS_server_soa1" could not be deployed:
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_SOA1000000.DAT"
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_SOA1000000.DAT"
at weblogic.store.io.file.Heap.open(Heap.java:168)
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:88)
...
java.io.IOException: Error from fcntl() for file locking, Resource
temporarily unavailable, errno=11

このエラーは、NFSv3システムでファイル・ストア上のロックが解放されていない場合に発生します。WebLogic Serverは、同じ管理対象サーバーの2つのインスタンスを間違って起動した場合にデータ破損が発生しないように、JMSデータおよびトランザクション・ログを格納しているファイルに対するロックを保持します。NFSv3ストレージ・デバイスはロック所有者を追跡しないため、ロック所有者が失敗した場合、NFSはロックを無期限に保持します。このため、予期しないマシン障害とそれに続く再起動の後に、WebLogic Serverがロックを取得しようとしても、失敗する可能性があります。

このエラーの解決方法は、NFS環境によって異なります(このトピックの更新については、『Oracle Fusion Middlewareリリース・ノート』を参照してください)。

- NFSv4環境の場合、サーバー移行を完了する所要時間内にロックを解放するよう、NASサーバーでチューニング・パラメータを設定できます(この項の手順に従う必要はありません)。ストレージ・デバイスでNFSにマウントされたディレクトリに格納されているファイルのロックに関する情報は、使用しているストレージのベンダーのドキュメントを参照し、結果をテストしてください。

- NFSv3環境の場合、次の項で、デフォルト・ファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストア、診断ファイル・ストアに対するWebLogicのファイル・ロック・メカニズムを無効化する方法について説明します。

警告:

NFSv3のファイル・ロックにより、複数の管理対象サーバーが任意の時点で同じファイル・ストアに書込みを行う場合に、深刻なファイルの破損が発生しないようにします。

NFSv3のファイル・ロックを無効化する場合は、特定のファイル・ストアに書込みを行う管理対象サーバーが1つのみとなるよう、管理手順や管理ポリシーを実装する必要があります。破損は、同じクラスタまたは別のクラスタ、同じノードまたは別のノード、あるいは同じドメインまたは別のドメインに管理対象サーバーが2つ存在することにより発生する可能性があります。

ポリシーの例としては、ドメインをコピーしない、WLS構成オブジェクト(サーバーやストア)の一意のネーミング・スキームを強制しない、各ドメインに独自の記憶域ディレクトリを必ず含める、2つのドメインに同じディレクトリを参照する同じ名前のストアを含めることはできない、などがあげられます。

ファイル・ストアを使用する管理対象サーバーをサーバー移行用に構成している場合は、必ずデータベース・ベースのリース・オプションを構成してください。このオプションにより、データベース表を使用した追加のロック・メカニズムが強制的に適用され、特定の管理対象サーバーの複数のインスタンスが自動的に再起動しなくなります。

デフォルト・ファイル・ストアのファイル・ロックの無効化

管理コンソールを使用してデフォルト・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

1. 必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

2. 「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。

3. 「サーバーのサマリー」リストで、変更するサーバーを選択します。

4. 「構成」→「サービス」タブを選択します。

5. 「デフォルト・ストア」セクションを下にスクロールし、「詳細」をクリックします。

6. 下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。

7. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

8. 変更したサーバーを再起動して変更を反映します。

生成されるconfig.xmlのエントリは、次のようになります。

<server>
<name>examplesServer</name>
...
<default-file-store>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
</default-file-store>
</server>

カスタム・ファイル・ストアのファイル・ロックの無効化

管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

1. 必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

2. 「ドメイン構造」ツリーで、「サービス」ノードを開いて「永続ストア」を選択します。

3. 「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。

4. カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックします。

5. 下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。

6. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

7. カスタム・ファイル・ストアが使用中の場合、変更を反映するにはサーバーを再起動する必要があります。

生成されるconfig.xmlのエントリは、次のようになります。

<file-store>
<name>CustomFileStore-0</name>
<directory>C:\custom-file-store</directory>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
<target>examplesServer</target>
</file-store>

JMSページング・ファイル・ストアのファイル・ロックの無効化

管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

1. 必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

2. 「ドメイン構造」ツリーで、「サービス」ノードを開き、次に「メッセージング」ノードを開いて「JMSサーバー」を選択します。

3. 「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。

4. JMSサーバーの「構成」→「全般」タブで、下にスクロールして「ページング・ファイル・ロックの有効化」チェック・ボックスを選択解除します。

5. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

6. 変更したサーバーを再起動して変更を反映します。

生成されるconfig.xmlファイルのエントリは、次のようになります。

<jms-server>
<name>examplesJMSServer</name>
<target>examplesServer</target>
<persistent-store>exampleJDBCStore</persistent-store>
...
<paging-file-locking-enabled>false</paging-file-locking-enabled>
...
</jms-server>

診断ファイル・ストアのファイル・ロックの無効化

管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。

1. 必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。

2. 「ドメイン構造」ツリーで、「診断」ノードを開いて「アーカイブ」を選択します。

3. 「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。

4. 「<サーバー名>の設定」ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。

5. 「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

6. 変更したサーバーを再起動して変更を反映します。

生成されるconfig.xmlファイルは、次のようになります。

<server>
<name>examplesServer</name>
...
<server-diagnostic-config>
<diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
<diagnostic-store-file-locking-enabled>false</diagnostic-store-file-locking-
enabled>
<diagnostic-data-archive-type>FileStoreArchive</diagnostic-data-archive-type>
<data-retirement-enabled>true</data-retirement-enabled>
<preferred-store-size-limit>100</preferred-store-size-limit>
<store-size-check-period>1</store-size-check-period>
</server-diagnostic-config>
</server>

3.11 管理サーバーおよびノード・マネージャの高可用性

管理サーバーは、そのドメイン内のWebLogic Serverインスタンス群を構成および管理するWebLogic Serverインスタンスです。

ドメインには複数のWebLogic Serverクラスタと、クラスタ化されないWebLogic Serverインスタンスが存在できます。ドメインは1つのWebLogic Serverインスタンスのみで構成できますが、この場合、各ドメインには必ず1つの管理サーバーが存在する必要があるため、その唯一のサーバー・インスタンスが管理サーバーとなります。

管理サーバーのサービスを起動して構成タスクを実行するには、様々な方法があります。いずれの方法を使用するにしても、構成を変更する際はクラスタの管理サーバーが稼働している必要があります。

注意:

複数のMiddlewareホームまたはOracleホームを使用したシステムの場合は特に、管理サーバーのリスニング・アドレスに、そのクライアントがサーバーにアクセスするのに必要なホスト名を設定することをお薦めします。

3.11.1 管理サーバーの障害

ドメインの管理サーバーで障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。管理対象のサーバー・インスタンスが(クラスタ化されているかいないかには関係なく)稼働しているときにドメインの管理サーバーが使用できなくなっても、管理対象サーバーは稼働し続けます。ドメインにクラスタ化されたサーバー・インスタンスがある場合は、管理サーバーに障害が発生しても、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバー機能を使用できます。

注意:

ホスト・マシンのハードウェア障害またはソフトウェア障害によって管理サーバーに障害が発生した場合は、同じマシンの他のサーバー・インスタンスも同様に影響を受けることがあります。ただし、管理サーバー自体で障害が発生しても、ドメイン内の管理対象サーバーの動作には影響しません。

管理サーバーを再起動する手順については、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

3.11.2 ノード・マネージャの障害

ノード・マネージャに障害が発生した場合、または明示的に停止した場合は、再起動した時点で、前回終了時に管理していたサーバー・インスタンスが判別されます。ノード・マネージャでは、必要に応じて、障害の発生した任意のサーバー・インスタンスを再起動できます。

注意:

ノード・マネージャはオペレーティング・システムのサービスとして実行することをお薦めします。こうしておけば、ノード・マネージャのホスト・マシンが再起動した場合に、ノード・マネージャが自動的に再起動します。

3.12 ロード・バランシング

ロード・バランシング構成は、3つの情報(使用するロード・バランシング・アルゴリズム、ローカル・アフィニティを適用するかどうかを示すインジケータ、およびトポロジの各メンバーに割り当てられる重み(重みを利用する任意のルーティング・アルゴリズムに影響))で構成されます。

ロード・バランシング・アルゴリズムによって、コンポーネント間でリクエストをロード・バランシングする方法を指定します。Oracle Fusion Middlewareでは、次の3つのロード・バランシング方法を使用します。

- ラウンド・ロビン: 使用可能なサーバーのリストから順番に選択して、一連のサーバーにリクエストを分散します。

- ランダム: リクエストごとに、使用可能なサーバーのリストからサーバーをランダムに選択して、一連のサーバーにリクエストを分散します。

- 重み付け: 使用可能なサーバーのリストの中の各サーバーに割り当てられた重みを使用して、それぞれに送信されるリクエストの割合を決定することで、一連のサーバーにリクエストを分散します。

ローカル・アフィニティは、ネットワーク待機時間を回避するために、同じマシンで稼働するサーバーに対してクライアントが優先度を示すかどうかを決定します。このフラグがtrueに設定されていると、ローカル・サーバーのいずれかが使用可能な場合、ロード・バランシング・アルゴリズムを使用して、ローカル・マシン上の一連のサーバーにわたってリクエストがルーティングされます。使用可能なローカル・サーバーがない場合には、ロード・バランシング・アルゴリズムに従って、すべての使用可能なリモート・サーバーにリクエストがルーティングされます。ローカル・アフィニティがfalseに設定されていると、ロード・バランシング・アルゴリズムに基づいて、(ローカルおよびリモートの)すべての使用可能なサーバーにわたってリクエストがルーティングされます。

重みは、コンポーネント・インスタンスに関連付けられる単一の整数値として構成します。重みは、現在グループにないコンポーネントにも割り当てることができますが、そのコンポーネントがグループのメンバーとして後で構成され、重みが付けられたロード・バランシング・アルゴリズムが選択されないと、その重みは使用されません。重みは単位のない数値です。各メンバーに送信されるリクエストの割合は、使用可能なメンバーすべての重みを合計し、その重みの合計で各メンバーの重みを割って計算します。

3.13 GridLinkデータ・ソース

単一のGridLinkデータ・ソースにより、WebLogic ServerとOracle Database Real Application Clusters(RAC)間の接続が可能となります。これは、Oracle RACにおける状態変化に適応して対処するために、Oracle Notification Service(ONS)を使用します。これはFANイベントに応答して、高速接続フェイルオーバー(FCF)、ランタイム接続ロード・バランシング(RCLB)、およびRACインスタンスの正常な停止を提供します。また、アフィニティ機能もあります。

GridLinkデータ・ソースの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのGridLinkデータ・ソースの使用に関する説明を参照してください。

3.14 マルチ・データ・ソース

マルチ・データ・ソースとは、データ・ソースのグループの抽象概念です。これによって、ロード・バランシングまたはフェイルオーバーは、接続要求時に、マルチ・データ・ソースに関連付けられたデータ・ソースの間で処理されます。マルチ・データ・ソースは、単純なデータ・ソースがJNDIツリーにバインドされるように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされます。アプリケーションは、単純なデータ・ソースと同様に、JNDIツリーまたはローカル・アプリケーション・コンテキスト(java:comp/env)でマルチ・データ・ソースを検索してから、データベース接続を要求します。マルチ・データ・ソースによって、マルチ・データ・ソース構成で選択されたアルゴリズム(ロード・バランシングまたはフェイルオーバー)に応じて、リクエストに対応するために使用するデータ・ソースが決定します。

マルチ・データ・ソースは、データ・ソースのプールと考えることができます。マルチ・データ・ソースは、冗長なデータベースやOracle RACなど、可用性の高いデータベース・システムのノード間のフェイルオーバーまたはロード・バランシングに使用するのが最適です。

3.15 クラスタの構成とconfig.xml

config.xmlファイルは、WebLogic Serverドメインの構成を記述しているXMLドキュメントです。config.xmlのdomain要素はトップレベルの要素であり、ドメイン内のすべての要素はdomain要素の子です。domain要素には、server、cluster、applicationなどの子要素があります。子要素の中にさらに子要素がある場合もあります。たとえば、server要素には、子要素としてWebServer、SSLおよびLogを記述できます。Application要素には、子要素としてEJBComponentとWebAppComponentがあります。

各要素には、1つ以上の構成可能な属性があります。config.dtdに定義されている属性には、構成APIに対応する属性があります。たとえば、Server要素にはListenPort属性があり、同様にWeblogic.management.configuration.ServerMBeanにもListenPort属性があります。構成できる属性は読み書きが可能です。たとえば、ServerMBeanにはgetListenPort()メソッドとsetListenPort()メソッドがあります。

config.xmlの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

3.16 シングルトン・サービスについて

シングルトン・サービスとは、ホストとして機能しているサーバー・インスタンスで障害が発生した場合に、常に1つのサーバー・インスタンス上でのみ実行される必要があるサービス(JMSやJTAトランザクション・リカバリ・システムなど)です。障害が発生した場合、自動移行が構成されている管理対象サーバーは別のマシンに自動的に移行されます。

3.17 WebLogic ServerおよびLDAPの高可用性

高可用性環境では、次のような理由でWebLogic ServerはLDAPにアクセスできる必要があります。

- WebLogic ServerでフェイルオーバーをサポートするLDAPに格納されているユーザーおよびグループにアクセスするため。
LDAP認証プロバイダのフェイルオーバーの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のLDAP認証プロバイダのフェイルオーバーの構成に関する項を参照してください。

- LDAPベースのポリシー・ストアおよび資格証明ストアにアクセスするため。
LDAPベースのポリシー・ストアを使用するドメインの構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のLDAPベースのポリシー・ストアを使用するドメインの構成に関する項を参照してください。

LDAPベースの資格証明ストアを使用するドメインの構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のLDAPベースの資格証明ストアを使用するドメインの構成に関する項を参照してください。

4 可用性の高いOracle Databaseアクセスの考慮事項

この章では、可用性の高いOracle Databaseアクセスの考慮事項について説明します。

この章に含まれている項は次のとおりです。

- 第4.1項「Oracle Real Application ClustersとFusion Middleware」

- 第4.2項「ファイアウォールのタイムアウトからのアイドル接続の保護」

- 第4.3項「トラブルシューティング」

- 第4.4項「Oracle Database 11g (11.2)でのSCANアドレスの使用」

4.1 Oracle Real Application ClustersとFusion Middleware

Fusion Middlewareコンポーネントのほとんどでは、そのデータの永続ストアとしてデータベースが使用されます。Oracle Databaseバックエンドは、Cold Failover Clusters、Oracle Real Application Clusters、Oracle Data Guard、Oracle Streamsなど、任意の数の高可用性構成で構成できます。詳細は、Oracle Database高可用性概要を参照してください。この章では、可用性の高いOracle DatabaseであるOracle Real Application Clustersで構成されたOracle Fusion Middlewareの考慮事項について説明します。

Oracle Real Application Clusters(Oracle RAC)とは、複数の相互接続されたコンピュータの処理能力を利用したコンピューティング環境です。ハードウェアの集合(クラスタ)とともに、各コンポーネントの処理能力を結合して1つの堅牢なコンピューティング環境を構成します。Oracle RACは同時に、Oracle Fusion Middlewareに対して、スケーラビリティおよび可用性の高いデータベースを提供します。

クラスタ内のすべてのOracle RACインスタンスは、同じアクセス権および認可レベルを持つため、ノードおよびインスタンスに障害が発生しても、障害が発生していないサーバー・インスタンスでデータベース・サービスを利用したり、利用可能な状態にすることができ、これにより、パフォーマンスに影響を及ぼす場合はありますが、停止することはありません。

Oracle RACの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。

Oracle Fusion Middlewareにより、高可用性環境でOracle Databaseとの最適な統合が実現します。Oracle Fusion Middlewareはデータベースのクライアント(javaクライアントとシステム・クライアントのいずれか)として動作する場合、データベース障害シナリオに対して高速のフェイルオーバーを提供して中間層のダウンタイムを最小に抑える、特別な通信機能および監視機能を使用します。

データベースにアクセスするOracle Fusion Middlewareコンポーネントは、次のように分類できます。

- Oracle WebLogic ServerにデプロイされるJavaベースのコンポーネント

- スタンドアロンのJavaクライアントとなるJavaベースのコンポーネント

- Java以外のコンポーネント

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

- 第4.1.1項「Oracle WebLogic ServerにデプロイされるJavaベースのOracle Fusion Middlewareコンポーネント」

- 第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」

- 第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」

- 第4.1.4項「Oracle RACでのGridLinkデータ・ソースの構成」

- 第4.1.5項「Oracle RACでのマルチ・データ・ソースの構成」

- 第4.1.6項「JDBCクライアント」

- 第4.1.7項「システム・クライアント」

4.1.1 Oracle WebLogic ServerにデプロイされるJavaベースのOracle Fusion Middlewareコンポーネント

Oracle WebLogic ServerにデプロイされるOracle Fusion Middlewareコンポーネントはすべて、Oracle RACをサポートします。接続プールを確立する場合、Oracle Fusion Middlewareでは、XA JDBCドライバとXA以外のJDBCドライバ両方に対して、Oracle RACバックエンドのGridLinkデータ・ソースおよびマルチ・データ・ソースがサポートされます。Oracle Fusion Middlewareデプロイメントでは、Oracle RACのOracle JDBCドライバでサポートされるその他の接続フェイルオーバー機能はサポートされません。マルチ・データ・ソースの構成の詳細は、各コンポーネントのマニュアルを参照してください。

Oracle RACのノードまたはインスタンスに障害が発生すると、Oracle WebLogic ServerまたはOracle Thinドライバによって、セッション・リクエストがクラスタ内の別のノードにリダイレクトされます。既存の接続のフェイルオーバーはありませんが、アプリケーションからの新しい接続要求は、Oracle WebLogicプールの既存の接続を使用して管理されるか、稼働中のOracle RACインスタンスへの新しい接続によって管理されます。データベースがトランザクション・マネージャの場合、通常、進行中のトランザクションはロールバックされます。WebLogic Serverがトランザクション・マネージャの場合、進行中のトランザクションはフェイルオーバーされ、障害発生時のトランザクションの状態に基づいて、完了するかロールバックするかが判断されます。アプリケーションにOracle RACノード全体でのロード・バランシングが必要な場合、WebLogic Serverでは、ロード・バランシング用に構成されたJDBC GridLinkデータ・ソースまたはJDBCマルチ・データソースを使用することにより、この機能がサポートされます。GridLinkロード・バランシングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのランタイム接続ロード・バランシングに関する説明を参照してください。

4.1.2 GridLinkデータ・ソースおよびOracle RAC

GridLinkデータ・ソースには、汎用データ・ソースの機能に加え、Oracle RACに対する次のサポートが含まれています。

- 高速接続フェイルオーバー

- ランタイム接続ロード・バランシング

- Oracle RACの停止に対する適切な処理

- XAアフィニティ

- SCANアドレス

- Oracleウォレットを使用したセキュアな通信

次のトピックの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのGridLinkデータ・ソースの使用に関する説明を参照してください。

- GridLinkデータ・ソースとは

- GridLinkデータ・ソースのソケット・ダイレクト・プロトコルの使用

- 接続プール機能の構成

- Oracleパラメータの構成

- ONSクライアントの構成

- GridLinkデータ・ソース接続プールのチューニング

- データベースのセキュリティ資格証明の設定

- GridLink JDBCリソースの監視

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

Oracle RACバックエンドに対してOracle Fusion Middlewareをデプロイする場合、これは、マルチ・データ・ソースを使用してすぐに使用可能な状態に構成されています。マルチ・データ・ソースには、データベース・サービスを提供するRACインスタンスごとの構成データ・ソースが存在します。データベース・サービスを提供するRACインスタンスを追加で構成する場合、Fusion Middleware層でマルチ・データ・ソースにデータ・ソースを追加することをお薦めします。マルチ・データ・ソースに作成する各構成データ・ソースが、第4.1.5項「Oracle RACでのマルチ・データ・ソースの構成」のプロパティとまったく同じように構成されていることを確認します。

非RACのデータベースをRACデータベースに移行する場合、影響を受けるデータ・ソースごとに同等のマルチ・データ・ソースを新しく作成する必要があります。作成するマルチ・データ・ソースには、各RACインスタンスと整合性のあるデータ・ソースが必要です。第4.1.5項「Oracle RACでのマルチ・データ・ソースの構成」のプロパティでは、データ・ソース値は元の単一インスタンスのデータ・ソースと同一である必要があります。たとえば、単一インスタンスのデータ・ソース・ドライバがoracle.jdbc.xa.client.OracleXADataSourceである場合、新しいマルチ・データ・ソースの各構成データ・ソースのドライバはoracle.jdbc.xa.client.OracleXADataSourceである必要があります。

図4-1 マルチ・データ・ソース構成

「図4-1 マルチ・データ・ソース構成」の説明

4.1.3.1 MDSリポジトリのためのマルチ・データ・ソースの構成

MDSデータベース・ベースのリポジトリを使用するアプリケーションは、可用性の高いOracle Databaseへのアクセス用に構成できます。この構成では、MDSおよびWebLogicインフラストラクチャによる障害検出、リカバリおよび再試行によって、アプリケーションの読取り専用のMDS操作が、Oracle RACデータベースの計画停止および計画外停止から保護されます。

マルチ・データ・ソースは、Fusion Middleware Controlのナビゲーション・ツリーに、MDSリポジトリとして公開されます。これらのマルチ・データ・ソースは、アプリケーション・デプロイメントのデプロイメント・プランのカスタマイズ時に選択できます。また、MDS WLSTコマンドでも使用できます。

- 読取り専用操作を再試行できるようなアプリケーションの構成
接続を再試行できるようにアプリケーションを構成するには、アプリケーションのMDS AppConfig MBeanのRetryConnection属性を構成します。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

- MDSマルチ・データ・ソースの登録
第4.1.5項「Oracle RACでのマルチ・データ・ソースの構成」で指定した手順以外にも、次の点を検討してください。

- MDSリポジトリに使用されるマルチ・データ・ソースを構成する子データ・ソースは、XA以外のデータ・ソースとして構成する必要があります。

- マルチ・データ・ソースの名前には、mds-という接頭辞を付ける必要があります。これにより、Fusion Middleware Control、WLSTおよびJDeveloperを介してMDS管理機能に使用できるMDSリポジトリとして、マルチ・データ・ソースを認識できるようになります。

注意:

MDSデータ・ソースをマルチ・データ・ソースの子として追加すると、このデータ・ソースはMDSリポジトリとしては公開されなくなります。たとえば、これはFusion Middleware Controlのナビゲーション・ツリーで、「メタデータ・リポジトリ」フォルダの下に表示されなくなり、それに対してMDSリポジトリの操作を実行できなくなって、デプロイメント時には選択可能なリポジトリのリストに表示されなくなります。

- マルチ・データ・ソースへのデータ・ソースの変換
データ・ソースをマルチ・データ・ソースに変換してアプリケーションが正しく構成されていることを確認する場合、次の2つの考慮事項があります。

- 新しい一意の名前を持つマルチ・データ・ソースを新規作成するには、アプリケーションを再デプロイして、デプロイメント・プランのカスタマイズ時に、この新しいマルチ・データ・ソースをMDSリポジトリとして選択します。

- アプリケーションの再デプロイを回避するには、データ・ソースを削除し、同じ名前とjndi-name属性を使用して、新しいマルチ・データ・ソースを再作成できます。

4.1.3.2 Oracle RACの構成要件

この項では、Oracle RACの構成の要件について説明します。

- XAの要件: 多くのOracleコンポーネントは、分散トランザクションに参加したり、コンテナで管理されるトランザクションの一部となります。それらのコンポーネントには、 Oracle WebLogic トランザクション・マネージャによるXAリカバリ用に、バックエンド・データベースの設定が必要です。RCUを使用して作成されたリポジトリでは、これは自動的に実行されます。XAトランザクションに参加する他のデータベースについては、XAの前提条件が満たされていることを確認してください。

1. 次のように入力して、システム・ユーザーとしてSQL*Plusにログオンします。

sqlplus "/ as sysdba"

2. sys.dba_pending_transactionsに対してselectをpublicに付与します。

3. sys.dbms_xaに対してrunをpublicに付与します。

4. 任意のトランザクションに対してforceをuserに付与します。

注意:

Oracle Databaseのdistributed_lock_timeoutパラメータが、JTAタイムアウトの値より大きな値に設定されていることを確認します。これは、中間層(WebLogic Serverのデフォルト、データ・ソースの特定の構成またはトランザクションのコンポーネントで使用される値)の最高値より大きな値にする必要があります

- サーバー側のロード・バランシング: サーバー側のロード・バランシング機能が(remote_listenersを使用して)Oracle RACバックエンドで有効である場合、マルチ・データ・ソース構成のデータ・ソースで使用されるJDBC URLにINSTANCE_NAMEを含める必要があります。たとえば、このURLは次の書式で指定できます。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)
(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))

デフォルトでは、インストールした時点では、remote_listenerが構成されていると想定されており、それに従ってマルチ・データ・ソースのデータ・ソースにURLが作成されます。通常のインストールおよび構成以外で作成された任意のマルチ・データ・ソースは、この項で説明されている書式に従う必要があります。

remote_listenersがOracle RAC側で指定できず、サーバー側のロード・バランシングが無効になっている場合は、URLのINSTANCE_NAMEを指定する必要はありません。リモート・リスナーを無効にするには、それぞれのOracle RACノードのspfile.oraファイルで、一覧表示されているリモート・リスナーをすべて削除します。例:

*.remote_listener="

この場合、マルチ・データ・ソース構成のデータ・ソースで使用する際にお薦めするURLは次のとおりです。

jdbc:oracle:thin:@host-vip:port/dbservice

または

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=dbservice)))

- サービス: Oracle Database(特にOracle RAC)にOracle Fusion Middlewareを構成する場合、Oracleサービス機能を使用することをお薦めします。特定のアプリケーションのデータベース・サービスの場所の一部として提供するservice_nameを作成します。

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

Oracle WebLogic Serverトランザクション・マネージャがトランザクションの状態情報を問い合せて、WebLogic Serverコンテナで障害が発生した後の処理中トランザクションのリカバリ時に、commitやrollbackなどの適切なコマンドを発行できるようにするには、適切なデータベース権限が必要です。

トランザクション・リカバリ権限のスキーマを構成する手順は次のとおりです。

1. sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例:

sqlplus "/ as sysdba"

2. sys.dba_pending_transactionsに対してselectをappropriate_userに付与します。

3. 任意のトランザクションに対してforceをappropriate_userに付与します。

注意:

これらの権限は、RCUの操作によって決定されるsoainfraスキーマの所有者に付与します。

4.1.4 Oracle RACでのGridLinkデータ・ソースの構成

GridLinkデータ・ソースの構成方法は、使用しているOracleコンポーネントおよび作成するドメインによって異なります。手順の詳細は、使用しているコンポーネントについて説明している項を参照してください。たとえば、SOAの場合、第5.13.20.2項「Oracle WebLogic管理コンソールを使用したGridLinkデータ・ソースまたはマルチ・データ・ソースの作成」を参照してください。

注意:

WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、Oracle単一クライアント・アクセス名(SCAN)アドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、御社のネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。

GridLinkデータ・ソースの構成方法の包括的な概要は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのGridLinkデータ・ソースの作成に関する説明を参照してください。

4.1.5 Oracle RACでのマルチ・データ・ソースの構成

マルチ・データ・ソースは、次のものを使用して構成できます。

- Oracle Fusion Middlewareの構成ウィザード(WebLogic Serverドメインの作成時)

- Oracle Universal InstallerのJava EEコンポーネント構成(Identity ManagementまたはOracle Portal、Forms、ReportsおよびDiscoverer用)

- Oracle WebLogic Server管理コンソール

- WLSTコマンド

マルチ・データ・ソースでは、XAデータ・ソースとXA以外のデータ・ソースの両方のロード・バランシングがサポートされます(これは、Oracle Fusion MiddlewareコンポーネントでサポートされるすべてのOracle Databaseのバージョンに適用されます)。

マルチ・データ・ソースでは、Oracle RACの特定のインスタンスへの接続をプールする個々のデータ・ソースがカプセル化されます。手動で作成されたマルチ・データ・ソースまたは初期構成の後に変更されたマルチ・データ・ソースについては、可用性の高い動作を最適にするために、次のXAデータ・ソースおよびXA以外のデータ・ソースのプロパティ値に設定することを強くお薦めします。環境の要件により変更が必要な場合は、検討とテストを十分に行ってから変更してください。

表4-1 推奨されるマルチ・データ・ソース構成

プロパティ名

値

test-frequency-seconds

5

algorithm-type

Load-Balancing

高可用性環境では、個々のデータ・ソースに対して次の設定をお薦めします。その他のパラメータについても、アプリケーション要件に従って設定することをお薦めします。

表4-2 XAデータ・ソース構成

プロパティ名

値

ドライバ

oracle.jdbc.xa.client.OracleXADataSource

プロパティ・コマンド

<property>

<name>oracle.net.CONNECT_TIMEOUT</name>

<value>10000</value>

</property>

initial-capacity

0

connection-creation-retry-frequency-seconds

10

test-frequency-seconds

300

test-connections-on-reserve

true

test-table-name

SQL SELECT 1 FROM DUAL

seconds-to-trust-an-idle-pool-connection

0

global-transactions-protocol

TwoPhaseCommit

keep-xa-conn-till-tx-complete

true

xa-retry-duration-seconds

300

xa-retry-interval-seconds

60

表4-3 XA以外のデータ・ソース構成

プロパティ名

値

ドライバ

oracle.jdbc.OracleDriver

設定するプロパティ

<property>

<name>oracle.net.CONNECT_TIMEOUT</name>

<value>10000</value>

</property>

initial-capacity

0

connection-creation-retry-frequency-seconds

10

test-frequency-seconds

300

test-connections-on-reserve

true

test-table-name

SQL SELECT 1 FROM DUAL

seconds-to-trust-an-idle-pool-connection

0

global-transactions-protocol

なし

推奨されるマルチ・データ・ソースの例は、付録B「推奨されるマルチ・データ・ソース」を参照してください。

XAデータ・ソースのトランザクション・タイムアウトの増加

次の例外を含むWARNINGメッセージがサーバー・ログに表示される場合があります。

javax.transaction.SystemException: Timeout during commit processing

[ javax.transaction.SystemException: Timeout during commit processing

このメッセージは、設定したXAタイムアウト値を増加する必要があることを示している可能性があります。このような警告が表示された場合は、個々のデータ・ソースのXAタイムアウトを増加できます。

管理コンソールを使用してこの設定を増加する手順は次のとおりです。

1. データ・ソース構成にアクセスします。

2. 「トランザクション」タブを選択します。

3. XAトランザクション・タイムアウトを、300のように大きな値に設定します。

4. 「XAトランザクション・タイムアウトの設定」チェック・ボックスを選択します。このチェック・ボックスは、新しいXAトランザクション・タイムアウト値を有効にするために選択する必要があります。

5. 「保存」をクリックします。

XAマルチ・データ・ソースの個々のデータ・ソースすべてに対してこの構成を繰り返します。

4.1.6 JDBCクライアント

Java J2SEベースのOracle Fusion Middlewareコンポーネントは、Oracle RACの高可用性機能と連携するように最適化されています。このコンポーネントは、Oracle JDBCシン・ドライバまたはOCIベースのJDBCドライバの両方を使用するようにデプロイできます。

JDBCシン・クライアントは、Pure JavaのタイプIVドライバです。これは軽量でインストールが簡単であり、JDBC Oracle Call Interface(OCI)ドライバのパフォーマンスに匹敵する高いパフォーマンスを提供します。JDBCシン・ドライバは、Oracle DatabaseからデータにアクセスするためにOracleによって開発されたプロトコル、TTCを使用しているサーバーと通信します。このドライバは、Javaソケットの上にOracle NetとTTCを実装するTCP/IPの実装を提供することにより、データベースへの直接接続を可能とします。JDBC OCIクライアントはタイプIIのドライバであり、Oracle Netを介してJDBCクライアントへの接続を提供します。これは、Oracle Netのクライアント側インストールを使用します。デプロイメントでは、中間層のOracle Net構成を使用して動作をカスタマイズできます。

注意:

これらのJDBCクライアントは、スタンドアロンのJava J2SEプログラムの一部として使用されます。

Oracle Virtual Directory

データベース・アダプタで使用すると、Oracle Virtual Directoryはデータベースに接続し、接続はプールされません。Oracle RACのデータベース・アダプタの構成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのデータベース・アダプタの作成に関する項を参照してください。

データベースURL

Oracle Directory Services Managerを使用してOracle RACデータベースにOracle Virtual Directoryデータベース・アダプタを構成するには、次の手順を実行します。

1. 「接続」画面で、「URLタイプ」リストから「カスタムURLの使用」を選択します。

2. 「データベースURL」フィールドで、次の例に示すようなOracle RACデータベースに接続するためのURLを入力します。
JDBCシン

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_
BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=host-name-1)(PORT=1521))(ADDRESS=
(PROTOCOL=TCP)(HOST=host-name-2)(PORT=1521)))(CONNECT_
DATA=(SERVER=DEDICATED)(SERVICE_NAME=database-service-name)))

JDBC OCI

jdbc:oracle:oci:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_
BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=host-name-1)(PORT=1521))(ADDRESS=
(PROTOCOL=TCP)(HOST=host-name-2)(PORT=1521)))(CONNECT_
DATA=(SERVER=DEDICATED)(SERVICE_NAME=database-service-name)))

接続タイムアウトの構成

Oracle Directory Services Managerを使用してOracle RACデータベースの接続タイムアウトを構成するには、次の手順を実行します。

1. 「接続」画面のJDBCシンで、タイムアウトのパラメータとしてデータベース・アダプタのパラメータoracleNetConnectTimeoutを秒数で指定します。

2. JDBC OCIの場合は、ディレクトリORACLE_INSTANCE/configのsqlnet.oraでTCP.CONNECT_TIMEOUT=nと指定します。

4.1.7 システム・クライアント

Oracle Fusion Middleware 11gには、Java以外のコンポーネントがいくつか含まれています。これらのコンポーネントは主にCベースで、Oracle Internet Directory(OID)、Oracle Forms、Oracle Reports、Oracle DiscovererおよびOracle Portalが含まれます。これらのコンポーネントでは、Oracle Call Interface層を使用してOracle Databaseと対話します。Oracle RACベースのシステムの場合、一部のコンポーネントは、Oracle Databaseの高可用性イベント通知機能と統合します。

高可用性イベント通知は、データベースに障害が発生した場合に、Java以外のアプリケーションに信号を送ります。受け取ったアプリケーションは環境でコールバックを登録して、データベース接続を監視できます。Java以外のクライアントに関連したデータベースに障害が発生すると、コールバックが呼び出されます。このコールバックには、イベント・ペイロードなどのデータベース障害に関する情報、障害が原因で切断された接続(サーバー・ハンドル)のリストが含まれます。

同じデータベースの別のインスタンス(インスタンスCなど)が停止した場合、クライアントの接続には影響しないため、クライアントには通知されません。

高可用性イベント通知を使用すると、データベースに障害が発生した場合のアプリケーションのレスポンス時間が向上します。イベント通知を使用しないと、データベースの障害が発生した場合に、TCPタイムアウトの時間が経過するまで接続は切断されず、それまでに数分かかってしまいます。高可用性のイベント通知により、スタンドアロン、接続プールおよびセッション・プールの接続はOCIによって自動的に切断されてクリーンアップされ、障害が発生してから数秒以内にアプリケーション・コールバックが呼び出されます。サーバー・ハンドルのいずれかがTAF対応の場合、OCIによって自動的にフェイルオーバーが処理されます。

次の項では、Java以外のクライアントでOracle RACデータベースに接続する際にお薦めする設定について説明します。

4.1.7.1 Oracle Internet Directory

Oracle Internet Directoryは、高可用性のイベント通知と統合します。クライアント・アプリケーションがデータベースへの接続に使用するデータベース・サービスは、Oracle Enterprise Manager Cluster Managed Services Pageを使用して作成することをお薦めします。

SQL*Plusを使用してOracle RACデータベース・サービスを構成することもできます。

Oracle RACデータベース接続で高可用性のイベント通知を有効にするには、次の手順を実行します。

1. AQ_HA_NOTIFICATIONS属性をTRUEに設定して、サーバー側の透過的アプリケーション・フェイルオーバー(TAF)設定を有効にします。フェイルオーバーの再試行とフェイルオーバーの遅延は、デプロイメントの要件に基づいて調整できます。そのため、OIDで使用されるデータベース・サービスの場合、Oracle RACのDBMS_SERVICEプロパティの値を設定するときには、表4-4に従うことをお薦めします。

表4-4 OIDのデータベース・サービス・プロパティ設定

プロパティ名

値

AQ_HA_NOTIFICATIONS

TRUE

FAILOVER_METHOD

DBMS_SERVICE.FAILOVER_METHOD_BASIC

FAILOVER_TYPE

DBMS_SERVICE.FAILOVER_TYPE_SELECT

FAILOVER_RETRIES

5

FAILOVER_DELAY

5

2. Oracle Net構成のTCP接続タイムアウトを設定することもお薦めします。この設定を構成するには、ORACLE_INSTANCE/configディレクトリのsqlnet.oraファイルでTCP.CONNECT_TIMEOUT=nと指定します。

4.1.7.2 Oracle Forms

Oracle Formsも、高可用性のイベント通知と統合します。Oracle Formsでこの機能を有効にするには、次の手順を実行します。

1. Oracle Enterprise Manager Cluster Managed Services Pageを使用して、データベース・サービスを作成します。Oracle Formsでは、表4-5に従ってOracle RACのDBMS_SERVICEプロパティの値を設定します。次のプロパティは、Oracle Databaseのパッケージを使用して設定することをお薦めします。

表4-5 Oracle Formsのデータベース・サービス・プロパティ設定

プロパティ名

値

AQ_HA_NOTIFICATIONS

TRUE

FAILOVER_METHOD

DBMS_SERVICE.FAILOVER_METHOD_NONE

FAILOVER_TYPE

DBMS_SERVICE.FAILOVER_TYPE_NONE

2. Oracle Net構成のTCP接続タイムアウトを設定することもお薦めします。この設定を構成するには、ORACLE_INSTANCE/configディレクトリのsqlnet.oraファイルでTCP.CONNECT_TIMEOUT=nと指定します。

4.1.7.3 Oracle Portal

高可用性環境でOracle Portalの動作を最適に構成するには、Oracle Net構成のTCP接続タイムアウトを設定します。この設定を構成するには、ORACLE_INSTANCE/configディレクトリのsqlnet.oraファイルでTCP.CONNECT_TIMEOUT=nと指定します。

Oracle Portalでは、mod plsqlの障害検出機能も使用します。

mod_plsqlではデータベースへの接続プールが保持され、確立されたデータベース接続が後続のリクエストに再利用されます。接続プールのデータベース接続からレスポンスがない場合には、mod_plsqlでそのことが検出され、切断された接続が廃棄されて、後続のリクエスト用に新しいデータベース接続が作成されます。

mod_plsqlの切断されたデータベース接続検出機能によって、データベース・ノードまたはインスタンスが停止したときにエラーがランダムに発生しなくなります。この機能は、Oracle RACなどの高可用性構成でもきわめて有用です。Oracle RACクラスタのノードが停止すると、mod_plsqlでそのことが検出され、他のOracle RACノードを使用してリクエストへの対応が即座に開始されます。

デフォルトでは、Oracle RACノードまたはデータベース・インスタンスが停止し、そのノードへの接続がmod_plsqlでそれ以前にプールされていた場合、プール内の切断された接続を使用する最初のmod_plsqlリクエストには障害が発生し、レスポンス(HTTP-503)がエンド・ユーザーに返されます。mod_plsqlでは、この障害をトリガーとして、プール内の切断されている接続をすべて検出して削除します。mod_plsqlにより、ノードに障害が発生する前に作成された接続プールがすべてpingされます。このping操作は、プールされた接続を使用する次回リクエストの処理時に実行されます。ping操作が失敗すると、そのデータベース接続は破棄され、新しい接続が作成されて処理されます。

注意:

ノード障害の後、複数のmod_plsqlリクエストを同時に受信したときに、最初に切断された接続がmod_plsqlで検出されていないと、その時点で複数の障害が発生している可能性があります。

mod_plsqlでは、切断されたデータベース接続の検出機能をチューニングするために、次の2つの構成オプションが用意されています。

- 切断されたデータベース接続を検出するオプションの指定

- 接続検証とタイムアウト期間の指定

切断されたデータベース接続を検出するオプションの指定

mod_plsqlでは、データベース・ノードの停止が原因と考えられる障害を検出すると、接続を修正します。これは、PlsqlConnectionValidationパラメータにより制御されます。

PlsqlConnectionValidationをAutomaticに設定すると(デフォルト)、mod_plsqlモジュールは、失敗したリクエストの前に作成されていたプール済データベース接続をすべてテストします。

PlsqlConnectionValidationをAlwaysValidateに設定すると、mod_plsqlは、任意のリクエストを発行する前に、プールされていたデータベース接続をすべてテストします。AlwaysValidate構成オプションを使用すると、可用性は高まりますが、パフォーマンス・オーバーヘッドも増加します。

mod_plsqlが接続プールの不完全なデータベース接続をテストするタイムアウト期間を指定できます。PlsqlConnectionTimeoutパラメータには、テスト・リクエストが完了するまでmod_plsqlが待機する最大時間を指定します。この時間を超えると、接続が使用不可とみなされます。このパラメータの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のmod_plsqlに関する説明を参照してください。

接続検証とタイムアウト期間の指定

PlsqlConnectionValidationパラメータをAutomaticまたはAlwaysValidateに設定すると、mod_plsqlはプールされているデータベース接続をテストします。

mod_plsqlが接続プールの不完全なデータベース接続をテストするタイムアウト期間を指定できます。これは、PlsqlConnectionTimeoutパラメータで制御されます。このパラメータには、テスト・リクエストが完了するまでmod_plsqlが待機する最大時間を指定します。この時間を超えると、接続が使用不可とみなされます。

PlsqlConnectionTimeout、PlsqlConnectionValidationおよびPlsqlConnectionTimeoutパラメータの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のmod_plsqlに関する項を参照してください。

4.1.7.4 Oracle ReportsとOracle Discoverer

高可用性環境でOracle ReportsとOracle Discovererの動作を最適に構成するには、Oracle Net構成のTCP接続タイムアウトを設定します。この設定を構成するには、ORACLE_INSTANCE/configディレクトリのsqlnet.oraファイルでTCP.CONNECT_TIMEOUT=nと指定します。

Oracle Discovererでは、Oracle RACデータベースの接続に、次のようなTNSエントリも使用します。

frdisco = (DESCRIPTION = (LOAD_BALANCE = ON) (ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = stajo05-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = stajo06-vip)(PORT = 1521)))
(CONNECT_DATA = (SERVICE_NAME = orcl.example.com)))

注意:

Oracle DiscovererがカスタマOracle RACデータベースに接続するように構成されている場合、次のTNS接続文字列を使用することをお薦めします。

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host1-vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=host2-vip)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAM
E=orcl)(FAILOVER_MODE=(TYPE=select)(METHOD=basic)(RETRIES=20)(DELAY=15))))

4.2 ファイアウォールのタイムアウトからのアイドル接続の保護

ほとんどの本番デプロイメントにはファイアウォールが関係しており、データベース接続はファイアウォールを介して行われます。そのため、このファイアウォールは、データベース接続がタイムアウトしないように構成することをお薦めします。Oracle RACの場合は具体的に、Oracle RAC VIPおよびデータベース・リスナー・ポートで接続をタイムアウトしないということになります。

そのような構成が不可能な場合は、データベース・サーバー側のORACLE_HOME/network/admin/sqlnet.oraで SQLNET.EXPIRE_TIME=nと設定します。Oracle RACでは、すべてのOracleホームでこのように設定する必要があります。nの単位は分です。これは、ネットワーク・デバイス(ファイアウォール)のタイムアウトの既知の値より小さく設定する必要があります。これらの時間は通常、10分より大きな値で、場合によっては数時間に設定されていることもあるため、できるだけ大きな値に設定する必要があります。

4.3 トラブルシューティング

Oracle RACインスタンスが停止すると、WebLogic ServerはSELECT 1 FROM DUALという問合せを使用して、データベースのステータスを確認します。この問合せは通常、数秒以内に完了します。ただし、データベースのレスポンスが遅い場合、WebLogic Serverはそれを断念してそのデータベースを使用不可とみなします。ログに記録される種類の例外の例を次に示します。

<Mar 30, 2009 2:14:37 PM CDT> <Error> <JDBC> <BEA-001112> <Test "SELECT 1 FROM
DUAL" set up for pool SOADataSource-rac1" failed with exception:
oracle.jdbc.xa.OracleXAException".> [TopLink Warning]: 2009.03.30
14:14:37.890--UnitOfWork(14568040)--Exception [TOPLINK-4002] (Oracle TopLink -
11g Release 1 (11.1.1.1.0) (Build 090304)):
oracle.toplink.exceptions.DatabaseException Internal Exception:
java.sql.SQLException: Internal error: Cannot obtain XAConnection Creation of
XAConnection for pool SOADataSource failed after waitSecs:30 :
weblogic.common.ResourceException: SOADataSource(SOADataSource-rac1): Pool
SOADataSource-rac1 has been @ disabled because of hanging connection tests,
cannot allocate resources to applications. We waited 10938 milliseconds. A
typical test has been taking 16.

データベースからレスポンスを受信するまでWebLogic Serverが待機する時間を増加するには、WebLogic Serverパラメータの-Dweblogic.resourcepool.max_test_wait_secs=30を設定します。このパラメータは、setDomainEnv.shファイルに格納されています。このパラメータを設定すると、WebLogic Serverは、SELECT 1 FROM DUALという問合せに対してデータベースからレスポンスを受信するまで30秒待機し、この時間を超えると断念します。

4.4 Oracle Database 11g (11.2)でのSCANアドレスの使用

11.2 RDBMS Oracle RACデータベースが単一クライアント・アクセス名(SCAN)を使用して構成されていない場合、構成ウィザードおよびOracle Universal Installerで、Oracle RACインスタンスの詳細(host:portという形式のインスタンス・アドレス)を以前のデータベース・リリースで入力したとおりに指定できます。

ご使用の11.2 RDBMS Oracle RACデータベースがSCANを使用して構成されている場合、SCANアドレスでOracle RACインスタンスの詳細を指定します。Oracle RACインスタンスへのFusion Middlewareの接続では、各Oracle RACインスタンスは、サービス名、インスタンス名、ホストおよびポートを使用して一意に識別されます。SCANで構成されたOracle RACデータベースの場合、そのようなすべてのインスタンスのhost:portアドレスはSCAN host:portであるため、この同じ共通アドレスをすべてのインスタンスに使用することをお薦めします。

Oracle Fusion Middlewareの構成では、インストール・タイプに基づき次のガイドラインに従います。

- RCUインストールでは、Oracle RACデータベースに対して、ホスト名をscan-hostname-addressとして指定します。

- Oracle Universal Installerに基づくインストールでは、Oracle Universal Installerで必要な入力形式に応じて、Oracle RACデータベースに対して次のように指定できます。

scan-address-hostname:port:instance1^scan-address-hostname:port:instance2@servicename

または

scan-address-hostname:port^scan-address-hostname:port@servicename

- 11gR2 Oracle RACデータベース用のマルチ・データ・ソースを使用する構成ウィザードに基づくインストールでは、scan-address-hostname,port,service-nameは各構成データ・ソースで同じである必要があります。インスタンス名は、各構成データ・ソースに関して固有である必要があり、Oracle RACエンド・インスタンスがターゲット指定されている必要があります。
SCANを使用したGridLinkでは、インスタンス名は使用されません。次の例では、RACインスタンスを使用しないGridLink接続文字列を示しています。

jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<scan-host-name>)(PORT=<scan-port>)))(CONNECT_DATA=(SERVICE_NAME=rac-service-name)))

- 接続文字列が明示的に指定される場合は、次のベース・フォーマットを使用します。

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=scan-hostname-address)
(PORT=port)))(CONNECT_DATA=(SERVICE_NAME=service-name))) when the whole Oracle
RAC database needs to be specified

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=scan-hostname-address)
(PORT=port)))(CONNECT_DATA=(SERVICE_NAME=service-name)(INSTANCE_NAME=inst1)))
when a specific Oracle RAC instance needs to be specified

注意:

SCANの詳細は、Oracle Grid Infrastructureに関するインストレーション・ガイドのクラスタに関する単一クライアント・アクセス名(SCAN)についての説明や、『Oracle Real Application Clustersインストレーション・ガイド』の簡略化されたクライアント・アクセスに関するSCANアドレスについての説明を参照してください。

SCANの実行時の内容と制限

表4-6では、RACに対して構成するときに、サポートされるシナリオについて説明しています。

表4-6 SCANの実行時の内容と制限

シナリオ

説明

高可用性実行時の成果と制限

1. SCANなし

別のRACインスタンスを指している各下位マルチ・データ・ソースを含むマルチ・データ・ソース

WLSマルチ・データ・ソースを実装することによって管理されるデータベース接続について、実行時の高可用性が得られます。

2. SCAN

SCANアドレスを指している各下位データ・ソースを含むマルチ・データ・ソース

WLSマルチ・データ・ソースを実装することによって管理されるデータベース接続について、実行時の高可用性が得られます。

制限: SCANアドレスを参照した場合でも、WLSマルチ・データ・ソースの高可用性機能を制限付きで使用することになります。

3. SCAN

SCANアドレスを指している単一のデータ・ソース

データベース接続について実行時の高可用性は得られません。

制限: SCANアドレスはRACインスタンスへのエントリ・ポイントを仮想化しますが、WLS上の単一データ・ソースを指定したとしても、それによって高可用性が提供されることはありません。これは、各サーバーが実際には単一のRACインスタンスにバインドされているためです。

4. SCAN

SCANアドレスを指しているGridLinkデータ・ソース

SCANをサポートする適切なデータベース・バージョンを使用してONSを正しく設定する必要があり、これにより、FANが有効な設定を使用して、データベースから送信されるONSステータス・メッセージを受信します。

5 Oracle SOA Suiteの高可用性の構成

Oracle SOA Suiteは、コンポジット・アプリケーションを設計、デプロイおよび管理するためのサービス・インフラストラクチャ・コンポーネントのセットです。Oracle SOA Suiteを使用することで、サービスの作成、管理、およびコンポジット・アプリケーションとビジネス・プロセスへの編成が可能になります。コンポジットを使用すると、様々なテクノロジのコンポーネントを1つのSOAコンポジット・アプリケーションにアセンブルできます。Oracle SOA Suiteは異種ITインフラストラクチャを組み込み、SOAを段階的に導入できます。

この章では、Oracle SOA Suiteコンポーネントについて高可用性の観点から説明します。また、高可用性を備えたデプロイメントの設計に重要なSOAコンポーネントの単一インスタンスの概念について概要を説明します。

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

- 第5.1項「Oracle SOA Suiteの概要」

- 第5.2項「Oracle SOAサービス・インフラストラクチャの高可用性」

- 第5.3項「Oracle BPEL Process Managerと高可用性の概要」

- 第5.4項「Oracle BPM Suiteと高可用性の概要」

- 第5.5項「Oracle Mediatorと高可用性の概要」

- 第5.6項「Oracle Human Workflowと高可用性の概要」

- 第5.7項「Oracle B2Bと高可用性の概要」

- 第5.8項「Oracle Web Services Managerと高可用性の概要」

- 第5.9項「Oracle User Messaging Serviceと高可用性の概要」

- 第5.10項「Oracle JCAアダプタと高可用性の概要」

- 第5.11項「Oracle Business Activity Monitoringと高可用性の概要」

- 第5.12項「Oracle Service Busと高可用性の概要」

- 第5.13項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」

- 第5.14項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンを使用するOracle Service Busの高可用性の構成」

- 第5.15項「Oracle BAMの高可用性の構成」

5.1 Oracle SOA Suiteの概要

図5-1に示すように、Oracle SOA Suiteは、サービス指向アーキテクチャ(SOA)を開発、保護および監視するための包括的な製品スイートを提供します。Oracle SOA Suite 11gは、SCA標準に準拠した、統一されたランタイム・エンジンを実現します。ランタイム・エンジンは、共通のサービス・インフラストラクチャによって管理およびインターコネクトされるサービス・エンジン(BPEL Process Manager、Human Workflow、Mediator、Rules)およびバインディング・コンポーネント(JCAアダプタ、B2B)で構成されます。サービス・インフラストラクチャは、ライフサイクル管理やデプロイメントなどの共通サービスも提供します。

図5-1 Oracle SOA Suiteとコンポーネント

「図5-1 Oracle SOA Suiteとコンポーネント」の説明

SOAコンポジット・アプリケーションは、SOAランタイム・エンジンへのデプロイメントの基本単位です。サービス・コンポーネント(BPELプロセス、ビジネス・ルール、ヒューマン・タスクおよびMediatorルーティング・ルール)は、SOAコンポジットの構成要素です。サービス・コンポーネントは、デプロイメント時にサービス・エンジンにターゲット指定され、サービスと参照は、バインディング・コンポーネントを使用することにより有効になります。実行時には、メッセージはバインディング・コンポーネントによって受信され、サービス・インフラストラクチャによって適切なサービス・エンジンにルーティングされます。

図5-2 Oracle SOAインフラストラクチャ・スタックの図

「図5-2 Oracle SOAインフラストラクチャ・スタックの図」の説明

SOAランタイム・エンジンはOracle WebLogic Application Serverなどのアプリケーション・サーバーのコンテキスト内で動作します。これは、基盤となるアプリケーション・サーバーのロード・バランシングと高可用性の機能を利用します。

このマニュアルでは、次のOracle SOA Suiteコンポーネントの高可用性情報について説明しています。

- Oracle SOAサービス・インフラストラクチャ

- Oracle BPEL Process Manager(Oracle BPEL PM)

- Oracle BPM Suite

- Oracle Mediator

- Oracle Human Workflow

- Oracle JCAアダプタ

- Oracle B2B

- Oracle Web Services Manager

- Oracle User Messaging Service

- Oracle Business Activity Monitoring

5.2 Oracle SOAサービス・インフラストラクチャの高可用性

この項では、SOAサービス・インフラストラクチャの高可用性クラスタを設計するために必要な課題および考慮事項について説明します。

Oracle SOAサービス・インフラストラクチャは、Oracle SOA Suiteを実行するための基礎となるサービスを提供するJava EEアプリケーションです。このJava EEアプリケーションは、Oracle SOA Suiteをインストールすると、自動的にデプロイされるランタイム・エンジンです。コンポジット(ソフトウェア・コンポーネント・アーキテクチャの基本のアーティファクト)をOracle SOAインフラストラクチャにデプロイすると、コンポジットの実行に必要なサービスが提供されます。Oracle SOAインフラストラクチャは、コンポジットに対して、デプロイメント、接続およびスレッド管理のサービスを提供します。このようなサービスによって、コンポジットのライフサイクルやランタイム動作が支えられています。

バックアップとリカバリに関する考慮事項

SOAサービス・インフラストラクチャ・ファイルのバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の「バックアップとリカバリの概要」および「環境のバックアップ」を参照してください。

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

- 第5.2.1項「Oracle SOAサービス・インフラストラクチャの単一インスタンスの特性」

- 第5.2.2項「Oracle SOAサービス・インフラストラクチャの高可用性アーキテクチャとフェイルオーバーに関する考慮事項」

5.2.1 Oracle SOAサービス・インフラストラクチャの単一インスタンスの特性

Oracle SOAサービス・インフラストラクチャは、コンポジットの実行に必要なサービスを提供します。コンポジットは、サービス・コンポーネント・アーキテクチャ(SCA)のデプロイメントの基本単位です。SCAアセンブリ・モデルは、XMLファイルに記述されている要素によって定義される一連のアーティファクトで構成されます。

コンポジットは、コンポーネント、ワイヤ、サービスおよび参照で構成されるソフトウェア・パッケージです。たとえば、Oracle BPELプロセスがコンポーネント、インバウンド・アダプタがサービス、アウトバウンド・アダプタが参照となります。ワイヤはサービス・エンジン間の接続を確立します。

各コンポーネントは、Oracle BPEL PMなどの特定のサービス・エンジンにターゲット指定されます。Oracle SOAサービス・インフラストラクチャは、SOAデータベースに接続してコンポジット状態を保持し、SOA Oracle Metadata Services(MDS)リポジトリに接続してデプロイメントやバージョン追跡などのコンポジット・メタデータを保持します。これら2つのデータベースは、同一の物理データベースである場合がありますが、使用されるスキーマはそれぞれの目的に応じて異なります。SOAインフラストラクチャは、コンポジットのリモート・デプロイメント用のサーブレットを提供します。リモート・デプロイメント用のメタデータとアーティファクトも、MDSリポジトリに格納されます。MDSリポジトリの詳細は、第4.1.3.1項「MDSリポジトリのためのマルチ・データ・ソースの構成」を参照してください。

また、Oracle SOAサービス・インフラストラクチャ・アプリケーションは、個々のコンポーネントを特定エンジンにターゲット指定し、リクエストがSOAシステムに届いたときにそれらのコンポジットをインスタンス化します。ターゲット指定とインスタンス化が終了すると、Oracle SOAサービス・インフラストラクチャはスレッドとリソースの割当てを制御します。これは、コンポジットが実行されるJVMで行われます。

Oracle SOAサービス・インフラストラクチャは、SOAコンポジット・アプリケーションを、図5-3に示すようにUDDIレジストリに統合します。UDDIレジストリは、公開されているサービスの特定、サービスの呼出しおよびサービス・メタデータの管理のための、標準ベースの基盤を提供します。Oracle SOAサービス・インフラストラクチャは中央のハブでもあり、サービス・エンジンがOracle User Messaging Serviceインフラストラクチャを通じて電子メールやボイスなどの通信チャネルにメッセージを配信する際に使用されます。

Oracle SOAサービス・インフラストラクチャは、サービス・コンポーネント・アーキテクチャ内の様々なコンポーネントを支える必須サービスを提供し、コンポーネント間の通信を可能にします。SCAシステムにおける様々なコンポーネントの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

図5-3 Oracle SOAサービス・インフラストラクチャの基本的な単一ノード・アーキテクチャ

「図5-3 Oracle SOAサービス・インフラストラクチャの基本的な単一ノード・アーキテクチャ」の説明

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

- 第5.2.1.1項「Oracle SOAサービス・インフラストラクチャ・アプリケーションの特性」

- 第5.2.1.2項「Oracle SOAサービス・インフラストラクチャの起動とシャットダウンのライフサイクル」

- 第5.2.1.3項「Oracle SOAサービス・インフラストラクチャの外部依存性」

- 第5.2.1.4項「Oracle SOAサービス・インフラストラクチャのプロセスの起動とシャットダウン」

- 第5.2.1.5項「Oracle SOAサービス・インフラストラクチャの構成アーティファクト」

- 第5.2.1.6項「Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所」

5.2.1.1 SOAサービス・インフラストラクチャ・アプリケーションの特性

soa-infra-wls.earファイルには、Oracle SOAサービス・インフラストラクチャ・サービスが含まれています。Oracle SOAサービス・インフラストラクチャ・システムで提供されるサービスは、いずれもシングルトンではないため、Oracle SOAサービス・インフラストラクチャは、完全なアクティブ/アクティブ・モードで実行可能です。SOAサービス・インフラストラクチャのJava EEアプリケーションには、デプロイされているコンポジットの参照と、これらコンポジットのテスト・ページへのリンクを可能にするWebモジュールが含まれています。このWebモジュールでは、関連付けられたURLコンテキストとして/soa-infraを使用しています。このWebモジュールはステートレスであり、特別なセッション・レプリケーション要件はありません。

Oracle SOAサービス・インフラストラクチャ・アプリケーションの他のモジュールは、プロセスをインスタンス化およびトラッキングするためのタスク制御機能と、Oracle User Messaging System(UMS)にアクセスするためのクライアント・サービスを提供します。

タスク・サービスは、プロセスのインスタンス化とトラッキングを非同期で制御します。その他にも、Oracle SOAサービス・インフラストラクチャ・システムでは、複数のEJBが使用されます。しかし、EJBはすべてステートレスであり、Oracle SOAクラスタでのステートフル・セッションBeanレプリケーションに要件はありません。これらEJBでのトランザクションの処理は、Oracle WebLogic Serverのトランザクション制御サービスに依存します。Oracle WebLogic Serverコンテナの障害から確実にリカバリできるようにするために、Oracle WebLogic Serverの基本ガイドラインで推奨されている適切なトランザクション・ストアを構成してください。

5.2.1.2 Oracle SOAサービス・インフラストラクチャの起動とシャットダウンのライフサイクル

Oracle SOAコンポジットは次のものから構成されます。

- BPELプロセス、Human Workflowタスク、Business Rulesなどのコンポーネント。

- Oracle SOAコンポジット・アプリケーションと外部サービス、アプリケーションおよびテクノロジを接続する、サービスおよび参照。

これらのコンポーネントは、Oracle SOAコンポジット・アプリケーションにアセンブルされます。このアプリケーションは、Oracle SOAアプリケーションの管理とライフサイクルを簡素化するデプロイメントの1つの単位です。

Oracle SOAサービス・インフラストラクチャ・アプリケーションは、起動時に、各種サービス・エンジンを初期化し、MDSリポジトリからコンポジットをロードします。これは、個々のコンポーネントを特定エンジンにターゲット指定します。コンポジットがロードされると、システムはリクエストを受信できるようになります。Oracle SOAサービス・インフラストラクチャは、実行時にサービス・コンポーネント間のすべての通信を管理します。サービス・エンジン間でのコールは、インプロセス・コールです。図5-4は、Oracle SOAサービス・インフラストラクチャの起動と操作処理の手順を表しています。

図5-4 Oracle SOAサービス・インフラストラクチャ・アプリケーションの起動とシャットダウンのライフサイクル

「図5-4 Oracle SOAサービス・インフラストラクチャ・アプリケーションの起動とシャットダウンのライフサイクル」の説明

5.2.1.3 Oracle SOAサービス・インフラストラクチャの外部依存性

前の項で説明したように、Oracle SOAサービス・インフラストラクチャのシステムは、次のコンポーネントに依存します。

- インスタンス・マネージャ・サービスは、ランタイムSOAデータベース・スキーマ(soa-infra)に依存します。

- コンポジット・メタデータは、リポジトリとして機能するMDSデータベース・スキーマに格納されます。

- クラスタ化された環境での、デプロイメント・コーディネータ・サービスによるシグナルの伝播は、基盤となるCoherenceクラスタに依存します。

Oracle SOAサービス・インフラストラクチャが適切に起動し、実行されるためには、これらのコンポーネントが使用可能である必要があります。

5.2.1.4 Oracle SOAサービス・インフラストラクチャのプロセスの起動とシャットダウン

Oracle SOAサービス・インフラストラクチャがデプロイされているOracle WebLogic管理対象サーバーが起動するたびに、Oracle SOAサービス・インフラストラクチャ・アプリケーションがデフォルトで起動します。通常は、Oracle SOAサービス・インフラストラクチャやそのコンポーネント自体を停止する必要はありません。一部の操作では、SOAサービス・インフラストラクチャが実行されているOracle WebLogic管理対象サーバーの再起動が必要な場合があります。アプリケーションの停止が必要なのは、一部のパッチを適用するときのみです。

管理コンソールを使用すると、ステータスを確認したり、Oracle WebLogic Serverを起動および停止したりできます。アプリケーションの制御に、WebLogic Server WLSTのコマンドラインも使用できます。また、Oracle Enterprise Manager Fusion Middleware Controlを使用すると、Oracle SOAサービス・インフラストラクチャ・アプリケーションの多数の操作と構成を行って、そのステータスを監視することもできます。Oracle SOAサービス・インフラストラクチャ・アプリケーションの監視および制御の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.2.1.5 Oracle SOAサービス・インフラストラクチャの構成アーティファクト

Oracle Fusion Middleware 11g リリース1(11.1.1.2)からは、Oracleサービス・インフラストラクチャの構成パラメータはSOA MDSデータベースに格納されます。Oracle SOAサービス・インフラストラクチャの主なコントロールは、Oracle Enterprise Manager Fusion Middleware Controlを使用して構成します。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAインフラストラクチャ・プロパティの構成に関する項を参照してください。

- デハイドレーションを処理するためのデータ・ソースJNDI名。

注意:

このファイルからJNDI名が読み取られると、システムで使用されるデータベースが、WebLogic ServerのJDBSリソース構成内でそれらのJNDI名と一致するデータ・ソースによって決定されます。

- サーバーおよびコールバック・サーバーURL
コールバック・サーバーURLとは、非同期サービスにおいて、呼び出したサービスへのレスポンスが通知されるように指定されているアドレスのことです。

注意:

外部または内部の非同期サービスへのリクエストがOracle SOA Suiteから送られると、コールバック・サーバーURLは次のように、優先度の高い順に決定されます。

- 特定の参照用のバインド・プロパティとして指定されたcallbackServerURLを使用します(このプロパティは、コンポジットのモデリング時または実行時にMBeansを使用して設定できます)。これにより、サービス・コールごとに異なるコールバック・サーバーURLを割り当てることができます。このプロパティは、実行時に、対応するバインディングMbeanによって、システムMBeanブラウザを使用して設定されます。特定のURLを追加するには、callbackServerURLプロパティをプロパティ属性に追加し、保存操作を実行します。

- SOAデータベースに指定されているコールバック・サーバーURLを使用します。この場合は、考えられるすべてのサービスに対して適切に機能するアドレスを1つのみ指定できます。

- WebLogic ServerでSOA_Clusterに対して指定されるフロントエンド・ホストとしてコールバック・サーバーURLを使用します。この場合も同様に、アドレスは1つのみ指定でき、SOAデータベース構成オプションに指定されているアドレスと同じであることが推奨されます。

- WebLogic Server MBean APIによって提供されるローカル・ホスト名を使用します。これは、高可用性環境ではお薦めしません。

- メッセージ・トラッキング・インフラストラクチャで収集する情報の監査レベル。

データ・ソース、JTA構成および永続ストアなど、コンテナ・レベルの他の構成オプションは、WebLogic Serverのドメイン構成の一部として保持され、Oracle WebLogic Serverのコア・インフラストラクチャにより、Oracle WebLogic Serverのクラスタ上で同期化されます。

5.2.1.6 Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所

Oracle SOAサービス・インフラストラクチャとそのコンポーネントにより実行される操作は、SOAサービス・インフラストラクチャが実行されているOracle WebLogic管理対象サーバーによってログに記録されます。これらのログは、次の場所にあります。

DOMAIN_HOME/servers/WLS_ServerName/logs/WLS_ServerName.log

別のOracle WebLogic Server管理対象サーバーのログ・ファイルも、管理コンソールで使用できます。ログを確認するには、URL: admin_server_host:port/consoleを使用して管理コンソールにアクセスします。「診断-ログ・ファイル」をクリックします。

Oracle SOAサービス・インフラストラクチャが実行されているOracle WebLogic管理対象サーバーの出力を確認することも重要です。この情報は次の場所に格納されています。

DOMAIN_HOME/servers/WLS_ServerName/logs/WLS_ServerName.out

さらに、管理対象サーバーのログ・ディレクトリに診断ログが作成されます。このログの粒度とロギング・プロパティは、domain_dir/config/fmwconfig/servers/WLS_ServerName/logging.xmlファイルで変更できます。このファイルのプロパティは、Oracle Enterprise Manager Fusion Middleware Controlから、「ファーム」→「SOA」→SOAサーバーを選択して変更することもできます。右クリックして、「ログ」→「ログ構成」を選択します。

Oracle Enterprise Manager Fusion Middleware Controlでは、SOAドメインのすべてのログの選択検索が可能です。選択検索を実行するには、Oracle Fusion Middleware Controlにアクセスし、ファーム・ログをクリックして、soa-infraまたはデプロイされているコンポジットに関する検索条件を入力します。Oracle Enterprise Manager Fusion Middleware ControlのSOAシステムに関してレポートされるログおよび情報の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.2.2 Oracle SOAサービス・インフラストラクチャの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-5は、2つのOracle WebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle WebLogic Serverは、それらの前面のロード・バランサからリクエストを受信する、Web層ホスト上の2つのOracle HTTP Serverインスタンスによってフロントエンド処理されます。

図5-5 Oracle SOAサービス・インフラストラクチャの高可用性アーキテクチャ

「図5-5 Oracle SOAサービス・インフラストラクチャの高可用性アーキテクチャ」の説明

図5-5は、この高可用性の構成の持つ次の主要な特性を表しています。

SOAサービス・インフラストラクチャは、Oracle WebLogic Serverクラスタの一部であるOracle WebLogic Server管理対象サーバーで実行されます。Oracle WebLogic Serverクラスタは、JTS構成、データ・ソースおよび永続ストア定義など、Oracle SOAサービス・インフラストラクチャで使用するOracle WebLogic Serverクラスタの共通アーティファクトの構成を同期化します。

Oracle SOAサービス・インフラストラクチャでは、Oracle WebLogic Serverクラスタに対して構成されたフロントエンド・ホストおよびポート情報を、サーバーおよびコールバック・サーバーURLとして使用します。これらの設定は、管理コンソールから定義します。「クラスタ」→「SOA_Cluster_Name」→HTTP/HTTPSフロントエンド・ホスト→「ポート」を選択します。Oracle SOAサービス・インフラストラクチャが実行されているOracle WebLogic Serverクラスタのアドレスがない場合、サーバーおよびコールバック・サーバーURLに物理ホスト名が使用されます。

Oracle HTTP Serverによってフロントエンド処理されるSOA高可用性インストールでは、Oracle HTTP Serverのリスニング・ポートでの監視が必要になります。これは、SOA管理対象サーバーにデプロイされたすべてのコンポーネントがデプロイメントで使用される場合です。HTTP/HTTPSポートをpingし、事前に決められた応答が返されることを予期する単純なHTTPモニターであれば十分です。特定のSOAコンポーネント(B2Bなど)のみが使用されている場合は、使用中のコンポーネントの状態を検証するために、破損したサーバー全体のより深いレベルまでチェックするモニターを使用することも考えられます。ご使用のロード・バランサでのHTTPモニターの設定方法については、ロード・バランサのベンダーにご確認ください。

サーバーおよびコールバック・サーバーURLの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。クラスタのHTTPフロントエンド・アドレスの変更では、クラスタの一部である管理対象サーバーを再起動する必要があります。

デプロイメント・コーディネータが構成され、コンポジットのデプロイと更新に使用されます。グループ・リーダーによりアーティファクトが更新されると、デプロイメント・コーディネータは、デプロイメント・コーディネータ・クラスタのメンバーに通知を送って、MDSリポジトリから新しいアーティファクトを取得します。デプロイメント後、またはコンポジットに変更があったときに、リーダー・ノードは、クラスタに対してMDSの更新などのシングルトン操作を実行します。

Oracle SOAサービス・インフラストラクチャ・システムでは、Oracle WebLogic Serverクラスタ名をキーとして使用し、デプロイメント・コーディネータ・グループを確認します。Oracle WebLogic Serverクラスタのすべてのノードが(マルチキャストまたはユニキャストで)通信できる場合、デプロイメント・コーディネータ・クラスタは、Oracle SOAサービス・インフラストラクチャを実行するWebLogic Serverクラスタと同じです。

管理サーバーは、アクティブ/パッシブ・モードで実行されます。SOAHOST1で障害が発生したときには、いつでもSOAHOST2の管理サーバーを再起動できます。管理サーバーは、リスナー・アドレスとして仮想IPまたは仮想ホスト名を使用します。

管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第12章「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。

Oracle WebLogic Serverのサーバー全体の移行

SOAサービス・インフラストラクチャは完全なアクティブ/アクティブ・モードで実行可能ですが、アーキテクチャでは一部のSOAコンポーネントを障害から保護するために、Oracle WebLogic Serverの移行機能を使用します。

図5-5に示すように、WLS_SOA1はVIP1でリスニングし、WLS_SOA2はVIP2でリスニングします。各管理対象サーバーはフェイルオーバー・リソースとして他方のノードを使用し、システムは交差的に構成されます。WLS_SOA1はSOAHOST2にフェイルオーバーし、WLS_SOA2はSOAHOST1にフェイルオーバーします。2つのSOA管理対象サーバーが同一ノード上で実行されるシナリオを予想して、適切な容量計画を立てる必要があります。サーバー移行機能の詳細は、このガイドの第3章「WebLogic Serverの高可用性」を参照してください。

サーバーの移行後にトランザクションを再開するため、トランザクションとJMSストアを共有記憶域に構成します。サーバー・インフラストラクチャ・インスタンスの1つで障害が発生した場合、他のインスタンスがその共有記憶域から永続ストアを読み取って、トランザクションとJMS操作を再開できます。

メタデータ・ストアは、データベースの障害から保護するために、Oracle RACデータベース内に構成されます。同時に、Oracle RACデータベースには、SOAプロセスの状態情報も格納されます。この例では、どちらのOracle RACデータベースも同一になります。

Oracle SOAサービス・インフラストラクチャ・コンポーネントについて

これらの高可用性の特性は、クラスタにデプロイされるコンポジット・アプリケーションに組み込まれているほとんどのOracle SOA Suiteコンポーネントに当てはまります。個々のコンポーネントの特定の2ノード高可用性の特性については、この章の個別のコンポーネントの項を参照してください。

5.2.2.1 Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作

この項では、Oracle SOA Suiteの高可用性クラスタ・デプロイメントによって、コンポーネントを障害から保護する仕組みと、コンポーネントの障害が発生したときに予想される動作について説明します。

WebLogic Serverインフラストラクチャは、Oracle SOAサービス・インフラストラクチャ・システムをあらゆるプロセス障害から保護します。

このトピックには、次の項があります。

- 第5.2.2.1.1項「WebLogic Serverの障害」

- 第5.2.2.1.2項「ノード障害」

- 第5.2.2.1.3項「データベース障害」

5.2.2.1.1 WebLogic Serverの障害

WLS_SOAxサーバーで障害が発生すると、ノード・マネージャはローカルでこのサーバーを再起動します。繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへのWLS_SOAxサーバーのサーバー移行を実行します。フェイルオーバーの実行中は、他のSOAサービス・インフラストラクチャ・インスタンスがデプロイメントとコンポジットの更新を主導的に実行し、システム内のサービス・エンジンに必要な基本サービスを提供します。

Oracle HTTP Serverからの処理中のリクエストはタイムアウトして、新しいリクエストは他のWLS_SOAxサーバーに送られます。他のノードでサーバーが正常に再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。移行先のサーバーは、再起動中に実行された更新をMDSリポジトリから読み取り、デプロイメント・コーディネータ・クラスタを結合して新しい更新をリスニングします。また、共有記憶域にあるトランザクション・ログを基に、保留されていたトランザクションを再開します。

サーバー移行シナリオでは、Oracle BPEL PMやOracle Mediatorなどのサービス・エンジンは、SOAサービス・インフラストラクチャとともにフェイルオーバーされます。サービス・エンジン自体は、他のSOAサービス・インフラストラクチャ・インスタンスに対してリクエストを再発行しません。フェイルオーバーが完了すると、サービス・エンジンは、SOAサービス・インフラストラクチャとともに操作を再開します。

Oracle SOAサービス・インフラストラクチャ・アプリケーションは、リソースへのアクセスの失敗、デプロイメント・コーディネータ・インフラストラクチャが原因で発生するエラー、または管理対象サーバーが実行されているかどうかには関係なく発生する問題が原因で使用できなくなる場合があります。そのため、管理者がsoa-infraアプリケーションによって引き起こされるエラーを管理対象サーバーのログで監視することをお薦めします。ログ・ファイルの場所の詳細は、第5.2.1.6項「Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所」を参照してください。

5.2.2.1.2 ノード障害

ノード障害が発生した場合、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。障害が発生したサーバーがデプロイメント・コーディネータ・クラスタ・マスターであった場合、使用可能なサーバーが新しいマスターとなり、SOAサービス・インフラストラクチャはデプロイメントおよびコンポジット・ライフサイクルに対して引き続き使用可能となります。リースのタイムスタンプが検証された後、現在も使用可能なノードのノード・マネージャが、障害が発生した管理対象サーバーで使用されているVIPの移行を試行し、VIPアドレスをローカルで再起動します。これによって、SOAサービス・インフラストラクチャ・アプリケーションは同一ノードで実行される2つのインスタンスを持つようになります。フェイルオーバー・プロセスの詳細は、第3.9項「サーバー全体の移行」を参照してください。

サービス・エンジンは、サービス・インフラストラクチャ・アプリケーションの一部としてコンテナにデプロイされます。このようなサービス・エンジンには、すべてのEARファイルとライブラリ・コールが含まれます。

5.2.2.1.3 データベース障害

SOAサービス・インフラストラクチャ・システムは、GridLinkデータ・ソースおよびマルチ・データ・ソースにより、データベースの障害から保護されます。システム設定中にGridLinkおよびマルチ・データ・ソースを構成し、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることを保証します。

注意:

SOAに対して高速接続フェイルオーバー・フラグを無効化する必要があり、無効化しない場合、NULLポインタ例外が発生します。

Oracle RACおよびMDSリポジトリでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照し、マルチ・データ・ソースのOracle RACおよびMDSリポジトリでの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

5.2.2.2 Oracle SOAサービス・インフラストラクチャのクラスタワイドのデプロイメント

前の項で説明したように、コンポジットのデプロイメントは、SOAサービス・インフラストラクチャによって、中央のMDSリポジトリに格納されます。SOAサービス・インフラストラクチャは、起動するたびにMDSリポジトリおよびSOAストアと同期化して、デプロイメントとプロセスの状態を取得します。デプロイメント・コーディネータ・インフラストラクチャは、コンポジットのデプロイメントと更新の通知を作成します。新たなデプロイメントまたは更新が実行されると、デプロイメント・コーディネータは、クラスタ内のすべてのメンバーに通知します。デプロイメントが正常に終了したことをクラスタ内のすべてのメンバーが確認すると、マスターはコンポジットの起動通知を送信します。ノードの1つでデプロイメントが失敗すると、他のクラスタにデプロイメントがロールバックされます。デプロイメント・コーディネータ・マスター(WebLogic Serverの管理対象サーバー)のエラー・メッセージで、デプロイメントが失敗したノードが示されます。図5-6はこのプロセスを表しています。

図5-6 Oracle SOA Suiteコンポジットのクラスタワイドのデプロイメント

「図5-6 Oracle SOA Suiteコンポジットのクラスタワイドのデプロイメント」の説明

5.2.2.3 クラスタ内でのOracle SOAサービス・インフラストラクチャ・コンポジットのオンライン再デプロイメント

Oracle SOAサービス・インフラストラクチャがコンポジットの更新や再デプロイメントを実行するときに、既存のバージョン(x)に上書きしたり、新バージョン(x+1)を作成したりできます。コンポジットはすべて、コンポジット名とリビジョンに基づいて一意に識別されます。デフォルトでは、コンポジットにアクセスするクライアントは、MDSリポジトリ内で識別されるバージョン(Oracle Enterprise Manager Fusion Middleware Controlでも参照可能)をデフォルト・バージョンとして使用します。各バージョンのライフサイクルを個別に管理して、SOAサービス・インフラストラクチャの単一インスタンスであっても、オンラインでコンポジットを再デプロイメントできます。この操作を実行する手順は次のとおりです。

1. バージョンxをデプロイします。

2. バージョンxをデフォルトに指定します。

3. コンポジットの新バージョン(x+1)をデプロイし、version xをデフォルトに指定します。この手順によって、ユーザーがデフォルト・アクセスで新バージョンにアクセスしないようにします。

4. テスト・クライアントからコンポジットのバージョン(x+1)を指定し、新バージョンにアクセスしてテストします。

5. 検証が終了したら、x+1をデフォルト・バージョンに指定します。新クライアントはバージョンx+1にルーティングされ、一方、旧クライアントはバージョンx内で処理を完了します。

前バージョンはデプロイしたままにすることも、アンデプロイすることもできます。進行中のインスタンスのあるコンポジットをアンデプロイすると、それらのインスタンスは失効し、完了しません。コンポジットをアンデプロイすることによって、MDSリポジトリからコンポジットが削除されます。

5.2.2.4 Oracle SOAサービス・インフラストラクチャのクラスタワイドの構成変更

Oracle SOAサービス・インフラストラクチャが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、SOAサービス・インフラストラクチャで使用されるライブラリの同期化を制御します。

第5.2.1項「Oracle SOAサービス・インフラストラクチャの単一インスタンスの特性」で説明したように、SOAサービス・インフラストラクチャ固有の構成は、SOAデータベースに格納されます。変更はSOAサーバーごとに一度適用されますが、同じSOAドメイン内のすべてのSOAサーバーに影響します。たとえば、この章で説明する高可用性テクノロジでは、サーバーWLS_SOA1のコールバック・サーバーURLまたは監査レベルを変更した場合、その変更はサーバーWLS_SOA2にも適用されます。

注意:

MBeanブラウザを使用してOracle Enterprise Manager Fusion Middleware Controlからコンポジットのプロパティを変更すると、SOAクラスタ内のすべてのノードにも反映されます。たとえば、oracle.soa.config node、server:WLS_SOA1(クラスタ化されたノード)、SCAComposite、My Compositeを選択してMbeanを変更した場合、この変更はクラスタ内の他のサーバーにも伝播します。

5.3 Oracle BPEL Process Managerと高可用性の概要

この項では、高可用性のためのOracle BPEL PMの構成を実行する前に知っておく必要のある問題や考慮する必要のある事項を紹介します。

5.3.1 Oracle BPEL Process Managerの単一インスタンスの特性

サービス・エンジンは、SOAコンポジット・アプリケーション内のサービス・コンポーネントのビジネス・ロジックをホストするコンテナです。Oracle BPEL PMなどの各サービス・コンポーネントは、自身のサービス・エンジンで実行されます。(デシジョン・サービスは、ビジネス・ルール・サービス・エンジンで実行します。)サービス・エンジンはOracle SOAサービス・インフラストラクチャに組み込まれます。Oracle BPELプロセス・エンジンは、Oracle SOAサービス・インフラストラクチャ内で実行され、BPELプロセスを実行可能にするサービス・エンジンです。

BPELプロセスは、個々のサービスのセットをエンドツーエンド・プロセス・フローにアセンブルし、同期および非同期サービスをエンドツーエンドBPELプロセス・フローに展開するための標準を提供します。これにより、プロセスのオーケストレーションや、長期にわたって実行される非同期プロセスの保存が可能になります。

図5-7は、BPELエンジンがOracle SOAサービス・インフラストラクチャのステートレスな部分であることを示しています。Oracle SOAサービス・インフラストラクチャ・アプリケーションを使用して起動し、BPELプロセスを実行するモジュールを含んでいます。デプロイされたコンポジットにBPELプロセスがある場合、SOAサービス・インフラストラクチャは、BPEL Process Managerを起動して、MetaDataStoreからコンポーネントを取得します。

BPEL Process Managerは、作業ユニットが格納されているメモリー内論理キューを管理するディスパッチャ・モジュールを使用して、バインディング・コンポーネント(JMS、データベース、Webサーバー)からの受信メッセージを処理します。

BPEL Process Managerエンジンは、Oracle TopLinkに基づいた永続モジュールによって、プロセスの実行状態をSOAデータベースに保存します。監査フレームワークは、プロセスの実行情報をSOAデータベースに格納して、実行中の処理を継続的に監査します。

図5-7 Oracle BPEL PMの単一インスタンス・アーキテクチャ

「図5-7 Oracle BPEL PMの単一インスタンス・アーキテクチャ」の説明

5.3.1.1 BPEL Process Managerのコンポーネントの特性

BPELサービス・エンジンは、SOAサービス・インフラストラクチャのJava EEアプリケーション(soa-infra.ear)内で実行されます。BPELサービス・エンジンではシングルトン・サービスはありません。BPELプロセスに関連するすべての状態がデータベース(デハイドレーション・ストア)に格納され、メモリー内の状態のレプリケーションは必要ありません。

SOAサービス・インフラストラクチャのJava EE EJBで実行される処理は、トランザクション処理され、Oracle WebLogic Serviceのトランザクション制御サービスに依存します。WebLogic Serverコンテナの障害から確実にリカバリできるようにするために、WebLogic Serverの基本ガイドラインで推奨されている適切なトランザクション・ストアを構成してください。BPELエンジン・システムにはWebモジュールがないため、Oracle BPEL PMをアクティブ/アクティブ・モードで実行している場合は、サーブレット・レイヤーにセッション・レプリケーションは必要ありません。

今回リリースされるOracle Fusion Middlewareでは、BPELサービス・コンテナでの非同期メッセージ・ディスパッチは、JMSに依存しません。そのため、分散JMSインフラストラクチャへの依存性はありません。

外部依存性

BPELエンジン・システムは、次のコンポーネントに依存します。

- BPELプロセスの状態の永続性については、SOAサービス・インフラストラクチャ・データベース

- BPEプロセスのメタデータ・ストアについては、MDSリポジトリ

BPELエンジン・システムが適切に起動し、実行されるためには、どちらのコンポーネントも使用可能である必要があります。

5.3.1.2 Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル

図5-8に示すように、Oracle SOAサービス・インフラストラクチャ・アプリケーションは、起動時に、BPELエンジンを初期化し、MDSリポジトリからコンポジットをロードします。コンポジットにBPELプロセスが含まれる場合は、それら個々のコンポーネントをBPELエンジンにターゲット指定します。プロセスがロードされると、システムはリクエストを受信できるようになります。実行時に、BPELエンジンは、JMSおよびデータベースなどの様々なチャネルからのリクエストを待機します。

図5-8 Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル

「図5-8 Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル」の説明

起動とシャットダウンのライフサイクルの詳細は、次のとおりです。

1. SOAサーバーを起動します。

2. BPELエンジンを起動します。

3. SOAサービス・インフラストラクチャによりMDSリポジトリからコンポジットがロードされます。

4. BPEL PMコンポーネントが、ロードされるBPELエンジンにディスパッチされます。

5. コンポジット・バインディング・コンポーネントがアクティブになります。

6. BPELエンジンがリクエストを処理します。

7. シャットダウン・シグナルがSOAサービス・インフラストラクチャによって受信されます。

8. SOAサービス・インフラストラクチャは、ロードされているコンポジットのアンデプロイを開始します。

9. コンポジット・バインディング・コンポーネントが無効化されます。

10. BPELコンポーネントが、アンロードされるBPELエンジンにディスパッチされます。

11. BPELエンジンがシャットダウンされます。

5.3.1.3 Oracle BPEL Process Managerのリクエスト・フローとリカバリ

リカバリ可能アクティビティは失敗したアクティビティですが、リカバリが可能です。たとえば、非同期BPELプロセスを起動するファイル・アダプタを使用しているときに、システムがインスタンスの処理中にクラッシュした場合は、すべてのメッセージ・レコードが確実にリカバリされるように、サーバーが再起動したときに手動でリカバリを実行できます。

BPELプロセスには、呼出しインタフェースに応じて2つのタイプがあります。

- 一方向: もっとも一般的な非同期ファイア・アンド・フォーゲット・パターン

- 双方向: 同期リクエスト・レスポンス・パターン

サーバー障害後のリカバリ・セマンティックは、プロセスが同期的に呼び出されるか、非同期的に呼び出されるかによって決まります。次に、呼出しとプロセスのタイプ別の動作を説明します。

- 同期呼出し(リクエスト): 同期リクエストでは、サーバー障害時にエラーがクライアントに戻されます。クライアントは、エラー・メッセージを処理して、リクエストの再試行などの適切な措置を講じます。これは、一時プロセスと永続プロセスの両方に対して当てはまります。

注意:

永続プロセスでは、メッセージは、特定時点のデハイドレーション・ストアに永続的に保持されます。Enterprise Managerを使用してデハイドレーション・ストアのメッセージをリカバリし、プロセスを再実行することは可能ですが、クライアントにレスポンスは通知されません。このため、このオプションではなく、クライアントからのすべてのリカバリを処理することをお薦めします。

- 非同期呼出し(ポスト): 非同期呼出しには2つのタイプがあり、1つはプロセスを新しく開始するもので、もう1つは既存プロセスへのコールバックです。コールバックの場合、エンジンは、それが継続操作であることを認識した後、最初に対話ID、次に相関セット(定義されている場合)により、サブスクライブ・プロセスの解決を試行します。非同期リクエストに関連するメッセージは、クライアント・コールの一部として、デハイドレーション・ストアに永続的に保持されます。永続的に保持される前に障害が発生した場合、クライアントは、エラー・メッセージを受け取るとともに、同期呼出しのエラーの場合と同様の方法でエラーを処理します。永続的な保持が成功すると、クライアント・コールが戻され、以降の処理がクライアント・コールのコンテキストの外部で実行されます。サーバーの障害が発生した場合は、Oracle Enterprise Managerを使用して、非同期に呼び出された一方向プロセスを再起動できます。

図5-9 Oracle Enterprise Manager BPEL PMエンジンのリカバリ

「図5-9 Oracle Enterprise ManagerのBPEL PMエンジンのリカバリ」の説明

BPELエンジンでサポートされている同期モデルと非同期モデルの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』および『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

5.3.1.4 Oracle BPEL Process Managerの構成アーティファクト

Oracle Fusion Middleware 11g リリース1(11.1.1.2)からは、Oracle BPEL PMの構成パラメータはSOAデータベースに格納されます。

これらのパラメータを構成するには、Oracle Enterprise Manager Fusion Middleware Controlに移動して、ナビゲーション・ツリーで「SOA」→「soa-infra」→「(server_name)」を選択します。「SOA管理」を右クリックし、「BPELプロパティ」を選択するか、MBeanブラウザを使用して、適切なプロパティに移動します。

これらのプロパティは、Oracle SOA Suiteを実行するWebLogic Serverが属する各WebLogicドメイン・ディレクトリに固有のものです。データソースおよび永続ストアなど、コンテナ・レベルの他の構成オプションは、WebLogic Serverのドメイン構成の一部として保持され、WebLogic Serverのコア・インフラストラクチャにより、WebLogic Serverのクラスタ上で同期化されます。BPELエンジンの構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

図5-10は、管理コンソールを示しており、この管理コンソールでOracle BPEL PMプロパティを構成できます。

図5-10 Oracle BPEL PMの構成プロパティ

「図5-10 Oracle BPEL PMの構成プロパティ」の説明

クラスタ環境でOracle SOA Suiteを使用している場合、あるノードでOracle Enterprise Managerにより構成プロパティを変更する場合、その変更はすべてのノードで行う必要があります。

構成プロパティを設定するには、次の手順に従います。

1. 「SOAインフラストラクチャ」メニューから、「管理」、「システムMBeanブラウザ」の順に移動します。

2. 「SOA管理」→任意のプロパティを選択します。

5.3.2 Oracle BPEL Process Managerの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-5は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle BPEL PMは、Oracle SOAサービス・インフラストラクチャの一部としてデプロイされます。

5.3.2.1 Oracle BPEL Process Managerの障害からの保護および予想される動作

Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。

WebLogic Serverインフラストラクチャは、BPELエンジンをあらゆるプロセス障害から保護します。次のプロセス障害に関する考慮事項は、Oracle BPEL PMに適用されます。

- 管理対象サーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。サーバー全体の移行が構成されており、繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへのサーバー移行を実行します(サーバー移行が構成されている場合)。他のノードでサーバーが再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。移行されたサーバーは、SOAデータベースを読み取って、保留されていた処理を再開し、共有記憶域にあるトランザクション・ログを基にトランザクションを再開します。

- 管理対象サーバーが正常に起動した後でも、JDBCデータ・ソースやOracle Coherence構成に関連するエラーが原因で、BPEL PMサービス・エンジンまたはSOAサービス・インフラストラクチャ全体が使用できなくなる場合があります。そのため、SOAサービス・インフラストラクチャのログでエラーを監視する必要があります。サーバー・ログの場所の詳細は、第5.2.1.6項「Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所」を参照してください。

さらに、WebLogic Serverインフラストラクチャを使用したBPELエンジン自体の障害の処理では、Oracle Enterprise Manager Fusion Middleware Controlで、リカバリ可能として識別されたBPELプロセス・フォルトに対して、フォルト・リカバリ・アクションを定義して実行できます。フォルトに対して実行するリカバリ・アクションは、フォルト・リカバリ・ポリシー・ファイルでBPELプロセス・サービス・コンポーネントに定義されたアクションに基づくものです。

Oracle Enterprise Manager Fusion Middleware Controlでは、これらの障害のタイプを表示できます。

- ビジネス: 処理中の情報に問題がある(データベースで社会保障番号が見つからないなど)ときに発生するアプリケーション固有のフォルト。

- システム: データベース・サーバーが完全に使用不可能であったり、Webサービスにアクセス不可能であったりするなどの、ネットワークおよび他のタイプのエラー。

- Oracle Web Services Manager (WSM): SOAコンポジット・アプリケーション、サービス・コンポーネントまたはバインディング・コンポーネントにアタッチされているポリシーのエラー。

フォルト・リカバリ・ポリシーは設計時に定義します。コンポジットに付属のフォルト・ポリシー・ファイルには、障害発生時に講じる措置が定義されています。詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

インスタンスの欠落

一方向呼出しリクエストのインバウンド・ペイロードは、デハイドレーション・ストアに格納され、現行のグローバル・トランザクションのコンテキストに従ってコミットされます。コール元がすでにグローバル・トランザクションを開始している場合は、コール元がトランザクションをコミットするときに呼出しメッセージが保存され、受信トランザクションがない場合は、新しいトランザクションが開始されて呼出しメッセージがコミットされます。

Oracle Enterprise ManagerにBPEL PMインスタンスが見つからない場合は、手動リカバリ・コンソールに呼出しメッセージが存在することがあります(リカバリ・コンソールには、未配信のすべての受信メッセージがリストされます)。

リカバリ・コンソールに呼出しメッセージがない場合は、コール元のトランザクションのステータスをチェックしてください。

エンドポイントでのトランザクションの問題

BPELは、リクエストが開始されたグルーバル・トランザクション内でデハイドレートできないインスタンスの監査証跡を非同期に保存します。BPELコンポーネントから参照されるトランザクション・サービスがトランザクションをロールバックする場合にも、BPELインスタンスの監査証跡がEnterprise Managerに保存されます。デハイドレーション・ストアに問題がある場合は、グルーバル・トランザクション全体がロールバックされ、監査証跡は保存されません。この場合、メッセージやアクティビティをリカバリして、最後に認識されたデハイドレーション地点から処理を取得できます。

デハイドレーション・ポイントが複数ノードを持つOracle RACデータベースであり、BPELエンジンがホストされているJava EEサーバーがOracle RACノードへのJDBC接続を失った場合、BPELエンジンはトランザクションを再試行します(これにより、現行トランザクションで加えられたすべての変更はロールバックされます)。新たなOracle RACノードへの新たな接続が確立できない場合は、リカバリ・コンソールを使用してBPELメッセージまたはアクティビティをリカバリします。

ロギング

BPELエンジン・ロガーは、デフォルトでINFOレベルに設定されます。メッセージやインスタンスを検索するには、ロガーをTRACEレベルに設定して、WebLogic Serverログ・ファイルに詳細を出力できます。デハイドレーションのログ・メッセージについては、oracle.soa.bpel.engine.dataを有効にします。スレッドまたはディスパッチャのログ・メッセージについては、oracle.soa.bpel.engine.dispatcherを有効にします。すべてのエンジン・ログ・メッセージを取得するには、oracle.soa.bpel.engineを有効にします。

5.3.2.1.1 失敗したBPELインスタンスおよびMediatorインスタンスのリカバリ

サーバーの障害が発生した場合は、非同期に呼び出された進行中の一方向プロセスの手動リカバリが必要になることがあります。このようなプロセスは、リカバリ可能とマークされ、図5-11で示すように、Oracle Enterprise Managerを使用して再起動できます。

図5-11 Oracle Enterprise Managerを使用したBPEL PMインスタンスのリカバリ

「図5-11 Oracle Enterprise Managerを使用したBPEL PMインスタンスのリカバリ」の説明

5.3.2.2 Oracle BPEL Process Managerのクラスタワイドの構成変更

BPELエンジンが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。

第5.3.1項「Oracle BPEL Process Managerの単一インスタンスの特性」で説明したように、BPELエンジン固有の構成は、SOAデータベースに格納されます。変更はSOAサーバーごとに一度適用されますが、同じSOAドメイン内のすべてのBPELインスタンスに影響します。たとえば、WLS_SOA1およびWLS_SOA2が同じSOAクラスタの一部である場合、WLS_SOA1内のBPELのディスパッチャ・スレッド数が20に変更されると、WLS_SOA2のディスパッチャ・スレッドも20に設定されます。

5.4 Oracle BPM Suiteと高可用性の概要

Oracle BPM Suiteは、ビジネス・プロセス管理(BPM)プロジェクトを設計、デプロイおよび管理するコンポーネントの完全なセットを提供します。

5.4.1 Oracle BPM Suiteの単一インスタンスの概要

図5-12に示すように、Oracle BPM Suiteは、BPMプロジェクトを開発、管理および監視するための包括的な製品スイートを提供します。Oracle SOA Suite 11gに基づいて、SCAなどのテクノロジと規格の完全なセットをBPM Suite 11gで活用できます。BPMランタイムは、共通のサービス・インフラストラクチャによって管理およびインターコネクトされるサービス・エンジン(BPMNサービス・エンジン、BPEL Process Manager、Human Workflow、Rules、Mediator)およびバインディング・コンポーネント(JCAアダプタ、B2B)で構成されます。サービス・インフラストラクチャは、ライフサイクル管理およびBPMプロジェクトのデプロイメントの共通サービスも提供します。

図5-12 BPM Suiteの単一インスタンス・アーキテクチャ

「図5-12 BPM Suiteの単一インスタンス・アーキテクチャ」の説明

BPMプロジェクトは、BPMランタイム・エンジンへのデプロイメントの基本単位です。BPMプロジェクトは、サービス・コンポーネント(BPMNプロセス、Business Rules、Human Workflowなど)と参照情報で構成されており、この参照情報は、SOAコンポジット、組織データ(ロールやビジネス・カレンダなど)、ビジネス・インジケータのメタデータおよびダッシュボード・データとして編成されています。

コンポーネントは、デプロイメント時にサービス・エンジンにターゲット指定され、サービスと参照は、バインディング・コンポーネントを使用することで有効になります。組織データ、ビジネス・インジケータおよびダッシュボードのメタデータは、永続的に保持され、実行時に適切なコンポーネントによって評価されます。実行時には、メッセージはバインディング・コンポーネントまたはBPM Workspaceによって受信され、サービス・インフラストラクチャによって適切なサービス・エンジンにルーティングされます。

図5-13は、Oracle BPM Suiteインフラストラクチャ・スタックの図を示しています。

図5-13 BPM Suiteインフラストラクチャ・スタックの図

「図5-13 BPM Suiteインフラストラクチャ・スタックの図」の説明

BPMランタイム・エンジンは、Oracle WebLogic Serverなどのアプリケーション・サーバーのコンテキスト内で実行されます。これは、基盤となるアプリケーション・サーバーのロード・バランシングと高可用性の機能を利用します。

5.4.1.1 Oracle BPM Suiteのコンポーネントの特性

図5-14は、BPM Suiteのコンポーネント、それらの関係、およびそれらが相互に通信するために使用するテクノロジを示しています。

図5-14 BPM Suiteのコンポーネントとインタフェース

「図5-14 BPM Suiteのコンポーネントとインタフェース」の説明

BPM Suiteのコンポーネントは次のとおりです。

- BPMNサービス・エンジン
BPMNは、Business Process Modeling Notationの略称です。BPMNサービス・エンジンは、既存のBPELサービス・エンジンの拡張機能であり、BPELのコア・インフラストラクチャを活用します。BPMNサービス・エンジンは、JPA/EclipseLinkを活用して、データベースによって保持されるSOAインフラストラクチャ・デハイドレーション・ストア内のプロセス・インスタンスの状態を格納またはリカバリし、プロセスの実行の過程で作成される監査レコードを永続的に保持します。MDS APIは、BPMNプロセス・モデルなどのBPMプロジェクト・アーティファクト(ビジネス・カタログなど)に関するメタデータ情報を取得します。

- BPM Composer
BPM Composerは、標準のJ2EE Webアプリケーションです。エンド・ユーザーはブラウザからアクセスします。BPM Composerは、BPMインフラストラクチャ・ライブラリを活用します。プロジェクト・メタデータ層を使用して、BPMプロジェクトのアーティファクト(ビジネス・ルールやBPMNプロセスなど)を作成およびMDSから取得します。

- BPM Workspace
BPM Workspaceは、標準のJ2EE Webアプリケーションです。エンド・ユーザーはブラウザからアクセスします。BPM Workspaceは、Oracle Business Process Interface(OBPI)のAPIを使用して、ワークリストに表示するための、BPMNプロセス・インスタンスおよびユーザー・タスクに関する情報を取得します。また、標準およびカスタムのダッシュボード用にCube Persistence APIを活用します。

- BPMインフラストラクチャ・ライブラリ
もっとも重要なBPMインフラストラクチャ・ライブラリは次のとおりです。

- OBPI:
Oracle Business Process Interfaceは、プロセス・インスタンスやユーザー・タスクなどに関する情報にアクセスする方法を提供します。これは、WebLogic Server内のライブラリとしてデプロイされ、EJBインタフェースおよび依存関係インジェクションのSpring Beanを公開します。OBPIは、ヒューマン・ワークフロー・サービス、アイデンティティ・サービス、ファサードAPIなど、既存のSOAサービスを活用します。OBPIは、BPMインフラストラクチャにアクセスする必要のあるクライアントにとって第一のインタフェースです。

- PML:
プロジェクト・メタデータ層(Project Metadata Layer)は、BPMプロジェクトを管理するための内部APIです。これは、BPMプロジェクトの格納、取得およびラベル付けのためにMDSを活用し、BPM ComposerおよびBPMNサービス・エンジンによって使用されます。

- 分析:
分析ライブラリは、プロセス・キューブを管理する方法を提供します。このライブラリは、EJB3(ステートレス)インタフェースを公開し、永続性のためにJPA/EclipseLinkを使用します。このライブラリは、BPM Workspaceによって使用されます。

注意:

Oracle BPMNサービス・エンジンはBPM Suiteのコアな部分であるため、次の各項で詳細に説明します。

5.4.1.2 Oracle BPM Suiteのコンポーネントの相互作用

表5-1は、BPM Suiteコンポーネントの相互作用のしくみ、およびBPMNプロセスの実行時にコンポーネントごとに実行可能なタスクについて示しています。

表5-1の見出し行に続く、表内の各行では、特定のBPM Suiteコンポーネントを示します。表5-1の最初の列に続く、各列の見出しは、BPMNプロセスの実行時の特定の時点を表します(T1は最初の時点、T2は次の時点など)。T8は、プロセス実行の最後の時点になります。コンポーネントごとに実行可能なタスクは、BPMNプロセスの実行時にタスクが実行される時点におけるそのコンポーネントの行に示されます。

表5-1 BPMNプロセスの実行時にBPM Suiteコンポーネントによって実行されるタスク

コンポーネント

T1

T2

T3

T4

T5

T6

T7

T8

BPM Workspace

タスクの開始を使用してプロセス・インスタンスをインスタンス化する

ユーザー・タスクを承認する

タスクのパフォーマンスとワークロードを監視する

プロセスのパフォーマンスを監視する

BPM Composer

BPMプロジェクトをデプロイする

BPMNサービス・エンジン

プロセス・インスタンスを実行する

プロセス・インスタンスの実行を続行する

プロセス・インスタンスを完了する

BPM Studio

BPMプロジェクトをデプロイする

Webサービス・クライアント

コンポジット・サービスを呼び出してプロセス・インスタンスをインスタンス化する

結果を返す

次に、表5-1に示されているBPMNプロセス実行時の8つの時点(T1からT8)に関する詳細を示します。

- T1.表5-1の例では、BPMプロジェクトが、BPM StudioとBPM Composerのいずれかで使用可能であり、デプロイメントの準備が整っていると想定します。BPM StudioまたはBPM ComposerからBPMプロジェクトをデプロイする処理の一環として、(SCA)アーカイブが作成され、WebLogic Serverで実行されている標準のSOAコンポジット・デプロイヤ・サーブレットに転送されます。コンポジット・デプロイヤ・サーブレットは、MDS内のBPMプロジェクトのコンテンツを格納し、新しいBPMプロジェクトがデプロイされたことを適切なサービス・エンジンに通知します。その後、BPMNサービス・エンジンは、処理するリクエストを受信できるようになります。

- T2.BPMNプロセスを開始するには次の2つの方法があります。

- タスクの開始を使用する:
ユーザーが、プロセス・インスタンスを起動するために、BPMNプロセスの図にあるタスクの開始をモデル化している場合は、デプロイメント・タスクがBPM Workspaceに表示された後、プロセス・インスタンスはここから起動できます。

- 任意のWebサービス(WSクライアント)を使用してタスクの開始でコンポジット・サービスを呼び出します。BPMNプロセスがサービス・インタフェースを公開している場合、そのサービスはコンポジット・サービスとして公開され、したがって、任意のWSクライアントを使用してプロセス・インスタンスをインスタンス化できます。

- T3.BPMNサービス・エンジンは、プロセスの実行を開始し、最初のユーザー・タスクを実行するまでプロセスの実行を続行します。ユーザー・タスクの場合、BPMNサービス・エンジンは、OBPIを使用してヒューマン・タスクを作成します。その結果、SOAインフラストラクチャのデハイドレーション・ストアに新しいタスクが作成されます。

- T4.BPM WorkspaceがOBPIを使用して、ワークリストに表示するための新しいタスクを問い合せます。BPM Workspaceにログインしたユーザーがタスクを処理するとみなされます。最終的に、タスクは承認または拒否され、そのタスクの処理は完了します。BPM WorkspaceがOBPIを使用してタスクを完了します。

- T5.タスクが完了すると、BPMNプロセス内のユーザー・タスク・アクティビティも完了し、プロセスは続行可能になります。

- T6.プロセス・インスタンスの実行時はいつでも、ユーザーがBPM Workspaceを使用してタスクのパフォーマンスとワークロードを監視できます。このために、BPM Workspaceは、Cube Persistence APIを活用して、データベース内に格納されているプロセス・キューブからタスク・パフォーマンス・データを問い合せます。

- T7.最終的に、BPMNプロセスが完了します。

- T8.通常、この最後の手順は、MessageEndイベントを通じてプロセスを呼び出したクライアントに結果を返します。プロセスが完了すると、ユーザーはBPM Workspaceを使用してプロセスのパフォーマンスを監視できます。

5.4.1.3 Oracle BPM Suiteの起動とシャットダウンのライフサイクル

BPMNサービス・エンジンはBPELサービス・エンジンに基づいているため、起動とシャットダウンのライフサイクルは、BPMNサービス・エンジンでもBPELサービス・エンジンでも同じです。詳細は、第5.3.1.2項「Oracle BPEL Process Managerの起動とシャットダウンのライフサイクル」および第5.4.2.1.3項「Oracle BPMNサービス・エンジンの起動とシャットダウンのライフサイクル」を参照してください。

BPM ComposerおよびBPM Workspaceでは、ライフサイクルは、Oracle WebLogic Serverに存在するWebアプリケーションと同じです。

BPMインフラストラクチャ・ライブラリのライフサイクルは、それらのライブラリを使用し、呼び出すシステムのライフサイクルになります。

5.4.1.4 Oracle BPM Suiteの構成アーティファクト

Enterprise ManagerでBPMNサービス・エンジンを構成するには、図5-15に示すように、soa-infraの「SOAインフラストラクチャ」で、「SOA管理」→「BPMNプロパティ」を選択します。

図5-15 BPMNサービス・エンジンの「プロパティ」ページの表示

「図5-15 BPMNサービス・エンジンの「プロパティ」ページの表示」の説明

これにより、図5-16に示されているBPMNサービス・エンジンの「プロパティ」ページが表示されます。追加のパラメータは、システムMBeanブラウザから使用できます。BPMNサービス・エンジンの「プロパティ」ページで「詳細BPMN構成プロパティ」をクリックして、BPMN MBeanブラウザを起動します。

図5-16 BPMN MBeanブラウザの起動

「図5-16 BPMN MBeanブラウザの起動」の説明

Enterprise Managerを使用したOracle BPMNサービス・エンジンの構成の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。

Oracle BPMNサービス・エンジンの高可用性の構成の詳細な手順は、第5.13項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」を参照してください。

5.4.2 Oracle BPMNサービス・エンジンの高可用性

この項では、Oracle BPMNサービス・エンジンの単一インスタンスおよび高可用性について説明します。

5.4.2.1 Oracle BPMNサービス・エンジンの単一インスタンスの特性

サービス・エンジンは、BPMプロジェクト内のサービス・コンポーネントのビジネス・ロジックをホストするコンテナです。Oracle BPMNサービス・エンジンなどの各サービス・コンポーネントは、自身のサービス・エンジンで実行されます。サービス・エンジンはOracle SOAサービス・インフラストラクチャに組み込まれます。

Oracle BPMNサービス・エンジンは、SOAサービス・インフラストラクチャ内で実行され、BPMNプロセスを実行可能にするサービス・エンジンです。

BPMNプロセスは、適切に定義されたプロセス・フロー内で標準化されたアクティビティ、ゲートウェイおよびイベントを使用してビジネス・プロセスをアセンブルするための標準を提供します。BPMNサービス・エンジンは、実行に長い時間がかかる可能性のあるBPMNプロセス・モデルの実行のための機能を提供します。これは、デハイドレーション、ディスパッチ、サービス・オーケストレーションなどの、Oracle BPEL Process Managerのコア・インフラストラクチャ機能を活用します。

5.4.2.1.1 Oracle BPMNサービス・エンジンの単一インスタンス・アーキテクチャ

図5-17に示すように、BPMNサービス・エンジンは、Oracle BPEL Process Managerサービス・エンジン上に構築されたOracle SOAサービス・インフラストラクチャのステートレスな部分です。Oracle BPEL Process Managerおよび高可用性の詳細は、第5.3項「Oracle BPEL Process Managerと高可用性の概要」を参照してください。

図5-17 Oracle BPMNサービス・エンジンの単一インスタンス・アーキテクチャ

「図5-17 Oracle BPMNサービス・エンジンの単一インスタンス・アーキテクチャ」の説明

BPMNサービス・エンジンは、BPEL PMディスパッチャ・モジュールを使用して、バインディング・コンポーネント(JMS、データベース、Webサービス)からの受信メッセージを処理するためにディスパッチします。

プロセス実行の状態は、Java Persistence Architecture(JPA)に基づいた永続モジュールによってSOAデータベースに保存されます。BPMNサービス・エンジンの監査インフラストラクチャは、エンジンが実行中の継続的に監査し、監査レコードをBPMデータベースに格納します。これらの監査レコードは、Oracle Business Activity Monitoring(BAM)での測定およびBAMとの統合のソースとして使用されます。

BPMNサービス・エンジンは、SOAサービス・インフラストラクチャのJava EEアプリケーション(soa-infra.ear)内で実行されます。これはBPEL Process Manager上に構築されているため、特性もBPEL Process Managerと同じです。詳細は、第5.3.1.1項「BPEL Process Managerのコンポーネントの特性」を参照してください。

5.4.2.1.2 Oracle BPMNサービス・エンジンの外部依存性

BPMNサービス・エンジンは、次のコンポーネントに依存します。

- BPMNプロセスの状態の永続性については、SOAサービス・インフラストラクチャ・データベース

- 分析データの永続性については、BPMデータベース
デフォルトでは、BPMデータベースはSOAサービス・インフラストラクチャ・データベースに連結され、追加の手順は必要ありません。

- BPMNプロセスのメタデータ・ストアについては、MDSリポジトリ

BPMNサービス・エンジンが適切に起動し、実行されるためには、図5-17のコンポーネントが使用可能である必要があります。

BPMプロジェクトに応じて、BPMNサービス・エンジンは、次の追加コンポーネントに依存する場合があります。

- BAMアダプタ

- ユーザー・ディレクトリ。たとえば、Oracle Internet Directoryや、BPMと連動するように構成されている別のLDAPサーバーです。

5.4.2.1.3 Oracle BPMNサービス・エンジンの起動とシャットダウンのライフサイクル

図5-18に示すように、Oracle SOAサービス・インフラストラクチャ・アプリケーションは、起動時に、BPMNサービス・エンジンを初期化し、MDSリポジトリからコンポジットをロードします。コンポジットにBPMNプロセスが含まれる場合は、それら個々のコンポーネントをBPMNサービス・エンジンにターゲット指定します。プロセスがロードされ、そのBPM固有のメタデータがデータベース内で永続的に保持されると、システムはリクエストを受信できるようになります。

図5-18 Oracle BPMNサービス・エンジンの起動とシャットダウンのライフサイクル

「図5-18 Oracle BPMNサービス・エンジンの起動とシャットダウンのライフサイクル」の説明

起動とシャットダウンのライフサイクルの詳細は、次のとおりです。

1. BPMサーバーを起動します。

2. BPMNサービス・エンジンを起動します。

3. SOAサービス・インフラストラクチャによりMDSリポジトリからBPMプロジェクト・コンポジットがロードされます。

4. BPMNコンポーネントが、ロードされるBPMNサービス・エンジンにディスパッチされます。

5. 組織データや監査/測定メタデータなどのBPMプロジェクト・メタデータがインフラストラクチャ・データベース内で永続的に保持されます。

6. コンポジット・バインディング・コンポーネントがアクティブになります。

7. BPMNエンジンがリクエストを処理します。

8. シャットダウン・シグナルがSOAサービス・インフラストラクチャによって受信されます。

9. SOAサービス・インフラストラクチャがコンポジットのアンロードを開始します。

10. コンポジット・バインディング・コンポーネントが無効化されます。

11. BPMNコンポーネントが、アンロードされるBPMNエンジンにディスパッチされます。

12. BPMNサービス・エンジンがシャットダウンされます。

5.4.2.1.4 Oracle BPMNサービス・エンジンのログ・ファイル

BPMNサービス・エンジン・ロガーは、デフォルトでINFOに設定されます。メッセージやインスタンスを追跡するときに、ロガーをTRACEレベルに設定して、WebLogic Serverログ・ファイルに詳細を出力できます。

BPMNサービス・エンジンは、SOAサービス・インフラストラクチャと同じファイルにトレース情報をログします。サーバー・ログの場所の詳細は、第5.2.1.6項「Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所」を参照してください。

5.4.2.2 Oracle BPMNサービス・エンジンの高可用性に関する考慮事項

この項では、高可用性のためのOracle BPMN Process Managerの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.4.2.2.1 Oracle BPMNサービス・エンジンの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

BPMNサービス・エンジンは、プロセス・インスタンスのリカバリのためにBPEL PMの機能を活用します。インスタンスのリカバリの詳細は、第5.3.2.1項「Oracle BPEL Process Managerの障害からの保護および予想される動作」を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlで、図5-19に示すように、BPMNサービス・エンジンの管理用の「BPMNエンジン(サービス・エンジン)」を選択します。

図5-19 Enterprise ManagerにおけるBPMNサービス・エンジンのホーム・ページ

「図5-19 Enterprise ManagerにおけるBPMNサービス・エンジンのホーム・ページ」の説明

BPMNサービス・エンジンのホーム・ページは、いくつかのサブ・ページで構成されます。「ダッシュボード」ページがデフォルトのページです。BPMNサービス・インスタンスをリカバリするには、「リカバリ」タブを選択してBPMNサービス・エンジンの「リカバリ」ページを開きます(図5-20を参照)。

図5-20 Enterprise ManagerにおけるBPMNサービスの「リカバリ」ページ

「図5-20 Enterprise ManagerにおけるBPMNサービスの「リカバリ」ページ」の説明

5.4.2.2.2 高可用性のためのOracle BPMNサービス・エンジンの構成

Oracle BPMNサービス・エンジンの高可用性を構成するには、第5.13項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」を参照してください。

5.4.2.2.3 Oracle BPMNサービス・エンジンのクラスタワイドの構成変更

Oracle BPMNコンポーネントが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle BPMNコンポーネントで使用されるライブラリを同期化する役割を持ちます。第5.4.1.4項「Oracle BPM Suiteの構成アーティファクト」で説明したように、Oracle BPMNコンポーネントの構成は、SOA MDSデータベースに格納されます。変更は(SOAサーバーごとに)一度適用されますが、同じSOAドメイン内のすべてのOracle BPMNインスタンスに影響します。

5.4.3 Oracle Business Process Webアプリケーションの高可用性

この項では、Oracle Business Process Webアプリケーションの単一インスタンスおよび高可用性について説明します。

5.4.3.1 Oracle Business Process Webアプリケーションの単一インスタンスの特性

この項では、Oracle Business Process Webアプリケーションの単一インスタンスについて説明します。

5.4.3.1.1 Oracle Business Process Webアプリケーションの単一インスタンス・アーキテクチャ

図5-21に、Oracle BPM Suite Webアプリケーション、および他のBPMNコンポーネントとそれらの相互作用を示します。

図5-21 Oracle BPM Suite Webアプリケーション

「図5-21 Oracle BPM Suite Webアプリケーション」の説明

Webアプリケーションはステートレスです。状態はデハイドレーション・サービスで保持され、データは操作APIを通じて、またはMDSで公開されます。

5.4.3.1.2 Oracle Business Process Webアプリケーションの外部依存性

BPM WorkspaceとBPM Composerは両方とも、BPMNサービス・エンジンとは別にデプロイされますが、BPMNサービス・エンジンに完全に依存しています。BPMNサービス・エンジンが(soa-infraシステムで)停止した場合、BPM WorkspaceもBPM Composerも、デプロイ済のプロジェクトの情報とメタデータにアクセスできなくなります。soa-infraはSOA MDSデータベースに依存しています。ひいては、Business Process Webアプリケーションが使用できるかどうかは、MDSデータベースにかかっています。

5.4.3.1.3 Oracle Business Process Webアプリケーションの起動とシャットダウンのライフサイクル

BPM WorkspaceとBPM Composerは、標準のJ2EEアプリケーションです。これらは、BPMがデプロイされているWebLogic Serverの起動時に起動されます。これらは、管理コンソールから制御でき、強制シャットダウンまたは正常なシャットダウンで停止できます。

5.4.3.1.4 Oracle Business Process Webアプリケーションのログ・ファイル

WorkspaceおよびComposerのWebアプリケーションは、SOA WebLogic Serverのログ・ファイルおよびSOA WebLogic Serverの出力に書き込みます。サーバー・ログの場所の詳細は、第5.2.1.6項「Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所」を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlは、ログ・ファイル・メッセージの診断に使用することができます。

5.4.3.2 Oracle Business Process Webアプリケーションの高可用性に関する考慮事項

この項では、Oracle Business Process Webアプリケーションの高可用性の考慮事項について説明します。

5.4.3.2.1 Oracle Business Process Webアプリケーションの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

BPM WorkspaceとBPM Composerは両方とも、ステートレスWebアプリケーションです。これらが存在するWebLogic Serverがロード・バランサまたはHTTPサーバーの背後にデプロイされると、フロントエンド・デバイスは、アプリケーションが実行されているいずれかのノードにリクエストをルーティングします。ノードの障害が発生すると、リクエストは、使用可能な他のWebLogic Serverにリダイレクトされ、ユーザー・インタフェースでの作業は、中断されることなく続行できます。

5.4.3.2.2 高可用性のためのOracle Business Process Webアプリケーションの構成

Oracle Business Process Webアプリケーションの高可用性の構成の詳細な手順は、第5.13項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」を参照してください。これらのWebアプリケーションは、Oracle SOAサービス・インフラストラクチャの構成の一部として、ステートレスなクラスタでクラスタ化されます。

5.4.3.2.3 Oracle Business Process Webアプリケーションのクラスタワイドの構成変更

サーバーのファイル・システムにローカルに存在するWebアプリケーションに対しては、特別な構成ファイルはありません。Workspaceのプロパティ・ファイルであるworkspace.propertiesなど一部のプロパティ・ファイルは、OracleBPMWorkspace.earファイルの一部ですが、インスタンス固有の設定は含まれていません。これらは、Oracle BPM Workspaceがデプロイされている場所にデプロイされ、使用可能になります。

5.4.4 Oracle Business Process Analyticsの高可用性

この項では、Oracle Business Process Analyticsの単一インスタンスおよび高可用性について説明します。

5.4.4.1 Oracle Business Process Analyticsの単一インスタンスの特性

次の項では、Oracle Business Process Analyticsの単一インスタンスの特性について説明します。

5.4.4.1.1 Oracle Business Process Analyticsの単一インスタンス・アーキテクチャ

Oracle BPM Suiteには、ビジネスフレンドリなプロセス・ダッシュボードをサポートし、Oracle Business Activity Monitoring(BAM)を使用してビジネス・プロセスをリアルタイムに監視するための組込みの分析機能があります。

図5-22は、Oracle BPM Suite分析インフラストラクチャを示しています。

図5-22 Oracle BPM Suite分析インフラストラクチャ

「図5-22 Oracle BPM Suite分析インフラストラクチャ」の説明

技術的な観点から見ると、Oracle BPM Suite分析インフラストラクチャは、次のようなプロセス分析をサポートするために使用されます。

- 監査の永続性
BPMNサービス・エンジンは、アクティビティのラインタイム・データで構成される監査イベントを継続的に生成します。これらの監査イベントのデータは、サービス・エンジンのデハイドレーション・ストアの監査表に永続的に保持されます。監査データは、すべての分析データのソースです。

- JMSトピック
分析データの準備と公開からプロセスの実行を切り離すには、SOAサービス・インフラストラクチャの一部として構成されたJMSトピックが使用されます。

- キューブ・アクションMDB
メッセージドリブンBean(MDB)は、分析データの集計と永続性を、SOAサービス・インフラストラクチャ・データベース内に格納されているBPMキューブ・スキーマにトリガーするために使用されます。

- BAMアクションMDB
メッセージドリブンBean(MDB)は、分析データを、SOAサービス・インフラストラクチャの一部としてインストールされたBAMアダプタに公開するために使用されます。

- プロセスの永続性
SOAインフラストラクチャ・データベースに対する監査イベントおよび分析データの永続性のために、Oracle BPM Suiteは、Java Persistence API(JPA)インフラストラクチャを活用します。

永続性ユニットは、JTAデータ・ソースjdbc/SOADataSourceおよびプロバイダorg.eclipse.persistence.jpa.PersistenceProviderを使用して構成されます。

5.4.4.1.2 Oracle Business Process Analyticsの外部依存性

Oracle Business Process Analyticsライブラリおよびコンポーネントは、BPMNサービス・エンジン・インフラストラクチャの一部として実行されます。これらは、正常に機能するためには、BPMNサービス・エンジンのアーティファクト(問合せ、ストアおよびJDBCリソース)に大きく依存します。サービス・インフラストラクチャの場合と同様に、分析フレームワークが機能するには、SOAデータベースが使用可能である必要があります。さらに、BAMにデータをフィードする際、分析情報を処理するために、必須のBAMシステムが稼働している必要があります。

5.4.4.1.3 Oracle Business Process Analyticsの起動とシャットダウンのライフサイクル

Oracle Business Process AnalyticsはBPMNサービス・エンジンの一部であるため、そのライフサイクルはBPMNサービス・エンジンのライフサイクルと同じです。

5.4.4.1.4 Oracle Business Process Analyticsのログ・ファイル

Oracle Business Process Analyticsコンポーネントのトレースには、次のロガーが使用可能です。

- oracle.bpm.analytics.measurement

- oracle.bpm.analytics.cube

- oracle.bpm.analytics.bam

分析コンポーネントのいずれかに対するロギングを有効にするには、ログ・レベルをTRACEに設定します。

5.4.4.2 Oracle Business Process Analyticsの高可用性に関する考慮事項

この項では、Oracle Business Process Analyticsの高可用性の考慮事項について説明します。

5.4.4.2.1 Oracle Business Process Analyticsの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

Oracle Business Process Analyticsは、他のシステムに情報(主に読取り指向の情報)をフィードする役割を持つサブシステムであるため、フェイルオーバーについて特別な考慮事項は必要ありません。Oracle Business Process Analyticsによって使用される多数のJMSキューは、可用性とロード・バランシングを最適にするために、(SOAシステムの高可用性設定の一部として)均一に分散された宛先として構成されます。永続的に保持されるすべてのBPMキューブ・データは、SOA JDBCサービスを使用します。SOA JDBCサービスは、Oracle RACデータベース用に構成されたマルチ・データソースを使用します。

5.4.4.2.2 高可用性のためのOracle Business Process Analyticsの構成

Oracle Business Process Analyticsの高可用性の構成の詳細な手順は、第5.13項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」を参照してください。

5.4.4.2.3 Oracle Business Process Analyticsのクラスタワイドの構成変更

Oracle Business Process Analyticsインスタンスには、ローカルのインスタンス固有プロパティは格納されません。クラスタの構成変更は、各Oracle Business Process Analyticsインスタンスに適用されます。

5.5 Oracle Mediatorと高可用性の概要

この項では、高可用性のためのOracle Mediatorの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.5.1 Oracle Mediatorの単一インスタンスの特性

Oracle Mediatorは、Oracle SOAサービス・インフラストラクチャ内のサービス・エンジンです。各種プロバイダと、サービスやイベントのコンシューマとを仲介するフレームワークを提供します。Oracle Mediatorサービス・エンジンは、SOAサービス・インフラストラクチャのJava EEアプリケーションとともに即時実行されます。非同期の相互作用やパラレル・ルーティング・ルールの呼出しにより開始された実行のランタイム状態は、SOAランタイム・データベース内に保持されます。Oracle Mediatorの管理の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

- 同期および非同期の相互作用
Oracle Mediatorは、同期および非同期リクエスト・レスポンス相互作用をサポートします。同期相互作用では、リクエストを発行するクライアントは、ブロックされた状態のままでレスポンスを待機します。非同期相互作用では、クライアントはサービスを呼び出しますが、レスポンスを待機しません。非同期相互作用の場合は、タイムアウト期間を指定できます。

- 順次およびパラレルのメッセージ・ルーティング
Oracle Mediatorでは、メッセージを、順次またはパラレルに宛先にルーティングできます。

- 順次ルーティングでは、データは1つのトランザクション内で処理されます。

- パラレル・ルーティングでは、情報のエンキューに1つのトランザクションが使用され、デキューには別のトランザクションが使用されます。

5.5.1.1 Oracle Mediatorのコンポーネントの特性

コンポジットにOracle Mediatorコンポーネントが含まれる場合、SOAサービス・インフラストラクチャはこのコンポーネントをOracle Mediatorエンジンにターゲット指定してデプロイメントします。Oracle Mediatorエンジン・システムで提供されるサービスは、いずれもシングルトンではないため、Oracle Mediatorエンジンは完全なアクティブ/アクティブ・モードで実行可能です。Oracle Mediatorのワーカー・スレッドによるメッセージ処理は、トランザクション処理され、Oracle WebLogic Serverのトランザクション制御サービスに依存します。WebLogic Serverコンテナの障害から確実にリカバリできるようにするために、WebLogic Serverのガイドラインで推奨されている適切なトランザクション・ストアを構成してください。また、Oracle MediatorのエンジンにはステートフルなWebモジュールやステートフルなセッションBeanがないため、Oracle Mediatorをアクティブ/アクティブ・モードで実行するときには、セッション・レプリケーションの構成は一切必要ありません。処理の状態や必要な処理は、Oracle Mediatorによってデータベース内に保持されます。したがって、Oracle Mediatorのデータベースが高可用性に対応している必要があります。そのためには、第5.13.4項「SOAのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って、SOAデータ・ソースに対するマルチ・データ・ソースを構成する必要があります。Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

外部依存性

Oracle Mediatorは、次のコンポーネントに依存します。

- Mediatorメッセージおよびメッセージの状態の永続性については、SOAデータベース

- コンポジットのメタデータ・ストアについては、MDSリポジトリ

Oracle Mediatorが適切に起動し、実行されるためには、どちらのコンポーネントも使用可能である必要があります。

5.5.1.2 Oracle Mediatorの起動とシャットダウンのライフサイクル

Oracle SOAサービス・インフラストラクチャ・アプリケーションは、起動時に、Oracle Mediatorエンジンを初期化し、MDSリポジトリからコンポジットをロードします。コンポジットにOracle Mediatorコンポーネントが含まれる場合は、それらのコンポーネントをOracle Mediatorエンジンにターゲット指定します。Oracle Mediatorルーティング・ルールは、実行時に、インバウンド・バインディング・コンポーネントや別のサービス・エンジンによって呼び出すことができます。Oracle Mediatorエンジンのシャットダウンは、SOAサービス・インフラストラクチャによって開始されます。また、シャットダウン時には、進行中のインスタンスにシグナルが送信され、ロードされていたコンポーネントがアンロードされます。

図5-23は、Oracle Mediatorの起動のライフサイクルを表しています。

図5-23 Oracle Mediatorの起動のライフサイクル

「図5-23 Oracle Mediatorの起動のライフサイクル」の説明

5.5.1.3 Oracle Mediatorのリクエスト・フロー

サーバー障害後のOracle Mediatorのリカバリ・セマンティックは、クライアントの相互作用のタイプとルーティング・ルールのタイプによって決まります。

Oracle Mediatorは、同期および非同期リクエスト・レスポンス相互作用をサポートします。次に、相互作用のタイプ別の動作を説明します。

- 同期相互作用: 同期相互作用では、サーバー障害時にエラーがクライアントに戻されます。クライアントは、エラー・メッセージを処理して、リクエストの再試行などの適切な措置を講じます。

- 非同期呼出し: 非同期呼出しには2タイプあります。1つはルーティング・ルールの実行を新たに開始するもので、もう1つは既存のルールの実行へのコールバックです。コールバックでは、エンジンが相関IDによるサブスクライブ・インスタンスの解決を試行します。コールバックの処理で障害が発生した場合、クライアントは、エラー・メッセージを受け取るとともに、エラーを適切に処理する必要があります。サーバーの障害が発生した場合は、コールバック処理の信頼性を保証するために、クライアント呼出しをトランザクション処理する必要があります。

Oracle Mediatorでは、メッセージを、順次またはパラレルにルーティングできます。サーバーの障害が発生した場合は、パラレルで処理されたメッセージにかぎり、手動リカバリが必要です。次に、ルーティング・ルールのタイプ別の動作を説明します。

- 順次ルーティング・ルール: 順次ルーティング・ルールでは、ルール全体が1つのトランザクション内で実行されます。サーバーの障害が発生した場合、Oracle Mediatorは、基盤となるトランザクション・マネージャにリカバリを依存します。

- パラレル・ルーティング・ルール: パラレル・ルーティング・ルールでは、Oracle Mediatorは、2つの異なるトランザクションを実行するストア/フォワード・パラダイムを使用しており、1つはメッセージを永続的に保持するトランザクション、もう1つはルーティング・ルールを実行するトランザクションです。永続的に保持される前に障害が発生した場合、クライアントは、エラー・メッセージを受け取るとともに、順次ルーティング・ルールと同様の方法でエラーを処理する必要があります。永続的な保持が成功すると、クライアント・コールが戻され、以降の処理がクライアント・コールのコンテキストの外部で実行されます。サーバーの障害が発生した場合、Oracle Mediatorは、ContainerIdLeaseRefreshで指定された構成可能な時間間隔が経過した後のサーバーの再起動時に、リカバリを開始します。

5.5.1.4 Oracle Mediatorの構成アーティファクト

Oracle Fusion Middleware 11g リリース1(11.1.1.2)からは、Oracle Mediatorの構成パラメータはSOA MDSデータベースに格納されます。これらのパラメータは、Oracle Enterprise Manager Fusion Middleware Controlを使用して構成できます。

これらのパラメータを構成するには、Oracle Enterprise Manager Fusion Middleware Controlに移動して、ナビゲーション・ツリーで「SOA」→「soa-infra」→「(server_name)」を選択します。「SOA管理」を右クリックし、「メディエータ・プロパティ」を選択するか、MBeanブラウザを使用して、適切なプロパティに移動します。

5.5.2 Oracle Mediatorの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

Oracle Mediatorは、Oracle SOAサービス・インフラストラクチャと同じ高可用性アーキテクチャを活用する埋込みサービス・エンジンです。図5-5は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle Mediatorは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。

クラスタ化された構成では、シングルトン・サービスはなく、すべての状態がSOAランタイム・データベースに格納されるため、Oracle Mediatorはアクティブ/アクティブ・モードで実行可能です。

注意:

単一ノード環境では、中間層とデータベースの間に長い待機時間がある場合(たとえば、中間層とデータベースが異なるサブネットにある場合)、Oracle Mediatorのパフォーマンスは低下します。

5.5.2.1 Oracle Mediatorの障害からの保護および予想される動作

Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。

パラレル・ルーティング・ルールの実行時に、Oracle Mediatorは、SOAランタイム・データベース内のメッセージのバッチに対する論理ロックを取得します。このロックには、Oracle Mediatorエンジンを一意に識別するコンテナIDへの参照が含まれています。コンテナIDは、起動時に割り当てられます。ユーザーは、DeferredMaxRowsRetrievedを使用してバッチ・サイズを構成できます。前述のように、バッチ・サイズが小さいほど、サーバーの障害が発生したときにリカバリが必要になるロックの行数が少なくなります。

計画外停止が発生した場合は、サーバーの再起動後に、ContainerIdLeaseRefresh間隔で指定された時間だけ待機する必要があります。これにより、サーバーは実行状態のままインスタンスを完了できます。

マルチノードのクラスタ環境で、非同期メッセージ交換パターンにOracle Mediatorが使用されている場合は、リクエストが完了する前にコールバックが返されてきても、Oracle Mediatorでコールバックが処理されない可能性があります。こうした現象は、Oracle Mediatorによりターゲット・サービスに対して開始されたリクエストが完了するのに長時間かかり、リクエストが完了する前にターゲット・サービスからのコールバックが返されるようなシナリオにおいて発生することがあります。

プロセス障害

Oracle Mediatorは、WebLogic Serverインフラストラクチャによってあらゆるプロセス障害から保護されます。次のプロセス障害に関する考慮事項は、Oracle Mediatorに適用されます。

- 管理対象サーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。サーバー全体の移行が構成されており、繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへの管理対象サーバーのサーバー移行を試行します(サーバー移行が構成されている場合)。他のノードでサーバーが再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。移行されたサーバーは、SOAデータベースを読み取って、保留されていた処理を再開し、共有記憶域にあるトランザクション・ログを基にトランザクションを再開します。

- リソースへのアクセスの失敗、コヒーレンス・インフラストラクチャが原因で発生するエラー、またはOracle Mediatorエンジンが配置されている管理対象サーバーのステータスとは関係なく発生する他の問題が原因で、Oracle Mediatorエンジンが実行されているSOAサービス・インフラストラクチャ・アプリケーションが停止する場合があります。そのため、Oracle SOAサービス・インフラストラクチャ・アプリケーションによって引き起こされるエラーを管理対象サーバーのログで監視することをお薦めします。サーバー・ログの場所の詳細は、第5.2.1.6項「Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所」を参照してください。

- サーバーで障害が発生した後のリカバリ時に、Oracle Mediatorは、部分的に処理されたメッセージの再配信を試行します。自動再試行が失敗すると、Oracle Mediatorは、メッセージを手動リカバリできるようにエラー・ホスピタルにエンキューします。

ノード障害

ノード障害が発生した場合、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。クラッシュしたサーバーがコヒーレンス・クラスタ・マスターであった場合、使用可能なサーバーが新しいマスターとなり、Oracle Mediatorエンジンはバインディング・コンポーネントからのメッセージの処理に対して引き続き使用可能となります。リースのタイムスタンプが検証された後、他のノードのノード・マネージャは、障害が発生した管理対象サーバーで使用されているVIPの移行を試行し、VIPをローカルで再起動します。これは、同一ノードで実行される2つのインスタンスを持つOracle Mediatorエンジンに効果的な結果をもたらします。

クラスタワイドの構成変更

Oracle Mediatorエンジンが使用する標準Java EEアーティファクトは、SOAがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle Mediatorエンジンで使用されるライブラリを同期化する役割を持ちます。

第5.5.1項「Oracle Mediatorの単一インスタンスの特性」で説明したように、Oracle Mediatorエンジン固有の構成は、SOA MDSデータベースに格納されます。変更は(SOAサーバーごとに)一度適用されますが、同じSOAドメイン内のすべてのOracle Mediatorインスタンスに影響します。たとえば、WLS_SOA1およびWLS_SOA2が同じSOAクラスタの一部である場合、WLS_SOA1内のOracle Mediatorのハートビート間隔が20に変更されると、WLS_SOA2のハートビート間隔も20に設定されます。

5.5.2.1.1 失敗したMediatorインスタンスのリカバリ

サーバー障害からのリカバリ時に、特定の状況下で、ルーティング・ルールが進行中のメッセージが、手動リカバリのためエラー・ホスピタルに置かれる場合があります。このようなメッセージは、図5-24に示すように、Enterprise Managerを使用してリカバリできます。

図5-24 Oracle Enterprise Managerを使用したMediatorインスタンスのリカバリ

「図5-24 Oracle Enterprise Managerを使用したMediatorインスタンスのリカバリ」の説明

5.5.2.1.2 クラスタ内でのOracle Mediatorの再順序付け

Oracle Mediatorのリシーケンサを使用すると、関連する(ただし必ずしも順序が正しくない)メッセージのストリームを再配置して順序どおりに戻すことができます。ランダムな順序で到着した受信メッセージを順序付けしてから、ターゲット・サービスに正しい順序で送信します。

リシーケンサでは、グループと順序IDの2つの中心的な概念が使用されます。順序IDはメッセージの識別子の部分で、メッセージはこれに基づいて再編成されます。再順序付けのために着信したメッセージは、複数のグループに分割され、各グループ内のメッセージは順序IDに従って順序付けされます。順序付けは、選択された順序付け戦略(Oracle JDeveloper Composite Designerで標準、FIFOおよびベスト・エフォートの各戦略を選択可能)に基づいて行われます。

メッセージ処理は、Oracle Mediatorのキュー・システムのメッセージのバッチにグループIDを割り当てる処理に基づいています。リシーケンサ・デキュー・システムは、インスタンス識別子(ID)を使用してグループをロックし、グループ・メッセージを処理します。ハートビート・インフラストラクチャは、Oracle MediatorでインスタンスIDを作成して保持します。すべてのOracle Mediatorインスタンスに対して1つのインスタンスIDが作成されます。ハートビート・インフラストラクチャは、MEDIATOR_CONTAINERID_LEASE表にインスタンスIDと現在時刻を挿入します。ハートビート・インフラストラクチャには、1つのハートビート・スレッドがあります。このスレッドは、インスタンスIDに関連付けられている時刻を定期的に更新し、その存在を他のOracle Mediatorインスタンスに知らせます。Oracle Mediator構成パラメータContainerIdLeaseRefreshはこの目的で使用され、分単位で指定されます(デフォルトは1)。ハートビート・スレッドは、構成可能な期間内に更新されていないインスタンスIDの検索も行います。Oracle Mediator構成パラメータContainerIdLeaseTimeoutはこの目的で使用され、分単位で指定されます(デフォルトは5)。このスレッドは、それらのインスタンスIDによって保持されているロックを解放します。解放されたグループは、他のOracle Mediatorインスタンスのデキュー・システムが選択して処理することが可能になります。

MEDIATOR_GROUP_STATUS表に格納されているグループの取り得る状態は次のとおりです。

- 処理可能なグループ - 0

- ロック中のグループ - 1

- 処理完了済グループ - 2

- グループの処理中にエラー発生 - 3

ContainerIdLeaseTimeoutパラメータとContainerIdLeaseRefreshパラメータはどちらも、Oracle Enterprise Manager Fusion Middleware ControlのOracle Mediator構成画面で構成できます。これらのプロパティにより、リシーケンス用に構成されているOracle Mediatorインスタンスのクラスタの動作が決まります。各グループの処理は、1つのサーバーがそのリース期間が切れる(インスタンスIDが更新されない)まで実行します。グループを処理中の管理対象サーバーが停止した場合、クラスタ内の他のインスタンスが、リース期間が切れたとき(すなわち、グループに割り当てられている一意なIDがリースのタイムアウト期間中に更新されなかったとき)の順序に従って処理を進めます。

5.5.2.2 Oracle Mediatorの高可用性のトラブルシューティング

Oracle Mediatorの障害をデバッグするには、データベース表をチェックして、障害が発生しているコンテナを特定します。Oracle Mediatorに障害が発生した時点で処理中だったリクエストを特定するには、まだロック状態になっている行を特定し、ロック解除します。この行はBlobとして格納されているため、ペイロードを確認することもできます。

Oracle Mediatorインスタンス・マネージャのポーリング間隔は、すべてのノードで同一である必要があります。使用されているタイムスタンプは、データベースのタイムスタンプです。

データベース内のメッセージは、次のような段階を踏んで処理されます。

- 準備完了

- ロック

- 完了

- エラー

5.6 Oracle Human Workflowと高可用性の概要

この項では、高可用性のためのOracle Human Workflowの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.6.1 Oracle Human Workflowの単一インスタンスの特性

Oracle Human Workflowは、Oracle SOAサービス・インフラストラクチャ内で実行され、インタラクティブなヒューマン・ドリブン・プロセスの実行を可能にするサービス・エンジンです。Human Workflowは、プロセス内外での承認、却下および再割当てのアクションなどの、ヒューマン・インタラクションをサポートします。Human Workflowサービスは、ビジネス・プロセスとのヒューマン・インタラクションを多様な側面から処理する多数のサービスで構成されます。

ヒューマン・タスク・メタデータはすべてメタデータ・サービス(MDS)リポジトリに格納されて、管理されます。Human Workflowエンジンは、SOAサービス・インフラストラクチャ内で実行するサービス・エンジンと、DefaultToDoTaskFlowおよびワークリスト・アプリケーションのための追加のJava EEアプリケーションで構成されます。Human Workflowは、ヒューマン・タスク関連の通知に内部JMS キューを利用します。

Oracle Human Workflowの管理の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.6.1.1 Oracle Human Workflowの起動とシャットダウンのライフサイクル

Human Workflowの起動は、Java EEアプリケーションのロードとサービス・エンジンの初期化という、2つのフェーズから成り立ちます。Java EEアプリケーションは、アプリケーション・サーバーの起動時にロードされます。サービス・エンジンの初期化とシャットダウンは、SOAサービス・インフラストラクチャにより制御されます。初期化後、Human Workflowコンポーネントを持つコンポジットは、SOAサービス・インフラストラクチャによってHuman Workflowサービス・エンジンにターゲット指定されます。

5.6.1.2 Oracle Human Workflowのリクエスト処理

Human Workflowは、他のSOAエンジン(Oracle BPEL PMなど)による呼出しで開始できます。メッセージは、SOAサービス・インフラストラクチャによってエンジンにルーティングされ、ワークフロー・エンジンによってランタイム・スキーマ内に永続的に保持されます。メッセージは、呼出しに関連するクライアント・トランザクションがコミットされた後、ブラウザベースのUIを通じ、管理者アクションに対して使用できるようになります。ユーザー・アクションによるメッセージやランタイム状態の更新は、それぞれ個別のトランザクションです。

ワークフローがトランザクションをコミットするとすぐにBPELに制御が戻され、それとほぼ同時にBPELがトランザクションをコミットします。このウィンドウ間でOracle RACインスタンスが停止すると、フェイルオーバー時にメッセージが再試行され、それがタスクの重複の原因になる場合があります。

5.6.1.3 Oracle Human Workflowの構成アーティファクト

Oracle Fusion Middleware 11g リリース1(11.1.1.2)からは、Oracle Human Workflowの構成パラメータはSOA MDSデータベースに格納されます。これらのパラメータは、Oracle Enterprise Manager Fusion Middleware Controlを使用して構成できます。

これらのパラメータを構成するには、Oracle Enterprise Manager Fusion Middleware Controlに移動して、ナビゲーション・ツリーで「SOA」→「soa-infra」→「(server_name)」を選択します。「SOA管理」を右クリックし、ワークフロー通知/タスク・サービス・プロパティを選択するか、MBeanブラウザを使用して、適切なプロパティに移動します。

5.6.1.3.1 ヒューマン・タスク・サービス・コンポーネントのタスク詳細アプリケーションのURIの管理

Oracle Human Workflowで使用するタスク詳細アプリケーションのURIは、追加したり削除したりできます。

ヒューマン・タスク・サービス・コンポーネントのタスク詳細アプリケーションのURIを管理する手順は、次のとおりです。

1. 次のいずれかのオプションを使用して、このページにアクセスします。

SOAインフラストラクチャのメニュー

ナビゲータのSOAフォルダ

1. 「ホーム」を選択します。

2. 「デプロイ済コンポジット」タブを選択します。

3. 「コンポジット」セクションで、特定のSOAコンポジット・アプリケーションを選択します。

1. 「soa-infra」で、特定のSOAコンポジット・アプリケーションを選択します。

2. 「コンポーネント・メトリック」表で、ヒューマン・タスク・サービス・コンポーネントを選択します。

3. 「管理」をクリックします。
「管理」ページにタスク詳細アプリケーションのURIが表示されます。

図hwf_comp_admin.gifの説明

4. 「追加」アイコンをクリックして、URIに次の詳細を指定します。

- アプリケーション名

- ホスト名

- HTTPポート

- HTTPSポート(オプション)

- URI

5. 「適用」をクリックします。

5.6.2 Oracle Human Workflowの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-5は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle Human Workflowは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。

5.6.2.1 Oracle Human Workflowの障害からの保護および予想される動作

Oracle Human Workflowのエンジンでは、トランザクションEJBを使用して永続性を実現し、JMSキューを使用してユーザー通知を格納します。すべての状態がデータベースとJMSキューに格納され、メモリー内セッション状態がリカバリ用にレプリケートされることはありません。そのため、Oracle Human Workflowのサービス・エンジンと関連Java EEアプリケーションは、WebLogicクラスタ上のアクティブ/アクティブ・トポロジで実行されます。サーバーまたはハードウェアで障害が発生した場合に保留中のトランザクションやローカル・キューに格納されているJMSメッセージをリカバリするために、サーバー全体の移行を構成する必要があります。サーバーが再起動されるまで通知は送信されません。

5.6.2.2 拒否メッセージ表でのHuman Workflowタスクに必要な手動リカバリ

FabricInstanceManager.persistCompositeInstanceBean API(または他のInstanceManager API)には、組込みの再試行ロジックがありません。Oracle RACフェイルオーバーによって引き起こされた一時的な障害があると、WSの呼出しは直接拒否されます。これらの拒否メッセージの手動リカバリは、Oracle Enterprise Manager Fusion Middleware Controlを使用して行われます。

拒否メッセージを手動でリカバリするには、Oracle Enterprise Manager Fusion Middleware Controlで、「SOA」→「soa-infra(soa_server1)」→「<composite_name>」→「フォルトと拒否メッセージ」を選択し、メッセージを選択して、「オプションを指定してリカバリ」を選択します。これでワークフロー・リクエストが再試行されるようになります。

5.6.3 Oracle Human Workflowの高可用性のトラブルシューティング

ヒューマン・ワークフローは、ブラウザ・ベースのクライアントで標準Java EEアプリケーションと同じように動作します。メッセージがランタイム・スキーマ内に永続的に保持されると、そのメッセージをワークフローUIを使用して処理できます。トランザクションの途中でサーバーに障害が発生した場合は、リカバリまたはロールバックが正常に実行されるようサーバーをリカバリする必要があります。Oracle Human Workflowに関連するエラーのデバッグには、次のログが関係します。

- oracle.soa.services.common

- oracle.soa.services.notification

- oracle.soa.services.workflow

- oracle.soa.services.workflow.common

- oracle.soa.services.workflow.evidence

- oracle.soa.services.workflow.metadata

- oracle.soa.services.workflow.persistency

- oracle.soa.services.workflow.query

- oracle.soa.services.workflow.runtimeconfig

- oracle.soa.services.workflow.soa

- oracle.soa.services.workflow.task

- oracle.soa.services.workflow.task.dispatch

- oracle.soa.services.workflow.task.routing

5.7 Oracle B2Bと高可用性の概要

この項では、高可用性のためのOracle B2Bの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.7.1 Oracle B2Bの単一インスタンスの特性

Oracle B2Bは、SOAコンポジット・アプリケーションと外部サービス、アプリケーションおよびテクノロジを接続します。Oracle B2Bは、業界が認めるB2B標準対応マルチプロトコル・ゲートウェイを提供します。Oracle B2Bは、Oracle SOA Suiteを、電子データ交換(EDI)、ebXML、HL7、RosettaNetなどのビジネス・プロトコル標準で拡張します。Oracle B2Bの機能の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

Oracle B2Bは、SOAサービス・インフラストラクチャ内のバインディング・コンポーネントです。B2Bメタデータは、取引パートナの詳細と、サポート・ドキュメントおよびデリバリ・チャネルで構成され、MDSリポジトリに格納されています。SOAコンポジットは、このメタデータへの参照を持ちます。

Oracle B2Bは、様々なチャネルからのメッセージを受け取ります。リスナー・スレッドは、SOAデータベースの表内のメッセージをログに記録し、対応するイベントをJMSキューに送ります。イベント・ハンドラは、JMSキューにあるリクエストを処理するために、イベントをリスニングします。

Oracle B2Bは、ビジネス・エンティティと通信するための、次のトランスポート・プロトコルをサポートしています。

- HTTP(HTTPS)

- Oracle Advanced Queue

- 電子メール(SMTP 1.0、IMAP 1.0、POP3)

- ファイル

- FTPおよびSFTP(SSH FTP)

- TCP/IP

- JMS

HTTPプロトコルの場合、Oracle B2Bは、システムのHTTPリスナーを使用します。FTPおよび電子メールの場合、Oracle B2Bは、外部FTPと、システム内で構成されている電子メール・サーバーを使用します。高可用性モードでも、1つのB2Bインスタンスだけが、FTP、ファイルおよび電子メールの各プロトコルの受信メッセージをポーリングします。

注意:

MLLP & TCP/IPプロトコルは、クラスタ化された環境ではサポートされません。

5.7.1.1 Oracle B2Bのコンポーネントの特性

Oracle B2Bは、SOAサービス・インフラストラクチャのJava EEアプリケーションとともに即時実行されます。Oracle B2Bのユーザー・インタフェースは、SOAサービス・インフラストラクチャと同じ管理対象サーバーにスタンドアロンのWARファイルとしてデプロイされるWebアプリケーションです。Oracle B2B UIアプリケーションは、ステートフルで、HTTPセッションに情報を格納します。

Oracle B2Bは、状態情報をJMSキューとSOAランタイム・データベースに格納します。サーバーの障害が発生した後のJMSメッセージおよびトランザクションの自動リカバリには、サーバー全体の移行が必要です。

Oracle B2Bは、JMSを集中的に使用します。Oracle B2Bは、Oracle B2BのJMSリソースを障害から保護するために、Oracle WebLogic Serverの移行機能を使用します。Oracle B2Bのエンジンは、EJBとサーブレットを使用しますが、そのどちらもステートレスです。すべての状態情報は、JMSキューとデータベース内に永続的に保持されます。

B2Bの高可用性は、ランタイム・データベースの高可用性に依存します。したがって、GridLinkデータ・ソースまたはマルチ・データ・ソースとして構成して、高可用性を確保することをお薦めします。第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」または第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

外部依存性

Oracle B2Bは、次のコンポーネントに依存します。

- Oracle B2Bメッセージおよびメッセージの状態の永続性については、Oracle SOAデータベース

- Oracle B2Bのメタデータ・ストアについては、MDSリポジトリ

- 対応するアダプタが使用されている場合は、FTPおよび電子メール・サーバー

Oracle B2Bが適切に起動し、実行されるためには、SOAデータベースとMDSリポジトリが使用可能である必要があります。

5.7.1.2 Oracle B2Bの起動とシャットダウンのライフサイクル

Oracle SOAサービス・インフラストラクチャ・アプリケーションは、起動時にOracle B2Bのエンジンを初期化します。Oracle B2Bメタデータのデプロイメントは、コンポジットがOracle SOAサービス・インフラストラクチャにデプロイされる前に実行されます。Oracle B2Bのエンドポイントは、チャネルとして定義され、エンジンの初期化時に起動されます。構成された各チャネルには、プロトコルに応じて次のような外部依存性があります。

- FTPを使用する場合は、適切なFTPサーバーを起動する必要があります。

- 電子メールを使用する場合は、適切な電子メール・サーバーを起動する必要があります。

- HTTP/HTTPSを使用する場合は、B2Bシステムをフロントエンド処理するHTTPサーバーを起動する必要があります。

5.7.1.3 Oracle B2Bのリクエスト・フロー

Oracle B2Bシステムでは、すべての処理が非同期で実行されます。リクエストが到着すると、対応するメッセージがSOAデータベースに挿入されます。保留中の処理のプレースホルダとしてのJMSキューに通知が挿入されます。イベント・ハンドラ・スレッドは、このキューにあるイベントをリスニングして、処理を順次実行します。

図5-25 Oracle B2Bのリクエスト・フロー

「図5-25 Oracle B2Bのリクエスト・フロー」の説明

5.7.1.4 Oracle B2Bの構成アーティファクト

Oracle B2Bのサーバーのメトリックは、Oracle Enterprise Manager Fusion Middleware Controlを使用して有効および無効にできます。これは、Oracle Enterprise Manager Fusion Middleware Controlにより直接公開される唯一のプロパティです。Oracle B2Bのサーバーの構成はSOAデータベースに保持され、その多くはOracle B2Bのユーザー・インタフェース・アプリケーションにより公開されます。Oracle B2B構成の詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』を参照してください。

5.7.2 Oracle B2Bの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-5は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle B2Bは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。次の高可用性の特性は、Oracle B2Bの高可用性デプロイメントに固有のものです。

- Oracle B2Bのユーザー・インタフェース・アプリケーションは、Oracle WebLogic Serverの各サーバー内で、Oracle SOAサービス・インフラストラクチャ・アプリケーションと同じクラスタの一部として実行されます。

- Oracle B2Bのサーバーは、パートナ、ドキュメントおよびチャネルの定義を、Oracle RACデータベースを使用するSOAデータベースに保持します。

5.7.2.1 Oracle B2Bの障害からの保護および予想される動作

この項では、Oracle B2Bの高可用性クラスタ・デプロイメントによって、コンポーネントを障害から保護する仕組みと、コンポーネントの障害が発生したときに予想される動作について説明します。

Oracle B2BのUI障害

Oracle B2Bのユーザー・インタフェース・アプリケーションは、ナビゲーションの情報の一部をメモリーに保持します。Oracle B2Bのユーザー・インタフェースを実行する管理対象サーバーの1つで障害が発生すると、ユーザーのリクエストは、アプリケーションを実行しているアクティブな別のWebLogic Serverにリダイレクトされます。Oracle HTTP Serverからの処理中のリクエストは、Oracle HTTP Serverの構成のタイムアウト設定に応じてタイムアウトします。アプリケーションではセッション情報のシリアライズが有効化されていないため、フェイルオーバーには、障害が発生したインスタンスにアクセスしているユーザーの再ログインが必要となります。

Oracle B2Bのユーザー・インタフェースのメモリー内データはトランザクションではなく、フェイルオーバー時にはいくつかの手順の繰り返しが必要になる場合があります。

Oracle SOAサービス・インフラストラクチャのプロセス障害の一般情報は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。

ノード障害

ノード障害が発生したり、Oracle WebLogic Serverのローカルのノード・マネージャで、障害の発生した管理対象サーバーの再起動の最大試行回数に達したりした場合には、使用可能なサーバーがデータベース・リース・システム内のタイムスタンプを検証した後、サーバー全体の移行がトリガーされます。他のOracle B2Bエンジンでは、別のチャネルからの新しいメッセージの処理が引き続き可能です。同時に、他のOracle B2Bサーバーは、障害の発生したノードでデータベースに設定されているタイムスタンプのデフォルトのタイムアウト期間(デフォルトは2分)が経過した後、FTP、電子メールまたはファイルなど、シングルトン・チャネルの保留中の操作を再開します。Oracle B2Bのユーザー・インタフェース・アプリケーションでは、Oracle HTTP Serverの構成に応じて、Oracle HTTP Serverからの処理中のリクエストがタイムアウトします。

データベース障害

Oracle B2Bのデータベース障害の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。

5.7.2.2 Oracle B2Bのクラスタワイドの構成変更

Oracle B2Bエンジンが使用する標準Java EEアーティファクトは、Oracle SOAサービス・インフラストラクチャがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle B2Bのエンジンで使用されるライブラリの同期化を制御します。

第5.7.1項「Oracle B2Bの単一インスタンスの特性」で説明したように、Oracle B2Bサーバー固有のすべての構成はデータベース内に保持され、構成変更は、WebLogic Serverドメインで実行されるすべてのSOAサーバーに適用されます。したがって、ペイロード・サイズやアウトバウンド・ディスパッチャ数などの構成プロパティはクラスタワイドで適用されるため、Oracle SOAクラスタ内のすべてのインスタンスで使用されることになります。

ファイル、FTPまたは電子メールのトランスポートを高可用性環境で設定するには、b2b.HAInstanceName unique_instance_nameを使用して、各インスタンスの一意の名前を指定します。値に#ServerName#を使用すると、Oracle B2Bは、HAInstanceNameとしてWebLogic Server名を取得します。

『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』のFusion Middleware Controlで設定するプロパティに関する項でも、高可用性環境におけるファイル、FTPまたは電子メールのトランスポートの設定について説明しています。

5.7.2.3 クラスタ内へのOracle B2Bのデプロイメント

B2Bでのメタデータのデプロイ、パージ、またはインポートにコマンドライン・ユーティリティを使用すると、B2Bシステム内での不整合やエラーが発生する場合があります。B2Bでのアグリーメントのデプロイ、メタデータのパージまたはインポートには、コマンドライン・ユーティリティを使用しないで、B2Bコンソールで使用可能なGUIのみを使用してください。

5.7.2.4 Oracle B2Bのアクティブ/アクティブ構成のトラブルシューティング

この項では、Oracle B2Bのアクティブ/アクティブ構成のトラブルシューティングのヒントと有効な解決法について説明します。

5.7.2.4.1 B2Bメタデータのパージ、インポートまたはデプロイメント

B2Bメタデータをクラスタにパージ、インポートまたはデプロイメントするときに、エラーのタイミングとロード・バランシングによって、操作を再試行した場合に発生する可能性の低い例外が発生する場合があります。

この場合に必要なクリーンアップ手順や追加手順はありません。[java] MDS-02202: メタデータ・オブジェクトのコンテンツのようなエラーがデプロイメントで表示されたり、postTransfer: MDS-00521: ドキュメント読取り時のエラー... のようなエラーがパージやインポートで表示された場合は、操作を再試行してください。

5.7.2.4.2 Oracle B2Bのドキュメント定義取得時のエラー

問題: Oracle B2Bからドキュメント定義XSDの取得を試行する際にエラーが発生します。B2Bはクラスタ内に配置され、ロード・バランサを通じてアクセスされます。B2Bコンソールには、次のようにレポートされます。

An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when clustering
is enabled.

ソリューション: このエラーは、フロントエンドHTTPホスト、およびOracle B2Bが配置されているOracle WebLogicクラスタのポートを設定していないために起きます。このエラーを解決するには、次の手順を実行してSOAクラスタのフロントエンド・アドレスを設定します。

1. 管理コンソールの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

2. 左側のペインで、「ドメイン構造内の環境」ウィンドウを選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. 「WLS_SOA」クラスタを選択します。

4. 「HTTP」を選択します。

5. 次の値を設定します。

- フロントエンド・ホスト: soa.mycompany.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80

6. 「保存」をクリックします。

7. 変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

8. サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。

5.8 Oracle Web Service Managerと高可用性の概要

この項では、高可用性のためのOracle WSMの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.8.1 Oracle WSMの単一インスタンスの特性

Oracle Web Services Manager(Oracle WSM)は、組織全体でWebサービスを一貫して管理および保護するポリシー・フレームワークを提供します。これは、セキュリティ、WSRM、MTOMおよびアドレス指定ポリシーなどのWebサービス・ポリシーを構築、施行、実行および監視する機能を提供します。通常、SOAサービス・インフラストラクチャとともにデプロイされます。

Oracle WSMを構成するコンポーネントは、次のとおりです。

- ポリシー・マネージャは、MDSリポジトリに対して、事前定義済ポリシーやカスタム・ポリシーをはじめとするセキュリティ・ポリシーおよび管理ポリシーの読取りと書込みを実行します。通常は、Oracle SOAサービス・インフラストラクチャの管理対象サーバーにデプロイされます。一方、ポリシー・マネージャは個別の管理対象サーバーにデプロイできます。
ポリシー・マネージャは、ステートレスJava EEアプリケーションです。ステートレス・セッションBeanによって、その機能が公開されます。ポリシー・マネージャは、データを一切キャッシュしません(アクセスの対象は、すべてMDSリポジトリとなります)。

- エージェントは、ポリシーの施行、実行、およびランタイム統計の収集を行います。Oracle WSMエージェントは、Oracle Fusion Middlewareのすべての管理対象サーバー上で使用できます。これは、保護するアプリケーションと同じサーバー上で構成されます。
Oracle WSMエージェントは、jarファイルのセットで構成され、そのセットが、基盤となるWebサービス・スタックの一部となります。これには、セッションの状態はありません。エージェントは、メモリー内ポリシー・キャッシュを保持し、これがエージェントの起動時に移入されます。JTAまたはJMSは使用しません。

Oracle WSMエージェントは、次の2つの部分で構成されます。

- ポリシー・アクセス・ポイント(PAP)は、ポリシー・マネージャと通信します。エージェントは、T3(SSLが有効な場合はT3s)プロトコル上でのEJBの呼出しによってポリシー・マネージャと通信します。

- ポリシー・インターセプタは、Webサービスがデプロイされてアクティブ化されたとき、またはポリシーがEnterprise Managerを使用してWebサービスにアタッチされたときに生成されます。新たなWebサービスがOracle WSMを使用して保護された場合は、各新規Webサービスに対してインターセプタの追加インスタンスが生成されます。インターセプタは、ポリシーを施行します。

- メタデータ・ストア・ポリシーは、MDSリポジトリに格納されます。通常は、Oracle Databaseがバックエンドで使用されます。高可用性を確保するため、MDSリポジトリのバックエンドとしてOracle RACデータベースを使用することをお薦めします。

- Oracle WSMの構成には、Enterprise Managerが使用されます。Oracle WSMによって収集された様々なWebサービス・メトリックも表示されます。

Oracle WSMアーキテクチャの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

図5-26 Oracle WSMの単一インスタンス・アーキテクチャ

「図5-26 Oracle WSMの単一インスタンス・アーキテクチャ」の説明

5.8.1.1 Oracle WSMのコンポーネントの特性

Oracle WSMエージェントは、Webサービス・スタック内のOracle Fusion Middlewareのすべての管理対象サーバーで使用可能な.jarファイルのセットです。

ポリシー・マネージャは、wsm-pm.earファイルに格納されます。Oracle WSMで提供されるサービスは、いずれもシングルトンではないため、Oracle WSMエンジンは完全なアクティブ/アクティブ・モードで実行可能です。Oracle WSMサービスは、http://SOAHOSTx:port/wsm-pm/validatorで検証できます。このバリデータには、Oracle WSMポリシーが表示されます。

Oracle WSMエージェントとOracle Enterprise Managerは、EJBインタフェースを使用してポリシー・マネージャと対話します。Oracle WSMで使用されるEJBはステートレスであり、クラスタ化された環境にデプロイできます。そのため、クラスタ内で状態のレプリケーションを有効化するための要件はありません。

Oracle WSMエージェントとポリシー・マネージャを同じ場所に配置する必要はありません。ただし、エージェントでは、ポリシー・マネージャがドメインの最低1つのノードにデプロイされていると想定します。Oracle WSMエージェントには、ドメインにデプロイされているポリシー・マネージャを自動検出する機能があります。

Oracle WSMエージェントとポリシー・マネージャは、どちらもJTAまたはJMSメッセージ機能を使用しません。MDSベースのポリシー・ストアも、JTAをサポートしません。

外部依存性

Oracle WSM Policy Managerは、次のコンポーネントに依存します。

- ポリシーの格納についてはMDSリポジトリ

- Oracle WSMエージェントは、Oracle WSMポリシー・マネージャにのみ依存します。

Oracle WSMが適切に起動し、実行されるためには、どちらのコンポーネントも使用可能である必要があります。

5.8.1.2 Oracle WSMの起動とシャットダウンのライフサイクル

Oracle WSMの起動ライフサイクルには、Oracle WSMの次の主要コンポーネントが関係します。

- Oracle WSM Policy Manager

- Oracle WSMエージェント

ポリシー・マネージャは、ステートレス・アプリケーションであり、キャッシュは一切行いません。ポリシー・マネージャがデプロイされている管理対象サーバーの起動時に実行される、アプリケーション・レベルの特別な起動シーケンスはありません。ポリシー・マネージャは、MDSリポジトリと通信してポリシーを取得します。MDSリポジトリをOracle RACデータベースに格納すると、MDSの高可用性を実現できます。

エージェントが構成されている管理対象サーバーが起動すると、エージェントは、ポリシー・マネージャに接続して、最新リビジョンのポリシーを取得します。ポリシーが正常に取得されると、ポリシーの変更がダウンロードされてキャッシュされます。エージェントが起動して実行されると、構成可能な間隔に基づいて定期的にキャッシュのリフレッシュが試行されます。デフォルトの間隔は1分です。

Oracle WSMエージェントは、T3(sslが有効な場合はT3s)プロトコル上でのEJBの呼出しによってポリシー・マネージャと通信します。ポリシー・マネージャが別のノードにデプロイされており、一部のノードのSSLが有効で他のノードのSSLが有効でない場合、エージェントはSSL接続されているノードのみと通信します。

Oracle WSMエージェントの接続先ポリシー・マネージャが使用できなくなると、基盤となるインフラストラクチャは、クラスタ内の他の場所で実行されている別のポリシー・マネージャのインスタンスに自動的に接続します。これは、Oracle WebLogicのEJBクラスタリングによって実現されます。

高可用性シナリオでは、Oracle WSMアプリケーションのターゲットが複数のノードに設定される場合、ターゲット設定は、個々の管理対象サーバーではなく、クラスタに対して行われる必要があります。

管理対象サーバーにWebサービスがデプロイされており、これがOracle WSMによって保護されている場合、Oracle WSMエージェントは起動時にいずれのポリシー・マネージャとも通信できず、Webサービスの呼出しが失敗します。

5.8.1.3 Oracle WSMのリクエスト・フロー

保護されているWebサービスがクライアント・アプリケーションからアクセスされたときに、Oracle WSMエージェントはポリシー・キャッシュに問い合せて、アプリケーション・ポリシーを施行します。リクエストの認証、暗号化、復号化、認可またはログは、ポリシーに基づいて行われます。これらの操作のいずれについても、ポリシー・マネージャに接続しません。Oracle WSMによって保護された新しいWebサービスがデプロイされたり、既存のWebサービスに新しいポリシーがアタッチされたなどの構成変更がないかぎり、ポリシー・マネージャの実行時の可用性がOracle WSMエージェントの機能に影響することはありません。このような構成の変更があった場合、Oracle WSMエージェントは、ポリシー・マネージャに接続して、適切なポリシーを取得する必要があります。初期起動後に接続できない場合は、キャッシュされているポリシーに基づいて動作し続けます。

5.8.1.4 Oracle WSMの構成アーティファクト

Oracle WSMエージェントの構成は、policy-accessor-config.xmlに格納されています。このファイルは、DOMAIN_HOME/config/fmwconfigディレクトリにあります。この構成ファイルでは、次のことを指定できます。

- ポリシー・マネージャのURL(構成されている場合)。

- キャッシュ・リフレッシュ間隔。

- 時間誤差(クライアントとサーバーのシステム・クロックの誤差を許容します)。

これらのオプションは、Oracle Enterprise Manager Fusion Middleware Controlからでも使用でき、Oracle WSMエージェントのインストールごとに固有です。

MDSリポジトリの場所のデータ・ソースやアプリケーションのターゲット指定など、コンテナ・レベルの他の構成オプションは、Oracle WebLogic Serverのドメイン構成の一部として保持され、Oracle WebLogic Serverのコア・インフラストラクチャにより、Oracle WebLogic Serverのクラスタ上で同期化されます。

5.8.2 Oracle WSMの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-5は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャの2ノード・クラスタが実行されている様子を示しています。Oracle WSMは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。次の高可用性の特性は、Oracle WSMの高可用性デプロイメントに固有のものです。

- Oracle WSMポリシー・マネージャとOracle WSMエージェントは、WLS_SOA_INFRAにデプロイされます。Oracle WSMエージェントにデプロイされるカスタムWebサービスの保護が必要な場合には、Oracle WSMエージェントをすべてのカスタムWLSクラスタで使用できます。

- Oracle WSMポリシー・マネージャとOracle WSMエージェントは、WebLogic Serverクラスタの一部であるWebLogic Serverインフラストラクチャの管理対象サーバーで実行されます。WebLogic Serverクラスタは、Oracle SOAサービス・インフラストラクチャ(JDBC)で使用されるWebLogic Serverの共通アーティファクトの構成を同期化します。

- Oracle WSMポリシー・マネージャEJBは、WebLogic Serverクラスタのクラスタリングと高可用性の機能を利用します。

- Oracle WSMポリシー・マネージャのクラスタ内のインスタンスは、すべて同一のMDSリポジトリを指します。

- Oracle WSMポリシーが格納されたMDSリポジトリが、データベースの障害から保護するためにOracle RACデータベース内に構成されます。

5.8.2.1 Oracle WSMの障害からの保護および予想される動作

Oracle WSMエージェントは、アプリケーションがデプロイされているサーバーと同じ管理対象サーバーにデプロイされるため、サーバーの再起動や移行によりアプリケーションが使用可能になると同時に、再度エージェントが使用可能になります。以降の2つの項では、ポリシー・マネージャのフェイルオーバーについて説明します。

プロセス障害

Oracle WSMコンポーネントは、WebLogic Serverインフラストラクチャによってプロセス障害から保護されます。

- 管理対象サーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。サーバー全体の移行が構成されており、繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへの管理対象サーバーのサーバー移行を試行します。他のノードでサーバーが再起動されると、Oracle HTTP Serverは、サーバーへの受信したリクエストのルーティングを再開します。第5.8.1.2項「Oracle WSMの起動とシャットダウンのライフサイクル」で説明したように、Oracle WSMエージェントとポリシー・マネージャは、起動ライフサイクルを経て起動されます。

- ポリシー・マネージャを実行する管理対象サーバーが再起動または移行される場合、フェイルオーバーはそのサーバーに接続されているエージェントに透過的に実行されます。ポリシー・マネージャは、基盤となるEJBクラスタリングと、Oracle WebLogic Serverのフェイルオーバー・インフラストラクチャを利用します。

ノード障害

ノードの障害が発生した場合、サーバー全体の移行が構成されていないと、Oracle WSMエージェントはポリシー・マネージャの他のインスタンスに透過的にフェイルオーバーします。

サーバー全体の移行が構成されていると、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。リースのタイムスタンプが検証された後、現在も使用可能なノードのノード・マネージャが、障害が発生した管理対象サーバーで使用されているVIPの移行を試行し、VIPをローカルで再起動します。これは、同一ノードで実行される2つのインスタンスを持つOracle WSMポリシー・マネージャ・アプリケーションに効果的な結果をもたらします。フェイルオーバー・プロセスの詳細は、第3.9項「サーバー全体の移行」を参照してください。このような状況では、Oracle WSMエージェントは、同一ノード上で実行される2つのポリシー・マネージャ・インスタンスに対するロード・バランシングを実行します。

5.8.2.2 Oracle WSMのクラスタワイドの構成変更

ポリシー・マネージャが使用する標準Java EEアーティファクトは、Oracle SOAサービス・インフラストラクチャがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、別のOracle WSMコンポーネントで使用されるライブラリの同期化を制御します。

単一インスタンスの項で説明したように、Oracle WSMインスタンス固有の面に関して、WebLogic Serverドメイン・ディレクトリ(通常、1つのノードに1つのドメイン・ディレクトリ)ごとに、policy-accessor-config.xmlファイルで個別に構成されます。このファイルは、Oracle WebLogic Serverのpackユーティリティを使用するときに作成される.jarファイルに含まれるため、ユーザーがpack/unpackを実行してOracle SOAサービス・インフラストラクチャに高可用性を設定するときに、他のノードに伝播されます。ただし、policy-accessor-config.xmlに対して現在加えている変更は、他のノードに自動的にレプリケートされません。つまり、ポリシー・マネージャのURLやキャッシュ・リフレッシュ間隔を更新したときなどに、各ノードを個別に修正する必要があります。このような修正は、高可用性トポロジにかかわるすべてのドメイン・ディレクトリで、手動で行う必要があります。ユーザーは、policy-accessor -config.xmlファイルを直接編集したり、Oracle Enterprise Manager Fusion Middleware Controlを使用して各管理対象サーバーの構成を変更したりできます。

Oracle WSMエージェントは、デプロイされているOracle WSMポリシー・マネージャを自動検出できます。この動作をオーバーライドして、特定のポリシー・マネージャ・インスタンスをポイントするには、policy-accessor-config.xmlファイルを編集します。

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

Javaオブジェクト・キャッシュ(JOC)は、Oracle WSMを実行しているすべてのサーバー間で構成する必要があります。このローカル・キャッシュは、Oracle WSMのパフォーマンスを向上させるために用意されています。

Oracle WSMを実行するすべてのサーバー間でのJavaオブジェクト・キャッシュの構成の説明は、第F.1項「Javaオブジェクト・キャッシュの構成」を参照してください。

5.8.2.4 MDSリポジトリに対する分散通知の構成

高可用性環境では、MDSリポジトリに対して分散通知を構成することをお薦めします。

MDSリポジトリに対する分散通知の構成の詳細は、付録G「MDSに対する分散通知の構成」を参照してください。

5.9 Oracle User Messaging Serviceと高可用性の概要

この項では、高可用性のためのOracle User Messaging Serviceの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.9.1 Oracle User Messaging Serviceの単一インスタンスの特性

Oracle User Messaging Service(Oracle UMS)は、ユーザーと、デプロイされているアプリケーションとの双方向通信を可能にします。電子メール、IM、SMSおよびText-to-Voiceメッセージなど、多様なチャネルに対応しています。Oracle UMSは、Oracle BPEL PMやOracle WebCenterポータルなどのOracle Fusion Middlewareコンポーネントに統合されます。通常は、Oracle SOAサービス・インフラストラクチャとともにデプロイされます。

Oracle UMSは、次のコンポーネントで構成されています。

- UMSサーバー: Oracle WebLogic Server上で実行されるJava EEアプリケーションです。UMSサーバーは、アプリケーションとユーザー間のメッセージ・フローをオーケストレートします。サーバーは、アウトバウンド・メッセージをクライアント・アプリケーションから適切なドライバにルーティングし、インバウンド・メッセージを適切なクライアント・アプリケーションにルーティングします。また、サーバーは、すでに送信されたメッセージのリポジトリを永続ストアに保持し、すでに送信されたメッセージに配信ステータス情報を関係付けます。

- UMSドライバ: UMSをメッセージ・ゲートウェイに接続し、コンテンツをUMSでサポートされている様々なプロトコルに適応させます。ドライバは、指定のインストールで使用可能なメッセージング・チャネルに応じて、個別にデプロイまたはアンデプロイできます。
UMSドライバは、電子メール、XMPPおよびSMPPなど、外部プロトコルに対して送受信されたコンテンツを適応させます。UMSドライバは、Oracle WebLogic ServerにデプロイされるJava EEアプリケーションでもあります。

- UMSクライアント・アプリケーション: メッセージの送受信のビジネス・ロジックを実装します。UMSクライアント・アプリケーションの例としては、Oracle BPEL PMワークフローの1手順としてメッセージを送信するOracle SOAアプリケーション、またはWebインタフェースからメッセージを送信できるOracle WebCenterポータル: Spacesアプリケーションがあります。
UMSクライアント・アプリケーションは、UMS固有の埋込みEJBモジュールを持つか、標準のWebサービス・クライアントとして対話します。

図5-27は、Oracle UMSの単一インスタンス・アーキテクチャのサービスと依存性を表しています。

図5-27 Oracle User Messaging Serviceの単一インスタンス・アーキテクチャ

「図5-27 Oracle User Messaging Serviceの単一インスタンス・アーキテクチャ」の説明

5.9.1.1 Oracle User Messaging Serviceのコンポーネントの特性

この項では、Oracle UMSのコンポーネントの特性を説明します。

UMSサーバーは、次のものから構成されます。

- JMSキューからメッセージをデキューするメッセージドリブンBean(MDB)

- メッセージング・ビジネス・ロジックを実装するステートレス・セッションBean

- メッセージングWebサービスを実装するJAX-WSサーブレット

- エンドユーザー・メッセージング・プリファレンスを管理するための簡易Oracle ADF Facesユーザー・インタフェースのコンポーネント

UMSドライバには、通常、次のものが含まれます。

- 外部プロトコル・ゲートウェイとのインタフェースを保つためのJCAリソース・アダプタ(EARに埋込み)

- 2つのMDB。1つはインバウンド用、もう1つはアウトバウンド用で、リソース・アダプタとJMSキューとのインタフェースを保ちます。

- VoiceXMLのようなHTTPベース・プロトコルを実装する一部のUMSドライバは、サーブレット・モジュールも持っています。

EJBインタフェースを使用するUMSクライアント・アプリケーションは、クライアント・ビジネス・ロジックで使用されるAPIを提供するステートレス・セッションBean、およびインバウンド・メッセージを非同期で受信するためのMDBを持ちます。

UMSは、JMSに大きく依存します。JMSキューは、クライアントとサーバー間、およびサーバーとドライバ間のコンテンツのバッファにも使用されます。

一般的なメッセージング操作(アウトバウンド・メッセージの送信やインバウンド・メッセージの受信)では、クライアントとサーバー間、およびサーバーとドライバ間の、2つのJMSキューを使用します。

UMSメッセージングの状態は、データベースと永続JMSキューに格納されます。

外部依存性

UMSは、メッセージと構成の状態の保持を外部データベース・リポジトリに依存します。この状態は、クラスタ化されたインスタンス間で共有されます。UMSサーバーは、インストール時にプロビジョニングされたJava EE JDBCデータ・ソースを使用してデータベースにアクセスします。このデータ・ソースは、非XAデータ・ソースです。そのため、UMSは、基盤となるインフラストラクチャのJTA機能に依存しません。

UMSでは、メッセージング・アプリケーション間のメッセージの配信にJMSを使用します。デフォルトでは、ファイル・ベースの永続JMSストアを使用するように構成されるため、そのファイルが存在するストレージ・デバイスに依存します。

5.9.1.2 Oracle User Messaging Serviceの起動とシャットダウンのライフサイクル

Java EEアプリケーションと同様、すべてのUMSコンポーネントは、Oracle WebLogic Serverコンテナにより起動します。

UMSサーバーの起動

UMSサーバーは、起動時に、データベース・リポジトリへの接続を確立するTopLinkセッションを初期化します。その後、UMSサーバーは、Webサービス・エンドポイントでのリスニングを開始します。また、メッセージの送信や配信ステータスの取得などの機能の呼出しにEJBを使用できるようになります。

UMSドライバの起動

UMSドライバがクラスタにデプロイされると、ドライバは登録メッセージをローカルUMSサーバーに送信します。UMSサーバーは、登録情報をデータベースに記録し、クラスタ内のすべてのUMSサーバーで使用できるようにします。すると、UMSサーバーは、クラスタ内のすべてのUMSドライバにメッセージをルーティングできるようになります。こうした状況は、新しいドライバがデプロイされたり、構成の変更後に既存のドライバが再起動されたりしたときに起こります。

通常、UMSドライバは、サーバーの起動時に、ドライバが構成されている外部ゲートウェイへの接続を確立します。たとえば、SMPPやXMPPなどの永続的なソケット・レベルの接続です。また、SMTP接続やIMAP接続のように、各リクエストに対して確立され、切断される接続もあります。その後、ドライバは、UMSサーバーへのリモートEJBコールを実行して、ドライバ自体を登録します。

UMSクライアント・アプリケーションの起動

クライアントがデプロイされている管理対象サーバーが起動すると、通常、EJBクライアントは、リモートEJBコールを実行し、UMSサーバーでドライバ自体を登録します。Webサービス・クライアントには明確な登録メカニズムはありません。

5.9.1.3 Oracle User Messaging Serviceのリクエスト・フロー

UMSクライアントは、UMSサーバーへの連続した短期リクエストを作成します。Webサービス・クライアントは、SOAPまたはHTTPを使用してリクエストを作成します。EJBクライアントは、JMSを使用した対話および管理の初期化と構成を目的とした、サーバーへのリモートEJBコールを実行します。

初期起動と登録の後のUMSのリクエスト・フローは、次のように分類できます。

- アウトバウンド・メッセージング: アウトバウンド・メッセージの場合、クライアント・アプリケーションは、ユーザーにメッセージを送信します。クライアント・アプリケーションは、UMSサーバーに対してWebサービス・リクエストを送るか、UMSサーバーの送信JMSキューにメッセージをエンキューします。UMSサーバーは、リクエストを受信し、メッセージの状態を記録して、適切なドライバを選択します。UMSサーバーは、別のアウトバウンドJMSキューにメッセージをエンキューします。対応するドライバは、アウトバウンド・キューをリスニングし、メッセージをデキューして、所定のプロトコルに適した形式に変換し、これを外部ゲートウェイ(SMTPサーバーまたはIMゲートウェイなど)に配信します。

- インバウンド・メッセージング: インバウンド・メッセージの場合、エンド・ユーザーは、クライアント・アプリケーションにメッセージを返信したいと考えます。ユーザーは、IMクライアントや電話などのデバイスからメッセージを送信します。メッセージは、外部ゲートウェイからドライバに渡されます。ドライバは、メッセージをUMS形式に適応させて、JMSキューにエンキューします。サーバーは、JMSキューからメッセージをデキューし、メッセージの状態を記録して、アプリケーションの適切なインバウンドJMSキューにメッセージをエンキューします。この後、クライアント・アプリケーションは、メッセージをデキューし、必要に応じて処理を実行します。

5.9.1.4 Oracle User Messaging Serviceの構成アーティファクト

UMSサーバーとUMSドライバは、それぞれのXML構成ファイルを持ちます。このファイルは、構成Mbeanのアーティファクトであり、Oracle Fusion MiddlewareのJMXフレームワークを使用して実装されます。構成は、Oracle Enterprise Manager Fusion Middleware Controlを使用して変更できます。

図5-28 Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle User Messaging Serviceの構成

「図5-28 Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle User Messaging Serviceの構成」の説明

すべてのUMSコンポーネントでは、標準のJava EEデプロイメント・ディスクリプタとOracle WebLogic固有のディスクリプタを使用して、Java EEコンポーネントを構成します。これらのディスクリプタは、管理コンソールやWLSTなどの標準Oracle WebLogicツールを使用して構成できます。詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』のUMS管理に関する項を参照してください。

Oracle SOA Suiteをクラスタ環境で使用している場合、あるノードの構成プロパティをOracle Enterprise Managerで変更したときには、その変更がすべてのノードに適用される必要があります。構成プロパティは、Oracle Enterprise Managerで、「SOAインフラストラクチャ」メニューの次のオプションを使用して設定します。

「管理」→「システムMBeanブラウザ」

「SOA管理」→任意のプロパティを選択

5.9.2 Oracle User Messaging Serviceの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

Oracle SOAサービス・インフラストラクチャの2ノード高可用性の特性の説明は、第5.2.2項「SOAサービス・インフラストラクチャの高可用性アーキテクチャとフェイルオーバーに関する考慮事項」を参照してください。図5-5は、2つのWebLogic ServerでOracle SOAサービス・インフラストラクチャのクラスタが実行されている様子を示しています。Oracle User Messaging Serviceは、Oracle SOAサービス・インフラストラクチャのコンポジット・アプリケーションの一部としてデプロイされます。次の高可用性の特性は、Oracle User Messaging Serviceの高可用性デプロイメントに固有のものです。

- すべてのUMSコンポーネントは、Oracle WebLogic Serverクラスタの一部であるOracle WebLogic Serviceインフラストラクチャの管理対象サーバーにデプロイされます。Oracle WebLogic Serverクラスタは、JDBCデータ・ソースなど、UMSで使用されるOracle WebLogic Serverの共通アーティファクトの構成を同期化します。

- Oracle UMSコンポーネントは、すべてステートレスです。

- UMSのサーバーおよびクライアントのステートレスEJBは、Oracle WebLogic Serverクラスタのクラスタリングと高可用性の機能を利用します。

- UMSサーバーは、永続記憶域に関して、共有データベース・リポジトリに依存します。

- UMSは、クラスタ・ノード間のロード・バランシングと可用性に関して、JMS分散宛先に依存します。また、障害の発生時には、別のJMSサーバーにフェイルオーバーするために、JMSコネクション・ファクトリの機能に依存します。

- ユーザー・メッセージング・プリファレンスのユーザー・インタフェースでは、セッション振分けは必要ありません。基本ロード・バランシングを使用することで、使用可能な状態に保たれます。セッションの状態はすべて、データベースに永続的に保持され、クラスタ化されたインスタンスにより共有されるため、セッション・ルーティング要件は特にありません。

- UMSは、グローバル・トランザクションにはまったく関与しません。

- UMSでは、GridLinkデータ・ソースまたはマルチ・データ・ソースを使用して、バックエンドOracle RACデータベースに接続します。

5.9.2.1 Oracle User Messaging Serviceの障害からの保護および予想される動作

通常、Oracle UMSは、Oracle SOAサービス・インフラストラクチャと同じ管理対象サーバーにデプロイされます。Oracle SOAサービス・インフラストラクチャは、Oracle WebLogic Serverのサーバー全体の移行を使用して、プロセスやノードの障害から保護されます。サーバー全体の移行では、JMS使用時のフェイルオーバー機能も提供されます。

Oracle UMSの障害からの保護および予想される動作の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。

プロセス障害

この項では、Oracle User Messaging Serviceの高可用性構成のプロセス障害に固有の考慮事項について説明します。

- 障害が発生した場合、ノード・マネージャはこのサーバーの再起動をローカルで試行します。

- Oracle UMSコンポーネントのデプロイ先のOracle WebLogic Server管理対象サーバーに対してサーバー全体の移行が構成されており、再起動の回数がしき値を超えた場合、Oracle WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへの管理対象サーバーの移行を試行します。前述のように、サーバーの移行が正常に完了すると、UMSサーバーとUMSドライバは、起動時に、起動サイクルを経てドライバを登録します。ドライバの登録は依存性のない操作であるため、使用可能な他のインスタンスにはまったく影響しません。サーバーの移行の詳細は、第3章「WebLogic Serverの高可用性」を参照してください。

- 管理対象サーバー内のUMS JMSサーバーは、再起動時に(同じノードまたは別のノードで)、メッセージの作成、およびJMSストアのメッセージの使用を開始します。

- UMSサーバーとUMSドライバを実行する管理対象サーバーが再起動または移行される場合、フェイルオーバーは接続されているUMSクライアントに透過的に実行されます。フェイルオーバーが透過的に実行されるのは、UMSコンポーネントがステートレスであるためです。サーバーの再起動が完了すると、Webサーバーは、Webサービス・クライアントに対して、サーバーへのリクエストのルーティングを開始します。同様に、EJBクライアントは、サーバーが使用可能であることを認識して、サーバーへのリクエストのルーティングを開始します。これは、Oracle WebLogicのクラスタリング・インフラストラクチャによって実現されます。

ノード障害

Oracle UMSのノード障害の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。

データベース障害

Oracle UMSデータベース障害の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。

外部メッセージ・ゲートウェイ障害からの保護

UMSは、メッセージの配信を試行する前に、メッセージをあらかじめデータベースに永続的に保持しておきます。外部メッセージ・ゲートウェイが使用できなくなると、対応するUMSドライバは、ゲートウェイへの再接続と、データベースに永続的に保持されている未配信のメッセージの配信を定期的に試行します。また、メッセージが配信されない場合、管理者は、Oracle Fusion MiddlewareのEnterprise Managerで、UMSサーバーの「メッセージ・ステータス」ページを使用して手動でメッセージを再送信できます。

5.9.2.2 Oracle User Messaging Serviceのクラスタワイドの構成変更

UMSは、ファイルベースの標準Java EEデプロイメント・ディスクリプタと、標準JMXフレームワークを使用するJMX構成Mbeanで構成されます。変更は、標準のOracle WebLogic Server Mbeanサーバー・メカニズムにより伝播されます。クラスタワイドの構成機能はありません。そのため、クラスタのすべてのメンバーに対して構成の変更を繰り返す必要があります。

UMSは、標準のJava EEアーティファクトを使用します。このアーティファクトは、Oracle UMSがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogic Serverクラスタは、Oracle WebLogic Serveｒドメイン全体にわたる、データ・ソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、Oracle WebLogic Serverクラスタは、デプロイメントと、別のOracle UMSコンポーネントで使用さるライブラリの同期化を制御します。

5.10 Oracle JCAアダプタと高可用性の概要

この項では、高可用性のためのOracle JCAアダプタの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.10.1 Oracle JCAアダプタの単一インスタンスの特性

Oracle JCA Adaptersは、Service Infrastructureが異なるプロトコルを使用してエンドポイントと通信できるようにするJCAバインディング・コンポーネントです。Oracle JCAアダプタは、JCAリソース(RAR)としてデプロイされるものであり、Oracle SOAサービス・インフラストラクチャの一部ではありません。

Oracle JCAアダプタのランタイム・コンポーネントは、特定のバックエンド・アプリケーションのJ2CA 1.5リソース・アダプタです。Oracle JCAアダプタは、Oracle WebLogic ServerのJ2CAコンテナにデプロイされます。Oracle Fusion Middlewareは、JCAバインディング・コンポーネントを介してこれらのJ2CA 1.5アダプタと統合され、このJCAバインディング・コンポーネントによって、Webサービス・メッセージがJ2CA相互作用との間で変換されます。そのため、アダプタは、Oracle WebLogic Serverの基盤となるプラットフォームのスケーラビリティと高可用性を完全に利用できます。

図5-29は、Oracle JCAアダプタの単一インスタンス・アーキテクチャのサービスと依存性を表しています。

図5-29 Oracle JCAアダプタの単一インスタンス・アーキテクチャ

「図5-29 Oracle JCAアダプタの単一インスタンス・アーキテクチャ」の説明

5.10.1.1 Oracle JCAアダプタのコンポーネントのライフサイクル

アダプタのライフサイクルは、Oracle SOAサービス・インフラストラクチャにより制御されます。Oracle JCAアダプタの初期化では、3つの高レベルな手順を実行します。

- デプロイメント: Oracle JCAアダプタは、J2CA 1.5リソース・アダプタ(RARファイル)として、インストール時にOracle Fusion Middlewareと同じOracle WebLogic Serverコンテナ内にデプロイされます。アダプタの物理的デプロイメントには、RARファイルの使用と、基盤となるOracle WebLogic Serverまたは中間層プラットフォームとのコネクタとしてのアダプタの登録が必要になります。RARファイルにはra.xmlファイルが含まれます。このファイルには、Oracle WebLogic Serverとリソース・アダプタとの間の規定に関する宣言情報が記述されています。さらに、RARファイルには、weblogic-ra.xmlファイルが含まれています。これは、リソース・アダプタに関するデプロイメント固有の情報が記述されたデプロイメント・ディスクリプタ・ファイルです。

- ロード: ロードとは、メモリー内リソースの作成と構成済エンドポイントへの接続の確立のプロセスを表します。Oracle JCAアダプタは、J2CA 1.5リソース・アダプタとして物理的にデプロイされますが、論理的デプロイメントでは、weblogic-ra.xmlファイルを編集して、J2CA 1.5リソース・アダプタのコネクション・ファクトリ・エントリを作成する必要があります。このファイルは、リソース・アダプタ用の、Oracle WebLogic Server固有のデプロイメント・ディスクリプタです。これには、リソース・アダプタのデプロイメント・ディスクリプタで指定されているバックエンド・アプリケーション接続情報、使用されるJava Naming and Directory Interface(JNDI)名、接続プーリング・パラメータ、リソース・プリンシパル・マッピング・メカニズムおよび構成など、リソース・アダプタをOracle WebLogic Serverにデプロイするための構成が含まれています。

- アクティブ化: アクティブ化とは、コンポジット内のJCAバインディング・コンポーネント(サービスおよび参照)の開始を表します。リスナーは、コンポジット内のアダプタ構成で参照されるエンドポイントに対して開始されます。

Oracle JCAアダプタの実行時のプロパティ変更

Oracle JCAアダプタは、基盤となるバックエンド操作固有のプロパティをヘッダー・プロパティとして公開して、ビジネス・プロセス内でのこれらの要素の操作を可能にします。基盤となるプロパティは、次のとおりです。

- interactionspecプロパティまたはactivationspecプロパティ: リサイクルする(再アクティブ化する)アダプタ・エンドポイントが必要です。

- エンドポイント・プロパティ: これらのプロパティの変更はアダプタに通知され、エンドポイントを再起動する必要はありません。

5.10.1.2 Oracle JCAアダプタの信頼性とトランザクションの動作

Oracle JCAアダプタは、基盤となるアプリケーション・サーバーのトランザクション・マネージャを利用するJCA 1.5 XA規定に基づいて、グローバル・トランザクションをサポートします。XAトランザクションをサポートするアダプタとして、Oracle Applications、データベース、アドバンスト・キューイング、JMSおよびMQSeries向けOracleアダプタがあります。非トランザクション・アダプタとしては、Oracle File AdapterおよびOracle FTP Adapterがあります。

インバウンド・トランザクション

同期プロセスでは、アダプタによって開始されるグローバル・トランザクションは、メッセージの配信やコンポジットの実行にまでわたります。

非同期サービスのエントリ・ポイントでは、トランザクション・アダプタはインバウンド・メッセージをコンポジットに送信する前に、グローバルJTAトランザクションを開始します。制御がアダプタに戻ると、アダプタは、JTAトランザクションをコミットし、次の一連のアクションを自動作業ユニットとして実行します。

1. 表やキューなどのインバウンド・アダプタ・エンドポイントからのメッセージの削除をコミットします。

2. コンポジット・インスタンスの実行をコミットします。

このプロセスのいずれかが失敗すると、XAで保証されているとおり、これら2つのアクションがロールバックされます。

アウトバウンド・トランザクション

トランザクション・アダプタでは、アウトバウンドJCA相互作用(呼出しアクティビティ)は、コンポジット・インスタンスのグローバルJTAトランザクションの範囲に含まれます。つまり、Oracle JCAアダプタの起動をはじめとするすべてのコンポジット・アクティビティは、グローバル・トランザクションの一部であり、すべてのアクティビティがコミットされ、またエラー発生時にはロールバックされます。したがって、インバウンド・アダプタとアウトバウンド・アダプタの両方がトランザクション・アダプタであり、XAグローバル・トランザクションをサポートする接続ファクトリが構成されている場合は、メッセージが必ず1回配信されることが保証されます。

非トランザクション

Oracle File Adapterは、インバウンド・ディレクトリからファイルを選択し、ファイルを処理して、処理済ファイルを出力ディレクトリに送信します。ただし、この処理中にOracle RACバックエンドまたはSOA管理対象サーバーでフェイルオーバーが発生した場合は、Oracle File Adapterの非トランザクション特性によりファイルは2回処理されます。その結果、出力ディレクトリにファイルが重複して存在する場合があります。

5.10.1.3 Oracle JCAアダプタ: 拒否メッセージの処理

Oracle SOAサービス・インフラストラクチャ・メッシュにポストされる前にエラーになったメッセージは、拒否メッセージとして参照されます。たとえば、Oracle File Adapterにより、CSV形式のデータを持つファイルが選択され、NXSDを使用したXML形式への変換が試みられたとします。このとき、トランザクションでなんらかのエラーが発生すると、メッセージが拒否され、ターゲット・コンポジットにポストされません。

拒否メッセージは、すべてペイロードとともにデータベースに格納されます。拒否メッセージの格納先は、次の2つです。

- アダプタ拒否表: 破損メッセージに関連するバインディング・エラーがある場合、メッセージはアダプタ拒否表に格納されます。
拒否メッセージ表をホストするデータベースがオフラインになっている場合、拒否メッセージはバックアップとして一時的にローカル・ファイル・システムに格納され、オンラインに戻って検出されたときに、最終的に再度データベースにロードされます。

- コンポジット・インスタンス障害表: この表は、インスタンス・トラッキングの一部であり、各コンポーネントが障害を検出したときに移入されます。

SOAサービス・インフラストラクチャ・レイヤーによってエラーがスローされた場合のアダプタ・フレームワークの動作は、エラーが再試行可能として指定されているかどうかにより異なります。エラーが再試行可能でない場合、メッセージは拒否メッセージとして処理され、拒否メッセージ表に永続的に保持されます。

拒否ハンドラの構成

拒否ハンドラは、フォルト・ポリシーを使用して、次の手順で定義および構成されます。

1. 拒否メッセージのフォルト・ポリシーをfault-policies.xmlファイルに定義します。このファイルは、composite.xmlとともにOracle JDeveloperプロジェクト・ディレクトリに格納されています。

2. fault-bindings.xmlファイルで、フォルト・ポリシーをコンポジットのサービス・エンドポイントに関連付けます。

3. fault-policies.xmlファイルとfault-bindings.xmlファイルをOracle SOAコンポジット・プロジェクト・ディレクトリにコピーします。

4. Oracle SOAコンポジット・プロジェクトをデプロイします。

再試行の頻度と間隔は、どちらも構成可能です。サービス・エンジンの起動は、再試行可能としてマークできます。クラスタ化された環境でロールバックが実行された場合、その情報を別のインスタンスで取得できます。別のノードがメッセージを取得すると、一意のIDが作成されます。再試行の回数は、コンポジットのbinding.jca要素で構成されます。詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

システム定義の拒否メッセージ・ハンドラ

次のシステム定義のエラー・ハンドラをフォルト・ポリシーで構成できます。

- Webサービス・ハンドラ: 事前定義のWSDLインタフェースは、ターゲット・サービスにより実装される必要があります。

- カスタムJavaハンドラ: 事前定義のJavaインタフェースは、ターゲット・クラスにより実装される必要があります。

- JMSキュー: 拒否メッセージは、適切なコンテキストとペイロードとともに、JMSメッセージとしてキューにエンキューされます。

- ファイル: 拒否メッセージは、適切なコンテキストとペイロードとともにファイル・システムに格納されます。

ペイロードの永続性

拒否メッセージの再発行には、ペイロードの永続性が必要です。ペイロードは、データベースに格納され、Oracle Enterprise Manager Fusion Middleware Controlで表示されます。エラー・ハンドラは、エラーの自動処理時に起動され、起動中にペイロードも受け取ります。データベース内でのエラーのペイロードの永続性は、デフォルトで有効になっています。

5.10.2 Oracle JCAアダプタの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

この項では、Oracle SOAクラスタ上で実行されるOracle JCAアダプタの構成の高可用性に関する考慮事項について説明します。

5.10.2.1 Oracle JCAアダプタの高可用性に関するエラーの処理

この項では、Oracle JCAの高可用性に関するエラーの処理について説明します。

接続エラー

Oracle Applications向けOracle JCAアダプタおよびOracle Adapterは、次の相互作用に関する接続エラーを処理します。

- アウトバウンド相互作用: Oracle Applications向けOracle JCAアダプタおよびOracle Adapterでは、一時接続エラーに関するoracle.tip.adapter.api.exception.PCRetriableResourceException例外が発生します。これらのエラーは、リカバリ可能な接続エラーです。たとえば、データベース・リスナーが起動しない場合に接続エラーとなります。再接続の最大試行回数をfault-policy.xmlファイルで定義できます。再接続の試行に関するパラメータは、このファイルで指定できます。設定された再試行の回数に達すると、fabricInvocationException例外がスローされます。
フォルト処理と再試行のプロパティは、バインディング・レベルの構成の一部として定義されます。バインディング・レベルの再試行が最大回数に達すると、fault-policy.xmlで指定されているポリシーに基づいてフォルトが処理されます。バインディング・プロパティの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

- インバウンド相互作用: Oracle Applications向けOracle JCAアダプタおよびOracle Adapterと、レガシー・アダプタは、イベント受信のためのバックエンド・アプリケーションへの接続に対するポーリング・モデルをサポートします。リカバリ不能な接続障害が発生した場合、アダプタは旧接続をリサイクルし、Oracle SOAサービス・インフラストラクチャにアラートまたは通知を送ります。インバウンド相互作用の接続エラーはログに記録され、管理コンソールで表示できます。

5.10.2.2 Oracle File AdapterとOracle FTP Adapterの高可用性

Oracle File AdapterおよびOracle FTP Adapterは、アクティブ/アクティブ・トポロジを使用した高可用性構成が可能です。クラスタ・ベースの高可用性構成は、インバウンドとアウトバウンドの両方の操作でサポートされています。Oracle File AdapterおよびOracle FTP Adapterでは、XAに対応していないため、最低一回のメッセージの配信のみが保証されます。そのため、サーバー障害からのリカバリ後は、メッセージが重複する可能性があります。

高可用性のための前提条件

Oracle File AdapterとOracle FTP Adapterの高可用性のための前提条件は、次のとおりです。

- クラスタ化された構成では、管理対象サーバー上のインバウンド・アダプタが共有ドライブの同一物理ディレクトリを指す必要があります。

- 接続ファクトリでは、制御ディレクトリに同一の共有フォルダを指定し、それらの名前が一致している必要があります。たとえば、あるコネクション・ファクトリのデプロイメント・ディスクリプタで、controlDirの値が/shared/control_dirとなっている場合は、他のデプロイメント・ディスクリプタの値も同じである必要があります。

Oracle File AdapterおよびOracle FTP Adapterでは、必ず1つのノードのみが分散トポロジ内の特定ファイルを処理するようにする必要があります。データベース表をコーディネータとして使用して、Oracle File AdapterおよびOracle FTP Adapterのインバウンド操作に対する高可用性を確保できます。データベース表をコーディネータとして構成する方法の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

Oracle File AdapterおよびOracle FTP Adapterでは、複数の参照が同一ディレクトリに書き込む場合に、相互に上書きしないようにする必要があります。アウトバウンド操作に対するOracle File AdapterおよびOracle FTP Adapterの高可用性を確保するために、次のロック機能を使用できます。

- データベースmutex

- ユーザー定義mutex

データベースmutexの構成の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

Oracle File AdapterとOracle FTP Adapterの高可用性の構成

クラスタ・ベースの高可用性構成は、インバウンドとアウトバウンドの両方の操作でサポートされています。ただし、次の点を考慮してください。

- インバウンド操作: Oracle File AdapterおよびOracle FTP Adapterでは、必ず1つのノードのみが分散トポロジ内の特定ファイルを処理するようにする必要があります。

- アウトバウンド操作: Oracle File AdapterおよびOracle FTP Adapterでは、複数の参照が同一ディレクトリに書き込む場合に、相互に上書きしないようにする必要があります。

クラスタ化されたトポロジでのこれらの動作を保証するため、データベース・ベースのmutexがコーディネータとして使用されます。

データベースmutexの構成

次の手順を実行して、管理コンソールから、eis/HAFileAdapterに対応するconnection-instance用のOracle File AdapterおよびOracle FTP Adapterのデプロイメント・ディスクリプタを変更し、データベース表をコーディネータとして構成します。

1. 管理コンソールで、「デプロイメントの概要」の「FileAdapter」をクリックします。

2. 「アウトバウンド接続プール」タブをクリックし、「javax.resource.cci.ConnectionFactory」を開いて、構成済接続ファクトリを表示します。

3. 「eis/HAFileAdapter」をクリックします。

4. 接続ファクトリ・プロパティを更新します。

接続ファクトリを使用するためのアダプタ構成を、次の例のように更新します。

<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>

注意:

接続ファクトリの位置属性は、eis/HAFileAdapterに設定されています。

Oracle File AdapterおよびOracle FTP Adapterの接続ファクトリの新しいパラメータは、次のとおりです。

- controlDir: このパラメータには、制御ファイルを格納するディレクトリ構造を設定します。クラスタ内で複数のOracle WebLogic Serverインスタンスが実行されている場合は、共有場所を設定します。

- inboundDataSource: このパラメータには、jdbc/SOADataSourceを設定します。これは、高可用性に対応するスキーマがあらかじめ作成されているデータ・ソースです。事前に作成されたスキーマは、MW_HOME/ASreleaseSOA/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlにあります。それ以外の場所にスキーマを作成するには、このスクリプトを使用します。別のスキーマを選択する場合は、そのスキーマに応じてinboundDataSourceプロパティを設定します。

- outboundDataSource: このパラメータには、jdbc/SOADataSourceを設定します。これは、高可用性に対応するスキーマがあらかじめ作成されているデータ・ソースです。スキーマの場所については、「inboundDataSource」を参照してください。

- outboundLockTypeForWrite: Oracle Databaseを使用している場合は、このパラメータにoracleを設定します。Oracle File AdapterおよびOracle FTP Adapterは、デフォルトでメモリー内mutexを使用してアウトバウンド書込み操作をロックします。書込み操作を同期化するには、次の値の1つを選択します。

- メモリー: Oracle File AdapterおよびOracle FTP Adapterは、メモリー内mutexを使用してファイル・システムへのアクセスを同期化します。

- oracle: アダプタは、Oracle Databaseシーケンスを使用します。

- db: アダプタは、事前に作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用しているときにかぎり使用します。

- ユーザー定義: アダプタはユーザー定義のmutexを使用します。ユーザー定義のmutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutexを実装し、oracle.tip.adapter.file.mutexという名前の新しいバインディング・プロパテと、アウトバウンド参照用mutexに対して完全修飾されたクラス名の値を構成します。

注意:

大きなペイロードの場合は、次の行を追加して、SOA DataSourceのトランザクション・タイムアウトを増やします。

<xa-set-transaction-timeout>true</xa-set-transaction-timeout>

<xa-transaction-timeout>1000</xa-transaction-timeout>

データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトを増やします。

5.10.2.3 Oracle Databaseアダプタの高可用性

Oracle Databaseアダプタは、アクティブ/アクティブ設定での高可用性をサポートします。アクティブ/アクティブ設定では、インバウンド・データベース・アダプタに対して分散ポーリング技術を使用して、同一データが重複して取得されないようにできます。分散ポーリングのベスト・プラクティスの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』の「データベースのOracle JCAアダプタ」を参照してください。他のアダプタと同様、Oracle Databaseアダプタをアクティブ/パッシブ設定内でのシングルトン動作に対して構成することもできます。これにより、アクティブ/パッシブ設定で動作するパフォーマンスの高いマルチスレッドのインバウンドOracle Databaseアダプタ・インスタンスは、ファンアウト・パターンに従ってクラスタ全体で複数のコンポジット・インスタンスを起動できます。Oracle Databaseアダプタは、データベース障害時や再起動時にも、高可用性機能をサポートします。DBアダプタは、メッセージを損失することなく、再度メッセージを取得します。

フォルト・ポリシーを使用したインバウンド拒否メッセージの処理の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

データベースの障害発生時の再起動

Oracle Databaseアダプタは、データベースが停止した場合にも、メッセージを損失することなく、再度メッセージを取得できます。データを損失しないようにするには、データ・ソースがXA対応であり、Oracle RAC(マルチ・データ・ソース)用に構成されている必要があります。データ・ソースの高可用性構成の詳細は、付録B「推奨されるマルチ・データ・ソース」を参照してください。

5.10.2.4 Oracle JMSアダプタの高可用性

Oracle JMSアダプタは、WLS JMS、MQ SeriesおよびOracle AQをはじめとする複数のプロバイダをサポートします。プロバイダごとに高可用性の側面は異なる可能性があり、基盤となるメッセージング・インフラストラクチャ機能に依存します。たとえば、Oracle AQではXAおよびOracle RAC用に適切に構成されたデータ・ソースが必要です。高可用性のためのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照し、マルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

Oracle JMSアダプタを使用する場合、整合性と信頼性を確保することとトランザクション制御は密接に関連しています。Oracle JMSアダプタは、基盤となるアプリケーション・サーバーのトランザクション・マネージャを利用するJCA 1.5 XA規定に基づいて、グローバル・トランザクションをサポートします。JMSアダプタのコンテキストでは、送信または受信されたメッセージを1つの単位として扱うことで、アプリケーションは、1つのトランザクションで発行および消費のメッセージのグループを調整できます。アプリケーションがトランザクションをコミットすると、そのトランザクション内で受信したすべてのメッセージが、JMSプロバイダにより削除されます。そのトランザクション内で送信したメッセージは、1つの単位としてすべてのJMSコンシューマに配信されます。アプリケーションがトランザクションをロールバックすると、そのトランザクション内で受信したメッセージはメッセージ・システムに戻され、送信したメッセージは破棄されます。

WLS JMSプロバイダを使用する場合、アダプタはXA対応接続ファクトリ(デフォルトのweblogic.jms.XAConnectionFactory)を使用して、XAトランザクションをサポートします。このプロバイダの場合、高可用性の動作は、アダプタによって使用されるキューとトピックの構成およびOracle WebLogic Serverによって提供されるJMSインフラストラクチャに結び付けられています。プロバイダとしてOracle WLS JMSを使用する場合、主に次の2つの側面がJMSアダプタの動作に影響を及ぼします。

- メッセージ再配信

- WebLogic Server分散宛先の使用

次の2つの項では、これらのトピックについて説明します。JMSアダプタの高可用性の構成の詳細は、Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイドのOracle JMSアダプタの高可用性の有効化に関する説明を参照してください。

5.10.2.4.1 メッセージ再配信

メッセージ再配信は、高可用性構成で重要な役割を果たします。WLS JMSでは、一時的な外部条件によりアプリケーションが適切にメッセージを処理できない場合、メッセージの再配信を遅らせることができます。これにより、アプリケーションが現在処理できない有害なメッセージの受信を一時的に抑制できます。再配信遅延時間は、メッセージをロールバックまたはリカバリする際、そのメッセージの再配信を試行するまでメッセージを保留しておく時間です。JMSがすぐにメッセージを再配信する場合、エラー条件が解決されていない可能性があり、アプリケーションは依然としてそのメッセージを処理できない可能性があります。しかし、アプリケーションに対して再配信の遅延が構成されている場合、メッセージがロールバックまたは再配信される際、再配信遅延時間が経過するまでそのメッセージは保留され、その時間が経過すると、そのメッセージは再配信可能になります。セッションにより消費された後にロールバックまたはリカバリされるすべてのメッセージは、ロールバックまたはリカバリの際にそのセッションの再配信遅延時間を受信します。1つのユーザー・トランザクションの一部として複数のセッションにより消費されるメッセージは、個々のメッセージを消費したセッションの関数として異なる再配信遅延時間を受信します。意図的に、または障害の結果として、クライアントによって確認もコミットもされずに残っているメッセージには、再配信遅延時間は割り当てられません。

JMSコンテキストのセッションは、セッション作成時に接続ファクトリから再配信遅延時間を継承します。接続ファクトリのRedeliveryDelay属性の構成には、管理コンソール(「構成」→「デフォルト配信」画面)を使用します。WebLogic JMSにはデフォルトの接続ファクトリが2つ定義されていますが、それらは次のJNDI名を使用して検索できます。

- weblogic.jms.ConnectionFactory

- weblogic.jms.XAConnectionFactory

WLS JMSプロバイダ用に構成されたJMSアダプタでは、デフォルトでweblogic.jms.XAConnectionFactoryが使用されるので、XAConnectionFactoryと同じ再配信設定が使用されます。異なるアダプタで使用する接続ファクトリの構成の詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』の「Oracle JMSアダプタのユースケース」を参照してください。

5.10.2.4.2 WebLogic Server分散宛先の使用

以前のリリースのOracle JMSアダプタでは、一部のタイプのOracle WebLogic共通分散宛先を使用する場合、メッセージが必ず1回配信されることを保証できませんでした。Oracle Fusion Middleware 11gR1では、JMSアダプタにより消費されるWLS JMSレイヤーで様々な拡張が行われ、共通分散宛先のサポートが向上しています。主な拡張として共有ClientID、パーティション分散トピック、共有サブスクリプションがあります。これらの拡張は、スケーラビリティ、高可用性、および様々なシナリオにおける一貫したメッセージ配信を容易にします。

- 共有ClientID: 恒久サブスクライバは、同じClientIDを使用して分散宛先から消費できます。JMS標準では、恒久サブスクリプションから消費するトピック・アプリケーションはClientIDを指定する必要があること、および任意の時点で動作中の複数の接続により同じClientIDが使用されないようにする必要があることが要求されます。この機能は、この制限をオーバーライドします。

- パーティション分散トピック: パーティション分散トピックは、共通分散キューと共通分散トピックの動作を融合した機能です。これにより、メッセージを分散キューと同じように分散トピック・メンバー間でロード・バランシングでき、さらに1つの分散トピック・メンバーに複数のメッセージの受信者(サブスクライバ)を存在させることができます。パーティション分散トピックに対してメッセージを1つパブリッシュすると、そのメッセージは、以前の実装のようにすべてのメンバーによって受信されるのではなく、いずれか1つのメンバーによってのみ受信されます。

- 共有サブスクリプション: 複数のサブスクライバが、必要に応じて、接続のSubscriptionSharingPolicyをSHARABLEに設定することによって、恒久または非恒久の同じサブスクリプションを共有できます。この機能をパーティション・トピックおよび無制限の接続Client-IDポリシーとともに使用すると、同じ分散サブスクリプションを共有するすべてのサブスクライバのうち、1つのサブスクライバのみがトピックに送信された特定の1つのメッセージを受信することが保証されます。同じ分散サブスクリプションを共有するすべてのサブスクライバは、一体となって、そのトピックにパブリッシュされる各メッセージを処理します。

また、11gのWLS JMSインフラストラクチャでは、特定の分散宛先のメンバーの実行時の可用性を通知できる通知ヘルパーが提供されます。分散キューを使用する場合、これらのJMS機能には、JMSアダプタの観点から見て、次の影響があります。

インバウンド - 分散キュー

JMSアダプタは、エンドポイントのアクティブ化の際、自動的にWLS JMSに通知リスナーを登録します。「使用不可」通知を受信した場合、対応するポーラー・スレッドが停止し、必要なクリーンアップが実行されます。同様に、「使用可能」通知を受信した場合、ポーラー・スレッドが開始され、アダプタは新しいメンバーから消費を開始します。

注意:

Oracle BAMのエンタープライズ・メッセージ・ソース(EMS)は、プロデューサのフィード先である分散キューをUDDにロード・バランシングするように構成することはできません。UDDの動作では、各コンシューマが1つの物理宛先に固定されるので、EMS側でメッセージが失われる可能性があります。かわりに、標準宛先であるクラスタワイドのJNDI名でEMSを構成し、プロデューサのフィード先を(クラスタワイドのJNDI名を使用するのではなく、その特定のサーバー・ホストを使用することにより)1つの物理JMSキューに固定します。

アウトバウンド - 分散キュー

分散キュー宛のメッセージを作成する場合、JMSアダプタの動作に変化はありません。メッセージは特定メンバーではなく分散宛先を対象とするMessageProducerを作成することによって作成されるので、「使用可能」/「使用不可」/「障害」の通知は、アウトバウンド・アダプタ参照の動作には影響を及ぼしません。

分散トピックを使用する場合、これらのJMS機能には、次の影響があります。

インバウンド - 分散トピック

JMSアダプタは、エンドポイントのアクティブ化の際、自動的にWLS JMSに通知リスナーを登録します。「使用不可」通知を受信した場合、対応するポーラー・スレッドが停止し、必要なクリーンアップが実行されます。同様に、「使用可能」通知を受信した場合、ポーラー・スレッドが開始され、アダプタは新しいメンバーから消費を開始します。恒久サブスクリプションは、非分散トピック・シナリオの場合と同様に保持されます。アダプタは、エンドポイントの非アクティブ化の際、通知リスナーを登録解除します。分散トピックに到着するメッセージは、使用する様々な設定および使用中の分散宛先のタイプに応じて、次の説明のように処理されます。

- アプリケーションごとにメッセージを1つ処理: 各メッセージは、必ず1回処理されます(重複して処理されることはありません)。パーティション分散トピックを使用すること、および無制限ClientIDと共有サブスクリプション・ポリシー(これらはデフォルト設定)を使用するようにJMSアダプタを構成することをお薦めします。このシナリオでは、クライアントIDとサブスクリプション名はすべて同一であり、各アダプタ・インスタンスはすべてのメンバーに対してサブスクリプションを作成します。名前は一意であり、サーバーの再起動の前後で変化しません。アダプタの接続インスタンス(ローカル・クラスタのweblogic-ra.xml)に、固有のClientIDを構成する必要があります。

<property>
<name>FactoryProperties</name>
<value>ClientID=SOAClient1;</value>
</property>

レプリケートされた分散トピックを使用する場合も、アプリケーションごとにメッセージを1つ処理するように強制できます。そのために、無制限ClientIDと共有サブスクリプション・ポリシー(デフォルト設定)を使用するようにJMSアダプタを構成する必要があります。また、アクティブ化仕様を定義する際に、メッセージ・セレクタ(NOT JMS_WL_DDForwarded)を指定する必要があります。このタイプの構成は非常に効率が悪く、お薦めしません。なぜなら、この構成ではメッセージがすべてのコンシューマに配布されますが、コンシューマ側で拒否が発生するからです。

- クラスタ内のアダプタ・エンドポイント・インスタンスごとにメッセージを1つ処理: このシナリオでは、ClientIDまたはサブスクリプション名のどちらかが、アダプタ・インスタンスごとに一意です。また、名前の一意な部分は、サーバーの再起動の前後で変化しません。このタイプの構成は、レプリケート・トピックまたはパーティション・トピックの両方を使用することにより実現可能です。
パーティション分散トピックの場合、無制限のClientIDと共有サブスクリプション・ポリシーを使用するようにJMSアダプタを構成(すなわちSubscriptionSharingPolicyプロパティをSHARABLEに設定)します。これはデフォルト設定です。また、サブスクリプション名が一意であることを保証するために、TopicMessageDistributionAllプロパティをtrueに設定します(デフォルト値はfalse)。このプロパティは、weblogic-ra.xmlで接続インスタンスのFactoryPropertiesプロパティを設定することによって定義できます。使用例(weblogic-ra.xmlの接続インスタンスのスニペット)を次に示します。

<property>
<name>FactoryProperties</name>
<value>ClientID=SOACLient2; TopicMessageDistributionAll=true</value>
</property>

レプリケート分散トピックの場合、無制限のClientIDと共有サブスクリプション・ポリシーを使用するようにJMSアダプタを構成(すなわちSubscriptionSharingPolicyプロパティをSHARABLEに設定)します。これはデフォルト設定です。パーティション分散トピックの場合と同じように、サブスクリプション名が一意であることを保証するために、アダプタのTopicMessageDistributionAllプロパティをtrueに設定する必要があります(デフォルト値はfalse)。このプロパティは、weblogic-ra.xmlで接続インスタンスのFactoryPropertiesプロパティを設定することによって定義できます。使用例(ローカル・クラスタのweblogic-ra.xmlの接続インスタンスのスニペット)を上に示します。

レプリケート分散トピックでアダプタ・エンドポイントごとにメッセージを1つ処理することを保証するには、次の.jcaファイルの例に示すように、アクティブ化仕様を定義する際にメッセージ・セレクタNOT JMS_WL_DDForwardedを使用する必要があります。

<activation-spec className="oracle.tip.adapter.jms.inbound.JmsConsumeActivationSpec">
<property name="DestinationName" value="jms/DemoInTopic"/>
<property name="UseMessageListener" value="false"/>
<property name="DurableSubscriber" value="dsub1"/>
<property name="MessageSelector" value="NOT JMS_WL_DDForwarded"/>
<property name="PayloadType" value="TextMessage"/>
</activation-spec>

ただし、この構成は非常に効率が悪く、メッセージがすべてのコンシューマに配布されるものの、コンシューマ側で拒否が発生するため、お薦めしません。パフォーマンスを向上するには、パーティション分散トピックを使用します。

アウトバウンド - 分散トピック

分散トピック宛のメッセージを作成する場合、アダプタの動作に変化はありません。「使用可能」/「使用不可」/「障害」の通知は、アウトバウンド・アダプタ参照の処理には影響しません。メッセージは特定メンバーではなく分散宛先を対象とするMessageProducerを作成することによって作成されます。

注意:

Oracle BAMでは、恒久分散トピックはサポートされていませんが、非恒久(一時)分散トピックはサポートされています。

5.10.2.5 Oracle JCAアダプタのログ・ファイルの場所

Oracle JCAアダプタのログは、次のようにして表示できます。

Oracleアプリケーション向けOracle JCAアダプタおよびOracle Adapter: アウトバウンドとインバウンドの両方の相互作用で、ログ・ファイルはsoa-diagnostic.logファイルにリダイレクトされます。server-soa管理対象サーバーにデプロイされるOracle SOA Suiteのログ・ファイルは、次の場所に格納されます。

MW_HOME/user_projects/domains/domain_name/servers/server-soa/logs/soa-diagnostic.log

パッケージ・アプリケーション・アダプタ: これらのアダプタは、J2CA 1.5標準に準拠していないため、LogManagerインタフェースを実装しません。そのため、OPMN管理コンポーネントでは、ログ出力は次の場所にリダイレクトされます。

ORACLE_INSTANCE\diagnostics\logs\component_type\component_name

アウトバウンド相互作用では、ログは同じ場所に送られます。これに対して、インバウンド相互作用では、ログはsoa-diagnostic.logにリダイレクトされます。

レガシー・アダプタ: レガシー・アダプタは、J2CAリソース・アダプタとOracle Connectで構成され、Oracle Connectはメインフレーム・アプリケーションおよびデータ・ストアと通信するためのネイティブ・アダプタで構成されます。Oracle Connectのログは、Oracle Studioを使用して表示できます。Oracle Studioは、メインフレーム・アダプタのデザインタイム・ツールであり、Oracle Connectの管理ツールです。Oracle Connectは、デーモン・ログ、ワークスペース・ログ、サーバー・プロセス・ログなど、様々なタイプのログを生成します。

5.11 Oracle Business Activity Monitoringと高可用性の概要

この項では、高可用性のためのOracle BAMの構成で検討する必要のある問題や考慮する必要のある事項を紹介します。

5.11.1 Oracle Business Activity Monitoringの単一インスタンスの特性

Oracle BAMは、企業のビジネス・サービスおよびビジネス・プロセスを監視するツールを提供します。これにより、市場の指標を実際のビジネス・プロセスと相関させることや、ビジネス・プロセスをすばやく変更したり、ビジネス環境の変化に応じて修正を加えたりすることが可能になります。Oracle Business Activity Monitoring(Oracle BAM)は、リアルタイムのデータ・フローを表示し、特定の状況においてアラートを送信するルールを定義するダッシュボードの作成に必要なツールやランタイム・サービスを提供します。

図5-30は、Oracle BAMインスタンスの特徴である主要サービスと依存性を表しています。

図5-30 Oracle Business Activity Monitoringの単一インスタンス・アーキテクチャ

「図5-30 Oracle Business Activity Monitoringの単一インスタンス・アーキテクチャ」の説明

5.11.1.1 Oracle Business Activity Monitoringのコンポーネントの特性

Oracle BAMは、次のコンポーネントで構成されます。

- Oracle BAM Server: 様々なデータ・ソースからの受信データを処理するランタイム・コンポーネントのセットです。Oracle BAMコンポーネントは、ユーザーにアラートを送信し、それらのアラートに対して構成されている必要なアクションをトリガーするための条件の評価にも使用されます。Oracle BAM Serverの主要コンポーネントは、次のとおりです。

- アクティブ・データ・キャッシュは、リアルタイム・ソリューションで大容量データを処理することを目的として、設計および最適化されています。データへのアクセスおよびデータの配信を迅速化するために、データのリアルタイム・ビューを保持しています。アクティブ・データ・キャッシュへのデータ・フィードは、データ・ウェアハウスの情報からトランザクション・フィードおよび他企業のソースまでの、ビジネス・データ・ソースの組合せです。Oracle BAMに統合されている様々なデータ・ストリーム・テクノロジにより、データが変更されたときに、この情報が連続したストリームでアクティブ・データ・キャッシュに送られます。
アクティブ・データ・キャッシュは、データ・オブジェクト、ビュー・セットおよびアクティブ・ビュー・セットをホストおよび実行します。データ・オブジェクトへのトランザクション(挿入、更新および削除)を受け取ると、これらのデータ・オブジェクトが、参照によってリンクされている他のデータ・オブジェクトに通知します。また、これらのデータ・オブジェクトを監視しているアクティブ・ビュー・セットに変更が通知され、アクティブ・データが作成されます。

- イベント・エンジン: イベント・エンジンは、複雑なデータ条件を監視して、指定のルールを実装します。ルールには、イベントに関連付けられている一連の条件とアクションを含めることができます。イベント・エンジンは、アクティブ・データ・キャッシュ内の情報の特定条件を継続的に監視し、関連付けられているルールに定義されている関連アクションを実行します。
イベント・エンジンは、日付、時刻またはデータ変更に基づいてイベントを追跡します。イベント・エンジンの設計では、サテライトの概念が採用されています。サテライトの概念では、4つの異なる体系(サテライト)があり、それによってイベント句を登録でき、その内部でイベント句を追跡できます。

- レポート・キャッシュは、アクティブ・データ・キャッシュのビュー・セット・スナップショットをメモリー内に保持しておかなくても済むようにするためのものです。レポート・キャッシュは、Oracle BAM Webアプリケーションのコンポーネント・セット内のレポート・サーバーのアクティブ・データ・キャッシュにあるビュー・セットとアクティブ・ビュー・セットを開きます。次に、スナップショット(チャンク単位)とアクティブ・データを、レポート・サーバーに送信する前にキャッシュします。これにより、スナップショットへのランダム・アクセスと、インターネット接続の切断からのリカバリが可能になります。また、レポート・キャッシュは、ステートレスなレポート・サーバーを実現し、アクティブ・データ・キャッシュを使用してビュー・セットの共有をサポートします。

- リアルタイム・データ・ストリーミング・クライアント: Oracle BAMシステム・クライアントでは、様々なタイプのプロトコルとAPIを使用してOracle BAM Serverにデータを送ることができます。Oracle BAM Serverへのデータの送信で使用可能なメカニズムは、次のとおりです。

- Oracle BAMアダプタは、JCA準拠のアダプタで、Java EEアプリケーションがOracle BAM Serverにデータを送信する際に使用できます。

- エンタープライズ・メッセージ・ソースは、アプリケーションが、メッセージをOracle BAMデータ・オブジェクトに直接マッピングすることにより、Oracle BAM Serverに直接Java Message Service(JMS)接続できるようにするために使用します。Oracle BAM Serverは、JMSベースのメッセージ・キューやトピックから、データを直接読み取ることができます。このオプションにより、保証されたメッセージングが可能になります。
エンタープライズ・メッセージ・ソースを使用するOracle BAMの高可用性環境では、エンタープライズ・メッセージ・ソースのプロパティ「BAMサーバーの起動時に起動」を「はい」に設定します。

フェイルオーバー時にメッセージを損失しないように、エンタープライズ・メッセージ・ソースでは「永続サブスクライバ名」を設定する必要があります。

- Oracle Data Integratorは、Oracle BAMで正確なデータ変換を実行するために使用されるETLツールです。Oracle BAM ServerはODIテクノロジ(DB2、SQL ServerなどもODIテクノロジです)として実装されており、Oracle BAMにはODIナレッジ・モジュールが搭載されています。ODIでは、このモジュールにより、Oracle BAM Server上ですべての操作を実行して、チェンジ・データ・キャプチャをはじめとする様々な方法でのデータの読取りおよび書込みを容易化します。

- WebサービスAPIは、リモート・クライアントから直接Oracle BAMデータ・オブジェクトと対話します。

- Oracle BAM Webアプリケーション: Oracle BAMデータを表示するためのWebユーザー・インタフェース(Java EE Webアプリケーション)です。Oracle BAM Webアプリケーションでは、データ・モデルの構築や、ダッシュボードおよびアラートの作成も可能です。Oracle BAM Webアプリケーションは、レポートを作成したり、BAMユーザー・インタフェースへのアクセス権があるユーザーを管理したりするための、ブラウザ・ベースのインタフェースです。レポート・サーバーは、Webアプリケーションの一部として、アクティブ・データ・キャッシュから取得したデータ・セットにレポート定義を適用して、ブラウザに表示します。

- ICommandは、アクティブ・データ・キャッシュ内のデータを管理するためのコマンドライン・インタフェースです。これは、アクティブ・データ・キャッシュのアイテムをエクスポート、インポート、名前変更、クリアおよび削除するためのコマンド・セットを提供します。

BAMアプリケーションは、他のOracle SOA Suiteコンポーネントから独立して実行されます。Oracle BAM Webアプリケーションは、BAM Serverとともにデプロイされます。Oracle BAM Serverは、サービスを実装してデータベースに情報を永続的に保持するために、EJBとDAOを使用します。EJBは、すべてステートレスです。ただし、Oracle BAM Serverはシングルトンであり、送られてきたデータを保持して、それをWebアプリケーション・レポートにプッシュするために、アクティブなOracle BAM Serverが1つのみ使用されます。Oracle BAM Serverを障害から保護するために、Oracle WebLogic Serverの移行機能が使用されます。Oracle BAM Serverは、JMSを集中的に使用します。ただし、Oracle BAM JMSキューはすべて内部的なものであり、高可用性構成で構成する必要はありません。フェイルオーバーが発生した場合、新しいアクティブOracle BAMインスタンスでキューが再作成されます。

Oracle BAM Webアプリケーション・モジュールは、使用可能なOracle BAM Serverに接続して、完全なアクティブ/アクティブ・モードで実行可能です。リモート・コンシューマに情報を提供するEJBにアクセスするための情報は、RMIプロトコルによって取得されます。レポートのセッションIDや、システムにアクセスするユーザーを管理するReports Serverを除き、Oracle BAM Webアプリケーションはステートレスです。そのためには、Oracle BAM Webアプリケーションが実行されるWebLogic管理対象サーバーに対してセッション・レプリケーションを有効にする必要があります。

Oracle BAMでのEJBおよびスレッドにより実行される処理は、非トランザクションであるため、Oracle WebLogic Serverの特別なトランザクション・ログ構成は必要ありません。同時に、Oracle BAMはデータベースを集中的に使用するため、データベースの障害に備えたOracle BAMのデータベース・アクセスが重要となります。そのため、第5.15項「Oracle BAMの高可用性の構成」の説明に従って、Oracle BAMデータ・ソースにGridLinkデータ・ソースまたはマルチ・データ・ソースを構成する必要があります。

外部依存性

Oracle BAMエンジン・システムは、Oracle BAMデータおよびレポート・メタデータに関して、Oracle BAMデータベース(Oracle BAMスキーマを含む)にのみ依存します。Oracle BAMシステムが適切に起動し、実行されるためには、データベースが使用可能である必要があります。

5.11.1.2 Oracle Business Activity Monitoringの起動とシャットダウンのライフサイクル

図5-31に示すように、WebLogic Serverが起動するときに、Oracle BAM Serverアプリケーションが初期化されます。アクティブ・データ・キャッシュは、起動時にすべてのデータをリポジトリからロードします。レポート・キャッシュは、使用可能なシステムに必要なデータで初期化されます。イベント・エンジンは、データの分析と通知の準備を開始します。Oracle BAM Webアプリケーションは、起動時にOracle BAM Serverのアドレスで構成されます。Oracle BAM Webアプリケーションは、起動時にOracle BAM Serverのアクティブ・データ・キャッシュに接続し、Reports Serverを通じて対応するビューセットを取得します。初期化が終了すると、クライアントからのデータ受信、イベントの呼出し、およびレポートの動的更新が可能になります。

図5-31 Oracle Business Activity Monitoringの起動とシャットダウンのライフサイクル

「図5-31 Oracle Business Activity Monitoringの起動とシャットダウンのライフサイクル」の説明

5.11.1.3 Oracle Business Activity Monitoringのプロセスの起動とシャットダウン

Oracle BAM Serverは、SOAサービス・インフラストラクチャの他のアプリケーションから独立して動作する1つのアプリケーション、すなわちoracle-bamです。Oracle BAMがインストールされている管理対象サーバーで実行されます。また、Oracle BAMがデプロイされているOracle WebLogic管理対象サーバーによってデフォルトで起動されます。管理コンソールを使用して、Oracle BAM Serverのステータスを確認して、これを起動および停止します。アプリケーションの制御に、WebLogic Server WLSTのコマンドラインも使用できます。

図5-32 WebLogic Serverを使用したOracle Business Activity Monitoringの起動とシャットダウン

「図5-32 WebLogic Serverを使用したOracle Business Activity Monitoringの起動とシャットダウン」の説明

Oracle Enterprise Manager Fusion Middleware Controlを使用すると、BAM Serverの多数の操作と構成を行えるだけでなく、ステータスを監視することもできます。Oracle BAMエンジンの監視と制御の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

図5-33 Fusion Middleware Controlを使用したOracle Business Activity Monitoringの起動とシャットダウン

「図5-33 Fusion Middleware Controlを使用したOracle Business Activity Monitoringの起動とシャットダウン」の説明

BAM Webアプリケーションは、デフォルトでBAM Serverと同じ管理対象サーバーにコロケートされて実行されます。たとえば、BAM ServerとBAM Webアプリケーションは、管理コンソールで同一デプロイメントの一部となります。デフォルトでは、これらをBAM Serverと切り離して停止したり管理したりできません。ただし、それぞれを個別のコンポーネントにターゲット指定してWebLogic Serverアプリケーションを処理することは可能です。Oracle WebLogic Administration Consoleを使用すると、Oracle BAMを起動および停止できます。

Oracle Enterprise Manager Fusion Middleware Controlのコンソールを使用すると、BAM Webアプリケーションの多数の操作と構成を行えます。

図5-34 Oracle Enterprise Manager Fusion Middleware Control

「図5-34 Oracle Enterprise Manager Fusion Middleware Control」の説明

注意:

Enterprise ManagerはOracle BAM ServerとOracle BAM Webアプリケーションを個別に起動および停止しますが、停止操作は、実際には両方のコンポーネントに影響します。つまり、Oracle BAM ServerがEnterprise Managerにより停止されると、対応するOracle BAM Webアプリケーションも停止し、その逆も同様です。このことは、起動操作にも当てはまります。

5.11.1.4 Oracle Business Activity Monitoringの構成アーティファクト

Oracle Enterprise Manager Fusion Middleware Controlは、Oracle BAM Serverに関するいくつかの構成オプションを公開します。

図5-35 Oracle Business Activity Monitoringの構成

「図5-35 Oracle Business Activity Monitoringの構成」の説明

Oracle Enterprise Managerにより公開されるプロパティは、BAMServerConfig.xmlとBAMCommonConfig.xmlという2つの異なるファイルの情報が混ざったものです。これらのファイルは、DOMAIN_HOME/servers/BAM_Server_Name/tmp/_WL_user/oracle-bam_11.1.1/yhryfp/APP-INF/classes/configディレクトリにあります(yhryfpは、BAMアプリケーションのデプロイでインストール時に生成されたランダム・ディレクトリであることに注意してください)。これはOracle BAMアプリケーションのデプロイでインストール時に生成されたランダム・ディレクトリです。これらのファイルのプロパティは、Oracle Enterprise Manager Fusion Middleware Controlで公開されるMbeanを使用して変更可能です。Oracle BAM Serverの構成オプションの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』および『Oracle Fusion Middleware Oracle Business Activity Monitoringユーザーズ・ガイド』を参照してください。

同様に、図5-36に示すように、Oracle Enterprise Manager Fusion Middleware Controlによって、Oracle BAM Webアプリケーションに対するいくつかのプロパティが公開されます。

図5-36 Oracle Business Activity Monitoringの構成プロパティ

「図5-36 Oracle Business Activity Monitoringの構成プロパティ」の説明

データ・ソースや永続ストアなど、コンテナ・レベルの構成オプションは、WebLogic Serverドメイン構成の一部として保持され、Oracle WebLogic Serverのコア・インフラストラクチャにより、Oracle WebLogic Serverのクラスタ上で同期化されます。Oracle BAMの構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.11.2 Oracle Business Activity Monitoringの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-37は、2つのOracle WebLogic Serverで2ノードのOracle BAMクラスタが実行されている様子を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。この構成の主要な特性は、次のとおりです。

- Oracle BAM Webアプリケーションは、クラスタ化された2つのWebLogic Serverの管理対象サーバー上で実行されます。WebLogic Serverクラスタは、データ・ソース、永続ストアおよび定義など、Oracle BAM Webアプリケーションで使用されるWebLogic Serverの共通アーティファクトの構成を同期化します。Oracle BAM Serverは、BAM Webアプリケーションが実行されているいずれかのサーバーからターゲット指定されます。Oracle BAM Serverを実行するWebLogic Serverは、1つのみです。

- アーキテクチャは、Oracle WebLogic Serverの移行機能を使用して、Oracle BAM WebアプリケーションとOracle BAM Serverの両方(BAMHOST1内)を実行するOracle WebLogic Serverを障害から保護します。これにより、シングルトンのOracle BAM Serverが保護されます。Oracle BAM Serverが実行されているWebLogic管理対象サーバーは、フェイルオーバーの発生時に別のノードに移行された仮想IPをリスニングします。これは、BAMHOST2内のOracle BAM WebアプリケーションがOracle BAM Serverへの接続に使用するアドレスです。Oracle BAM Serverと、Oracle BAM Webアプリケーションの2つのインスタンスが、BAMHOST2上で実行されるシナリオを考慮し、適切に計画してください。サーバー移行機能の詳細は、第3章「WebLogic Serverの高可用性」を参照してください。

- Oracle BAMのデータベースは、データベースの障害から保護するために、Oracle Real Application Cluster(Oracle RAC)で構成されます。データベース・インスタンスの障害が発生すると、Oracle BAM Serverは、再接続と操作の再試行を適切に実行します。

図5-37 Oracle BAMの高可用性アーキテクチャ

「図5-37 Oracle BAMの高可用性アーキテクチャ」の説明

5.11.2.1 Oracle Business Activity Monitoringの障害からの保護および予想される動作

Oracle BAM ServerとOracle BAM Webアプリケーションは、WebLogic Serverインフラストラクチャによってあらゆるプロセス障害から保護されます。この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。

プロセス障害

Oracle BAM ServerとBAM Webアプリケーションは、WLSインフラストラクチャによってあらゆるプロセス障害から保護されます。この項では、Oracle BAMのプロセス障害に関する考慮事項について説明します。

- WLS_BAMxサーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。これは、構成済の再起動回数のしきい値に基づいてサーバーの再起動を試行します。

- BAM Serverが実行されているWebLogic Serverに関連する障害の場合、繰り返し再起動しても失敗すると、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへのサーバー移行を試行します。クライアントからの処理中のリクエストは、フェイルオーバー時にタイムアウトします。他のノードでサーバーが正常に再起動されると、クライアントが再起動されて、そのサーバーへのルーティングを続行します。Webブラウザで実行中の開かれているレポートについては、BAM Serverと同じ管理対象サーバーで実行されているBAM WebAppsを通じてリクエストが配信されている場合、再接続メッセージがBAM WebAppsレポートに出力されます。他のノードで実行されているBAM WebAppsを通じてリクエストが配信されている場合、メッセージは出力されません。このような状況では、フェイルオーバー時に、失効したデータが表示されることがあります(フェイルオーバーの実行中、またはWebappsからサーバーへの接続の再確立中)。BAMWebAppsサーブレットは、引き続き使用可能であり、BAM Serverが起動するとすぐに再接続します。新しいレポートおよびリクエストについては、VIPが移行されて管理対象サーバーが再起動すると、BAMHOST2内のBAM Webアプリケーションが再接続します。VIP1をリスニングするBAM Webアプリケーションは、サーバー移行が完了すると機能し始めます。このときに、HTTP Serverは、管理対象サーバーへのHTTPリクエストのルーティングを再開します。

- BAM Webアプリケーションのみが実行されているWebLogic Serverに影響のある障害は、BAMシステムには影響しません。他のBAM Webアプリケーション(BAMHOST1で実行)は、引き続き使用可能であり、WebLogic Serverのセッション・レプリケーション・クラスタを使用してセッション情報を保持します。フェイルオーバーは、透過的に実行されます。

- BAM ServerとBAM Webアプリケーションが実行されているoracle-bamアプリケーションは、リソースへのアクセスの失敗、データベースの読取りエラー、またはデータベースが配置されている管理対象サーバーのステータスには関係なく発生する他の問題が原因で停止する場合があります。そのため、Oracle SOAサービス・インフラストラクチャ・アプリケーションによって引き起こされるエラーを管理対象サーバーのログで監視する必要があります。ログ・ファイルの場所の詳細は、第5.2.1.6項「Oracle SOAサービス・インフラストラクチャのログ・ファイルの場所」を参照してください。

- レポートが開かれており、クラスタ内でBAM管理対象サーバーが1つしか起動していず、クラスタ内での追加の管理対象サーバーの起動後に他の操作を何も実行していない場合は、開かれたレポートのフェイルオーバーは正常に終了しません。セッション状態レプリケーションの1回のトリガーでレポートが開かれます。セッション状態レプリケーションは、アクティブ・データの更新ではトリガーされません。

Oracle BAMの高可用性環境では、停止されて再起動されたOracle BAMサーバー上でOracle BAM Active Viewerが実行されていると、サーバーのログに「ビューセットが見つかりません」というエラーが書き込まれます。このエラーは、Oracle BAM Active Viewerの機能には影響しないので無視してかまいません。

ノード障害

SOAHOST2でのノード障害の場合、ノード障害時の動作はプロセス障害のシナリオの場合と同じです。つまり、他のノード内のOracle BAM Webアプリケーションは、引き続き使用可能であり、リクエストを処理できます。セッションは、WebLogic Serverが提供するセッション・レプリケーション・フレームワークによって維持され、他のノードへのフェイルオーバーが透過的に実行されます。

SOAHOST1でのノード障害が発生した場合、使用可能なサーバーによりデータベース・リース・システム内のタイムスタンプが検証された後、サーバーの移行がトリガーされます。フェイルオーバーの実行中には、クライアントはデータをシステムに送信できず、必要に応じて送信を再試行します。サーバーに接続しているOracle BAM Webアプリケーションは、VIPが移行されてサーバーが再起動するまで、再接続を試行します。

データベース障害

Oracle BAMデータベース障害の詳細は、第5.2.2.1項「Oracle SOAサービス・インフラストラクチャの障害からの保護および予想される動作」を参照してください。

5.11.2.2 Oracle Business Activity Monitoringのクラスタワイドの構成変更

Oracle BAM ServerとOracle BAM Webアプリケーションが使用する標準Java EEアーティファクトは、Oracle BAMがインストールされているOracle WebLogicドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソース、永続ストアおよびJMSモジュールなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle BAM WebアプリケーションおよびOracle BAM Serverで使用されるライブラリを同期化する役割を持ちます。

単一インスタンスの項で説明したように、Oracle BAM ServerおよびOracle BAM Webアプリケーションの構成は、DOMAIN_HOME/servers/BAM_Server_Name/tmp/_WL_user/oracle-bam_11.1.1/yhryfp/APP-INF/classes/configディレクトリに保持されます(yhryfpは、BAMアプリケーションのデプロイでインストール時に生成されたランダム・ディレクトリであることに注意してください)。これらのファイル内のプロパティは、Oracle Enterprise Manager Fusion Middleware Controlで公開されるMbeanを使用して変更可能です。MBeanによって公開されるプロパティは、各サーバーに固有のものです。Enterprise Manager固有の画面を通じて公開されるプロパティは、クラスタワイドであり、1つのサーバー上でのみで変更できます。Enterprise ManagerまたはMBeanブラウザのいずれで適用されていても、すべてのプロパティで、Oracle BAMが実行されているOracle WebLogic Serverの再起動が必要です。BAM ServerおよびBAM Webアプリケーションの構成オプションの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』および『Oracle Fusion Middleware Oracle Business Activity Monitoringユーザーズ・ガイド』を参照してください。

高可用性の環境に関連する構成オプションの1つに、クラスタ構成でシステムにより使用されるフロントエンド・ホストを決定するために使用されるアプリケーションURLがあります。このオプションは、レポートおよびアラートのショートカットURLのコピーの作成に使用されます。Oracle BAMの高可用性構成に関連する他のパラメータには、OracleBAM Web構成画面のサーバー名があります。このパラメータは、Oracle Webアプリケーションがアクティブ・データ・キャッシュにアクセスするための接続先のOracle BAM Serverを決めるのに使用されます。

Oracle HTTP Serverによってフロントエンド処理されるSOA高可用性インストールでは、実質的なバックエンド・サーバーのOracle HTTP Serverポートでの監視をお薦めします。すなわち、SOA管理対象サーバーにデプロイされたすべてのコンポーネントがデプロイメントで使用される場合です。HTTP/HTTPSポートをpingし、事前に決められた応答が返されることを予期する単純なHTTPモニターであれば十分です。特定のSOAコンポーネント(B2Bなど)のみを使用している場合は、使用中のコンポーネントの状態を検証するために、管理対象サーバー全体のさらに深いレベルまでチェックするモニターを検討する必要がある場合があります。お使いのロード・バランサでのHTTPモニターの設定について、ロード・バランサのベンダーにご確認ください。

5.11.2.3 BAMクライアントの再試行に関する考慮事項

BAM Serverと通信するOracle BAMクライアントは、再試行可能なメソッドを実行して再試行可能な例外を原因とする障害が発生した場合、そのメソッドを再試行します。再試行可能な例外の代表は、BAM Serverとの通信に障害が発生したことを示す例外(ネットワーク通信例外など)です。BAM Serverの一部のメソッドは、障害発生時に自動的にBAMクライアントによって再試行されます。また、再試行する例外を増やすこともできます。それには、クライアントの構成ファイルの次の構成フィールドに、再試行可能として処理する例外クラス名をカンマで区切ったリストを追加します。

<BamEjbRetryableExceptions></BamEjbRetryableExceptions>

再試行可能な例外に関する他の構成パラメータは次のとおりです。

- <BamEjbRetryCount>180</BamEjbRetryCount>: このパラメータは、getSessionまたは再試行可能なメソッドの呼出しで再試行可能な例外を原因とする障害が発生した場合の再試行回数を構成します。デフォルトは180です。

- <BamEjbRetryInterval>10000</BamEjbRetryInterval>: このパラメータは、再試行の間隔をミリ秒単位で構成します。デフォルトは10000ミリ秒または10秒です。

これらのパラメータは、BAM Serverにアクセスする次のクライアントの構成ファイルに追加できます。

- BAM Server、BAM Web、BAMデータ・コントロール: BamCommonConfig.xml構成ファイル

- ICommand: BAMICommandConfig.xml構成ファイル

- ODI: BAMODIConfig.xml構成ファイル

- BAMアダプタ: BAMAdapterConfig.xml構成ファイル

5.12 Oracle Service Busと高可用性の概要

Oracle Service Busは、SOAライフサイクル管理のために一から構築された、実績あるEnterprise Service Bus(ESB)です。サービスの検出と仲介、サービスの迅速なプロビジョニングとデプロイメント、および管理を実行するための基盤機能を提供します。

図5-38は、Oracle Service Busの高レベルの機能を示します。

図5-38 Oracle Service Busの機能

「図5-38 Oracle Service Busの機能」の説明

Oracle Service Busの機能の詳細は、『Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ』を参照してください。

5.12.1 Oracle Service Busの単一ノードの特性

Oracle Service Busは、Oracle WebLogic Server上で実行されるステートレスJava EEアプリケーションです。

Oracle Service Busでは、次のJava EEテクノロジが使用されています。

- サーブレット: Oracle Service Bus Web Console、Service Busリソース・サーブレット、WSILサーブレット、HTTPプロキシ・サービス

- EJB: 次の目的で使用されます。

- Java EJBプロトコル・プロキシ・サービス。このサービス(別名JEJB)は、プロキシ・サービスをEJBとして公開するために使用されます。

- Service Busトランスポート。このプロトコル(別名SB)は、2つのOracle Service Busサービス間の通信に使用されます。

- Webサービスをテストするためのテスト・コンソール。

- JMS: FTP、SFTP、電子メールおよびファイル転送のインバウンド・メッセージ処理に使用されます。また、Oracle Service Busレポート作成フレームワークおよびWeb Services Reliable Messaging(WS-RM)で使用されます。

- JDBCデータ・ソース: Oracle Service Busは、JMSレポート作成プロバイダに関連付けられているデータベース表のデータ・ソースを定義します。

- JCAアダプタ: Oracle Service Busは、JCAトランスポートを使用して、DB、Oracle Applications、AQ、File、BAM、FTP、SAP、Siebel、PeopleSoftおよびJD Edwardsの各アダプタをサポートします。これらのアダプタでは、SOA Suiteの場合と同じアダプタ実装が使用されています。

Oracle Service Busでは、次の非Java EEコンポーネントも使用されています。

- Configuration Framework: Configuration Frameworkコンポーネントは、Oracle Service BusリソースのCRUD(作成、読取り、更新、削除)機能、リソースとファイルの整合性保護、セッション管理、キャッシュと索引付け、参照整合性および構成伝播を提供します。Oracle WebLogic Server管理サーバーではマスター構成がファイルに格納され、これらのファイルがWebLogicデプロイメント・サービスによって管理対象サーバーに伝播されます。

- Monitoring and Alert Framework: Monitoring Frameworkは、カウンタ(メッセージ・カウンタ、エラー・カウンタ)、間隔(応答または実行の最小/最大/平均時間)およびステータス(エンドポイントの稼働/停止)に基づく統計を定義します。Monitoring Frameworkには、次のサブコンポーネントがあります。

- コレクタ: チェックポイントと呼ばれる1分間隔で統計を収集し、WebLogic永続ストアへの格納およびAggregatorへの送信を行います。コレクタは、クラスタ内の各管理対象サーバーで実行されます。

- Aggregator: クラスタ内の各管理対象サーバーから受信した統計を集計します。Aggregatorは、クラスタ内の1つの管理対象サーバーでのみ実行されるシングルトン・サービスです。

- Retriever: メモリーに格納されている統計を取得します。これは、Aggregatorが存在する管理対象サーバーにのみ存在します。

- Alert Manager: Alert Managerは、集計された統計に基づいてアラートを起動します。これは、Aggregatorが存在する管理対象サーバーにのみ存在します。Aggregatorは、ルールを評価する必要がある集計間隔(サービスまたはアラート・ルールに対して定義)が存在する場合に、集計された統計をAlert Managerにプッシュします。Alert Managerは、Aggregatorとは別のスレッドでトリガーされます。

- Transport SDK: Oracle Service Busにおけるメッセージ処理では、メッセージがシステムに対してどのように入出力されたかは考慮されません。Transport SDKは、Oracle Service Busに対して入出力されるデータのフローを処理するコンポーネントとOracle Service Busとの間を抽象化するレイヤーを提供します。この抽象化レイヤーにより、ユーザーは、固有のトランスポート・プロトコルを処理するための新しいトランスポート・プロバイダを開発できます。トランスポート・プロバイダは、Transport SDKのインタフェースを実装し、Oracle Service Busとメッセージの送受信メカニズムとの間のブリッジを提供します。トランスポート・プロバイダは、トランスポート・エンドポイントのライフサイクルと実行時動作を管理します。エンドポイントは、メッセージの発行元またはターゲットに指定されるリソースです。

- Message Flow Engine: Message Flow Engineは、メッセージ・フロー・デザイナにより構成されたアクションを使用して、メッセージ・フロー・ロジックを実行する機能を提供します。

- Split-Join Engine: Split-Join Engineは、Split-Joinで指定されているロジックを実行する機能を提供します。これは、高性能なメッセージ処理をパラレルにメモリー内で実行するために使用されます。

図5-39は、Oracle Service Busとその機能サブシステムを示す高レベルのアーキテクチャ図です。

図5-39 Oracle Service Busの単一インスタンス・アーキテクチャ

「図5-39 Oracle Service Busの単一インスタンス・アーキテクチャ」の説明

Oracle Service Busが高可用性構成でデプロイされている場合、AggregatorコンポーネントとAlert Managerコンポーネントは、クラスタ内の1つのホストにのみデプロイされるシングルトンである必要があります。

Transport SDKやレポート作成フレームワークなどのOracle Service Bus拡張フレームワークを使用して、カスタム・クライアント・アプリケーションを記述できます。

Oracle Service Busのアーキテクチャの詳細は、『Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ』の「Oracle Service Busのアーキテクチャ」を参照してください。

5.12.1.1 Oracle Service Busのセッション状態

Oracle Service Busは、短期メッセージの処理/仲介を行うユースケース向けに最適化されています。したがって、メッセージのコンテキスト状態はすべてメモリー内に保持されます。HTTP、EJB、SBなどの同期トランスポートでは、同期リクエストを処理中のOracle Service Busサーバーで障害が発生した場合、クライアントが再試行する必要があります。Oracle Service Busでは、JMSやWS (WS-RM)などの非同期トランスポートのリクエスト/レスポンス・パターンがサポートされています。この場合、リクエストを対応するレスポンス先にマップする相関情報はメモリー内に保持されます。レスポンスを送信する前にOracle Service Busで障害が発生した場合、相関情報は失われます。したがって、サーバーの再起動後に、Oracle Service Busはレスポンスを送信することができません。JMSトランスポートとWSトランスポートの詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の「JMSトランスポート」と「WSトランスポート」を参照してください。

5.12.1.2 Oracle Service Bus外部依存性

Oracle Service Busには、次のような外部依存性があります。

- JMSレポート作成プロバイダは、データベースを使用してレポート・データを格納します。

- UDDI (Oracle Service Registry)は、Oracle Service Busのプロキシ・サービスを格納するため、およびOracle Service Busのビジネス・サービスを作成するサービスを参照するために使用されます。

- Oracle Enterprise Repositoryは、サービスを参照および消費するために使用されます。その結果として、Oracle Service Busのビジネス・サービスが生成されます。Oracle Service Busのプロキシ・サービスは、Oracle Enterprise Repositoryにより収集されます。

- Oracle Service Busには、Oracle Service Busのプロキシ・サービスとビジネス・サービスにアタッチされているOracle WSMセキュリティ・ポリシーを施行するOracle WSMエージェントが実装されています。

- Oracle Service Busは、SOA SuiteのJCAアダプタの実装(HTTP、FTPなどのJCAアダプタ)およびJCAフレームワークに依存します。

- Oracle Service Busは、サービス結果キャッシュ(Oracle Service Busにより起動されたサービスの結果のキャッシュ)のためにCoherenceインフラストラクチャに依存します。

Oracle Service Busメッセージ・フローは一般に短期です。メッセージ・フロー状態は常にメモリー内に存在します。Oracle Service Busは、即時利用可能な様々なトランスポートを提供します。たとえば、HTTPトランスポートでは、HTTP 1.1永続接続がサポートされています。

Oracle Service Busは、HTTP、JMS、電子メール、ファイル、FTP、SFTP、JCA - DB、AQ、Oracle Applications、Peoplesoft、Siebel、SAP、JD Edwards、ファイル、FTP、JEJB、EJB (アウトバウンドのみ)、Local (同一JVM内)、MQ、SB (RMIベース、2つのOSBサーバー/ドメイン間)、Tuxedo、Web Services Reliable Messaging (WS-RM)、SOA-Direct (RMIベース)、BPEL 10g (RMIベース)の各トランスポートをサポートしています。

Oracle Service Busは、JMS、ファイル、FTP、電子メール、SFTP、WS-RM、JCA - DB、AQ、SB、JEJB、EJB、SOA-DIRECTおよびBPEL 10gなど、一部のトランスポート・タイプに対して、JTAを使用します。

5.12.1.3 Oracle Service Busの構成アーティファクト

Oracle Service Busの主な構成ファイルは次のとおりです。

- DOMAIN_HOME/config/config.xml: すべてのアプリケーションとライブラリ、JMSシステム・リソース、JDBCシステム・リソース、ワーク・マネージャ、起動/停止クラス、SAFエージェント、セキュリティの構成が含まれます。

- DOMAIN_HOME/config/osb/coherence/osb-coherence-override.xml: このOracle Coherenceオーバーライド・ファイルでは、Oracle Coherenceのユニキャスト/マルチキャスト・リスナー情報を指定します。このファイルは、管理サーバーによって、管理サーバー・ドメイン・ディレクトリから他の管理対象サーバーのドメイン・ディレクトリに伝播されます。

- DOMAIN_HOME/config/osb/coherence/osb-coherence-cache-config.xml: このCoherenceキャッシュ構成ファイルでは、Oracle Service Busサービス結果キャッシュ機能で使用されるキャッシュを定義します。

- DOMAIN_HOME/config/osb/transports/sftp/known_hosts: このファイルはSFTPトランスポートで使用されます。リモートSFTPサーバーに関する情報が含まれます。known_hostsファイルの作成の詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。仮想ホスト名は、known_hostsファイルで使用できます。

5.12.1.4 Oracle Service Busのデプロイメント・アーティファクト

Eclipse IDEまたはOracle Service Bus Webコンソールを使用して、Oracle Service Busアーティファクト(リソース)をjarファイルにエクスポートし、選択した名前を付けることができます。エクスポートできるリソースには、プロキシ・サービス、ビジネス・サービス、WSDL、XSDおよびXSLTなどがあります。このjarファイルには、エクスポートされたすべてのOracle Service Busリソースが含まれます。構成jarファイル(およびその内部のOracle Service Busリソース)をOracle Service Busサーバーにインポートするには、次の2通りの方法があります。

- パブリックOracle Service Bus APIを使用するWLST/ANTスクリプト

- Oracle Service Bus Webコンソール: 「構成jarからインポート」オプションを使用

Oracle Service Busリソースは、構成フレームワーク・コンポーネントによって管理されます。構成フレームワークのデータはすべて、各管理対象サーバー(および管理サーバー)上のDOMAIN_HOME/osb/config (CONFIG_HOME)に格納されます。各リソースは、CONFIG_HOME/coreにある固有のファイルに格納されます。Oracle Service Bus構成フレームワークでは、各リソースで使用されるファイルに自動的に一意なファイル名が割り当てられるので、それらのファイル間で名前の衝突が発生しないことが保証されます。CONFIG_HOME/coreディレクトリは、すべてのリソース・データと構成データのマスター・ビューです。ランタイムは、このデータに基づいて動作します。これは、セッションで変更された内容がアクティブ化されたときにのみ変更されます。各管理対象サーバーでは、CONFIG_HOME/coreに、リソースのコピーが置かれます。管理対象サーバーの場所に応じて、このディレクトリが別システムにマウントされる可能性があります。

5.12.1.5 Oracle Service Busの起動とシャットダウン

ノード・マネージャまたはstartWebLogic/stopWebLogicスクリプトを使用して、Oracle Service Busサーバーを起動および停止できます。Oracle Enterprise Manager Grid Controlは、Oracle Service Busサービスの管理と監視をサポートします。

Oracle Service Busは、アプリケーション・リスナーを使用して初期化します。ALSB Framework Starter Applicationは、アプリケーション・リスナーを使用して、メイン・フレームワークを初期化します。このアプリケーションは、管理サーバーおよびクラスタにデプロイされます。このアプリケーション・リスナーの事前起動で、ロギング、ALSBConfigService、セキュリティ・サービス、クラスタ・タイマー・サービスおよびALSBStatisticsManagerを初期化します。XBus Kernelは、デプロイされる次に重要なアプリケーションであり、Oracle Service Busコンポーネントの初期化と起動のそれ以外の手順を実行します。このアプリケーションは管理サーバーとクラスタにターゲット指定され、アップグレーダ、リソース、Split-Join、Coherenceなどを初期化します。

障害検出機能は、Oracle WebLogic Serverによって提供されます。

5.12.1.6 Oracle Service Busのログ・ファイルの場所

Oracle Service Busの動作は、アプリケーションが実行されるOracle WebLogic管理対象サーバーに記録されます。

DOMAIN_HOME/servers/WLS_ServerName/logs/WLS_ServerName.log

Oracle Service Busは、デバッグ・ロギングもサポートします。これは、DOMAIN_HOME/alsbdebug.xmlとDOMAIN_HOME/configfwkdebug.xmlを更新することによって、有効化または無効化できます。

5.12.2 Oracle Service Busの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図5-40は、2つのOracle WebLogic ServerでOracle Service Busの2ノード・クラスタが実行されている様子を示しています。Oracle WebLogic Serverは、それらの前面のロード・バランサからリクエストを受信する、Web層ホスト上の2つのOracle HTTP Serverによってフロントエンド処理されます。

図5-40 Oracle Service Busの高可用性アーキテクチャ

「図5-40 Oracle Service Busの高可用性アーキテクチャ」の説明

図5-40に示す高可用性構成の主要な特性は次のとおりです。

- Oracle WebLogic Serverの移行機能を使用して、一部のコンポーネントを障害から保護します。これは、Oracle Service Busが実行されている各WebLogic管理対象サーバーが、フェイルオーバー時に別のボックスに移行される仮想IPをリスニングすることを意味します。Enterprise Managerは、図5-40の管理サーバーにデプロイされます。
図5-40に示すように、WLS_OSB1管理対象サーバーはVIP1でリスニングし、WLS_OSB2管理対象サーバーはVIP2でリスニングします。各管理対象サーバーはフェイルオーバー・リソースとして他方のノードを使用し、システムは交差的に構成されます。WLS_OSB1はOSBHOST2にフェイルオーバーし、WLS_OSB2はOSBHOST1にフェイルオーバーします。2つのOracle Service Bus管理対象サーバーが同一ノード上で実行されるシナリオを予想して、適切な容量計画を立てる必要があります。サーバー移行機能の詳細は、第3.9項「サーバー全体の移行」を参照してください。

サーバーの移行後にトランザクションを再開するため、トランザクションとJMSストアを共有記憶域に構成します。サーバー・インフラストラクチャ・インスタンスの1つで障害が発生した場合、他のインスタンスがその共有記憶域から永続ストアを読み取って、トランザクションとJMS操作を再開できます。

- 管理サーバーは、アクティブ/パッシブ・モードで実行されます。OSBHOST1で障害が発生したときはいつでも、OSBHOST2で管理サーバーを再起動できます。そのため、管理サーバーでは、リスニング・アドレスに仮想IPまたは仮想ホスト名が使用されます。管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。

- Oracle RACデータベースをデータベース障害から保護することをお薦めします。このOracle Service Bus高可用性構成では、Oracle RACデータベースは、JMSレポート作成プロバイダとOracle WSMのポリシーで使用されます。

注意:

前述の図では、Oracle Service Busの高可用性構成を見やすくするために、Oracle SOAサービス・インフラストラクチャの高可用性構成は図示されていません。Oracle SOAサービス・インフラストラクチャの図は、図5-5を参照してください。

ALSB Cluster Singleton Marker Applicationは、AggregatorとAlert Managerを監視するシングルトンを実行する管理対象サーバーをクラスタ内で決定します。同様に、データベースからの(JMSレポート作成プロバイダの)レポート作成データの消去に使用されるMessage Reporting Purger MDBは、クラスタ内の1つの管理対象サーバーにのみデプロイされます。他のOracle Service Busコンポーネントはすべて、クラスタをターゲットに設定するか、またはクラスタと管理サーバーをターゲットに設定します。Oracle Service BusのWebコンソール・サポートを提供するServiceBus_ConsoleおよびUDDIインポートのリソース・タイプを構成フレームワークに登録するUDDI Managerだけは、管理サーバーのみをターゲットに設定します。これらのコンポーネントは、WebLogicのシングルトン・サービスとしては定義されません。これらの高可用性は、WebLogicのサーバー全体の移行によって保証されます。

Oracle Service Busのすべてのサービスとリソースは、クラスタに均一に(クラスタ内のすべての管理対象サーバーに)デプロイされます。この唯一の例外を次に示します。

- ポーラー・トランスポートである電子メール、ファイル、FTPおよびSFTPのインバウンド(プロキシ・サービス)エンドポイント。ポーラーはクラスタ内の1つの管理対象サーバーのメッセージのみをポーリングします。ポーリングする管理対象サーバーは、ユーザー構成により決まります。

- JMSトランスポートのインバウンド(プロキシ・サービス)エンドポイント。JMSトランスポートは、WebLogic JMSトピック宛先を(互換トピック・メッセージ分散モードを使用して)リスニングし、ユーザーによって構成された管理対象サーバーで(クラスタ内で)1回のみトピックからのメッセージを処理するように構成されます。

可用性の高い基本的なトポロジは、1つの管理サーバーと2つの管理対象サーバーが異なるシステムで実行されるWebLogic Serverの同種クラスタ(前述のOracle Service Busシングルトン・サービスを除く)です。

WebLogicドメインでは、Oracle Service Busのクラスタが1つのみサポートされます。ローカル・データは、SANストレージ・システム、マルチポート・ディスク、NASストレージなどの共有ストレージに格納する必要があります。

ローカル・データ(ローカル・ファイルとしてアクセスされ、管理対象サーバーまたは管理サーバーにプライベート)には、次のデータが含まれます。

- WebLogic構成ファイルやサーバー・ログなどのシステム・ファイル。必要に応じて、WLS JMSデータをOracle RACデータベースに格納できます。JMSは、サービス・バス内部でも、外部サービスおよびプロキシ・サービスへのトランスポートとしても、使用されます。

- 構成ファイルやログなどのOracle Service Busデータ。

- ユーザー定義Oracle Service Bus構成データ

- プロキシ・サービスによってファイル/FTPトランスポートを使用して読取りまたは書込みされるデータ・ファイルなどのユーザー・ファイル。

- アラート・ログや集計されたパフォーマンス・メトリックを格納するJMS永続ストア。

Oracle RACデータベースは、レポート作成プロバイダの高可用性のため、およびサーバー移行に使用するleasingデータソースとして、使用されます。

必要に応じて、Webサーバー・ファームをOracle Service Busクラスタのフロントエンドとして使用できます。ハードウェア・ロード・バランサによって、Webサーバーまたはアプリケーション・サーバーを直接ロード・バランシングできます。Webサーバーを使用する場合、Oracle Service Bus管理対象サーバー間でHTTPトラフィックをロード・バランシングするように、WebLogicプラグインを構成する必要があります。

電子メール、FTPまたはNFSのサーバーはネットワーク内に存在でき、サード・パーティJMSのサーバーまたはサーバー・クラスタもネットワーク内に存在できます。

5.12.2.1 Oracle Service Busの障害からの保護および予想される動作

この項では、Oracle Service Busの高可用性クラスタのデプロイメントでコンポーネントがどのようにして障害から保護されるかを説明します。この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。

Oracle Service Busは、WebLogic Serverインフラストラクチャによってあらゆるプロセス障害から保護されます。

5.12.2.1.1 WebLogic Serverの障害

Oracle Service Busは、状態を保持することも、ユーザー・セッションという概念をサポートすることもありません。そのため、Oracle Service Busには、セッション状態のレプリケーションとフェイルオーバーは実装されていません。HTTP、SB、EJBなどの同期インバウンド・トランスポートの場合、リクエストを処理中の管理対象サーバーが停止した場合、クライアントは接続例外を受信するので、再試行する必要があります。

ノード・マネージャは、管理対象サーバーで障害が発生した場合にWebLogic Serverの自動移行を実行するように構成する必要があります。WebLogic Serverの移行の詳細は、第3.9項「サーバー全体の移行」を参照してください。

JMSのフェイルオーバーの場合は、WebLogicサーバーの移行を使用します。

Aggregator、Alert Manager、Reporting Message PurgerなどのOracle Service Busシングルトン・コンポーネントの場合、自動フェイルオーバーは存在しません。シングルトン・コンポーネントのフェイルオーバーを実行するには、WebLogicサーバー移行を使用します。

注意:

Aggregator、Alert ManagerおよびReporting Message Purgerサービスはシングルトンであるにもかかわらず、障害時のサービス停止はありません。ポーラー・トランスポート(ファイル、FTP、SFTPおよび電子メール)については、サーバーで障害が発生した場合に、ポーラー・トランスポートを使用するプロキシ・サービスのみに障害が発生します。

5.12.2.1.2 ノード障害

外部ロード・バランサを使用して、HTTPリクエストを直接、クラスタ内の管理対象サーバー上のOracle Service Bus HTTPプロキシ・サービスまたはOracle Service BusクラスタのフロントエンドとなるWebサーバー/Oracle HTTP Server(OHS)にロード・バランシングできます。スティッキー・セッション・ルーティング要件はありません。

ノード・マネージャを、障害が発生したOracle Service Busノードをフェイルオーバーするように構成できます。

HTTPリクエストを処理中のOracle Service Bus管理対象サーバーに障害が発生した場合、クライアントは同じリクエストを再送信する必要があります。JEJBトランスポートおよびSBトランスポートの場合、サーバーが停止すると、クライアントは接続エラーを受け取ります。すべてのポーラー・トランスポートの場合、メッセージはXA接続ファクトリを使用してデキューされるので、メッセージ処理の整合性は、トランザクション・セマンティクスによって処理されます。ポーラー・トランスポートは、「少なくとも1回」というセマンティックを提供します。しかし、(障害が発生したノードの)サーバー全体が移行した後、ポーラーはポーリング中のリソースにアクセスする必要があります。JTAトランスポートも、JMSトランスポートを使用する際、トランザクションの整合性を維持します。進行中のJTAトランザクションをリカバリするには、JTAのTlogをリカバリする必要があります。

Oracle Service Busは、「必ず1回」というメッセージ配信セマンティックを保証します。この動作は、プロキシ・サービスで構成される$outboundコンテキスト変数のQoSプロパティによって制御されます。様々なQoS設定の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』を参照してください。

管理対象サーバーが起動したとき、進行中のグローバル・トランザクションが存在する場合は、それをリカバリします。たとえば、プロキシ・サービスがXA接続ファクトリを使用して2つのJMSプロバイダ間を必ず1回のQoSでブリッジしている場合、グローバル・トランザクションのリカバリが必要になる可能性があります。もう1つの例として、JMSレポート作成プロバイダがあります。デフォルトのJMSレポート作成プロバイダを使用している場合、レポート・メッセージはまずJMSキューに書き込まれます。MDBは、JMSキューからレポート・メッセージをデキューして、それをデータベースに書き込みます。(データベースの)データ・ソースは、LLR (ロギング・ラスト・リソース最適化)のトランザクション・セマンティックにより構成されています。この場合、リカバリの実行中にデータベースが実行中である必要があります。実行されていない場合、サーバーは起動しません。LLRが有効な場合も、Tlogは使用されます。ただし、それはトランザクション単位に限定されます。したがって、すべてのトランザクションがLLRトランザクションだとしても、Tlogの可用性は高くする必要があります。トランザクション・マネージャは、特定のトランザクションには無関係でも、トランザクションの完全な安全性を提供するために必要とされるチェックポイントTlogレコードを永続的に保持します。

次の2つのケースでは、管理対象サーバーの障害によって特定の状態が失われ、メッセージが正しく処理されません。

- JMSリクエスト/レスポンス・ビジネス・サービス: メモリー内に表のマッピングの相関情報を保持しています。これは、管理対象サーバーが停止すると失われます。そのため、JMSサービスからのレスポンスが、JMSリクエスト/レスポンス・ビジネス・サービスへのルーティングを行うプロキシ・サービスを利用した元のクライアントに返されない可能性があります。

- WS(信頼できるメッセージング)ビジネス・サービス: JMSリクエスト/レスポンス・ビジネス・サービスと同様に、WSビジネス・サービスはメモリー内に表のマッピングの相関情報を保持しています。これは管理対象サーバーが停止すると失われ、レスポンスを処理できません。

5.12.2.1.3 データベース障害

データベース障害は、データベース・リース(サーバー移行に使用)に対する影響以外に、JMSレポート作成プロバイダの機能のコンテキストでのみOracle Service Busに影響を及ぼします。プロキシ・サービスでレポート・アクションが実行されている場合、レポート・データはレポート作成JMSキューにエンキューされます。レポート作成MDBは、JMSキューからメッセージをデキューし、それを、ロギング・ラスト・リソース(LLR)グローバル・トランザクション・プロトコルで構成されているデータ・ソースを使用して、データベースに挿入します。レポート作成JMSキューは、2回の再配信の制限とエラー・キューで構成されています。データベース障害が発生し、再配信が制限回数に達すると、レポート・メッセージはエラー・キューに移動されます。データベースが再稼働した後でこれらのレポート・メッセージをJMSレポート作成キューに戻すことによって、データベースに挿入できます。LLRトランザクションの処理中にデータベース障害が発生した場合、トランザクション・リカバリが実行されます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JTAのプログラミング』の「ロギング・ラスト・リソース・トランザクションの最適化」を参照してください。

5.12.2.2 Oracle Service Busのクラスタワイドのデプロイメント

Oracle Service Busのリソースの更新/デプロイは、WebLogic管理サーバー上で行われます。管理サーバーは、WebLogicデプロイメント・サービスを使用して、Oracle Service Busのリソースを、クラスタ内のすべての管理対象サーバーに伝播します。

5.12.2.3 クラスタ内のOracle Service Busのオンライン再デプロイメント

Oracle Service Busでは、複数のレコード(バージョン)またはリソースの履歴のコピーを保持しません。リソースの更新は、新しいバージョンがデプロイされ、古いバージョンは上書きされるという形で実行されます。構成フレームワークにより、セッション内のリソースが変更されます。セッション内のリソースは、セッション作成時にコア(すべての管理対象サーバーが現在使用している)からコピーされたものです。このセッションがコミットされると、変更によってコアが更新されます。この変更はトランザクション的にクラスタ内の管理対象サーバーに伝播されます。進行中のリクエスト(プロキシ・サービス・メッセージ・フローをすでに実行しているリクエスト)は、更新が行われている間、更新前のリソースを引き続き使用します。コアが変更された後のリクエストは、更新後のリソースを使用します。

5.12.2.4 Oracle Service Busのクラスタワイドの構成変更

Oracle Service Busのリソースは、クラスタ・レベルで更新されます。これらの変更は、WebLogic管理サーバーによって、クラスタ内のすべての管理対象サーバーに伝播されます。構成変更は、Oracle Service Bus Webコンソール、管理コンソールおよびパブリックMBeanで実行できます。

次のファイルは、クラスタ内の管理対象サーバーへの自動伝播の対象外です。

- DOMAIN_HOME/config/osb/coherence/ディレクトリのファイル

- DOMAIN_HOME/config/osb/transports/sftp/known_hosts

これらのディレクトリにあるファイルにアクセスする各管理対象サーバーは、DOMAIN_HOMEへのアクセス権が必要です。

注意:

高可用性構成のOracle Service Busのインストールと構成の詳細な手順は、第5.14項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンを使用するOracle Service Busの高可用性の構成」を参照してください。

5.13 Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成

この項では、Oracle BPEL/Oracle PM、Oracle Mediator、Oracle Human WorkflowおよびOracleデシジョン・サービスの他、Oracle B2BおよびOracle User Messaging Serviceなど、Oracle SOAサービス・インフラストラクチャ・システムに含まれるサービス・エンジンの設定手順について説明します。

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

- 第5.13.1項「環境の準備: SOAの高可用性構成の設定前に必要な手順」

- 第5.13.2項「Oracle Fusion Middlewareホームのインストール」

- 第5.13.3項「SOAHOST1のVIP1およびSOAHOST2のVIP2の有効化」

- 第5.13.4項「SOAのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行」

- 第5.13.5項「SOAHOST1での管理サーバー用boot.propertiesの作成」

- 第5.13.6項「SOAHOST1での管理サーバーの起動と検証」

- 第5.13.7項「管理サーバーおよびWLS_SOAn管理対象サーバーに対するホスト名の検証の無効化」

- 第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」

- 第5.13.9項「SOAHOST1でのシステムの起動」

- 第5.13.10項「pack/unpackユーティリティを使用したSOAHOST2へのドメイン構成の伝播」

- 第5.13.11項「第2ノードのXEngineファイルの抽出」

- 第5.13.12項「SOAHOST2でのシステムの起動」

- 第5.13.13項「管理サーバーおよび管理対象サーバーWLS_SOAnのOracle HTTP Serverの構成」

- 第5.13.14項「Oracle HTTP Serverを使用したアクセスの検証」

- 第5.13.15項「サーバー間で共有するJMS永続ストアの構成」

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

- 第5.13.17項「フロントエンドHTTPのホストおよびポートの設定」

- 第5.13.18項「コンポジットへの直接バインディング/RMI呼出しのためのWLSクラスタ・アドレスの設定」

- 第5.13.19項「アプリケーションのデプロイ」

- 第5.13.20項「WLS_SOAサーバーのサーバー移行の構成」

- 第5.13.21項「トポロジのスケーリング」

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

注意:

このガイドで定義されているアーキテクチャとデプロイメント手順を使用することにより、単純なクラスタ・デプロイメントを実現できます。各章に記載されている手順は、このトポロジおよび他の類似する高可用性トポロジを、該当するFusion Middlewareコンポーネントで実現する場合の基礎的要素として使用できます。また、本番デプロイメントでは、セキュリティ・ポリシーと一元的なLDAPサーバーを関連付けるなど、この他にも必要な手順を使用することが予想されます。セキュアな複数層アーキテクチャおよびデプロイメント手順の詳細は、構成対象のコンポーネントのエンタープライズ・デプロイメント・ガイドを参照してください。

図5-41は、この項の構成手順で作成するアーキテクチャの例を表しています。

図5-41 Oracle SOAサービス・インフラストラクチャの高可用性アーキテクチャ

「図5-41 Oracle SOAサービス・インフラストラクチャの高可用性アーキテクチャ」の説明

図5-41は、2つのOracle WebLogic Serverで2ノードのSOAクラスタが実行されている様子を示しています。Oracle WebLogic Serverは、受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。ロード・バランサは、システムをフロントエンド処理し、クライアントから受信したリクエストを2つのOracle HTTP Serverに配布します。カスタムの論理デプロイメントとアプリケーション・デプロイメントには、(図には示されていない)異なるOracle WebLogic Serverが使用されます。この構成では、メタデータとSOAスキーマの格納にはOracle RACデータベース、トランザクションとJMSストアには共有記憶域を使用しています。仮想IPアドレス(VIP)は、管理サーバーとOracle SOA Server(サーバー移行用)の手動フェイルオーバーに使用されます。このアーキテクチャに含まれるコンポーネントの詳細は、この章の個々のコンポーネントの項を参照してください。

管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。

5.13.1 環境の準備: SOAの高可用性構成の設定前に必要な手順

次の各項では、Oracle SOAサービス・インフラストラクチャの高可用性構成を設定する前に必要となる手順について説明します。

プラットフォーム固有のコマンドの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteインストレーション・ガイド』を参照してください。

- 第5.13.1.1項「データベースに関する前提条件」

- 第5.13.1.2項「VIPとIPの前提条件」

- 第5.13.1.3項「共有記憶域に関する前提条件」

- 第5.13.1.4項「LDAPプロバイダのインストールと構成」

- 第5.13.1.5項「システム・クロックの同期」

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

- 第5.13.1.7項「データベース・リポジトリのインストールと構成」

- 第5.13.1.8項「Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード」

- 第5.13.1.9項「ロード・バランサの仮想サーバー名とポートの構成」

- 第5.13.1.10項「WEBHOST1およびWEBHOST2へのOracle HTTP Serverのインストール」

5.13.1.1 データベースに関する前提条件

Oracle SOA Suiteでは、サポートされているデータベースおよびスキーマが存在している必要があります。

データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。

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

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

5.13.1.2 VIPとIPの前提条件

表5-2に示されているように、それぞれ異なる仮想IPをリスニングする管理サーバーとSOA管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。各VIPが使用可能であり、SOAHOST1、SOAHOST2およびクライアント・システムからアクセスできることを確認してから、インストールを実行してください。

表5-2 仮想ホスト

仮想IP

VIPのマップ先

説明

VIP0

SOAHOST1VHN0

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

VIP1

SOAHOST1VHN1

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

VIP2

SOAHOST2VHN1

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

5.13.1.3 共有記憶域に関する前提条件

障害発生時に適切にリカバリできるようにするには、すべてのノードからアクセスできる場所にJMSとトランザクションの両方のログを格納して、管理対象サーバーで障害が発生した後にすべてのノードが操作を再開できるようにします。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表5-3は、共有記憶域の内容を示しています。

表5-3 共有記憶域の内容

サーバー

データの型

共有記憶域のボリューム

ディレクトリ

ファイル

WLS_SOA1

Txログ

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

共通の場所(WebLogicサーバーにより決められたストア)

WLS_SOA2

Txログ

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

共通の場所(WebLogicサーバーにより決められたストア)

WLS_SOA1

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

共通の場所である、サーバーごとに個別のストア(SOAJMSStore1、UMSJMSStore1など)

WLS_SOA2

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

共通場所である、サーバーごとに個別のストア(SOAJMSStore2、UMSJMSStore2など)

共有記憶域にはNASやSANなどのデバイスを使用できます。具体的には、NFSマウント・システムの場合、ファイルのロックに関連する別の問題および突然のノード障害が検出されます。『Oracle Fusion Middlewareリリース・ノート』をチェックし、記憶域のベンダーに、マウント・オプションとして使用する主な推奨パラメータについて問い合せてください。NASデバイス別のコマンド例を次に示します。この項で指定しているオプションは、実際のオプションと異なる場合があります。

SOAHOST1> mount nasfiler:/vol/volX/FMWshared
MW_HOME -t nfs -o
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

5.13.1.4 LDAPプロバイダのインストールと構成

本番環境では、Oracle SOA Suiteの高可用性トポロジに外部のLDAPポリシー・ストアが必須です。サポートされているポリシー・ストアの詳細と、LDAPの構成手順は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.13.1.5 システム・クロックの同期

高可用性SOAのデプロイメントでは、各クラスタ・ノードのシステム・クロックを同期することが必要です。

5.13.1.6 ディレクトリおよびディレクトリ環境変数の用語

次のリストは、この章で使用するディレクトリと変数について説明しています。

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

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

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

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

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

- DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。

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

このディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。

ORACLE_BASE:

/u01/app/oracle

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

ORACLE_BASE/product/fmw

WL_HOME:

MW_HOME/wlserver_10.3

ORACLE_HOME:

MW_HOME/soa

ORACLE_COMMON_HOME:

MW_HOME/oracle_common

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

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/

5.13.1.7 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

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

自動ストレージ管理

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

- インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clusterデータベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

データベースの初期化パラメータ

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

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

パラメータ

必要な値

パラメータ・クラス

PROCESSES

300以上

静的

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

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

SQL> SHOW PARAMETER processes

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

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

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

注意:

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

5.13.1.8 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード

Oracle SOA Suiteのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとOracle SOAスキーマをReal Application Clusterデータベースにインストールします。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

5.13.1.8.1 RCUの実行

RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。

1. Linuxでは、RCU_Home/binに移動して、次のコマンドを使用します。

./rcu

2. 「ようこそ」画面で「次へ」をクリックします。

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

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

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

- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを指定します: SOADBHOST1VIRTUAL

- ポート: データベースのポート番号: 1521

- サービス名: データベースのサービス名を入力します: soaha.mycompany.com

- ユーザー名: SYS

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

- ロール: SYSDBA

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

6. 次のような警告メッセージを受信する場合があります。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。

7. その場合は、「無視」または「停止」をクリックします。

8. 「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、SOAHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。

- 次のスキーマを選択します。

- 「AS共通スキーマ」で、メタデータ・サービスを選択します。

- 「SOAサービス・インフラストラクチャ」で、SOAサービス・インフラストラクチャとユーザー・メッセージングを選択します。

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

10. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。

11. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

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

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

RCUの使用の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

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

Oracle WebLogic Serverトランザクション・マネージャがトランザクションの状態情報を問い合せて、WebLogic Serverコンテナで障害が発生した後の処理中トランザクションのリカバリ時に、commitやrollbackなどの適切なコマンドを発行できるようにするには、適切なデータベース権限が必要です。

トランザクション・リカバリ権限のSOAスキーマを構成する手順は次のとおりです。

1. sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例:

sqlplus "/ as sysdba"

2. sys.dba_pending_transactionsに対してselectをsoaha_soainfraに付与します。

3. 任意のトランザクションに対してforceをsoaha_soainfraに付与します。

注意:

これらの権限は、RCUの操作によって決定されるsoainfraスキーマの所有者に付与する必要があります。

5.13.1.9 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle SOA Suiteの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

Oracle SOA Suiteは、2つのOracle HTTP ServerがWeb層コンポーネントとして含まれた高可用性構成にデプロイされた場合は、ハードウェア・ロード・バランサを使用します。ハードウェア・ロード・バランサには、次の機能が必要です。

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

- ポート変換の構成: ロード・バランサには、1つのポートで受信した受信リクエストを別のポートで実行されているサーバー・プロセスにルーティングできるポート変換機能が必要です。たとえば、ポート80で受信したリクエストをポート7777にルーティングできます。

- ポート(HTTP、HTTPS)の監視

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

- ロード・バランサには複数の仮想サーバーを構成できる必要があります。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、通常は、HTTPおよびHTTPSトラフィック用の仮想サーバーとポートでロード・バランサを構成する必要があります。

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

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

- リソースの監視/ポートの監視/プロセス障害検出: ロード・バランサは、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへの非Oracle Netトラフィックの送信を停止できる必要があります。ロード・バランサに障害の自動検出機能がある場合は、それを使用する必要があります。

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

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

- スティッキーなルーティング機能: CookieまたはURLに基づいたコンポーネントへのスティッキーな接続を維持する機能。

- SSLアクセラレーション: SSLアクセラレーションは、SSLトランザクションで実行され、プロセッサを集中的に使用する公開鍵暗号化アルゴリズムを、ハードウェア・アクセラレータにオフロードする方法です。
この機能は推奨されますが、必須ではありません。

表5-5は、Oracle SOA Suiteの高可用性環境で外部ロード・バランサに使用する仮想サーバー名の例を示しています。

表5-5 外部ロード・バランサの仮想サーバー名

コンポーネント

仮想サーバー名

Oracle SOA Suite

soa.mycompany.com

WebLogic Server管理コンソール

admin.mycompany.com

Oracle Enterprise Manager Fusion Middleware Control

admin.mycompany.com

仮想サーバー名

この項では、この章で説明する高可用性デプロイメントのために設定が必要な仮想サーバー名について説明します。

soa.mycompany.com

soa.mycompany.comは、soa-infraやワークフローなどのランタイムSOAコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、アドレスsoa.mycompany.com:443を使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

admin.mycompany.com

この仮想サーバーは、管理サービスへ送信されるすべての内部HTTPトラフィックのアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスadmin.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777に順に転送されます。この仮想ホストでアクセスされるサービスには、WebLogic管理サーバー・コンソールやOracle Enterprise Managerなどがあります。

さらに、仮想サーバー名に対応するIPアドレスが設定されていることと、仮想サーバー名がドメイン・ネーム・システム(DNS)に登録されていることを確認します。Oracle Fusion Middlewareを実行するコンピュータには、これらの仮想サーバー名を解決できることが必要です。

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

WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。

1. サーバーが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』で指定されている要件を満たしています。

- ポート7777が、ノード上のどのサービスによっても使用されていない。このことを確認するには、次のコマンドを実行します。
UNIX:

netstat -an | grep LISTEN | grep "7777"

Windows:

netstat -an | findstr "LISTEN" | findstr ":7777"

ポートを使用中の場合は、それらのポートを使用可能にします。

2. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

3. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンドrunInstallerを実行します。

Windowsでは、setup.exeをダブルクリックします。

4. 「ようこそ」画面で「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

6. 「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。

7. 「インストール場所の指定」画面で、場所を次のように設定します。
/u01/app/oracle/product/11.1.1/ohs_1

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

9. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

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

10. 「コンポーネントの詳細の指定」画面で、次の値を入力します。

- インスタンス・ホームの場所: インスタンス・ホーム

- インスタンス・ホームの場所: /u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1

- インスタンス名: ohs_instance1

- OHSコンポーネント名: ohs1

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

12. 「Web Tierポートの詳細の指定」画面で、次の操作を行います。

- 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

- 「Oracle HTTP Serverポート」に値を入力します(例: 7777)。

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

14. 「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。

15. 「インストールの進行状況」画面で、次の操作を行います。
UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

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

16. 「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。

17. 「構成が完了しました」画面で、「終了」をクリックして終了します。

WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してLBRを構成します。

5.13.1.10.1 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、ブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

HTTP://WEBHOST1:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザにOracle FMWの「ようこそ」画面が表示されます。

5.13.2 Oracle Fusion Middlewareホームのインストール

この項では、Oracle WebLogic ServerとOracle SOA Suiteを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。WebLogic ServerとOracle SOAをSOAHOST2にインストールするために、この手順を繰り返します(次ではSOAHOST1を対象にして説明しています)。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは正しく機能しません。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

- Oracle WebLogic Server(第5.13.2.1項「Oracle WebLogic Serverのインストール」を参照)

- Oracle SOA Suite(第5.13.2.2項「Oracle SOA用Oracle Fusion Middlewareのインストール」を参照)

5.13.2.1 Oracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。

1. Oracle WebLogic Serverインストーラを起動します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」フィールドで、MW_HOMEと入力します。

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

4. 「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。

6. 「製品とコンポーネントの選択」画面で、「次へ」をクリックします。

7. 「JDKの選択」画面で、「Oracle JRockit 160_20_D1.0.1-2124 SDK」のみを選択して「次へ」をクリックします。

8. 「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
WL_HOME

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

9. 「インストールの概要」画面で「次へ」をクリックします。

10. 「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。

5.13.2.2 Oracle SOA用Oracle Fusion Middlewareのインストール

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

1. Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラを起動します。
UNIXの場合:

SOAHOST1> runInstaller

Windowsの場合:

SOAHOST1> setup.exe

Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_<バージョン>のように入力します。

2. 「インベントリ・ディレクトリの指定」画面で、次の操作を行います。

1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所が推奨されます)。

2. インストールを実行するユーザーのOSグループを入力します。

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

4. 画面の手順に従って、/createCentralInventory.shをルートとして実行します。

5. 「OK」をクリックします。

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

5. 「インストール場所の指定」画面で、次の操作を行います。

- 「MiddleWareホーム」には、MW_HOMEと入力します。

- 「Oracleホーム・ディレクトリ」には、soaと入力します。

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

6. 「インストール・サマリー」画面で「インストール」をクリックします。

7. 「インストール完了」画面で「終了」をクリックします。

注意:

第5.13.4項「SOAのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareが最新バージョンになるように、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチがMiddlewareホームに適用されていることを確認してください。

最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

5.13.3 SOAHOST1のVIP1およびSOAHOST2のVIP2の有効化

SOAドメインは、SOA管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのSOAマシン上でこれらのホスト名それぞれに対してVIPマッピングを有効にして(SOAHOST1ではVIP1、SOAHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。

仮想IPの構成の詳細は、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。この項には、管理サーバーの例が記載されています。SOAサーバーのサーバー移行の構成の詳細は、第5.13.20項「WLS_SOAサーバーのサーバー移行の構成」を参照してください。

5.13.4 SOAのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行

SOAホーム・ディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracle SOAコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。

注意:

同じWebLogic Serverドメイン内では、複数のSOAクラスタは許可されていません。

注意:

ドメインを拡張するためにOracle Fusion Middlewareの構成ウィザードを実行する前に、Oracle BPMはOracle Fusion Middlewareの適切なパッチ・セット・レベルのパッチの適用対象になるWL_HOMEホームとORACLE_HOMEホームを要求します。

1. MiddlewareホームのSOAディレクトリにある、Oracle Fusion Middlewareの構成ウィザードの場所に、ディレクトリを変更します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

2. Oracle Fusion Middlewareの構成ウィザードを起動します。
Linuxの場合:

SOAHOST1> ./config.sh

Windowsの場合:

SOAHOST1> config.cmd

3. 「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択します。「次へ」をクリックします。

4. 「ドメイン・ソースの選択」画面で、次を選択します。

- 「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

- 次の製品を選択します。

- Basic Weblogic Server Domain - 10.3.6.0 [wlserver_10.3](デフォルトで選択されており、グレーアウトされています)

- Oracle BPM Suite - 11.1.1.0 [Oracle_SOA1](BPMシステムの場合のみ)

- Oracle SOA Suite - 11.1.1.0 [Oracle_SOA1](BPM Suiteを選択した場合は、デフォルトで選択されています)

- Oracle Service Bus OWSM Extension - 11.1.1.6

- Oracle Enterprise Manager - 11.1.1.0 [oracle common](デフォルトで選択されています)

- Oracle Service Bus - 11.1.1.6

- WebLogic Advanced Web Services for JAX-RPC Extension - 10.3.6.0

- Oracle WSM Policy Manager - 11.1.1.0 [oracle_common](SOA/BPM Suiteを選択した場合は、デフォルトで選択されています)

- Oracle JRF - 11.1.1.0 [oracle_common](SOA/BPM Suiteを選択した場合は、デフォルトで選択されています)

ターゲットの一部を間違って選択解除した場合は、この画面で次の項目が選択されていることを確認してください。

- Oracle BPM Suite(BPMシステムの場合のみ)

- Oracle SOA Suite

- Oracle Enterprise Manager

- Oracle WSM Policy Manager

- Oracle JRF

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

5. 「ドメイン名と場所の指定」画面で、次のエントリを作成します。

- ドメイン名: soadomain

- ドメインの場所: デフォルトを受け入れます。

- アプリケーションの場所: デフォルトを受け入れます。

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

6. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。

7. 「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。

- WebLogicドメインの起動モード: 「本番モード」を選択

- JDKの選択: 「Oracle JRockit 160_20_D1.0.1-2124 SDK」を選択

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

8. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

1. 画面下部の表に表示されるすべてのコンポーネント・スキーマ(SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマ)を選択します。

2. 「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択します。単一のデータベース構成の場合は、「変換しない」を選択します。

3. 画面に次のデータ・ソースが表示されていることを確認します。表5-6に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にsoahaが使用されていることを想定しています。
Oracle RACでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照してください。

Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

表5-6 データ・ソースの値の構成

コンポーネント・スキーマ

スキーマ所有者

SOAインフラストラクチャ

SOAHA_SOAINFRA

ユーザー・メッセージング・サービス

SOAHA_ORASDPM

OWSM MDSスキーマ

SOAHA_MDS

SOA MDSスキーマ

SOAHA_MDS

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

9. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
マルチ・データ・ソースの場合は、次のフィールドに値を入力します。

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

「図5-42「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。

図5-43 GridLink RACコンポーネント・スキーマの構成

「図5-43 GridLink RACコンポーネント・スキーマの構成」の説明

1. ドライバ: RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

2. サービス名 : データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、 <mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(example.comなど)を含むRACサービス名を登録または追加することをお薦めします。

3. ユーザー名接頭辞: スキーマの接頭辞を入力します。表5-6に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にsoahaが使用されていることを想定しています。

4. 「パスワード」と「パスワードの確認」: スキーマにアクセスするときのパスワードを入力します。

5. GridLinkデータ・ソースの場合は、SCANアドレスをリスナー・アドレス・フィールドに入力し、「ポート」フィールドにSCANポートを入力します。「ONSホスト」と「ポート」の各フィールドに、ONSホストおよびポート情報を入力します。

注意:

WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、SCANアドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、ネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。

マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。

6. 一度に1つのデータ・ソースを選択し、適切な詳細を追加することにより、各スキーマを更新します。
すべてのスキーマ(SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマおよびSOA MDSスキーマ)に情報が入力されていることを確認します。

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

10. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックしてエントリを修正します。
すべての接続が正常になったら「次へ」をクリックします。

11. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

12. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: VIP0仮想IPのホスト名を入力します。

- リスニング・ポート: 7001

- SSLリスニング・ポート: N/A

- SSL有効: 選択を解除

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

13. UDD設定で、UMSJMSSystemResource、SOAJMSModuleおよびBPMJMSModuleのUDDが設定されていることを確認します。

14. 「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。

表5-7 管理対象サーバーの構成

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_SOA1

SOAHOST1VHN1

8001

n/a

いいえ

WLS_SOA2

SOAHOST2VHN1

8001

n/a

いいえ

表示されるどのサーバーも削除しないでください。サーバーは変更できます。サーバーを削除して新しいサーバーを追加すると、ターゲット指定が失敗します。

注意:

標準の推奨事項は、個々のWebLogic管理対象サーバー内でカスタム・アプリケーションおよび他のシステムを実行するためのものです。図5-41で説明しているカスタムWLS管理対象サーバーの作成については、ここでは取り上げません。

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

15. 「クラスタの構成」画面で、次のクラスタを追加します。

- 名前: SOA_Cluster

- クラスタ・メッセージング・モード: unicast

- マルチキャスト・アドレス: N/A

- マルチキャスト・ポート: N/A

- クラスタ・アドレス: 空白のまま

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

16. 「サーバーのクラスタへの割当」画面で、SOA_Clusterに次のサーバーを割り当てます。

- WLS_SOA1

- WLS_SOA2

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

17. 「マシンの構成」画面で、次の操作を行います。

- デフォルトとして表示される「LocalMachine」を削除します。

- 「UNIXマシン」タブをクリックし、次のマシンを追加します。

表5-8 マシンの構成

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1のホスト名

SOAHOST2

SOAHOST2のホスト名

その他すべてのフィールドをデフォルト値のままにして、「次へ」をクリックします。

18. 「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

図5-44 「サーバーのマシンへの割当」画面

「図5-44 「サーバーのマシンへの割当」画面」の説明

- SOAHOST1: AdminServer、WLS_SOA1

- SOAHOST2: WLS_SOA2

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

19. WebLogicドメインの確認画面で、「次へ」をクリックします。

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

21. ドメインの作成中画面で「完了」をクリックします。

注意:

マルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用されるものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタと、コンポジットがデプロイされるグループ)の通信プロトコルが異なっていても、コンポジットが単一のWebLogic Serverクラスタのメンバーにデプロイされることが保証されています。

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

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。SOAHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。

管理サーバーに対しては、次の手順を実行します。

1. 次のディレクトリを作成します。

SOAHOST1> mkdir -p ORACLE_BASE/product/fmw/user_
projects/domains/soadomain/servers/AdminServer/security

2. テキスト・エディタを使用して、前の手順で作成したセキュリティ・ディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminuser
password=password

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

5.13.6 SOAHOST1での管理サーバーの起動と検証

この項では、SOAHOST1で管理サーバーを起動および検証する手順について説明します。

5.13.6.1 SOAHOST1での管理サーバーの起動

SOAHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

SOAHOST1> cd MW_HOME/user_projects/domains/soadomain/bin

SOAHOST1> ./startWebLogic.sh

5.13.6.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. ブラウザでhttp://vip0:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. 管理対象サーバーとしてWLS_SOA1およびWLS_SOA2が表示されていることを確認します。

4. SOA_Clusterクラスタが表示されていることを確認します。

5. Enterprise Manager(http://vip0:7001/em)にアクセスできることを確認します。

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

この手順が必要になるのは、管理サーバーとノード・マネージャの間にホスト名を検証するための適切な証明書を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。

ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。

ホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールで、「サーバー」→「AdminServer」を選択します。

2. 「SSL」→「詳細」を選択します。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 「ホスト名の検証」を「なし」に設定します。

5. 変更を保存およびアクティブ化します。

6. WLS_SOA1およびWLS_SOA2サーバーに対してこの手順を繰り返します。

7. 管理サーバーを再起動します。

5.13.8 コンポジットのデプロイでのOracle Coherenceの構成

コンポジットのデプロイではデフォルトでマルチキャスト通信を使用しますが、SOAの高可用性を実現するためにはユニキャスト通信を使用することをお薦めします。セキュリティ上の理由からマルチキャスト通信を無効化した場合には、ユニキャスト通信を使用します。

注意:

デプロイメントに使用されるOracle Coherenceフレームワークの構成が不適切な場合、SOAシステムは起動できません。SOAシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項でこれらから説明する構成をお薦めします。

ユニキャスト通信を使用したクラスタ内通信の有効化

マルチキャスト通信を使用すると、クラスタの中でコンポジットの動的なデプロイメント先となるすべてのメンバーをOracle SOA Suiteで検出できます。しかし、ユニキャスト通信では、ノードはこのように他のクラスタ・メンバーを検出することはできません。そのため、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加された新しいノードが既存ノードの1つを検出するために必要なノードを指定するだけで済みます。これによって、新しいノードがクラスタに追加されたときに、クラスタ内の他のすべてのノードを検出できるようになります。さらに、同じノードで複数のIPを使用可能な構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

ヒント:

SOAコンポジットのデプロイメント時の高可用性を保証するためには、十分なノードを指定して、いつでも最低1つのコンポジットが実行されているようにします。

tangosol.coherence.wka<n>システム・プロパティを使用してノードを指定します。<n>は、1から9の数字です。最大9つのノードを指定できます。番号は、1から開始します。連続した番号を指定する必要があり、途切れていてはなりません。また、Oracle Coherenceがtangosol.coherence.localhostシステム・プロパティを使用してクラスタを作成するときに使用するホスト名を指定します。このホスト名は、対応するリスナー・アドレス(VIP1およびVIP2)をマップするSOAサーバーによって使用される仮想ホスト名である必要があります。このプロパティは、管理コンソールの「サーバーの起動」タブ(図5-45)の「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加して設定します。

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

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

ホスト名の指定

Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。

5. 「サーバーの起動」タブをクリックします(図5-45を参照)。

6. 「引数」フィールドで、WLS_SOA1とWLS_SOA2について次のように入力します。
WLS_SOA1について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1

WLS_SOA2について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1

注意:

デプロイメントに使用される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

7. 「保存」をクリックして、変更をアクティブ化します。

8. この変更を適用するには、SOAサーバーを再起動する必要があります。

注意:

マルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用されるものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタと、コンポジットがデプロイされるグループ)の通信プロトコルが異なっていても、コンポジットが単一のWebLogic Serverクラスタのメンバーにデプロイされることが保証されています。

前述のテキストを管理コンソールの引数テキスト・フィールドにコピーしないでください。コピーすると、HTMLタグがJava引数に挿入されることがあります。テキストには、前述のもの以外のテキストや文字を含めることはできません。

5.13.9 SOAHOST1でのシステムの起動

この項では、SOAHOST1でノード・マネージャを起動する方法、およびSOAHOST1で管理対象サーバーWLS_SOA1を起動して検証する方法について説明します。

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

SOAHOST1でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./setNMProps.sh

注意:

クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

2. ノード・マネージャを起動します。

SOAHOST1> cd WL_HOME/server/bin
SOAHOST1> ./startNodeManager.sh

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

WLS_SOA1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

1. 管理コンソールを使用してWLS_SOA1管理対象サーバーを起動します。

2. WLS_SOA1が起動すると、次のURLが使用できるようになります。

- http://SOAHOST1VHN1:8001/b2bconsole

- B2Bコンソールへのログインを確認します。

- http://SOAHOST1VHN1:8001/integration/worklistapp

- ワークリスト・コンソールへのログインを確認します。

- http://SOAHOST1VHN1:8001/wsm-pm

- ポリシー・バリデータ・リンクを確認します。

- http://SOAHOST1VHN1:8001/soa/composer

- http://SOAHOST1VHN1:8001/soa-infra

- http://SOAHOST1VHN1:8001/bpm/composer(BPMシステムの場合のみ)

- http://SOAHOST1VHN1:8001/bpm/workspace(BPMシステムの場合のみ)

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

次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をSOAHOST2に伝播します。

1. 次のpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplate.jar
-template_name=soa_domain_template

2. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします

SOAHOST1> scp soadomaintemplate.jar
oracle@node2:ORACLE_COMMON_HOME/common/bin

3. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

SOAHOST2> cd ORACLE_COMMON_HOME/common/bin
SOAHOST2> ./unpack.sh
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplate.jar

注意:

pack/unpackプロシージャを実行した後でFusion Middleware構成ウィザードを実行するときには、元のドメインにすでに存在し、「拡張ソースの選択」画面に表示される製品は、選択されていず、グレー表示されています。

packコマンドで作成されたテンプレートは、ユーザー作成テンプレートと見なされます。このようなテンプレートは、デフォルト・テンプレートとは別のものとして扱われます。ユーザー作成テンプレートは自己完結型で、元のドメインの作成に関連する情報は一切含んでいません。

5.13.11 第2ノードのXEngineファイルの抽出

B2BのXEngineを第2ノードで有効にするには、次のようにZEngine tarのコンテンツを手動で抽出する必要があります。

SOAHOST2>cd ORACLE_HOME/soa/thirdparty/edifecs
SOAHOST2>tar xzvf XEngine.tar.gz

5.13.12 SOAHOST2でのシステムの起動

この項では、SOAHOST2でシステムを起動する手順について説明します。

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

SOAHOST2でノード・マネージャを起動するには、第5.13.9.1項「SOAHOST1でのノード・マネージャの起動」の手順をSOAHOST2で繰り返します。

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

管理対象サーバーWLS_SOA2を起動して、正しく構成されていることをチェックする手順は、次のとおりです。

1. 管理コンソールを使用してWLS_SOA2管理対象サーバーを起動します。

2. WLS_SOA2が起動すると、次のURLが使用できるようになります。

- http://SOAHOST2VHN1:8001/b2bconsole
B2Bコンソールへのログインを確認します。

- http://SOAHOST2VHN1:8001/integration/worklistapp
ワークリスト・コンソールへのログインを確認します。

- http://SOAHOST2VHN1:8001/wsm-pm
ポリシー・バリデータ・リンクを確認します。

- http://SOAHOST2VHN1:8001/soa/composer

- http://SOAHOST2VHN1:8001/soa-infra

- http://SOAHOST2VHN1:8001/bpm/composer(BPMシステムの場合のみ)

- http://SOAHOST2VHN1:8001/bpm/workspace(BPMシステムの場合のみ)

5.13.13 管理サーバーおよび管理対象サーバーWLS_SOAnのOracle HTTP Serverの構成

管理対象サーバーWLS_SOAnを含むSOAクラスタへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

1. WEBHOST1およびWEBHOST2で、ORACLE_BASE/admin/<instance_name>/config/OHS/<component_name>/mod_wl_ohs.confファイルに次の行を追加します。

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# SOA soa-infra app
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Worklist
<Location /integration/>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# B2B
<Location /b2b>
SetHandler weblogic-handler
WebLogicCluster SOAHOST11VHN1:8001,SOAHOST2VHN1:8001
</Location>

<Location /b2bconsole>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# UMS
<Location /sdpmessaging/ >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# UMS WS
<Location /ucs/messaging/webservice >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow/>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# SOA composer application
<Location /soa/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# BPM composer (ONLY FOR BPM Systems)
<Location /bpm/composer >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# BPM workspace (ONLY FOR BPM Systems)
<Location /bpm/workspace >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

2. mod_wl_ohsファイルと同じディレクトリにあるhttpd.confファイルが次の行を含んでいることを確認します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://soa.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>

注意:

このドキュメントに記載されているsoa.mycompany.com:443、7777、admin.mycompany:80、you@youraddressなどの値は、例としてのみ示されています。実際の環境に基づく値を入力してください。

3. WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。

4. 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

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

管理コンソールでSOAサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中」と表示される場合は、サーバーの状態が「起動済」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。次のURLにアクセスできることを確認します。

- http://WEBHOST1:7777/wsm-pm

- http://WEBHOST2:7777/wsm-pm

- http://WEBHOST1:7777/soa-infra

- http://WEBHOST2:7777/soa-infra

- http://WEBHOST1:7777/soa/composer

- http://WEBHOST2:7777/soa/composer

- http://WEBHOST1:7777/integration/worklistapp

- http://WEBHOST2:7777/integration/worklistapp

- http://WEBHOST1:7777/sdpmessaging/userprefs-ui

- http://WEBHOST2:7777/sdpmessaging/userprefs-ui

- http://WEBHOST1:7777/b2bconsole

- http://WEBHOST2:7777/b2bconsole

- http://WEBHOST1:7777/bpm/composer(BPMシステムの場合のみ)

- http://WEBHOST2:7777/bpm/composer(BPMシステムの場合のみ)

- http://WEBHOST1:7777/bpm/workspace(BPMシステムの場合のみ)

- http://WEBHOST2:7777/bpm/workspace(BPMシステムの場合のみ)

次のURLがロード・バランシング・ルーター・アドレスを使用していることも確認します。

- http://soa.mycompany.com:80/wsm-pm

- http://soa.mycompany.com:80/soa-infra

- http://soa.mycompany.com:80/soa/composer

- http://soa.mycompany.com:80/integration/worklistapp

- http://soa.mycompany.com:80/sdpmessaging/userprefs-ui

- http://soa.mycompany.com:80/b2bconsole

- http://soa.mycompany.com:80/bpm/composer(BPMシステムの場合のみ)

- http://soa.mycompany.com:80/bpm/workspace(BPMシステムの場合のみ)

次の手順に従って、HTTP ServerからSOA_CLusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

1. WLS_SOA2の実行中に、管理コンソールからWLS_SOA1を停止します。

2. 次のURLにアクセスして、適切な機能を検証します。

- WEBHOST1:7777/wsm-pm

- WEBHOST1:7777/soa-infra

- WEBHOST1:7777/soa/composer

- WEBHOST1:7777/integration/worklistapp

- WEBHOST1:7777/sdpmessaging/userprefs-ui

- WEBHOST1:7777/b2bconsole

- WEBHOST1:7777/bpm/composer(BPMシステムの場合のみ)

- WEBHOST1:7777/bpm/workspace(BPMシステムの場合のみ)

3. 管理コンソールから、WLS_SOA1を開始します。

4. WLS_SOA2を停止します。

5. 前述のステップ2のURLにアクセスして、適切な機能を検証します。

5.13.15 サーバー間で共有するJMS永続ストアの構成

2つのノードから参照できるディレクトリに、すべての永続ストアの場所を構成します。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。

Fusion Middleware管理コンソールで、「サービス」、永続ストア、「Persistence_Store_Name」、「ディレクトリ」の順に選択します。

保留されているJMSメッセージを再開できるようにするには、クラスタ内の他のサーバーで使用可能な永続記憶域ソリューション(NAS、SAN)上の場所を指定する必要があります。したがって、入力するディレクトリは、WLS_SOA1とWLS_SOA2の両方からアクセスできる必要があります。このディレクトリは、サーバーが再起動される前に存在している必要があります。

注意:

JMSメッセージ、トランザクション・ログおよびファイル・ストアでのロックの解放に関する重要な情報は、「NFSでのファイル・ストアの使用に関する考慮事項」を参照してください。

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

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーに対してトランザクション回復サービスの移行機能を利用するためには、サーバーとそのバックアップ・サーバーで利用可能な場所、可能であればデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)にトランザクション・ログを格納する必要があります。デフォルトの永続ストアを構成する手順は、次のとおりです。

1. 「ドメイン構造」ツリーで、「環境」を開き、「サーバー」を選択します。

2. 変更するサーバーを選択します。

3. 「構成」、「サービス」タブの順に選択します。

4. 「デフォルト・ストア」の「ディレクトリ」フィールドに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定する必要があります。したがって、入力するディレクトリは、WLS_SOA1とWLS_SOA2の両方からアクセスできる必要があります。このディレクトリは、サーバーが再起動される前に存在している必要があります。

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

Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定する必要があります。

1. 管理コンソールの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

2. 左側のペインで、「環境」→「クラスタ」を選択します。

3. 「SOA_Cluster」を選択します。

4. 「HTTP」を選択します。

5. 次の値を設定します。

- フロントエンド・ホスト: soa.mycompany.com
フロントエンドHTTPポート: 80

- フロントエンドHTTPSポート: 空白のまま

注意:

このアドレスが正しく、使用可能である(ロード・バランシング・ルーターが稼働している)ことを確認してください。アドレスのhttp://やホスト名の末尾/など、値が誤っていると、仮想IPを使用してもSOAシステムにアクセスできません。

6. 「保存」をクリックします。

7. 変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

8. すでにサーバーを起動している場合、この変更にはクラスタの管理対象サーバーの再起動が必要であることに注意してください。

注意:

SOAシステムでは、次のようにコールバック・サーバーURLを計算します。

- SOAへのリクエストが外部サービスから発行されたものであったり、内部サービスがSOAにリクエストを発行したりした場合、SOAは、クライアントによって指定されているコールバック・サーバーURLを使用します。

- 外部または内部サービスへのリクエストがSOAから発行されている場合は、SOAが発行元であるため、コールバックURLをSOAリクエストに動的に移入できません。しかし、callbackServerURLが特定参照のバインディング・プロパティに指定されている場合は、callbackServerURLが使用されます。(これは、コンポジットをモデル化するときに設定するか、実行時にOracle Enterprise Managerコンソールからアクセス可能なMBeanを使用して設定できます。)これにより、サービス・コールごとに異なるコールバック・サーバーURLを割り当てることができます。したがって、外部サービスからのコールバック・サーバーURLは、内部サービスへのコールバック・サーバーURLと異なります。
ただし、callbackServer URLがその参照のバインディング・プロパティに指定されていない場合、SOAシステムは、soa-infra-configに指定されているコールバック・サーバーURLを使用します。soa-infra-configにコールバック・サーバーURLが指定されていない場合、システムでは、WLSに指定されているフロントエンド・ホストがコールバック・サーバーURLとして使用されます。WLSにフロントエンド・ホストが指定されていない場合、システムでは、WLS MBean APIで指定されているローカル・ホスト名がコールバック・サーバーURLとして使用されます。

Oracle HTTP Serverによってフロントエンド処理されるSOA高可用性インストールでは、実質的なバックエンド・サーバーのOracle HTTP Serverポートでの監視が必要になります。すなわち、SOA管理対象サーバーにデプロイされたすべてのコンポーネントがデプロイメントで使用される場合です。HTTP/HTTPSポートをpingし、事前に決められた応答が返されることを予期する単純なHTTPモニターであれば十分です。特定のSOAコンポーネント(B2Bなど)のみが使用されている場合は、使用中のコンポーネントの状態を検証するために、管理対象サーバー全体のより深いレベルまでチェックするモニターを使用することも考えられます。お使いのロード・バランサでのHTTPモニターの設定について、ロード・バランサのベンダーにご確認ください。

フロントエンドHTTPのホストとポートを設定しない場合、Oracle B2Bからドキュメント定義XSDを取得しようとすると、次のメッセージを受け取ります。

An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when
clustering is enabled.

5.13.18 コンポジットに対する直接バインディング/RMI呼出し用のWLSクラスタ・アドレスの設定

コンポジットへの直接バインディングを使用する場合は、SOA_ClusterのWLSクラスタ・アドレスを設定する必要があります。そのためには、次の手順に従ってください。

1. 管理コンソールの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

2. 左側のペインで、「ドメイン構造」ウィンドウの「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. 「SOA_Cluster」クラスタを選択します。

4. 「構成」→「一般」タブで、「クラスタ・アドレス」フィールドにSOAHOST1VHN1:8001,SOAHOST2VHN1:8001と入力します。

5. 「保存」をクリックします。

6. 変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

7. サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。

注意:

直接バインディングでの非同期リクエスト/レスポンスの場合、SOAコンポジットでは、コールバックのBeanを検索するために、呼び出されたサービスのJNDIプロバイダURLを指定する必要があります。

soa-infra configプロパティは指定されていないが、WebLogic Serverクラスタ・アドレスは指定されている場合、クラスタ・アドレスを使用してJNDIプロバイダURLが形成されます。このクラスタ・アドレスには、クラスタ化されたサーバーのIPアドレスにマップする単一のDNS名、またはサーバーのip:portのカンマ区切りリストを使用できます。または、soa-infra configプロパティJndiProviderURL/SecureJndiProviderURLがユーザーによって明示的に指定されている場合は、同じ目的でそれを使用することもできます。

5.13.19 アプリケーションのデプロイ

SOAコンポジット・アプリケーションは、Oracle Enterprise Manager Fusion Middleware ControlのSOAコンポジットのデプロイ・ウィザードでデプロイできます。SOAコンポジットのデプロイ・ウィザードで、次のいずれかをデプロイします。

- 最初の新しいSOAコンポジット・アプリケーション

- 旧リビジョン(1.0など)と新リビジョン(2.0など)。旧リビジョンへの影響はありません。最後にデプロイされたリビジョンが、そのコンポジットの新しいデフォルト・リビジョンになります(デプロイメントのこの後の手順で他のリビジョンを指定しない場合にかぎります)。

- 現在デプロイされているもの(1.0など)とは異なるリビジョンをすでに持っているSOAコンポジット・アプリケーションの複数のSOAコンポジット・アプリケーション・リビジョン(リビジョン2.0、3.0、4.0など)が含まれているバンドル(ZIPファイル)。このオプションを使用すると、リビジョン1.0、2.0、3.0および4.0を同時にデプロイできます。バンドルには様々なコンポジットのリビジョンを含めることもできます。すべてのリビジョンが同一のコンポジット・アプリケーションのリビジョンでなければならないという制約はありません。

デプロイメントでは、SOAサービス・インフラストラクチャのコンポジット・アプリケーションを抽出し、アクティブ化します。アプリケーションがデプロイされると、インスタンスの作成、プロパティの構成、パフォーマンスの監視、インスタンスのライフサイクルの管理、ポリシーとフォルトの管理などの管理タスクを実行できます。

注意:

アプリケーションの既存のリビジョンを再デプロイする場合は、このウィザードを使用しないでください。かわりに、SOAコンポジットの再デプロイ・ウィザードを使用してください。

アプリケーションをデプロイする手順は、次のとおりです。

1. 次のいずれかのオプションを使用して、SOAコンポジットのデプロイ・ウィザードにアクセスします。

SOAインフラストラクチャのメニュー

ナビゲータのSOAフォルダ

SOAインフラストラクチャのホーム・ページ

SOAコンポジットのメニュー

1. 「SOAデプロイ」→「デプロイ」を選択します。

1. 「soa-infra」を右クリックします。

2. 「SOAデプロイ」→「デプロイ」を選択します。

1. 「デプロイ済コンポジット」タブをクリックします。

2. 「コンポジット」表の上にある「デプロイ」をクリックします。

1. 「SOAデプロイ」→「別のコンポジットをデプロイ」を選択します。

「アーカイブの選択」ページが表示されます。

図sca_deploy.gifの説明

2. 「アーカイブまたは展開済ディレクトリ」セクションで、デプロイするSOAコンポジット・アプリケーションのアーカイブを指定します。アーカイブには、デプロイするコンポジットのプロジェクト・ファイルが格納されています(たとえば、単一アーカイブのHelloWorld_rev1.0.jar、または複数アーカイブのOrderBooking_rev1.0.zip)。

3. 「構成プラン」セクションで、アーカイブに含める構成プランのオプションを指定します。構成プランには、異なる環境で使用するURLとプロパティ値を定義できます。構成プランは、プロセスのデプロイメント時に、プロジェクトを別のターゲット環境に適合させるために置換する必要のある値に関するSOAプロジェクトを検索する際に使用されます。

4. 「次へ」をクリックします。
「ターゲットの選択」ページが表示されます。

5. SOAコンポジット・アプリケーション・アーカイブのデプロイ先WebLogic Serverまたはクラスタを選択します。アーカイブは、複数のサーバーおよびクラスタにデプロイできます。

6. 「次」をクリックします。

7. SOAコンポジット・アプリケーションをデフォルトのリビジョンとしてデプロイするかどうかを選択します。デフォルトのリビジョンは、新しいリクエストを受信するとインスタンス化されます。

8. 「デプロイ」をクリックします。

9. デプロイメントが完了したら、「閉じる」をクリックします。

関連項目:

Oracle JDeveloperでの構成プランの作成とアプリケーションのデプロイの手順は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

5.13.20 WLS_SOAサーバーのサーバー移行の構成

SOAシステムの高可用性アーキテクチャでは、一部のシングルトン・サービスを障害から保護するためにサーバー移行を利用します。サーバー全体の移行の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

WLS_SOA1管理対象サーバーは、障害発生時にSOAHOST2で再起動するように構成され、WLS_SOA2管理対象サーバーは、障害発生時にSOAHOST1で再起動するように構成されます。このような構成では、WLS_SOA1サーバーおよびWLS_SOA2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。

サーバー移行によって、サーバーまたはプロセスの障害時に、管理対象サーバーが別のノードにフェイルオーバーするよう設定する手順は、次のとおりです。

WebLogic管理対象サーバーのサーバー移行を構成する手順は、次のとおりです。

- ステップ1: サーバー移行leasing表のユーザーと表領域を設定する

- ステップ2: Oracle WebLogic管理コンソールを使用してGridLinkデータ・ソースまたはマルチ・データ・ソースを作成する

- ステップ3: ノード・マネージャのプロパティ・ファイルを編集する

- ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する

- ステップ5: サーバー移行ターゲットを構成する

- ステップ6: サーバー移行をテストする

5.13.20.1 サーバー移行leasing表のユーザーと表領域の設定

最初の手順では、サーバー移行leasing表のユーザーと表領域を設定します。

注意:

同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。この場合、データベース・リース用にデータ・ソースおよびマルチ・データ・ソースを再作成する必要はありませんが、これらをサーバー移行用に構成しているクラスタにターゲット指定しなおす必要があります。

1. leasingという名前の表領域を作成します。たとえば、ユーザーsysdbaでSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;

2. leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by welcome1;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

3. leasing.ddlスクリプトを使用してleasing表を作成します。

1. WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。

2. データベースにleasingユーザーとして接続します。

3. SQL*Plusでleasing.ddlスクリプトを実行します。

SQL> @Copy_Location/leasing.ddl;

5.13.20.2 Oracle WebLogic管理コンソールを使用したGridLinkデータ・ソースまたはマルチ・データ・ソースの作成

マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。

- このデータ・ソースが非XAデータ・ソースであることを確認します。

- Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。

- したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。データ・ソースは、グローバル・トランザクションのサポートを必要としません。

- これらのデータ・ソースをクラスタにターゲット指定します。

- データ・ソースの接続プールの初期容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」、「接続プール」タブの順にクリックし、「初期容量」フィールドに0(ゼロ)を入力します。

- ONSデーモンがデータベース・サーバーで常に実行中であることを確認します。ONSデーモンをデータベース・サーバーで起動するには、onsctlコマンド(start)を実行します。

GridLinkデータソースの作成

GridLinkデータ・ソースを作成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. 「データ・ソースの概要」ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択します。

5. 次の情報を入力します。

1. 「名前」フィールドで、データ・ソースの論理名を入力します。たとえば、gridlinkと入力します。

2. JNDIの名前を入力します。たとえば、jdbc/gridlinkと入力します。

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

6. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。

7. 「個別のリスナー情報の入力」を選択して、「次へ」をクリックします。

8. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名name example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(example.comなど)を含むRACサービス名を登録または追加することをお薦めします。

- ホスト名: データベースをホストするサーバーのDNS名またはIPアドレス。Oracle GridLinkサービスとインスタンス間の接続の場合、特定のマルチ・データ・ソースの各データ・ソースで同じ名前にする必要があります。

- Port: データベース・サーバーが接続リクエストをリスニングするポート。

- データベース・ユーザー名: データベース・ユーザー名。たとえば、myDataBaseと入力します。

- パスワード: パスワード。たとえば、myPassword1と入力します。

- パスワードを確認して、「次へ」をクリックします。

ヒント:

詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

コンソールにより、完全なJDBC URLが自動的に生成されます。例:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))

9. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。
Oracle WebLogicにより、管理サーバーからデータベースへの接続の作成が試行されます。接続テストの結果がページの上部に表示されます。テストに失敗した場合は、構成エラーをすべて修正してテストを再試行します。

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

10. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- 「ONSホストとポート」で、ONSベースのFANイベントを受け取るためにONSデーモンが接続するリスニング・アドレスとリスニング・ポートのカンマ区切りのリストを入力します。単一クライアント・アクセス名(SCAN)アドレスを使用すると、FAN通知にアクセスできます。

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

11. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。「次へ」をクリックします。

12. 「ターゲットの選択」ページで「Dept1_Cluster1」をターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。

13. 「終了」をクリックします。

14. 「変更のアクティブ化」をクリックします。

マルチ・データ・ソースの作成

マルチ・データ・ソースを作成する手順は、次のとおりです。

1. 管理者の資格証明を使用して、管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「サービス」ノードを開き、次に、「データ・ソース」ノードを開きます。

3. 「チェンジ・センター」で「ロックして編集」をクリックします。

4. 「新規」をクリックしてから、「マルチ・データ・ソース」をクリックします。

5. 名前として、leasingと入力します。

6. JNDI名として、jdbc/leasingと入力します。

7. アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。「次へ」をクリックします。

8. ターゲット・クラスタを選択します。「次へ」をクリックします。

9. 「非XAドライバ」(デフォルト)を選択します。「次へ」をクリックします。

10. 「新しいデータ・ソースの作成」をクリックします。

11. 名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。

注意:

leasing表のマルチ・データ・ソースを作成する場合は、名前を<MultiDS>-rac0や<MultiDS>-rac1などの形式で入力します。

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

13. 「グローバル・トランザクションのサポート」の選択を解除します。「次へ」をクリックします。

14. リース・スキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。

15. 「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。

16. データ・ソースをクラスタにターゲット指定します。

17. データ・ソースを選択して、右の画面に追加します。

18. Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。

19. 2つ目のデータ・ソースをマルチ・データ・ソースに追加します。

20. 保存して、「変更のアクティブ化」をクリックします。

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

nodemanager.propertiesファイルを編集して、サーバー移行を構成するノードごとに次のプロパティを追加する必要があります。

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

- Interface: 浮動IPのインタフェース名(eth0など)を指定します。

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

注意:

Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: Interface="Local Area Connection"

- NetMask: 浮動IPのインタフェースのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります(255.255.255.0は一例です)。実際の値は、ネットワークにより異なります。

- UseMACBroadcast: ARPパケットの送信時にノードのMACアドレスを使用するかどうか、つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力で、次のようなエントリが表示されることを確認します。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:

サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合、次の手順は必要ありません。

1. nodemanager.propertiesファイルで次のプロパティを設定します。

- StartScriptEnabled: このプロパティをtrueに設定して、ノード・マネージャが管理対象サーバーで起動するようにします。

2. WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、OIMHOST1とOIMHOST2でノード・マネージャを起動します。

注意:

共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個々のパラメータを指定します。たとえば、HOSTnで異なるインタフェース(eth3)を使用するには、Interface環境変数をHOSTn> export JAVA_OPTIONS=-DInterface=eth3のように使用して、この変数がシェル内で設定された後にノード・マネージャを起動します。

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

wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。

注意:

Windowsでは、このスクリプトはwlsifconfig.cmdであり、管理者権限を持つユーザーがこれを実行できます。

1. PATH環境変数に次のファイルが含まれていることを確認します。

表5-9 PATH環境変数に必要なファイル

ファイル

格納されているディレクトリ

wlsifconfig.sh

DOMAIN_HOME/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

WL_HOME/common

2. wlsifconfig.shスクリプトに対するsudo構成権限を付与します。

- パスワード・プロンプトを使用しないで機能するsudoを構成します。

- セキュリティ上の理由から、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定することをお薦めします。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。

- WebLogicユーザー(oracle)に、パスワードによる制限なしのsudo権限を付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

- WebLogicユーザーがこのスクリプトを実行できることを確認します。次の例は、oracleのsudo実行権限をifconfigとarpingにも付与する/etc/sudoers内のエントリを示しています。

oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

注意:

この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。

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

まず、すべての使用可能なノードをクラスタのメンバーに割り当て、次に、サーバー移行用に構成された各サーバーに候補となるマシン(適切な順序で)を指定します。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。

3. 「名前」列で、移行を構成するクラスタをクリックします。

4. 「移行」タブをクリックします。「ロックして編集」をクリックします。

5. 「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。

6. 自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。

7. 「保存」をクリックします。「変更のアクティブ化」をクリックします。

8. サーバー移行の候補マシンを設定します。このタスクは、次の手順に従って、すべての管理対象サーバーについて実行する必要があります。

1. 管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。

ヒント:

「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックして、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動し、サーバーが実行されているマシンを表示します。サーバーが自動的に移行される場合、これは実際の構成とは異なります。

2. 移行を構成するサーバーを選択します。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。

5. 「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

6. 「保存」をクリックしてから、「変更のアクティブ化」をクリックします。

7. 追加の管理対象サーバーに対して、前述の手順を繰り返します。

8. 管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。

5.13.20.6 サーバー移行のテスト

サーバー移行が適切に機能していることを確認する手順は次のとおりです。

SOAHOST1から次の処理を実行します。

1. WLS_SOA1管理対象サーバーを強制停止します。
これを行うには、このコマンドを実行します:

SOAHOST1> kill -9 <pid>

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

SOAHOST1> ps -ef | grep WLS_SOA1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_SOA1のpidを確認します。

MW_HOME\jrockit_160_<version>\bin\jps -l -v

2. ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。

3. ノード・マネージャがWLS_SOA1の2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

SOAHOST2から次の処理を実行します。

1. ローカルのノード・マネージャのコンソールを確認します。ノード1で最後にWLS_SOA1の再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、WLS_SOA1の浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。

2. 同じIPのSOAサービス・インフラストラクチャ・コンソールにアクセスします。

管理コンソールで移行を検証する手順は、次のとおりです。

1. 管理コンソールにログインします。

2. 左側のペインで、「ドメイン」をクリックします。

3. 「監視」タブ、「移行」サブタブの順にクリックします。
「移行ステータス」表に、移行の状態に関する情報が表示されます。

図5-46 管理コンソールの「移行の状態」画面

「図5-46 管理コンソールの「移行の状態」画面」の説明

注意:

Windowsでは、同一マシン上で複数のサーバーを同時に手動で停止し、次に、別のマシンで停止したサーバーの1つを起動しようとしても、IPバインドは機能しません。これは、IPアドレスが削除されていることがnetshによってレポートされても、元のマシンでそのIPアドレスに対する要求が引き続き保持されているために起こります。

これを解決するには、ipconfigユーティリティまたはWindowsネットワーク構成を使用して、ネットワーク構成をチェックする必要があります。どちらを使用した場合も、仮想IPアドレスまたは浮動IPアドレスのいずれかが、サーバーが停止後も引き続き構成されていることが示されます。その場合は、次の手順に従い、Windowsネットワーク構成を使用して、IPアドレスを削除できます。

1. Windowsのコントロール・パネルで、「ネットワーク接続」を選択します。

2. 該当のネットワーク・インタフェースを選択して右クリックし、「プロパティ」を選択します。

3. 「インターネット プロトコル (TCP/IP)」を選択して「プロパティ」ボタンをクリックします。

4. 「詳細設定」を選択します。

5. 該当のIPアドレスを選択して、「削除」ボタンをクリックします。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

5.13.21 トポロジのスケーリング

この高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。

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

この場合は、SOAコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードには、既存の管理対象サーバーのMiddlewareホーム、Oracleホーム(SOA)およびドメイン・ディレクトリが含まれます。

新しいWLS_SOAサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用します(新しい場所にSOAバイナリをインストールしたり、packとunpackを実行したりしないでください)。

トポロジをスケール・アップするには:

1. 管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。

1. 管理コンソールから「環境」→「サーバー」を選択します。

2. クローンを作成する管理対象サーバー(WLS_SOA1など)を選択します。

3. 「クローンの作成」を選択します。

新しい管理対象サーバーにWLS_SOAnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。

この後の手順では、すでにWLS_SOA1を実行しているSOAHOST1に新しいサーバーを追加することを想定しています。

2. リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。仮想ホスト名は、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。
管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。

6. 「リスニング・アドレス」をSOAHOST1VHN1に設定します。

7. 「保存」をクリックします。

8. 変更を保存およびアクティブ化します。

この変更は、管理対象サーバーを再起動するまで有効になりません。

3. クラスタ・アドレスを更新して、新しいサーバーを追加します。

1. 管理コンソールの「ドメイン構造」ウィンドウで「環境」→「クラスタ」を選択します。

2. SOA_Clusterサーバーをクリックします。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:

SOAHOST1VHN1:8001,SOAHOST2VHN1:8001,SOAHOST1VHN2:8001

4. 新しい管理対象サーバーにSOA、BPM(該当する場合)およびUMSのJMSサーバーを作成します。

1. 管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。これには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定する必要があります。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/SOAJMSFileStore_N

2. SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_N)。このJMSサーバーに対して、SOAJMSFileStore_Nを使用します。SOAJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

3. 新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定する必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_N.

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。

4. UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_N)。このJMSサーバーに対して、UMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

5. (BPMシステムの場合のみ)新しいBPMJMSServerの新しい永続ストアを作成して(たとえば、BPMJMSFileStore_N)、このストアのパスを指定します。これには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定する必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N.

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいBPM JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。

6. (BPMシステムの場合のみ)BPMの新しいJMSサーバーを作成します(たとえば、BPMJMSServer_N)このJMSServerにはBPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

7. 新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウで「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列のハイパーリンク)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名はSOAJMSServerXXXXXX形式のランダムな名前で、最初の2つのサーバー(WLS_SOA1とWLS_SOA2)の構成ウィザードJMS構成から生成されます。

サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_Nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。

8. 新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUCMJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

9. (BPMシステムの場合のみ)新たに作成されたBPM JMSサーバーが含まれるように、BPMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「BPMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。BPMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。BPMJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたBPMJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「BPMJMSServerXXXXXX」をクリックします。このサブデプロイメントに、BPMJMSServer_Nと呼ばれる、BPMの新しいJMSサーバーを追加します。「保存」をクリックします。

5. デプロイするコンポジットのOracle Coherenceを構成します。第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」を参照してください。

注意:

サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例:

Dtangosol.coherence.localhost=SOAHOST1VHNn

6. 新しいサーバーに対してTX永続ストアを構成します。これは、共有記憶域についての推奨事項で示されているように、他のノードから参照できる場所に構成します。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。

7. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Enterprise Managerコンソールで、「管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

8. 管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーを停止します。

2. 新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。

3. 新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。

9. 新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

これはスケール・アップ操作であるため、ノード・マネージャ、サーバー移行に対して構成された環境および新しいSOA管理対象サーバーの浮動IPがノードに用意されている必要があります。

次の手順を実行してサーバー移行を構成します。

1. 管理コンソールにログインします。

2. 左側のペインで、「環境」を開き、「サーバー」を選択します。

3. 移行を構成する新しい管理対象サーバーの名前を選択します。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。
たとえば、すでにWLS_SOA1が実行されているSOAHOST1上の新しい管理対象サーバーには、SOAHOST2を選択します。すでにWLS_SOA2が実行されているSOAHOST2上の新しい管理対象サーバーには、SOAHOST1を選択します。

移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

10. この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。

1. 管理対象サーバーWLS_SOAnを停止します。
これを行うには、kill -9 <pid>を管理対象サーバーのPIDに対して実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを実行します。

注意:

Windowsの場合は、 taskkill コマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_SOAnのpidを確認します。

MW_HOME\jrockit_160_<バージョン>\bin\jps -l -v

2. ノード・マネージャ・コンソールを確認します。WLS_SOAnの浮動IPが無効になっていることを示すメッセージが表示されています。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージが、ノード・マネージャによってログに記録されます。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

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

トポロジのスケール・アウトでは、SOAで構成された新しい管理対象サーバーを新しいノードに追加します。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

- SOAで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。

- 新しいノードが、WebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやSOAバイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります)。

注意:

共有記憶域内に既存のインストールが存在しない場合は、新しいノードでWebLogic ServerとSOAをインストールする必要があります。第5.13項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」を参照してください。

注意:

異なるノードにおいてORACLE_HOMEまたはWL_HOMEが複数のサーバーで共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して、そのノードに共有記憶域内のインストールを追加するには、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、user_home/bea/beahomelistファイルを編集します。次の手順を参照してください。

トポロジをスケール・アウトするには、次の手順を実行します。

1. 新しいノードで、SOAのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
SOAHOSTn>./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. 管理コンソールを使用して、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。これにWLS_SOAnという名前を付けます。nは新しいマシンに割り当てる番号です。

注意:

これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。

7. リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。仮想ホスト名は、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。
次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。

6. 「リスニング・アドレス」をSOAHOSTnVHN1に設定します。

7. 「保存」をクリックします。

8. 変更を保存およびアクティブ化します。

変更内容は、管理対象サーバーが再起動されるまでは有効になりません。

8. クラスタ・アドレスを更新して、新しいサーバーを追加します。

1. 管理コンソールで「環境」→「クラスタ」を選択します。

2. SOA_Clusterサーバーをクリックします。SOA_Clusterの「設定」画面が表示されます。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:

SOAHOST1VHN1:8001,SOAHOST2VHN1:8001,SOAHOSTNVHN1:8001

9. 新しい管理対象サーバーにSOA、BPM(該当する場合)およびUMSのJMSサーバーを作成します。

1. 管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、 SOAJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore _N

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

2. SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_N)。このJMSサーバーに対して、SOAJMSFileStore_Nを使用します。SOAJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

3. 新しいUMSJMSServerの新しい永続ストアを作成し、UMSJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore _N

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

注意:

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。

4. UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_N)このJMSサーバーに対して、UMSJMSFileStore_Nを使用します。UMSJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

5. (BPMシステムの場合のみ)新しいBPMJMSServerの新しい永続ストアを作成し、BPMJMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.13.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore _N

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

注意:

新しいBPM JMSサーバーのストアとしてSOAJMSFileStore_Nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。

6. (BPMシステムの場合のみ)BPMの新しいJMSサーバーを作成します(たとえば、BPMJMSServer_N)このJMSサーバーに対して、BPMJMSFileStore_Nを使用します。BPMJMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

7. 新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウで、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(「名前」列のハイパーリンク)をクリックします。SOAJMSModuleの「設定」ページで、「サブデプロイメント」タブを開きます。SOAJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_Nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。

8. 新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブを開きます。UMSJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュールは、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUMSJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_Nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

9. (BPMシステムの場合のみ)新たに作成されたBPM JMSサーバーが含まれるように、BPMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「BPMJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。BPMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。BPMJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュールは、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたBPMJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「BPMJMSXXXXXX」をクリックします。このサブデプロイメントに、BPMJMSServer_Nと呼ばれる、BPMの新しいJMSサーバーを追加します。「保存」をクリックします。

10. 次のようにpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

SOAHOST1> ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをSOAHOSTNにコピーします。

SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_BASE/product/fmw/soa/common/bin

次のようにSOAHOSTNでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。

SOAHOSTN> cd ORACLE_BASE/product/fmw/soa/common/bin

SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar

11. 第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、コンポジットをデプロイする場合のOracle Coherenceを構成します。

注意:

サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例:

Dtangosol.coherence.localhost=SOAHOSTnVHN1

12. 新しいサーバーに対してTX永続ストアを構成します。これは、共有記憶域についての推奨事項で示されているように、他のノードから参照できる場所に構成します。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。

13. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAN管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

14. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。

SOAHOSTN> WL_HOME/server/bin/startNodeManager <new_node_ip>

15. 管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーをすべて停止します。

2. 新たに作成した管理対象サーバーWLS_SOAnが実行されていることを確認します。

3. 新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。

16. 新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャと、ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しいSOA管理対象サーバーの浮動IPが存在します。

次の手順を実行してサーバー移行を構成します。

1. 管理コンソールにログインします。

2. 左側のペインで、「環境」を開き、「サーバー」を選択します。

3. 移行を構成するサーバー(ハイパーリンクで表示)を、表の「名前」列から選択します。このサーバーの「設定」ページが表示されます。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。

注意:

新しいサーバーの移行ターゲットには、負荷が最小のマシンを指定します。このノードのリソースが追加の管理対象サーバーの持続に十分対応できるように、必須の容量計画を立てる必要があります。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

9. この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。
1. 管理対象サーバーWLS_SOAnを停止します。

2. そのためには、管理対象サーバーのPIDに対してkill -9 <pid>を実行します。ノードのPIDは、ps -ef | grep WLS_SOAnを使用して確認できます。

注意:

Windowsの場合は、 taskkill コマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_SOAnのpidを確認します。

MW_HOME\jrockit_160_<バージョン>\bin\jps -l -v

3. ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。

4. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

5. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

5.14 Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンを使用するOracle Service Busの高可用性の構成

この項では、Oracle Service Busの設定手順について説明し、Oracle BPEL/Oracle PM、Oracle Mediator、Oracle Human WorkflowおよびOracleデシジョン・サービスの他、Oracle B2BおよびOracle User Messaging Serviceなど、Oracle SOAサービス・インフラストラクチャ・システムに含まれる他のサービス・エンジンの設定手順についても説明します。

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

- 第5.14.1項「環境の準備: SOAの高可用性構成の設定前に必要な手順」

- 第5.14.2項「Oracle Fusion Middlewareホームのインストール」

- 第5.14.3項「SOAHOST1のVIP1とVIP3およびSOAHOST2のVIP2とVIP4の有効化」

- 第5.14.4項「SOAとOSBのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行」

- 第5.14.5項「SOAHOST1での管理サーバー用boot.propertiesの作成」

- 第5.14.6項「SOAHOST1での管理サーバーの起動と検証」

- 第5.14.7項「管理サーバーおよび管理対象サーバーWLS_SOAn/WLS_OSBnに対するホスト名の検証の無効化」

- 第5.14.8項「コンポジットのデプロイでのOracle Coherenceの構成」

- 第5.14.9項「Oracle Service Busの結果キャッシュのOracle Coherenceの構成」

- 第5.14.10項「B2Bキューの接続宛先識別子の設定」

- 第5.14.11項「SOAHOST1でのシステムの起動」

- 第5.14.12項「pack/unpackユーティリティを使用したSOAHOST2、OSBHOST1およびOSBHOST2へのドメイン構成の伝播」

- 第5.14.13項「第2ノードのXEngineファイルの抽出」

- 第5.14.14項「SOAHOST2、OSBHOST1およびOSBHOST2でのシステムの起動」

- 第5.14.15項「管理サーバーおよび管理対象サーバーWLS_SOAnとWLS_OSBnのOracle HTTP Serverの構成」

- 第5.14.16項「Oracle HTTP Serverを使用したアクセスの検証」

- 第5.14.17項「フロントエンドHTTPのホストおよびポートの設定」

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

- 第5.14.19項「アプリケーションのデプロイ」

- 第5.14.20項「WLS_SOAサーバーのサーバー移行の構成」

- 第5.14.21項「WLS_OSBサーバーのサーバー移行の構成」

- 第5.14.22項「トポロジのスケーリング」

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

注意:

このガイドで定義されているアーキテクチャとデプロイメント手順を使用することにより、単純なクラスタ・デプロイメントを実現できます。各章に記載されている手順は、このトポロジおよび他の類似する高可用性トポロジを、該当するFusion Middlewareコンポーネントで実現する場合の基礎的要素として使用できます。また、本番デプロイメントでは、セキュリティ・ポリシーと一元的なLDAPサーバーを関連付けるなど、この他にも必要な手順を使用することが予想されます。セキュアな複数層アーキテクチャおよびデプロイメント手順の詳細は、構成対象のコンポーネントのエンタープライズ・デプロイメント・ガイドを参照してください。

図5-47は、この項の構成手順で作成するアーキテクチャの例を表しています。

図5-47 Oracle SOAサービス・インフラストラクチャ、コンポーネント・サービス・エンジンおよびOracle Service Busの高可用性アーキテクチャ

「図5-47 Oracle SOAサービス・インフラストラクチャ、コンポーネント・サービス・エンジンおよびOracle Service Busの高可用性アーキテクチャ」の説明

図5-47は、2つのOracle WebLogic ServerでOracle Service Busの2ノード・クラスタが実行されている様子を示しています。Oracle WebLogic Serverは、受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。ロード・バランサは、システムをフロントエンド処理し、クライアントから受信したリクエストを2つのOracle HTTP Serverに配布します。この構成では、Oracle RACデータベースを使用して、JMSレポート作成プロバイダからのレポート作成データ、およびJTAトランザクション・マネージャでLLRを使用する場合の2フェーズ・コミット・ログ(レポート作成データ・プロバイダによってのみ使用される)を格納します。また、クラスタ内のサーバーからのハートビート・データ(WebLog Serverのサーバー全体の移行機能で使用)を格納する場合もあります。トランザクションの永続ストアおよびJMSストアは、共有記憶域に置かれます。仮想IPアドレス(VIP)によって、管理サーバーおよびOracle Service Bus管理対象サーバーの手動フェイルオーバーが提供されます(サーバーの移行で使用)。

注意:

前述の図では、Oracle Service Busの高可用性構成を見やすくするために、Oracle SOAサービス・インフラストラクチャの高可用性構成は図示されていません。Oracle SOAサービス・インフラストラクチャの図は、図5-5を参照してください。

管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。

5.14.1 環境の準備: SOAの高可用性構成の設定前に必要な手順

次の各項では、Oracle SOAサービス・インフラストラクチャの高可用性構成を設定する前に必要となる手順について説明します。

プラットフォーム固有のコマンドの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteインストレーション・ガイド』を参照してください。

- 第5.14.1.1項「データベースに関する前提条件」

- 第5.14.1.2項「VIPとIPの前提条件」

- 第5.14.1.3項「共有記憶域に関する前提条件」

- 第5.14.1.4項「LDAPプロバイダのインストールと構成」

- 第5.14.1.5項「システム・クロックの同期」

- 第5.14.1.6項「ディレクトリおよびディレクトリ環境変数の用語」

- 第5.14.1.7項「データベース・リポジトリのインストールと構成」

- 第5.14.1.8項「Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード」

- 第5.14.1.9項「ロード・バランサの仮想サーバー名とポートの構成」

- 第5.14.1.10項「WEBHOST1およびWEBHOST2へのOracle HTTP Serverのインストール」

5.14.1.1 データベースに関する前提条件

Oracle SOA Suiteでは、サポートされているデータベースおよびスキーマが存在している必要があります。Oracle Service Busは、JMSレポート作成プロバイダおよびOWSM Policy Managerの場合のみデータベースに依存します。

データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。

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

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

5.14.1.2 VIPとIPの前提条件

表5-10に示されているように、管理サーバーとSOAおよびOSBの管理対象サーバーがそれぞれ異なる仮想IPをリスニングするように構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。各VIPが使用可能であり、SOAHOST1、SOAHOST2およびクライアント・マシンからアクセスできることを確認してから、インストールを実行してください。

表5-10 仮想ホスト

仮想IP

VIPのマップ先

説明

VIP0

SOAHOST1VHN0

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

VIP1

SOAHOST1VHN1

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

VIP2

SOAHOST2VHN1

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

VIP3

OSBHOST1VHN1

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

VIP4

OSBHOST2VHN1

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

5.14.1.3 共有記憶域に関する前提条件

障害発生時に適切にリカバリできるようにするには、すべてのノードからアクセスできる場所にJMSとトランザクションの両方のログを格納して、管理対象サーバーで障害が発生した後にすべてのノードが操作を再開できるようにします。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表5-11は、共有記憶域の内容を示しています。

表5-11 共有記憶域の内容

サーバー

データの型

共有記憶域のボリューム

ディレクトリ

ファイル

WLS_SOA1

Txログ

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

共通の場所(WebLogicサーバーにより決められたストア)

WLS_SOA2

Txログ

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs

共通の場所(WebLogicサーバーにより決められたストア)

WLS_OSB1

Txログ

VOL1

ORACLE_BASE/admin/domain_name/osb_cluster_name/tlogs

共通の場所(WebLogicサーバーにより決められたストア)

WLS_OSB2

Txログ

VOL1

ORACLE_BASE/admin/domain_name/osb_cluster_name/tlogs

共通の場所(WebLogicサーバーにより決められたストア)

WLS_SOA1

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

共通の場所である、サーバーごとに個別のストア(SOAJMSStore1、UMSJMSStore1など)

WLS_SOA2

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

共通場所である、サーバーごとに個別のストア(SOAJMSStore2、UMSJMSStore2など)

WLS_OSB1

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/osb_cluster_name/jms

共通の場所である、サーバーごとに個別のストア(WseeFileStore_auto_1など)

WLS_OSB2

JMSストア

VOL1

ORACLE_BASE/admin/domain_name/osb_cluster_name/jms

共通の場所である、サーバーごとに個別のストア(WseeFileStore_auto_2など)

共有記憶域にはNASやSANなどのデバイスを使用できます。具体的には、NFSマウント・システムの場合、ファイルのロックに関連する別の問題および突然のノード障害が検出されます。『Oracle Fusion Middlewareリリース・ノート』をチェックし、記憶域のベンダーに、マウント・オプションとして使用する主な推奨パラメータについて問い合せてください。NASデバイス別のコマンド例を次に示します。この項で指定しているオプションは、実際のオプションと異なる場合があります。

SOAHOST1> mount nasfiler:/vol/volX/FMWshared
MW_HOME -t nfs -o
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

5.14.1.4 LDAPプロバイダのインストールと構成

本番環境では、Oracle SOA Suiteの高可用性トポロジに外部のLDAPポリシー・ストアが必須です。サポートされているポリシー・ストアの詳細と、LDAPの構成手順は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.14.1.5 システム・クロックの同期

高可用性SOAのデプロイメントでは、各クラスタ・ノードのシステム・クロックを同期することが必要です。

5.14.1.6 ディレクトリおよびディレクトリ環境変数の用語

次のリストは、この章で使用するディレクトリと変数について説明しています。

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

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

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

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

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

- DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。

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

このディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。

ORACLE_BASE:

/u01/app/oracle

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

ORACLE_BASE/product/fmw

WL_HOME:

MW_HOME/wlserver_10.3

ORACLE_HOME:

MW_HOME/soa

ORACLE_COMMON_HOME:

MW_HOME/oracle_common

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

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/

共有記憶域の場所:

Shared storage location: ORACLE_BASE/admin/domain_name/aserver

5.14.1.7 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

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

自動ストレージ管理

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

- インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clusterデータベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

データベースの初期化パラメータ

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

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

パラメータ

必要な値

パラメータ・クラス

PROCESSES

300以上

静的

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

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

SQL> SHOW PARAMETER processes

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

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

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

注意:

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

5.14.1.8 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード

Oracle SOA Suiteのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとOracle SOAスキーマをReal Application Clusterデータベースにインストールします。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

5.14.1.8.1 RCUの実行

RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。

1. Linuxでは、RCU_Home/binに移動して、次のコマンドを使用します。

./rcu

2. 「ようこそ」画面で「次へ」をクリックします。

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

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

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

- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを指定します: SOADBHOST1VIRTUAL

- ポート: データベースのポート番号: 1521

- サービス名: データベースのサービス名を入力します: soaha.mycompany.com

- ユーザー名: SYS

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

- ロール: SYSDBA

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

6. 次のような警告メッセージを受信する場合があります。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。

7. その場合は、「無視」または「停止」をクリックします。

8. 「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、SOAHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。

- 次のスキーマを選択します。

- 「AS共通スキーマ」で、メタデータ・サービスを選択します。

- SOAサービス・インフラストラクチャで、SOAサービス・インフラストラクチャとユーザー・メッセージングを選択します。

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

10. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。

11. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

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

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

RCUの使用の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

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

Oracle WebLogic Serverトランザクション・マネージャがトランザクションの状態情報を問い合せて、WebLogic Serverコンテナで障害が発生した後の処理中トランザクションのリカバリ時に、commitやrollbackなどの適切なコマンドを発行できるようにするには、適切なデータベース権限が必要です。

トランザクション・リカバリ権限のSOAスキーマを構成する手順は次のとおりです。

1. sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例:

sqlplus "/ as sysdba"

2. sys.dba_pending_transactionsに対してselectをsoaha_soainfraに付与します。

3. 任意のトランザクションに対してforceをsoaha_soainfraに付与します。

注意:

これらの権限は、RCUの操作によって決定されるsoainfraスキーマの所有者に付与する必要があります。

5.14.1.9 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle SOA Suiteの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

Oracle SOA Suiteは、2つのOracle HTTP ServerがWeb層コンポーネントとして含まれた高可用性構成にデプロイされた場合は、ハードウェア・ロード・バランサを使用します。ハードウェア・ロード・バランサには、次の機能が必要です。

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

- ポート変換の構成: ロード・バランサには、1つのポートで受信した受信リクエストを別のポートで実行されているサーバー・プロセスにルーティングできるポート変換機能が必要です。たとえば、ポート80で受信したリクエストをポート7777にルーティングできます。

- ポート(HTTP、HTTPS)の監視

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

- ロード・バランサには複数の仮想サーバーを構成できる必要があります。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、通常は、HTTPおよびHTTPSトラフィック用の仮想サーバーとポートでロード・バランサを構成する必要があります。

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

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

- リソースの監視/ポートの監視/プロセス障害検出: ロード・バランサは、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへの非Oracle Netトラフィックの送信を停止できる必要があります。ロード・バランサに障害の自動検出機能がある場合は、それを使用する必要があります。

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

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

- スティッキーなルーティング機能: CookieまたはURLに基づいたコンポーネントへのスティッキーな接続を維持する機能。

- SSLアクセラレーション: SSLアクセラレーションは、SSLトランザクションで実行され、プロセッサを集中的に使用する公開鍵暗号化アルゴリズムを、ハードウェア・アクセラレータにオフロードする方法です。
この機能は推奨されますが、必須ではありません。

表5-13は、Oracle SOA Suiteの高可用性環境で外部ロード・バランサに使用する仮想サーバー名の例を示しています。

表5-13 外部ロード・バランサの仮想サーバー名

コンポーネント

仮想サーバー名

Oracle SOA Suite

soa.mycompany.com

WebLogic Server管理コンソール

admin.mycompany.com

Oracle Enterprise Manager Fusion Middleware Control

admin.mycompany.com

Oracle Service Bus Webコンソール

admin.mycompany.com

仮想サーバー名

この項では、この章で説明する高可用性デプロイメントのために設定が必要な仮想サーバー名について説明します。

soa.mycompany.com

soa.mycompany.comは、soa-infraやワークフローなどのランタイムSOAコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、アドレスsoa.mycompany.com:443を使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

admin.mycompany.com

この仮想サーバーは、管理サービスへ送信されるすべての内部HTTPトラフィックのアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスadmin.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777に順に転送されます。この仮想ホストでアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise ManagerおよびOracle Service Bus Webコンソールなどがあります。

さらに、仮想サーバー名に対応するIPアドレスが設定されていることと、仮想サーバー名がドメイン・ネーム・システム(DNS)に登録されていることを確認します。Oracle Fusion Middlewareを実行するコンピュータには、これらの仮想サーバー名を解決できることが必要です。

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

WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。

1. サーバーが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』で指定されている要件を満たしています。

- ポート7777が、ノード上のどのサービスによっても使用されていない。このことを確認するには、次のコマンドを実行します。
UNIX:

netstat -an | grep LISTEN | grep "7777"

Windows:

netstat -an | findstr "LISTEN" | findstr ":7777"

ポートを使用中の場合は、それらのポートを使用可能にします。

2. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

3. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンドrunInstallerを実行します。

Windowsでは、setup.exeをダブルクリックします。

4. 「ようこそ」画面で「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

6. 「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。

7. 「インストール場所の指定」画面で、場所を次のように設定します。
/u01/app/oracle/product/11.1.1/ohs_1

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

9. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

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

10. 「コンポーネントの詳細の指定」画面で、次の値を入力します。

- インスタンス・ホームの場所: インスタンス・ホーム

- インスタンス・ホームの場所: /u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1

- インスタンス名: ohs_instance1

- OHSコンポーネント名: ohs1

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

12. 「Web Tierポートの詳細の指定」画面で、次の操作を行います。

- 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

- 「Oracle HTTP Serverポート」に値を入力します(例: 7777)。

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

14. 「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。

15. 「インストールの進行状況」画面で、次の操作を行います。
UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

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

「構成」画面で、いくつかの構成アシスタントが連続して起動されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。

16. 「構成が完了しました」画面で、「終了」をクリックして終了します。

WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してLBRを構成します。

5.14.1.10.1 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、ブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

HTTP://WEBHOST1:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザにOracle FMWの「ようこそ」画面が表示されます。

5.14.2 Oracle Fusion Middlewareホームのインストール

この項では、Oracle WebLogic ServerとOracle SOA Suiteを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。WebLogic ServerとOracle SOAをSOAHOST2にインストールするために、この手順を繰り返します(次ではSOAHOST1を対象にして説明しています)。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは正しく機能しません。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

- Oracle WebLogic Server(第5.14.2.1項「Oracle WebLogic Serverのインストール」を参照)

- Oracle SOA Suite(第5.14.2.2項「Oracle SOA用Oracle Fusion Middlewareのインストール」を参照)

- Oracle Service Bus(第5.14.2.3項「Oracle Service Busのインストール」を参照)

5.14.2.1 Oracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。

1. Oracle WebLogic Serverインストーラを起動します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」フィールドで、MW_HOMEと入力します。

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

4. 「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。

6. 「製品とコンポーネントの選択」画面で、「次へ」をクリックします。

7. 「JDKの選択」画面で、「Oracle JRockit 160_20_D1.0.1-2124 SDK」のみを選択して「次へ」をクリックします。

8. 「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
WL_HOME

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

9. 「インストールの概要」画面で「次へ」をクリックします。

10. 「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。

5.14.2.2 Oracle SOA用Oracle Fusion Middlewareのインストール

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

1. Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラを起動します。
UNIXの場合:

SOAHOST1> runInstaller

Windowsの場合:

SOAHOST1> setup.exe

Oracle Fusion Middleware 11g Oracle SOA Suiteのインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_<バージョン>のように入力します。

2. 「インベントリ・ディレクトリの指定」画面で、次の操作を行います。

1. HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所が推奨されます)。

2. インストールを実行するユーザーのOSグループを入力します。

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

4. 画面の手順に従って、/createCentralInventory.shをルートとして実行します。

5. 「OK」をクリックします。

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

5. 「インストール場所の指定」画面で、次の操作を行います。

- 「MiddleWareホーム」には、MW_HOMEと入力します。

- 「Oracleホーム・ディレクトリ」には、soaと入力します。

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

6. 「インストール・サマリー」画面で「インストール」をクリックします。

7. 「インストール完了」画面で「終了」をクリックします。

5.14.2.3 Oracle Service Busのインストール

Oracle Service Busをインストールするには、次の手順に従ってください。

1. Oracle Fusion Middleware 11g Oracle Service Busインストーラを起動します。
UNIXの場合:

SOAHOST1> runinstaller

Windowsの場合:

SOAHOST1> setup.exe

Oracle Fusion Middleware 11g Oracle Service Busのインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_<バージョン>のように入力します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ソフトウェア更新のインストール」画面で、更新のプリファレンスを入力します。

4. 「インストール場所の指定」画面で、次の操作を行います。

- 「ミドルウェア・ホーム」には、MW_HOMEと入力します。

- 「Oracleホーム・ディレクトリ」には、osbと入力します。

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

5. 「インストール・タイプ」画面で、「カスタム」を選択して「次へ」をクリックします。

6. 「インストールするコンポーネント」画面で、「Oracle Service Bus IDE」と「Oracle Service Bus Examples」の選択を解除します。

7. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

8. 製品ホーム位置画面でデフォルトを受け入れて、次へをクリックします。

9. 「インストール・サマリー」画面で「インストール」をクリックします。

10. 「インストール完了」画面で「終了」をクリックします。

注意:

第5.14.4項「SOAとOSBのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareが最新バージョンになるように、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチがMiddlewareホームに適用されていることを確認してください。

最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

5.14.3 SOAHOST1のVIP1とVIP3およびSOAHOST2のVIP2とVIP4の有効化

SOAドメインは、SOAおよびOSBの管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのSOAマシン上でこれらのホスト名それぞれに対してVIPマッピングを有効にして(SOAHOST1ではVIP1とVIP3、SOAHOST2ではVIP2とVIP4)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。

仮想IPの構成の詳細は、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。この項には、管理サーバーの例が記載されています。SOAサーバーのサーバー移行の構成の詳細は、第5.14.20項「WLS_SOAサーバーのサーバー移行の構成」を参照してください。

5.14.4 SOAとOSBのドメインを作成するためのSOAHOST1でのOracle Fusion Middleware構成ウィザードの実行

MW_HOME/Oracle_common/common/binディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーおよびOracle SOAとOSBのコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。

注意:

同じWebLogic Serverドメイン内では、複数のSOAクラスタは許可されていません。

同じWebLogic Serverドメイン内では、複数のOSBクラスタは許可されていません。

1つのWebLogic Serverドメイン内では、1つのクラスタでSOAとOSBの両方を保持することはできません。

1. Middlewareホームのoracle_common/common/binディレクトリにある、Oracle Fusion Middlewareの構成ウィザードの場所に、ディレクトリを変更します。

SOAHOST1> cd ORACLE_HOME/oracle_common/common/bin

2. Oracle Fusion Middlewareの構成ウィザードを起動します。
Linuxの場合:

SOAHOST1> ./config.sh

Windowsの場合:

SOAHOST1> config.cmd

3. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

4. 「ドメイン・ソースの選択」画面で、次を選択します。

- 「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

- 次の製品を選択します。

- Basic Weblogic Server Domain - 10.3.6.0 [wlserver_10.3](デフォルトで選択されており、グレーアウトされています)

- Oracle SOA Suite - 11.1.1.0 [soa](デフォルトで選択されています)

- Oracle Service Bus OWSM Extension - 11.1.1.6 [osb]

- Oracle Enterprise Manager - 11.1.1.0 [oracle common](デフォルトで選択されています)

- Oracle Service Bus - 11.1.1.6 [osb]

- WebLogic Advanced WebService for JAX-RPC Extension - 10.3.6.0 [wlserver_10.3]

- Oracle WSM Policy Manager - 11.1.1.0 [oracle_common](SOA Suiteを選択した場合は、デフォルトで選択されています)

- Oracle JRF Web Services - 11.1.1.0 [oracle_common] (SOA Suiteを選択した場合は、デフォルトで選択されています)

ターゲットの一部を間違って選択解除した場合は、この画面で前述の項目が選択されていることを確認してください。

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

5. 「ドメイン名と場所の指定」画面で、次のエントリを作成します。

- ドメイン名: soadomain

- ドメインの場所: デフォルトを受け入れます。

- アプリケーションの場所: デフォルトを受け入れます。

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

6. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。

7. 「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。

- WebLogicドメインの起動モード: 「本番モード」を選択

- JDKの選択: 「Oracle JRockit 160_20_D1.0.1-2124 SDK」を選択

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

8. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

1. 画面下部の表に表示されるすべてのコンポーネント・スキーマ、SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマ、SOA MDSスキーマおよびOSB JMSレポート作成プロバイダを選択します。

2. 「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」、「RACマルチ・データ・ソースへ変換」または「変換しない」のうち、いずれかのオプションを選択します。

3. 画面に次のデータ・ソースが表示されていることを確認します。表5-14に示されているユーザー名は、RCUからのスキーマ作成で接頭辞にsoahaが使用されていることを想定しています。
Oracle RACおよびMDSリポジトリでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照してください。

Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

表5-14 データ・ソースの値の構成

データ・ソース・スキーマ

スキーマ所有者

SOAインフラストラクチャ

SOAHA_SOAINFRA

ユーザー・メッセージング・サービス

SOAHA_ORASDPM

OWSM MDSスキーマ

SOAHA_MDS

SOA MDSスキーマ

SOAHA_MDS

OSB JMSレポート作成プロバイダ

SOAHA_SOAINFRA

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

9. 「JDBCコンポーネント・スキーマの構成」画面で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
マルチ・データ・ソースの場合は、次のフィールドに値を入力します。

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

「図5-48 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。

図5-49 「GridLink RACコンポーネント・スキーマの構成」画面

「図5-49 「GridLink RACコンポーネント・スキーマの構成」画面」の説明

1. ドライバ: RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

2. サービス名 : データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名name example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(example.comなど)を含むRACサービス名を登録または追加することをお薦めします。

3. ユーザー名接頭辞: スキーマの接頭辞を入力します。表5-14に示されているユーザー名は、RCUからのスキーマ作成で接頭辞としてsoahaが使用されていることを想定しています。

4. 「パスワード」と「パスワードの確認」: スキーマにアクセスするときのパスワードを入力します。

5. GridLinkデータ・ソースの場合は、SCANアドレスをリスナー・アドレス・フィールドに入力し、「ポート」フィールドにSCANポートを入力します。「ONSホスト」と「ポート」の各フィールドに、ONSホストおよびポート情報を入力します。

注意:

WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、SCANアドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、ネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。

マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。

6. 一度に1つのデータ・ソースを選択し、適切な詳細を追加することにより、各スキーマを更新します。
すべてのマルチ・データ・ソース・スキーマ(SOAインフラストラクチャ、ユーザー・メッセージング・サービス、OWSM MDSスキーマ、SOA MDSスキーマおよびOSB JMSレポート作成プロバイダ)について、必ず情報を入力してください。

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

10. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックしてエントリを修正します。
すべての接続が正常になったら「次へ」をクリックします。

11. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- JMSファイル・ストア

12. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: VIP0仮想IPのホスト名を入力します。

- リスニング・ポート: 7001

- SSLリスニング・ポート: N/A

- SSL有効: 選択を解除

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

13. JMS分散宛先タイプがUDDに設定されていることを確認します。

14. 「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。

表5-15 管理対象サーバーの構成

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_SOA1

SOAHOST1VHN1

8001

n/a

いいえ

WLS_SOA2

SOAHOST2VHN1

8001

n/a

いいえ

WLS_OSB1

OSBHOST1VHN1

8011

n/a

いいえ

WLS_OSB2

OSBHOST2VHN1

8011

n/a

いいえ

表示されるどのサーバーも削除しないでください。サーバーは変更できます。サーバーを削除して新しいサーバーを追加すると、ターゲット指定が失敗します。

注意:

標準の推奨事項は、個々のWebLogic管理対象サーバー内でカスタム・アプリケーションおよび他のシステムを実行するためのものです。ただし、図5-47で説明しているカスタムWLS管理対象サーバーの作成については、この項では説明しません。

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

15. 「クラスタの構成」画面で、次のクラスタを追加します。

表5-16 SOAクラスタとOSBクラスタの追加

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

SOA_Cluster

ユニキャスト

N/A

N/A

SOAHOST1VHN1:8001、SOAHOST2VHN1:8001

OSB_Cluster

ユニキャスト

N/A

N/A

OSBHOST1VHN1:8011、OSBHOST2VHN1:8011

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

16. 「サーバーのクラスタへの割当」画面で、SOA_Clusterに次のサーバーを割り当てます。

- WLS_SOA1

- WLS_SOA2

OSB_Clusterに次のサーバーを割り当てます。

- WLS_OSB1

- WLS_OSB2

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

17. 「マシンの構成」画面で、次の操作を行います。

- デフォルトとして表示される「LocalMachine」を削除します。

- 「UNIXマシン」タブをクリックし、次のマシンを追加します。

表5-17 マシンの構成

名前

ノード・マネージャのリスニング・アドレス

SOAHOST1

SOAHOST1のホスト名

SOAHOST2

SOAHOST2のホスト名

OSBHOST1

OSBHOST1のホスト名

OSBHOST2

OSBHOST2のホスト名

その他すべてのフィールドをデフォルト値のままにして、「次へ」をクリックします。

18. 「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

図5-50 「サーバーのマシンへの割当」画面

「図5-50 「サーバーのマシンへの割当」画面」の説明

- SOAHOST1: AdminServer、WLS_SOA1

- SOAHOST2: WLS_SOA2

- OSBHOST1: WLS_OSB1

- OSBHOST2: WLS_OSB2

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

19. 「JMSファイル・ストアの構成」画面で、サーバーのフェイルオーバー先として使用可能なすべてのノードからアクセス可能な各ストアのディレクトリの場所を入力します。第5.14.1.3項「共有記憶域に関する前提条件」で推奨されているディレクトリ(次に示す共有デバイス上のディレクトリなど)を使用します。

表5-18 JMSファイル・ストアの構成

名前

ディレクトリ

同期書込みポリシー*

FileStore_auto_1

/u01/app/oracle/admin/soadomain/soacluster/FileStore_auto_1

直接書込み

FileStore_auto_2

/u01/app/oracle/admin/soadomain/soacluster/FileStore_auto_2

直接書込み

SOAJMSFileStore_auto_1

/u01/app/oracle/admin/soadomain/soacluster/SOAJMSFileStore_auto_1

直接書込み

SOAJMSFileStore_auto_2

/u01/app/oracle/admin/soadomain/soacluster/SOAJMSFileStore_auto_2

直接書込み

UMSJMSFileStore_auto_1

/u01/app/oracle/admin/soadomain/soacluster/UMSJMSFileStore_auto_1

直接書込み

UMSJMSFileStore_auto_2

/u01/app/oracle/admin/soadomain/soacluster/UMSJMSFileStore_auto_2

直接書込み

WseeFileStore_auto_1

/u01/app/oracle/admin/soadomain/soacluster/WseeFileStore_auto_1

直接書込み

WseeFileStore_auto_2

/u01/app/oracle/admin/soadomain/soacluster/WseeFileStore_auto_2

直接書込み

* デフォルトの同期書込みポリシー(何も指定されない場合)は「直接書込み」です。

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

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

21. ドメインの作成中画面で「完了」をクリックします。

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

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。SOAHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。

管理サーバーに対しては、次の手順を実行します。

1. 次のディレクトリを作成します。

SOAHOST1> mkdir -p ORACLE_BASE/product/fmw/user_
projects/domains/soadomain/servers/AdminServer/security

2. テキスト・エディタを使用して、前の手順で作成したセキュリティ・ディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminuser
password=password

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

5.14.6 SOAHOST1での管理サーバーの起動と検証

この項では、SOAHOST1で管理サーバーを起動および検証する手順について説明します。

5.14.6.1 SOAHOST1での管理サーバーの起動

SOAHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

SOAHOST1> cd MW_HOME/user_projects/domains/soadomain/bin

SOAHOST1> ./startWebLogic.sh

5.14.6.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. ブラウザでhttp://vip0:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. 管理対象サーバーとしてWLS_SOA1およびWLS_SOA2が表示されていることを確認します。また、管理対象サーバーとしてWLS_OSB1およびWLS_OSB2が表示されていることを確認します。

4. SOA_ClusterクラスタおよびOSB_Clusterクラスタが表示されていることを確認します。

5. Enterprise Manager(http://vip0:7001/em)にアクセスできることを確認します。

6. http://vip0:7001/sbconsoleでOracle Service Busコンソールにアクセスできることを確認します。

5.14.7 管理サーバーおよび管理対象サーバーWLS_SOAn/WLS_OSBnに対するホスト名の検証の無効化

この手順が必要になるのは、管理サーバーとノード・マネージャの間にホスト名を検証するための適切な証明書を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。

ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。

ホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールで、「サーバー」、「AdminServer」の順に選択します。

2. 「SSL」→「詳細」を選択します。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 「ホスト名の検証」を「なし」に設定します。変更を保存およびアクティブ化します。

5. WLS_SOA1、WLS_SOA2、WLS_OSB1およびWLS_OSB2サーバーに対してこの手順を繰り返します。

6. 管理サーバーを再起動します。

5.14.8 コンポジットのデプロイでのOracle Coherenceの構成

コンポジットのデプロイではデフォルトでマルチキャスト通信を使用しますが、SOAの高可用性を実現するためにはユニキャスト通信を使用することをお薦めします。セキュリティ上の理由からマルチキャスト通信を無効化した場合には、ユニキャスト通信を使用します。

注意:

デプロイメントに使用されるOracle Coherenceフレームワークの構成が不適切な場合、SOAシステムは起動できません。SOAシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項でこれらから説明する構成をお薦めします。

ユニキャスト通信を使用したクラスタ内通信の有効化

マルチキャスト通信を使用すると、クラスタの中でコンポジットの動的なデプロイメント先となるすべてのメンバーをOracle SOA Suiteで検出できます。しかし、ユニキャスト通信では、ノードはこのように他のクラスタ・メンバーを検出することはできません。そのため、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加された新しいノードが既存ノードの1つを検出するために必要なノードを指定するだけで済みます。これによって、新しいノードがクラスタに追加されたときに、クラスタ内の他のすべてのノードを検出できるようになります。さらに、同じノードで複数のIPを使用可能な構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

ヒント:

SOAコンポジットのデプロイメント時の高可用性を保証するためには、十分なノードを指定して、いつでも最低1つのコンポジットが実行されているようにします。

tangosol.coherence.wka<n>システム・プロパティを使用してノードを指定します。<n>は、1から9の数字です。最大9つのノードを指定できます。番号は、1から開始します。連続した番号を指定する必要があり、途切れていてはなりません。また、Oracle Coherenceがtangosol.coherence.localhostシステム・プロパティを使用してクラスタを作成するときに使用するホスト名を指定します。このホスト名は、対応するリスナー・アドレス(VIP1およびVIP2)をマップするSOAサーバーによって使用される仮想ホスト名である必要があります。このプロパティは、管理コンソールの「サーバーの起動」タブ(図5-51)の「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加して設定します。

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

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

ホスト名の指定

Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。

5. 「サーバーの起動」タブをクリックします(図5-51を参照)。

6. 「引数」フィールドで、WLS_SOA1とWLS_SOA2について次のように入力します。
WLS_SOA1について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1

WLS_SOA2について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1

注意:

デプロイメントに使用される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

7. 「保存」をクリックして、変更をアクティブ化します。

8. この変更を適用するには、SOAサーバーを再起動する必要があります。

注意:

マルチキャスト・アドレスとユニキャスト・アドレスは、WebLogic Serverクラスタでクラスタ通信に使用されるものとは異なります。SOAでは、2つのエンティティ(WebLogic Serverクラスタと、コンポジットがデプロイされるグループ)の通信プロトコルが異なっていても、コンポジットが単一のWebLogic Serverクラスタのメンバーにデプロイされることが保証されています。

前述のテキストを管理コンソールの引数テキスト・フィールドにコピーしないでください。コピーすると、HTMLタグがJava引数に挿入されることがあります。テキストには、前述のもの以外のテキストや文字を含めることはできません。

5.14.9 Oracle Service Busの結果キャッシュのOracle Coherenceの構成

Oracle Service Busの結果キャッシュが使用するCoherenceインフラストラクチャのデフォルト構成は、マルチキャストです。Oracle Service Busの結果キャッシュでは、ユニキャスト通信を使用することをお薦めします。

Oracle Service Busの結果キャッシュのCoherenceインフラストラクチャに対してユニキャストを有効にするには、次の手順を実行します。

1. 管理コンソールにログインします。「チェンジ・センター」で、「ロックして編集」をクリックします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。

4. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。

5. 「サーバーの起動」タブをクリックします。

6. WLS_OSB1には、次の1行を入力します(改行は入れません)。

-DOSB.coherence.localhost=osbhost1vhn1 -DOSB.coherence.localport=7890
-DOSB.coherence.wka1= osbhost1vhn1 -DOSB.coherence.wka1.port=7890
-DOSB.coherence.wka2= osbhost2vhn1 -DOSB.coherence.wka2.port=7890

WLS_OSB2には、次の1行を入力します(改行は入れません)。

-DOSB.coherence.localhost=osbhost2vhn1 -DOSB.coherence.localport=7890
-DOSB.coherence.wka1= osbhost1vhn1 -DOSB.coherence.wka1.port=7890
-DOSB.coherence.wka2= osbhost2vhn1 -DOSB.coherence.wka2.port=7890

7. 変更を保存およびアクティブ化します。これらの変更を有効にするには、Oracle Service Busサーバー再起動する必要があります。

5.14.10 B2Bキューの接続宛先識別子の設定

Oracle B2Bは、特定のJMS宛先メンバー・コールを使用します。これらのコールの正常な実行には「宛先識別子の作成」(CDI)の設定が必要になります。CDIを設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「サービス」ノードを開き、「メッセージング」ノードを開きます。

3. 「JMSモジュール」をクリックしてから、「SOAJMSModule」をクリックします。

4. 「チェンジ・センター」で、「ロックして編集」をクリックします。

5. 「dist_B2BEventQueue_auto」→「構成」→「一般」タブ→「詳細」をクリックします。

6. 「宛先識別子の作成」フィールドで、キューの次のjndi名を追加します。

jms/b2b/B2BEventQueue

7. これらの手順を繰り返し、次に示すキューの宛先識別子を次のように作成します。

- B2B_OUT_QUEUE: jms/b2b/B2B_OUT_QUEUE

- B2B_IN_QUEUE: jms/b2b/B2B_IN_QUEUE

- B2BBroadcastTopic: jms/b2b/B2BBroadcastTopic

- XmlSchemaChangeNotificationTopic: jms/fabric/XmlSchemaChangeNotificationTopic

8. 「保存」→「変更のアクティブ化」をクリックします。

5.14.11 SOAHOST1でのシステムの起動

この項では、SOAHOST1でノード・マネージャを起動する方法、およびSOAHOST1で管理対象サーバーWLS_SOA1を起動して検証する方法について説明します。

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

SOAHOST1でノード・マネージャを起動するには、次の手順を実行します。

1. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./setNMProps.sh

注意:

クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

2. ノード・マネージャを起動します。

SOAHOST1> cd WL_HOME/server/bin
SOAHOST1> ./startNodeManager.sh

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

WLS_SOA1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認するには:

1. 管理コンソールを使用して、WLS_SOA1管理対象サーバーを起動します。

2. WLS_SOA1を起動すると、次のURLが使用可能になります。

- http://SOAHOST1VHN1:8001/b2b

- B2Bコンソールへのログインを確認します。

- http://SOAHOST1VHN1:8001/integration/worklistapp

- ワークリスト・コンソールへのログインを確認します。

- http://SOAHOST1VHN1:8001/wsm-pm

- ポリシー・バリデータ・リンクを確認します。

- http://SOAHOST1VHN1:8001/soa/composer

- http://SOAHOST1VHN1:8001/soa-infra

5.14.12 pack/unpackユーティリティを使用したSOAHOST2、OSBHOST1およびOSBHOST2へのドメイン構成の伝播

pack/unpackユーティリティを使用して、ドメイン構成をSOAHOST2に伝播する手順は次のとおりです。

1. 次のpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplate.jar
-template_name=soa_domain_template

2. 次のコマンドをSOAHOST1で実行し、前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーします

SOAHOST1> scp soadomaintemplate.jar
oracle@node2:ORACLE_COMMON_HOME/common/bin

3. unpackコマンドをSOAHOST2で実行し、伝播されたテンプレートを解凍します。

SOAHOST2> cd ORACLE_COMMON_HOME/common/bin
SOAHOST2> ./unpack.sh
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplate.jar

注意:

pack/unpackプロシージャを実行した後でFusion Middleware構成ウィザードを実行すると、元のドメインにすでに存在し、「拡張ソースの選択」画面に表示されている製品は、選択されていない状態でグレー表示されます。

packコマンドで作成したテンプレートは、ユーザー作成テンプレートと見なされ、デフォルト・テンプレートとは別に扱われます。ユーザー作成テンプレートは自己完結型で、元のドメインの作成に関連する情報を一切保持しません。

4. OSBHOST1とOSBHOST2に対しても前述の手順を繰り返します。

5.14.13 第2ノードのXEngineファイルの抽出

B2BのXEngineを第2ノードで有効にするには、次のようにZEngine tarのコンテンツを手動で抽出する必要があります。

SOAHOST2>cd ORACLE_HOME/soa/thirdparty/edifecs
SOAHOST2>tar xzvf XEngine.tar.gz

5.14.14 SOAHOST2、OSBHOST1およびOSBHOST2でのシステムの起動

この項では、SOAHOST2でシステムを起動する手順について説明します。

5.14.14.1 SOAHOST2、OSBHOST1およびOSBHOST2でのノード・マネージャの起動

SOAHOST2、OSBHOST1およびOSBHOST2でノード・マネージャを起動するには、第5.14.11.1項「SOAHOST1でのノード・マネージャの起動」の手順をそれらのノードで繰り返します。

5.14.14.2 管理対象サーバーWLS_SOA2、WLS_OSB1およびWLS_OSB2の起動と検証

管理対象サーバーWLS_SOA2を起動して、正しく構成されていることをチェックする手順は、次のとおりです。

1. 管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。起動中はサーバーの出力ファイルでエラーを監視します。

2. WLS_SOA2が起動すると、次のURLが使用できるようになります。

- http://SOAHOST2VHN1:8001/b2b
B2Bコンソールへのログインを確認します。

- http://SOAHOST2VHN1:8001/integration/worklistapp
ワークリスト・コンソールへのログインを確認します。

- http://SOAHOST2VHN1:8001/wsm-pm
ポリシー・バリデータ・リンクを確認します。

- http://SOAHOST2VHN1:8001/soa/composer

- http://SOAHOST2VHN1:8001/soa-infra

管理対象サーバーWLS_OSB1を起動して、正しく構成されていることをチェックする手順は、次のとおりです。

1. 管理コンソールを使用して、WLS_OSB1管理対象サーバーを起動します。起動中はサーバーの出力ファイルでエラーを監視します。

2. WLS_OSB1が起動すると、次のURLが使用できるようになります。

http://OSBHOST1VHN1:8011/sbinspection.wsil/

次のようなHTTP応答が表示されます。

<?xml version="1.0" encoding="UTF-8" ?>
<ins:inspection xmlns:ins="http://schemas.xmlsoap.org/ws/2001/10/inspection/">
<ins:link referencedNamespace="http://schemas.xmlsoap.org/ws/2001/10/inspection/" location="http://OSBHOSTVHN1:8011/sbinspection.wsil?refpath=default">
<ins:abstract>default</ins:abstract>
<ins:abstract>LinkType: Project</ins:abstract>
</ins:link>
</ins:inspection>

WLS_OSB2に対してこの手順を繰り返します。

5.14.15 管理サーバーおよび管理対象サーバーWLS_SOAnとWLS_OSBnのOracle HTTP Serverの構成

管理対象サーバーWLS_SOAnを含むSOAクラスタへのOracle HTTP Serverのルーティングを有効にするには、次に示すWebLogicClusterパラメータをクラスタ内のノードのリストに設定します。

1. WEBHOST1およびWEBHOST2で、ORACLE_BASE/admin/<instance_name>/config/OHS/<component_name>/mod_wl_ohs.confファイルに次の行を追加します。

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001, SOAHOST2VHN1:8001
</Location>

# SOA soa-infra app
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Worklist
<Location /integration/>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# B2B
<Location /b2b>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

<Location /b2bconsole>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# UMS
<Location /sdpmessaging/ >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# UMS WS
<Location /ucs/messaging/webservice >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow/>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# Workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# SOA composer application
<Location /soa/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# OSB wsil
<Location /sbinspection.wsil*>
SetHandler weblogic-handler
WebLogicCluster OSBHOST1VHN1:8011,OSBHOST2VHN2:8011
</Location>

# OSB resource
<Location /sbresource*>
SetHandler weblogic-handler
WebLogicCluster OSBHOST1VHN1:8011,OSBHOST2VHN2:8011
</Location>

2. mod_wl_ohsファイルと同じディレクトリにあるhttpd.confファイルが次の行を含んでいることを確認します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://soa.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>

注意:

soa.mycompany.com:443や7777、admin.mycompany:80、you@youraddressなどの値は、例を示すための値です。実際の環境に基づく値を入力してください。

注意:

Oracle Service Busの各HTTPプロキシ・サービスは、それらに固有のコンテキスト・ルートを公開します。これは、そのプロキシ・サービスのフルパスになります(デフォルト)。たとえば、プロジェクトOrderProcessingのフォルダsubmissionにordersubmit.proxyが存在する場合は、コンテキスト・パスとして/OrderProcessing/submission/ordersubmitが公開されます。これらのURLコンテキストは、各サービスのOracle HTTP Serverに追加する必要があります。

3. WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。

4. 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

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

管理コンソールで、SOAサーバーのステータスが「実行中」になっていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。別のステータス(「管理」や「失敗」)が表示される場合は、サーバーの出力ログ・ファイルでエラーを確認します。次のURLにアクセスできることを確認します。

- http://WEBHOST1:7777/wsm-pm

- http://WEBHOST2:7777/wsm-pm

- http://WEBHOST1:7777/soa-infra

- http://WEBHOST2:7777/soa-infra

- http://WEBHOST1:7777/soa/composer

- http://WEBHOST2:7777/soa/composer

- http://WEBHOST1:7777/integration/worklistapp

- http://WEBHOST2:7777/integration/worklistapp

- http://WEBHOST1:7777/sdpmessaging/userprefs-ui

- http://WEBHOST2:7777/sdpmessaging/userprefs-ui

- http://WEBHOST1:7777/b2bconsole

- http://WEBHOST2:7777/b2bconsole

- http://WEBHOST1:7777/sbinspection.wsil

- http://WEBHOST2:7777/sbinspection.wsil

次のURLがロード・バランシング・ルーター・アドレスを使用していることも確認します。

- http://soa.mycompany.com:80/wsm-pm

- http://soa.mycompany.com:80/soa-infra

- http://soa.mycompany.com:80/soa/composer

- http://soa.mycompany.com:80/integration/worklistapp

- http://soa.mycompany.com:80/sdpmessaging/userprefs-ui

- http://soa.mycompany.com:80/b2bconsole

- http://soa.mycompany.com:80/sbinspection.wsil

HTTP ServerからSOA_CLusterへのルーティングとフェイルオーバーが適切に機能していることを確認する手順は、次のとおりです。

1. WLS_SOA2の実行中に、管理コンソールからWLS_SOA1を停止します。

2. 次のURLにアクセスして、適切な機能を検証します。

- WEBHOST1:7777/wsm-pm

- WEBHOST1:7777/soa-infra

- WEBHOST1:7777/soa/composer

- WEBHOST1:7777/integration/worklistapp

- WEBHOST1:7777/sdpmessaging/userprefs-ui

- WEBHOST1:7777/b2bconsole

3. 管理コンソールから、WLS_SOA1を開始します。

4. WLS_SOA2を停止します。

5. 前述のステップ2のURLにアクセスして、適切な機能を検証します。

HTTP ServerからOSB_Clusterへのルーティングとフェイルオーバーが適切に機能していることを確認する手順は、次のとおりです。

1. WLS_OSB2の実行中に、管理コンソールからWLS_OSB1を停止します。

2. 次のURLにアクセスして、適切な機能を検証します。

- WEBHOST1:7777/sbinspection.wsil

3. 管理コンソールから、WLS_OSB1を開始します。

4. WLS_OSB2を停止します。

5. 前述のステップ2のURLにもう一度アクセスして、正しく機能することを検証します。

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

Oracle WebLogic Serverクラスタに対してフロントエンドHTTPのホストとポートを設定する必要があります。

1. 管理コンソールの「チェンジ・センター」セクションで、「ロックして編集」をクリックします。

2. 左側のペインで、「環境」→「クラスタ」を選択します。

3. 「SOA_Cluster」を選択します。

4. 「HTTP」を選択します。

5. 次の値を設定します。

- フロントエンド・ホスト: soa.mycompany.com
フロントエンドHTTPポート: 80

- フロントエンドHTTPSポート: 空白のまま

注意:

このアドレスが正しく、使用可能である(ロード・バランシング・ルーターが稼働している)ことを確認してください。アドレスのhttp://やホスト名の末尾/など、値が誤っていると、仮想IPを使用してもSOAシステムにアクセスできません。

6. 「保存」をクリックします。

7. 変更をアクティブにするには、管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

8. OSB_Clusterに対してステップ1 - 7を繰り返します。

9. すでにサーバーを起動している場合、この変更にはクラスタの管理対象サーバーの再起動が必要であることに注意してください。

注意:

SOAシステムでは、次のようにコールバック・サーバーURLを計算します。

- SOAへのリクエストが外部サービスから発行されたものであったり、内部サービスがSOAにリクエストを発行したりした場合、SOAは、クライアントによって指定されているコールバック・サーバーURLを使用します。

- 外部または内部サービスへのリクエストがSOAから発行されている場合は、SOAが発行元であるため、コールバックURLをSOAリクエストに動的に移入できません。しかし、callbackServerURLが特定参照のバインディング・プロパティに指定されている場合は、callbackServerURLが使用されます。(これは、コンポジットをモデル化するときに設定するか、実行時にOracle Enterprise Managerコンソールからアクセス可能なMBeanを使用して設定できます。)これにより、サービス・コールごとに異なるコールバックURLを割り当てることができます。したがって、外部サービスからのコールバック・サーバーURLは、内部サービスへのコールバック・サーバーURLと異なります。
ただし、callbackServer URLがその参照のバインディング・プロパティに指定されていない場合、SOAシステムは、soa-infra-configに指定されているコールバック・サーバーURLを使用します。soa-infra-configにコールバック・サーバーURLが指定されていない場合、システムでは、WLSに指定されているフロントエンド・ホストがコールバック・サーバーURLとして使用されます。WLSにフロントエンド・ホストが指定されていない場合、システムでは、WLS MBean APIで指定されているローカル・ホスト名がコールバック・サーバーURLとして使用されます。

Oracle HTTP Serverによってフロントエンド処理されるSOA高可用性インストールでは、実質的なバックエンド・サーバーのOracle HTTP Serverポートでの監視が必要になります。すなわち、SOA管理対象サーバーにデプロイされたすべてのコンポーネントがデプロイメントで使用される場合です。HTTP/HTTPSポートをpingし、事前に決められた応答が返されることを予期する単純なHTTPモニターであれば十分です。特定のSOAコンポーネント(B2Bなど)のみが使用されている場合は、使用中のコンポーネントの状態を検証するために、管理対象サーバー全体のより深いレベルまでチェックするモニターを使用することも考えられます。お使いのロード・バランサでのHTTPモニターの設定について、ロード・バランサのベンダーにご確認ください。

フロントエンドHTTPのホストとポートを設定しない場合、Oracle B2Bからドキュメント定義XSDを取得しようとすると、次のメッセージを受け取ります。

An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when
clustering is enabled.

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

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーに対してトランザクション回復サービスの移行機能を利用するためには、サーバーとそのバックアップ・サーバー(WebLogic Serverのフェイルオーバー先として使用可能なノード)で利用可能な場所、可能であればデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)にトランザクション・ログを格納する必要があります。デフォルトの永続ストアを構成する手順は、次のとおりです。

1. 「ドメイン構造」ツリーで、「環境」を開き、「サーバー」を選択します。

2. 変更するサーバーを選択します。

3. 「構成」、「サービス」タブの順に選択します。

4. 「デフォルト・ストア」の「ディレクトリ」フィールドに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。
トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定する必要があります。したがって、入力するディレクトリは、SOA_Clusterの場合はWLS_SOA1とWLS_SOA2の両方から、OSB_Clusterの場合はWLS_OSB1とWLS_OSB2の両方から、それぞれアクセスできる必要があります。このディレクトリは、サーバーが再起動される前に存在している必要があります。

5.14.19 アプリケーションのデプロイ

SOAコンポジット・アプリケーションは、Oracle Enterprise Manager Fusion Middleware ControlのSOAコンポジットのデプロイ・ウィザードでデプロイできます。SOAコンポジットのデプロイ・ウィザードで、次のいずれかをデプロイします。

- 最初の新しいSOAコンポジット・アプリケーション

- 旧リビジョン(1.0など)と新リビジョン(2.0など)。旧リビジョンへの影響はありません。最後にデプロイされたリビジョンが、そのコンポジットの新しいデフォルト・リビジョンになります(デプロイメントのこの後の手順で他のリビジョンを指定しない場合にかぎります)。

- 現在デプロイされているもの(1.0など)とは異なるリビジョンをすでに持っているSOAコンポジット・アプリケーションの複数のSOAコンポジット・アプリケーション・リビジョン(リビジョン2.0、3.0、4.0など)が含まれているバンドル(ZIPファイル)。このオプションを使用すると、リビジョン1.0、2.0、3.0および4.0を同時にデプロイできます。バンドルには様々なコンポジットのリビジョンを含めることもできます。すべてのリビジョンが同一のコンポジット・アプリケーションのリビジョンでなければならないという制約はありません。

デプロイメントでは、SOAサービス・インフラストラクチャのコンポジット・アプリケーションを抽出し、アクティブ化します。アプリケーションがデプロイされると、インスタンスの作成、プロパティの構成、パフォーマンスの監視、インスタンスのライフサイクルの管理、ポリシーとフォルトの管理などの管理タスクを実行できます。

注意:

アプリケーションの既存のリビジョンを再デプロイする場合は、このウィザードを使用しないでください。かわりに、SOAコンポジットの再デプロイ・ウィザードを使用してください。

アプリケーションをデプロイする手順は、次のとおりです。

1. 次のいずれかのオプションを使用して、SOAコンポジットのデプロイ・ウィザードにアクセスします。

SOAインフラストラクチャのメニュー

ナビゲータのSOAフォルダ

SOAインフラストラクチャのホーム・ページ

SOAコンポジットのメニュー

1. 「SOAデプロイ」→「デプロイ」を選択します。

1. 「soa-infra」を右クリックします。

2. 「SOAデプロイ」→「デプロイ」を選択します。

1. 「デプロイ済コンポジット」タブをクリックします。

2. 「コンポジット」表の上にある「デプロイ」をクリックします。

1. 「SOAデプロイ」→「別のコンポジットをデプロイ」を選択します。

「アーカイブの選択」ページが表示されます。

図sca_deploy.gifの説明

2. 「アーカイブまたは展開済ディレクトリ」セクションで、デプロイするSOAコンポジット・アプリケーションのアーカイブを指定します。アーカイブには、デプロイするコンポジットのプロジェクト・ファイルが格納されています(たとえば、単一アーカイブのHelloWorld_rev1.0.jar、または複数アーカイブのOrderBooking_rev1.0.zip)。

3. 「構成プラン」セクションで、アーカイブに含める構成プランのオプションを指定します。構成プランには、異なる環境で使用するURLとプロパティ値を定義できます。構成プランは、プロセスのデプロイメント時に、プロジェクトを別のターゲット環境に適合させるために置換する必要のある値に関するSOAプロジェクトを検索する際に使用されます。

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

5. SOAコンポジット・アプリケーション・アーカイブのデプロイ先WebLogic Serverまたはクラスタを選択します。アーカイブは、複数のサーバーおよびクラスタにデプロイできます。

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

7. 選択内容を確認します。

8. SOAコンポジット・アプリケーションをデフォルトのリビジョンとしてデプロイするかどうかを選択します。デフォルトのリビジョンは、新しいリクエストを受信するとインスタンス化されます。

9. 「デプロイ」をクリックします。

10. デプロイメントが完了したら、「閉じる」をクリックします。

関連項目:

Oracle JDeveloperでの構成プランの作成とアプリケーションのデプロイについては、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

5.14.20 WLS_SOAサーバーのサーバー移行の構成

SOAシステムの高可用性アーキテクチャでは、一部のシングルトン・サービスを障害から保護するためにサーバー移行を利用します。サーバー全体の移行の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

WLS_SOA1管理対象サーバーは、障害発生時にSOAHOST2で再起動するように構成され、WLS_SOA2管理対象サーバーは、障害発生時にSOAHOST1で再起動するように構成されます。このような構成では、WLS_SOA1サーバーおよびWLS_SOA2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。WLS_SOAn管理対象サーバーのサーバー移行を構成する手順は、次のとおりです。

- ステップ1: サーバー移行leasing表のユーザーおよび表領域を設定する

- ステップ2: 管理コンソールでマルチ・データ・ソースを作成する

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

- ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する

- ステップ5: サーバー移行ターゲットの構成

- ステップ6: サーバー移行をテストする

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

WebLogicユーザー(oracle)に、パスワードなし制限でsudo権限を付与して、/sbin/ifconfig and /sbin/arpingバイナリの実行権限を付与します。

注意:

Windowでは、スクリプト名はwlsifconfig.cmdです。これを実行できるのは、管理者権限を持つユーザーです。

スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。次の、/etc/sudoers内のエントリの例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

サーバー移行のテスト

サーバー移行が適切に機能していることを確認する手順は次のとおりです。

SOAHOST1から次の処理を実行します。

1. WLS_SOA1管理対象サーバーを強制停止します。
これを行うには、このコマンドを実行します:

SOAHOST1> kill -9 <pid>

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

SOAHOST1> ps -ef | grep WLS_SOA1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_SOA1のpidを確認します。

MW_HOME\jrockit_160_<version>\bin\jps -l -v

2. ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。

3. ノード・マネージャがWLS_SOA1の2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

SOAHOST2から次の処理を実行します。

1. ローカルのノード・マネージャのコンソールを確認します。ノード1で最後にWLS_SOA1の再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、WLS_SOA1の浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。

2. 同じIPのSOAサービス・インフラストラクチャ・コンソールにアクセスします。

管理コンソールで移行を検証する手順は、次のとおりです。

1. 管理コンソールにログインします。

2. 左側のペインで、「ドメイン」をクリックします。

3. 「監視」タブ、「移行」サブタブの順にクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。

図5-52 管理コンソールの「移行の状態」画面

「図5-52 管理コンソールの「移行の状態」画面」の説明

注意:

Windowsでは、同一マシン上で複数のサーバーを同時に手動で停止してから、停止したサーバーの1つを別のマシンで起動しようとしても、IPバインドが機能しないことがあります。これは、IPアドレスが削除されていることがnetshによってレポートされていても、元のマシンでそのIPアドレスに対する要求が引き続き保持されているために起こります。

これを解決するには、ipconfigユーティリティまたはWindowsネットワーク構成を使用して、ネットワーク構成をチェックする必要があります。どちらを使用した場合も、仮想IPアドレスまたは浮動IPアドレスのいずれかが、サーバーが停止後も引き続き構成されていることが示されます。その場合は、次の手順に従い、Windowsネットワーク構成を使用して、IPアドレスを削除できます。

1. Windowsのコントロール・パネルで、「ネットワーク接続」を選択します。

2. 該当のネットワーク・インタフェースを選択して右クリックし、「プロパティ」を選択します。

3. 「インターネット プロトコル (TCP/IP)」を選択して「プロパティ」ボタンをクリックします。

4. 「詳細設定」を選択します。

5. 該当のIPアドレスを選択して、「削除」ボタンをクリックします。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

5.14.21 WLS_OSBサーバーのサーバー移行の構成

OSBシステムの高可用性アーキテクチャでは、一部のシングルトン・サービスを障害から保護するためにサーバー移行を利用します。サーバー全体の移行の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

WLS_OSB1管理対象サーバーは、障害発生時にOSBHOST2で再起動するように構成され、WLS_OSB2管理対象サーバーは、障害発生時にOSBHOST1で再起動するように構成されます。このような構成では、WLS_OSB1サーバーおよびWLS_OSB2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。WLS_OSBn管理対象サーバーのサーバー移行を構成する手順は、次のとおりです。

注意:

第5.14.20項「WLS_SOAサーバーのサーバー移行の構成」の説明に従って、SOAですでに表領域、スキーマのマルチ・データ・ソースおよびデータ・ソースが設定されている場合、OSBクラスタは既存のleasingスキーマとデータ・ソースを再利用できるので、後述のステップ1とステップ2は不要です。かわりに、SOA用に作成されているデータ・ソースとマルチ・データ・ソースを、OSBクラスタにターゲット指定します。

ステップ1: サーバー移行leasing表のユーザーおよび表領域を設定する

1. leasingという表領域を作成します。
例: SQL*Plusにsysdbaユーザーとしてログオンして、次のコマンドを実行します。

SQL> create tablespace leasing
logging datafile 'DB_HOMEs/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. leasingというユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by welcome1;

SQL> grant create table to leasing;

SQL> grant create session to leasing;

SQL> alter user leasing default tablespace leasing;

SQL> alter user leasing quota unlimited on LEASING;

3. leasing.ddlスクリプトを使用してleasing表を作成します。

1. WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリにあるleasing.ddlファイルをデータベース・ノードにコピーします。

2. データベースにleasingユーザーとして接続します。

3. leasing.ddlをSQL*Plusで実行します。

SQL> @copy_location/leasing.ddl;

ステップ2   管理コンソールでマルチ・データ・ソースを作成する

マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。

- このデータ・ソースが非XAデータ・ソースであることを確認します。

- マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1です。

- Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。

- したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。データ・ソースは、グローバル・トランザクションのサポートを必要としません。

- これらのデータ・ソースをクラスタにターゲット指定します。

- データソースの接続プールの初期容量が0に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データ・ソース名」→「接続プール」タブをクリックし、「接続数の初期値」フィールドに0を入力します。

マルチ・データ・ソースを作成する手順は、次のとおりです。

1. 管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「データ・ソース」をクリックします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「新規」→「マルチ・データ・ソース」をクリックします。

4. 「名前」として、leasingと入力します。

5. 「JNDI名」として、jdbc/leasingと入力します。

6. 「アルゴリズムとしてフェイルオーバー」(デフォルト)を選択し、「次へ」をクリックします。

7. 「非XAドライバ」(デフォルト)を選択し、「次へ」をクリックします。

8. 「新しいデータ・ソースの作成」をクリックします。

9. 名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、Oracle Driver (Thin) for RAC server-Instance connection Version 10,11と入力します。

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

11. 「グローバル・トランザクションのサポート」の選択を解除して、「次へ」をクリックします。

12. leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。

13. 「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。

14. データ・ソースをOSBクラスタにターゲット指定します。

15. データ・ソースを選択して、右の画面に追加します。

16. 「新しいデータ・ソースの作成」をクリックして、Oracle RACデータベースの2つ目のインスタンスについても同じ手順を繰り返します。

17. 2つ目のデータ・ソースをマルチ・データ・ソースに追加します。

18. 変更を保存およびアクティブ化します。

ステップ3: ノード・マネージャのプロパティ・ファイルを編集する

ノード・マネージャとサーバー全体の移行の詳細は、第3.9項「サーバー全体の移行」を参照してください。

nodemanager.propertiesファイルは、WL_HOME/common/nodemanagerディレクトリにあります。サーバー移行が正しく機能するために、この項で説明するプロパティを追加する必要があります。

- Interface=eth0

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

このプロパティは、浮動IPのインタフェース名(たとえば、Linuxではeth0)を指定します。

注意:

Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: Interface="Local Area Connection"

指定するインタフェースが、このノードに対するパブリック・インタフェースであることを確認してください。このインタフェースは、複数のホーム・ノード上で浮動IPを有効にできるものでなければなりません。

- NetMask=255.255.255.0
このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。このネットマスク(255.255.255.0)は、一例にすぎません。実際の値は、ネットワークにより異なります。

- UseMACBroadcast=true
このプロパティでは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、すなわち、arpingコマンドで-bフラグを使用するかどうかを指定します。

ノード・マネージャの起動後、これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力は、次のように表示されます。

StateCheckInterval=500

Interface=eth0 (Linux)またはInterface="Local Area Connection" (Windows)

NetMask=255.255.255.0

UseMACBroadcast=true

注意:

この項で説明する手順は、サーバー・プロパティ(起動プロパティ)が適切に設定されていて、ノード・マネージャがリモートでサーバーを起動できる場合には不要です。

1. nodemanager.propertiesファイルで次のプロパティを設定します。

- StartScriptEnabled
このプロパティをtrueに設定します。

2. WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、OSBHOST1とOSBHOST2でノード・マネージャを起動します。

3. nodemanager.logファイルで、nodemanager.propertiesファイルへの変更を確認します。

ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する

1. WebLogicユーザー(oracle)に、パスワードなし制限でsudo権限を付与して、/sbin/ifconfig and /sbin/arpingバイナリの実行権限を付与します。

注意:

Windowsでは、このスクリプトの名前はwlsifconfig.cmdであり、管理者権限を持つユーザーが実行できます。

WebLogicユーザー(oracle)がスクリプトを実行できることを確認します。次の、/etc/sudoers内のエントリの例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

ステップ5: サーバー移行ターゲットを構成する

クラスタの移行の構成では、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左側のペインで、「環境」を開き、「クラスタ」を選択します。

3. 移行を構成するクラスタ(OSB_Cluster)を選択します。

4. 「移行」をクリックします。

5. 「チェンジ・センター」で、「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「OSBHOST1」と「OSBHOST2」を選択します。

7. leasingデータ・ソースを選択します。

8. 「保存」をクリックします。

9. すべての管理対象サーバーについて、サーバー移行の候補となるマシンを設定します。

1. 管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。

2. 移行を構成するサーバーを選択します。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。WLS_OSB1には「OSBHOST2」を選択します。WLS_OSB2には「OSBHOST1」を選択します。

5. 「サーバーの自動移行を有効化」のチェック・ボックスを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

6. 「保存」をクリックして、変更をアクティブ化します。

7. これらの変更を有効にするには、サーバーとノード・マネージャを再起動する必要があります。

ステップ6: サーバー移行をテストする

サーバー移行が適切に機能していることを確認する手順は次のとおりです。

OSBHOST1から次の処理を実行します。

1. WLS_OSB1管理対象サーバーを強制停止します。
これを行うには、このコマンドを実行します:

OSBHOST1> kill -9 <pid>

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

OSBHOST1> ps -ef | grep WLS_OSB1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_OSB1のpidを確認します。

MW_HOME\jrockit_160_<version>\bin\jps -l -v

2. ノード・マネージャのコンソールを確認します。WLS_OSB1の浮動IPが無効になっていることを示すメッセージが表示されています。

3. ノード・マネージャがWLS_OSB1の2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

OSBHOST2から次の処理を実行します。

1. ローカルのノード・マネージャのコンソールを確認します。ノード1で最後にWLS_OSB1の再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、WLS_OSB1の浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。

2. 同じIPのsbinspection.wsil urlconsoleにアクセスします。

管理コンソールから移行を検証する手順は、次のとおりです。

1. 管理コンソールにログインします。

2. 左側のペインで、「ドメイン」をクリックします。

3. 「監視」タブ、「移行」サブタブの順にクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。

図5-53 管理コンソールの「移行の状態」画面

「図5-53 管理コンソールの「移行の状態」画面」の説明

注意:

Windowsでは、同一マシン上で複数のサーバーを同時に手動で停止し、その後で別のマシンで、停止したサーバーの1つを起動しようとしても、IPバインドは機能しません。これは、IPアドレスが削除されていることがnetshによってレポートされていても、元のマシンでそのIPアドレスに対する要求が引き続き保持されているために起こります。

これを解決するには、ipconfigユーティリティまたはWindowsネットワーク構成を使用して、ネットワーク構成をチェックする必要があります。どちらを使用した場合も、仮想IPアドレスまたは浮動IPアドレスのいずれかが、サーバーが停止後も引き続き構成されていることが示されます。その場合は、次の手順に従い、Windowsネットワーク構成を使用して、IPアドレスを削除できます。

1. Windowsのコントロール・パネルで、「ネットワーク接続」を選択します。

2. 該当のネットワーク・インタフェースを選択して右クリックし、「プロパティ」を選択します。

3. 「インターネット プロトコル (TCP/IP)」を選択して「プロパティ」ボタンをクリックします。

4. 「詳細設定」を選択します。

5. 該当のIPアドレスを選択して、「削除」ボタンをクリックします。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

5.14.22 トポロジのスケーリング

この高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。

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

この場合は、SOAコンポーネントとOracle Service Busコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードには、既存の管理対象サーバーのMiddlewareホーム、Oracleホーム(SOAとOracle Service Bus)およびドメイン・ディレクトリが含まれます。

新しいWLS_OSBサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。SOAまたはOracle Service Busのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。

SOAサーバーをスケール・アップするには、第5.13.21.1項「トポロジのスケール・アップ(既存のノードへの管理対象サーバーの追加)」の手順に従ってください。

OSBサーバーのトポロジをスケール・アップするには、次の手順に従ってください。

1. 管理コンソールを使用し、WLS_OSBnのクローンを作成して新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。

1. 管理コンソールから「環境」→「サーバー」を選択します。

2. クローンを作成する管理対象サーバー(WLS_OSB1など)を選択します。

3. 「クローンの作成」を選択します。

新しい管理対象サーバーにWLS_OSBnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。

この後の手順では、すでにWLS_OSB1を実行しているOSBHOST1に新しいサーバーを追加することを想定しています。

2. リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。この仮想ホスト名は、OSB/SOAドメイン(同じドメインまたは別のドメイン)によって使用されているノードで実行されている他の管理対象サーバーで使用されているものとは異なっている必要があります。
管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。

6. 「リスニング・アドレス」をOSBHOST1VHN1に設定します。「保存」をクリックします。

7. 変更を保存およびアクティブ化します。

この変更は、管理対象サーバーを再起動すると有効になります。

3. クラスタ・アドレスを更新して、新しいサーバーを追加します。

1. 管理コンソールで「環境」→「クラスタ」を選択します。

2. OSB_Clusterサーバーをクリックします。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:

OSBHOST1VHN1:8011,OSBHOST2VHN1:8011,OSBHOST1VHN2:8011

4. Oracle Service BusにJMSリクエスト/レスポンス機能を使用するビジネス・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順も実行する必要があります。

1. 「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。

2. プロジェクト・エクスプローラで、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索し、選択します。このタイプのビジネス・サービスは、「サービスのタイプ」としてメッセージング・サービスが表示されます。

3. 「詳細の表示」ページの下部にある「編集」をクリックします。

4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

5. 「ビジネス・サービスの編集 - サマリー」ページで「保存」をクリックします。

6. JMSリクエスト/レスポンスを使用する他のビジネス・サービスについて、それぞれ前の手順を繰り返します。

7. 「チェンジ・センター」で、「アクティブ化」をクリックしてセッションを作成します。

8. 管理対象サーバーを再起動します。

9. 管理サーバーを再起動します。

これで、ビジネス・サービスは、拡張されたドメインで操作できるように構成されています。

注意:

JMS MessageID相関スキームを使用するビジネス・サービスの場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加する必要があります。キューとトピック宛先の構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。

5. Oracle Service Busにクラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順も実行する必要があります。

1. 「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。

2. プロジェクト・エクスプローラで、クラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスを検索し、選択します。

3. 「詳細の表示」ページの下部にある「編集」をクリックします。

4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

5. 「プロキシ・サービスの編集 - サマリー」ページで「保存」をクリックします。

6. クラスタ・アドレスを含むJMSエンドポイントを使用する他のプロキシ・サービスについて、それぞれ前の手順を繰り返します。

7. 「チェンジ・センター」で、「アクティブ化」をクリックしてセッションを作成します。

8. 管理対象サーバーを再起動します。

これで、プロキシ・サービスは、拡張されたドメインで操作できるように構成されています。

6. 新しいサーバーのOracle Service Busの結果キャッシュのCoherence構成を更新する手順は次のとおりです。

1. 管理コンソールにログインします。「チェンジ・センター」で、「ロックして編集」をクリックします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。

5. 「サーバーの起動」タブをクリックします。

6. WLS_OSBnについて(改行を入れずに1行で)次のように入力します。

-DOSB.coherence.localhost=osbhost1vhnn -DOSB.coherence.localport=7890
-DOSB.coherence.wka1= osbhost1vhn1 -DOSB.coherence.wka1.port=7890
-DOSB.coherence.wka2= osbhost2vhn1 -DOSB.coherence.wka1.port=7890

注意:

この構成は、WLS_OSBnの起動時に、サーバーWLS_OSB1とWLS_OSB2が実行されていることを想定しています。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたCoherenceクラスタに、指定されたWKAアドレスを使用して参加できます。また、サーバーWLS_OSB1、WLS_OSB2およびWLS_OSBnをすべて再起動する場合、WLS_OSB1とWLS_OSB2が起動されてからWLS_OSBnが起動されることを確認します。これにより、WLS_OSBnが、WLS_OSB1またはWLS_OSB2のどちらかにより起動されたクラスタに参加できることが保証されます。サーバーの起動順序を考慮する必要のない構成にするには、WLS_OSB1とWLS_OSB2のWKAとしてWLS_OSBnのホストとポートを追加し、さらにWLS_OSBnのWKAとしてWLS_OSBnを追加する必要があります。

7. 変更を保存およびアクティブ化します(この変更を適用するには、Oracle Service Busサーバーを再起動する必要があります)。

7. 新しい管理対象サーバーにOSBのレポート作成/内部宛先のJMSサーバーと永続ストアを作成します。

1. 管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、OSB_rep_JMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.14.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/OSB_rep_JMSFileStore_N

2. OSBの新しいJMSサーバーを作成します(たとえば、OSB_rep_JMSServer_N)。このJMSサーバーに対して、OSB_rep_JMSFileStore_Nを使用します。OSB_rep_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。

3. サブデプロイメントを新規に作成し、これを新規JMSサーバーにターゲット指定します。

4. 次に挙げられている必要なすべてのキューを作成します。
wli.reporting.jmsprovider.queue_auto_x

wlsb.internal.transport.task.queue.email_auto_x

wlsb.internal.transport.task.queue.file_auto_x

wlsb.internal.transport.task.queue.ftp_auto_x

wli.reporting.jmsprovider_error.queue_auto_x

wlsb.internal.transport.task.queue.sftp_auto_x

8. 新しい管理対象サーバーにOSB JAX-RPCのJMSサーバー、永続ストアおよび宛先を作成します。

注意:

WebLogic JAX-RPC Webサービスの高度な拡張機能では、通常の(非分散)宛先を使用して、ローカルに処理するサービス・リクエストがローカル・メンバーにのみエンキューされることを保証します。

1. 管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、Wsee_rpc_JMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.14.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/Wsee_rpc_JMSFileStore_N

2. OSB JAX-RPCの新しいJMSサーバーを作成します(たとえば、OSB_rpc_JMSServer_N)。このJMSサーバーに対して、Wsee_rpc_JMSFileStore_Nを使用します。OSB_rpc_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。

3. 宛先と新たに作成されたOSB JMSサーバーでWseeJMSModule OSB JMSモジュールを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「WseeJmsModule」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。WseeJmsModuleの「設定」ページが表示されます。ステップdからvを実行して、この手順を完了します。

4. 「チェンジ・センター」で、「ロックして編集」をクリックします。「新規」をクリックします。

5. 「キュー」をクリックします。

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

7. キューの名前としてDefaultCallbackQueue-WseeJmsServer_auto_nと入力します。

8. JNDI名としてweblogic.wsee.DefaultCallbackQueue-WseeJmsServer_auto_nと入力します。

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

10. 「新しいサブデプロイメントの作成」をクリックします。

11. デフォルト名を受け入れます。

12. 「OK」をクリックします。

13. ターゲットとして「OSB_rpc_JMSServer_n」を選択します。

14. 「終了」をクリックします。

15. 変更をアクティブ化します。

16. 次のステップqからuに従って、宛先のローカルJNDI名を更新します。

17. 「チェンジ・センター」で、「ロックして編集」をクリックします。

18. 「WseeJmsModuleの設定」ページで、「DefaultCallbackQueue-WseeJmsServer_auto_n」宛先をクリックします。

19. 「一般構成」タブで、「詳細」をクリックします。

20. ローカルJNDI名をweblogic.wsee.DefaultCallbackQueueに更新します。

21. 変更をアクティブ化します。

22. DefaultQueue-WseeJmsServer_auto_nキューに対して、JNDI名としてweblogic.wsee.DefaultQueue-WseeJmsServer_auto_nを、ローカルJNDI名としてweblogic.wsee.DefaultQueueを使用して、ステップdからnを繰り返します。

9. 次のように新しいSAFエージェントを作成し、そのターゲットを新しく追加した管理対象サーバーに設定します。
管理コンソールで「サービス」→「メッセージング」→「ストア・アンド・フォワード・エージェント」を開き、新しいSAFエージェントReliableWseeSAFAgent_auto_Nを追加します。

永続ストアWsee_rpc_JMSFileStore_N (OSB JAX-RPC用に作成された永続ストア)を選択します。SAFエージェントのターゲットを新しい管理対象サーバーに設定し、変更をアクティブにします。

10. 新しいサーバーに対してTX永続ストアを構成します。これは、共有記憶域についての推奨事項で示されているように、他のノードから参照できる場所に構成します。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。

11. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OSBn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOSBHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_OSBn」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

12. 新しいノードでノード・マネージャがまだ起動されていない場合はそれを起動します。ノード・マネージャを起動するには、次のように、すでに存在しているノードの共有記憶域にあるインストールを使用します。

OSBHOSTN> WL_HOME/server/bin/startNodeManager

13. 管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーを停止します。

2. 新たに作成した管理対象サーバーWLS_OSBnが起動していることを確認します。

3. 新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/sbinspection.wsil)にアクセスします。

14. 新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

これはスケール・アップ操作であるため、ノード・マネージャ、サーバー移行に対して構成された環境および新しいOSB管理対象サーバーの浮動IPがあらかじめノードに用意されている必要があります。

次の手順を実行してサーバー移行を構成します。

1. 管理コンソールにログインします。

2. 左側のペインで、「環境」を開き、「サーバー」を選択します。

3. 移行を構成する新しい管理対象サーバーの名前を選択します。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。
たとえば、すでにWLS_OSB1が実行されているOSBHOST1上の新しい管理対象サーバーには、OSBHOST2を選択します。すでにWLS_OSB2が実行されているOSBHOST2上の新しい管理対象サーバーには、OSBHOST1を選択します。

移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

15. この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。

1. 管理対象サーバーWLS_OSBnを停止します。
そのためには、管理対象サーバーのPIDに対してkill -9 <pid>を実行します。ノードのPIDは、ps -ef | grep WLS_OSBnを使用して確認できます。

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを停止できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_OSBnのpidを確認します。

MW_HOME\jrockit_160_<バージョン>\bin\jps -l -v

2. ノード・マネージャ・コンソールを参照します。WLS_OSBnの浮動IPが無効になっていることを示すメッセージが表示されます。

3. ノード・マネージャがWLS_OSBnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージが、ノード・マネージャによってログに記録されます。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

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

トポロジのスケール・アウトでは、OSBで構成された新しい管理対象サーバーを新しいノードに追加します。

SOAサーバーをスケール・アウトするには、第5.13.21.2項「トポロジのスケール・アウト(新しいノードへの管理対象サーバーの追加)」の手順に従ってください。

OSBサーバーのトポロジをスケール・アウトするには、この項の手順に従ってください。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

- OSBで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。

- 新しいノードは、WebLogic ServerとOSBインストールの既存のホーム・ディレクトリに必要に応じてアクセスできます(新しいWLS_OSB管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用してください。この場合は、新しい場所にWebLogic ServerやOSBのバイナリをインストールする必要はありませんが、OSBサーバーを同じドメインの他のサーバー(SOAサーバー)を含むマシンにスケーリングしている場合を除き、新しいノードでドメイン構成をブートストラップするためにpackとunpackを実行する必要があります)。

注意:

共有記憶域にインストールが存在しない場合は、第5.14項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンを使用するOracle Service Busの高可用性の構成」の説明に従って、新しいノードにWebLogic Server、SOAおよびOSBをインストールする必要があります。

注意:

ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して、そのノードに共有記憶域内のインストールを追加するには、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、user_home/bea/beahomelistファイルを編集します。次の手順を参照してください。

トポロジをスケール・アウトするには:

1. 新しいノードで、既存のMiddlewareホームをマウントします。これには、OSBとSOA(ホームを共有する場合)インストールおよびドメイン・ディレクトリを含める必要があります。新しいノードが、ドメイン内の他のノードと同様に、このディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するために、次のコマンドを実行します。

OSBHOSTn>cd ORACLE_BASE/product/fmw/soa/
OSBHOSTn>./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. 管理コンソールを使用し、WLS_OSB1をクローニングして新しい管理対象サーバーを作成します。これにWLS_OSBnという名前を付けます。nは新しいマシンに割り当てる番号です。

注意:

これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。

7. リスニング・アドレスに対して、この新しい管理対象サーバーに使用する仮想ホスト名を割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、この仮想ホスト名により別のノードに移動できます。この仮想ホスト名は、OSB/SOAドメイン(同じドメインまたは別のドメイン)によって使用されているノードで実行されている他の管理対象サーバーで使用されているものとは異なっている必要があります。
次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。

6. 「リスニング・アドレス」をOSBHOSTnVHN1に設定します。

7. 「保存」をクリックします。

8. 変更を保存およびアクティブ化します。

変更内容は、管理対象サーバーが再起動されるまでは有効になりません。

8. クラスタ・アドレスを更新して、新しいサーバーを追加します。

1. 管理コンソールで「環境」→「クラスタ」を選択します。

2. OSB_Clusterサーバーをクリックします。OSB_Clusterの「設定」画面が表示されます。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 新しいサーバーのアドレスとポートを「クラスタ・アドレス」フィールドに追加します。例:

OSBHOST1VHN1:8011,OSBHOST2VHN1:8011,OSBHOSTNVHN1:8011

9. 新しい管理対象サーバーにOSBのレポート作成/内部宛先のJMSサーバーと永続ストアを作成します。

1. 管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、OSB_rep_JMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.14.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

ORACLE_BASE/admin/domain_name/cluster_name/jms/OSB_rep_JMSFileStore _N

2. OSBの新しいJMSサーバーを作成します(たとえば、OSB_rep_JMSServer_N)。このJMSサーバーに対して、OSB_rep_JMSFileStore_Nを使用します。OSB_rep_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。

3. 新たに作成されたOSB JMSサーバーが含まれるように、jmsresources OSB JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「jmsresources」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。jmsResourcesの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。jmsresourcesのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OSB1とWLS_OSB2)のJMS構成から生成されたwlsbJMSServerXXXXXXという形式のランダム名です。

サブデプロイメント「wlsbJMSServerXXXXXX」をクリックし、ターゲットに新しいOSB_rep_JMSServer_Nサーバーを追加します。

10. 新しい管理対象サーバーにOSB JAX-RPCのJMSサーバー、永続ストアおよび宛先を作成します。

注意:

WebLogic JAX-RPC Webサービスの高度な拡張機能では、通常の(非分散)宛先を使用して、ローカルに処理するサービス・リクエストがローカル・メンバーにのみエンキューされることを保証します。

1. 管理コンソールを使用して、新しいWseeJMSServerの新しい永続ストアを作成し、Wsee_rpc_JMSFileStore_Nのような名前を付けます。このストアのパスを指定します。このパスには、第5.14.1.3項「共有記憶域に関する前提条件」で推奨されている共有記憶域のディレクトリを指定します。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/Wsee_rpc_JMSFileStore_N

2. OSB JAX-RPCの新しいJMSサーバーを作成します(たとえば、OSB_rpc_JMSServer_N)。このJMSサーバーに対して、Wsee_rpc_JMSFileStore_Nを使用します。OSB_rpc_JMSServer_Nサーバーを、新たに作成した管理対象サーバー(WLS_OSBn)にターゲット指定します。

3. 宛先と新たに作成されたOSB JMSサーバーでWseeJMSModule OSB JMSモジュールを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「WseeJmsModule」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。WseeJmsModuleの「設定」ページが表示されます。ステップdからvを実行して、この手順を完了します。

4. 「チェンジ・センター」で、「ロックして編集」をクリックします。「新規」をクリックします。

5. 「キュー」をクリックします。

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

7. キューの名前としてDefaultCallbackQueue-WseeJmsServer_auto_nと入力します。

8. JNDI名としてweblogic.wsee.DefaultCallbackQueue-WseeJmsServer_auto_nと入力します。

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

10. 「新しいサブデプロイメントの作成」をクリックします。

11. デフォルト名を受け入れます。

12. 「OK」をクリックします。

13. ターゲットとして「OSB_rpc_JMSServer_n」を選択します。

14. 「終了」をクリックします。

15. 変更をアクティブ化します。

16. 次のステップqからuに従って、宛先のローカルJNDI名を更新します。

17. 「チェンジ・センター」で、「ロックして編集」をクリックします。

18. 「WseeJmsModuleの設定」ページで、「DefaultCallbackQueue-WseeJmsServer_auto_n」宛先をクリックします。

19. 「一般構成」タブで、「詳細」をクリックします。

20. ローカルJNDI名をweblogic.wsee.DefaultCallbackQueueに更新します。

21. 変更をアクティブ化します。

22. DefaultQueue-WseeJmsServer_auto_nキューに対して、JNDI名としてweblogic.wsee.DefaultQueue-WseeJmsServer_auto_nを、ローカルJNDI名としてweblogic.wsee.DefaultQueueを使用して、ステップdからnを繰り返します。

11. 次のように新しいSAFエージェントを作成し、そのターゲットを新しく追加した管理対象サーバーに設定します。
管理コンソールで「サービス」→「メッセージング」→「ストア・アンド・フォワード・エージェント」を開き、新しいSAFエージェントReliableWseeSAFAgent_auto_Nを追加します。

永続ストアWsee_rpc_JMSFileStore_N (OSB JAX-RPC用に作成された永続ストア)を選択します。SAFエージェントのターゲットを新しい管理対象サーバーに設定し、変更をアクティブにします。

12. Oracle Service BusにJMSリクエスト/レスポンス機能を使用するビジネス・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順も実行する必要があります。

1. 「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。

2. プロジェクト・エクスプローラで、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索し、選択します。このタイプのビジネス・サービスは、「サービスのタイプ」としてメッセージング・サービスが表示されます。

3. 「詳細の表示」ページの下部にある「編集」をクリックします。

4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

5. 「ビジネス・サービスの編集 - サマリー」ページで「保存」をクリックします。

6. JMSリクエスト/レスポンスを使用する他のビジネス・サービスについて、それぞれ前の手順を繰り返します。

7. 「チェンジ・センター」で、「アクティブ化」をクリックしてセッションを作成します。

8. 管理対象サーバーを再起動します。

9. 管理サーバーを再起動します。

これで、ビジネス・サービスは、拡張されたドメインで操作できるように構成されています。

注意:

JMS MessageID相関スキームを使用するビジネス・サービスの場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加する必要があります。キューとトピック宛先の構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。

13. Oracle Service Busにクラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスが1つ以上構成されている場合、クラスタに新しい管理対象サーバーを追加した後で、Oracle Service Busコンソールから次の手順も実行する必要があります。

1. 「チェンジ・センター」で、「作成」をクリックしてセッションを作成します。

2. プロジェクト・エクスプローラで、クラスタ・アドレスを含むJMSエンドポイントを使用するプロキシ・サービスを検索し、選択します。

3. 「詳細の表示」ページの下部にある「編集」をクリックします。

4. エンドポイントURIにクラスタ・アドレスが含まれる場合、そのクラスタ・アドレスに新しいサーバーを追加します。

5. 「プロキシ・サービスの編集 - サマリー」ページで「保存」をクリックします。

6. クラスタ・アドレスを含むJMSエンドポイントを使用する他のプロキシ・サービスについて、それぞれ前の手順を繰り返します。

7. 「チェンジ・センター」で、「アクティブ化」をクリックしてセッションを作成します。

8. 管理対象サーバーを再起動します。

これで、プロキシ・サービスは、拡張されたドメインで操作できるように構成されています。

14. 新しいサーバーのOracle Service Busの結果キャッシュのCoherence構成を更新する手順は次のとおりです。

1. 管理コンソールにログインします。「チェンジ・センター」で、「ロックして編集」をクリックします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。

5. 「サーバーの起動」タブをクリックします。

6. WLS_OSBnについて(改行を入れずに1行で)次のように入力します。

-DOSB.coherence.localhost=osbhostnvhn1 -DOSB.coherence.localport=7890
-DOSB.coherence.wka1= osbhost1vhn1 -DOSB.coherence.wka1.port=7890
-DOSB.coherence.wka2= osbhost2vhn1 -DOSB.coherence.wka1.port=7890

注意:

前述の構成は、WLS_OSBnの起動時に、サーバーWLS_OSB1とWLS_OSB2が実行されていることを想定しています。これによりWLS_OSBnは、WLS_OSB1またはWLS_OSB2のどちらかによって起動されたCoherenceクラスタに、指定されたWKAアドレスを使用して参加できます。また、サーバーWLS_OSB1、WLS_OSB2およびWLS_OSBnをすべて再起動する場合、WLS_OSB1とWLS_OSB2が起動されてからWLS_OSBnが起動されることを確認します。これにより、WLS_OSBnが、WLS_OSB1またはWLS_OSB2のどちらかにより起動されたクラスタに参加できることが保証されます。サーバーの起動順序を考慮する必要のない構成にするには、WLS_OSB1とWLS_OSB2のWKAとしてWLS_OSBnのホストとポートを追加し、さらにWLS_OSBnのWKAとしてWLS_OSBnを追加する必要があります。

7. 変更を保存およびアクティブ化します(この変更を適用するには、Oracle Service Busサーバーを再起動する必要があります)。

15. 次のようにpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

SOAHOST1> ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをOSBHOSTnにコピーします。

SOAHOST1> scp soadomaintemplateScale.jar oracle@OSBHOSTN:/ ORACLE_BASE/product/fmw/soa/common/bin

次のようにOSBHOSTNでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。

OSBHOSTN> cd ORACLE_BASE/product/fmw/soa/common/bin

OSBHOSTN> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/ -template=soadomaintemplateScale.jar

16. 新しいサーバーに対してTX永続ストアを構成します。これは、共有記憶域についての推奨事項で示されているように、他のノードから参照できる場所に構成します。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。

17. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OSBn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOSBHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_OSBn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

18. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。

OSBHOSTN> WL_HOME/server/bin/startNodeManager <new_node_ip>

19. 管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーをすべて停止します。

2. 新しく作成した管理対象サーバーWLS_OSBnが実行中であることを確認します。新しく作成した管理対象サーバー上のアプリケーション(http://vip:port/sbinspection.wsil)にアクセスします。アプリケーションが機能している必要があります。

20. 新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャと、ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しいOSB管理対象サーバーの浮動IPが存在します。

次の手順を実行してサーバー移行を構成します。

1. 管理コンソールにログインします。

2. 左側のペインで、「環境」を開き、「サーバー」を選択します。

3. 移行を構成するサーバー(ハイパーリンクで表示)を、表の「名前」列から選択します。このサーバーの「設定」ページが表示されます。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
たとえば、すでにWLS_OSB1が実行されているOSBHOST1上の新しい管理対象サーバーには、OSBHOST2を選択します。すでにWLS_OSB2が実行されているOSBHOST2上の新しい管理対象サーバーには、OSBHOST1を選択します。

注意:

新しいサーバーの移行ターゲットには、負荷が最小のマシンを指定することをお薦めします。このノードのリソースが追加の管理対象サーバーの持続に十分対応できるように、必須の容量計画を立てる必要があります。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

21. この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。

1. 管理対象サーバーWLS_OSBnを停止します。
そのためには、管理対象サーバーのPIDに対してkill -9 <pid>を実行します。ノードのPIDは、ps -ef | grep WLS_OSBnを使用して確認できます。

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了します。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_OSBnのpidを確認します。

MW_HOME\jrockit_160_<バージョン>\bin\jps -l -v

2. ノード・マネージャ・コンソールに、WLS_OSBnの浮動IPが無効になったことを示すメッセージが表示されることを確認します。

3. ノード・マネージャがWLS_OSBnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

5.15 Oracle BAMの高可用性の構成

この項では、BAMに2ノードの高可用性構成を設定する方法を説明します。BAM ServerアプリケーションとBAM Webアプリケーションについても触れます。

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

- 第5.15.1項「環境の準備: Oracle BAMの高可用性構成の設定前に必要な手順」

- 第5.15.2項「WEBHOST1へのOracle HTTP Serverのインストール」

- 第5.15.3項「Oracle Fusion Middlewareホームのインストール」

- 第5.15.4項「BAMHOST1でのVIP0とVIP1の有効化」

- 第5.15.5項「WebLogic ServerのOracle BAMドメインを作成するためのBAMHOST1でのOracle Fusion Middleware構成ウィザードの実行」

- 第 5.15.6項「BAMHOST1での管理サーバー用およびWLS_BAM1用boot.propertiesの作成」

- 第5.15.7項「BAMHOST1での管理サーバーの起動」

- 第5.15.8項「サーバーに対するホスト名の検証の無効化」

- 第5.15.9項「BAM UMS用のJMS永続ストアの構成」

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

- 第5.15.11項「BAMHOST2からのBAM Serverシステムのターゲット指定解除」

- 第5.15.12項「pack/unpackユーティリティを使用したBAMHOST1からのドメイン構成の伝播」

- 第5.15.13項「BAMHOST1およびBAMHOST2でのノード・マネージャの起動」

- 第5.15.14項「Oracle BAMシステムの起動」

- 第5.15.15項「WLS_BAMサーバーのOracle RACフェイルオーバーの構成」

- 第5.15.16項「BAMHOST1でBAM Serverを使用するためのBAM Webアプリケーションの構成」

- 第5.15.17項「Oracle HTTP Serverの管理サーバーおよびWLS_BAMn管理対象サーバーの構成」

- 第5.15.18項「Oracle HTTP Serverを使用したアクセスの検証」

- 第5.15.19項「WLS_BAMサーバーのサーバー移行の構成」

構成手順では次のアーキテクチャを対象とします。

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

注意:

このガイドで定義されているアーキテクチャとデプロイメント手順を使用することにより、単純なクラスタ・デプロイメントを実現できます。各章に記載されている手順は、このトポロジおよび他の類似する高可用性トポロジを、該当するFusion Middlewareコンポーネントで実現する場合の基礎的要素として使用できます。また、本番デプロイメントでは、セキュリティ・ポリシーと一元的なLDAPサーバーを関連付けるなど、この他にも必要な手順を使用することが予想されます。セキュアな複数層アーキテクチャおよびデプロイメント手順の詳細は、構成対象のコンポーネントのエンタープライズ・デプロイメント・ガイドを参照してください。

図5-54は、この項の構成手順で作成するアーキテクチャの例を表しています。

図5-54 Oracle BAMの高可用性アーキテクチャ

「図5-54 Oracle BAMの高可用性アーキテクチャ」の説明

図5-54は、Oracle BAM Webアプリケーションを実行する2ノードのクラスタを表しています。一方のノードでは、Oracle BAM Serverも実行されています。Oracle WebLogic Serverは、BAM Webアプリケーションへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。ロード・バランサは、システムをフロントエンド処理し、クライアントからのリクエストを2つのHTTP Serverに配布します。Oracle RACデータベースは、メタデータとBAMスキーマを格納します。

5.15.1 環境の準備: Oracle BAMの高可用性構成の設定前に必要な手順

次の各項では、Oracle BAMの高可用性構成を設定する前に必要となる手順について説明します。

5.15.1.1 データベースに関する前提条件

Oracle BAMでは、サポートされているデータベースが存在している必要があります。

データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。

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

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

5.15.1.2 VIPとIPに関する前提条件

アーキテクチャの図で示すような、2つの異なる仮想IPをリスニングするBAMHOST1上の管理サーバーとBAM Serverを、表5-19のように構成します。そのためには、ボックス内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。インストールを実行する前に、各VIPが使用可能であり、BAMHOST1とBAMHOST2からアクセスできることを確認します。

表5-19 仮想ホスト

仮想IP

VIPのマップ先

説明

VIP0

BAMHOST1VHN0

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

VIP1

BAMHOST1VHN1

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

5.15.1.3 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

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

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

自動ストレージ管理

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

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

- インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

データベースの初期化パラメータ

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

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

パラメータ

必要な値

パラメータ・クラス

PROCESSES

300以上

静的

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

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

SQL> SHOW PARAMETER processes

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

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

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

注意:

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

5.15.1.4 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したOracle Fusion Middlewareスキーマのロード

Oracle Fusion Middleware BAMのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとBAMスキーマをReal Application Clusterデータベースにインストールします。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

5.15.1.4.1 RCUの実行

RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。

1. 次のコマンドを使用してRCUを起動します。

RCU_HOME/bin/rcu &

2. 「ようこそ」画面で「次へ」をクリックします。

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

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

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

- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを指定します: BAMDBHOST1VIRTUAL

- ポート: データベースのポート番号: 1521

- サービス名: データベースのサービス名を入力します: bamha.mycompany.com

- ユーザー名: SYS

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

- ロール: SYSDBA

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

6. 次のような警告メッセージを受信する場合があります。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。

7. その場合は、「無視」または「停止」をクリックします。

8. 「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、BAMHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。

- 次のスキーマを選択します。

- AS共通スキーマ:
Metadata Services

- SOAインフラストラクチャ:
Business Activity Monitoring

User Messaging

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

10. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。

11. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

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

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

RCUの使用方法の詳細は、Oracle Fusion Middlewareインストレーションの概念およびリポジトリ作成ユーティリティ・ユーザーズ・ガイドを参照してください。

5.15.1.5 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle BAMの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

Oracle BAMは、2つのOracle HTTP ServerがWeb層コンポーネントとして含まれた高可用性構成にデプロイされた場合は、ハードウェア・ロード・バランサを使用します。ハードウェア・ロード・バランサには、次の機能が必要です。

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

- ポート変換の構成: ロード・バランサには、1つのポートで受信した受信リクエストを別のポートで実行されているサーバー・プロセスにルーティングできるポート変換機能が必要です。たとえば、ポート80で受信したリクエストをポート7777にルーティングできます。

- ポート(HTTP/HTTPS)の監視

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

- ロード・バランサには複数の仮想サーバーを構成できる必要があります。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、通常は、HTTPおよびHTTPSトラフィック用の仮想サーバーとポートでロード・バランサを構成する必要があります。

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

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

- リソースの監視/ポートの監視/プロセス障害検出: ロード・バランサは、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへの非Oracle Netトラフィックの送信を停止できる必要があります。ロード・バランサに障害の自動検出機能がある場合は、それを使用する必要があります。

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

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

- スティッキーなルーティング機能: CookieまたはURLに基づいたコンポーネントへのスティッキーな接続を維持する機能。

- SSLアクセラレーション: SSLアクセラレーションは、SSLトランザクションで実行され、プロセッサを集中的に使用する公開鍵暗号化アルゴリズムを、ハードウェア・アクセラレータにオフロードする方法です。
この機能は推奨されますが、必須ではありません。

表5-21は、Oracle BAMの高可用性環境で外部ロード・バランサに使用する仮想サーバー名の例を示しています。

表5-21 BAMの外部ロード・バランサの仮想サーバー名とポート

コンポーネント

仮想サーバー名

Oracle BAM

bam.mycompany.com

WebLogic Server管理コンソール

admin.mycompany.com

Oracle Enterprise Manager Fusion Middleware Control

admin.mycompany.com

仮想サーバー名

この項では、この章で説明する高可用性デプロイメントのために設定が必要な仮想サーバー名について説明します。

bam.mycompany.com

bam.mycompany.comは、ランタイムBAM WebコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、アドレスbam.mycompany.com:443を使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

admin.mycompany.com

この仮想サーバーは、管理サービスへ送信されるすべての内部HTTPトラフィックのアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスadmin.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777に順に転送されます。この仮想ホストでアクセスされるサービスには、WebLogic管理サーバー・コンソールやOracle Enterprise Managerなどがあります。

さらに、仮想サーバー名に対応するIPアドレスが設定されていることと、仮想サーバー名がドメイン・ネーム・システム(DNS)に登録されていることを確認します。Oracle Fusion Middlewareを実行するコンピュータには、これらの仮想サーバー名を解決できることが必要です。

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

WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。

1. サーバーが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』で指定されている要件を満たしています。

- ポート7777が、ノード上のどのサービスによっても使用されていない。このことを確認するには、次のコマンドを実行します。
UNIX:

netstat -an | grep LISTEN | grep ":7777"

Windows:

netstat -an | findstr "LISTEN" | findstr ":7777"

ポートを使用中の場合は、それらのポートを使用可能にします。

2. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

3. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンドrunInstallerを実行します。

Windowsでは、setup.exeをダブルクリックします。

4. 「ようこそ」画面で「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

6. 「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。

7. 「インストール場所の指定」画面で、場所を次のように設定します。
/u01/app/oracle/product/11.1.1/ohs_1

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

9. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

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

10. 「コンポーネントの詳細の指定」画面で、次の値を入力します。

- インスタンス・ホームの場所: /u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1

- インスタンス名: ohs_instance1

- OHSコンポーネント名: ohs1

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

12. 「ポートの構成」画面で、次の手順を実行します。

- 「構成ファイルを使用してポートを指定」を選択し、インストール・ディスクからユーザーのホームにstaticports.iniテンプレート・ファイルをコピーします(このファイルは/Disk1/stage/Responseディレクトリにあります)。次に、「参照」ボタンを使用して、このファイルを選択します。

- ファイルの表示/編集をクリックして、エディタでstaticports.iniファイルを開きます。

- このファイルのOracle HTTP Serverポートを7777に変更します。

- ファイルを保存します。

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

14. 「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。

15. 「インストールの進行状況」画面で、次の操作を行います。
UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

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

16. 「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。

17. 「構成が完了しました」画面で、「終了」をクリックして終了します。

18. WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランシング・ルーターを構成します。

5.15.2.1 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、ブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

HTTP://WEBHOST1:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザに「Hello World」ページが表示されます。

5.15.3 Oracle Fusion Middlewareホームのインストール

この項では、Oracle WebLogic ServerとOracle Fusion Middleware BAMを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする方法について説明します。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

- Oracle WebLogic Server(第5.15.3.1項「Oracle WebLogic Serverのインストール」を参照)

- Oracle SOA Suite(第5.15.3.2項「Oracle SOA Suiteインストーラを使用したOracle BAMのインストール」を参照)

5.15.3.1 Oracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。

1. Oracle WebLogic Serverインストーラを起動します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」フィールドで、MW_HOMEと入力します。

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

4. 「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。

6. 「製品とコンポーネントの選択」画面で、「次へ」をクリックします。

7. 「JDKの選択」画面で、「Oracle JRockit 160_20_D1.0.1-2124 SDK」のみを選択して「次へ」をクリックします。

8. 「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
WL_HOME

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

9. 「インストールの概要」画面で「次へ」をクリックします。

10. 「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。

5.15.3.2 Oracle SOA Suiteインストーラを使用したOracle BAMのインストール

Oracle BAMは、Oracle SOA Suiteの一部としてインストールされます。11g Oracle SOA Suiteインストーラを使用して、アプリケーション層のすべてのノードに対し、次のように必要なOracle BAMバイナリをインストールします。

1. Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

2. Oracle FMW 11g SOA Suiteインストーラを起動します。
UNIXの場合:

BAMHOST1> runInstaller

Windowsの場合:

BAMHOST1> setup.exe

Oracle FMW 11g SOA Suiteインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_<バージョン>のように入力します。

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

5. 「インストール場所の指定」画面で、次の操作を行います。

- 「MiddleWareホーム」には、MW_HOMEと入力します。

- 「Oracleホーム・ディレクトリ」には、soaと入力します。

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

6. 「インストール・サマリー」画面で「インストール」をクリックします。

7. 「インストール完了」画面で「終了」をクリックします。

5.15.4 BAMHOST1でのVIP0とVIP1の有効化

管理サーバーの仮想IPの構成および高可用性のための管理サーバーの構成の詳細は、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。

5.15.5 WebLogic ServerのOracle BAMドメインを作成するためのBAMHOST1でのOracle Fusion Middleware構成ウィザードの実行

SOAホーム・ディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracle BAMコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。

1. SOA/BAMホーム・ディレクトリにある、Oracle Fusion Middlewareの構成ウィザードの場所に、ディレクトリを変更します。

BAMHOST1> cd ORACLE_HOME/common/bin

2. Oracle Fusion Middlewareの構成ウィザードを起動します。
UNIXの場合:

BAMHOST1> ./config.sh

Windowsの場合:

BAMHOST1> config.cmd

3. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

4. 「ドメイン・ソースの選択」で、「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択して、次の製品を選択します(デフォルトでは、Basic WebLogic Server Domain - 10.3.6.0が選択されています)。

- Oracle Business Activity Monitoring

- Oracle WSM-PM(デフォルトで選択)

- Enterprise Manager

- JRF(デフォルトで選択)

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

5. 「ドメイン名と場所の指定」画面で、次のエントリを作成します。

- ドメイン名: bamdomain

- ドメインの場所: デフォルトを受け入れます。

- アプリケーションの場所: デフォルトを受け入れます。

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

6. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者が使用するユーザー名とパスワードを入力します。「次へ」をクリックします。

7. 「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。

- WebLogicドメインの起動モード: 「本番モード」を選択

- JDKの選択: 「Oracle SDK1.6.0_05」を選択

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

8. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

図5-55 JDBCコンポーネント・スキーマの構成

「図5-55 JDBCコンポーネント・スキーマの構成」の説明

1. 画面に次のデータ・ソースが表示されていることを確認します。表5-22に示されているユーザー名は、RCUからのスキーマ作成で接頭辞にbamhaが使用されていることを想定しています。

表5-22 データ・ソースの値の構成

データ・ソース

ユーザー名

BAMDataSource

bamha_orabam

OraSDPMDataSource

bamha_orasdpm

mds-owsm

bamha_mds

2. 「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択します。単一のデータベース構成の場合は、「変換しない」を選択します。「変換しない」を選択した場合は、ステップ10にスキップします。

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

9. 「JDBCコンポーネント・スキーマの構成」画面で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
マルチ・データ・ソースの場合は、次のフィールドに値を入力します。

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

「図5-56「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。

図5-57 GridLink RACコンポーネント・スキーマの構成

「図5-57 GridLink RACコンポーネント・スキーマの構成」の説明

すべてのスキーマを選択した状態で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

1. ドライバ: RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

2. サービス名 : データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、 <mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(example.comなど)を含むRACサービス名を登録または追加することをお薦めします。

3. ユーザー名: スキーマの完全ユーザー名(接頭辞を含む)を入力します。

4. パスワード: スキーマへのアクセスに使用するパスワードを入力します。

5. GridLinkデータ・ソースの場合は、SCANアドレスをリスナー・アドレス・フィールドに入力し、「ポート」フィールドにSCANポートを入力します。「ONSホスト」と「ポート」の各フィールドに、ONSホストおよびポート情報を入力します。

注意:

WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、SCANアドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、ネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。

マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。

6. 一度に1つのデータ・ソースを選択し、適切な詳細を追加することにより、各スキーマを更新します。
すべてのスキーマ(BAMスキーマのみ、ユーザー・メッセージング・サービスのみ、OWSM MDSスキーマのみ)に情報が入力されていることを確認します。

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

10. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックしてエントリを修正します。
すべての接続が正常になったら「次へ」をクリックします。

11. 「オプションの構成を選択」画面で、「管理サーバー」→「管理対象サーバー」→クラスタとマシン→デプロイメントとサービスを選択して、「次へ」をクリックします。

12. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: VIP0

- リスニング・ポート: 7001

- SSLリスニング・ポート: N/A

- SSL有効: 選択を解除

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

13. 「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。

表5-23 管理対象サーバーの構成

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_BAM1

BAMHOST1VHN1

8001

n/a

いいえ

WLS_BAM2

BAMHOST2(BAM Server WLS_BAM2はサーバー移行を使用しません)

8001

n/a

いいえ

注意:

標準の推奨事項は、個々のWebLogic管理対象サーバー内でカスタム・アプリケーションおよび他のシステムを実行するためのものです。図5-54で説明しているカスタムWLS管理対象サーバーの作成については、ここでは取り上げません。

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

14. 「クラスタの構成」画面で、次のクラスタを追加します。

- 名前: BAM_Cluster

- クラスタ・メッセージング・モード: unicast

- マルチキャスト・アドレス: N/A

- マルチキャスト・ポート: N/A

- クラスタ・アドレス: 空白のまま

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

15. 「サーバーのクラスタへの割当」画面で、BAM_Clusterに次のサーバーを割り当てます。

- WLS_BAM1

- WLS_BAM2

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

16. 「マシンの構成」画面で、次の操作を行います。

- デフォルトとして表示される「LocalMachine」を削除します。

- 「UNIXマシン」タブをクリックし、次のマシンを追加します。

表5-24 マシンの構成

名前

ノード・マネージャのリスニング・アドレス

BAMHOST1

BAMHOST1

BAMHOST2

BAMHOST2

その他すべてのフィールドをデフォルト値のままにして、「次へ」をクリックします。

17. 「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

- BAMHOST1: AdminServer、WLS_BAM1

- BAMHOST2: WLS_BAM2

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

18. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- ユーザー・メッセージングのデプロイメントがBAM_Clusterにのみターゲット指定されていること(usermessaging-xmpp、usermessaging-smppおよびusermessaging-voicexmlの各アプリケーションはオプションです)。

- wsm-pmがBAM_Clusterにのみターゲット指定されていること。

- DMSアプリケーションがBAM_Clusterと管理サーバーにターゲット指定されていること。

- oracle.rules.*、oracle.sdp.*、oracle.bam.*の各デプロイメントがBAM_Clusterにのみターゲット指定されていること。

- oracle.wsm.seedpoliciesライブラリがBAM_Clusterにのみターゲット指定されていること。

19. 「サービスのクラスタまたはサーバーへのターゲット設定」画面で、次のターゲットを確認します。

- WSMの起動クラスがBAM_Clusterにのみターゲット指定されていること。

- mds-wsm、mds-wsm-rac0およびmds-wsm-rac1が、BAM_ClusterとAdminServerの両方にターゲット指定されていること。

- OrasDPMDatasource、OrasDPMDatasource-rac0およびOrasDPMDatasource-rac1がBAM_Clusterにターゲット指定されていること。

- OWSMの起動クラスがBAM_Clusterにのみターゲット指定されていること、DMSの起動クラスが、BAM_ClusterとAdminServerの両方にターゲット指定されていること、mds-wsm、mds-wsm-rac0およびmds-wsm-rac1が、BAM_ClusterとAdminServerの両方にターゲット指定されていること。

- mds-soa、mds-soa-rac0およびmds-soa-rac1が、BAM_ClusterとAdminServerの両方にターゲット指定されていること。

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

21. ドメインの作成中画面で「完了」をクリックします。

5.15.6 BAMHOST1での管理サーバー用およびWLS_BAM1用boot.propertiesの作成

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。BAMHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。

管理サーバーに対しては、次の手順を実行します。

1. 次のディレクトリを作成します。

mkdir ORACLE_BASE/product/fmw/user_projects/domains/bamdomain/servers/AdminServer/security

2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminuser
password=password

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

5.15.7 BAMHOST1での管理サーバーの起動

BAMHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

Linuxの場合:

BAMHOST1> cd MW_HOME/user_projects/domains/bamdomain/bin

BAMHOST1> ./startWebLogic.sh

Windowsの場合:

startWebLogic.cmd

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. ブラウザでhttp://VIP0:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. 管理対象サーバーとしてWLS_BAM1およびWLS_BAM2が表示されていることを確認します。

4. BAM_Clusterクラスタが表示されていることを確認します。

5. Enterprise Manager(http://VIP0:7001/em)にアクセスできることを確認します。

5.15.8 サーバーに対するホスト名の検証の無効化

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。

ホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールで、「管理サーバー」→「SSL」→「詳細」を選択します。

2. 「ホスト名の検証」を「なし」に設定します。

3. 管理コンソールで、「WLS_BAM1」→「SSL」→「詳細」を選択します。

4. 「ホスト名の検証」を「なし」に設定します。

5. 管理コンソールで、「WLS_BAM2」→「SSL」→「詳細」を選択します。

6. 「ホスト名の検証」を「なし」に設定します。

7. 管理サーバーを再起動して、変更を有効にします。

8. 変更を保存およびアクティブ化します。

5.15.9 BAM UMS用のJMS永続ストアの構成

BAMHOST1とBAMHOST2の両方から参照できるディレクトリに、すべての永続ストアの場所を構成します。これは、サーバーが別のノードに移行されたときにトランザクションを再開できるようにするために必要です。両方のノードで永続ストアの共有場所を使用することで、フェイルオーバーが発生してもメッセージが失われないことが保証されます。

注意:

JMSメッセージ、トランザクション・ログおよびファイル・ストアでのロックの解放に関する重要な情報は、「NFSでのファイル・ストアの使用に関する考慮事項」を参照してください。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。
「永続ストアの概要」ページが表示されます。

3. 表の「名前」列から永続ストア(ハイパーリンクとして表示)を選択します。
その永続ストアの「設定」ページが表示されます。

4. 「構成」タブで、クラス内の他のサーバーで使用可能な永続記憶域ソリューション(NASやSANなど)の場所を、「ディレクトリ」フィールドに入力します。この場所を指定することで、保留中のJMSメッセージを送信できます。

5. 「保存」をクリックします。

6. 同じ手順をすべての永続ストアに対して実行します。

7. 変更を保存およびアクティブ化します。

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

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。

デフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。
「サーバーの概要」ページが表示されます。

3. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。
選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

4. 「サービス」タブをクリックします。

5. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。

6. 変更を保存およびアクティブ化します。

注意:

トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。このディレクトリは、サーバーを再起動する前にも存在している必要があります。

5.15.11 BAMHOST2からのBAM Serverシステムのターゲット指定解除

BAM内のBAM Serverコンポーネントはシングルトンであるため、サーバー移行に対して構成する前に、WLS_BAMサーバーのいずれかから、そのコンポーネントのターゲット指定を解除する必要があります。解除しないと、2つのアクティブなBAM Serverが使用されることになり、データが異なるための不整合の原因となります。このように、BAM WebアプリケーションはBAMHOST1とBAMHOST2の両方で実行されますが、BAM Serverは、最初はBAMHOST1でのみアクティブになります。

次の手順では、WLS_BAM2からBAM Serverランタイムを削除します。WLS_BAM2からBAM Serverアーティファクトのターゲット指定を解除する手順は次のとおりです。

1. Oracle WebLogic管理コンソール(http://BAMHOST1VHN0:7001/console)にログインします。

2. 「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択します。
「サーバーの概要」ページが表示されます。

3. 表の「名前」列で「WLS_BAM2」を選択します。
WLS_BAM2の「設定」ページが表示されます。

4. 「デプロイメント」タブをクリックします。

5. 表の「名前」列から「oracle-bam」アプリケーションを選択します。
oracle-bamアプリケーションの「設定」ページが表示されます。

6. 「ターゲット」タブをクリックします。

7. 「チェンジ・センター」で、「ロックして編集」をクリックします。

8. 表5-25の説明に従って、モジュールのターゲットを変更します。
変更を保存およびアクティブ化します。

注意:

表5-25の説明に従って、これらのコンポーネントをすべてターゲット指定する必要があります。ターゲット指定を誤ると、BAMシステムが起動しなくなります。

表5-25 oracle-bamコンポーネントのターゲット・タイプ

コンポーネント

タイプ

ターゲット

oracle-bam(11.1.1)

エンタープライズ・アプリケーション

BAM_Cluster

/oracle/bam

WEBAPP

WLS_BAM1

oracle-bam-adc-ejb.jar

EJB

WLS_BAM1

oracle-bam-ems-ejb.jar

EJB

WLS_BAM1

oracle-bam-eventengine-ejb.jar

EJB

WLS_BAM1

oracle-bam-reportcache-ejb.jar

EJB

WLS_BAM1

oracle-bam-statuslistener-ejb.jar

EJB

WLS_BAM1

OracleBAM

WEBAPP

BAM_Cluster

OracleBAMWS

WEBAPP

BAM_Cluster

sdpmessagingclient-ejb.jar

EJB

WLS_BAM1

5.15.12 pack/unpackユーティリティを使用したBAMHOST1からのドメイン構成の伝播

Pack/Unpackユーティリティを使用して、ドメイン構成をBAMHOST1に伝播する手順は次のとおりです。

1. 次のpackコマンドをBAMHOST1で実行し、テンプレート・パックを作成します。

BAMHOST1> cd ORACLE_COMMON_HOME/common/bin
BAMHOST1> ./pack.sh -managed=true
domain=ORACLE_BASE/product/fmw/user_projects/domains/bamdomain/
-template=bamdomaintemplate.jar
-template_name=bam_domain_template

2. unpackコマンドをBAMHOST2で実行し、伝播されたテンプレートを解凍します。

BAMHOST2> cd ORACLE_COMMON_HOME/common/bin
BAMHOST2> ./unpack.sh
-domain=MW_HOME/user_projects/domains/bamdomain/
-template=bamdomaintemplate.jar

5.15.13 BAMHOST1およびBAMHOST2でのノード・マネージャの起動

BAMHOST1およびBAMHOST2でノード・マネージャを起動する手順は次のとおりです。

1. setNMProps.shスクリプトを実行します。このスクリプトはORACLE_COMMON_HOME/common/binディレクトリに格納されています。
このスクリプトによって、ノード・マネージャを起動する前にStartScriptEnabledプロパティがtrueに設定され、管理コンソールからサーバーを起動できるようになります(BAM Serverに必要な環境変数は、ドメイン・ディレクトリのデフォルトの起動スクリプトに設定されています)。

BAMHOST1> cd ORACLE_COMMON_HOME/common/bin
BAMHOST1> ./setNMProps.sh

注意:

クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

2. 次のコマンドを実行してノード・マネージャを起動します。

BAMHOST1> cd WL_HOME/server/bin
BAMHOST1> ./startNodeManager.sh

3. BAMHOST2のノード・マネージャに対してステップ1と2を繰り返します。

5.15.14 Oracle BAMシステムの起動

BAMHOST1上の管理対象サーバーWLS_BAM1を起動する手順は次のとおりです。

1. 管理対象サーバーWLS_BAM1を起動します。

1. 次のURLを使用して、管理コンソールにログインします。
http://bamhost1vhn0:7001/console

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」を選択します。
「サーバーの概要」ページが表示されます。

3. 「制御」タブをクリックします。

4. 表の「サーバー」列から「WLS_BAM1」を選択します。

5. 「起動」をクリックします。

2. http://bamhost1vhn1:9001/OracleBAMにアクセスしてWLS_BAM1のステータスを確認します。

3. 管理対象サーバーWLS_BAM2を起動します。

1. http://bamhost1vhn0:7001/consoleから、管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」を選択します。
「サーバーの概要」ページが表示されます。

3. 「制御」タブをクリックします。

4. 表の「サーバー」列から「WLS_BAM2」を選択します。

5. 「起動」をクリックします。

4. HTTP://BAMHOST2:9001/OracleBAMにアクセスしてWLS_BAM2の状態を確認します。

管理対象サーバーが次のメッセージで起動に失敗した場合、

Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was <db_connect_string>

データベースのPROCESSES初期化パラメータができるだけ高い値に設定されていることを確認してください。

5.15.15 WLS_BAMサーバーのOracle RACフェイルオーバーの構成

Oracle RACをBAMスキーマのリポジトリとして使用しているときにデータベースで障害が発生した場合のBAMサーバーの動作を、Oracle BAMでカスタマイズできます。このカスタマイズを可能にするプロパティは、アプリケーションに応じて、また各BAMシステムに必要とされる動作に基づいて調整できます。プロパティは、Fusion Middleware Controlのコンソール・システムのMBeanブラウザ、またはOracle BAM固有の対応のXML構成ファイルで構成されます。

データベースに対するOracle BAMのフェイルオーバーをOracle RAC構成で完全に無効化する場合は、Fusion Middleware Controlのコンソール・システムのMBeanブラウザで、BAMサーバーのUseDBFailoverをfalseに設定します。このプロパティのデフォルト値はtrueです。つまり、フェイルオーバーが実行されます。また、データベース・インスタンス障害時のデータベースへのアクセス試行回数(進行中のトランザクションでBAMが再試行する回数)を増減することもできます。再試行回数を調整するには、Fusion Middleware Controlのコンソール・システムのMBeanブラウザでMaxDBNodeFailoverRetriesを変更します。MaxDBNodeFailoverRetriesのデフォルト値は5回です。Oracle BAMに構成可能なプロパティの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

5.15.16 BAMHOST1でBAM Serverを使用するためのBAM Webアプリケーションの構成

BAMHOST1でBAM Serverを使用するためのOracleBamWeb(WLS_BAM1)アプリケーションおよびOracleBamWeb(WLS_BAM2)アプリケーションを構成する手順は次のとおりです。

1. 次のURLで、Oracle Enterprise Manager Fusion Middleware Controlにアクセスします。

http://bamhost1vhn0:7001/em

2. ナビゲーション・ツリーの「BAM」を開きます。

3. 「OracleBamWeb(WLS_BAM1)」を右クリックします。

- ポップアップ・メニューの「BAM Webプロパティ」を選択します。
「BAM Webプロパティ」ページが表示されます。

- 次のプロパティを定義します。

- アプリケーションURLにWEBHOST:7777と入力します。

- サーバー名にBAMHOST1VHN1と入力します。

- MBeanブラウザを使用して、BAM Serverのリスニング・ポートを変更します。そのためには、次の手順に従ってください。

- Oracle Enterprise Manager Fusion Middleware Controlにログオンします。

- 左側のナビゲーション・ツリーでドメイン名を開きます。

- 左側のナビゲーション・ツリーで「BAM」アイテムを開きます。

- 右上の「BAM」ドロップダウン・メニューで「MBeanブラウザ」を選択します。

- 右側で「oracle.bam.web」→「サーバー」→「アプリケーション」→「構成」→「BAMWebConfig」に移動します。

- 「ServerPort」フィールドのDEFAULT値を9001に置き換えます。

4. ナビゲーション・ツリーで「OracleBamWeb(WLS_BAM2)」を選択し、同じ手順を繰り返します。

5.15.17 管理サーバーおよび管理対象サーバーWLS_BAMnのOracle HTTP Serverの構成

管理対象サーバーWLS_BAMnを含むBAM_ClusterへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

1. WEBHOST1およびWEBHOST2で、ORACLE_BASE/admin/<instance_name>/config/OHS/<component_name>/mod_wl_ohs.confファイルに次の行を追加します。

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster bamhost1vhn1:9001,bamhost2:9001
</Location>

# UMS
<Location /sdpmessaging/ >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# UMS WS
<Location /ucs/messaging/webservice >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
</Location>

# BAM Web app
<Location /OracleBAM>
SetHandler weblogic-handler
WebLogicCluster bamhost1vhn1:9001,bamhost2:9001
</Location>

# BAM Web Services
<Location /OracleBAMWS>
SetHandler weblogic-handler
WebLogicCluster bamhost1vhn1:9001,bamhost2:9001
</Location>

mod_wl_ohs.confファイルと同じディレクトリにあるhttpd.confファイルが、ロード・バランシング・ルーター・アドレスを指す次の行を含んでいることを確認します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://bam.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>

注意:

このドキュメントに記載されている値(bam.mycompany.com:443, 7777、admin.mycompany:80、you@youraddressなど)は、単なる例です。実際の環境に基づく値を入力してください。

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

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

管理コンソールでBAMサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中」と表示される場合は、サーバーの状態が「起動済」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。次のURLにアクセスできることを確認します。「WEBHOSTN」には、各Oracle HTTP Serverホストの名前(WEBHOST1、WEBHOST2など)が指定されます。

- http://WEBHOST1:7777/wsm-pm

- http://WEBHOST2:7777/wsm-pm

- http://WEBHOST1:7777/sdpmessaging/userprefs-ui

- http://WEBHOST2:7777/sdpmessaging/userprefs-ui

- http://WEBHOST1:7777/OracleBAM

- http://WEBHOST2:7777/OracleBAM

次のURLがロード・バランシング・ルーター・アドレスを使用していることも確認します。

- http://bam.mycompany.com:80/wsm-pm

- http://bam.mycompany.com:80/sdpmessaging/userprefs-ui

- http://bam.mycompany.com:80/OracleBAM

次の手順に従って、HTTP ServerからBAMクラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。

1. WLS_BAM2の実行中に、管理コンソールからWLS_BAM1を停止します。

2. 次のURLにアクセスして、適切な機能を検証します。

- http://WEBHOST1:7777/wsm-pm

- http://WEBHOST1:7777/sdpmessaging/userprefs-ui

- http://WEBHOST1:7777/OracleBAM

3. 管理コンソールから、WLS_BAM1を開始します。

4. WLS_BAM2を停止します。

5. 前述のステップ2のURLにアクセスして、適切な機能を検証します。

5.15.19 WLS_BAMサーバーのサーバー移行の構成

Oracle BAMの高可用性アーキテクチャは、シングルトン・サービスを障害から保護するためにサーバー移行を利用します。WLS_BAM1管理対象サーバーは、障害発生時にBAMHOST2で再起動できるように構成されます。このような構成では、WLS_BAM1は、Oracle WebLogic Server移行によってフェイルオーバーされる特定の浮動IPをリスニングします。WLS_BAM1管理対象サーバーのサーバー移行を構成する手順は次のとおりです。

注意:

サーバー移行が以前SOAに対して構成された場合、BAMシステムでは、同じデータ・ソースとデータベース・スキーマを使用できます。その場合、ステップ1から5は必要でないこともありますが、対応するサーバー移行/リーシング・データソースのターゲットをBAMクラスタに設定する必要があります。

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

ユーザーと表領域を作成する手順は次のとおりです。

1. leasingという表領域を作成します。たとえば、ユーザーsysdbaでSQL*Plusにログインし、次のコマンドを実行します。
例: SQL*Plusにsysdbaユーザーとしてログオンして、次のコマンドを実行します。

SQL> create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by welcome1;

SQL> grant create table to leasing;

SQL> grant create session to leasing;

SQL> alter user leasing default tablespace leasing;

SQL> alter user leasing quota unlimited on LEASING;

3. leasing.ddlスクリプトを使用してleasing表を作成します。

1. WL_HOME/server/db/oracleディレクトリにあるleasing.ddlファイルをデータベース・ノードにコピーします。

2. データベースにleasingユーザーとして接続します。

3. leasing.ddlをSQL*Plusで実行します。

SQL> @copy_location/leasing.ddl;

5.15.19.2 管理コンソールからのGridLinkデータ・ソースまたはマルチ・データ・ソースの作成

マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。

- このデータ・ソースが非XAデータ・ソースであることを確認します。

- Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。

- したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。データ・ソースは、グローバル・トランザクションのサポートを必要としません。

- これらのデータ・ソースをクラスタにターゲット指定します。

- データソースの接続プールの初期容量が0に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データ・ソース名」→「接続プール」タブをクリックし、「接続数の初期値」フィールドに0を入力します。

- ONSデーモンがデータベース・サーバーで常に実行中であることを確認します。ONSデーモンをデータベース・サーバーで起動するには、onsctlコマンド(start)を実行します。

GridLinkデータソースの作成

GridLinkデータ・ソースを作成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. 「データ・ソースの概要」ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択します。

5. 次の情報を入力します。

1. 「名前」フィールドで、データ・ソースの論理名を入力します。たとえば、gridlinkと入力します。

2. JNDIの名前を入力します。たとえば、jdbc/gridlinkと入力します。

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

6. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除します。「次」をクリックします。

7. 「個別のリスナー情報の入力」を選択して、「次へ」をクリックします。

8. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を入力します。RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(example.comなど)を含むRACサービス名を登録または追加することをお薦めします。

- ホスト名: データベースをホストするサーバーのDNS名またはIPアドレス。Oracle GridLinkサービスとインスタンス間の接続の場合、特定のマルチ・データ・ソースの各データ・ソースで同じ名前にする必要があります。

- Port: データベース・サーバーが接続リクエストをリスニングするポート。

- データベース・ユーザー名: データベース・ユーザー名。たとえば、myDataBaseと入力します。

- パスワード: パスワード。たとえば、myPassword1と入力します。

- パスワードを確認して、「次へ」をクリックします。

ヒント:

詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

コンソールにより、完全なJDBC URLが自動的に生成されます。例:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))

9. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。
Oracle WebLogicは、管理サーバーからデータベースへの接続を作成します。接続テストの結果がページの上部に表示されます。テストに失敗した場合は、構成エラーをすべて修正してテストを再試行します。

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

10. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- 「ONSホストとポート」で、ONSベースのFANイベントを受け取るためにONSデーモンが接続するリスニング・アドレスとリスニング・ポートのカンマ区切りのリストを入力します。単一クライアント・アクセス名(SCAN)アドレスを使用すると、FAN通知にアクセスできます。

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

11. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
「次へ」をクリックします。

12. 「ターゲットの選択」ページで「Dept1_Cluster1」をターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。

13. 「終了」をクリックします。「変更のアクティブ化」をクリックします。

マルチ・データ・ソースの作成

マルチ・データ・ソースを作成するには、次の手順を実行します。

1. 管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「データ・ソース」をクリックします。「JDBCデータ・ソースのサマリー」ページが表示されます。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「新規」→「マルチ・データ・ソース」をクリックします。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。

4. 「名前」として、leasingと入力します。

5. 「JNDI名」として、jdbc/leasingと入力します。

6. アルゴリズムとしてフェイルオーバー(デフォルト)を選択します。

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

8. ターゲットとして「BAM_Cluster」を選択します。

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

10. 「非XAドライバ」(デフォルト)を選択します。

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

12. 「新しいデータ・ソースの作成」をクリックします。

13. 名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、Oracle Driver (Thin) for RAC server-Instance connection Version 10,11と入力します。

注意:

leasing表のマルチ・データ・ソースを作成するときに、名前を<MultiDS>-rac0、<MultiDS>-rac1などの形式で入力します。

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

15. 「グローバル・トランザクションのサポート」の選択を解除します。

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

17. leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。

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

19. 「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。

20. データ・ソースをBAMクラスタにターゲット指定します。

21. データ・ソースを選択して、右の画面に追加します。

22. Oracle RACデータベースの2つ目のインスタンスについて「新しいデータ・ソースの作成」をクリックし、そのターゲットをBAM_Clusterに設定して、Oracle RACデータベースの2つ目のインスタンスについても同じ手順を繰り返します。

23. 2つ目のデータ・ソースをマルチ・データ・ソースに追加します。

24. 「保存」をクリックします。

25. 「変更のアクティブ化」をクリックします。

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

nodemanager.propertiesファイルは、WL_HOME/server/binディレクトリにあります。

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

- Interface=eth0
このプロパティは、浮動IPのインタフェース名(たとえば、Linuxではeth0)を指定します。

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

注意:

Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: Interface="Local Area Connection"

- NetMask
このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。

- UseMACBroadcast
このプロパティでは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、すなわち、arpingコマンドで-bフラグを使用するかどうかを指定します。

この構成をBAMHOST1とBAMHOST2の2つのノードで実行します。これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。適用されていないと、移行中に問題が発生する可能性があります。出力は次のように表示されます。

...
StateCheckInterval=500
Interface=eth0 (Linux) or Interface="Local Area Connection" (Windows)
NetMask=255.255.255.0
...

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

wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。

注意:

Windowsでは、このスクリプトの名前はwlsifconfig.cmdであり、管理者権限を持つユーザーが実行できます。

1. 表5-26に一覧表示されているファイルがPATH環境変数に含まれていることを確認します。

表5-26 PATH環境変数に含める必要のあるファイル

ファイル

格納されているディレクトリ

wlsifconfig.sh

MW_HOME/user_projects/domains/bamdomain/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

WL_HOME//common

2. wlsifconfig.shスクリプトに対するsudo構成権限の付与

- パスワード・プロンプトを使用しないで機能するsudoを構成します。

- セキュリティ上の理由から、sudoをwlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する場合は、次の手順を実行します。

- WebLogicユーザー(oracle)に、パスワードなしのsudo権限を付与し、/sbin/ifconfig and /sbin/arpingバイナリの実行権限を付与します。

- スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。次の例は、oracleのsudo実行権限をifconfigとarpingにも付与する/etc/sudoers内のエントリを示しています。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

注意:

この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。

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

クラスタ移行を構成することにより、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。クラスタ内のクラスタ移行を構成する手順は、次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。

3. 移行を構成するクラスタ(BAM_Cluster)を、表の「名前」列でクリックします。

4. 「移行」タブをクリックします。「チェンジ・センター」で、「ロックして編集」をクリックします。

5. 「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「BAMHOST1」と「BAMHOST2」を選択します。

6. 自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。

7. 「保存」をクリックします。

8. サーバー移行の候補マシンを設定します。
このタスクはWLS_BAM1に対して実行する必要があります。

1. 管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。

2. 移行を構成するサーバーを選択します。「移行」タブをクリックします。

3. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。WLS_BAM1には「BAMHOST2」を選択します。

4. 「サーバーの自動移行を有効化」を選択します。
これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

5. 「保存」をクリックして、変更をアクティブ化します。

6. 管理サーバーとWLS_BAM1サーバーを再起動します。

5.15.19.6 サーバー移行のテスト

サーバー移行が適切に機能していることを確認する手順は次のとおりです。

BAMHOST1から次の処理を実行します。

1. 次のコマンドを使用して、管理対象サーバーWLS_BAM1を強制停止します。

BAMHOST1> kill -9 <pid>

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

BAMHOST1> ps -ef | grep WLS_BAM1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了します。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_BAM1のpidを確認します。

MW_HOME\jrockit_160_<バージョン>\bin\jps -l -v

2. ノード・マネージャ・コンソールに、WLS_BAM1の浮動IPが無効になっていることを示すメッセージが表示されます。

3. ノード・マネージャがWLS_BAM1の2回目の再起動を試行するのを待ちます。
ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。
サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

BAMHOST2から次の処理を実行します。

1. ローカルのノード・マネージャのコンソールを確認します。
ノード1で最後にWLS_BAM1の再起動が試行されてから30秒経過した後、BAMHOST2のノード・マネージャによって、WLS_BAM1の浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。

2. BAMHOST1VHN1/OracleBAM and WEBHOST1:7777/OracleBAMを使用して、Oracle BAMコンソールにアクセスします。

管理コンソールからの検証

管理コンソールで移行を検証する手順は、次のとおりです。

1. 管理コンソールにログインします。左側のコンソールで、「ドメイン」をクリックします。

2. 「監視」タブ→「移行」タブをクリックします。

「移行ステータス」表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後に、そのサーバーを元のノード/マシンにフェイルバックする場合は、Oracle WebLogic管理コンソールを使用して、管理対象サーバーを停止してから再起動します。該当するノード・マネージャによって、その管理対象サーバーは最初に割り当てられていたマシン上で起動されます。

5.15.20 BAMシステムに接続するクライアントの構成

BAMアダプタ(RMI)を使用してBAMサーバーにアクセスする場合、接続にはBAMサーバーの仮想ホスト名(BAMHOST1VNH1)を使用する必要があります。SOAPリクエストはHTTPを介して着信するため、この状況でBAMアダプタを使用する場合、ロード・バランシング・ルーター・アドレスを使用する必要があります。

6 Oracle ADFおよびWebCenterポータル・アプリケーションの高可用性の構成

この章では、Oracle Application Development Framework(Oracle ADF)とOracle WebCenterポータルの高可用性の概要と構成手順について説明します。

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

- 第6.1項「Oracle ADFと高可用性の概要」

- 第6.2項「Oracle ADFの高可用性デプロイメントの構成」

- 第6.3項「WebCenterポータルと高可用性の概要」

- 第6.4項「WebCenterポータルの高可用性の構成」

- 第6.5項「WebCenterポータル・アプリケーションの高可用性の構成」

6.1 Oracle ADFと高可用性の概要

Oracle ADFは、Java Platform, Enterprise Edition(Java EE)の標準およびオープンソース・テクノロジに基づいて作成されたエンドツーエンド・アプリケーション・フレームワークで、サービス指向アプリケーションの実装を簡素化および迅速化します。Oracle ADFは、Web、無線、デスクトップ、またはWebサービスのインタフェースを使用してデータの検索、表示、作成、変更および検証を行うアプリケーションを作成するエンタープライズ開発者に適しています。Oracle JDeveloper 11gとOracle ADFを連携させると、ドラッグ・アンド・ドロップでのデータ・バインディング、視覚的なUI設計およびチーム開発の各機能を組み込んで、設計からデプロイまでの完全な開発ライフサイクルに対応する環境を作成できます。

- 第6.1.1項「Oracle ADFの理解」

- 第6.1.2項「Oracle ADFの高可用性に関する考慮事項」

- 第6.1.3項「高可用性のためのOracle ADFの構成」

- 第6.1.4項「Oracle ADFの高可用性のトラブルシューティング」

6.1.1 Oracle ADFの理解

コミュニティのベスト・プラクティスに従い、Fusion Webテクノロジ・スタックを使用して作成したアプリケーションでは、次のレイヤーによってサポートされているモデル・ビュー・コントローラ(MVC: Model-View-Controller)アーキテクチャに準拠することで、ビジネス・ロジック、ページ・ナビゲーションおよびユーザー・インタフェースが明確に分離されます。

図6-1に示すように、MVCアーキテクチャでは次のような構成になります。

- モデル・レイヤーは、現行ページに関連するデータ値を表します。

- ビュー・レイヤーには、その関連データの表示や変更に使用するUIページが保持されます。

- コントローラ・レイヤーは、ユーザー入力を処理し、ページ・ナビゲーションを決定します。

- ビジネス・サービス・レイヤーは、データ・アクセスを処理し、ビジネス・ロジックをカプセル化します。

図6-1 Oracle ADFアーキテクチャの概要

「図6-1 Oracle ADFアーキテクチャの概要」の説明

6.1.1.1 Oracle ADFコンポーネント

フレームワークにおけるコア・モジュールは、Oracle ADFモデルです。Oracle ADFモデル・レイヤーでは、統一されたアプローチを使用して、任意のユーザー・インタフェースとビジネス・サービスをコードを記述することなくバインドすることが可能です。

Fusion Webアプリケーション・テクノロジ・スタックを構成する他のモジュールは次のとおりです。

- Oracle ADFビジネス・コンポーネントは、ビジネス・サービスの構築を簡素化します。

- Oracle ADF Facesは、JavaServer Faces(JSF)で構築されたWebアプリケーションに対し、AJAX対応のUIコンポーネントのリッチ・ライブラリを提供します。

- Oracle ADF Controllerは、JSFをOracle ADFモデルに統合します。ADF Controllerは、追加機能を提供することにより標準のJSFコントローラを拡張します。この追加機能には、JSFページ間だけでなく他のアクティビティ(メソッドのコールや他のタスク・フローなど)間の制御も渡す再使用可能なタスク・フローなどがあります。

図6-2は、Fusion Webアプリケーション・アーキテクチャにおける各Oracle ADFモジュールの適合を示しています。

図6-2 シンプルなOracle ADFアーキテクチャ

「図6-2 シンプルなOracle ADFアーキテクチャ」の説明

6.1.1.1.1 ADFビジネス・コンポーネント

ADFビジネス・コンポーネントは、ビルトイン・アプリケーション・オブジェクトであり、高性能で機能の豊富なデータベース中心のサービスの提供と維持を迅速化します。サービス指向のJava EEアプリケーションを作成するとき、開発者はコア・ビジネス・ロジックを1つ以上のビジネス・サービスとして実装します。これらのバックエンド・サービスは、適切なビジネス・ルールを施行し、かつ必要に応じてビジネス・データの問合せ、挿入、更新および削除を行う手段をクライアントに提供します。ADFビジネス・コンポーネントは、Java EEの設計パターンとベスト・プラクティスを即座に実装できるようにします。

Oracle ADFビジネス・コンポーネントは、データベース中心のビジネス・サービスの作成を簡略化するために次の主要なコンポーネントを提供しています。

- エンティティ・オブジェクト
エンティティ・オブジェクトは、データベース表内の1行を表し、すべてのデータ操作言語(DML)操作を処理することでデータ変更を簡略化します。また、ビジネス・ロジックをカプセル化し、ビジネス・ルールが一貫して適用されることを保証します。開発者は、エンティティ・オブジェクトを他のエンティティ・オブジェクトと関連付け、基盤となるデータベース・スキーマの関係を反映することで、複数のアプリケーションで再使用できるビジネス・ドメイン・オブジェクトのレイヤーを作成します。

- ビュー・オブジェクト
ビュー・オブジェクトはSQL問合せを表し、その結果の操作を簡略化します。開発者は、SQL言語を使用し、ユーザー・インタフェースで表されるエンド・ユーザーのタスクが必要とする形に、データを結合、計画、フィルタ、ソートおよび集約します。これには、ビュー・オブジェクトを他のエンティティ・オブジェクトにリンクし、複雑度に関係なくマスター/ディテール階層を作成する機能が含まれます。エンド・ユーザーがユーザー・インタフェースでデータを変更すると、ビュー・オブジェクトはエンティティ・オブジェクトと連携し、変更内容が一貫して検証され、保存されます。

- アプリケーション・モジュール
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。これによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。

Oracle ADFビジネス・コンポーネントの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

6.1.1.1.2 ADF Modelレイヤー

モデル・レイヤーでは、Oracle ADFモデルによって、ビジネス・サービスの実装テクノロジを抽象化するデータ・コントロールが実装されます。標準のメタデータ・インタフェースにより、サービスの操作やデータ・コレクション、関連するプロパティ、メソッド、タイプに関する情報などが記述されます。Oracle JDeveloperでは、そのような情報はアイコンとして開発者に表示され、開発者はそれらのアイコンをページ上にドラッグ・アンド・ドロップできます。開発者がサービス表現をページ上にドラッグすると、Oracle JDeveloperによって、そのページからサービスへのバインディングが自動的に作成されます。実行時にADFモデル・レイヤーによって、アプリケーションのデータ・コントロールおよびデータ・バインディングを記述した情報が該当するXMLファイルから読み取られ、ユーザー・インタフェースとアプリケーションのビジネス・サービス間の双方向接続が実装されます。

Oracle ADFは、最も一般的なビジネス・サービス・テクノロジに対し、すぐに実装可能なデータ・コントロールを提供します。ユーザー・インタフェースの構築にOracle JDeveloperとOracle ADFを併用すると、ドラッグ・アンド・ドロップを使用した宣言的なデータ・バインディングが可能になります。ADFビジネス・コンポーネント・アプリケーション・モジュールのサポートとともに、ADFモデルは次のサービス・テクノロジもサポートしています。

- Enterprise JavaBeans(EJB)のセッションBeanとJPAエンティティ

- JavaBeans

- Webサービス

- XML

- CSVファイル

Oracle ADFモデルの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

6.1.1.1.3 ADF Controller

Webアプリケーションのページ・フロー処理が主な課題となるコントローラ・レイヤーでは、ADF Controllerは、拡張されたナビゲーションおよび状態管理モデルをJSFに追加する形で提供しています。JDeveloperは、ページ、マネージドBean上のメソッド、宣言的なcase文、他のタスク・フローへのコールなど、様々なタイプのアクティビティの間でアプリケーション制御を管理できるタスク・フローの宣言的な作成をサポートします。

Oracle ADF Controllerの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

6.1.1.1.4 ADF Faces Rich Client

ADF Faces Rich Client(ADF Faces)とは、AJAX機能が組み込まれた一連の標準JSFコンポーネントです。AJAXは、非同期JavaScript、動的HTML(DHTML)、XMLおよびXmlHttpRequest通信チャネルを組み合せたものです。この組合せを使用すると、ページを全面的に再レンダリングしないでサーバーにリクエストを送信できます。AJAXでは、リッチ・クライアントのようなアプリケーションが標準のインターネット・テクノロジを使用できますが、JSFにはサーバー側のコントロールが用意されており、これにより、通常のAJAXアプリケーションで頻繁に見られる、大量のJavaScriptへの依存度が下がります。

ADF Facesには、100を超えるリッチ・コンポーネントが含まれています。これには、階層形式のデータ表、ツリー・メニュー、ページ内ダイアログ、アコーディオン、デバイダ、ソート可能な表などがあります。また、ADF Facesでは、動的チャート、グラフ、ゲージ、および基礎となるデータをリアルタイムで表示するその他のグラフィックをレンダリングできるFlashおよびSVG対応のコンポーネントである、ADFデータ視覚化のコンポーネントも提供します。各コンポーネントはカスタマイズやスキニングに加えて、国際化とアクセシビリティの機能もサポートしています。

これらのフロントエンド機能を実現するために、ADF Facesコンポーネントではレンダリング・キットが使用されます。このレンダリング・キットは、コンポーネントの表示を処理するだけでない、リッチ機能に必要なJavaScriptオブジェクトも提供します。これらは組込みでサポートされているため、開発者は、フロントエンドとバックエンドの個々のテクノロジについて豊富な知識がない場合でも、リッチ・アプリケーションの構築は可能です。

各コンポーネントのアーキテクチャおよび詳細情報など、ADF Facesの詳細は、Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイドを参照してください。

6.1.1.2 Oracle ADFの単一ノード・アーキテクチャ

Oracle ADFランタイムをOracle WebLogic Serverにインストールするには、Oracle JDeveloperインストーラまたはOracle Fusion Middleware Application Developerインストーラを使用します。Application Developerインストーラでは、オプションでFusion Middleware Controlをインストールしてドメイン内のすべての管理対象サーバーに対するWebベースの管理サポートを提供することもできます。Oracle JDeveloperインストーラではFusion Middleware Controlはインストールされません。『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「デプロイメント」を参照してください。

Application Developerインストーラを使用してOracle ADFランタイムをインストールすると、Middlewareホームの下にOracle Application Developerホーム・ディレクトリ(デフォルトではOracle_APPDEV1)が作成されます。ドメイン構成ウィザードを使用し、JRFドメイン・テンプレートに基づいてApplication Developerドメイン(base_domain)を作成すると、サーバーのトポロジを構成できるようになります。通常の設定では、ドメインには、WLS管理コンソールとFusion Middleware Controlを含む管理サーバーが含まれています。通常は、ユーザー向けのカスタムFusion Webアプリケーションのほかに、Oracle ADFランタイムのライブラリ(Javaの必須ファイルの一部)が管理対象サーバーにデプロイされます。カスタマイズ機能およびパーソナライズ機能を提供するために、オプションのMDSリポジトリをインストールして個別に構成できます。図6-3は、Oracle ADFの基本的な単一ノード・アーキテクチャを示しています。

図6-3 Oracle ADFの基本的な単一ノード・アーキテクチャ

「図6-3 Oracle ADFの基本的な単一ノード・アーキテクチャ」の説明

ドメインとサーバーの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

6.1.1.3 Oracle ADFの外部依存性

Fusion WebアプリケーションでOracle Metadata Services (MDS)を使用したカスタマイズを行う場合は、アプリケーションをデプロイする前に、MDSリポジトリをOracle WebLogic Serverドメインに登録することをお薦めします。MDSの登録の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

次に、アプリケーションをデプロイすると、JDeveloperでは、ターゲット・メタデータ・リポジトリまたは共有メタデータ・リポジトリを選択するように求められます。ここでは、Oracle WebLogic管理サーバーに登録されているメタデータ・リポジトリのリストから選択できます。

メタデータ・リポジトリの選択が求められるようにするには、アプリケーションのadf-config.xmlファイルのmds-configセクションでcust-config要素を定義する必要があります。この要素は、順序付けされ、名前が付けられたカスタマイズ・クラスのリストを指定します。カスタマイズ・クラスとは、ベース定義メタデータに適用するカスタマイズを定義するためにMDSが使用するインタフェースです。JDeveloperでは、adf-config.xmlファイル用の概要エディタを使用してcust-config要素を定義できます。

MDS用adf-config.xmlファイルの構成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「MDSを使用したカスタマイズ」を参照してください。

MDSのアーキテクチャ、メタデータ・リポジトリおよびアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middleware管理者ガイド『を参照してください。

6.1.1.4 Oracle ADFのログ・ファイル

Fusion Webアプリケーションで実行された操作は、アプリケーションが稼働しているWebLogic管理対象サーバーの次のログに直接記録されます。

DOMAIN_HOME/servers/server_name/logs/server_name-diagnostic.log

別のWebLogic管理対象サーバーのログ・ファイルも、Oracle WebLogic Server管理コンソールで使用できます。ログを確認するには、Oracle WebLogic Server管理コンソールhttp://<admin_server_host>:<port>/consoleにアクセスして、「診断-ログ・ファイル」をクリックします。

このログの粒度とロギング・プロパティは、Oracle Enterprise Manager Fusion Middleware Control(Fusion Middleware Control)を使用して変更できます。Fusion Middleware ControlはWebブラウザベースのグラフィカル・ユーザー・インタフェースで、ファームの監視および管理に使用できます。Oracle ADFに関する高可用性警告診断メッセージを受信するには、第6.1.4.3項「Oracle ADFのレプリケーションおよびフェイルオーバーに関する問題のトラブルシューティング」に説明されているように、レベルをFINEに設定してください。

Fusion Webアプリケーションに指定できる診断レベルの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「テストとデバッグ」を参照してください。

Fusion Middleware Controlを使用したWebLogic管理対象サーバーとOracle ADFのログ設定の変更の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

6.1.2 Oracle ADFの高可用性に関する考慮事項

Oracle ADFテクノロジ・スタック上に構築されるFusion Webアプリケーションは、Java EEアプリケーション(およびJ2EEアプリケーション)です。この項の項目は次のとおりです。

- 第6.1.2.1項「Oracle ADFのスコープとセッションの状態」

- 第6.1.2.2項「Oracle ADFのフェイルオーバーおよび予想される動作」

- 第6.1.2.3項「Oracle ADFのアクティブ・データ・サービス」

- 第6.1.2.4項「Oracle RAC用ADFアプリケーション・モジュールの構成」

6.1.2.1 Oracle ADFのスコープとセッションの状態

バインディング・コンテナやマネージドBeanなどのADFオブジェクトは、実行時にインスタンス化されます。これらの各オブジェクトには、そのスコープ属性によって設定される存続期間が定義されています。

Fusion Webアプリケーションには次の6種類のスコープがあります。

- アプリケーション・スコープ: このオブジェクトは、アプリケーションの継続期間中、利用できます。

- セッション・スコープ: このオブジェクトは、セッションの継続期間中、利用できます。

- ページ・フロー・スコープ: このオブジェクトは、バインド・タスク・フローの継続期間中、利用できます。

- リクエスト・スコープ: このオブジェクトは、HTTPリクエストが発生してからレスポンスがクライアントに返送されるまでの間、利用できます。

- バッキングBeanスコープ: ページ・フラグメントおよび宣言コンポーネントのみのマネージドBeanに使用されます。このオブジェクトは、HTTPリクエストが発生してからレスポンスがクライアントに返送されるまでの間、利用できます。

- ビュー・スコープ: このオブジェクトは、現在のビュー・アクティビティのビューIDが変更されるまで利用できます。このスコープは、所定のページの値を保持するために使用できます。ただし、1つのページから次のページに必要な値を格納するために使用できるリクエスト・スコープとは異なり、ビュー・スコープに格納されたものはビューIDの変更とともに失われます。

Fusion Webアプリケーションをクラスタ環境で実行する場合は、アプリケーションの状態の一部がシリアル化され、各リクエストの終わりに別のサーバーまたはデータ・ストアにコピーされるため、クラスタ内の他のサーバーがこの状態を利用できるようになります。

クラスタ環境で実行されるようにアプリケーションを設計している場合、次のようにする必要があります。

- 1つのリクエストより存続期間が長いマネージドBeanがすべてシリアライズ可能である(つまり、java.io.Serializableインタフェースを実装している)ことを確認します。具体的には、セッション・スコープ、ページ・フロー・スコープおよびビュー・スコープに格納されているBeanは、シリアライズ可能である必要があります。

- ADFスコープ(ビュー・スコープおよびページ・フロー・スコープ)に格納されているマネージドBeanの変更をOracle ADFが認識していることを確認し、ADFメモリー・スコープに対する変更の追跡を有効にします。

ビュー・スコープまたはページ・フロー・スコープのいずれかで、マネージドBean内の値を変更した場合には、アプリケーションがOracle ADFに通知して、Beanの新しい値がレプリケートできるようにする必要があります。

例6-1では、ビュー・スコープ内のオブジェクトの属性が変更されます。

例6-1 viewScope内のオブジェクトを変更するコード

Map<String, Object> viewScope =
AdfFacesContext.getCurrentInstance().getViewScope();
MyObject obj = (MyObject)viewScope.get("myObjectName");
Obj.setFoo("newValue");

コードを追加しないかぎり、Oracle ADFではこの変更を認識しないため、新しい値をクラスタ内でレプリケートする必要があることがわかりません。変更およびレプリケーションの必要性をOracle ADFに通知するには、例6-2に示すように、markScopeDirty()メソッドを使用します。markScopeDirty()メソッドは、viewScopeおよびpageFlowScopeのみをパラメータとして受け入れます。

例6-2 オブジェクトの変更をOracle ADFに通知するための追加のコード

controllerContext ctx = ControllerContext.getInstance();
ctx.markScopeDirty(viewScope);

このコードは、ADFスコープのいずれかにある既存のオブジェクトを変更するリクエストに対して必要になります。スコープ自体がスコープのput()メソッドremove()またはclear()メソッドによって変更された場合は、Oracle ADFに通知する必要はありません。

ADF ControllerがADFメモリー・スコープに対する変更を追跡し、サーバー・クラスタ内のページ・フロー・スコープおよびビュー・スコープをレプリケートできるようにするには、第6.1.3.3項「adf-config.xmlの構成」に説明されているように、adf-config.xmlファイル内の<adf-scope-ha-support>パラメータを有効にします。

ADFオブジェクト・スコープの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「Fusionのページ・ライフサイクル」を参照してください。

6.1.2.2 Oracle ADFのフェイルオーバーおよび予想される動作

Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内で他に利用可能なメンバーがリクエストを処理できます。

セッションのフェイルオーバー要件

Fusion Webアプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。

- アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できます。

- ステートフル・アプリケーションに対し、第6.1.3項「高可用性のためのOracle ADFの構成」の説明に従って、状態のレプリケーションが正しく構成されています。

- Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されています。

- ハードウェア・ロード・バランサを使用する場合は、ロード・バランサが:

- 利用可能なインスタンスすべてに対してトラフィックをルーティングしています

- 利用できないインスタンスをマークするように、状態モニターで正しく構成されています

- セッションの状態の永続性をサポートするように構成されています

アプリケーションのフェイルオーバーで予想される動作

環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気がつきません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。

1. ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。

2. ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。

3. ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。

4. ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。

5. インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。

6. インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。

6.1.2.3 Oracle ADFのアクティブ・データ・サービス

Fusionテクノロジ・スタックにはアクティブ・データ・サービス(ADS)が含まれており、このADSによって、ADFモデル・レイヤーを使用してADF Facesコンポーネントをアクティブ・データ・ソースにバインドできます。JDeveloperでは、JSFページ内で個々のコンポーネントを構成し、アクティブ・データを表示します。アクティブ・データを使用するようにコンポーネントを構成すると、データ・ソースによって変更イベントが発生するたびにデータがクライアントにプッシュされます。データはサーバーからクライアントにプッシュされ、ブラウザで表示されます。

アクティブ・データを表示するように構成されているページに対してフェイルオーバーをサポートするには、ADFビジネス・コンポーネント・アプリケーション・モジュールのフェイルオーバーを有効にし、ADF ControllerがADFメモリー・スコープへの変更を追跡できるようにする必要があります。これらのADF設定を構成すると、フェイルオーバーの発生時にADFサーバーがフェイルオーバーを検出し、アクティブ・データを表示するように構成されているすべてのページに対し、ページをリフレッシュするように要求すると、その後ADSが再起動し、データがクライアントにプッシュされます。

Fusion Webアプリケーションのフェイルオーバーを有効にする方法の詳細は、第6.1.3項「高可用性のためのOracle ADFの構成」を参照してください。

Oracle ADF Facesコンポーネントでのアクティブ・データ・サービスの使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「ADS」を参照してください。

6.1.2.4 Oracle RAC用ADFアプリケーション・モジュールの構成

冗長なデータベースやバックエンドとしてのOracle Real Application Clusters(Oracle RAC)など、可用性の高いデータベース・システムにアクセスするようにADFアプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、GridLinkデータ・ソースまたはマルチ・データ・ソースを使用する必要があります。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースまたはGridLinkデータ・ソースのネーミング規則は、非マルチ・データ・ソースまたはGridLinkデータ・ソースのネーミング規則と同じになります。このネーミング規則によって、正しいデータ・ソースが実行時に使用されるようになります。高可用性アプリケーションに対するGridLinkデータ・ソースの構成の詳細は、第4.1.4項「Oracle RACでのGridLinkデータ・ソースの構成」を参照してください。マルチ・データ・ソースの詳細は、第4.1.5項「Oracle RACでのマルチ・データ・ソースの構成」を参照してください。

6.1.3 高可用性のためのOracle ADFの構成

クラスタ環境内のWebアプリケーションに対して自動的なレプリケーションとフェイルオーバーをサポートするために、Oracle WebLogic Serverは、クラスタ間でHTTPセッションの状態をレプリケートするメカニズムをサポートしています。Fusion Webアプリケーションの状態をクラスタ内のどのサーバーからでもリストアできるようにOracle ADFを構成できます。

6.1.3.1 アプリケーション・モジュールの構成

アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。これによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。アプリケーション・モジュールは、そのトランザクション状態を 非アクティブ化する、またはスナップショットとしてデータベースに格納することをサポートしています。また、これらの保存済スナップショットのいずれかからトランザクション状態をアクティブ化する逆の操作もサポートしています。

アプリケーション・モジュールの状態管理の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のFusion Webアプリケーションの状態管理の概要に関する項を参照してください。

ADFビジネス・コンポーネントのフェイルオーバーのサポートを有効にするには、jbo.dofailoverパラメータをtrueに設定し、アプリケーション・モジュールの状態が解放時に保存されるようにします。これによって、Oracle ADFは、前のチェックインで保存されたスナップショットからアプリケーション・モジュールの状態をリストアできるようになります。一方、フェイルオーバー機能がデフォルトにより無効のままになっている場合は、アプリケーションが後続のユーザー・セッションで再利用されたときと、アプリケーション・モジュール・プールが未使用のアプリケーション・モジュールを見つけられないときにのみ、アプリケーション・モジュールの状態が保存されます。

アプリケーション・モジュールの構成でこのパラメータを設定するには、「ビジネス・コンポーネント構成の編集」ダイアログの「プーリングおよびスケーラビリティ」タブを使用します。

高可用性のためのアプリケーション・モジュールを構成する手順は次のとおりです。

1. JDeveloperを起動してアプリケーションを開きます。

2. アプリケーション・ナビゲータで、データ・モデルを含むプロジェクトを展開し、アプリケーション・モジュールを探します。

3. アプリケーション・モジュールを右クリックし、「構成」を選択します。

4. 「編集」をクリックします。

5. 「プーリングおよびスケーラビリティ」タブをクリックします。

6. 「管理された解放時にトランザクションの状態をフェイルオーバー」チェック・ボックスを選択します。

7. 「OK」をクリックして「ビジネス・コンポーネント構成の編集」ダイアログを閉じます。

8. 「OK」をクリックして「構成の管理」ダイアログを閉じます。

Oracle ADFの状態管理機能とその使用方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「アプリケーションの状態管理」を参照してください。

6.1.3.2 weblogic.xmlの構成

HTTPセッションの状態のレプリケートをサポートできるようにするには、Oracle WebLogic Server weblogic.xmlファイルのpersistent-store-type要素に値を割り当てる必要があります。replicated_if_clusteredの値により、有効な永続ストアのタイプがレプリケートされ、このサーバーの属するサーバーのクラスタに対して設定された値に従って、クラスタ環境のセッションが格納されるようになります。

高可用性を実現するためにweblogic.xmlファイルを構成する手順は次のとおりです。

1. JDeveloperを起動してアプリケーションを開きます。

2. アプリケーション・ナビゲータで、Webアプリケーションを含むプロジェクトを展開し、WEB-INFフォルダを展開します。

3. weblogic.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。

4. ファイル内で、persistent-store-typeの定義をsession-descriptor要素に追加します。

<weblogic-web-app>
<session-descriptor>
<persistent-store-type>
replicated_if_clustered
</persistent-store-type>
</session-descriptor>
</weblogic-web-app>

6.1.3.3 adf-config.xmlの構成

クラスタ環境で実行するアプリケーションを設計している場合は、ADFスコープ(ビュー・スコープおよびページ・フロー・スコープ)に格納されているマネージドBeanの変更をOracle ADFが認識していることを確認する必要があります。

ビュー・スコープまたはページ・フロー・スコープのいずれかで、マネージドBean内の値が変更された場合には、アプリケーションがOracle ADFに通知して、Beanの新しい値がレプリケートできるようにする必要があります。

ADF ControllerがADFメモリー・スコープに対する変更を追跡し、サーバー・クラスタ内のページ・フロー・スコープおよびビュー・スコープをレプリケートできるようにするには、アプリケーションのadf-config.xmlファイル内のADF Controllerパラメータ<adf-scope-ha-support>をtrueに設定する必要があります。たとえば、アプリケーションにtrueを設定した場合、そのアプリケーションがリクエスト中にページ・フロー・スコープでBeanの追加または削除を行うと、変更がクラスタ内で自動的にレプリケートされます。

adf-config.xmlは、すべてのADFコンポーネントの中核となる構成ファイルです。このファイルには、ADF ControllerなどのADFコンポーネントの実行時の動作を構成するためのセクションが含まれています。

注意:

アプリケーションでMDSを使用しており、フェイルオーバーをサポートするOracle Databaseを使用する場合は、フェイルオーバー時におけるMDSの再試行を有効化しておくことをお薦めします。これを行うには、次のretry-connectionエントリをadf-config.xmlのMDS構成セクションに追加します。

<persistence-config>
<metadata-namespaces>...
<metadata-store-usages>...
<external-change-detection enabled="false" polling-interval-secs="30"/>
<read-only-mode enabled="true"/>
<retry-connection enabled="true"/>
</persistence-config>

高可用性を実現するためにadf-config.xmlファイルを構成する手順は次のとおりです。

1. JDeveloperを起動してアプリケーションを開きます。

2. アプリケーション・ナビゲータで、「アプリケーション・リソース」を展開します。

3. 「ディスクリプタ」を選択し、「ADF META-INF」ノードを選択します。

4. adf-config.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。

5. このファイルに次の行を追加します。

<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
<adf-scope-ha-support>true</adf-scope-ha-support>
</adf-controller-config>

adf-config.xmlファイルを使用したADFの構成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の「複雑なタスク・フローの作成」を参照してください。

6.1.3.4 org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONの構成

高可用性環境で実行する場合、org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONパラメータをtrueに設定しないでください。このコンテキスト・パラメータをtrueに設定すると、フェイルオーバーの発生後にエラーを引き起こす可能性があります。

6.1.4 Oracle ADFの高可用性のトラブルシューティング

この項では、Oracle ADFで発生する可能性のある問題のトラブルシューティング手順について説明します。

6.1.4.1 Oracle ADFの開発に関する問題のトラブルシューティング

Fusion WebアプリケーションをOracle JDeveloperで開発する場合は、この統合開発環境によって、高可用性に関する問題を検出するためのサポートが提供されます。JDeveloperが発する警告は監査フレームワークによって生成され、JDeveloperのソース・エディタに表示するようにトリガーされます。エディタに表示される警告は、高可用性アプリケーションの監査ルールに基づきます。

JDeveloperがデフォルトにより有効にする高可用性監査ルールは次のとおりです。

- 「ADF Controller構成 - ADFスコープの高可用性が有効になっていません」は、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されていないことを警告します。この監査ルールは、<adf-controller-config>要素がADFアプリケーションレベルの構成ファイル(adf-config.xml)に存在する場合にのみ適用されます。

- 「ADFページ・フロー - スコープ・マップのBeanが変更されました」は、コードがBeanでsetterメソッドを呼び出す際、続いてControllerContext.markScopeDirty()メソッドを呼び出さなかったことを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。

- 「ADFページ・フロー - EL Beanが変更されました」は、BeanをミューテーションするEL式をコードが評価する際、続いてControllerContext.markScopeDirty()メソッドを呼び出さなかったことを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。

- 「ADFページ・フロー - マネージドBeanクラスはシリアライズ不可」は、マネージドBeanのviewScope、pageFlowScopeまたはsessionScopeに、シリアライズ不可のクラスが定義されていることを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。

高可用性監査ルール設定は、JDeveloperの「設定」ダイアログを使用して変更できます。JDeveloperのツールバーで「ツール - 設定」を選択し、「監査 - プロファイル」の下にある「ADF Controller構成」または「ADFページ・フロー」を展開して、目的の監査ルールを選択します。

JDeveloperのツールバーで「ビルド - 監査 project.jpr」を選択して監査をトリガーすることもできます。

6.1.4.2 Oracle ADFのデプロイメントに関する問題のトラブルシューティング

Fusion Webアプリケーションは、管理対象サーバーが最初に起動したときにデプロイされます。最初にOracle WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメントがすべて成功したことを確認します。

左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。

アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME/servers/server_name/logsディレクトリに格納されています。一般的な問題には、次のようなものがあります。

- データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。

- 適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。

6.1.4.3 Oracle ADFのレプリケーションおよびフェイルオーバーに関する問題のトラブルシューティング

フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります:

- ウィンドウが閉じたか、または状態がリセットされた可能性がある。

- 画面のリセットが必要になった可能性がある。

- アプリケーションがログオン画面にリダイレクトしている可能性がある。

状態のレプリケーションに関する問題の診断およびトラブルシューティングを行う手順は、次のとおりです。

1. これがレプリケーションに関する既知の問題でないことを確認します。
予想される動作については、第6.1.2.2項「Oracle ADFのフェイルオーバーおよび予想される動作」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。

2. ロード・バランサの設定を確認します。
レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverのハードウェア・ロード・バランサの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

3. クラスタのステータスを確認します。
クラスタのコンテキスト内でレプリケーションが発生します。フェイルオーバーが成功するには、クラスタの正常なメンバーが、ほかに少なくとも1つ使用可能である必要があります。クラスタのステータスは、次の2種類の方法のどちらかで確認できます。

- Oracle WebLogic Server管理コンソールを使用してクラスタのステータスを確認します。左側のペインで「サーバー」をクリックします。クラスタ内のすべてのサーバーの状態を確認します。

- weblogic.Adminユーティリティを使用してクラスタのステータスを確認します。weblogic.Adminコマンドは、特定のクラスタ内のすべてのサーバーの状態を問い合せるときに使用できます。例:

$ java weblogic.Admin -url Adminhost:7001 -username <username> -password
<password>  CLUSTERSTATE -clustername Spaces_Cluster

次のようなメッセージが返されます。

There are 2 server(s) in cluster: Spaces_Cluster
The alive servers and their respective states are listed below:
Application Server---RUNNING
Managed Server---RUNNING

4. クラスタ通信を確認します。
クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。

- ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。
個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。

- マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTestを実行して、マルチキャストが正しく構成されていることを確認します。例:

$ java utils.MulticastTest -H

5. Oracle WebLogic Serverアプリケーションの構成を確認します。
Oracle WebLogic Serverは、デフォルトではフェイルオーバーするように構成されていません。メモリー内のレプリケーションは、weblogic.xmlファイルに次の適切な設定が含まれている場合にのみ行われます。

<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

replicatedのpersistent-store-typeも受け入れられます。この設定は、第6.1.3.2項「weblogic.xmlの構成」で説明されているように、JDeveloperで行うことができます。

6. Oracle ADFビジネス・コンポーネントの構成を確認します。
Oracle ADFは、デフォルトではフェイルオーバーするように構成されていません。フェイルオーバーは、ADFビジネス・コンポーネントの構成ファイル(bc4j.xcfg)に次の適切な設定が含まれている場合にのみサポートされます。

<AppModuleConfig ...
<AM-Pooling jbo.dofailover="true"/>
</AppModuleConfig>

この設定は、第6.1.3.1項「アプリケーション・モジュールの構成」で説明されているように、JDeveloperの「ビジネス・コンポーネント構成の編集」ダイアログで行います。

7. Oracle WebLogic Serverの接続プール・パラメータを確認します。
weblogic-application.xmlデプロイメント・ディスクリプタの要素<connection-check-params> pool-paramsにあるパラメータinactive-connection-timeout-secondsに適切な値を設定します。

アプリケーション・モジュール状態の非アクティブ化を有効にしている場合は、接続を強制的にプールに復帰させるようにOracle WebLogic Serverを構成していると障害が発生することがあります。この障害によって、例外Connection has already been closedが生成されます。この例外は、サーバー・ログに保存されます。ユーザー・インタフェースには、この例外は表示されません。

inactive-connection-timeout-secondsは、数分に設定します。多くの場合は、この設定値によって、非アクティブ接続の強制的なタイムアウトと、非アクティブ化障害を回避できます。ご使用の環境に合わせて、この設定値を調整してください。

8. Oracle ADF Controllerの構成を確認します。
Oracle ADFは、デフォルトでは、ADFオブジェクトに対する変更をADFメモリー・スコープ内にレプリケートするように構成されていません。ADFオブジェクトのレプリケーションは、ADFアプリケーションレベルの構成ファイル(adf-config.xml)に次の適切な設定が含まれている場合にのみサポートされます。

<adfc:adf-controller-config>
<adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support>
</adfc:adf-controller-config>

この設定は、JDeveloperのソース・エディタを使用して行います。第6.1.3.1項「アプリケーション・モジュールの構成」を参照してください。

9. デフォルトのログ出力メッセージを確認します。
デフォルトでは、ADFのログには上位レベルのメッセージ(INFOレベル)が表示されます。デフォルトのログ出力では、さらに詳細なログ・メッセージを有効にする必要なしに、シリアライズやレプリケーションに関する問題を報告することがよくあります。ログの詳細は、第6.1.1.4項「Oracle ADFのログ・ファイル」を参照してください。

10. ADF高可用性アプリケーションのログ・メッセージを有効にします。
ADFのログ出力を、高可用性のランタイム・メッセージを出力するように構成します。デフォルトでは、ADFのログには上位レベルのメッセージ(INFOレベル)が表示されます。Fusion Middleware Controlでロギング・レベルをFINEに設定して、ADF Controllerの高可用性の診断を有効にします。

有効にすると、adf-config.xmlファイルにadfc:adf-scope-ha-supportが設定されていない場合に、ログ出力が警告を出力するようになります。ADFのログ出力の詳細は、第6.1.1.4項「Oracle ADFのログ・ファイル」を参照してください。

11. デバッグを有効にします。
サーバー・ログを調べて、管理対象サーバーの起動時に異常なメッセージがないか確認します。この確認は、管理対象サーバーがクラスタの他のメンバーを見つけられない場合に、特に必要です。サーバー・ログは、DOMAIN_HOME/servers/SERVER_NAME/logsディレクトリに格納されています。

詳細な診断を行うには、DebugCluster、DebugClusterAnnouncements、DebugFailOver、DebugReplication、DebugReplicationDetailsの各フラグを有効にします。各フラグは、weblogic.Adminユーティリティを使用して次のように有効にできます。

$ java weblogic.Admin -url Adminhost:7001 -username <username> -password
<password> SET -type ServerDebug -property DebugCluster true

12. コンポーネントの状態のシリアライズ・チェックを有効にします。
サーバーのチェックを有効にして、セッション属性でシリアライズ不能な状態コンテンツが検出されないようにします。このチェックは、デフォルトでは、実行時のオーバーヘッドを軽減するために無効になっています。シリアライズ・チェックは、Javaサーバーのシステム・プロパティorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATIONによってサポートされます。

表6-1は、このプロパティで使用できるオプションを示しています。オプションを区切るには、カンマを使用します。

表6-1 CHECK_STATE_SERIALIZATIONのオプション

オプション

説明

tree

コンポーネント・ツリー全体がシリアライズ可能であるかどうかをチェックします。これは、最も高速なコンポーネント・チェックです。大部分のテストは、このフラグを有効にして実行してください。

component

シリアライズ可能性について各コンポーネントを個別にチェックします。このオプションは、treeと比較するとかなり低速です。これは、通常、treeのテストでエラーが報告された後にのみ有効にします。このオプションは、問題のあるコンポーネントを絞り込みます。

property

シリアライズ可能性について各コンポーネント属性を個別にチェックします。これはcomponentよりも低速であり、treeまたはcomponentモードで障害が検出された後に問題のある特定のコンポーネント属性を絞り込みます。

session

シリアライズ可能とマークされているJSF Session Mapのすべての属性がシリアライズ可能であることをチェックします。

application

シリアライズ可能とマークされているJSF Application Mapのすべての属性がシリアライズ可能であることをチェックします。

beans

該当するマップのシリアライズ可能なオブジェクトのシリアライズ可能なコンテンツがリクエスト中に変更された場合に、そのオブジェクトがダーティとマークされたことをチェックします。

all

すべてをチェックします。

高可用性をテストするには、まず次のシステム・プロパティを使用してアプリケーション・サーバーを起動し、セッションおよびJSFの状態がシリアライズ可能であることを確認します。

-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree

次のようにbeansオプションを追加して、該当するマップのシリアライズ可能なオブジェクトのシリアライズされたコンテンツがリクエスト中に変更された場合に、そのオブジェクトがダーティとマークされたことをチェックします。

-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree,beans

JSFの状態がシリアライズ不能であることが検出された場合は、次のシステム・プロパティを使用してアプリケーション・サーバーを再起動し、コンポーネントとプロパティのフラグを有効にしてからテストを再実行します。

-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all

これらはJavaシステム・プロパティで、アプリケーション・サーバーを起動する際にこれらを指定する必要があります。

6.2 Oracle ADFの高可用性デプロイメントの構成

この項では、サンプルとして示したOracle ADFの高可用性デプロイメントを構成する方法について説明します。

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

6.2.1 ディレクトリおよびディレクトリ環境変数の用語

次のリストは、この項で使用するディレクトリと変数について説明しています。

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

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

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

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

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

- DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。

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

一貫性を保つために、このディレクトリに対して使用する推奨値は次のとおりです。

- ORACLE_BASE: /u01/app/oracle

- MW_HOME(アプリケーション層): ORACLE_BASE/product/fmw

- WL_HOME: MW_HOME/wlserver_10.3

- ORACLE_HOME: MW_HOME/adf

6.2.2 RCUを使用したデータベースへのFusion Middlewareスキーマのロード

この手順は、Oracle Fusion Middlewareの一部であるスキーマのいずれかをADFアプリケーションで使用する必要がある場合にのみ必要になります。これは通常、ADFアプリケーションがMDSリポジトリを使用する場合に行います。その場合は、Oracle Fusion Middlewareをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareメタデータ・ストアをReal Application Clusters(Oracle RAC)データベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。

最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。

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

6.2.2.1 RCUの実行

Oracle Fusion Middleware 11gに必要なメタデータをインストールする手順は次のとおりです。

1. 次のコマンドを使用してRCUを起動します。

RCU_HOME/bin/rcu &

2. 「ようこそ」画面で「次へ」をクリックします。

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

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

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

- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを指定します: ADFDBHOST1VIRTUAL

- ポート: データベースのポート番号: 1521

- サービス名: データベースのサービス名を入力します: adfha.mycompany.com

- ユーザー名: SYS

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

- ロール: SYSDBA

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

5. 次のメッセージが表示された場合は、「無視」または「停止」をクリックします。
接続先のデータベースには非UTF8 charsetが含まれており、このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。多言語サポートに使用しない場合は続行できますが、それ以外の場合はUTF-8データベースを使用することをお薦めします。

6. 「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、ADFHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。

次のスキーマを選択します。

- AS共通スキーマ

- Metadata Services

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

7. 「スキーマ・パスワード」画面で、メインおよび追加(補助)スキーマ・ユーザーのパスワードを入力し、「次へ」をクリックします。

8. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択し、「次へ」をクリックします。

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

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

RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

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

WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。

1. サーバーが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルおよびその他の要件が、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』に指定されている要件を満たしている必要があります。

- この例ではポート7777を使用しますポート7777を選択する場合、次のコマンドを実行して、ノード上のどのサービスによっても使用されていないことを確認します。

UNIX:
netstat -an | grep LISTEN | grep ":7777"

Windows:
netstat -an | findstr "LISTEN" | findstr ":7777"

2. ポート7777が使用中の場合には、別のポートを選択するか、またはこのポートを使用可能にします。

3. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

4. Oracle Fusion Middleware 11g Webtier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンド./runInstallerを実行します。

Windowsでは、setup.exeをダブルクリックします。

5. 「インベントリ・ディレクトリの指定」画面で、インベントリおよびユーザー・グループの場所を入力して「OK」をクリックします。

6. ダイアログに従ってrootの特権アクションを実行し、「OK」をクリックします。

7. 「ようこそ」画面で「次へ」をクリックします。

8. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

9. 「前提条件チェック」画面で、前提条件がすべて満たされていることを確認し、「次へ」をクリックします。

10. 「インストール場所の指定」画面で、場所を次のように設定します。

/u01/app/oracle/product/11.1.1/ohs_1

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

11. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

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

12. 「コンポーネントの詳細の指定」画面で、次の値を入力します。

- インスタンス・ホームの場所:

/u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1

- インスタンス名: ohs_instance1

- OHSコンポーネント名: ohs1

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

13. 「Web Tierポートの詳細の指定」画面で、次の操作を行います。

- 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

- Oracle HTTP Serverのポート番号を入力します。たとえば、7777と入力します。

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

注意:

ポートの設定の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteインストレーション・ガイド』を参照してください。

14. 「構成サマリー」画面で、選択した内容が正しいことを確認します。「インストール」をクリックします。

15. 「インストールの進行状況」画面で、次の操作を行います。
UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

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

16. 「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。

17. 「構成が完了しました」画面で、「終了」をクリックして終了します。

6.2.3.1 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、Webブラウザで次のURLを入力し、サーバーのルートURLコンテキストにアクセスします。

WebHost1:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザに「Hello World」ページが表示されます。

6.2.4 Oracle Fusion Middlewareホームのインストール

次の各項に記載されている情報を使用して、Oracle Fusion Middlewareコンポーネントをインストールします。

- 第6.2.4.1項「Oracle WebLogic Serverのインストール」

- 第6.2.4.2項「Oracle ADFアプリケーション用Oracle Fusion Middlewareのインストール」

6.2.4.1 Oracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。

1. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

2. Oracle WebLogic Serverインストーラを起動します。

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。

ORACLE_BASE/product/fmw

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

5. 「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。

6. 「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。

7. 「JDKの選択」画面で、「Oracle JRockit 1.6.0_<バージョン> SDK」のみを選択します。「次へ」をクリックします。

8. 「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。

ORACLE_BASE/product/fmw/wlserver_10.3

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

9. 「アプリケーション・サーバー」画面で、「WebLogic」を選択します。「次へ」をクリックします。

10. 「インストールの概要」画面で「次へ」をクリックします。

11. 「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。

6.2.4.2 Oracle ADFアプリケーション用Oracle Fusion Middlewareのインストール

Oracle Fusion MiddlewareのOracle ADFをインストールするには、Application Developerインストーラを使用し、アプリケーション層にあるすべてのノードで次の操作を行います。

1. Oracle Fusion MiddlewareのOracle Fusion Middleware 11g Application Developerインストーラを起動します。

On UNIX (Linux used in this example):
APPHOST1> runInstaller

On Windows:
APPHOST1> setup.exe

Oracle Fusion Middleware 11g Application Developerインストーラで、JRE/JDKの場所を入力するように求められたら、第6.2.4.1項「Oracle WebLogic Serverのインストール」のOracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します。例:

ORACLE_BASE/product/fmw/jrockit_160_<version>

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

4. 「インストール場所の指定」画面で、次の操作を行います。

- 「ミドルウェア・ホーム」には、ORACLE_BASE/product/fmwと入力します。

- 「Oracleホーム・ディレクトリ」には、たとえばadfのように、使用するディレクトリを入力します。

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

5. 「アプリケーション・サーバー」画面で、「WebLogic」を選択します。

6. 「インストール・サマリー」画面で「インストール」をクリックします。

7. 「インストール完了」画面で「終了」をクリックします。

注意:

第6.2.6項「WebLogic ServerのADFドメインを作成するためのAPPHOST1での構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareの最新のパッチ・セットなどの既知のパッチをMiddlewareホームに適用して、Oracle Fusion Middlewareを最新バージョンにしておいてください。

最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

6.2.5 管理サーバーの高可用性

Oracle WebLogic Server管理サーバーの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。

6.2.6 WebLogic ServerのADFドメインを作成するためのAPPHOST1での構成ウィザードの実行

MiddlewareホームのadfディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracleコンポーネントが格納されるドメインを作成します。

1. 次のコマンドを使用して、MW_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。

APPHOST1> ./config.sh

2. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

3. 「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。

- Oracle Enterprise Manager - 11.1.1.0

- Oracle JRF - 11.1.1.0

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

4. 「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。

5. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。

6. 「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。

- WebLogicドメインの起動モード: 「本番モード」を選択

- JDKの選択: 「Oracle JRockit 1.6.0_<バージョン>」を選択

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

7. 「オプションの構成を選択」画面で、次を選択します。

- デプロイメントとサービス

- 管理対象サーバー、クラスタ、およびマシン

- 管理サーバー

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

8. 「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。

9. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: APPHOST1

- リスニング・ポート: 7001

- SSLリスニング・ポート: NA

- SSL有効: 選択を解除

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

10. 「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。

管理対象サーバー名

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WLS_ADF1

APPHOST1のホスト名

8889

NA

選択を解除

WLS_ADF2

APPHOST2のホスト名

8889

NA

選択を解除

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

11. 「クラスタの構成」画面で、次のクラスタを追加します。

- 名前: ADF_CLUSTER

- クラスタ・メッセージング・モード: unicast

- クラスタ・アドレス有効化: 空白のまま

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

12. 「サーバーのクラスタへの割当」画面で、クラスタに次のサーバーを割り当てます。

- ADF_CLUSTER:

- WLS_ADF1

- WLS_ADF2

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

13. 「マシンの構成」画面で、次の操作を行います。

- デフォルトで表示されるLocalMachineを削除します。

- 「UNIXマシン」タブをクリックし、次のマシンを追加します。

名前

ノード・マネージャのリスニング・アドレス

APPHOST1

APPHOST1のホスト名

APPHOST2

APPHOST2のホスト名

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

14. 「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

- APPHOST1: AdminServer、WLS_ADF1

- APPHOST2: WLS_ADF2

15. 「デプロイメントのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。「サービスのクラスタまたはサーバーへのターゲット設定」画面で、「次へ」をクリックします。

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

17. ドメインの作成中画面で「完了」をクリックします。

6.2.6.1 APPHOST1での管理サーバーおよび管理対象サーバー用boot.propertiesの作成

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーおよび管理対象サーバーに対してboot.propertiesファイルを作成します。

管理サーバーに対しては、次の手順を実行します。

1. 次のディレクトリを作成します。

APPHOST1> mkdir -p MW_HOME/wls/user_projects/domains/adfdomain/servers/AdminServer/security

2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminUser
password=adminUserPassword

例:

username=weblogic
password=weblogic

注意:

管理サーバーまたは管理対象サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

WLS_ADF管理対象サーバーに対しては、次の手順を実行します。

管理サーバーに対して作成したファイルをすべてのサーバーにコピーします。

6.2.7 APPHOST1でのシステムの起動

この項では、APPHOST1でシステムを起動する手順について説明します。

6.2.7.1 APPHOST1での管理サーバーの起動

APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/bin
APPHOST1> ./startWebLogic.sh

6.2.7.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. Webブラウザでhttp://VIP1:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. 管理対象サーバーとしてWLS_ADF1およびWLS_ADF2が表示されていることを確認します。

4. ADF_Clusterクラスタが表示されていることを確認します。

5. Enterprise Manager(http://VIP1:7001/em)にアクセスできることを確認します。

6.2.7.3 APPHOST1およびAPPHOST2の管理サーバーおよび管理対象サーバーに対するホスト名の検証の無効化

管理サーバーとノード・マネージャ間にSSL通信を設定していない場合は、この手順を実行する必要があります。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。

ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。

APPHOST1でホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールで、管理サーバー→「SSL」→「詳細」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. プロンプトが表示されたら、変更内容を保存してアクティブ化します。

4. 「ホスト名の検証」を「なし」に設定します。

5. 「WLS_ADF1」→「SSL」→「詳細」を選択します。

6. 「ホスト名の検証」を「なし」に設定します。

7. 管理サーバーとWLS_ADF1管理対象サーバーを再起動します。

APPHOST2でホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールで、「WLS_ADF2」→「SSL」→「詳細」を選択します。

2. 「ホスト名の検証」を「なし」に設定します。

3. 管理サーバーとWLS_ADF2管理対象サーバーを再起動します。

6.2.7.4 APPHOST1でのノード・マネージャの起動

APPHOST1でノード・マネージャを起動する手順は次のとおりです。

1. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

OAHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./setNMProps.sh

注意:

クラスのロード失敗などの問題を回避するために、StartScriptEnabled=trueプロパティを使用する必要があります。

2. ノード・マネージャを起動します。

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

6.2.8 APPHOST2へのOracle WebLogic ServerとOracle ADFのインストール

WebLogic ServerおよびOracle ADFをAPPHOST2にインストールするには、第6.2.3項「WEBHOST1へのOracle HTTP Serverのインストール」以降の手順を繰り返します。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。

6.2.9 pack/unpackユーティリティを使用したAPPHOST2へのドメイン構成の伝播

pack/unpackユーティリティを使用して、ドメイン構成をAPPHOST2に伝播する手順は次のとおりです。

1. 次のpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。

APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/
-template=adfdomaintemplate.jar
-template_name=adf_domain_template

2. 前の手順で作成したテンプレート・ファイルをAPPHOST1からAPPHOST2にコピーします。たとえば、UNIXプラットフォームでは次のようにします。

APPHOST1> scp adfdomaintemplate.jar
user@node2:ORACLE_COMMON_HOME/common/bin

3. unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。

APPHOST2> cd ORACLE_COMMON_HOME/common/bin
APPHOST2> ./unpack.sh
-domain=ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/
-template=adfdomaintemplate.jar

6.2.9.1 APPHOST2での管理サーバーおよび管理対象サーバー用boot.propertiesの作成

APPHOST2上の管理サーバーおよび管理対象サーバーに対してboot.propertiesファイルを作成する手順は、次のとおりです。

1. 次のディレクトリを作成します。

APPHOST1> mkdir -p MW_HOME/wls/user_projects/domains/adfdomain/servers/WLS_ADF2
APPHOST2> mkdir -p MW_HOME/wls/user_projects/domains/adfdomain/servers/WLS_ADF2/security

2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminUser
password=adminUserPassword

例:

username=weblogic
password=weblogic

注意:

管理サーバーまたは管理対象サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

6.2.9.2 APPHOST2でのノード・マネージャの起動

APPHOST2でノード・マネージャを起動するには、第6.2.7.4項「APPHOST1でのノード・マネージャの起動」の手順をAPPHOST2で繰り返します。

6.2.9.3 ADFアプリケーションのレプリケーションの構成

この項の手順を使用して、アプリケーションのレプリケーションを構成します。

クラスタリング要件

アプリケーションをOracle WebLogicクラスタにデプロイする必要があります。これによって、アプリケーションの複数インスタンスに、レプリケーション・チャネルが自動的に確立されます。

注意:

ユニキャスト・クラスタでは、デフォルトのレプリケーション・チャネルは、各管理対象サーバーのリスニング・アドレスを使用して構成されています。そのため、リスニング・アドレスは、Anyでリスニングするように構成するのではなく、特定のIPアドレスまたはホスト名となるように構成する必要があります。

Oracle ADFのレプリケーション

Oracle ADFが適切に構成されていることが重要です。ステートフル・アプリケーションの場合には、アプリケーション・リソースの1つであるadf-config.xmlファイルに、次のタグが存在している必要があります。

<adfc:adf-controller-config><adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support></adfc:adf-controller-config>

アプリケーションでレプリケーションが有効化されていることも必要です。Oracle WebLogic Serverでは、レプリケーションのために様々な種類の永続ストアを使用できます。永続ストアの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

ADFアプリケーションのレプリケーションをデフォルトで有効にするには、weblogic.xmlファイルで次の設定を行います。

<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

replicated_if_clustered設定は、スタンドアロン・アプリケーション環境のレプリケーションを無効にし、クラスタ環境内のメモリー内レプリケーションを使用します。

メモリー内レプリケーションに任意のカスタム・アプリケーションが構成されていることを確認します。

6.2.9.4 ADFアプリケーションのデプロイ

クラスタを設定すると、ADFアプリケーションをデプロイできるようになります。次の点に注意してください。

- 管理サーバー・コンソールを使用して、ADFアプリケーションをEARファイルにデプロイします。

- デプロイメントがクラスタに対して行われるようにします。

- アプリケーションがMDSを使用する場合は、『Oracle Fusion Middleware管理者ガイド』のデータベース・ベースのMDSリポジトリの登録に関する項の指示に従って、MDSをドメインに登録します。

6.2.9.5 Oracle HTTP Serverの管理サーバーおよびWebCenterポータル管理対象サーバーの構成

WebCenterポータル管理対象サーバーを含む管理サーバーへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定します。次の手順を実行します。

1. OHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。

# Spaces
<Location /applicationMountpoint>
WebLogicCluster apphost1.com:8888,apphost2.com:8889
SetHandler weblogic-handler
</Location>

2. WEBHOST1上のOracle HTTP Serverを再起動します。

WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1

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

URLを検証し、HTTP ServerからWebCenterポータル・クラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。次の手順を実行します。

1. WebLogic Server管理コンソールから、WC_Spaces1、WC_Spaces2、WC_Collaboration1、WC_Collaboration2、WC_Utilities1、WC_Utilities2、WC_Portlet1およびWC_Portlet2を次のように起動します。

1. 次のURLの管理コンソールにアクセスします。

http://APPHOST1/console

2. 管理対象サーバーのいずれか(例: WC_Spaces1)をクリックします。

3. 「制御」タブを選択します。

4. 「起動」を選択して管理対象サーバーを起動します。

5. 管理対象サーバーごとに前の手順を繰り返します。

6. 次のURLを使用して、管理対象サーバーへの直接アクセスを検証します。

apphost1:8888/applicationMountpoint

apphost2:8888/applicationMountpoint

apphost1:8889/applicationMountpoint

apphost2:8889/applicationMountpoint

2. WLS_ADF2の稼働中に、Oracle WebLogic Server管理コンソールからWLS_ADF1を停止します。

3. 次のURLにアクセスして、適切な機能を検証します。

WebHost1:7777/applicationMountpoint

4. WebLogic Server管理コンソールからWLS_ADF1を起動します。

5. WLS_ADF2を停止します。

6. 次のURLにアクセスして、適切な機能を検証します。

WebHost2:7777/applicationMountpoint

6.2.10 トポロジのスケーリング

Oracle ADFトポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。

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

この場合は、Oracle ADFを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードの共有記憶域には、Middlewareホームが格納されています。

新しいサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。Oracle Fusion Middlewareのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。

トポロジをスケール・アップするには:

1. Oracle WebLogic Server管理コンソールを使用し、WLS_ADF1のクローンを作成して新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。

1. 管理コンソールから「環境」→「サーバー」を選択します。

2. クローンを作成する管理対象サーバーを選択します。

3. 「クローンの作成」を選択します。

新しい管理対象サーバーにWLS_ADFnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。

2. リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPを割り当てます。

3. この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。

4. Oracle HTTP Serverモジュールをクラスタの新しいメンバーで再構成します。第6.2.9.5項「Oracle HTTP Serverの管理サーバーおよびWebCenterポータル管理対象サーバーの構成」を参照してください。

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

トポロジのスケール・アウトでは、Oracle ADFアプリケーションを使用して構成されている新しい管理対象サーバーを新しいノードに追加します。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

- トポロジ内には、ADFアプリケーションを使用して構成されている管理対象サーバーを実行しているノードがすでに存在しています。

- ADF管理対象サーバーはクラスタ化されており、新しい管理対象サーバーもそのクラスタの一部になります。

- 新しいノードは、WebLogic Server用の既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。packとunpackを実行して管理対象サーバー・ドメインを作成する必要がありますが、WebLogic Serverバイナリを新しい場所にインストールする必要はありません。

トポロジをスケール・アウトするには:

1. 新しいノードで、既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。

3. Oracle WebLogic管理コンソールにログインします。

4. 新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。

5. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。

6. Oracle WebLogic Server管理コンソールを使用し、WLS_ADF1のクローンを作成して新しい管理対象サーバーにします。それにWLS_ADFnという名前を付けます。nはその新しいマシンに割り当てる番号です。

7. リスニング・アドレスとして、新しい管理対象サーバー用に使用するホスト名またはIPを割り当てます。
管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。

6. 「リスニング・アドレス」をAPPHOSTnに設定します。APPHOSTnは新しいマシンのDNS名です。

7. 「保存」をクリックします。

8. 変更を保存およびアクティブ化します。

この変更は、管理対象サーバーを再起動するまで有効になりません。

8. 次のようにpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。

APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/
adfdomain/ -template=adfdomaintemplateScale.jar
-template_name=adf_domain_templateScale

次のコマンドをAPPHOST1で実行し、作成したテンプレート・ファイルをAPPHOSTnにコピーします。

APPHOST1> scp adfdomaintemplateScale.jar oracle@APPHOSTN:/
ORACLE_COMMON_HOME/common/bin

次のようにAPPHOSTnでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。

APPHOSTn> cd ORACLE_COMMON_HOME/common/bin
APPHOSTN> ./unpack.sh
-domain=ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/
-template=adfdomaintemplateScale.jar

9. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。

APPHOSTn> WL_HOME/server/bin/startNodeManager <new_node_ip>

10. Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーをすべて停止します。

2. 新たに作成した管理対象サーバーが実行されていることを確認します。

3. 新たに作成した管理対象サーバー上のアプリケーションにアクセスします。アプリケーションが機能している必要があります。

6.3 WebCenterポータルと高可用性の概要

この項では、WebCenterポータルの高可用性クラスタを設計するために必要な課題および考慮事項を紹介します。

6.3.1 WebCenterポータルの理解

WebCenterポータルは、Java Server Faces(JSF)の標準ベースの宣言型開発と、ポータルの柔軟性とパワー、および一連の統合されたWeb 2.0サービスを組み合せたものです。

6.3.1.1 WebCenterポータル・コンポーネント

WebCenterポータルのコンポーネントは次のとおりです。

- Oracle WebCenterポータル: Spacesは、一連の堅牢なサービスとアプリケーションにより、ソーシャル・ネットワーキング、通信、コラボレーションおよび個人の生産性に対して、単一の統合されたWebベース環境を提供します。
Spacesアプリケーションは、JSF、Oracle ADF、Oracle WebCenterポータル: Framework、Oracle WebCenterポータル・サービスおよびComposerを使用して構築されています。Spacesアプリケーションには、次の機能が備えられています。

- 企業ポータルおよび複数のサイトやコミュニティを作成するためのブラウザベースのプラットフォーム。

- 個人用コンテンツの格納、メモの保存、ビジネス・プロセスの割当ての表示およびビジネス・プロセスの割当てへの応答、メールの送受信などを行う個人用作業領域である、各ユーザーのホーム・スペース。

- スレッド・ディスカッション、ブログ、Wiki、ワークリスト、お知らせ、RSS、最近のアクティビティ、検索など。

- Oracle WebCenter Portlets Frameworkは、標準ベースのポートレット(JSR 168、WSRP 1.0および2.0)と従来のOracle PDK-Javaベースのポートレット両方のデプロイメントと実行をサポートしています。WebCenterポータルには、OmniPortlet、Webクリッピング、WSRPツールなど、すぐに使用可能なプロデューサがいくつか用意されています。

- Oracle WebCenterポータル: Frameworkの機能は次のとおりです。

- ランタイム・アプリケーションのカスタマイズ(アプリケーションを再デプロイせずに、Composerを使用してWebCenterポータル・アプリケーションを即時変更できます)

- JSR-168およびJSR-286標準ベースのWSRPポートレットおよびPDK-Javaポートレットのサポート

- Oracle WebCenter Content Server、Oracle Portal、ファイル・システムなどのコンテンツ・リポジトリへの、JCR(JSR170)を使用したコンテンツの統合

- JSFページおよびOracle ADFタスク・フローを標準ベースのポートレットとして表示できるようにするOracle JSF Portlet Bridge

- Oracle WebCenterポータルのディスカッション・サーバーは、ディスカッション・フォーラムやお知らせをアプリケーションに統合する機能を提供します。

- Oracle WebCenterポータルのAnalyticsコレクタは、WebCenterポータル・アプリケーション内での様々なユーザー・アクティビティに関するレポートを表示する、次のような機能を提供します。

- ログイン

- ページ・ビュー

- ポートレット・ビュー

- ドキュメント・ビュー

- 検索メトリック

- レスポンス時間

- Oracle WebCenterポータルのアクティビティ・グラフ・サービスは、Oracle WebCenterポータルのAnalyticsで収集された統計を分析する機能を提供します。アクティビティ・グラフによる分析の出力は、オブジェクトおよびユーザーについて収集されたスコアであり、推奨事項を示すために使用されます。これらのスコアはアクティビティ・データベースに格納されます。

- Oracle WebCenterポータルのパーソナライズ・サーバーは、RESTful Webサービスを介してクライアント・アプリケーションからアクセスされる軽量サービスです。パーソナライズ・サーバーを使用すると、ユーザーは選択した基準に基づいて対象ユーザーにアプリケーション・コンテンツを配信できます。

WebCenterポータル・アプリケーションは、WebCenterポータル: サービスと統合することもできます。Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイドのサービス・データ・リポジトリに関する表を参照してください。このガイドでは、WebCenterポータル・サービスを構成する方法についても説明しています。

6.3.1.2 WebCenterポータルの単一ノード・アーキテクチャ

WebCenterポータルをインストールすると、Middlewareホーム・ディレクトリの下にWebCenterディレクトリが作成されます。このインストールによって作成されるWebCenterドメイン(wc_domain)には、管理サーバーと4つのWebLogic管理対象サーバーであるWC_Spaces1(Spacesアプリケーションをホスト)、WC_Portlet(すぐに使用可能ないくつかのポートレット・プロデューサをホスト)、WC_Collaboration1(ディスカッション・サーバーをホスト)、WC_Utilities1(Analytics、アクティビティ・グラフおよびパーソナライズ・サーバーをホスト)が含まれ、さらに統合用に選択したその他のWebCenterポータル・サービスが含まれます。

WebCenterポータル: Frameworkを使用して構築したWebCenterポータル・アプリケーションは、Frameworkアプリケーションと呼ばれます。追加のカスタム管理対象サーバーを作成すると、適切なライブラリによってこれらのサーバーがプロビジョニングされ、WebCenterポータル: Spacesと同じ外部リソースを利用できるようになります。管理対象サーバーの詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middlewareの概念の理解に関する項を参照してください。図6-4は、WebCenterポータルの基本的な単一ノード・アーキテクチャを示しています。

図6-4 WebCenterポータルの基本的な単一ノード・アーキテクチャ

「図6-4 WebCenterポータルの基本的な単一ノード・アーキテクチャ」の説明

6.3.1.3 WebCenterポータル: 状態と構成の永続性

Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイドのWebCenterポータルの状態と構成の永続性に関する説明を参照してください。

6.3.1.4 WebCenterポータルのログ・ファイルの場所

Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイドのWebCenterポータルのログ・ファイルの場所に関する説明を参照してください。

6.3.2 WebCenterの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内の別のメンバーがリクエストを処理できます。

WebCenterポータル・デプロイメント内の管理対象サーバーは、それぞれクラスタとしてデプロイでき、異なるクラスタ・メンバーを同じノードまたは異なるノードに配置できます。図6-5では、クラスタに送信されるすべてのリクエストが、クラスタのいずれかのメンバーによって同等に処理されます。

図6-5 WebCenterポータルの2ノードの高可用性アーキテクチャ

「図6-5 WebCenterポータルの2ノードの高可用性アーキテクチャ」の説明

次の各項では、WebCenterポータル・クラスタのランタイムと構成に関して詳細に説明します。

6.3.2.1 WebCenterポータル・アプリケーション

WebCenterポータルのインストール中に、管理対象サーバーにシステム・ライブラリとADFライブラリがプロビジョニングされます。表6-2に、管理対象サーバーとそれらで実行されるアプリケーションの一覧を示します。

表6-2 WebCenterポータルの管理対象サーバーとアプリケーション

管理対象サーバー

インストールされているアプリケーション

WC_Spaces

Spaces

Spacesオンライン・ヘルプ

WC_Portlet

OmniPortletおよびWebクリッピング

WSRPツール

ページレット・プロデューサ

WebCenterサービス・プロデューサ

WC_Collaboration

ディスカッション・サーバー

WC_Utilities

Analyticsコレクタ

アクティビティ・グラフ・エンジン

パーソナライズ・サービス

6.3.2.2 Oracle WebCenterの起動順序

管理対象サーバーを起動すると、アプリケーションとライブラリは次の順序で起動します。

1. Oracleシステム・ライブラリ(別名、JRFライブラリ)

2. Oracle ADFライブラリ

3. インスツルメンテーション・アプリケーション(Oracle DMSなど)

4. WebCenterポータル・アプリケーション

起動順序は依存性の順序でもあります。依存コンポーネントが正しくデプロイされないと、その後のコンポーネントが正しく機能しない場合があります。WebCenterポータル・アプリケーションの起動は、ディスカッション・サーバーなどの外部サービスやその他のバックエンド・サーバーの可用性に依存しません。

6.3.2.3 クラスタへのWebCenterポータル・アプリケーションのデプロイ

図6-5に示すようなWebCenterポータルのクラスタ・デプロイメントでは、アプリケーション、ライブラリおよびシステム・リソースのターゲット設定に関して、次のルールに従います。

- アプリケーションとライブラリのターゲットをクラスタのターゲットに設定します。たとえば、SpacesアプリケーションのターゲットをSpacesクラスタに設定します。

- JDBCリソースのターゲットをクラスタのターゲットに設定します。

WebCenterポータル・アプリケーションおよびWebCenterポータル・ディスカッション・サーバーは、Oracle WebLogicstageアプリケーションとしてデプロイされます。各アプリケーションの初期デプロイメント中に、デプロイメント・ファイルが管理サーバーから送信され、ローカルにデプロイされます。

クラスタ通信

デフォルトでは、各WebCenterポータル・クラスタはユニキャストとして構成されています。WebCenterポータル・クラスタをマルチキャスト用に構成するには、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

6.3.2.4 WebCenterポータルのAnalyticsコレクタ

WebCenterポータルのAnalyticsは、SpacesアプリケーションなどのAnalyticsクライアントからリクエストを受信する、個別のAnalyticsコレクタで構成されています。

この項では、Analyticsコレクタ・クラスタがどのように機能するのかを説明します。

クラスタ化された環境では、プロデューサ(コレクタのクライアント)およびコレクタは、クラスタ固有のチャネル名で構成されます。各コレクタは、その場所からクラスタ固有のチャネルで定期的にハートビートをブロードキャストします。プロデューサはそのチャネルでこれらのコレクタのハートビートをリスニングし、ハートビートを受信すると、そのコレクタを既知のコレクタのリストに追加します。プロデューサがイベントを送信する必要がある場合は、ラウンドロビン・アルゴリズムを使用してそのリストからコレクタを選択し、そのコレクタにイベントを送信します。(意図的に、または障害によって)コレクタが停止すると、ハートビートのブロードキャストは停止します。プロデューサがハートビートの受信を停止した場合、そのコレクタをリストから削除して、そのコレクタへのイベントの送信を停止します。いずれのコレクタのハートビートも受信しない場合は、イベントを送信しません。

WebCenterポータルAnalyticsは、構成された一連のポート上でUDPおよびマルチキャストを使用してクライアントと通信します。単一ノード・セットアップでは、クライアントは、サーバー・ホストとポートの場所を持つWLSTコマンドで構成され、すべてのイベントをUDPを使用してその場所に送信します。複数ノード・セットアップの場合、サーバーはクラスタで実行中の様々なサーバーの場所に(UDPマルチキャストを使用して)ブロードキャストするよう構成され、クライアントは同じWLSTコマンドで構成されるため、クライアントはサーバーの場所を受信し、使用可能なサーバーのリストを保持します(これはメモリー内に格納されます)。クライアントでサーバーからの定期的なハートビートが受信されない場合、クライアントはそのサーバーを既知のサーバーのリストから削除してイベントの送信を停止します。

WebCenterポータル・アプリケーション・クライアントと1対1の関係になるよう、Analyticsコレクタをユニキャストとして構成することをお薦めします。

6.3.2.5 WebCenterポータルの状態のレプリケーション

WebCenterポータルは、いくつかのステートフル・コンポーネントを持つOracle ADFに依存しています。Oracle WebCenter自体もステートフル・アプリケーションです。したがって、クラスタ・シナリオでは状態レプリケーションを構成する必要があります。

Oracle WebLogic Serverの状態レプリケーションの動作の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

Oracle WebLogic Serverは、次の2種類の状態のレプリケーションをサポートしています。

- メモリー内レプリケーション: Oracle WebLogic Serverはメモリー内レプリケーションを使用して、1つのサーバー・インスタンスから別のインスタンスにセッション状態をコピーします。プライマリ・サーバーは、クライアントが最初に接続するサーバーにプライマリ・セッション状態を作成し、クラスタ内の別のWebLogic Serverインスタンスにセカンダリ・レプリカを作成します。このレプリカは最新状態に維持されるため、サーブレットをホストしているサーバーに障害が発生した場合に使用できます。

- JDBCベースの永続性: JDBCベースの永続性では、Oracle WebLogic Serverは、ファイル・ベースまたはデータベース・ベースの永続性を使用して、サーブレットまたはJSPのHTTPセッション状態を保持します。

状態のレプリケーションを正常に構成するには、環境とアプリケーションの両方を適切に構成する必要があります。フェイルオーバーの状況における状態のレプリケーションの動作の詳細は、第6.3.2.8項「アプリケーションのフェイルオーバーで予想される動作」を参照してください。

状態のレプリケーションにおける問題の診断の詳細は、第6.3.2.5項「WebCenterポータルの状態のレプリケーション」を参照してください。

6.3.2.6 分散Javaオブジェクト・キャッシュの理解

WebCenterポータル・アプリケーションでは、パフォーマンス向上のために分散Javaオブジェクト・キャッシュが使用されています。このキャッシュはすべてのWebCenterポータル・クラスタで構成し、クラスタごとに分散キャッシュを1つずつ用意します。

表6-3は、WebCenterポータルがJavaオブジェクト・キャッシュに配置するオブジェクト・タイプの例を一覧表示しています。

表6-3 WebCenterポータルのJavaオブジェクト・キャッシュ用のオブジェクト・タイプ

WebCenterポータル・コンポーネント

キャッシュされるオブジェクト

ディスカッション・サービス

トピックとフォーラム

お知らせサービス

お知らせ

インスタント・メッセージおよびプレゼンス・サービス

プレゼンス・サブスクリプション・リスト

ユーザーのプレゼンス/サブスクリプション・ステータス

ワークリスト・サービス

呼び出されたワークリスト項目(キャッシュ済データは、リフレッシュが呼び出されるまで使用されます)。

コンテンツ統合(Oracle Portal)

JCR: リポジトリから取得したタイプ情報とメタデータ。

サービス・フレームワーク

ユーザー・プロファイル。問合せされたユーザー名。

最近のアクティビティ・サービス

ユーザーごとの最近のアクティビティ結果。

Spacesアプリケーション

アプリケーション内のスペースとスペース・テンプレートのグローバル・リスト。

ユーザーがアクセス可能なスペースとスペース・テンプレートのリスト。

ページ・サービス

スコープ内のページのリスト。

WSRPサーバー

WSRPプロデューサのプリファレンス・ストアの値。

ドキュメント・サービス

Spacesアプリケーション用に構成されたドキュメント・サービスのプロビジョニングと構成のチェック。

プロファイルの管理

軽量ユーザー・プロファイル・オブジェクト

ナビゲーション・サービス

アクティブなナビゲーション・モデル・オブジェクトのリスト

ポートレット・コンシューマ

ポートレット・マークアップ

コラボレーション

コラボレーション・サービスは、ユーザー・セッションごとにオブジェクトをJavaオブジェクト・キャッシュに格納します。HTTPセッションが破棄されると、これらのキャッシュ済ユーザー・セッションも破棄されます。

ワークリスト

ワークリストは呼び出された項目をキャッシュするため、リフレッシュをクリックするか、または15分間隔のリフレッシュ・ポーリングをトリガーしないかぎり、ユーザーが設定によってソートやグループを変更する際に同じ項目が表示されます。グループおよびソートの順序の設定により表示もキャッシュされ、変更が行われたときに更新されます。これは読取り専用データで、存在しない場合にはフェッチされてキャッシュに格納されます。

Spacesアプリケーション

すべてのテンプレートおよびパブリック・スペースのリストは、Javaオブジェクト・キャッシュに保持されます。すべてのユーザーは、特定のユーザーがアクセスできるスペースとテンプレートのリストに加えて、このリストを共有します。これらはユーザーごとにキャッシュされます。1つのJVMで作成されるテンプレートは、JOCがデータを配布するか、または2番目のJVMの管理者が明示的リフレッシュを行ってキャッシュを再構築しないかぎり、テンプレート・キャッシュが別のJVMで初期化されている場合には表示されません。

ドキュメント・サービス

Spacesアプリケーションの構成と同様、ドキュメント・サービスは、Javaオブジェクト・キャッシュを使用して、ドキュメント・サービスのプロビジョニングと構成のチェックをキャッシュします。プロビジョニングの場合、キャッシュされたオブジェクトには分散済のフラグが付けられます。これらのオブジェクトは、正しく構成されたJavaオブジェクト・キャッシュによって高可用性環境内でレプリケートされ、構成のキャッシュ済状態はローカルで保持されます。キャッシュされたオブジェクトはすべて、1分後に期限切れとなるようにフラグが付けられます。Spacesアプリケーションがプロビジョニングと構成を繰り返しチェックしてUIにおけるサービスのレンダリングを制御するため、キャッシュすることによって、Oracle WebCenter Content Serverの状態をチェックする目的でOracle WebCenter Contentコールが行われる回数が減ります。

ポートレット・コンシューマ

ポートレット・コンシューマでは、ポートレット・レスポンスのキャッシュ・ヘッダーに応じて、ポートレット・マークアップがJavaオブジェクト・キャッシュに格納されます。このキャッシュは、期限切れベースまたは検証ベースになります。

プロファイルの管理では、軽量のユーザー・プロファイル・オブジェクトがJavaオブジェクト・キャッシュに格納されます。特定のプロファイル・データが見つからない場合、バックエンドから問合せが行われ、キャッシュに格納されます。格納されるオブジェクトの数の上限は1000であり、Javaオブジェクト・キャッシュに1時間保持されます。

ナビゲーションでは、ユーザー・セッションごとにナビゲーション・モデル・オブジェクトがJavaオブジェクト・キャッシュに格納されます。HTTPセッションが破棄されると、これらのキャッシュされたオブジェクトも破棄されます。

最近のアクティビティ

最近のアクティビティのタスク・フローまたはRSSフィードが表示されるたびに結果の再問合せが行われないようにするため、最近のアクティビティ結果のリストは、ユーザーごとにキャッシュされます。キャッシュは15分ごとに自動的にリフレッシュされるか、または最近のアクティビティのタスク・フローにあるリフレッシュ・アイコンを使用して手動でリフレッシュできます。

Javaオブジェクト・キャッシュの構成手順については、第6.4.13項「Javaオブジェクト・キャッシュの構成」を参照してください。

6.3.2.7 WebCenterポータルのフェイルオーバーによる保護および予想される動作

Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内で他に利用可能なメンバーがリクエストを処理できます。

セッションのフェイルオーバー要件

WebCenterポータル・アプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。

- クラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できる必要があります。

- ステートフルな場合、第6.4.15項「WebCenterポータルのレプリケーションの構成」の説明に従って、状態のレプリケーションが正しく構成されています。

- Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されています。

- ハードウェア・ロード・バランサを使用する場合は、ロード・バランサが:

- 利用可能なインスタンスすべてに対してトラフィックをルーティングしています

- 利用できないインスタンスをマークするように、状態モニターで正しく構成されています

- セッションの状態の永続性をサポートするように構成されています

6.3.2.8 アプリケーションのフェイルオーバーで予想される動作

環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気が付きません。アプリケーション・フェイルオーバーにおけるイベントの順序の例は次のようになります。

1. ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。

2. ノード、プロセスまたはネットワークに障害が発生したため、インスタンスAが使用できなくなります。

3. ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。

4. ユーザーが後続のリクエストを行い、このリクエストがインスタンスBにルーティングされます。

5. インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。

6. インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。

予想される動作に対する例外

WebCenterポータルについて、既知の例外は次のとおりです。

- Oracle ADFのポップアップ: 開いているポップアップがフェイルオーバー時に閉じられ、次のコンポーネントに影響を与えます(それ以外の場合は、例外はありません)。

- Composer(プロパティ・インスペクタ、ELビルダー、タスク・フローのパラメータ選択リスト、リソース文字列エディタ)

- 保存(確認ダイアログ・ボックス)

- リスト

- リンク(リンク削除のポップアップ)

フェイルオーバーの発生時には、ポップアップが表示される操作を再実行して、そのポップアップを再表示する必要があります。これがSpacesに表示される具体的な方法および推奨される処置は、表6-4に一覧表示されています。

表6-4 WebCenterポータルのトラブルシューティングのシナリオ

フェイルオーバー前のアクション

フェイルオーバー後

推奨される処置

任意のページにアクセスして「ページの作成」をクリックします。

名前を入力し、テーマを選択して「OK」をクリックします。テーマを選択すると、「ページ作成」ポップアップが閉じられます。

この操作を繰り返します。

「ページの管理」を起動します。

ポップアップ内で、ポップアップを閉じる以外の操作を実行します。たとえば、「ページ・アクション」をクリックします。任意の操作を実行すると、「ページの管理」ポップアップが閉じます。

この操作を繰り返します。

「ページの管理」を起動し、ページに対して「ページ・アクション」をクリックしてから、メニュー内の「削除」オプションをクリックします。

確認ポップアップで「OK」をクリックします。「OK」をクリックすると、確認ポップアップと「ページの管理」ポップアップが閉じます。削除(完了済の可能性がある)の結果は、タブ間で表示されません。

「ページの管理」ポップアップを再起動し、ページが削除されたかどうかを確認します。削除されていない場合は、もう一度削除してみます。

「アプリケーションのパーソナライズ」ポップアップを起動します。「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。

「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。リクエストをサーバーに送信する任意の操作を実行すると、「アプリケーションのパーソナライズ」ポップアップが閉じます。

この操作を繰り返します。

「プリファレンス」を起動します。

「プリファレンス」のタブ(「一般」、アカウント、「メッセージング」、「検索」)間の切替えを行います。「プリファレンス」のタブ間で切替えを行うと、「プリファレンス」ポップアップが閉じます。

この操作を繰り返します。

「お気に入りの管理」を起動します。サーバーを停止して、ポップアップを閉じる以外の操作を実行します。たとえば、フォルダを開いてお気に入り情報の編集をクリックします。

ポップアップを閉じる以外の操作を実行します。たとえば、フォルダを開いてお気に入り情報の編集をクリックします。任意の操作を実行すると、「お気に入りの管理」ポップアップが閉じます。

「お気に入りの管理」ポップアップを再起動し、操作が正常に実行されたかどうかを確認します。正常に実行されなかった場合は、この操作を再試行します。

アプリケーションの編集と新しいフォルダの作成を選択します。

MDSの例外が開きます。

この操作を再試行します。

ComposerのCustomization Managerで作業します。

Oracle Composerは、Customization Managerに関連する状態を失います。

Customization Managerを再起動します。

Oracle Composerのソース・ビューでコンポーネントを選択します。

Oracle Composerは、コンポーネントを見失います。

この操作を繰り返します。

- コンポーネント固有の問題: WebCenterポータルの各コンポーネントに固有の他の問題は、表6-5に一覧表示されています。

表6-5 WebCenterポータルでの予想される動作に対する例外

WebCenterポータル・コンポーネント

予想される動作に対する例外

ページレット・プロデューサ

フェイルオーバー時には、未保存または保留中の変更は保持されません。フェイルオーバーが発生すると、管理者は

管理セッションを再確立する必要があり、特定の状態を保持するためにプロキシが必要なときには、ユーザーもセッションを再確立する必要がある場合があります。SSOが構成されている場合、資格証明が自動的に提供され、セッションが再確立されます。

スペース・イベント

特定のフィールド(開始または終了の日/時/分)を変更すると、フェイルオーバーの発生時にイベント・フォームが閉じます。

ポートレット

障害は完全に透過的です。

リスト

障害は完全に透過的です。

リンク

障害は完全に透過的です。

検索

長時間実行される問合せの最中。戻される結果は保証されません(ここでは書込み操作は存在しないことに注意)。ユーザーは問合せを再発行できます。

タグ付け

障害は完全に透過的です。

最近のアクティビティ

ツリー・ノードのオープン/クローズ状態はレプリケートされません。フェイルオーバー後、結果のツリーによってノードがすべて閉じます。ノードは開きなおす必要があります。

ワークリスト

障害は完全に透過的です。

ドキュメント・マネージャ

ユーザーがドキュメントをアップロードしたときに、同じ名前のドキュメントがすでに存在している場合は、「新規バージョンの確認」画面が表示されます。その画面の表示中、ファイルは一時的なローカルの場所に格納されます。そのときにフェイルオーバーが発生すると、アップロードしたファイルは失われ、ユーザーはアップロード・プロセスを再実行する必要があります。

6.3.2.9 アプリケーション・デプロイメントのロギングの監視

Oracle WebLogic Server管理コンソールを使用して、アプリケーション・デプロイメントのステータスを確認します。また、WebCenterポータル・プロセスの開始、停止および監視には、Oracle WebLogic ServerインフラストラクチャとEnterprise Manager Fusion Middleware Controlも使用できます。

6.3.2.10 WebCenterポータルのクラスタワイドの構成変更

Spacesアプリケーションとポートレット・プロデューサの場合、すべての構成データはMDSリポジトリおよびポートレット・プロデューサに格納されます。アプリケーションの起動時には、追加のクラスタ・デプロイメントによって、最新の構成が自動的に読み取られます。

ディスカッション・サーバーの場合、構成情報は既存のクラスタ・サーバーから移動する必要があります。これは、Oracle WebLogic Serverのpack/unpackユーティリティによって自動的に行われます。これがお薦めする手順です。

6.3.2.11 クラスタ環境での構成の保持

Spacesアプリケーションとポートレット・プロデューサの場合、すべての構成データはMDSリポジトリおよびポートレット・プロデューサに格納されます。クラスタ内の1つのサーバーの構成に対して行われた変更は、ただちに他のすべてのメンバーから参照可能になります。

ディスカッション・サーバーは頻繁に変更されることはありませんが、変更された場合は、変更をクラスタの他のメンバーに再適用する必要があります。再適用するには、ロード・バランサを使用するかわりに各ディスカッション・サーバーに直接接続し、必要な管理変更を行います。

6.4 WebCenterポータルの高可用性の構成

図6-5は、1つのWebLogic Serverドメイン内の2つのOracle WebLogic Serverで、2ノードのWebCenterポータル・クラスタが稼働している状況を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。Oracle RACデータベースには、メタデータとスキーマが格納されます。管理サーバーにはVIPが使用されます(手動フェイルオーバー用)。

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

注意:

コマンド例はすべて、Kシェルまたはbashシェルに対するものです。Cシェルの例は提供されていません。

WebCenterポータルの高可用性の構成手順は次のとおりです。

- 第6.4.1項「環境の準備: WebCenterポータルの高可用性構成の設定前に必要な手順」

- 第6.4.2項「WEBHOST1へのOracle HTTP Serverのインストール」

- 第6.4.3項「Oracle Fusion Middlewareホームのインストール」

- 第6.4.4項「管理サーバーのVIPの有効化」

- 第6.4.5項「WebLogic Server WebCenterのドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」

- 第6.4.6項「APPHOST1での管理サーバーおよび管理対象サーバー用boot.propertiesの作成」

- 第6.4.7項「APPHOST1でのシステムの起動」

- 第6.4.8項「APPHOST2でのWebLogic ServerおよびWebCenterポータルのインストール」

- 第6.4.9項「pack/unpackユーティリティを使用したAPPHOST2へのドメイン構成の伝播」

- 第6.4.10項「APPHOST2でのノード・マネージャの起動」

- 第6.4.11項「Oracle HTTP Serverの管理サーバーおよびWebCenterポータル管理対象サーバーの構成」

- 第6.4.12項「APPHOST2への管理サーバーの手動フェイルオーバーの構成」

- 第6.4.13項「Javaオブジェクト・キャッシュの構成」

- 第6.4.14項「MDSリポジトリに対する分散通知の構成」

- 第6.4.15項「WebCenterポータルのレプリケーションの構成」

- 第6.4.16項「Analyticsの構成」

- 第6.4.17項「アクティビティ・グラフの構成」

- 第6.4.18項「ディスカッション・サーバー用クラスタリングの構成」

- 第6.4.19項「トポロジのスケーリング」

- 第6.4.20項「WebCenterポータルの高可用性のトラブルシューティング」

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

6.4.1 環境の準備: WebCenterポータルの高可用性構成の設定前に必要な手順

次の各項では、WebCenterポータルの高可用性構成を設定する前に必要となる手順について説明します。

プラットフォーム固有のコマンドの詳細は、Oracle Fusion Middleware Oracle WebCenterインストレーション・ガイドを参照してください。

6.4.1.1 データベースに関する前提条件

WebCenterポータルでは、サポートされているデータベースおよびスキーマが存在している必要があります。

データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。

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

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

6.4.1.2 VIPとIPの前提条件

管理サーバーの仮想IPを構成するには、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。

6.4.1.3 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

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

自動ストレージ管理

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

- インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clusterデータベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

データベースの初期化パラメータ

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

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

パラメータ

必要な値

パラメータ・クラス

PROCESSES

300以上

静的

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

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

SQL> SHOW PARAMETER processes

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

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

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

注意:

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

6.4.1.4 LDAPプロバイダのインストールと構成

本番環境では、WebCenterポータルの高可用性トポロジには外部LDAPポリシー・ストアが必要です。サポートされるポリシー・ストアおよびLDAPの構成手順の詳細は、Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイドを参照してください。

6.4.1.5 ディレクトリおよびディレクトリ環境変数の用語

次のリストは、この項で使用するディレクトリと変数について説明しています。

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

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

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

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

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

- DOMAIN_HOME: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。

これらのディレクトリで一貫性を保つためにお薦めする値は、次のとおりです。

ORACLE_BASE:

/u01/app/oracle

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

ORACLE_BASE/product/fmw

WL_HOME:

MW_HOME/wlserver_10.3

ORACLE_HOME:

MW_HOME/WC1

ORACLE_COMMON_HOME:

MW_HOME/oracle_common

6.4.1.6 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード

WebCenterポータルのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとWebCenterポータル・スキーマをReal Application Clusterデータベースにインストールします。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。

最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

6.4.1.6.1 RCUの実行

RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。

1. 次のコマンドを使用してRCUを起動します。

RCU_HOME/bin/rcu

2. 「ようこそ」画面で「次へ」をクリックします。

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

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

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

- ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを指定します: WCDBHOST1VIRTUAL

- ポート: データベースのポート番号: 1521

- サービス名: データベースのサービス名を入力します: wcha.mycompany.com

- ユーザー名: SYS

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

- ロール: SYSDBA

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

6. 次の警告メッセージを受信した場合は、「無視」または「停止」をクリックします。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。

7. 「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、WCHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。

- 次のスキーマを選択します。

- AS共通スキーマ:
Metadata Services

- WebCenterインフラストラクチャ:
WebCenterポータル

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

9. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。「次へ」をクリックします。

10. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択します。「次へ」をクリックします。

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

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

RCUの使用方法の詳細は、Oracle Fusion Middlewareインストレーションの概念およびリポジトリ作成ユーティリティ・ユーザーズ・ガイドを参照してください。

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

WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。

1. サーバーが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルおよびその他の要件が、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』に指定されている要件を満たしている必要があります。

- この例ではポート7777を使用しますポート7777を選択する場合には、ノード上のいずれのサービスでもこのポートが使用されていないことを確認します。このことを確認するには、次のコマンドを実行します。
UNIX:

netstat -an | grep LISTEN | grep ":7777"

Windows:

netstat -an | findstr "LISTEN" | findstr ":7777"

ポート7777が使用中の場合には、別のポートを選択するか、またはこのポートを使用可能にします。

2. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

3. Oracle Fusion Middleware 11g Webtier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンド./runInstallerを実行します。

Windowsでは、setup.exeをダブルクリックします。

4. 「インベントリ・ディレクトリの指定」画面で、インベントリおよびユーザー・グループの場所を入力して「OK」をクリックします。

5. ダイアログに従ってrootの特権アクションを実行し、「OK」をクリックします。

6. 「ようこそ」画面で「次へ」をクリックします。

7. 「インストール・タイプの選択」画面で、「インストールと構成」を選択します。「次へ」をクリックします。

8. 「前提条件のチェック」で、すべての前提条件が満たされていることを確認します。「次へ」をクリックします。

9. 「インストール場所の指定」画面で、場所を次のように設定します。
/u01/app/oracle/product/11.1.1/ohs_1

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

11. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

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

12. 「コンポーネントの詳細の指定」画面で、次の値を入力します。

- インスタンス・ホームの場所: app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1

- インスタンス名: ohs_instance1

- OHSコンポーネント名: ohs1

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

14. 「Web Tierポートの詳細の指定」画面で、次の操作を行います。

- 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

- Oracle HTTP Serverのポート番号を入力します。たとえば、7777と入力します。

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

注意:

ポートの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』を参照してください。

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

16. 「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。

17. 「インストールの進行状況」画面で、次の操作を行います。
UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

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

18. 「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。

19. 「構成が完了しました」画面で、「終了」をクリックして終了します。

6.4.2.1 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、ブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

WebHost1:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザに「Hello World」ページが表示されます。

6.4.3 Oracle Fusion Middlewareホームのインストール

次の手順を使用して、Oracle Fusion Middlewareコンポーネントをインストールします。

- Oracle WebLogic Server(第6.4.3.1項「Oracle WebLogic Serverのインストール」を参照)

- WebCenterポータル(第6.4.3.2項「WebCenterポータル用のOracle Fusion Middlewareのインストール」を参照)

6.4.3.1 Oracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。

1. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、およびそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

2. Oracle WebLogic Serverインストーラを起動します。

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」フィールドで、MW_HOMEと入力します。

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

5. 「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。

6. 「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。

7. 「JDKの選択」画面で、「Oracle JRockit 1.6.0_<バージョン> SDK」のみを選択して、「次へ」をクリックします。

8. 「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
WL_HOME

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

9. 「インストールの概要」画面で「次へ」をクリックします。

10. 「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。

6.4.3.2 WebCenterポータル用のOracle Fusion Middlewareのインストール

アプリケーション層にあるすべてのノードにWebCenterポータル用のOracle Fusion Middlewareをインストールする手順は次のとおりです。

1. WebCenterポータル用のOracle Fusion Middlewareのインストーラを起動します。
UNIXの場合(次の例はLinuxの場合):

APPHOST1> runInstaller

Windowsの場合:

APPHOST1> setup.exe

Oracle Fusion Middleware 11g WebCenterインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_<バージョン>のように入力します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

4. 「インストール場所の指定」画面で、次の操作を行います。

- 「MiddleWareホーム」には、MW_HOMEと入力します。

- 「Oracleホーム・ディレクトリ」には、たとえばwcのように、使用するディレクトリを入力します。

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

5. 「インストール・サマリー」画面で「インストール」をクリックします。

6. 「インストール完了」画面で「終了」をクリックします。

注意:

第6.4.5項「WebLogic Server WebCenterのドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareの最新のパッチ・セットなどの既知のパッチをMiddlewareホームに適用して、Oracle Fusion Middlewareを最新バージョンにしておいてください。

最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

6.4.4 管理サーバーのVIPの有効化

管理サーバーの仮想IPの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のアクティブ/パッシブ・トポロジ」を参照してください。

6.4.5 WebLogic Server WebCenterのドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行

MiddlewareホームのWebCenterディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとWebCenterポータル・コンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースでは、すべてのインスタンスを実行することをお薦めします。

1. 次のコマンドを使用して、ORACLE_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。

APPHOST1> ./config.sh

2. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

3. 「ドメイン・ソースの選択」画面で、「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。次の製品を選択します。
WebCenter Spacesを選択すると、Oracle WSMポリシー・マネージャが自動的に選択されます。

- Oracle WebCenter Spaces - 11.1.1.0

- Oracle WebCenterサービス・ポートレット - 11.1.1.0

- Oracle WebCenterページレット・プロデューサ - 11.1.1.0

- Oracle Enterprise Manager - 11.1.1.0

- Oracleポートレット・プロデューサ - 11.1.1.0

- Oracle WebCenterディスカッション・サーバー - 11.1.1.0

- Oracle WebCenterアクティビティ・グラフ・エンジン - 11.1.1.0

- Oracle WebCenterパーソナライズ - 11.1.1.0

- Oracle WebCenter Analyticsコレクタ - 11.1.1.0

- Oracle WSM Policy Manager

- Oracle JRF - 11.1.1.1

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

4. 「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。

5. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者が使用するユーザー名とパスワードを入力します。「次へ」をクリックします。

6. 「サーバーの起動モードおよびJDKの構成」画面で次を選択します。

- WebLogicドメインの起動モード: 「本番モード」を選択

- JDKの選択: 「Oracle JRockit 1.6.0_<バージョン>」を選択します。

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

7. 「JDBCデータ・ソースの構成」画面で、次の手順を実行します。

1. 画面の下部にある表で、すべてのコンポーネント・スキーマを選択します。

2. 「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択します。単一のデータベース構成の場合は、「変換しない」を選択します。

3. 画面に次のデータ・ソースが表示されていることを確認します。これらのスキーマにはカスタム接頭辞を指定します。表6-7は、データ・ソース、使用するスキーマ、およびスキーマが割り当てられている管理対象サーバーを一覧表示しています。
Oracle RACおよびMDSリポジトリでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照し、マルチ・データ・ソースの場合は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

表6-7 Oracle WebCenterポータルのデータ・ソース

データ・ソース

ユーザー名

WebCenterDS

wcha_webcenter

ActivitiesDS

wcha_activities

DiscussionsDS

wcha_discussions

PersonalizationDS

wcha_webcenter

PortletDS

wcha_portlet

Portlet-ServicesProducerDS

wcha_portlet

WC-ServicesProducerDS

wcha_webcenter

WebCenterMDS

wcha_mds

PersonalizationMDS

wcha_mds

mds-PageletProducerDS

wcha_mds

mds-ServicesProducerDS

wcha_mds

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

8. 「JDBCコンポーネント・スキーマの構成」画面で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
マルチ・データ・ソースの場合は、次のフィールドに値を入力します。

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

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

GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。

図6-7 GridLink RACコンポーネント・スキーマの構成

「図6-7 GridLink RACコンポーネント・スキーマの構成」の説明

1. ドライバとして、RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

2. データベースの「サービス名」を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(example.comなど)を含むRACサービス名を登録または追加することをお薦めします。

3. WebCenterポータル・スキーマのPrefix_Usernameを入力します。

4. スキーマの「パスワード」を入力します。

5. GridLinkデータ・ソースの場合は、SCANアドレスをリスナー・アドレス・フィールドに入力し、「ポート」フィールドにSCANポートを入力します。「ONSホスト」と「ポート」の各フィールドに、ONSホストおよびポート情報を入力します。

注意:

WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、SCANアドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、ネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。

マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。

6. 一度に1つのデータ・ソースを選択し、適切な詳細を追加することで、各マルチ・データ・ソース・スキーマを更新します。

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

9. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。(GridLinkデータ・ソースの場合は、ONS接続もテストされます。)「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常でない接続があった場合には、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続が正常になったら「次へ」をクリックします。

10. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

11. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: 第6.4.4項で使用したVIPアドレスを入力します。

- リスニング・ポート: 7001

- SSLリスニング・ポート: N/A

- SSL有効: 選択を解除

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

12. 「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。

表6-8 管理対象サーバーの構成

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

WC_Portlet1

APPHOST1のホスト名

8889

n/a

選択を解除

WC_Portlet2

APPHOST2のホスト名

8889

n/a

選択を解除

WC_Spaces1

APPHOST1のホスト名

8888

n/a

選択を解除

WC_Spaces2

APPHOST2のホスト名

8888

n/a

選択を解除

WC_Collaboration1

APPHOST1のホスト名

8890

n/a

選択を解除

WC_Collaboration2

APPHOST2のホスト名

8890

n/a

選択を解除

WC_Utilities1

APPHOST1のホスト名

8891

n/a

選択を解除

WC_Utilities2

APPHOST2のホスト名

8891

n/a

選択を解除

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

13. 「クラスタの構成」画面で、次のクラスタを追加します。
Portlet_Cluster

- 名前: Portlet_Cluster

- クラスタ・メッセージング・モード: unicast

- クラスタ・アドレス有効化: 空白のまま

Spaces_Cluster

- 名前: Spaces_Cluster

- クラスタ・メッセージング・モード: unicast

注意:

デフォルトでは、各WebCenterポータル・クラスタはユニキャストとして構成されています。WebCenterポータル・クラスタをマルチキャスト用に構成するには、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

- クラスタ・アドレス有効化: 空白のまま

Collaboration_Cluster

- 名前: Collaboration_Cluster

- クラスタ・メッセージング・モード: unicast

- クラスタ・アドレス有効化: 空白のまま

Utilities_Cluster

- 名前: Utilities_Cluster

- クラスタ・メッセージング・モード: unicast

- クラスタ・アドレス有効化: 空白のまま

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

14. 「サーバーのクラスタへの割当」画面で、クラスタに次のサーバーを割り当てます。

- Spaces_Cluster
WC_Spaces1

WC_Spaces2

- Portlet_Cluster
WC_Portlet1

WC_Portlet2

- Collaboration_Cluster
WC_Collaboration1

WC_Collaboration2

- Utilities_Cluster
WC_Utilities1

WC_Utilities2

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

15. 「マシンの構成」画面で、次の操作を行います。

- デフォルトとして表示される「LocalMachine」を削除します。

- 「UNIXマシン」タブをクリックし、次のマシンを追加します。

表6-9 マシンの構成

名前

ノード・マネージャのリスニング・アドレス

APPHOST1

APPHOST1のホスト名

APPHOST2

APPHOST2のホスト名

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

16. 「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

図6-8 「サーバーのマシンへの割当」画面

「図6-8 「サーバーのマシンへの割当」画面」の説明

- APPHOST1: WC_Spaces1、WC_Portlet1、WC_Collaboration1、WC_Utilities1

- APPHOST2: WC_Spaces2、WC_Portlet2、WC_Collaboration2、WC_Utilities2

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

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

18. ドメインの作成中画面で「完了」をクリックします。

6.4.6 APPHOST1での管理サーバーおよび管理対象サーバー用boot.propertiesの作成

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーおよび管理対象サーバーに対してboot.propertiesファイルを作成します。

管理サーバーに対しては、次の手順を実行します。

1. 次のディレクトリを作成します。

APPHOST1> mkdir -p MW_HOME/user_projects/domains/wc_domain/servers/AdminServer/security

2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminuser
password=password

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

WC_Spaces1管理対象サーバーに対して、次の手順を実行します。

1. 次のディレクトリを作成します。

APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wc_domain/servers/WC_Spaces1/security

2. テキスト・エディタを使用して、前の手順で作成したセキュリティ・ディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminuser
password=password

3. APPHOST1上のWC_Portlet1およびWC_Collaboration1管理対象サーバーに対してステップ2および3を繰り返します。

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

6.4.7 APPHOST1でのシステムの起動

この項では、APPHOST1でシステムを起動する手順について説明します。

6.4.7.1 APPHOST1での管理サーバーの起動

APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/wc_domain/bin

APPHOST1> ./startWebLogic.sh

6.4.7.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. ブラウザでhttp://VIP1:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. すべての管理対象サーバー(WC_Spaces1、WC_Spaces2など)がリストされていることを確認します。

4. すべてのクラスタがリストされていることを確認します。

5. Enterprise Manager(http://VIP1:7001/em)にアクセスできることを確認します。

6. EMコンソールに、手順2で使用したユーザー名とパスワードを使用してログインします。

6.4.7.3 APPHOST1およびAPPHOST2の管理サーバーおよび管理対象サーバーに対するホスト名の検証の無効化

この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。

ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。

ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールで、「サーバー」→「管理サーバー」を選択します。

2. 「SSL」→「詳細」を選択します。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. プロンプトが表示されたら、変更内容を保存してアクティブ化します。

5. 「ホスト名の検証」を「なし」に設定します。

6. 「WC_Spaces1」→「SSL」→「詳細」を選択します。

7. 「ホスト名の検証」を「なし」に設定します。

8. すべての管理対象サーバーに対してステップ6と7を繰り返します。

9. 管理サーバーとすべての管理対象サーバーを再起動します。

6.4.7.4 APPHOST1でのノード・マネージャの起動

APPHOST1でノード・マネージャを起動するには、次の手順を実行します。

1. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./setNMProps.sh

注意:

クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

2. ノード・マネージャを起動します。

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

6.4.8 APPHOST2でのWebLogic ServerおよびWebCenterポータルのインストール

APPHOST2に対し、WebLogic ServerとWebCenterポータルのインストール手順を繰り返します(第6.4.3.1項「Oracle WebLogic Serverのインストール」の手順から始めてください)。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。

6.4.9 pack/unpackユーティリティを使用したAPPHOST2へのドメイン構成の伝播

次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST2に伝播します。

1. 次のpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。

APPHOST1> cd WL_HOME/common/bin
APPHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/product/fmw/user_projects/domains/wc_domain/
-template=wc_domaintemplate.jar
-template_name=wc_domain_template

2. 次のコマンドをAPPHOST1で実行し、前の手順で作成したテンプレート・ファイルをAPPHOST2にコピーします。この例ではscpを使用しています。

APPHOST1> scp wc_domaintemplate.jar
APPHOST2:WL_HOME/common/bin

3. unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。

APPHOST2> cd WL_HOME/common/bin
APPHOST2> ./unpack.sh
-domain=ORACLE_BASE/product/fmw/user_projects/domains/wc_domain/
-template=wc_domaintemplate.jar

6.4.10 APPHOST2でのノード・マネージャの起動

APPHOST2でノード・マネージャを起動するには、第6.4.7.4項「APPHOST1でのノード・マネージャの起動」の手順をAPPHOST2で繰り返します。

6.4.11 Oracle HTTP Serverの管理サーバーおよびWebCenterポータル管理対象サーバーの構成

WebCenterポータル管理対象サーバーを含む管理サーバーへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定します。

1. OHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。

# Spaces
<Location /webcenter>
WebLogicCluster apphost1.com:8888,apphost2.com:8888
SetHandler weblogic-handler
</Location>

<Location /webcenterhelp>
WebLogicCluster apphost1.com:8888,apphost2.com:8888
SetHandler weblogic-handler
</Location>

<Location /rss>
WebLogicCluster apphost1.com:8888,apphost2.com:8888
SetHandler weblogic-handler
</Location>

<Location /rest>
WebLogicCluster apphost1.com:8888,apphost2.com:8888
SetHandler weblogic-handler
</Location>

# Pagelet Producer
<Location /pagelets>
WebLogicCluster apphost1.com:8889,apphost2.com:8889
SetHandler weblogic-handler
</Location>

# Activity Graph
# The WebLogicHost below should be set to the Host on which ActivityGraph is   running
<Location /activitygraph-engines>
WebLogicCluster apphost1.com:8891
SetHandler weblogic-handler
</Location>

# Portlet
<Location /portalTools>
WebLogicCluster apphost1.com:8889,apphost2.com:8889
SetHandler weblogic-handler
</Location>

<Location /wsrp-tools>
WebLogicCluster apphost1.com:8889,apphost2.com:8889
SetHandler weblogic-handler
</Location>

# SES Search
<Location /rsscrawl>
SetHandler weblogic-handler
WeblogicHost ses.example.com
WeblogicPort 7777
</Location>
<Location /sesUserAuth>
SetHandler weblogic-handler
WeblogicHost ses.example.com
WeblogicPort 7777
</Location>

# Personalization
<Location /wcps>
SetHandler weblogic-handle
WeblogicHost webcenter.example.com
WeblogicPort 8889
</Location>

# Discussions
<Location /owc_discussions>
WebLogicCluster apphost1.com:8890,apphost2.com:8890
SetHandler weblogic-handler
</Location>

#AdminServer and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
</Location>

2. WEBHOST1上のOracle HTTP Serverを再起動します。

WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1

6.4.11.1 Oracleページレット・プロデューサおよびSharepointの仮想ホストの構成

WebCenter Suiteには、/をWebコンテキスト・ルートとして使用する次の2つのアプリケーションが含まれています。

- Sharepointルート(WC_Spaces上にデプロイされる)

- ページレット・プロデューサ・ルート(WC_Portlet上にデプロイされる)

6.4.11.1.1 仮想ホストの要件

仮想ホストを使用しないSharepointルート・アプリケーションをOracle HTTP Server(OHS)を使用してルーティングするには、次のエントリを追加します。

<Location  />
SetHandler weblogic-handler
WebLogicHost webcenter.example.com
WebLogicPort 8889
</Location>

このエントリによって、明示的に定義されていないすべてのコンテキスト・ルートが捕捉されます。Sharepointにはマッピングが必要ですが、単一のOHSでは実行できません。このため、www.company1.comやwww.company2.comなどの複数のWebサイトを実行する単一システムである、仮想ホスト構成が必要となります。仮想ホストは、IPベース(Webサイトごとに一意のIPアドレス)または名前ベース(各IPアドレス上で実行される複数の名前)です。それらが同じ物理サーバー上で実行されていることはエンド・ユーザーにはわかりません。仮想ホストの詳細は、Apache HTTPサーバーのドキュメントを参照してください。

Oracle HTTP Serverの構成

次のエントリは、Sharepointルート用とページレット・プロデューサ・ルート用の2つの名前ベースのホストを追加します。

1. $WEBTIER_INSTANCE_HOME/config/OHS/<ohs>でOHS httpd.confをみつけます。

2. サンプルVirtualHost構成をみつけ、次のエントリを追加します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName webhost.example.com
</VirtualHost>

<VirtualHost *:7777>
ServerName webtier-spaces.example.com
<Location  />
SetHandler weblogic-handler
WebLogicCluster apphost1:8888,apphost2:8888
</Location>
<Location /webcenter>
Deny from all
</Location>
<Location /webcenterhelp>
Deny from all
</Location>
<Location /rest>
Deny from all
</Location>
</VirtualHost>

3. 新しい仮想ホストwebtier-pageletproducerおよびwebtier-spacesがDNSに追加されたことを確認します。

6.4.11.1.2 追加の構成

仮想ホスト・セットアップでは、仮想ホスト経由でルーティングされたアプリケーションを使用するための追加のプロパティを構成する必要があります。

Sharepoint

Oracle Access Manager 10gまたはOracle Access Manager 11gとの統合を含むシングル・サインオンの設定については、Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイドを参照してください。

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

URLを検証し、HTTP ServerからWebCenterポータル・クラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。

1. WebLogic Server管理コンソールから、WC_Spaces1、WC_Spaces2、WC_Portlet1およびWC_Portlet2を次のように起動します。

1. 次のURLの管理コンソールにアクセスします。
http://APHHOST1/console

2. 「サーバー」をクリックします。

3. 「制御」タブを開きます。

4. WC_Spaces1、WC_Spaces2、WC_Portlet1およびWC_Portlet2を選択します。

5. 「起動」をクリックします。

6. 次のURLを使用して、管理対象サーバーへの直接アクセスを検証します。
apphost1:8888/webcenter

apphost2:8888/webcenter

apphost1:8889/portalTools

apphost2:8889/portalTools

2. WC_Spaces2とWC_Portlet2の稼働中に、Oracle WebLogic Server管理コンソールからWC_Spaces1とWC_Portlet1を停止します。

3. 次のURLにアクセスして、適切な機能を検証します。

- WebHost1:7777/webcenter

- WebHost1:7777/portalTools

4. WebLogic Server管理コンソールからWC_Spaces1とWC_Portlet1を起動します。

5. WC_Spaces2とWC_Portlet2を停止します。

6. 次のURLにアクセスして、適切な機能を検証します。

- WebHost1:7777/webcenter

- WebHost1:7777/portalTools

6.4.12 APPHOST2への管理サーバーの手動フェイルオーバーの構成

高可用性のための管理サーバーの構成の詳細は、第12.4項「コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換」を参照してください。

6.4.13 Javaオブジェクト・キャッシュの構成

Javaオブジェクト・キャッシュ(JOC)は、WebCenter Spacesを実行しているすべてのサーバー間で構成する必要があります。このローカル・キャッシュは、Spacesアプリケーションのパフォーマンスを向上させるために提供されています。

Spacesアプリケーションを実行するすべてのサーバー間でのJavaオブジェクト・キャッシュの構成の説明は、第F.1項「Javaオブジェクト・キャッシュの構成」を参照してください。

6.4.14 MDSリポジトリに対する分散通知の構成

高可用性環境では、MDSリポジトリに対して分散通知を構成することをお薦めします。

MDSリポジトリに対する分散通知の構成の詳細は、付録G「MDSに対する分散通知の構成」を参照してください。

6.4.15 WebCenterポータルのレプリケーションの構成

この項の手順を使用して、WebCenterポータルのレプリケーションを構成します。

クラスタリング要件

アプリケーションをOracle WebLogicクラスタにデプロイする必要があります。これによって、アプリケーションの複数インスタンスに、レプリケーション・チャネルが自動的に確立されます。

注意:

ユニキャスト・クラスタでは、デフォルトのレプリケーション・チャネルは、各管理対象サーバーのリスニング・アドレスを使用して構成されています。そのため、リスニング・アドレスは、Anyでリスニングするように構成するのではなく、特定のIPアドレスまたはホスト名となるように構成する必要があります。

Oracle ADFのレプリケーション

WebCenterポータルはOracle ADFコンポーネントに依存しているため、Oracle ADFを適切に構成することが重要です。ステートフル・アプリケーションの場合には、アプリケーション・リソースの1つであるadf-config.xmlファイルに、次のタグが存在している必要があります。

<adfc:adf-controller-config><adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support></adfc:adf-controller-config>

WebCenterポータル・アプリケーションでは、これはデフォルトで有効になっています。

アプリケーションのレプリケーション

アプリケーションでレプリケーションが有効化されていることも必要です。Oracle WebLogic Serverでは、レプリケーションのために様々な種類の永続ストアを使用できます。永続ストアの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

WebCenterポータル・アプリケーションは、weblogic.xmlファイルの次の設定により、デフォルトで有効になっています。

<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

replicated_if_clustered設定は、スタンドアロン・アプリケーション環境のレプリケーションを無効にし、クラスタ環境内のメモリー内レプリケーションを使用します。

すべてのWebCenterポータル・アプリケーションがメモリー内レプリケーション用に構成されていることを確認します。

6.4.16 Analyticsの構成

Analyticsコレクタはすぐに使用できるよう構成されているため、必要な操作は、SpacesアプリケーションとAnalyticsコレクタ間の接続を構成することのみです。

1. 次のように、WLSTシェルを開きます。

ORACLE_HOME/common/bin/wlst.sh

2. 次のように、WLSサーバーに接続します。

connect('weblogic_admin_username', 'weblogic_admin_pwd', 'APPHOST1:8888')

ホストに接続し、Spaces Serverのポートに接続していることに注意してください。

3. 次のように、Analyticsコレクタ接続を作成し、それをデフォルトの接続にします。

createAnalyticsCollectorConnection(appName='webcenter', connectionName='HAConn1', isUnicast=1,
collectorHost='localhost', collectorPort=31314, isEnabled=1, timeout=30, default=1)

4. 次のように、行った変更をリストします。

listDefaultAnalyticsCollectorConnection(appName='webcenter')

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

アクティビティ・グラフ・エンジン・アプリケーションは、シングルトンとして実行する必要があります。クラスタ環境では、アクティビティ・グラフ・エンジン・アプリケーションのインスタンスは1つを除いてすべて無効化する必要があります。

アクティビティ・グラフ・エンジン・アプリケーションを無効化する手順は次のとおりです。

1. Oracle WebLogic管理コンソールにログインします。

2. WC_Spaces、WC_PortletおよびWC_Utilitiesを停止します。「デプロイメント」を選択します。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 次の各デプロイメントのターゲットを変更します。

- 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. デプロイメントのターゲットが、クラスタの一部/管理対象サーバーの1つのみになっていることを確認します。「OK」をクリックして変更を保存します。

4. すべての変更をアクティブ化をクリックします。

アクティビティ・グラフは1つのノードでのみ実行されているため、このノードが失われたり、管理対象サーバーが使用不可になると、アクティビティ・グラフは使用できなくなります。この場合、アクティビティ・グラフをアクティブな管理対象サーバー上にデプロイすることをお薦めします。このプロセスは、サービスの移行を構成することによって自動化できます。例については、第5.13.20項「WLS_SOAサーバーのサーバー移行の構成」を参照してください。

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

この手順にはユニキャスト・クラスタが必要です。

この手順を実行する前に、第6.4.21項「マルチキャストからユニキャストへのディスカッションの変換」の次の操作に関する説明を参照してください。

- マルチキャスト・クラスからユニキャスト・クラスタへの変換(必要に応じて)

- 既存のユニキャスト・クラスタが正しく設定されていることの確認

ディスカッション・サーバー管理コンソールを使用して、ディスカッション・サーバー・クラスタのすべてのメンバーが相互に通信できることを確認します。

1. 次の場所にあるクラスタの各メンバーにログインします。
http://<host>:<port>/owc_discussions/admin

2. 「キャッシュ設定」を開きます。

3. ページの下部にある「キャッシュ機能」セクションで、「クラスタリング」が「有効」に設定されていることを確認します。
ページの上部に、クラスタのすべてのメンバーが一覧表示されます。

4. 再度ページの下部に移動し、「キャッシュ・ツール」セクションで、クラスタワイドでのキャッシュのリセットおよびキャッシュのウォームアップ・タスクを実行します。クラスタのすべてのメンバーで、キャッシュのウォームアップ・タスクを繰り返します。

6.4.19 トポロジのスケーリング

WebCenterポータル・トポロジは、スケール・アウトまたはスケール・アップが可能です。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。

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

この場合は、WebCenterポータル・コンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードの共有記憶域には、MiddlewareホームとWebCenterディレクトリが格納されています。

新しいWebCenterポータル管理対象サーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。WebCenterポータルのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。1つのノード上における複数の管理対象サーバーの実行は、WC_SpacesサーバーおよびWC_Portletサーバーに対してのみサポートされています。

トポロジをスケール・アップするには、次の手順を実行します。

1. 管理コンソールを使用して、WC_Spaces1またはWC_Portlet1のクローンを作成し、新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。

1. 管理コンソールから「環境」→「サーバー」を選択します。

2. クローンを作成する管理対象サーバー(WC_Spaces1またはWC_Portlet1など)を選択します。

3. 「クローンの作成」を選択します。

新しい管理対象サーバーにSERVER_NAMEnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。

2. リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPを割り当てます。
この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。

3. この新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します(第6.4.13項「Javaオブジェクト・キャッシュの構成」を参照)。

4. Oracle HTTP Serverモジュールをクラスタの新しいメンバーで再構成します。第6.4.11項「Oracle HTTP Serverの管理サーバーおよびWebCenterポータル管理対象サーバーの構成」を参照してください。

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

トポロジのスケール・アウトでは、WebCenterポータル・アプリケーションを使用して構成されている新しい管理対象サーバーを新しいノードに追加します。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

- トポロジ内には、WebCenterポータル・アプリケーションを使用して構成されている管理対象サーバーを実行しているノードがすでに存在しています。

- 新しいノードは、WebLogic ServerおよびWebCenterポータル用の既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。packとunpackを実行して管理対象サーバー・ドメインを作成する必要がありますが、WebLogic ServerやWebCenterポータルのバイナリを新しい場所にインストールする必要はありません。

トポロジをスケール・アウトするには、次の手順を実行します。

1. 新しいノードで、WebCenterポータルのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

WCHOSTn> cd ORACLE_BASE/product/fmw/wc/
WCHOSTn> ./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. リスニング・アドレスをWCHOSTnに設定します。WCHOSTnは、新しいマシンのDNS名です。

7. 「保存」をクリックします。

8. 変更を保存およびアクティブ化します。

変更内容は、管理対象サーバーが再起動されるまでは有効になりません。

8. 次のようにpackコマンドをWCHOST1で実行し、テンプレート・パックを作成します。

WCHOST1> cd ORACLE_COMMON_HOME/common/bin
WCHOST1> ./pack.sh -managed=true -domain=MW_HOME/user_projects/
domains/wc_domain/ -template=webcenterdomaintemplateScale.jar
-template_name=webcenter_domain_templateScale

次のコマンドをWCHOST1で実行し、作成したテンプレート・ファイルをWCHOSTnにコピーします。

WCHOST1> scp wc_domaintemplateScale.jar oracle@WCHOSTn:/ ORACLE_BASE/product/
fmw/wc/common/bin

次のようにWCHOSTnでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。

WCHOSTn> cd ORACLE_BASE/product/fmw/wc/common/bin
WCHOSTn> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/
wc_domain/ -template=wc_domaintemplateScale.jar

9. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。

WCHOSTn> WL_HOME/server/bin/startNodeManager <new_node_ip>

10. これが新しいコラボレーション管理対象サーバーである場合は、第6.4.18項「ディスカッション・サーバー用クラスタリングの構成」の手順に従って新しいディスカッション・サーバーに対してクラスタ化が構成済であることを確認します。また、第6.4.21項「マルチキャストからユニキャストへのディスカッションの変換」の手順を、coherence.localhostパラメータに新しいホストのホスト名を使用して実行済であることも確認します。

11. これが新しいユーティリティ管理対象サーバーである場合は、第6.4.17項「アクティビティ・グラフの構成」の手順に従ってアクティビティ・グラフを無効化済であることを確認します。また、第6.4.16項「Analyticsの構成」の新しいAnalyticsコレクタの構成の手順に従っていることも確認します。

12. Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーをすべて停止します。

2. 新たに作成した管理対象サーバーが実行されていることを確認します。

3. 新たに作成した管理対象サーバー上のアプリケーションにアクセスします。アプリケーションが機能している必要があります。

6.4.20 WebCenterポータルの高可用性のトラブルシューティング

この項では、WebCenterポータルのトラブルシューティング手順について説明します。

6.4.20.1 WebCenterポータルのデプロイメントに関する問題のトラブルシューティング

WebCenterポータル・アプリケーションは、管理対象サーバーが最初に起動したときにデプロイされるため、最初にOracle WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメントがすべて成功したことを確認します。

左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。

アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME/servers/SERVER_NAME/logsディレクトリに格納されています。一般的な問題には、次のようなものがあります。

- データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。

- 適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。

6.4.20.2 WebCenterポータルのレプリケーションおよびフェイルオーバーに関する問題のトラブルシューティング

フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります:

- ウィンドウが閉じたか、または状態がリセットされた可能性がある。

- 画面のリセットが必要になった可能性がある。

- アプリケーションがログオン画面にリダイレクトしている可能性がある。

状態のレプリケーションに関する問題のトラブルシューティングおよび診断を行う手順は、次のとおりです。

1. これがレプリケーションに関する既知の問題でないことを確認します。
予想される動作については、第6.3.2.8項「アプリケーションのフェイルオーバーで予想される動作」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。

2. ロード・バランサの設定を確認します。
レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverのハードウェア・ロード・バランサの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

3. クラスタのステータスを確認します。
クラスタのコンテキスト内でレプリケーションが発生します。フェイルオーバーが成功するには、クラスタの正常なメンバーが、ほかに少なくとも1つ使用可能である必要があります。クラスタのステータスは、次の2種類の方法のどちらかで確認できます。

- Oracle WebLogic Server管理コンソールを使用してクラスタのステータスを確認します。左側のペインで「サーバー」をクリックします。クラスタ内のすべてのサーバーの状態を確認します。

- weblogic.Adminユーティリティを使用してクラスタのステータスを確認します。weblogic.Adminコマンドは、特定のクラスタ内のすべてのサーバーの状態を問い合せるときに使用できます。例:

$ java weblogic.Admin -url Adminhost:7001 -username <username> -password
<password>  CLUSTERSTATE -clustername Spaces_Cluster

次のようなメッセージが返されます。

There are 2 server(s) in cluster: Spaces_Cluster
The alive servers and their respective states are listed below:
WC_Spaces1---RUNNING
WC_Spaces2---RUNNING

4. クラスタ通信を確認します。
クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。

- ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。
個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。

- マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTestを実行して、マルチキャストが正しく構成されていることを確認します。例:

$ java utils.MulticastTest -H

5. アプリケーションの構成を確認します。
WebCenterポータル・アプリケーションは、デフォルトで正しく構成されています。ユーザー・アプリケーションに対するメモリー内のレプリケーションは、weblogic.xmlで適切な構成がなされている場合にのみ行われます。

<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

replicatedのpersistent-store-typeも受け入れられます。

6. デバッグを有効にします。
サーバー・ログを調べて、管理対象サーバーの起動時に異常なメッセージがないか確認します。この確認は、管理対象サーバーがクラスタの他のメンバーを見つけられない場合に、特に必要です。サーバー・ログは、DOMAIN_HOME/servers/SERVER_NAME/logsディレクトリに格納されています。

詳細な診断を行うには、DebugCluster、DebugClusterAnnouncements、DebugFailOver、DebugReplication、DebugReplicationDetailsの各フラグを有効にします。各フラグは、weblogic.Adminユーティリティを使用して次のように有効にできます。

$ java weblogic.Admin -url Adminhost:7001 -username <username> -password
<password> SET -type ServerDebug -property DebugCluster true

6.4.20.3 ポリシーの変更が失われた場合のトラブルシューティング

ポリシーは、変数oracle.security.jps.ldap.policystore.refresh.intervalによってjps-config.xmlに定義されている間隔でリフレッシュされます。デフォルトでは、この間隔は10分です。サーバーが失われた場合、リクエストは、元のポリシーがキャッシュされている、クラスタ内の別のサーバーにルーティングされます。前回のリフレッシュ以後に発生した最近のポリシーの変更が失われたように見えることがあります。たとえば、フェイルオーバーの直前に作成されたロールは、使用不可と表示される場合があります。

このような状況でも、ポリシーは、バックエンド・ポリシー・ストアにあります。キャッシュをリフレッシュして、ポリシー情報をリストアします。数分後に再試行するか、またはアプリケーションにログインしてからログアウトして、ポリシー・キャッシュのリフレッシュを強制実行します。

6.4.20.4 JOC構成のトラブルシューティング

OWSMやSpacesアプリケーション管理対象サーバーなど、Javaオブジェクト・キャッシュを使用する管理対象サーバーを起動しようとした場合、起動に失敗し、ログに次のエラーが記録されます。

J2EE JOC-058 distributed cache initialization failure
J2EE JOC-043 base exception:
J2EE JOC-803 unexpected EOF during read.

別のプロセスが、JOCが取得を試みている同じポートを使用しています。この問題を解決するには、そのプロセスを停止するか、推奨ポート範囲内の別のポートを使用するように、このクラスタのJOCを再構成します。

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

ディスカッションをマルチキャストからユニキャストに変換する手順は次のとおりです。

ステップ1: 起動パラメータの追加

関連する起動パラメータの追加手順は次のとおりです。

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

Host1は、WC_Collaboration1が実行されている場所です。

WebCenter Coherenceの通信に8088以外のポートを使用するには、前述の例の引数-Dtangosol.coherence.wka1.portおよび-Dtangosol.coherence.wka2.portを使用して、別のポート番号を指定します。

3. WC_Collaboration2に対してステップ1と2を繰り返します。ただし、ローカルホスト・パラメータにはHost2に設定します。

4. WC_Collaborationサーバーを再起動します。

ステップ2: 変更の検証

変更を検証する手順は次のとおりです。

1. ディスカッション・フォーラムの管理コンソール(http://<ホスト>:<ポート>/owc_discussions/admin.)にログインします。

2. 左ペインで「キャッシュ設定」を選択します。

3. 画面の下部で、「クラスタリング」が「有効」に設定されていることを確認します。

4. クラスタのすべてのメンバーに対して、ステップ1から3を繰り返します。
サーバーがクラスタに参加すると、それらのサーバーが画面の上部に表示されます。

6.5 WebCenterポータル・アプリケーションの高可用性の構成

WebCenterポータル・アプリケーションは、必須ライブラリをプロビジョニング済のサーバーおよびクラスタにデプロイされます。このプロビジョニングは、既存のWebCenterポータル・ドメインにドメイン・テンプレートを適用することによって行われます。

拡張は、ドメインごとに一度のみ実行できます。したがって、どのWebCenterポータル・アプリケーション・サーバーも、一度に作成するか、または既存のWebCenterポータル・アプリケーション・サーバーのクローンとして作成する必要があります。

6.5.1 WebCenterポータル・アプリケーションに対するクラスタの構成

WebCenterポータル・アプリケーションをデプロイするためにクラスタを構成する手順は、次のとおりです。

1. 次のコマンドを使用して、ORACLE_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。

APPHOST1> ./config.sh

2. 「ようこそ」画面で「既存のWebLogicドメインの拡張」を選択します。「次へ」をクリックします。

3. 次の画面で、Weblogicドメイン・ディレクトリを選択します。

4. 次の画面で、「既存の拡張テンプレートを使用してドメインを拡張する」を選択します。

5. 独自のFrameworkアプリケーションを作成するのか、ポートレット・プロデューサ・アプリケーションを作成するのかに応じて、次の2つのテンプレートのいずれかを選択します。

- Frameworkアプリケーションの場合:

$WC_ORACLE_HOME/common/templates/applications/oracle.wc_custom_portal_
template_11.1.1.jar

- ポートレット・プロデューサ・アプリケーションの場合:

$WC_ORACLE_HOME/common/templates/applications/oracle.wc_custom_services_
producer_template_11.1.1.jar

6. すべてのデータ・ソースを選択し、「RACデータソース」チェック・ボックスを選択することにより、新しいデータ・ソース(カスタム・ポータル・アクティビティ、カスタム・ポータルWebCenter、カスタム・ポータルMDS)をOracle RACとして構成します。アプリケーションでは既存のスキーマを使用します。

7. データベース接続情報を入力し、次に、データ・ソースのステータスをチェックします。

8. オプション構成画面で、「管理対象サーバー、クラスタ、およびマシン」を選択します。

9. 「管理対象サーバー」画面で、次のように実行します。

- 手順5で、custom_portalテンプレートを選択した場合は、管理対象サーバーの名前をWC_CustomPortalからWC_CustomPortal_Cluster1に変更します。custom_services_producer_templateを選択した場合は、管理対象サーバーの名前をWC_CustomServicesProducerからWC_CustomServicesProducer_Cluster1に変更します。

- 「追加」をクリックして新しい管理対象サーバーを作成し、そのサーバーにWC_CustomPortal_Cluster2と名前を付けます。リスニング・ポートをWC_CustomPortal_Cluster1のリスニング・ポートと同じになるよう設定します。

10. 「クラスタの構成」画面で、クラスタWC_CustomServicesProducer_Cluster1を追加します。

11. 「サーバーのクラスタへの割当」画面で、新しく作成した2つのサーバーをクラスタに追加します。

12. 「サーバーのマシンへの割当」画面で、2つのサーバーをそれぞれ別のマシンに配置します。

13. 「拡張」→「完了」をクリックし、ドメインを拡張します。

Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを起動し、WebCenterポータル・アプリケーションをデプロイできるようになりました。これらのWebCenterポータル・アプリケーションは、管理対象サーバーのターゲットではなく、クラスタのターゲットにデプロイします。

6.5.2 WebCenterポータル・アプリケーション・サーバーの追加

新しいサーバーは、既存のサーバーのクローニングによって拡張されているドメインにのみ追加できます。

1. Oracle WebLogic Server管理コンソール(http://APPHOST1:7001/console)にアクセスし、ログインします。

2. 「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択し、「サーバーのサマリー」ページに既存の管理対象サーバーをすべて表示します。

3. いずれかのカスタム管理対象サーバーを選択します。「クローンの作成」をクリックします。

4. サービス名(WC_CustomPortal3など)を入力します。この新しいサーバーを配置するリスニング・アドレスとポートを設定します。

サーバーが自動的にクラスタ(WC_CustomPortalClusterなど)のメンバーになります。

6.5.3 MDSリポジトリに対する分散通知の構成

高可用性WebCenterポータル・アプリケーションの場合は、MDSリポジトリに対して分散通知を構成することをお薦めします。MDSリポジトリに対する分散通知の構成の詳細は、付録G「MDSに対する分散通知の構成」を参照してください。

7 Oracle Data Integratorの高可用性

Oracle Data Integratorは、データ統合プロセスを設計、デプロイおよび管理するコンポーネントの完全なセットを提供します。データ統合プロセスでは、ELT(抽出、ロード、変換)アプローチを使用して、データをソース・データ・サーバーからターゲット・データ・サーバーに移行して変換します。ELTは、ソース・データ・サーバーとターゲット・データ・サーバーにすべての変換を委任することで、変換エンジンの必要性をなくすアプローチです。

この章では、Oracle Data Integratorコンポーネントについて高可用性の観点から説明します。この章の各項では、高可用性を備えたデプロイメントの設計に重要な単一インスタンスの概念について概要を説明します。

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

- 第7.1項「Oracle Data Integratorの概要」

- 第7.2項「Oracle Data Integratorの単一インスタンスの特性」

- 第7.3項「Oracle Data Integratorの高可用性とフェイルオーバーに関する考慮事項」

- 第7.4項「Oracle Data Integratorの高可用性の構成」

7.1 Oracle Data Integratorの概要

図7-1に示すように、Oracle Data Integratorは、データ統合プロセスを開発、デプロイおよび監視するための包括的な機能セットを提供します。Oracle Data Integratorは、Javaコンポーネントに基づく、統一されたランタイム・アーキテクチャを提供します。

ランタイム・アーキテクチャは、次のもので構成されています。

- リポジトリ: リポジトリには、データ統合のデザインタイム・オブジェクト、ランタイム・オブジェクト(実行するデータ統合シナリオ)、およびこれらのデザインタイム・オブジェクトおよびランタイム・オブジェクトの実行インスタンスに対応するセッションが格納されます。

- ランタイム・エージェント: セッションを実行するスタンドアロン・エージェントまたはJava EEエージェントで、アプリケーション・サーバーにデプロイされています。エージェントは、データ統合セッションの処理時に、リポジトリだけでなく、ソース・データ・サーバーとターゲット・データ・サーバーにも接続します。エージェントは、サード・パーティのSOA対応アプリケーションからシナリオの実行を開始および監視するためのWebサービスも提供します。

- Oracle Data Integratorコンソール: これは、ユーザーがリポジトリに格納されているアーティファクトを参照、監視および管理できるようにするWebアプリケーションです。ランタイム・エージェントでのシナリオの起動など、ランタイム操作も実行します。

7.2 Oracle Data Integratorの単一インスタンスの特性

図7-1は、Oracle Data Integratorの単一インスタンスのアーキテクチャを示しています。

図7-1 Oracle Data Integratorの単一インスタンス・アーキテクチャ

「図7-1 Oracle Data Integratorの単一インスタンス・アーキテクチャ」の説明

Oracle Data Integratorのランタイム・エージェントは、統合プロセスを管理します。Oracle Data Integratorエージェントは、リポジトリに格納されているシナリオに従って統合ジョブを実行する、本番構成にデプロイされたコンポーネントです。

Oracle Data Integratorエージェントは、各シナリオ実行インスタンスをセッションとして処理します。各セッションは、エージェントのJavaプロセスの別のスレッドとしてエージェント内に存在します。

エージェントには、実行するセッションに関する非常に基本的な情報が格納されます。ほとんどのセッション・データは、リポジトリに格納されます。エージェントでシナリオが実行される際、エージェントは、リポジトリ内にこのシナリオのインスタンスに対応するセッションを作成します。エージェントは、リポジトリからこのセッションの各タスクを読み取り、それを処理して、リポジトリに結果(リターン・コード、メッセージ、および処理にかかった時間や処理された行の数などのタスク・メトリック)を書き込みます。

リポジトリは、2つのデータベース・スキーマで構成されています。1つはマスター・リポジトリを含み、もう1つは作業リポジトリを含みます。マスター・リポジトリには、トポロジとセキュリティに関連するすべての情報(ソース・データ・サーバー定義、ターゲット・データ・サーバー定義、ユーザーの資格証明など)が含まれます。作業リポジトリには、開発データおよびランタイム・データ(セッションやシナリオなど)が含まれます。マスター・リポジトリには、作業リポジトリへの接続情報も含まれます。作業リポジトリに接続するには、エージェントは、まずマスター・リポジトリに接続し、Oracle Data Integratorユーザーの資格証明をチェックして、作業リポジトリの接続情報を読み取ってから、作業リポジトリに接続します。通常のトポロジには、1つのマスター・リポジトリと、場合によっては複数の作業リポジトリ(テスト用と本番用など)が含まれます。

エージェントでセッションを開始する方法は次のとおりです。

- 別のOracle Data Integratorコンポーネント(エージェントやOracle Data Integrator Studioなど)からHTTP経由で

- エージェントのWebサービス・インタフェースから

- 外部スケジューラまたはコマンドラインから

- Agent Invocation SDKを使用してJavaプログラムから

エージェントは常に、マスター・リポジトリにアタッチされます。これは、起動時にこのマスター・リポジトリに接続し、このマスターにアタッチされた作業リポジトリのいずれかでセッションを開始できます。また、スケジューラとしても機能します。起動時、エージェントは、複数の作業リポジトリからそのエージェント用に定義されているスケジュールを読み取り、このスケジューリング情報を格納します。エージェントは、適切な作業リポジトリでこのメモリー内スケジュールからセッションを開始できます。

エージェントは、リモートのシナリオ起動(HTTP経由)を通じて、またはロード・バランシング機能によって相互に対話できます。ロード・バランシングでは、親/子エージェントの階層を定義できます。この階層内で、親エージェントは、自分のセッションの処理を各自の子エージェントに委任できます。

エージェントは、Java EEエージェントまたはスタンドアロン・エージェントとして提供されるJavaプログラムです。Java EEエージェントは、同じJVM内の他のWebアプリケーションとともに、Java EEアプリケーション・サーバーにデプロイ可能なWebアプリケーションです。このエージェントは、このサーバーのデータ・ソースを使用して、ソース、ターゲットおよびリポジトリ・データベースに接続できます。

スタンドアロン・エージェントは、コマンドライン・インタフェースから起動されるスタンドアロンJavaプロセスとして提供されます。このスタンドアロン・エージェントは、Java EEエージェントに似ていますが、軽量コンテナに組み込まれます。主な違いは、スタンドアロン・エージェントは、Java EEエージェントとは異なり、直接JDBC接続のみを使用してソース・データ・サーバーとターゲット・データ・サーバーに接続できるというところです。

7.2.1 Oracle Data Integratorセッションのライフサイクルとリカバリ

ランタイム・エージェントに実行リクエストが到着すると、エージェントは、マスター・リポジトリに接続してユーザーの資格証明をチェックしてから、作業リポジトリに接続してセッションとそのすべてのタスクを作成し、それらをwaitingとしてマークします。次に、このセッションで使用されるすべてのデータ・サーバーへの接続を作成します。

実行が開始されると、エージェントは、作業リポジトリ内の最初の実行対象タスクを読み取り、セッションとこのタスクの両方をrunningとしてマークします。このタスクは、データ・サーバーまたはオペレーティング・システムで操作を開始できます。タスクが完了すると、エージェントは、このタスクの実行結果を作業リポジトリに書き込み、それを終了済の状態(Done、WarningまたはError)に移動します。エラーについてはODIパッケージで処理でき、エラーが必ずしもセッションを停止させるわけではないことに注意してください。管理対象外のエラーまたは最終手順に達したためにセッションが完了すると、エージェントは、そのセッションを終了済の状態に移動し、すべての接続を解放します。この時点で、セッションは終了します。

7.2.1.1 セッションの中断

セッションは、次の場合に中断することがあります。

- ユーザーがエージェントにセッションの停止をリクエストしたとき。

- 管理者によってエージェントが停止されたとき。選択されたエージェント停止モードに応じて、このエージェントのすべてのセッションは停止されます。

- エージェントまたはリポジトリでクリティカル・イベントが発生したとき。

ユーザーまたは管理者のアクションによって停止されたすべてのセッションは、エラー状態に移動され、「停止済」としてマークされます。

エージェントまたはリポジトリで障害が発生した場合、正常に停止できなかったセッションは、リポジトリ内で実行状態として表示されます。これらのセッションは、実行中としてマークされてはいますが、どのエージェントによっても処理されないため、失効セッションです。エージェントが再起動され、失効セッションがリポジトリ内でこのエージェントによる実行状態を正しく反映していないことが検出されると、これらのセッションは自動的にエラー状態に移動されます。

7.2.1.2 セッションのリカバリ

Oracle Data Integratorは、ソース・データ・サーバーおよびターゲット・データ・サーバーとの対話時にJDBCトランザクションを使用し、セッションがエラー状態で終了した場合、オープン・トランザクションの状態は永続化されません。適切な再起動ポイントは、未完了のトランザクションを起動したタスクです。そのような再起動ポイントが特定できない場合、エラー状態にある既存のセッションを再開するのではなく、シナリオを実行することで新たなセッションを開始することをお薦めします。

デフォルトで、セッションは、実行に失敗した最後のタスク(通常は、エラー状態または待機状態のタスク)から再開されます。既存のステージング表での処理を続行し、長い時間のかかるロード・フェーズの再実行を回避するために、セッションを再開する必要がある場合もあります。その場合、ユーザーは、KM固有のトランザクション管理を考慮に入れる必要があります。一般的なガイドラインとしては、ロード・タスクで障害が発生した場合、失敗したロード・タスクから再起動できます。統合フェーズで障害が発生した場合、ターゲットへの統合はトランザクション内で行われるため、最初の統合タスクから再起動します。このガイドラインは、一度に1つのインタフェースにのみ適用されます。複数のインタフェースが連鎖しており、最後のインタフェースのみがコミットされている場合、トランザクションは複数のインタフェースにわたって実行されるため、それらの複数のインタフェースをすべて再起動する必要があります。

特定のタスクまたは手順から再起動する手順は次のとおりです。

1. オペレータ・ナビゲータで、このタスクまたは手順に移動し、それを編集して、「待機中」状態に切り替えます。

2. 「オペレータ」ツリー・ビューで、これ以降のすべてのタスクおよび手順を「待機中」状態に設定します。

3. セッションを右クリックし、「再起動」をクリックします。

セッションが、待機状態の最初のタスクから再開されます。

7.2.2 エージェントの起動とシャットダウンのサイクル

図7-2は、エージェントの起動のサイクルを示しています。

図7-2 Oracle Data Integratorエージェントの起動のサイクル

「図7-2 Oracle Data Integratorエージェントの起動のサイクル」の説明

Oracle Data Integratorエージェントの起動時、まず、マスター・リポジトリの接続情報を含む構成を読み取ります。次に、エージェントは、このマスター・リポジトリにアタッチされたそれぞれの作業リポジトリに接続し、失効セッションを削除します。失効セッションは、この特定のエージェントで実行中であると、作業リポジトリで誤って示されているセッションです。失効セッションは、これらのセッションを正常に停止できずにエージェントが停止されたことで生じる場合があります。エージェントが再起動されると、そのセッションは、失効セッションとして識別され、エラー状態に移動されます。

その時点で、エージェントは、各作業リポジトリで使用可能なスケジュールを取得して計算できます。このフェーズが終了すると、エージェントは、受信セッション・リクエストを待機してそれらの処理を開始し、さらに、スケジュールに基づいてセッションを開始できます。

7.2.3 Oracle Data Integratorの外部依存性

Oracle Data Integratorは、Oracle Data Integratorのマスター・リポジトリおよび作業リポジトリ・データベース・スキーマに依存します。

拡張機能が使用されている場合、次のような他の依存性が存在する可能性があります。

- 他のOracle Data Integratorエージェント: ロード・バランシング機能が構成されており、エージェントがセッションの実行をその子エージェントに委任する必要がある場合。

- このエージェントのマスター・リポジトリに対して外部パスワード記憶域が有効な場合、エージェントは、セッションの実行時にソース・データ・サーバーとターゲット・データ・サーバーに接続するためのパスワードを取得する際、資格証明ストアに依存します。

- このエージェントのマスター・リポジトリに対して外部認証が有効な場合、ラインタイム・エージェントとOracle Data Integratorコンソールは、Oracle Data Integratorのユーザー・アカウントを格納するアイデンティティ・ストア・サービスに依存します。

Oracle Data Integratorシステムが適切に起動し、実行されるためには、これらのコンポーネントが使用可能である必要があります。

7.2.4 Oracle Data Integratorの起動およびシャットダウン・プロセス

Oracle Data Integrator Java EEエージェントがデプロイされているOracle WebLogic管理対象サーバーが起動するたびに、Oracle Data Integrator Java EEエージェント・アプリケーションがデフォルトで起動します。通常は、Oracle Data Integratorやそのコンポーネント自体を停止する必要はありません。一部の操作では、Oracle Data Integratorが実行されているOracle WebLogic管理対象サーバーの再起動が必要な場合があります。アプリケーションの停止が必要なのは、一部のパッチを適用するときのみです。

管理コンソールを使用すると、ステータスを確認したり、Oracle WebLogic Serverを起動および停止したりできます。アプリケーションの制御に、WebLogic Server WLSTのコマンドラインも使用できます。Oracle Enterprise Manager Fusion Middleware Controlを使用すると、Oracle Data Integratorの多数の操作と構成を行えるだけでなく、ステータスを監視することもできます。

7.2.5 Oracle Data Integratorの構成アーティファクト

この項では、Oracle Data Integratorの構成アーティファクトについて説明します。

7.2.5.1 Java EEエージェントの構成

Java EEエージェントの構成パラメータは、エージェント・アプリケーションと、エージェントがアタッチされているマスター・リポジトリの両方に格納されます。

図7-3に示すように、マスター・リポジトリに格納されたエージェント構成は、Oracle Data Integrator Studioから編集でき、次の主要なパラメータを含みます。

- ホスト

- ポート

- Webアプリケーション・コンテキスト

図7-3 Oracle Data Integrator Studioに表示されるマスター・リポジトリのエージェント構成

「図7-3 Oracle Data Integrator Studioに表示されるマスター・リポジトリのエージェント構成」の説明

この情報と有効な資格証明を使用して、リポジトリに接続するコンポーネントは、<host>:<port>/<web_application_context> URL上のこのエージェントから実行をリクエストできます。「Webアプリケーション・コンテキスト」に別の値を指定することで、同じホストとポートのペアで複数のエージェントを起動できます。

この情報に加えて、マスター・リポジトリには次の情報も含まれます。

- ソース、ターゲットおよびリポジトリ・データベース・ホストに接続するための、このエージェントによって使用されるデータ・ソース名。

- ロード・バランシング機能のためのエージェントの階層。

Oracle Data Integrator Studioは、特定のエージェントのOracle WebLogicテンプレートを生成する機能を提供します。このテンプレートには、エージェントのバイナリ、構成およびデータ・ソース定義が含まれます。Oracle WebLogic管理者は、これらのテンプレートを使用して、クラスタに事前構成されたエージェントをデプロイできます。

データ・ソースの作成や変更など、コンテナ・レベルの他の構成オプションは、WebLogic Serverのドメイン構成として使用可能であり、Oracle WebLogic Serverのコア・インフラストラクチャにより、Oracle WebLogic Serverのクラスタ上で同期化されます。

Java EEエージェントのデプロイメント・オプションの詳細は、『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の「トポロジの設定」を参照してください。

7.2.5.2 スタンドアロン・エージェント構成

スタンドアロン・エージェントの構成パラメータは、スタンドアロン・エージェント構成ファイルと、このエージェントがアタッチされているマスター・リポジトリの両方に格納されます。エージェント構成のリポジトリの部分は、Java EEエージェントに似ています。

エージェント構成は、構成ファイルに格納されているか、インストール・フォルダに格納されているかに応じて異なります。

- UNIXの場合: ODI_HOME/oracledi/agent/bin/odiparams.sh

- Windowsの場合: ODI_HOME/oracledi/agent/bin/odiparams.bat

この構成ファイルには、スタンドアロン・エージェント構成の一部として手動で編集する必要のある次のパラメータが含まれます。

- マスター・リポジトリに接続するためのJDBC接続情報

- ODIスーパーバイザ・ユーザーおよび暗号化されたパスワード

スタンドアロン・モードで起動されたエージェントは、その起動に使用されたコマンドラインでも構成されます。このコマンドラインには次のパラメータが含まれます。

- リスニング・ポート

- エージェント名

- トレース・レベル

このエージェントに実行リクエストを送信するコンポーネントは、<host>:<port>/oraclediagentというURLで送信することになります。デプロイ済のスタンドアロン・アプリケーション名はoraclediagentに設定されることに注意してください。結果として、単一のホスト上で複数のスタンドアロン・エージェントを起動するには、別々のポートを使用する必要があります。

エージェントの構成の詳細は、『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の「トポロジの設定」を参照してください。

7.2.5.3 Oracle Data Integratorコンソールの構成

Oracle Data Integratorコンソールの構成は、このWebアプリケーションを使用して参照可能なマスター・リポジトリと作業リポジトリへの接続定義で構成されます。

接続のリストは、次のディレクトリにあるrepositories.xmlファイルに格納されます。

user_projects/domains/domainName/config/oracledi

接続は、Oracle Data Integratorコンソールの管理ページで追加、編集または削除できます。

注意:

Oracle Data Integratorコンソールは、ドメイン内のOracle Data Integratorターゲットを検出するためのEnterprise Managerのエントリ・ポイントとして使用されます。検出プロセスは、次のような方法で動作します。Enterprise ManagerがOracle Data Integratorコンソールを識別します。Oracle Data Integratorコンソールの構成を使用して、Enterprise Managerは、マスター・リポジトリと作業リポジトリ、ドメイン内のおよびランタイム・エージェントを識別します。

7.2.5.4 Oracle Data Integratorのログの場所と構成

この項では、Oracle Data Integratorのログの場所と構成について説明します。

7.2.5.4.1 Oracle Data Integratorのセッション・ログ

Oracle Data Integratorのセッション実行ログは、セッションが起動される対象となった作業リポジトリに格納されます。このセッションには、処理された行の数や実行済コードなど、Oracle Data Integratorのセッションの詳細が表示されます。Oracle Data Integrator Studioのオペレータ・ナビゲータ(「セッション・リスト」アコーディオン)、またはOracle Data Integratorコンソールの「参照」タブ(「ランタイム」>「セッション」)からログを表示します。

7.2.5.4.2 Java EEエージェントのログ・ファイル

Oracle Data Integrator Java EEエージェントにより実行される操作は、エージェント・アプリケーションが実行されているOracle WebLogic管理対象サーバーによってログに記録されます。これらのログは、次の場所にあります。

DOMAIN_HOME/servers/WLS_ServerName/logs/oracledi/odiagent.log

別のOracle WebLogic Server管理対象サーバーのログ・ファイルも、管理コンソールで使用できます。ログを確認するには、URL: admin_server_host:port/consoleを使用して管理コンソールにアクセスします。「診断-ログ・ファイル」をクリックします。

Oracle Data Integratorが実行されているOracle WebLogic管理対象サーバーの出力を確認することも重要です。この情報は次の場所に格納されています。

DOMAIN_HOME/servers/WLS_ServerName/logs/WLS_ServerName.out

さらに、管理対象サーバーのログ・ディレクトリに診断ログが作成されます。このログの粒度とロギング・プロパティは、次のファイルで変更できます。

DOMAIN_HOME/config/fmwconfig/logging/oraclediagent-logging.xml

7.2.5.4.3 スタンドアロン・エージェントのログ・ファイル

Oracle Data Integratorスタンドアロン・エージェントにより実行される操作は、スタンドアロン・エージェントを実行している軽量コンテナによってログに記録されます。デフォルトでは、ログは、コンソールおよびODI_HOME/oracledi/log/フォルダでトレースされます。

ロギング方法およびロギング・レベルは、ODI_HOME/oracledi/agent/bin/ODI-logging-config.xmlファイルを編集することで構成できます。

7.2.5.4.4 Oracle Data Integratorコンソールのログ・ファイル

Oracle Data Integratorコンソールのロギング操作は、第7.2.5.4.2項「Java EEエージェントのログ・ファイル」で説明されているJava EEエージェントのログ・ファイルと同様に、エージェント・アプリケーションが実行されているOracle WebLogic管理対象サーバーによってログに記録されます。

7.3 Oracle Data Integratorの高可用性とフェイルオーバーに関する考慮事項

この項では、Oracle Data Integratorの高可用性とフェイルオーバーに関する考慮事項について説明します。

7.3.1 Oracle Data Integratorのクラスタ・デプロイメント

図7-4は、2つのOracle WebLogicサーバーで2ノードのOracle Data Integratorクラスタが実行されている様子を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。

図7-4 Oracle Data Integratorの高可用性アーキテクチャ

「図7-4 Oracle Data Integratorの高可用性アーキテクチャ」の説明

この構成の主要な特性は、次のとおりです。

- Oracle Data Integratorアプリケーションは、クラスタ化された2つのWebLogic Serverの管理対象サーバー上で実行されます。WebLogic Serverクラスタは、データ・ソースなど、Oracle Data Integratorで使用されるWebLogic Serverの共通アーティファクトの構成を同期化します。

- スケジュールが重複して処理されることを回避するため、これらのエージェントのうち1つのみがスケジューラとして動作します。Coherenceキャッシュは、スケジューラ・サービスの一意性と移行を処理するために使用されます。
エージェントは、フェイルオーバー・スケジュール機能を提供します。たとえば、スケジューラが午前9時に起動し、4時間ごとの毎正時にジョブXが実行されるサイクルが設定されており、午前9時55分にエージェントに障害が発生したとします。この場合、サイクル内にあったジョブXは計算を実行し、続行されます。ただし、単一のジョブが午前9時に開始されるようにスケジュールされている場合、午前8時59分にエージェントに障害が発生し、午前9時1分にリカバリされると、午前9時にスケジュールされていたジョブは実行されません。

- クラスタ内のOracle Data Integratorエージェントへのリクエストは、ロード・バランサまたはHTTPプロキシ・サーバー経由でルーティングされる必要があります。クライアントは、このフロント・サーバーのアドレスを使用して、クラスタ内の任意のOracle Data Integratorサーバーに透過的に接続します。このアドレスは、マスター・リポジトリ内のエージェント定義で指定されている必要があります。スケジューラ・シングルトンは、スケジュール済のすべてのセッション起動リクエストをこのアドレスにルーティングし、リクエストはクラスタにロード・バランシングされるようになります。

- Oracle Data Integratorのマスター・リポジトリおよび作業リポジトリのデータベースは、データベースの障害から保護するために、Oracle Real Application Cluster(Oracle RAC)で構成されます。データベース・インスタンスの障害が発生すると、Oracle Data Integratorコンポーネントは、再接続と操作の再試行を適切に実行します。

7.3.2 OPMNを使用したスタンドアロン・エージェントの高可用性

スタンドアロン・エージェントは、コマンドライン・インタフェースから起動されるスタンドアロンJavaプロセスです。このエージェントは通常、最適な統合フロー・パフォーマンスを実現するために、ソース・マシンまたはターゲット・マシン上にローカルにデプロイされます。OPMNを使用して、この状況でスタンドアロン・エージェントを起動、停止および保護できます。

スタンドアロン・エージェントをOPMNに追加するには、次の手順を実行します。

1. ODI_HOME/oracledi/agent/bin/ディレクトリにあるagentcreate.propertiesファイルを、エージェントおよびOPMN構成に一致するように編集します。

2. このエージェントをOPMN構成に追加するスクリプトを実行します。

- UNIXの場合: ODI_HOME/oracledi/agent/bin/opmn_addagent.sh

- Windowsの場合: ODI_HOME/oracledi/agent/bin/opmn_addagent.bat

opmnctlを使用して、次のようにOracle HTTP Serverのステータスを確認できます。

opmnctl status

opmnctlを使用して、Oracleインスタンスのすべてのエージェント・コンポーネントを起動するには、次を実行します。

opmnctl startproc process-type=odiagent

opmnctlを使用して、odiagent1など、特定のエージェント・コンポーネントを起動するには、次を実行します。

opmnctl startproc ias-component=odiagent1

opmnctlを使用して、Oracleインスタンスのすべてのエージェント・コンポーネントを停止するには、次を実行します。

opmnctl stopproc process-type=odiagent

opmnctlを使用して、odiagent1など、特定のエージェント・コンポーネントを停止するには、次を実行します。

opmnctl stopproc ias-component=odiagent1

7.3.3 障害からのOracle Data Integratorの保護および必要な対応

この項では、Oracle Data Integratorの高可用性クラスタのデプロイメントおよびOPMNでコンポーネントがどのようにして障害から保護されるかを説明します。また、この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。

7.3.3.1 WebLogic Serverまたはスタンドアロン・エージェントのクラッシュ

WebLogicサーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。繰り返し再起動しても失敗する場合、WebLogic Serverインフラストラクチャは、クラスタ内の他のノードへのサーバーの移行を試行します。フェイルオーバーの発生時、他のWebLogicインスタンスは、スケジューラになり、すべての作業リポジトリのスケジュールの読取り、計算および実行を行えるようになります。Coherenceキャッシュは、スケジューラ・ライフサイクルを処理するために使用されます。ロックにより、スケジューラの一意性が保証され、イベント通知はスケジューラの移行を知らせます。エージェントが再起動され、そのスケジュールを計算する場合、進行中のスケジュール(実行サイクルの途中にあるスケジュール)が考慮されることに注意してください。これらのスケジュールは自動的に、サーバーの起動時間を過ぎても実行サイクル内で続行されます。新しいセッションが、スケジューラが停止しなかったかのようにトリガーされます。

失効セッションは、エラー状態に移動され、再起動時にはエラー状態のセッションとして扱われます。このセッションのリカバリ/再起動の説明は、第7.2.1.1項「セッションの中断」および第7.2.1.2項「セッションのリカバリ」にあります。

スタンドアロン・エージェントで障害が発生すると、OPMNはそのエージェントをローカルに再起動します。障害のあるエージェントで実行されている既存のセッションは、失効セッションとなります。失効セッションは、エージェントの再起動時に削除されます。

Oracle Data Integratorエージェントは、リソースへのアクセスの失敗、または管理対象サーバーが実行されているかどうかには関係なく発生する問題が原因で停止する場合があります。そのため、管理者がアプリケーションによって引き起こされるクラスタ・エラーを管理対象サーバーのログで監視することをお薦めします。ログ・ファイルの場所の詳細は、第7.2.5.4項「Oracle Data Integratorのログの場所と構成」を参照してください。

Oracle Data Integratorコンソールは、HTTPセッションのフェイルオーバーをサポートしていません。ユーザーは、障害の発生後、Oracle Data Integratorコンソールに再度ログインする必要があります。

7.3.3.2 リポジトリ・データベースの障害

Oracle Data Integratorリポジトリは、マルチ・データ・ソースの使用によりデータベースの障害から保護されます。通常、これらのマルチ・データ・ソースは、システムの初期設定時に構成され(Oracle Fusion Middleware構成ウィザードで、インストール時にマルチプールを直接定義できます)、これらのソースによって、リポジトリをホストするOracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。

Java EEエージェントは、初期設定時に構成されるWebLogicマルチ・データ・ソースを使用します。スタンドアロン・エージェントは、odiparams.shで指定されたOracle RAC JDBC接続を使用します。

Oracle RACでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

Oracle Data Integratorは、リポジトリ・インスタンスが使用できなくなり、後でリストアされる場合に、進行中のセッションの続行を可能にする再試行ロジックを実装します。Oracle RACが有効な構成では、Oracle RACノードが使用可能であれば、進行中のセッション実行リクエストと受信するセッション実行リクエストの両方が処理されます。これは、接続再試行数および接続再試行の遅延時間パラメータを使用して、スタンドアロン・エージェントとJava EEエージェントの両方でサポートされます。ユーザーは、Java EEエージェントのWebLogic Serverテンプレートの生成時に、スタンドアロン・エージェントのodiparams.shまたはodiparams.batを編集することで、これらのパラメータを構成できます。

Oracle Data Integrator StudioでOracle RACデータベースへの接続が失われた場合、最後の保存操作以降に実行されたOracle Data Integrator Studioの作業はすべて失われます。一般に、Oracle Data Integrator Studioの使用時には定期的に作業を保存することをお薦めします。

7.3.3.3 スケジューラ・ノードの障害

Oracle Data Integratorエージェント・クラスタで、スケジューラ・ノードであるエージェント・ノードで障害が発生すると、WebLogic Serverクラスタ内の別のノードがスケジューラ・ノードとしての役割を引き継ぎます。新しいスケジューラ・ノードは、その時点からのすべてのスケジュールを再初期化し、その時点以降のスケジュール済シナリオの実行を続行します。

ただし、元のスケジュール・ノードのクラッシュ時に、そのノードで、繰り返し可能な実行サイクルでのスケジュール済シナリオが実行されていた場合は、この状況で問題が生じます。新しいスケジューラ・ノードが引き継いだとき、元のスケジューラ・ノードで実行されていたスケジュール済シナリオは、元のスケジューラ・ノードがクラッシュした時点以降、新しいスケジューラ・ノードでその反復を続行しません。

たとえば、スケジュール済シナリオが2分間隔で10回実行を繰り返すように構成されている場合に、3回目の実行の途中で元のスケジューラ・ノードで障害が発生すると、新しいスケジューラ・ノードは、引き続きシナリオの実行を8回繰り返す必要があります。しかし、新しいスケジューラ・ノードでは、残りの分のシナリオの実行が継続されません。

7.4 Oracle Data Integratorの高可用性の構成

この項では、Oracle Data Integratorの高可用性の構成を設定するためのインストールおよび構成手順について説明します。

7.4.1 マスター・リポジトリと作業リポジトリを作成するためのRCUの実行

リポジトリ作成ユーティリティ(RCU)の最新バージョンを作成して、Oracle RACデータベース・リポジトリでOracle Data Integrator用の必要なスキーマを作成します。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

次のコマンドを実行してRCUを起動します。

RCU_HOME/bin/rcu

次の手順を実行します。

1. 「リポジトリの作成」ページで、新規スキーマの作成およびロードを選択します。

2. 「データベース接続の詳細」ページで、データベースの詳細を入力します。Oracle RACでは、1つのモードのみが必要です。

3. 「コンポーネントの選択」ページで、「Oracle Data Integrator」を選択します。これにより、「マスターおよび作業リポジトリ」が自動的に作成されます。

4. 「スキーマ・パスワード」ページで、スキーマのパスワードを指定します。

5. 「カスタム変数」ページで、少なくとも「スーパーバイザ・パスワード」と「作業リポジトリ・パスワード」を指定します。他のすべてのフィールドはデフォルトのままでかまいません。

6. 「表領域のマップ」画面で、「OK」をクリックします。

7. 「サマリー」画面で、「OK」をクリックし、リポジトリのインストールを終了します。

7.4.2 最初のOracle Data Integratorホストのインストールと構成

この項では、最初のOracle Data Integratorホスト(APPHOST1など)のインストールおよび構成手順について説明します。

7.4.2.1 APPHOST1へのOracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

Oracle WebLogic Serverインストーラを起動します。

インストーラが起動したら、次の手順に従ってOracle WebLogic Serverをコンピュータにインストールします。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。次に、Oracle WebLogicソフトウェアのインストール先となるコンピュータ上のディレクトリを選択します。
「次へ」をクリックします。

3. 「セキュリティ更新のための登録」画面で、「My Oracle Support」のユーザー名とパスワードを入力して、セキュリティ・アップデートが通知されるようにします。

4. 「インストール・タイプの選択」画面では、完全インストールとカスタム・インストールのどちらを実行するかを指示するように求めるプロンプトが、インストール・プログラムによって表示されます。
「標準」を選択します。

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

5. 「製品インストール・ディレクトリの選択」画面で、WebLogic ServerおよびCoherenceのデフォルトの場所を受け入れます。
「次へ」をクリックします。

6. 「インストール・サマリー」画面に、インストール対象として選択したコンポーネントの一覧と、それらをインストールするために使用されるディスク領域の概算値が表示されます。
「次へ」をクリックします。

7. 「完了」をクリックしてインストーラを終了します。

7.4.2.2 APPHOST1へのOracle Data Integratorのインストール

Oracle Data Integratorインストーラを起動します。

./runInstaller

インストーラからJDKの場所の指定を求められたら、Middlewareホームの下のSDKへのフルパスを入力します。

次のインストール手順を実行します。

1. 「インベントリ・ディレクトリの指定」画面が表示されたら、Oracleのインベントリの場所およびOSグループ名を入力し、「OK」をクリックします。

2. 「インストール・タイプの選択」画面で、次の操作を行います。

- 「J2EEインストール」を選択します。

- オプションで、Oracle Data Integrator Studioが必要な場合は、「開発者」インストールを選択します。

3. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

4. 「インストール場所の指定」画面で、リストからMiddlewareホームを選択します。
「次へ」をクリックします。

5. リポジトリ構成画面で、リポジトリ構成をスキップを選択し、「次へ」を選択します。

6. 「インストール・サマリー」画面で、「インストール」をクリックしてインストールを開始します。

7. 「インストール完了」画面で「終了」をクリックします。

7.4.2.3 高可用性ドメインの作成

構成ウィザードを起動するには、ODI_HOME/common/binディレクトリでconfig.shを実行します。次の手順を実行します。

1. 「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択します。

2. 「ドメイン・ソースの選択」画面で、次のコンポーネントを選択します。

- Oracle Data Integrator SDK Webサービス - 11.1.1.0

- Oracle Data Integrator - コンソール - 11.1.1.0

- Oracle Data Integrator - エージェント - 11.1.1.0

Oracle Enterprise ManagerおよびODI用のOracle Enterprise Managerプラグインもオプションで選択します。

3. 「ドメイン名と場所の指定」画面で、ドメイン名を入力し、「次へ」をクリックします。

4. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの優先ユーザー名とパスワードを入力します。

5. 「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」モードを選択します。「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

1. 下部にある表に表示されるコンポーネント・スキーマ(ODIマスター・スキーマおよびODI作業スキーマ)をすべて選択します。

2. 「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択します。単一のデータベース構成の場合は、「変換しない」を選択します。

3. 画面に次のデータ・ソースが表示されていることを確認します。表7-1に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にDEVが使用されていることを想定しています。
Oracle RACでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照してください。

Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

表7-1 データ・ソースの値の構成

コンポーネント・スキーマ

スキーマ所有者

ODIマスター・スキーマ

DEV_ODI_REPO

ODI作業スキーマ

DEV_ODI_REPO

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

7. 「JDBCコンポーネント・スキーマの構成」画面で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
マルチ・データ・ソースの場合は、次のフィールドに値を入力します。

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

「図7-5 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。

図7-6 GridLink RACコンポーネント・スキーマの構成

「図7-6 GridLink RACコンポーネント・スキーマの構成」の説明

1. ドライバ: RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

2. サービス名 : データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(例: example.com)を含むRACサービス名を登録または追加することをお薦めします。

3. ユーザー名接頭辞: スキーマの接頭辞を入力します。表7-1に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にDEVが使用されていることを想定しています。

4. 「パスワード」と「パスワードの確認」: スキーマにアクセスするときのパスワードを入力します。

5. GridLinkデータ・ソースの場合は、SCANアドレスをリスナー・アドレス・フィールドに入力し、「ポート」フィールドにSCANポートを入力します。「ONSホスト」と「ポート」の各フィールドに、ONSホストおよびポート情報を入力します。

注意:

WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、SCANアドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、ネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。

マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。

6. 一度に1つのデータ・ソースを選択し、適切な詳細を追加することにより、各スキーマを更新します。
すべてのスキーマ(ODIマスターおよびODI作業)に情報が入力されていることを確認します。

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

8. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックしてエントリを修正します。
すべての接続が正常になったら「次へ」をクリックします。

9. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

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

10. アプリケーション・サーバーの構成画面で、管理サーバーのリスニング・アドレスとリスニング・ポートを設定します。

11. 「管理対象サーバーの構成」ページで、次の操作を行います。

- クリックして、新しいサーバーodi_server2を追加します。

- 各サーバーのリスニング・アドレスを、各サーバーが実行されるホスト名に設定します。

- 両方のサーバーのリスニング・ポートが同じであることを確認します。

12. 「クラスタの構成」ページで、odi_clusterという名前のクラスタを作成し、ユニキャストのデフォルトを受け入れます。

13. 「サーバーのクラスタへの割当」ページで、両方のサーバーをクラスタに追加します。

14. 「マシンの構成」ページで、2つのマシンを作成します。

15. 「マシンの割当て」ページで、次の操作を行います。

- マシン1に管理サーバーとodi_server1を追加します。

- マシン2にodi_server2を追加します。

16. 「構成のサマリー」ページで、「作成」をクリックしてドメインを作成します。

7.4.2.4 管理サーバーの起動

次のコマンドを使用して、APPHOST1上のWebLogic管理サーバーを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

7.4.2.5 資格証明ストアの構成

WLSTまたはEnterprise Managerを使用して、資格証明ストアを構成できます。

7.4.2.5.1 WLSTを使用した資格証明の構成

次のスクリプトを実行します。

MW_HOME/oracle_common/common/bin/wlst.sh

次に、次のコマンドを発行します。

connect('weblogic','welcome1','t3://localhost:7001')
createCred(map="oracle.odi.credmap", key="SUPERVISOR", user="SUPERVISOR",
password="SUNOPSIS", desc="ODI SUPERVISOR Credential")
exit()

前述のユーザーは、RCUを使用してリポジトリが作成されたときに作成されたスーパーバイザ・ユーザーです。指定するパスワードは、そのスーパーバイザ・ユーザーのパスワードです。

7.4.2.5.2 Enterprise Managerを使用した資格証明の構成

Enterprise Managerを使用して資格証明を構成する手順は、次のとおりです。

1. Oracle Enterprise Managerにログインし、「ドメイン」→「セキュリティ」→「資格証明」に移動して、「資格証明」ページを表示します。

2. 「マップの作成」をクリックして、「マップの作成」ダイアログを表示します。

3. 「マップの作成」ダイアログで、資格証明の作成対象のマップ名(oracle.odi.credmap)を入力します。

4. 「OK」をクリックして、「資格証明」ページに戻ります。表に、新しい資格証明マップ名がマップ・アイコンとともに表示されます。

5. 「キーの作成」をクリックして、「キーの作成」ダイアログを表示します。

6. このダイアログで、oracle.odi.credmapのマップを選択し、「SUPERVISOR」のキーのテキスト・ボックスにキーを入力し、「タイプ」メニューからタイプを選択して、必要なデータを入力します(ダイアログの外観は、選択したタイプに応じて異なります)。

user="SUPERVISOR", password="your_password"

7. 終了したら「OK」をクリックして、「資格証明」ページに戻ります。選択したマップに対応するマップ・アイコンの下に新しいキーが表示されます。

7.4.2.6 デフォルト・エージェントの構成

Oracle Data Integrator管理対象サーバーを起動する前に、Oracle Data Integratorエージェントのエージェント定義を作成する必要があります。次の手順を実行します。

1. ODI_HOME/oracledi/client/odi.shでOracle Data Integrator Studioを起動します。

2. Oracle Data Integrator Studioが起動したら、左側のペインで「リポジトリへの接続...」をクリックします。

3. ログイン・ウィンドウが表示されます。鉛筆アイコンをクリックして、マスター・リポジトリのログオン情報を編集します。

4. 「リポジトリ接続情報」画面で、次のものを入力します。
ODI接続:

- ログイン名: マスター・リポジトリ

- ユーザー: SUPERVISOR

- パスワード: (資格証明ストアの作成時に使用されたパスワード)

DB接続:

- ユーザー: (DEV_ODI_REPOなどのODIスキーマ・ユーザー)

- パスワード: (ODIスキーマ・パスワード)

- ドライブ名: oracle.jdbc.driver.OracleDriver

- URL: (jdbc:oracle:thin:@host:port:sidという形式の接続URL)

5. 「テスト」をクリックして、接続をテストします。

6. 「OK」をクリックして、ログオン画面に戻ります。

7. ユーザー/パスワードが正しいことを確認し、「OK」をクリックしてマスター・リポジトリに接続します。

8. 接続されたら、左側のペインで「物理アーキテクチャ」セクションを開きます。

9. 「エージェント」を選択し、右クリックして新しいエージェントを作成します。

10. 次のプロパティを指定して新しいエージェントを作成します。

- 名前: OracleDI Agent

- ホスト: (odi_server1が実行されるホスト)

- ポート: (odi_server1管理対象サーバーが実行されているポート)

- Webアプリケーション・コンテキスト: oraclediagent

11. 「データソース」タブを開きます。左側のペインで、「リポジトリ」セクションを開き、そこからエージェントの「データソース」領域に「作業リポジトリ」をドラッグします。

12. 作業リポジトリ・データ・ソースを編集して、WebLogic Serverインストーラのデータ・ソースによって使用されるJNDI名を追加します。これはjdbc/odiWorkRepositoryです。

13. 変更内容を保存して、Oracle Data Integrator Studioを終了します。

7.4.2.7 クラスタのCoherenceの構成

Coherenceは、クラスタ・メンバー間で通信が有効になるように構成する必要があります。Coherenceを構成するには、次の手順を実行します。

1. 管理コンソールの左側のタブから、「環境」→「サーバー」を選択します。

2. 「odi_server1」を選択します。

3. 「サーバー起動」タブをクリックします。

4. 「引数」ボックスで、次のように入力します(すべてを1行で入力します)。

-Doracle.odi.coherence.wka1=machine1 -Doracle.odi.coherence.wka1.port=9088
-Doracle.odi.coherence.wka2=machine2 -Doracle.odi.coherence.wka2.port=9088
-Dtangosol.coherence.localport=9088

machine1とmachine2は、クラスタ内の2つのマシンのホスト名です。

注意:

ポート9088がマシン上で使用されていない場合は、それをCoherenceポートとして使用します。それ以外の場合は、別のポートを選択してCoherenceポートとして構成してください。

5. 「保存」をクリックします。

6. odi_server2に対しても前述の手順を繰り返します。

7.4.2.8 ノード・マネージャの構成とodi_server1の起動

次のコマンドを使用して、ノード・マネージャを構成および起動します。

$ MW_HOME/oracle_common/common/bin/setNMProps.sh
$ MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

odi_server1を起動する手順は次のとおりです。

1. 管理コンソールで、「環境」→「サーバー」→「制御」タブを選択します。

2. odi_server1を選択し、「起動」をクリックします。

7.4.2.9 Oracle Data Integratorエージェントが実行されていることの確認

Webブラウザに次のURLを入力して、Oracle Data Integratorエージェントが実行されていることを確認します。

http://APPHOST1:PORT/oraclediagent

7.4.3 2つ目のOracle Data Integratorホストのインストールと構成

この項では、2つ目のOracle Data Integratorホスト(APPHOST2など)のインストールおよび構成手順について説明します。

7.4.3.1 APPHOST2へのOracle WebLogic Serverのインストール

第7.4.2.1項「APPHOST1へのOracle WebLogic Serverのインストール」の手順に従います。

APPHOST1で使用したものと同じディレクトリ・パスを使用します。

7.4.3.2 APPHOST1からAPPHOST2へのドメインのパックと解凍

次のコマンドを使用して、最初のホスト(APPHOST1)に作成されたドメインをパックします。

$ cd MW_HOME/oracle_common/common/bin
$ ./pack.sh -domain=<full path to the domain> -template=mytemplate.jar
-template_name=<descriptive template name> -managed=true

最初のホストに作成したjarファイルを2つ目のホスト(APPHOST2)にコピーし、解凍します。

$ cd MW_HOME/oracle_common/common/bin
$ ./unpack.sh -domain=<full path to the domain> -template=mytemplate.jar

7.4.3.3 ノード・マネージャの構成とodi_server2の起動

次のコマンドを使用して、APPHOST2でノード・マネージャを構成および起動します。

$ MW_HOME/oracle_common/common/bin/setNMProps.sh
$ MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

odi_server2を起動する手順は次のとおりです。

1. 管理コンソールで、「環境」→「サーバー」→「制御」タブを選択します。

2. odi_server2を選択し、「起動」をクリックします。

7.4.3.4 Oracle Data Integratorエージェントが実行されていることの確認

Webブラウザに次のURLを入力して、Oracle Data Integratorエージェントが実行されていることを確認します。

http://APPHOST2:PORT/oraclediagent

7.4.4 Oracle HTTP Serverのインストール

Oracle HTTP Serverを別のホスト(WEBHOST1)にインストールします。

システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。

Oracle Web Tierコンポーネントのインストーラを起動します。

HOST> ./runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、/u01/app/product/fmw/jrockit_160_<バージョン>のように入力します。

次のインストール手順を実行します。

1. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

2. 「インストール場所の指定」画面で、次の値を入力します。
MW_HOME: MW_HOMEの値を入力します。例:

/u01/app/product/fmw

ドロップダウン・リストから、すでにインストールされているMiddlewareホームを選択します。Oracle HTTP Server Oracleホーム(OHS_ORACLE_HOME)ディレクトリには、ディレクトリ名WEBを入力します。

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

3. 「サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。

4. 「インストール完了」画面で「終了」をクリックします。

この手順を繰り返して、Oracle HTTP Serverを別のWeb層ホスト(WEBHOST2)にインストールします。

7.4.4.1 Oracle HTTP Server Oracleホームのアップグレード

この項では、Oracle HTTP Serverソフトウェアをアップグレードする手順について説明します。詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』のOracle Fusion Middlewareの最新パッチ・セットの適用に関する項を参照してください。

OHS_ORACLE_HOMEをアップグレードするには、次の手順を実行します。

1. ./runinstallerを実行して、Web Tierアップグレード・インストーラを起動します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「前提条件のチェック」画面で、「次へ」をクリックします。

4. 「インストール場所の指定」画面で、Oracle MiddlewareホームへのパスおよびOracle HTTP Server Oracleホーム・ディレクトリの名前を指定します。

5. 「インストール・サマリー」画面で、選択内容を確認して「インストール」をクリックします。

6. 「インストールの進行状況」画面に、インストールの進行状況が示されます。
インストールが終了すると、oracleRoot.shの確認ダイアログ・ボックスが表示されます。このダイアログ・ボックスは、インストールを続行する前に構成スクリプトをrootユーザーとして実行する必要があることを示しています。確認ダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootユーザーとしてログインして、スクリプト・ファイル/u01/app/oracle/product/fmw/id/oracleRoot.shを実行します。スクリプトが完了したら、確認ダイアログ・ボックスの「OK」をクリックします。

7. 「インストール完了」画面で「終了」をクリックして終了します。

この手順は、Oracle HTTP ServerがインストールされているWeb層ホスト(WEBHOST1やWEBHOST2など)ごとに実行する必要があります。

7.4.4.2 Oracle HTTP Serverの構成

インストール後、次の行を、Oracle HTTP Serverにインストールしたホスト(複数可)上のOHS_HOME/instances/ohs_instance1/config/OHS/ohs11/mod_wl_ohs.confファイルに追加します。

# ODI Agent
<Location /oraclediagent>
WebLogicCluster host1:8002,host2:8002
SetHandler weblogic-handler
</Location>

#ODI Explorere
<Location /odirepex>
WebLogicCluster host1:8002,host2:8002
SetHandler weblogic-handler
</Location>

#ODI Webservices
<Location /oracledisdkws>
WebLogicCluster host1:8002,host2:8002
SetHandler weblogic-handler
</Location>

この手順は、Oracle HTTP ServerがインストールされているWeb層ホスト(WEBHOST1やWEBHOST2など)ごとに実行する必要があります。

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

ロード・バランサは、リクエストがWEBHOST1上とWEBHOST2上の2つのHTTP Server間でラウンドロビン処理されるように構成する必要があります。

さらに、次のロード・バランサの構成に関する推奨事項に従います。

- ロード・バランサに対して永続性を有効にしないでください。これはHTTP Serverによって提供されます。

- HTTP Serverポートを監視するように構成して、ロード・バランサがフェイルオーバーを提供できるようにする必要があります。

7.4.4.4 Oracle Data Integratorエージェントが実行されていることの確認

Webブラウザに次のURLを入力して、Oracle Data Integratorエージェントが実行されていることを確認します。

http://LBRHOST:PORT/oraclediagent

7.4.4.5 エージェントの再構成

エージェント定義は、個々のサーバーのアドレスではなく、ロード・バランサのアドレスを指す必要があります。

新しいエージェントを作成する際は、このことを覚えておいてください。

デフォルトのエージェントでは、Oracle Data Integrator Studioに再度接続します。

1. ODI_HOME/oracledi/client/odi.shでOracle Data Integrator Studioを起動します。

2. Oracle Data Integrator Studioが起動したら、左側のペインで「リポジトリへの接続...」をクリックします。

3. ログイン・ウィンドウが表示されたら、「OK」をクリックしてログオンします。

4. 接続されたら、左側のペインで「物理アーキテクチャ」セクションを開きます。

5. 「エージェント」を選択し、「OracleDIAgent」を選択します。

6. 次のプロパティを編集します。

- ホスト: ロード・バランサの仮想サーバー・アドレス

- ポート: ロード・バランサの仮想アドレスのリスニング・ポート

7. 「テスト」をクリックして、エージェントの接続をテストします。

8. 変更内容を保存して、Oracle Data Integrator Studioを終了します。

8 Identity Managementコンポーネントの高可用性の構成

Oracle Identity Management製品を使用すると、多様なサーバーにわたるユーザー、デバイス、およびサービスを構成および管理して、これらのアイデンティティの管理を委託し、エンド・ユーザーにセルフサービスの特権を提供することができます。これらの製品を使用すると、アプリケーション全体にわたるシングル・サインオンを構成し、有効な資格証明を持つユーザーのみがオンライン・リソースにログインしてアクセスできるように、ユーザーの資格証明を処理できます。

他のエンタープライズ・レベルのアプリケーションは、Oracle Identity Management製品に依存するため、高可用性を構成しておくことが必要不可欠になります。Oracle Identity Management製品に障害が発生すると、この製品に依存するアプリケーションにも障害が発生します。

この章では、アクティブ/アクティブ構成における高可用性のためのIdentity Management製品の構成について説明します。

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

- 第8.1項「Identity Management製品のコンポーネントと高可用性の概要」

- 第8.2項「Oracle Identity Managementの高可用性構成のための前提条件」

- 第8.3項「Oracle Internet Directoryの高可用性」

- 第8.4項「Oracle Virtual Directoryの高可用性」

- 第8.5項「Oracle Directory Integration Platformの高可用性」

- 第8.6項「Oracle Directory Services Managerの高可用性」

- 第8.7項「コロケート・アーキテクチャの高可用性」

- 第8.8項「Oracle Access Managerの高可用性」

- 第8.9項「Oracle Identity Managerの高可用性」

- 第8.10項「認可ポリシー・マネージャの高可用性」

- 第8.11項「Oracle Identity Navigatorの高可用性」

- 第8.12項「Oracle Adaptive Access Managerの高可用性」

- 第8.13項「Oracle Identity Federationの高可用性」

- 第8.14項「コンポーネントの起動および停止」

8.1 Identity Management製品のコンポーネントと高可用性の概要

図8-1は、Oracle Fusion Middleware 11g Oracle Identity Managementの高可用性アーキテクチャの例を示しています。このアーキテクチャには、Web層、アプリケーション層、およびディレクトリ層があります。

図8-1 Oracle Fusion Middleware 11g Oracle Identity Managementの高可用性アーキテクチャ

「図8-1 Oracle Fusion Middleware 11g Oracle Identity Managementの高可用性アーキテクチャ」の説明

図8-1では、Web層にコンピュータWEBHOST1とWEBHOST2があります。

Oracle HTTP Serverインスタンスの1つはWEBHOST1に、もう1つのOracle HTTP ServerインスタンスはWEBHOST2にインストールされています。ロード・バランシング・ルーターによって、WEBHOST1およびWEBHOST2上のOracle HTTP Serverインスタンスにリクエストがルーティングされます。

アプリケーション層には、コンピュータIDMHOST1とIDMHOST2コンピュータがあります。

IDMHOST1では、次のインストールが実行されています。

- Oracle Directory Services ManagerインスタンスとOracle Directory Integration Platformインスタンスが、WLS_ODS1管理対象サーバー上にインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

- Oracle Access Manager Access ServerインスタンスがWLS_OAM1管理対象サーバーにインストールされています。

- WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。管理サーバーは、シングルトン・アプリケーションです。Oracle Access Manager Consoleもシングルトン・アプリケーションとしてインストールされています。

IDMHOST2では、次のインストールが実行されています。

- Oracle Directory Services ManagerインスタンスとOracle Directory Integration Platformインスタンスが、WLS_ODS2管理対象サーバー上にインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
IDMHOST2上のWLS_ODS2管理対象サーバーにあるインスタンスと、IDMHOST1上のWLS_ODS1管理対象サーバーにあるインスタンスは、Cluster_ODSクラスタとして構成されています。

- Oracle Access Manager Access ServerインスタンスがWLS_OAM2管理対象サーバーにインストールされています。
IDMHOST2上のWLS_OAM2管理対象サーバーにあるAccess Serverインスタンスと、IDMHOST1上のWLS_OAM1管理対象サーバーにあるAccess Serverインスタンスは、Cluster_OAMクラスタとして構成されています。

- WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。IDMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。アクティブ/パッシブの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。Oracle Access Manager Consoleもシングルトン・アプリケーションとしてインストールされており、それはIDMHOST2上の管理サーバーがアクティブになるまではパッシブです。

ディレクトリ層には、コンピュータOIDHOST1とOIDHOST2があります。

OIDHOST1上には、Oracle Internet DirectoryインスタンスとOracle Virtual Directoryインスタンスがインストールされています。Oracle RACデータベースをセキュリティ・メタデータ・リポジトリとして使用しているOracle Internet Directoryインスタンスの接続には、透過的アプリケーション・フェイルオーバー(TAF)が使用されます。サーバー側のTAFおよび高可用性のイベント通知に対してデータベースが有効化されます。

OIDHOST2上には、Oracle Internet DirectoryインスタンスとOracle Virtual Directoryインスタンスがインストールされています。Oracle RACデータベースをセキュリティ・メタデータ・リポジトリとして使用しているOracle Internet Directoryインスタンスの接続には、透過的アプリケーション・フェイルオーバー(TAF)が使用されます。サーバー側のTAFおよび高可用性のイベント通知に対してデータベースが有効化されます。

OIDHOST1およびOIDHOST2上のOracle Internet Directoryインスタンスは、クラスタとして構成されています。

Oracle Real Applications Cluster(Oracle RAC)データベースは、セキュリティ・メタデータ・リポジトリとして使用されます。

8.1.1 11g Oracle Identity Management製品について

表8-1は、Oracle Identity Management製品の要約です。これらの製品は、11gスイートレベルのインストール・プログラムを使用してインストールできます。詳細は、『Oracle Fusion Middleware Oracle Identity Managementクイック・インストレーション・ガイド』の序章を参照してください。

表8-1  11g Identity Managementコンポーネントおよび製品スイート

製品

説明

製品スイート

Oracle Internet Directory

Oracle Internet Directoryは、分散したユーザー、ネットワーク構成およびその他のリソースに関する情報をすばやく取得して集中管理できるLDAP Version 3対応のサービスです。

Oracle Identity Management Platform and Directory Services Suite

Oracle Virtual Directory

Oracle Virtual Directoryは、LDAP Version 3対応のサービスで、1つ以上のエンタープライズ・データ・ソースの1つのビューとして要約します。

Oracle Virtual Directoryは複数のソースを1つのディレクトリ・ビューに集約するので、LDAP認識アプリケーションと様々なディレクトリ・サーバー・データ・ストアとの統合が可能になります。

Oracle Identity Management Platform and Directory Services Suite

Oracleディレクトリ統合プラットフォーム

Oracle Directory Integration Platformは、様々なディレクトリとOracle Internet Directory間のデータ同期を可能にするJ2EEアプリケーションです。Oracle Directory Integration Platformには、他のエンタープライズ・リポジトリとの同期ソリューションのデプロイを可能とするサービスとインタフェースが含まれています。Oracle Internet Directoryとサード・パーティのメタディレクトリ・ソリューションとの相互運用性を実現するためにも使用できます。

Oracle Identity Management Platform and Directory Services Suite

Oracle Directory Services Manager

Oracle Directory Services Managerは、Oracle Virtual DirectoryおよびOracle Internet Directory用の統一されたグラフィカル・ユーザー・インタフェース(GUI)です。Oracle Directory Services Managerでは、Webベースのフォームやテンプレートを使用できるため、Oracle Virtual DirectoryとOracle Internet Directoryの管理および構成が簡素化されます。

Oracle Directory Services Managerは、Oracle Enterprise Manager Fusion Middleware Control、または独自のURLから使用できます。

Oracle Identity Management Platform and Directory Services Suite

Oracle Access Manager

Oracle Access Manager 11gは、Oracle Access Manager 10g(アクセスのみ)とOracle Single Sign-On 10gの両方の後継製品です。Oracle Access Manager 11gによって、すべての認証および認可サービスの一元的な提供が可能になります。提供されるコア・サービスは、有効なセッション・トークンのチェック、セッション・トークンが無効であるか見つからない場合の資格証明の要求、セッション・トークンの発行、リソース・リクエストのインターセプト、およびリソースへのアクセスを制御するためのアクセス制御ポリシーの評価です。

Oracle Identity and Access Management Suite

Oracle Identity Manager

Oracle Identity Managerは、アプリケーションおよびディレクトリからユーザー・アカウントを追加、更新および削除するプロセスを自動化するユーザー・プロビジョニングおよび管理ソリューションです。また、誰が何にアクセスしたかを示すきめ細かいレポートを提供することで、法規制コンプライアンスの向上にも寄与します。Oracle Identity Managerは、スタンドアロン製品として、またはOracle Identity and Access Management Suiteの一部として使用可能です。

Oracle Identity and Access Management Suite

認可ポリシー・マネージャ

認可ポリシー・マネージャは、アプリケーション・ポリシーを管理するためのグラフィカル・インタフェース・ツールです。認可ポリシー・マネージャの対象ユーザーは、セキュリティ管理者です。このツールを使用することで、管理者はエンタープライズ・アプリケーション全体にわたるポリシーを表示および管理できます。管理者は、ドメイン内で実行されているすべてのアプリケーションを管理することも、アプリケーションのサブセットのみを管理することもできます。

Oracle Identity and Access Management Suite

Oracle Identity Navigator

Oracle Identity Navigatorは、Oracle Identity Management製品のスタート地点として機能するよう設計されている管理ポータルです。これは、個々の製品コンソールに代わるものではありません。1つのサイトからOracle Identity Managementの各コンソールにアクセスできるようにするためのものです。

Oracle Identity and Access Management Suite

Oracle Adaptive Access Manager

Oracle Adaptive Access Manager(OAAM)は、エンタープライズ向けにWebアクセスのリアルタイム不正検出およびオンライン多要素認証セキュリティを提供するOracle Identity Managementのソリューションです。OAAMは、不正アクセス・リクエストのリアルタイム・ブロッキングを可能にし、高度なアラート・メカニズムを提供し、フィッシング、トロイの木馬、ウイルス、詐欺、介入者攻撃などの攻撃から企業とその顧客を保護します。

Oracle Identity and Access Management Suite

Oracle Identity Federation

Oracle Identity Federationは、各企業のセキュリティ・ドメイン境界を越えたサービスの提供やアイデンティティの共有を可能にするとともに不正アクセスに対する保護機能を提供します。

Oracle Identity Management Platform and Directory Services Suite

8.2 Oracle Identity Managementの高可用性構成のための前提条件

この項では、Oracle Identity Managementの高可用性構成を設定する前に完了する必要のある前提条件の手順について説明します。

8.2.1 Oracleホームの要件

Identity ManagementコンポーネントのOracleホームは、すべてのノードで同一である必要があります。たとえば、Node1でOracleホームとして/u01/app/oracle/product/fmw/idmを選択した場合は、すべての後続のノードのOracleホームとして/u01/app/oracle/product/fmw/idmを選択する必要があります。

8.2.2 データベースに関する前提条件

いくつかのOracle Identity Managementコンポーネントでは、サポートされているデータベースおよびスキーマが存在している必要があります。

データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。

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

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

8.2.3 データベース・リポジトリのインストールと構成

高可用性データベースを使用してメタデータ・リポジトリを格納することをお薦めします。可用性を最大にするために、Oracle Real Application Cluster (Oracle RAC) データベースの使用をお薦めします。必須ではありませんが、データベースではデータ記憶域にOracle自動ストレージ管理を使用することをお薦めします。Oracle ASMを使用する場合、ベスト・プラクティスはOracle Managed Filesも使用することです。

Oracle ASMを使用する場合、Oracle ASMを独自のOracleホームにインストールし、次の2つのディスク・グループを用意します。

- データベース・ファイル用のグループ。

- フラッシュ・リカバリ領域用のグループ。

この項には、データベース・リポジトリのインストールおよび構成手順への関連項目が記載されています。

Oracle Clusterware

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

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

自動ストレージ管理

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

Oracle Fusion Middlewareコンポーネントの多くは、インストールの前にデータベース内にスキーマが存在している必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するツール、リポジトリ作成ユーティリティ(RCU)があります。高可用性環境では、これらのスキーマを作成して、Real Application Clusters(Oracle RAC)データベースにロードする必要があります。

RCUを使用してOracle Identity ManagementスキーマをOracle RACデータベース・リポジトリにロードする操作の詳細は、次の項を参照してください。

8.2.4 リポジトリ作成ユーティリティ・ソフトウェアの取得

RCUの最新バージョンを取得するには、次のOracle Technology NetworkのOracle Fusion Middleware 11gR1のソフトウェア・ダウンロード・ページにアクセスしてください。

http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

Required Additional Softwareの表でRepository Creation Utilityを探します。.zipファイルをダウンロードした後で、選択したディレクトリに内容を抽出します。このガイドでは、このディレクトリをRCU_HOMEと呼びます。

注意:

Windowsオペレーティング・システムでは、名前に空白が含まれていないディレクトリにRCUの.zipファイルを解凍してください。

この章で説明するOracle Identity Managementコンポーネントのいずれもインストールする前には、RCUを実行して、そのコンポーネントで使用されるスキーマをOracle RACデータベースに作成しておきます。これらのスキーマは、この章で説明するOracle Identity Managementの高可用性構成に必要です。

RCUの詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』および『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

8.2.4.1 リポジトリ作成ユーティリティの実行

インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。

RCUの実行の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』および『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

作成するスキーマは、インストールおよび構成するアイデンティティ管理製品に応じて異なります。例:

- Oracle Identity Manager用のデータベースである場合は、「アイデンティティ管理 - Oracle Identity Manager」を選択します。

注意:

SOAおよびMDSスキーマは自動的に選択されています。

- Oracle Internet Directory用のデータベースである場合は、「アイデンティティ管理 - (Oracle Internet Directory - ODS)」を選択します。

- Oracle Access Manager用のデータベースである場合は、「アイデンティティ管理 - Oracle Access Manager」を選択します。

- Oracle Identity Federation用のデータベースである場合は、「アイデンティティ管理 - Oracle Identity Federation」を選択します。

- Oracle Adaptive Access Manager用のデータベースである場合は、「アイデンティティ管理 - Oracle Adaptive Access Manager」を選択します。

8.2.5 Oracle Fusion Middleware 11gメタデータ用データベースの構成

次の特性を持つOracle Fusion Middleware 11gメタデータを格納するOracle Real Application Clustersデータベースを作成します。

- バックアップとリカバリを容易にするためにアーカイブ・ログ・モードになっている必要があります。

- オプションでフラッシュバックを有効化する必要があります。

- ALT32UTF8キャラクタ・セットで作成されている必要があります。

静的なPROCESSES初期化パラメータの値は、Oracle Internet Directoryに対して500以上にする必要があります。この値は、リポジトリ作成ユーティリティによってチェックされます。

この値をチェックするには、次のようにSQL*PlusでSHOW PARAMETERコマンドを使用します。

prompt> sqlplus "sys/password as sysdba"
SQL> SHOW PARAMETER processes

パラメータの値を変更する一般的な方法の1つとして、次のようなコマンドを使用し、データベースの停止および再起動をしてパラメータを有効化する方法があります。

prompt> sqlplus "sys/password as sysdba"
SQL> ALTER SYSTEM SET PROCESSES=500 SCOPE=SPFILE;

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

8.2.5.1 この章で使用するデータベースの例

表8-2は、この章のデータベースの構成例で使用されている値を示しています。

表8-2 アイデンティティ管理で使用されるデータベースの構成例

コンポーネント

データベース・サービス名

データベース・インスタンス名

Oracle Internet Directory

oid.mycompany.com

oiddb1、oiddb2

Oracle Virtual Directory

N/A

N/A

Oracleディレクトリ統合プラットフォーム

oid.mycompany.com

oiddb1、oiddb2

Oracle Directory Services Manager

N/A

N/A

Oracle Access Manager

oam.mycompany.com

oamdb1、oamdb2

Oracle Identity Manager

oim.mycompany.com

oimdb1、oimdb2

認可ポリシー・マネージャ

apm.mycompany.com

apmdb1、apmdb2

Oracle Identity Navigator

N/A

N/A

Oracle Adaptive Access Manager

oaam.mycompany.com

oaamdb1、oaamdb2

Oracle Identity Federation

oif.mycompany.com

oifdb1、oifdb2

8.2.5.2 データベース・サービス

Oracle Enterprise Manager Cluster Managed Services Pageを使用して、クライアント・アプリケーションがデータベースへの接続に使用するデータベース・サービスを作成することをお薦めします。データベース・サービスの作成の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドの「ワークロード管理」を参照してください。

SQL*Plusを使用して、Oracle RACデータベースを構成し、次の指示に従ってOracle Internet Directoryのフェイルオーバーを自動化することもできます。次の各コマンドは、クラスタ内の1つのノードにのみ実行してください。

1. CREATE_SERVICEサブプログラムは、データベース・サービスの作成、および高可用性通知の有効化とサーバー側の透過的アプリケーション・フェイルオーバー(TAF)設定の構成の両方に使用します。

prompt> sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'idm.mycompany.com',
NETWORK_NAME => 'idm.mycompany.com',
AQ_HA_NOTIFICATIONS => TRUE,
FAILOVER_METHOD => DBMS_SERVICE.FAILOVER_METHOD_BASIC,
FAILOVER_TYPE => DBMS_SERVICE.FAILOVER_TYPE_SELECT,
FAILOVER_RETRIES => 5, FAILOVER_DELAY => 5);

EXECUTE DBMS_SERVICEコマンドは、1行で入力する必要があります。

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

prompt> srvctl add service -d idmdb -s idm -r idmdb1,idmdb2

3. srvctlを使用してサービスを開始します。

prompt> srvctl start service -d idmdb -s  idm

注意:

SRVCTLコマンドの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。

データベースにサービスが存在している場合は、高可用性通知が有効化され、サーバー側で正しく透過的アプリケーション・フェイルオーバー(TAF)が設定されていることを確認します。高可用性通知がアドバンスト・キューイング(AQ)を通して送信されるように、DBMS_SERVICEパッケージを使用してサービスを変更します。具体的には、次のようにAQ_HA_NOTIFICATIONS属性をTRUEに設定して、サーバー側の透過的アプリケーション・フェイルオーバー(TAF)の設定を構成します。

prompt> sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.MODIFY_SERVICE
(SERVICE_NAME => 'idm.mycompany.com',
AQ_HA_NOTIFICATIONS => TRUE,
FAILOVER_METHOD => DBMS_SERVICE.FAILOVER_METHOD_BASIC,
FAILOVER_TYPE => DBMS_SERVICE.FAILOVER_TYPE_SELECT,
FAILOVER_RETRIES => 5, FAILOVER_DELAY => 5);

EXECUTE DBMS_SERVICEコマンドは、1行で入力する必要があります。

注意:

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

11.2データベースを使用する場合は、11gリリース2 (11.2)用のOracle Database管理者ガイドのSRVCTLを使用したデータベース・サービスの作成と削除に関する項の手順に従ってください。

8.2.5.3 透過的アプリケーション・フェイルオーバー(TAF)の検証

ここでは、すでに設定されている透過的アプリケーション・フェイルオーバー(TAF)構成を検証する方法について説明します。

Oracle Internet Directoryプロセスの起動後、V$SESSION_VIEWのFAILOVER_TYPE、FAILOVER_METHOD、およびFAILED_OVER列を問い合せて、接続されているクライアントおよびそのTAFステータスを取得できます。

たとえば、次のSQL文を使用して、TAFが正しく構成されていることを検証します。

SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER, COUNT(*)
FROM V$SESSION
GROUP BY MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER;

フェイルオーバー前の出力は次のようになります。

MACHINE              FAILOVER_TYPE FAILOVER_M  FAI   COUNT(*)
-------------------- ------------- ---------- ---- ----------
oidhost1             SELECT        BASIC       NO          11
oidhost1             SELECT        BASIC       NO           1

フェイルオーバー後の出力は次のようになります。

MACHINE              FAILOVER_TYPE FAILOVER_M  FAI   COUNT(*)
-------------------- ------------- ---------- ---- ----------
oidhost2             SELECT        BASIC       NO          11
oidhost2             SELECT        BASIC       NO           1

8.2.5.4 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle Identity Managementの高可用性環境をデプロイするためのネットワークの前提条件について説明します。

8.2.5.4.1 ロード・バランサ

Oracle Identity Managementソフトウェア・スタック内のコンポーネントを高可用性構成にデプロイする場合は、すべてのコンポーネントにハードウェア・ロード・バランサが必要です。ハードウェア・ロード・バランサには、次の機能が必要です。

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

- ポート変換の構成: ロード・バランサには、1つのポートで受信した受信リクエストを別のポートで実行されているサーバー・プロセスにルーティングできるポート変換機能が必要です。たとえば、ポート80で受信したリクエストをポート7777にルーティングできます。

- プロトコル変換: ロード・バランサには、異なるプロトコルを実行するシステム間のプロトコル変換機能が必要です。これにより、発行元デバイスとターゲット指定されたホストに関連付けられているネイティブ・プロトコル・スタックが異なる場合も、あるネットワークに接続しているユーザーが別のネットワーク上のホストにアクセスできます。たとえば、HTTPSリクエストを受信して、HTTPリクエストを送信することができます。
この機能は推奨されますが、必須ではありません。

- SSLアクセラレーション: SSLアクセラレーションは、SSLトランザクションで実行され、プロセッサを集中的に使用する公開鍵暗号化アルゴリズムを、ハードウェア・アクセラレータにオフロードする方法です。
この機能は推奨されますが、必須ではありません。

- ポート(HTTP、HTTPS、LDAP、LDAPS)の監視

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

- ロード・バランサには複数の仮想サーバーを構成できる必要があります。各仮想サーバーに対し、ロード・バランサには2つ以上のポートでトラフィック管理を構成できることが必要です。たとえば、Oracle Internet Directoryクラスタでは、LDAPおよびLDAPSトラフィック用の仮想サーバーとポートでロード・バランサを構成する必要があります。

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

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

- リソースの監視/ポートの監視/プロセス障害検出
ロード・バランサは、サービスおよびノードの障害を通知などの方法を通じて検出し、障害が発生したノードへの非Oracle Netトラフィックの送信を停止できる必要があります。ロード・バランサに障害の自動検出機能がある場合は、それを使用する必要があります。

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

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

- スティッキーなルーティング機能
CookieまたはURLに基づいたコンポーネントへのスティッキーな接続を維持する機能

表8-3は、Oracle Identity Managementの高可用性環境で外部ロード・バランサに使用する仮想サーバー名を示しています。

表8-3 外部ロード・バランサの仮想サーバー名

コンポーネント

仮想サーバー名

Oracle Internet Directory

oid.mycompany.com

Oracle Virtual Directory

ovd.mycompany.com

Oracle Identity Federation

oif.mycompany.com

Oracle Directory Services Managerコンソール

admin.mycompany.com

Oracle Access Manager

sso.mycompany.com

Oracle Adaptive Access Manager

oaam.mycompany.com

Oracle Identity Manager

sso.mycompany.com

8.2.5.4.2 仮想サーバー名

この項では、この章で説明する高可用性デプロイメントのために設定が必要な仮想サーバー名について説明します。

仮想サーバー名に対応するIPアドレスが設定されていることと、仮想サーバー名がドメイン・ネーム・システム(DNS)に登録されていることを確認します。Oracle Fusion Middlewareを実行するコンピュータは、これらの仮想サーバー名を解決できることが必要です。

oid.mycompany.com

この仮想サーバーは、ディレクトリ層のOracle Internet DirectoryサーバーへのすべてのLDAPトラフィックのアクセス・ポイントとして機能します。SSLポートおよび非SSLポートの両方へのトラフィックが構成されます。クライアントは、SSLの場合はアドレスoid.mycompany.com:636、非SSLの場合はoid.mycompany.com:389を使用してこのサービスにアクセスします。

OIDHOST1およびOIDHOST2上のOracle Internet Directoryプロセスのハートビートを監視します。OIDHOST1またはOIDHOST2上でOracle Internet Directoryプロセスが停止した場合、あるいはホストOIDHOST1またはホストOIDHOST2のいずれかで障害が発生した場合、ロード・バランサは障害が発生していないコンピュータへのLDAPトラフィックのルーティングを継続する必要があります。

ovd.mycompany.com

この仮想サーバーは、ディレクトリ層のOracle Virtual DirectoryサーバーへのすべてのLDAPトラフィックのアクセス・ポイントとして機能します。SSLポートおよび非SSLポートの両方へのトラフィックが構成されます。クライアントは、SSLの場合はアドレスovd.mycompany.com:7501、非SSLの場合はovd.mycompany.com:6501を使用してこのサービスにアクセスします。

OVDHOST1およびOVDHOST2上のOracle Virtual Directoryプロセスのハートビートを監視します。OVDHOST1またはOVDHOST2上でOracle Virtual Directoryプロセスが停止した場合、あるいはホストOVDHOST1またはホストOVDHOST2のいずれかで障害が発生した場合、ロード・バランサは障害が発生していないコンピュータへのLDAPトラフィックのルーティングを継続する必要があります。

oif.mycompany.com

この仮想サーバーは、アプリケーション層のOracle Identity FederationサーバーへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。

oaam.mycompany.com

この仮想サーバーは、Webサイトへ送信されるすべてのOracle Adaptive Access Managerトラフィックのアクセス・ポイントとして機能します。

sso.mycompany.com

この仮想サーバーは、Webサイトへ送信されるすべてのOracle Access Managerトラフィックのアクセス・ポイントとして機能します。

この仮想サーバーは、シングル・サインオン・サービスへ送信されるすべてのHTTPトラフィックのアクセス・ポイントとして機能します。

この仮想ホストは、リクエストのクライアントIPアドレスを保持するように構成する必要があります。いくつかのロード・バランシング・ルーターでは、ロード・バランシング・ルーターがリクエストのオリジナルのクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入できるようにすることで、これを実現できます。

8.3 Oracle Internet Directoryの高可用性

この項では、Oracle Internet Directoryの概要、およびOracle Internet Directoryの高可用性環境の設計とデプロイ方法について説明します。

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

- 第8.3.1項「Oracle Internet Directoryコンポーネント・アーキテクチャ」

- 第8.3.2項「Oracle Internet Directoryの高可用性の概要」

- 第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」

- 第8.3.4項「Oracle Internet Directoryの高可用性の検証」

- 第8.3.5項「Oracle Internet Directoryのフェイルオーバーおよび予想される動作」

- 第8.3.6項「Oracle Internet Directoryの高可用性のトラブルシューティング」

- 第8.3.7項「Oracle Internet Directoryの高可用性に関するその他の問題」

8.3.1 Oracle Internet Directoryコンポーネント・アーキテクチャ

Oracle Internet Directoryは、Directory Integration Platform、Oracle Directory Services Manager、JPSなどのOracleコンポーネント、およびOracle以外のコンポーネントから使用可能なLDAPストアです。これらのコンポーネントは、LDAPまたはLDAPSプロトコルを使用してOracle Internet Directoryに接続します。

Oracleディレクトリ・レプリケーション・サーバーはLDAPを使用して、Oracleディレクトリ(LDAP)サーバー・インスタンスと通信します。データベースとの通信には、すべてのコンポーネントでOCI/Oracle Net Servicesを使用します。Oracle Directory Services Managerおよびコマンドライン・ツールは、LDAPを介してOracleディレクトリ・サーバーと通信します。

図8-2は、非高可用性アーキテクチャにおけるOracle Internet Directoryを示しています。

図8-2 非高可用性アーキテクチャのOracle Internet Directory

「図8-2 非高可用性アーキテクチャのOracle Internet Directory」の説明

Oracle Internet Directoryのノードは、同じディレクトリ・ストアに接続された1つ以上のディレクトリ・サーバー・インスタンスで構成されます。ディレクトリ・ストア、つまりディレクトリ・データのリポジトリは、Oracle Databaseになります。

図8-2は、単一ノードで実行される様々なディレクトリ・サーバーの要素とその関係を示しています。

Oracle Net Servicesは、Oracle Databaseサーバーと次に示すものとの間のすべての接続に使用されます。

- Oracleディレクトリ・サーバーの非SSLポート(このトポロジでは389)

- Oracleディレクトリ・サーバーのSSL対応ポート(このトポロジでは636)

- OIDモニター

LDAPは、ディレクトリ・サーバーと次に示すものとの間の接続に使用されます。

- Oracle Directory Services Manager

- Oracleディレクトリ・レプリケーション・サーバー

Oracleディレクトリ・サーバー・インスタンスとOracleディレクトリ・レプリケーション・サーバーは、オペレーティング・システムを経由してOIDモニターに接続します。

図8-2に示すように、Oracle Internet Directoryのノードには次の主要な要素が組み込まれています。

表8-4 Oracle Internet Directoryのノード

要素

説明

Oracleディレクトリ・サーバー・インスタンス

LDAPサーバー・インスタンスまたはディレクトリ・サーバー・インスタンスとも呼びます。特定のTCP/IPポートをリスニングする単一のOracle Internet Directoryのディスパッチャ・プロセスを介してディレクトリ・リクエストに応じます。異なるポートをリスニングする1つ以上のディレクトリ・サーバー・インスタンスが同一ノードに存在する場合もあります。

Oracleディレクトリ・レプリケーション・サーバー

レプリケーション・サーバーとも呼びます。別のOracle Internet Directoryシステムにあるレプリケーション・サーバーに対する変更の追跡と送信を行います。1つのノードのレプリケーション・サーバーは、1つに限られます。レプリケーション・サーバーを構成するかどうかは選択できます。同一データベースを使用するOracle Internet Directoryに複数のインスタンスがある場合、そのうちの1つのみがレプリケーションを実行できます。これは、Oracle Internet Directoryインスタンスが複数のノードに存在する場合も同様です。

レプリケーション・サーバー・プロセスは、Oracle Internet Directory内のプロセスです。レプリケーションが構成されている場合にのみ実行されます。

Oracle Internet Directoryのレプリケーションの詳細は、第10章「高可用性を最大化するIdentity Managementの構成」を参照してください。

Oracle Databaseサーバー

ディレクトリ・データを格納します。ディレクトリ専用のデータベースとすることを強くお薦めします。データベースは、ディレクトリ・サーバー・インスタンスと同じノードに配置できます。

Oracle Process Manager and Notification Server(OPMN)

Oracle Fusion Middlewareのコンポーネントの1つとしてOracle Internet Directoryを管理します。OPMNは、ORACLE_INSTANCE/opmn.xmlのOIDコンポーネント・スニペットのディレクティブを使用して、必要に応じてOIDMONとOIDCTLを呼び出します。コマンドライン・ユーティリティは、opmnctlです。

OIDモニター(OIDMON)

LDAPサーバーとレプリケーション・サーバー・プロセスの起動、監視および終了を行います。oidctl、opmnctlなどのプロセス管理コマンドを呼び出す場合、またはFusion Middleware Controlを使用してサーバー・インスタンスを起動または停止する場合は、このプロセスによってコマンドが解釈されます。

OIDMONはサーバーを監視し、異常のため実行を停止した場合はそのサーバーを再起動します。

OIDMONは、OIDLDAPDのデフォルト・インスタンスを起動します。OIDCTLコマンドを使用してOIDLDAPDのデフォルト・インスタンスが停止された場合、OIDMONがそのインスタンスを停止します。OPMNによってOIDMONが再起動された場合、OIDMONはデフォルト・インスタンスを再起動します。

OIDモニターのアクティビティはすべて、ファイルORACLE_INSTANCE/diagnostics/log/OID/component_id/oidmon-xxxx.logに記録されます。このファイルは、Oracle Internet Directoryサーバー・ファイル・システムにあります。

OIDモニターは、オペレーティング・システムのメカニズムを介して、サーバーの状態をチェックします。

OID制御ユーティリティ(OIDCTL)

Oracle Internet Directoryサーバーの表にメッセージ・データを配置して、OIDモニターと通信します。このメッセージ・データには、各Oracleディレクトリ・サーバー・インスタンスの実行に必要な構成パラメータが含まれます。通常は、コマンドラインからのレプリケーション・サーバーの停止と起動のみに使用されます。

8.3.1.1 Oracle Internet Directoryコンポーネントの特性

Oracle Internet Directoryは、OracleのLDAPストアであり、データベースを永続ストアとして使用するCベースのコンポーネントです。これはステートレスなプロセスで、すべてのデータと構成情報の大部分をバックエンド・データベースに格納します。データベースへの接続には、Oracle Net Servicesを使用します。

8.3.1.1.1 ランタイム・プロセス

Oracle Internet Directoryには、次のランタイム・プロセスがあります。

- OIDLDAPD: Oracle Internet Directoryのメイン・プロセスです。OIDLDAPDは、ディスパッチャ・プロセスとサーバー・プロセスで構成されます。ディスパッチャ・プロセスは、起動時にOIDLDAPDサーバー・プロセスを作成します。各OIDLDAPDディスパッチャ・プロセスには、リクエストを受信するための固有のSSLポートおよび非SSLポートがあります。デフォルトでは、各OIDインスタンスにはディスパッチャとサーバー・プロセスが1つずつあります。1つのインスタンスに作成されるサーバー・プロセスの数は、orclserverprocs属性によって制御されます。

- OIDMON: OIDMONは、Oracle Internet Directoryインスタンスのプロセス制御を行います。このプロセスは、Oracle Internet Directoryの起動、停止および監視を行います。OIDMONは起動時にOIDLDAPDディスパッチャ・プロセスを作成し、インスタンスにレプリケーションが構成されている場合はレプリケーション・サーバー・プロセスも作成します。

- レプリケーション・サーバー・プロセス: Oracle Internet Directory内のプロセスで、レプリケーションが構成されている場合にのみ実行されます。レプリケーション・サーバー・プロセスは、起動時にOIDMONによって作成されます。

- OPMN: Oracle Process Manager and Notification Server(OPMN)は、Oracle Internet DirectoryなどのOracle Fusion Middlewareコンポーネントを監視するデーモン・プロセスです。Oracle Enterprise Manager Fusion Middleware ControlはOPMNを使用して、Oracle Internet Directoryのインスタンスの停止と起動を行います。Oracle Internet Directoryコンポーネントの停止と起動をコマンドラインから行う場合は、OPMNに対するコマンドライン・インタフェースであるopmnctlを使用します。
OPMNは、OIDMONを直接、起動、停止、再起動、および監視します。サーバー・プロセスを直接起動または停止することはありません。

8.3.1.1.2 プロセスのライフサイクル

OPMNは、デーモン・プロセスOIDMON(ORACLE_HOME/bin/oidmon)を直接、起動、停止、再起動、および監視します。OIDMONは、Oracle Internet Directoryインスタンスのプロセスを制御します。11gリリース1(11.1.1)では、同一ノードの同一Oracleインスタンスに複数のOracle Internet Directoryインスタンスを設定できます。詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドを参照してください。

プロセス・ステータス表

Oracle Internet Directoryのプロセス情報は、ODSデータベース・ユーザー・スキーマのODS_PROCESS_STATUS表で管理されます。OIDMONは、指定された間隔で表の内容を読み取り、その表の内容が伝える目的に従って動作します。この間隔は、OIDMON起動時に使用されたスリープ・コマンド・ラインの引数の値によって制御されます。デフォルト値は10秒です。

Oracle Internet Directoryの起動と停止

Oracle Enterprise Manager Fusion Middleware Controlまたはコマンドopmnctlを使用して、Oracle Internet Directoryインスタンスの起動と停止ができます。

プロセスの起動

Oracle Internet Directoryの起動プロセスは次のとおりです。

1. 起動コマンドを受信すると、OPMNはopmn.xmlファイルで指定された適切な引数を使用してoidmon起動コマンドを発行します。

2. これにより、OIDMONは、ODS_PROCESS_STATUS表内の情報で状態の値が1または4、かつORACLE_INSTANCE、COMPONENT_NAME、INSTANCE_NAMEの値がOPMNによって設定された環境パラメータと一致するすべてのOracle Internet Directoryサーバー・インスタンスを起動します。

プロセスの停止

Oracle Internet Directoryの停止プロセスは次のとおりです。

1. 停止コマンドを受信すると、OPMNは、oidmon停止コマンドを発行します。

2. ODS_PROCESS_STATUS表内で環境パラメータORACLE_INSTANCE、COMPONENT_NAME、およびINSTANCE_NAMEに一致する各行に対して、oidmon停止コマンドがOIDMON、OIDLDAPD、およびOIDREPLDの各プロセスを停止し、状態を4に更新します。

監視

OPMNは、サーバー・プロセスを直接監視しません。OPMNはOIDMONを監視し、OIDMONがサーバー・プロセスを監視します。イベントは次のとおりです。

- OPMNを介してOIDMONを起動すると、OPMNはOIDMONを起動し、OIDMONが実行中であることを確認します。

- なんらかの理由でOIDMONが停止すると、OPMNによって再起動されます。

- OIDMONは、Oracle Internet Directoryディスパッチャ・プロセス、LDAPサーバー・プロセス、およびレプリケーション・サーバー・プロセスのステータスを監視し、このステータスをOPMNとOracle Enterprise Manager Fusion Middleware Controlで使用できるようにします。

8.3.1.1.3 リクエスト・フロー

Oracle Internet Directoryプロセスが起動すると、クライアントはLDAPまたはLDAPSプロトコルを使用してOracle Internet Directoryにアクセスします。Oracle Internet Directoryインスタンスの起動時に、他の実行インスタンスへの影響はありません。

Oracle Internet Directoryリスナー/ディスパッチャは、起動時に構成された数のサーバー・プロセスを起動します。サーバー・プロセスの数は、インスタンス固有の構成エントリ内のorclserverprocs属性によって制御されます。orclserverprocsのデフォルト値は1です。Oracle Internet Directoryでは複数のサーバー・プロセスによって、マルチ・プロセッサ・システムのメリットが得られます。

Oracle Internet Directoryのディスパッチャ・プロセスは、Oracle Internet Directoryのサーバー・プロセスに対するLDAP接続をラウンドロビン方式で送信します。各サーバーで受入れ可能なLDAP接続の最大数は、デフォルトでは1024です。この数は、インスタンス固有の構成エントリ内の属性orclmaxldapconnsを変更して増やせます。このDNの形式は次のとおりです。

cn=componentname,cn=osdldapd,cn=subconfigsubentry

各サーバー・プロセスからのデータベース接続は、インスタンス構成パラメータORCLMAXCCおよびORCLPLUGINWORKERSに設定された値に応じてサーバーの起動時に作成されます。各サーバーで作成されるデータベース接続の数は、ORCLMAXCC + ORCLPLUGINWORKERS + 2と等しくなります。Oracle Internet Directoryのサーバー・プロセスはOracle Net Servicesを介してOracle Databaseサーバーと通信します。Oracle Net Servicesリスナー/ディスパッチャは、リクエストをOracle Databaseに中継します。詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。

8.3.1.1.4 構成アーティファクト

記憶域の配置にはDB接続文字列が必要です。TNSNAMES.ORAは、ORACLE_INSTANCE/configに保存されます。ウォレットはORACLE_INSTANCE/OID/adminに保存されます(DB ODSユーザー・パスワードはウォレットに格納されます)。

8.3.1.1.5 外部依存性

Oracle Internet Directoryでは、データと同様に構成情報の格納にもOracle Databaseを使用します。この情報の格納にはODSスキーマを使用します。

Oracleディレクトリ・レプリケーション・サーバーはLDAPを使用して、Oracleディレクトリ(LDAP)サーバー・インスタンスと通信します。データベースとの通信には、すべてのコンポーネントでOCI/Oracle Net Servicesを使用します。Oracle Directory Services Managerおよびコマンドライン・ツールは、LDAPを介してOracleディレクトリ・サーバーと通信します。

8.3.1.1.6 Oracle Internet Directoryのログ・ファイル

Oracle Internet Directoryのログ・ファイルは、次のディレクトリにあります。

ORACLE_INSTANCE/diagnostics/log/OID

表8-5は、Oracle Internet Directoryのプロセスとログ・ファイル名、およびプロセスの場所を示しています。

表8-5 Oracle Internet Directoryのプロセス・ログ・ファイルの場所

プロセス

ログ・ファイルの場所

ディレクトリ・サーバー(oidldapd)

ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidldapd00sPID-XXXX.log。ここで:

00はインスタンス番号です(デフォルトは00)。

sはサーバーを表します。

PIDはサーバー・プロセス識別子です。

XXXXは、0000からorclmaxlogfilesconfiguredまでの数値です。orclmaxlogfilesconfigured値に達すると、再び0000から開始されます。この開始時にはファイルは0バイトに切り捨てられます。

ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidstackInstNumberPID.log

LDAPディスパッチャ(oidldapd)

ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidldapd00-XXXX.log。ここで:

00はインスタンス番号です(デフォルトは00)。

XXXXは、0000からorclmaxlogfilesconfiguredまでの数値です。

OIDモニター(OIDMON)

ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidmon-XXXX.log。ここで:

XXXXは、0000からorclmaxlogfilesconfiguredまでの数値です。

ディレクトリ・レプリケーション・サーバー(oidrepld)

ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidrepld-XXXX.log。ここで:

XXXXは、0000からorclmaxlogfilesconfiguredまでの数値です。

ログ・ファイルを使用したOracle Internet Directoryの問題のトラブルシューティングの詳細は、第8.3.6項「Oracle Internet Directoryの高可用性のトラブルシューティング」を参照してください。

8.3.2 Oracle Internet Directoryの高可用性の概要

この項では、Oracle Internet Directoryを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。前提条件については、第8.3.2.3項「Oracle Internet Directoryの前提条件」を、2ノードのクラスタ構成を設定するための固有の手順については、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。

8.3.2.1 Oracle Internet Directoryの高可用性アーキテクチャ

図8-3は、Oracle Internet Directoryクラスタ構成のアクティブ/アクティブ構成における高可用性アーキテクチャを示しています。

図8-3 Oracle Internet Directoryクラスタ構成の高可用性アーキテクチャ

「図8-3 Oracle Internet Directoryクラスタ構成の高可用性アーキテクチャ」の説明

図8-3では、クラスタ構成の高可用性アーキテクチャのディレクトリ層にOracle Internet Directoryがあります。クラスタ化はインストール時に設定されます。ロード・バランシング・ルーターによってLDAPクライアント・リクエストが2つのOracle Internet Directoryインスタンスにルーティングされます。この2つのインスタンスは、OIDHOST1とOIDHOST2上にあり、クラスタ化されています。

Oracle RACデータベースをセキュリティ・メタデータ・リポジトリとして使用しているOracle Internet Directoryインスタンスの接続には、透過的アプリケーション・フェイルオーバー(TAF)が使用されます。Oracle RACデータベースは、TNSNAMES.ORAに構成されます。高可用性イベント通知は、Oracle RACインスタンスが使用不可となった場合の通知に使用されます。Oracle RACでOracle Internet Directoryを使用する方法の詳細は、第4.1.7.1項「Oracle Internet Directory」を参照してください。

8.3.2.1.1 クラスタの起動と停止

クラスタ構成では、各Oracle Internet Directoryインスタンスの起動にOPMNコマンドを使用します。起動時にOracle Internet Directoryへの影響はありません。Oracle Internet Directoryの起動時に新しいデータベース接続が作成されます。

OPMNを使用してクラスタを停止すると、Oracle Internet Directoryは、データベースとの接続を切断し、Oracle Internet Directoryサーバーが停止します。

8.3.2.1.2 クラスタワイドの構成変更

構成の変更は、クラスタ構成内のすべてのインスタンスに対してクラスタ・レベルで行われます。同じデータベースを共有するクラスタ構成内のノードはすべて同じ構成情報を読み込みます。OIDMONプロセスは、各Oracle Internet Directoryサーバーの構成変更をポーリングし、構成変更に関するデータベース・リポジトリを更新します。OIDMONおよびその他のOracle Internet Directoryサーバーは、データベース・リポジトリから変更を取得します。このようにして、クラスタ・メンバー・レベルで加えられた変更はすべて、クラスタ内のすべてのOracle Internet Directoryサーバーに伝播されます。

Oracle Internet Directory LDAPサーバーの構成に必要なインスタンス固有の構成属性は、次のLDAPエントリに格納されます。

cn=<component-name>,cn=configsets,cn=osdldapd,cn=subconfigsubentry

Oracle Internet Directoryサーバー構成の各面(サーバー数、データベース接続、サイズ制限、時間制限など)は、インスタンス固有のサーバー構成エントリに含まれます。

クラスタ内のすべてのOracle Internet Directoryインスタンスに共通の構成属性は、次のLDAPエントリに格納されます。

cn=dsaconfig,cn=configsets,cn=osdldapd,cn=oracle internet directory

クラスタ内の各Oracle Internet Directoryインスタンスに対してインスタンス固有のサーバー構成属性を保持する場合は、インストール時/構成時に各Oracle Internet Directoryインスタンスに対して個別のOracle Internet Directoryコンポーネント名を選択する必要があります(ノード1はoid1、ノード2はoid2など)。この場合、構成エントリは、それぞれcn=oid1,cn=osdldapd,cn=subconfigsubentryおよびcn=oid2,cn=osdldapd,cn=subconfigsubentryとなり、Oracle Internet Directoryインスタンスごとに更新する必要があります。

一方、クラスタ内のOracle Internet Directoryインスタンスの両方に共通のサーバー構成属性セットを使用するように選択した場合は、Oracle Internet Directoryインスタンスの両方に同じOracle Internet Directoryコンポーネント名を選択する必要があります(Oracle Internet Directoryのノード1とノード2の両方にoid1を使用するなど)。この場合、cn=oid1,cn=osdldapd,cn=subconfigsubentryのように、共通の構成エントリになります。

Oracle Internet Directory LDAPサーバー・インスタンスは、スキーマ、ACL、パスワード・ポリシーなど、特定のLDAPメタデータ・アーティファクトをキャッシュします。任意のノードにある複数のOracle Internet Directory LDAPサーバー・プロセスは、各ノードのOracle Internet Directoryで管理される共有メモリー・セグメントに関して構築されるセマンティックを介して、キャッシュの同期を管理します。OIDMONは、ノード間の共有メモリー・セグメントの同期を保証することで、ノード間のキャッシュの同期を管理します。これはOracle Internet Directoryデータベースを使用して実現されます。

Oracle Internet Directoryでは、メタデータもキャッシュされ、メタデータの変更によって、ノード間の通知がトリガーされます。メタデータの変更にはldapmodifyユーティリティを使用します。メタデータ変更に関するldapmodifyリクエストを取得したOracle Internet Directoryサーバーは、他のOracle Internet Directoryサーバーに対してメタデータの変更を通知します(OIDMONを含む)。OIDMONは、他のノードのOIDMONにメタデータの変更を通知する役割を持ちます。

8.3.2.2 障害からの保護および予想される動作

この項では、Oracle Internet Directoryクラスタ構成における様々な障害からの保護について説明します。

8.3.2.2.1 Oracle Internet Directoryプロセスの障害

OIDMONは、Oracle Internet Directoryプロセスを監視します。Oracle Internet Directoryプロセスが停止すると、OIDMONが再起動を試行します。

OPMNはOIDMONを監視します。OIDMONが停止すると、OPMNがOIDMONを再起動します。

Oracle Internet Directoryプロセスを再起動できない場合は、フロントエンドのロード・バランシング・ルーターによってクラスタ構成内のOracle Internet Directoryインスタンスの障害が検出され、障害が発生していないインスタンスにLDAPトラフィックがルーティングされます。障害が発生した場合、LDAPクライアントによってトランザクションが再試行されます。トランザクションの途中でインスタンスに障害が発生した場合は、そのトランザクションはデータベースにコミットされません。障害が発生したインスタンスが再起動すると、ロード・バランシング・ルーターによってこれが検出され、すべてのインスタンスにリクエストがルーティングされます。

クラスタ構成内のOracle Internet Directoryインスタンスが停止すると、ロード・バランシング・ルーターによってこれが検出され、障害が発生していないインスタンスにリクエストがルーティングされます。

2ノードのクラスタ構成で一方のOracle Internet Directoryインスタンスに障害が発生した場合(またはインスタンスをホストするコンピュータの一方に障害が発生した場合)は、ロード・バランシング・ルーターによって、障害が発生していないOracle Internet Directoryインスタンスにクライアントがルーティングされます。

8.3.2.2.2 障害発生時に予想されるクライアント・アプリケーションの動作

通常、Oracle Internet Directoryサーバーの障害は、Oracle Internet Directoryクライアントに対して透過的です。これは、ロード・バランサを介してクライアントへのルーティングが継続されるためです。通常、外部ロード・バランサはOracle Internet Directoryプロセスのヘルス・チェックを実行するように構成されます。プロセスが利用不可であることをロード・バランサが検出する前にリクエストが受信されると、クライアント・アプリケーションでエラーを受信することがあります。クライアント・アプリケーションが再試行した場合、ロード・バランサは、これを正常なOracle Internet Directoryインスタンスにルーティングし、リクエストは正常に行われます。

Oracle Internet Directoryのアクティブ/アクティブ構成では、フェイルオーバー時にLDIFファイルを介してldapadd操作を実行していると、ロード・バランサ・ホストとポートを介して実行している場合でも、この操作がエラーになることがあります。これは、Oracle Internet Directoryが一瞬停止するためです。ほとんどのアプリケーションには、固定回数の接続を再試行する機能があるためこの問題は発生しません。

8.3.2.2.3 外部依存性の障害

この項では、Oracle Internet Directoryに利用できるデータベース障害からの保護について説明します。

デフォルトでは、Oracle Internet DirectoryのORACLE_INSTANCEで構成されたtnsnames.oraファイルによって、Oracle Internet Directoryからデータベースへの接続はOracle RACデータベース・インスタンス間でロード・バランシングされることが保証されます。たとえば、Oracle Internet Directoryインスタンスが4つのデータベース接続を確立した場合、各データベース・インスタンスに対して接続が2つ確立されます。

Oracle Internet Directoryは、データベースの高可用性イベント通知を使用してデータベースのノード障害を検出し、障害が発生していないノードへフェイルオーバーします。

透過的アプリケーション・フェイルオーバー(TAF)が構成されている場合は、データベース・インスタンスの障害発生時に、Oracle Internet Directoryが正常に稼働しているデータベース・インスタンスにデータベース接続をフェイルオーバーします。これにより、フェイルオーバー時に行われていたLDAPの検索操作が継続されます。

透過的アプリケーション・フェイルオーバー(TAF)と高可用性イベント通知の両方が構成されている場合は、フェイルオーバーには透過的アプリケーション・フェイルオーバー(TAF)が使用され、高可用性イベント通知は、イベントの記録にのみ使用されます。高可用性イベント通知は、OIDLDAPDログ・ファイルに記録されます。

Oracle Internet Directoryには、失効したデータベース接続を検出するメカニズムもあり、これにより、データベースへの再接続が可能になります。

いずれのデータベース・インスタンスも使用できない状態が長く続いた場合は、Oracle Internet DirectoryのLDAPおよびREPLの各プロセスは自動的に停止します。ただし、OIDMONとOPMNは、データベース・インスタンスの可用性に対してpingを継続し、データベースが使用可能になると、OIDMONによってOracle Internet Directoryのプロセス(LDAPとREPL)が自動的に再起動されます。

すべてのデータベース・インスタンスが停止している場合でも、OIDMONは実行を継続し、opmnctl statusコマンドによってOIDLDAPDインスタンスの停止が示されます。データベース・インスタンスが利用可能になると、OIDMONは構成されているすべてのOracle Internet Directoryインスタンスを再起動します。

Oracle Internet Directoryのアクティビティに起因するデータベースのフェイルオーバーはすべて、OIDMONログ・ファイルに記録されます。

8.3.2.3 Oracle Internet Directoryの前提条件

この項では、Oracle Internet Directoryの高可用性アーキテクチャを設定するための前提条件について説明します。

8.3.2.3.1 Oracle Internet Directoryノード間での時間の同期

高可用性環境でOracle Internet Directoryを設定する前に、各Oracle Internet Directoryのノードの時間が同期していることを確認しておく必要があります。

グリニッジ標準時を使用して全ノードの時間を同期し、ノード間で250秒を超える差異が発生しないようにします。

OIDモニターが2つのノード間で250秒を超える時間の差異を検出すると、遅れているノードのOIDモニターがそのノード上のすべてのサーバーを停止します。この問題を修正するには、遅れているノードの時間を正しい時間に同期させます。OIDモニターはシステム時間の変更を自動的に検出して、そのノードのOracle Internet Directoryサーバーを起動します。

2つ以上のノードがある場合は同様の動作が続きます。たとえば、3つのノードがあり、1つ目のノードが2つ目のノードより150秒進み、2つ目のノードは3つ目のノードより150秒進んでいるとします。この場合、3つ目のノードは最初のノードから300秒遅れているため、OIDモニターは時間が同期するまで3つ目のノードのサーバーを起動しません。

8.3.2.3.2 RCUを使用したリポジトリへのOracle Internet Directoryスキーマの作成

OIDHOST1およびOIDHOST2にOracle Internet Directoryインスタンスをインストールする前に、リポジトリ作成ユーティリティ(RCU)の最新バージョンを使用して、Oracle Identity ManagementおよびManagement Serviceで使用するスキーマのコレクションを作成します。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

次の手順に従って、RCUを実行し、Oracle RACデータベース・リポジトリにアイデンティティ管理スキーマを作成します。

1. 次のコマンドを発行します。
prompt> RCU_HOME/bin/rcu &

2. 「ようこそ」画面で「次へ」をクリックします。

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

4. 「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。
データベース・タイプ: Oracle Database

ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: INFRADBHOST1-VIPまたはINFRADBHOST2-VIP

ポート: データベースのポート番号。例: 1521

サービス名: データベースのサービス名。例: oid.mycompany.com

ユーザー名: SYS

パスワード: SYSユーザーのパスワード

ロール: SYSDBA

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

5. 「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: idm(「コンポーネント」フィールドで「アイデンティティ管理」(Oracle Internet Directory - ODS)しか選択していない場合は、接頭辞の入力はオプションです)。

コンポーネント: 「アイデンティティ管理」(Oracle Internet Directory - ODS)を選択します。その他のスキーマは選択を解除します。

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

6. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。

7. 「表領域のマップ」画面で、コンポーネントの表領域を選択します。

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

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

8.3.2.3.3 Oracle Internet Directory用のロード・バランサの仮想サーバー名

Oracle Internet Directoryを高可用性構成でデプロイする場合は、Oracle Internet Directoryインスタンスのフロントエンドに外部ロード・バランサを使用して、各種Oracle Internet Directoryインスタンス間のリクエストをロード・バランシングすることをお薦めします。

詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。

8.3.3 Oracle Internet Directoryの高可用性の構成手順

Oracle Internet Directoryは、スタンドアロン・モードまたはWebLogic Serverドメインの一部として可用性の高い構成にデプロイできます。

Oracle Internet Directoryの全体をコマンドライン・ツールで管理し、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Directory Services Managerが必須ではないと判断される場合は、スタンドアロン・モードのデプロイを選択する必要があります。必要な場合は、後から、opmnctlコマンドを使用してリモートのOracle WebLogic ServerドメインにスタンドアロンのOracle Internet Directoryインスタンスを登録できます。Oracle Enterprise Manager Fusion Middleware ControlとOracle Directory Services Managerを使用して、Oracle WebLogic Serverドメインで構成されたOracle Internet Directoryインスタンスを管理できます。

Oracle Internet Directoryをクラスタ・デプロイメント内に設定することをお薦めします。クラスタ化されたOracle Internet Directoryインスタンスは、同じOracle RACデータベース・リポジトリにアクセスします。

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

この章では、Oracle Identity Management用にOracle WebLogic Server(WL_HOME)およびOracleホーム(ORACLE_HOME)に必要なバイナリをインストールする方法について説明します。

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

8.3.3.1.1 Oracle WebLogic Serverのインストール

このインストール手順では、最初にOracle WebLogic Serverをインストールします。

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイドにあります。

Oracle WebLogic Serverインストーラを起動します。

インストーラが起動したら、次の手順に従ってOracle WebLogic Serverをコンピュータにインストールします。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。次に、Oracle WebLogicソフトウェアのインストール先となるコンピュータ上のディレクトリを選択します。
「ミドルウェア・ホーム・ディレクトリ」に、次の値を指定します。

/u01/app/oracleproduct/fmw

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

3. 「セキュリティ更新のための登録」画面で、「My Oracle Support」のユーザー名とパスワードを入力して、セキュリティ・アップデートが通知されるようにします。

4. 「インストール・タイプの選択」画面では、完全インストールとカスタム・インストールのどちらを実行するかを指示するように求めるプロンプトが、インストール・プログラムによって表示されます。
「カスタム」を選択します。

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

5. 「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。

6. 「製品インストール・ディレクトリの選択」画面で、ディレクトリ/u01/app/oracle/fmw/wlserver_10.3を受け入れます。
「次へ」をクリックします。

7. 「インストール・サマリー」画面に、インストール対象として選択したコンポーネントの一覧と、それらをインストールするために使用されるディスク領域の概算値が表示されます。
「次へ」をクリックします。

8. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除します。
「完了」をクリックします。

8.3.3.1.2 アイデンティティ管理用のOracle Fusion Middlewareのインストール

次の手順は、Oracle Fusion Middlewareコンポーネントをインストールすることです。

注意:

インストールは共有記憶域で実行されるため、トポロジの残りのサーバーからは2つのMW_HOMEインストールにアクセスし、使用できます。

システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合、この手順をスキップできます。

Oracle Fusion Middlewareコンポーネント用のインストーラを起動します。

UNIXの場合は、次のコマンドを発行します。

HOST1> runInstaller

Windowsの場合は、setup.exeをダブルクリックします。

インストールを開始する前に、次の環境変数が設定されていないことを確認してください。

- LD_ASSUME_KERNEL

- ORACLE_INSTANCE

「インベントリ・ディレクトリの指定」画面で、次の操作を行います。

- HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

- インストールを実行するユーザーのOSグループを入力します。「次へ」をクリックします。

UNIXのインストールの場合は、画面の手順に従ってrootとしてcreateCentralInventory.shを実行します。

「OK」をクリックします。

次の手順を実行します。

1. Oracleインベントリ・ディレクトリの指定画面で、HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。
インストールを実行するユーザーのOSグループを入力します。

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

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「インストール・タイプの選択」画面で、インストール-構成しないを選択します。
「次へ」をクリックします。

4. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

5. 「インストール場所の指定」画面で、次の値を入力します。
MW_HOME: MW_HOMEの値を入力します。例:

/u01/app/product/fmw

ドロップダウン・リストから、すでにインストールされているMiddlewareホームを選択します。「Oracleホーム」ディレクトリには、ディレクトリ名IDMを入力します。

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

6. 「サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。

7. 「インストール完了」画面で「終了」をクリックします。

8.3.3.1.3 Oracle Identity Managementのアップグレード

この項では、Oracle Identity Managementソフトウェアをアップグレードする手順について説明します。詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』のOracle Fusion Middlewareの最新パッチ・セットの適用に関する項を参照してください。

1. ./runinstallerを実行してIDMアップグレード・インストーラを起動します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「前提条件のチェック」画面で、「次へ」をクリックします。

4. 「インストール場所の指定」画面で、Oracle MiddlewareホームへのパスとOracleホーム・ディレクトリの名前を入力します。

5. 「インストール・サマリー」画面で、選択内容を確認して「インストール」をクリックします。

6. 「インストールの進行状況」画面に、インストールの進行状況が示されます。
インストールが終了すると、oracleRoot.shの確認ダイアログ・ボックスが表示されます。このダイアログ・ボックスは、インストールを続行する前に構成スクリプトをrootユーザーとして実行する必要があることを示しています。確認ダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootユーザーとしてログインして、スクリプト・ファイル/u01/app/oracle/product/fmw/id/oracleRoot.shを実行します。スクリプトが完了したら、確認ダイアログ・ボックスの「OK」をクリックします。

7. 「インストール完了」画面で「終了」をクリックして終了します。

8.3.3.2 WebLogicドメインを使用しないOracle Internet Directoryの構成

この項では、WebLogic Serverドメインを使用せずにOracle Internet Directoryをデプロイする手順について説明します。

8.3.3.2.1 OIDHOST1でのOracle Internet Directoryの構成

スキーマ・データベースが実行中であり、RCUを使用してODSデータベース・スキーマをシードしてあることを確認してから、次の手順に従ってOIDHOST1上のOracle Internet Directoryインスタンスを構成します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIDHOST1にインストールされ、アップグレードされていることを確認します。

3. 使用しているオペレーティング・システムに対して次のコマンドを発行して、ポート389と636がコンピュータ上の他のサービスに使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":389"

netstat -an | grep LISTEN | grep ":636"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr ":389"

netstat -an | findstr "LISTEN" | findstr ":636"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

/etc/servicesファイルでポート389と636のエントリを削除して、サービスまたはコンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Internet Directoryのポート番号を指定する行は非コメント化)を割り当てます。

# The Non-SSL port for OID
Oracle Internet Directory Port No = 389
# The SSL port for OID
Oracle Internet Directory (SSL) Port No = 636

7. 次のようにして、ORACLE_HOME/binディレクトリの下にあるOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. ドメインの選択画面で、「ドメインなしで構成」を選択して「次へ」をクリックします。

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。

- Oracleホーム・ディレクトリ:

/u01/app/oracle/product/fmw/idm

- Oracleインスタンスの場所:

/u01/app/oracle/admin/oid_instance1

- Oracleインスタンス名:

oid_instance1

注意:

OIDHOST1のOracleホームの場所を示すディレクトリ・ パスが、OIDHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OIDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。

/u01/app/oracle/product/fmw/idm

この場合、OIDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。

/u01/app/oracle/product/fmw/idm

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

11. 「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、「Oracle Internet Directory」を選択し、その他のすべてのコンポーネントの選択を解除して「次へ」をクリックします。

13. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。

14. 「スキーマ・データベースの指定」画面で、既存のスキーマの使用を選択し、次の値を指定します。

- 接続文字列:

infradbhost1-vip.mycompany.com:1521:oiddb1^infradbhost2-vip.mycompany.com:1521:oiddb2@oid.mycompany.com

注意:

Oracle RACデータベースの接続文字列の情報は、host1:port1:instance1^host2:port2:instance2@servicenameの書式で指定する必要があります。

このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。

前述のように指定した情報は、完全で正確である必要があります。具体的には、ホスト、ポート、およびインスタンス名が各Oracle RACインスタンスに正しく指定されている必要があります。また、指定したOracle RACインスタンスのすべてにサービス名が構成されている必要があります。

Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。

- ユーザー名: ODS

- パスワード: ******

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

15. Oracle Internet Directoryの作成画面で、レルムを指定し、管理者(cn=orcladmin)パスワードを入力して、「次へ」をクリックします。

16. 「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。

17. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

18. 「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。

19. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.3.3.2.2 Oracle Identity Managementのインストーラによって割り当てられるOracle Internet Directoryのコンポーネント名

Oracle Identity Management 11gインストーラを使用してOracle Internet Directoryのインストールを実行する場合、インストーラがOracle Internet Directoryインスタンスに割り当てるデフォルトのコンポーネント名はoid1です。このコンポーネント名は変更できません。

このOracle Internet Directoryインスタンスのインスタンス固有の構成エントリは、cn=oid1, cn=osdldapd, cn=subconfigsubentryです。

別のコンピュータ上で2つ目のOracle Internet Directoryのインストールを実行し、そのOracle Internet Directoryインスタンスで1つ目のインスタンスと同じデータベースを使用する場合、インストーラは、同一データベースを使用する他のコンピュータにすでにインストールされているOracle Internet Directoryインスタンスを検出し、2つ目のOracle Internet Directoryインスタンスにはコンポーネント名oid2を割り当てます。

2つ目のOracle Internet Directoryインスタンスのインスタンス固有の構成エントリは、cn=oid2, cn=osdldapd, cn=subconfigsubentryです。エントリcn=oid2, cn=osdldapd, cn=subconfigsubentryのプロパティを変更しても、1つ目のインスタンス(oid1)には影響しません。

さらに別のコンピュータ上に3つ目のOracle Internet Directoryがインストールされ、このインスタンスでも、前の2つのインスタンスと同じデータベースを使用する場合、インストーラは3つ目のOracle Internet Directoryインスタンスにコンポーネント名oid3を割り当てます。同じデータベースを使用する別のホストには、このような方法でコンポーネント名が割り当てられます。

すべてのOracle Internet Directoryインスタンスで共有される構成は、cn=dsaconfig, cn=configsets,cn=oracle internet directoryです。このエントリに変更が加えられた場合は、Oracle Internet Directoryのすべてのインスタンスに影響します。

このネーミング・スキームによって、各Oracle Internet Directoryインスタンスに異なるコンポーネント名が割り当てられるため、Oracle Enterprise Managerを使用してドメインを表示する際に混乱を回避できます。

8.3.3.2.3 OIDHOST2でのOracle Internet Directoryの構成

Oracle Internet Directoryリポジトリが実行されていることを確認してから、次の手順に従ってOIDHOST2上のOracle Internet Directoryインスタンスを構成します。

注意:

この項で説明する手順は、11g Oracle Identity Managementの高可用性構成でOracle Internet Directoryをスケール・アウトするときにも使用できます。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIDHOST2にインストールされ、アップグレードされていることを確認します。

3. OIDHOST1では、Oracle Internet Directoryによってポート389と636が使用されています。OIDHOST2のOracle Internet Directoryインスタンスにも同じポートを使用する必要があります。したがって、 ポート389および636がOIDHOST2上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに応じて次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":389"

netstat -an | grep LISTEN | grep ":636"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr ":389"

netstat -an | findstr "LISTEN" | findstr ":636"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

/etc/servicesファイルでポート389と636のエントリを削除して、サービスまたはコンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Internet Directoryのポート番号を指定する行は非コメント化)を割り当てます。

# The Non-SSL port for OID
Oracle Internet Directory Port No = 389
# The SSL port for OID
Oracle Internet Directory (SSL) Port No = 636

7. 次のようにして、ORACLE_HOME/binディレクトリの下にあるOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. ドメインの選択画面で、「ドメインなしで構成」を選択して「次へ」をクリックします。

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。

- Oracleホーム・ディレクトリ:

/u01/app/oracle/product/fmw/idm

- Oracleインスタンスの場所:

/u01/app/oracle/admin/oid_instance2

- Oracleインスタンス名:

oid_instance2

注意:

OIDHOST2のOracleホームの場所を示すディレクトリ パスが、OIDHOST1のOracleホームの場所を示すパスと同じであることを確認します。たとえば、OIDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。

/u01/app/oracle/product/fmw/idm

この場合、OIDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。

/u01/app/oracle/product/fmw/idm

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

11. 「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、「Oracle Internet Directory」を選択し、その他のすべてのコンポーネントの選択を解除して「次へ」をクリックします。

13. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。

14. 「スキーマ・データベースの指定」画面で、既存のスキーマの使用を選択し、次の値を指定します。

- 接続文字列:

infradbhost1-vip.mycompany.com:1521:oiddb1^infradbhost2-vip.mycompany.com:1521:oiddb2@oid.mycompany.com

注意:

Oracle RACデータベースの接続文字列の情報は、host1:port1:instance1^host2:port2:instance2@servicenameの書式で指定する必要があります。

このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。

前述のように指定した情報は、完全で正確である必要があります。具体的には、ホスト、ポート、およびインスタンス名が各Oracle RACインスタンスに正しく指定されている必要があります。また、指定したOracle RACインスタンスのすべてにサービス名が構成されている必要があります。

Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。

- ユーザー名: ODS

- パスワード: ******

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

15. ODSスキーマが使用中であることを示すメッセージが表示されます。選択したODSスキーマはすでに既存のOracle Internet Directoryインスタンスで使用されています。したがって、構成中の新しいOracle Internet Directoryインスタンスは、この同じスキーマを再利用します。
「はい」を選択して続行します。

16. OID管理者パスワードの指定画面で、OID管理者のパスワードを指定し、「次へ」をクリックします。

17. 「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。

18. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

19. 「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。

20. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.3.3.2.4 WebLogicドメインへのOracle Internet Directoryの登録

Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Internet Directoryコンポーネントを管理する場合は、コンポーネントとそれを含むOracle Fusion MiddlewareインスタンスをOracle WebLogic Serverドメインに登録する必要があります。インストール時またはOracleインスタンスの作成時に、Oracle Fusion MiddlewareインスタンスをWebLogicドメインに登録できますが、必須事項ではありません。

WebLogicドメインにOracle Internet Directoryコンポーネントを登録するには、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのWebLogic ServerにおけるOracle Fusion Middlewareインスタンスまたはコンポーネントの登録に関する説明を参照してください。

8.3.3.3 WebLogicドメインを使用したOracle Internet Directoryの構成

この項では、WebLogic Serverドメインの一部としてOracle Internet Directoryの高可用性構成をデプロイする手順について説明します。

この構成では、1つ目のホストにOracle Internet DirectoryとWebLogic Serverドメインが構成され、2つ目のホストにはOracle Internet Directoryのみが構成されます。2つ目のホストのOracle Internet Directoryインスタンスは、1つ目のホストで作成されたドメインに参加します。

8.3.3.3.1 OIDHOST1でのOracle Internet Directoryの構成

スキーマ・データベースが実行中であり、RCUを使用してODSデータベース・スキーマをシードしてあることを確認してから、次の手順に従ってOIDHOST1上のOracle Internet Directoryインスタンスを構成します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIDHOST1にインストールされ、アップグレードされていることを確認します。

3. 使用しているオペレーティング・システムに対して次のコマンドを発行して、ポート389と636がコンピュータ上の他のサービスに使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":389"

netstat -an | grep LISTEN | grep ":636"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr ":389"

netstat -an | findstr "LISTEN" | findstr ":636"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

/etc/servicesファイルでポート389と636のエントリを削除して、サービスまたはコンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Internet Directoryのポート番号を指定する行は非コメント化)を割り当てます。

# The Non-SSL port for OID
Oracle Internet Directory Port No = 389
# The SSL port for OID
Oracle Internet Directory (SSL) Port No = 636

7. 次のようにして、ORACLE_HOME/binディレクトリの下にあるOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. 「ドメインの選択」画面で、新規ドメインの作成を選択します。次の値を指定します。

- ユーザー名: weblogic

- パスワード: <weblogicユーザーのパスワード>

- パスワードの確認: <weblogicユーザーのパスワードを再度入力します>

- ドメイン名: IDMDomain

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。

- Oracleホーム・ディレクトリ:

/u01/app/oracle/product/fmw/idm

- WebLogic Serverのディレクトリ:

/u01/app/oracle/product/fmw/wlserver_10.3

- Oracleインスタンスの場所:

/u01/app/oracle/admin/oid_inst1

- Oracleインスタンス名:

oid_inst1

注意:

OIDHOST1のOracleホームの場所を示すディレクトリ・ パスが、OIDHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OIDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。

/u01/app/oracle/product/fmw/idm

この場合、OIDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。

/u01/app/oracle/product/fmw/idm

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

11. 「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、「Oracle Internet Directory」を選択し、その他のすべてのコンポーネントの選択を解除して「次へ」をクリックします。

13. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。

注意:

インストーラによって設定されるデフォルトのOracle WebLogic Serverのクラスタ・モードは、(マルチキャストではなく)ユニキャストになります。

14. 「スキーマ・データベースの指定」画面で、既存のスキーマの使用を選択し、次の値を指定します。

- 接続文字列:

infradbhost1-vip.mycompany.com:1521:oiddb1^infradbhost2-vip.mycompany.com:1521:oiddb2@oid.mycompany.com

注意:

Oracle RACデータベースの接続文字列の情報は、host1:port1:instance1^host2:port2:instance2@servicenameの書式で指定する必要があります。

このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。

前述のように指定した情報は、完全で正確である必要があります。具体的には、ホスト、ポート、およびインスタンス名が各Oracle RACインスタンスに正しく指定されている必要があります。また、指定したOracle RACインスタンスのすべてにサービス名が構成されている必要があります。

Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。

- ユーザー名: ODS

- パスワード: ******

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

15. 「OIDの構成」画面で、レルムを指定し、管理者(cn=orcladmin)パスワードを入力して、「次へ」をクリックします。

16. 「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。

17. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

18. 「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。

19. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

注意:

Oracle Identity Management 11gのインストーラによって割り当てられるOracle Internet Directoryコンポーネント名の詳細は、第8.3.3.2.2項「Oracle Identity Managementのインストーラによって割り当てられるOracle Internet Directoryのコンポーネント名」を参照してください。

8.3.3.3.2 OIDHOST1での管理サーバー用boot.propertiesの作成

この項では、OIDHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法について説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。

次の手順に従って、boot.propertiesファイルを作成します。

1. OIDHOST1で、次のディレクトリに移動します。

MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

例:

cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

2. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

username=adminUser
password=adminUserPassword

注意:

管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。

3. 管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。

4. MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OIDHOST1上の管理サーバーを起動します。

5. Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。

- WebLogic Server管理コンソール:

http://oidhost1.mycompany.com:7001/console

- Oracle Enterprise Manager Fusion Middleware Control:

http://oidhost1.mycompany.com:7001/em

weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

8.3.3.3.3 OIDHOST2でのOracle Internet Directoryの構成

Oracle Internet Directoryリポジトリが実行されていることを確認してから、次の手順に従ってOIDHOST2上のOracle Internet Directoryインスタンスを構成します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIDHOST2にインストールされ、アップグレードされていることを確認します。

3. OIDHOST1では、Oracle Internet Directoryによってポート389と636が使用されています。OIDHOST2のOracle Internet Directoryインスタンスにも同じポートを使用する必要があります。したがって、 ポート389および636がOIDHOST2上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに応じて次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":389"

netstat -an | grep LISTEN | grep ":636"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr ":389"

netstat -an | findstr "LISTEN" | findstr ":636"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

/etc/servicesファイルでポート389と636のエントリを削除して、サービスまたはコンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Internet Directoryのポート番号を指定する行は非コメント化)を割り当てます。

# The Non-SSL port for OID
Oracle Internet Directory Port No = 389
# The SSL port for OID
Oracle Internet Directory (SSL) Port No = 636

7. 次のようにして、ORACLE_HOME/binディレクトリの下にあるOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. 「ドメインの選択」画面で、既存ドメインの拡張を選択して、次の値を指定します。

- ホスト名: idmhost1.mycompany.com(WebLogic管理サーバーを実行しているホスト)

- ポート: 7001(これはWebLogic管理サーバーのポートです。)

- ユーザー名: weblogic

- パスワード: <weblogicユーザーのパスワード>

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。

- Oracleホーム・ディレクトリ: idm

- WebLogic Serverのディレクトリ:

/u01/app/oracle/product/fmw/wlserver_10.3

- Oracleインスタンスの場所:

/u01/app/oracle/admin/oid_inst2

- Oracleインスタンス名: oid_inst2

注意:

OIDHOST1のOracleホームの場所を示すディレクトリ・ パスが、OIDHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OIDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。

/u01/app/oracle/product/fmw/idm

この場合、OIDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。

/u01/app/oracle/product/fmw/idm

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

11. 「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、「Oracle Internet Directory」を選択し、「次へ」を選択します。

13. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。

14. 「スキーマ・データベースの指定」画面で、既存のスキーマの使用を選択し、次の値を指定します。

- 接続文字列:

infradbhost1-vip.mycompany.com:1521:oiddb1^infradbhost2-vip.mycompany.com:1521:oiddb2@oid.mycompany.com

注意:

Oracle RACデータベースの接続文字列の情報は、host1:port1:instance1^host2:port2:instance2@servicenameの書式で指定する必要があります。

このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。

前述のように指定した情報は、完全で正確である必要があります。具体的には、ホスト、ポート、およびインスタンス名が各Oracle RACインスタンスに正しく指定されている必要があります。また、指定したOracle RACインスタンスのすべてにサービス名が構成されている必要があります。

Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。

- ユーザー名: ODS

- パスワード: ******

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

15. ODSスキーマが使用中であることを示すメッセージが表示されます。選択したODSスキーマはすでに既存のOracle Internet Directoryインスタンスで使用されています。したがって、構成中の新しいOracle Internet Directoryインスタンスは、この同じスキーマを再利用します。
「はい」を選択して続行します。

16. OID管理者パスワードの指定画面で、Oracle Internet Directory管理者のパスワードを指定し、「次へ」をクリックします。

17. 「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。

18. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

19. 「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。

20. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.3.4 Oracle Internet Directoryの高可用性の検証

ldapbindコマンドライン・ツールを使用して、各Oracle Internet DirectoryインスタンスとLDAP仮想サーバーに接続できることを確認します。ldapbindツールでは、サーバーに対してクライアントを認証できるかどうかを確認できます。

注意:

ldapbindコマンドを使用する前に設定が必要な環境変数の一覧は、Oracle Fusion Middleware Oracle Identity Managementリファレンスで、環境の構成に関する項を参照してください。

非SSLの場合:

ldapbind -h oidhost1.mycompany.com -p 389 -D "cn=orcladmin" -q
ldapbind -h oidhost2.mycompany.com -p 389 -D "cn=orcladmin" -q
ldapbind -h oid.mycompany.com -p 389 -D "cn=orcladmin" -q

注意:

前述の-qオプションを指定すると、ユーザーのパスワードの入力が求められます。LDAPツールでは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定されている場合、-w passwordおよび-P passwordの各オプションが無効になるよう変更されています。可能なかぎり、この機能を使用してください。

SSLの場合:

ldapbind -h oidhost1.mycompany.com -p 636 -D "cn=orcladmin" -q -U 1
ldapbind -h oidhost2.mycompany.com -p 636 -D "cn=orcladmin" -q -U 1
ldapbind -h oid.mycompany.com -p 636 -D "cn=orcladmin" -q -U 1

-Uは、SSL認証モードの指定に使用されるオプション引数です。SSL認証モードに有効な値は次のとおりです。

- 1 = 認証は必要ありません。

- 2 = 一方向認証が必要です。このオプションを使用する場合は、ウォレットの場所(-W "file:/home/my_dir/my_wallet")およびウォレットのパスワード(-P wallet_password)も指定する必要があります。

- 3 = 双方向認証が必要です。このオプションを使用する場合は、ウォレットの場所(-W "file:/home/my_dir/my_wallet")およびウォレットのパスワード(-P wallet_password)も指定する必要があります。

ldapbindコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Managementリファレンスのldapbindに関する項を参照してください。

Oracle Internet Directoryに対するSSLの設定の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのSecure Sockets Layer(SSL)の構成に関する項を参照してください。

次のURLのWebLogic Server管理コンソールにアクセスします。

http://oidhost1.mycompany.com:7001/console

Oracle Enterprise Manager Fusion Middlewareコンソール

http://oidhost1.mycompany.com:7001/em

8.3.5 Oracle Internet Directoryのフェイルオーバーおよび予想される動作

この項では、Oracle Internet DirectoryのフェイルオーバーとOracle RACのフェイルオーバーを実行する手順を説明します。

8.3.5.1 Oracle Internet Directoryのフェイルオーバーの実行

次の手順に従って、Oracle Internet Directoryインスタンスのフェイルオーバーを実行し、Oracle Internet Directoryのステータスを調べます。

1. OIDHOST1で、opmnctlコマンドを使用して、Oracle Internet Directoryインスタンスを停止します。

ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1

2. OIDHOST2で、ロード・バランシング・ルーターを使用して、Oracle Internet Directoryのステータスをチェックします。

注意:

ldapbindコマンドを使用する前に設定が必要な環境変数の一覧は、Oracle Fusion Middleware Oracle Identity Managementリファレンスで、環境の構成に関する項を参照してください。

ldapbind -h oid.mycompany.com -p 389 -D "cn=orcladmin" -q

注意:

前述の-qオプションを指定すると、ユーザーのパスワードの入力が求められます。LDAPツールでは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定されている場合、-w passwordおよび-P passwordの各オプションが無効になるよう変更されています。可能なかぎり、この機能を使用してください。

3. OIDHOST1で、opmnctlコマンドを使用して、Oracle Internet Directoryインスタンスを起動します。

ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running)
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1

4. OIDHOST2で、opmnctlコマンドを使用して、Oracle Internet Directoryインスタンスを停止します。

ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1

5. OIDHOST1で、ロード・バランシング・ルーターを使用して、Oracle Internet Directoryのステータスをチェックします。

ldapbind -h oid.mycompany.com -p 389 -D "cn=orcladmin" -q

6. OIDHOST2で、opmnctlコマンドを使用して、Oracle Internet Directoryインスタンスを起動します。

ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running)
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1

8.3.5.2 Oracle RACフェイルオーバーの実行

次の手順に従って、Oracle RACのフェイルオーバーを実行します。

1. srvctlコマンドを使用して、データベース・インスタンスを停止します。

srvctl stop instance -d db_unique_name -i inst_name_list

2. srvctlコマンドを使用して、データベース・インスタンスのステータスを確認します。

srvctl status database -d db_unique_name -v

3. Oracle Internet Directoryのステータスを確認します。

注意:

ldapbindコマンドを使用する前に設定が必要な環境変数の一覧は、Oracle Fusion Middleware Oracle Identity Managementリファレンスで、環境の構成に関する項を参照してください。

ldapbind -h oid_host -p 389 -D "cn=orcladmin" -q
ldapbind -h oid_host -p 389 -D "cn=orcladmin" -q
ldapbind -h oid.mycompany.com -p 389 -D "cn=orcladmin" -q

注意:

前述の-qオプションを指定すると、ユーザーのパスワードの入力が求められます。LDAPツールでは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定されている場合、-w passwordおよび-P passwordの各オプションが無効になるよう変更されています。可能なかぎり、この機能を使用してください。

4. srvctlコマンドを使用して、データベース・インスタンスを起動します。

srvctl start instance -d db_unique_name -i inst_name_list

8.3.6 Oracle Internet Directoryの高可用性のトラブルシューティング

この項では、Oracle Internet Directoryの高可用性の問題のトラブルシューティングに役立つ情報について説明します。

- Oracle Internet Directoryのログ・ファイルは次のディレクトリにあります。

ORACLE_INSTANCE/diagnostics/log/OID

- トラブルシューティングの際に調査するログ・ファイルの順序は次のとおりです。

1. oidmon-xxx.log

2. oidldapd01-xxxx.log

3. oidldapd01s-xxxx.log

- この項では、高可用性に関連するエラー・メッセージの一部とその意味を示します。
エラー: ログ・ファイルにORA-3112、ORA-3113エラーがあります

原因: データベース・ノードのいずれかが停止し、障害が発生していないノードにOIDが再接続します。

処置: データベース・ノードの停止、またはOracleプロセスの停止の原因を確認します。

エラー: フェイルオーバーしています...ログ・ファイルでスタンバイしてください

原因: OIDサーバーがOracleプロセスからデータベース・ノードのいずれかが停止したことを知らせる通知を受信しました。OIDは障害が発生していないノードに接続します。

フェイルオーバーが正常完了すると、次のメッセージが表示されます。

フェイルオーバーが終了しました...サービスを再開しています

フェイルオーバーが失敗すると、次のようなエラーが表示されます。

a.10回試行しましたが、フェイルオーバー機能を終了しています

b.無効なフェイルオーバー・イベント:

c.セッションのDBパラメータを設定できないため、フェイルオーバーを強制終了しました

高可用性イベント通知が有効な場合は、次のようなメッセージが表示されます。

HA Callback Event
Thread Id: 8
Event type: 0
HA Source: OCI_HA_INSTANCE
Host name: dbhost1
Database name: orcl
Instance name: orcl1
Timestamp: 14-MAY-09 03.25.24 PM -07:00
Service name: orcl.example.com
HA status: DOWN - TAF Capable

TAFが無効な場合、HAステータスは「DOWN」と表示されます。

処置: データベース・ノードが停止した原因を確認します。

エラー: ノード1とノード2の間で250秒以上の時間差異が検出されました.

原因: 2つのノード間の時間に差異があります。

処置: システム時間を同期します。

エラー: ノード=%が構成された%d回までに応答しませんでした。フェイルオーバーしています...

原因: OIDノード(oidmon)のいずれかが応答しません。

処置: ノードが稼働中か、またはOIDMONプロセスが実行中であるかを確認します。

Oracle Internet Directoryのトラブルシューティングの詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドを参照してください。

8.3.7 Oracle Internet Directoryの高可用性に関するその他の問題

この項では、高可用性環境のOracle Internet Directoryに関する問題について説明します。

8.3.7.1 Oracle Internet Directoryで使用されるODSスキーマのパスワードの変更

Oracle Internet Directory Database Password Utility(oidpasswd)を使用すると、どのOracle Internet DirectoryのノードからもOracle Internet Directoryデータベースのスキーマ・パスワード(データベースのODSユーザーのパスワード)を変更できます。ただし、ODSスキーマ・パスワードは、各OIDインスタンスのORACLE_INSTANCEにあるパスワード・ウォレットに格納されるため、それぞれのOracle Internet Directoryノードでパスワード・ウォレットを更新する必要があります。

ODSデータベース・ユーザー・パスワードを変更するには、いずれかのOracle Internet Directoryノードから次のコマンドを呼び出します。

oidpasswd connect=database-connection-string change_oiddb_pwd=true

その他のすべてのOracle Internet Directoryノードで、次のコマンドを呼び出して、パスワード・ウォレットを同期化します。

oidpasswd connect=database-connection-string create_wallet=true

OID Database Password Utility(oidpasswd)を使用して、Oracle RACノードの1つでODSパスワードを変更する場合は、次のいずれかを実行して、他のOracle RACノードのウォレットORACLE_HOME/ldap/admin/oidpwdlldap1を更新する必要があります。

- その他のすべてのノードでOID Database Password Utilityを起動して、ウォレット・ファイルのみを更新します。これは、レプリケーション・パスワードの変更にも当てはまりますが、レプリケーション・パスワードの変更には、OID Database Password Utilityではなくレプリケーション環境管理ツールを使用してパスワードを更新します。

- 変更後のウォレットを他のノードにコピーします。

1つのノードでしかoidpasswdコマンドを実行せず、すべてのOracle RACノードのウォレットを更新していない場合、2つ目のノードのOracle Internet Directoryインスタンスは、他のノードで起動できなくなります。このエラーは、OIDMONログ・ファイルに次のように表示されます。

[gsdsiConnect] ORA-1017, ORA-01017: invalid username/password; logon denied.

これを修正するには、oidpwdlldap1ファイルを他のOracle RACノードにコピーするか、他のノードでオプションcreate_wallet=trueオプションを指定してoidpasswdツールを起動します。

8.4 Oracle Virtual Directoryの高可用性

この項では、Oracle Virtual Directoryの概要およびOracle Virtual Directoryの高可用性環境の設計とデプロイについて説明します。

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

- 第8.4.1項「Oracle Virtual Directoryコンポーネント・アーキテクチャ」

- 第8.4.2項「Oracle Virtual Directoryの高可用性の概要」

- 第8.4.3項「Oracle Virtual Directoryの高可用性の構成手順」

- 第8.4.4項「Oracle Virtual Directoryの高可用性の検証」

- 第8.4.5項「Oracle Virtual Directoryのフェイルオーバーおよび予想される動作」

- 第8.4.6項「Oracle Virtual Directoryの高可用性のトラブルシューティング」

8.4.1 Oracle Virtual Directoryコンポーネント・アーキテクチャ

Oracle Virtual DirectoryはLDAP Version 3対応のサービスであり、1つ以上のエンタープライズ・データ・ソースを単一のディレクトリ・ビューに仮想的に抽象化します。Oracle Virtual Directoryを使用すると、インフラストラクチャとアプリケーションのいずれかを変更する必要性を最小限に抑えるか、またはその必要性をなくして、LDAPを認識するアプリケーションを多様なディレクトリ環境に統合できます。図8-4に示すように、Oracle Virtual DirectoryはWebアプリケーションやポータルなど、一連の各種クライアントをサポートし、ディレクトリ、データベース、およびWebサービスに接続できます。

図8-4は、非高可用性アーキテクチャのOracle Virtual Directoryを示しています。

図8-4 非高可用性アーキテクチャのOracle Virtual Directory

「図8-4 非高可用性アーキテクチャのOracle Virtual Directory」の説明

Oracle Virtual Directoryサーバーは、Javaで作成され、内部は複数の層で構成されます。この層は論理的な層で、管理者やクライアントからはOracle Virtual Directoryは1つの完全なサービスのように見えます。

8.4.1.1 Oracle Virtual Directoryランタイムの考慮事項

OPMNは、Oracle Virtual Directoryプロセスを起動、監視、および管理するために使用され、Oracle Virtual Directoryプロセスが停止した場合はそれを再起動するために使用されます。Oracle Virtual Directoryインスタンスは、Oracle Enterprise Manager Fusion Middleware Controlを使用しても起動および停止できます。Oracle Virtual Directoryインスタンスを起動および停止するためのOPMNCTLやEnterprise Managerの使用方法の詳細は、Oracle Fusion Middleware Oracle Virtual Directoryに関する管理者ガイドを参照してください。

Oracle Virtual Directoryのインストール時にインストールされるJPSを除き、Oracle Virtual Directoryには外部依存性はありません。独立して実行できます。

Oracle Virtual Directoryは、LDAPオブジェクトをローカル・ファイルシステムに格納するように構成できます。この機能はJPSおよびその他のコンポーネントで使用できます。

Oracle Virtual Directoryには、2つのタイプのリスナー(LDAPとHTTP)があります。いずれのリスナーも基本プロトコルに加えてSSL/TLSもサポートします。LDAP層にはデジタル証明認証をサポートするLDAP-SASLに対応する機能もあります。

LDAPプロトコルは、LDAPv2/v3ベースのサービスを提供し、HTTPプロトコルはDSMLv2などの1つ以上のサービスや、XSLT対応のWebゲートウェイによる基本的なホワイト・ページ機能を提供します。

運用の特質に応じて、クライアント接続は永続または短期のいずれかにできます。

8.4.1.2 Oracle Virtual Directoryコンポーネントの特性

この項では、Oracle Virtual Directoryの様々な構成アーティファクトについて説明します。次のOracle Virtual Directory構成ファイルは、ORACLE_INSTANCE/config/OVD/OVDComponentNameにあります。

- server.os_xml:
Oracle Virtual Directoryには、サーバーが匿名ユーザーや認証ユーザーに返すことができるエントリの数などの項目を管理する機能があります。また、インバウンド・トランザクション・トラフィックを制限することもできます。これは、プロキシ設定されたソースをサービス拒否攻撃から保護するため、またはLDAPトラフィックを制限して一定のディレクトリ・インフラストラクチャ・リソースへのアクセスを制御するために利用できます。これらを含むプロパティはserver.os_xmlで構成されます。

- listeners.os_xml:
Oracle Virtual Directoryは、リスナーと呼ばれる接続を介してクライアントにサービスを提供します。Oracle Virtual Directoryでは、2つのタイプのリスナー(LDAPとHTTP)をサポートします。Oracle Virtual Directoryの構成では、任意の数のリスナーを設定できます。また、リスナーを設定しないことにより、アクセスを管理ゲートウェイのみに制限することもできます。ほとんどのOracle Virtual Directoryのデプロイでは、2つのHTTPリスナーと2つのLDAPリスナーが必要になります。この場合、各プロトコルで一方のリスナーがSSL、もう一方が非SSLに使用されます。リスナー構成ファイルは、listeners.os_xmlです。

- adapters.os_xml:
複数かつ様々なデータ・リポジトリにあるデータの単一の仮想ディレクトリ・ビューを表示するには、Oracle Virtual Directoryをこれらのリポジトリに接続して、データの仮想化とリポジトリ間でのデータのルーティングを可能にする必要があります。Oracle Virtual Directoryは、基盤となるデータ・リポジトリへの接続にアダプタを使用します。各アダプタが、特定の親識別名(DN)で識別されるディレクトリのネームスペースを管理します。構成可能なアダプタの数に制限はありません。また、アダプタの結合やオーバーラップによって、カスタマイズされたディレクトリ・ツリーを表示することもできます。アダプタの構成ファイルは、adapters.os_xmlです。

注意:

Oracle Virtual DirectoryとプロキシLDAPディレクトリとの間の非SSL認証接続の構成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドを参照してください。この手順は、匿名暗号をサポートするように構成されている任意のプロキシLDAPディレクトリに対して使用できます。

- acls.os_xml
Oracle Virtual Directoryは、接続されたすべてのデータ・ストアに一様に適用できる詳細なアクセス制御を提供します。また、Internet Engineering Task ForceのRFC 2820「Access Control Requirements for LDAP」にも準拠しています。アクセス制御のルールは、IETFの「LDAP Access Control Model for LDAPv3」(2001年3月2日草稿)というタイトルのインターネット・ドラフトに基づいてモデル化されています。

Oracle Virtual Directoryは、1つ以上のエンタープライズ・データ・ソースを単一のディレクトリ・ビューに仮想的に抽象化します。このためアクセス制御リスト(ACL)とアダプタのネームスペースは相互に独立しています。ネームスペース内のすべてのエントリの削除やアダプタのルート値を変更しても、ACLに対して自動的に作用することはありません。ACLとアダプタのネームスペースは、相互に独立して構成する必要があります。ACL構成ファイルは、acls.os_xmlです。

Oracle Virtual Directoryインスタンス固有のデータは、ORACLE_INSTANCEホームに格納されます。ウォレットもインスタンスのホームに格納されます。

単一のOracle Virtual Directoryインスタンスで障害が発生した場合は、OPMNを使用してインスタンスを再起動します。

8.4.1.2.1 Oracle Virtual Directoryのログ・ファイル

Oracle Virtual Directoryインスタンスのログ・ファイルは、インスタンスのホームにある次のディレクトリに保存されます。

ORACLE_INSTANCE/diagnostics/logs/OVD/OVDComponentName/

Oracle Virtual Directoryのログ・ファイルを使用したOracle Virtual Directoryに関する問題のトラブルシューティングについては、第8.4.6項「Oracle Virtual Directoryの高可用性のトラブルシューティング」を参照してください。

8.4.2 Oracle Virtual Directoryの高可用性の概要

この項では、Oracle Virtual Directoryを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。前提条件については、第8.4.2.2項「Oracle Virtual Directoryの前提条件」を、2ノードのクラスタを設定するための固有の手順については、第8.4.3項「Oracle Virtual Directoryの高可用性の構成手順」を参照してください。

8.4.2.1 Oracle Virtual Directoryの高可用性アーキテクチャ

図8-5は、Oracle Virtual Directoryのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。

図8-5 高可用性環境のOracle Virtual Directory

「図8-5 高可用性環境のOracle Virtual Directory」の説明

図8-5では、高可用性アーキテクチャのディレクトリ層にOracle Virtual Directoryがあります。2ノードのクラスタはインストール時に設定されます。ロード・バランシング・ルーターによって、2つのOracle Virtual Directoryインスタンスにリクエストがルーティングされます。これらのインスタンスはOVDHOST1およびOVDHOST2上にあり、クラスタ化されています。Oracle RACインスタンスが使用不可になった場合の通知には、高速接続フェイルオーバー(FCF)が使用されます。

2つのコンピュータには同一のOracle Virtual Directoryが構成されています。各インスタンスのOracle Virtual Directory構成は、それぞれのORACLE_INSTANCEに格納されます。各Oracle Virtual Directoryインスタンスの構成は、Oracle Directory Services Managerを使用して別々に更新し、それぞれ一度に1つのOracle Virtual Directoryインスタンスに接続する必要があります。これにかわる方法としては、一方のOracle Virtual Directoryインスタンスの構成を更新し、クローニングを使用してもう一方のOracle Virtual Directoryインスタンスに構成をコピーします。

注意:

Oracle Virtual Directoryの構成を管理するには、Oracle Directory Services Managerを使用する必要があります。Oracle Virtual Directoryインスタンスの構成を更新する際に、ロード・バランサを介してOracle Directory Services ManagerをOracle Virtual Directoryに接続しないでください。このインスタンスの構成を更新するには、物理的なOracle Virtual Directoryインスタンスに明示的に接続する必要があります。

OPMNを使用してOracle Virtual Directoryインスタンスの起動と停止をします。複数のOracle Virtual Directoryインスタンスを含むクラスタを起動する場合、クラスタ内の各Oracle Virtual Directoryインスタンスに影響はありません。

ロード・バランシング・ルーターによってOracle Virtual Directoryインスタンスの停止または障害が検出されると、障害が発生していないインスタンスにLDAPおよびHTTPトラフィックがルーティングされます。障害が発生したインスタンスが再起動すると、ロード・バランシング・ルーターによってこれが検出され、障害が発生していないすべてのインスタンスにトラフィックがルーティングされます。

トランザクションの途中でインスタンスに障害が発生した場合は、このトランザクションはバックエンドにコミットされません。

2ノードのOracle Virtual Directoryクラスタで一方のOracle Virtual Directoryインスタンスに障害が発生した場合、ロード・バランシング・ルーターによってこれが検出され、クラスタ内で障害が発生していないインスタンスにLDAPクライアント・トラフィックがルーティングされます。障害があったOracle Virtual Directoryインスタンスが再起動すると、ロード・バランシング・ルーターによってこれが検出され、クラスタ内で障害が発生していないインスタンスにLDAPクライアント・トラフィック・インスタンスがルーティングされます。

8.4.2.1.1 Oracle Virtual Directoryの高可用性の接続機能

Oracle Virtual Directoryには、次のように高可用性に関する多数の機能があります。

- フォルト・トレランスとフェイルオーバー: Oracle Virtual Directoryのフォルト・トレランスには、次の2つの形態があります。

- フォルト・トレラント構成内で構成できる

- フォルト・トレラント・プロキシ・ソースへのフローを管理できる

構成ファイルをコピーまたは共有することにより、複数のOracle Virtual Directoryを迅速にデプロイできます。ラウンドロビンDNS、リダイレクタまたはクラスタ・テクノロジと組み合せると、Oracle Virtual Directoryは完全なフォルト・トレラント・ソリューションとなります。

プロキシ設定された各ディレクトリ・ソースについて、特定のソースの複数のホスト(レプリカ)にアクセスするようにOracle Virtual Directoryを構成できます。ホスト間のフェイルオーバーと負荷分散もインテリジェントに実行されます。柔軟な構成オプションを使用して、管理者は特定のレプリカ・ノードに与える負荷の割合を制御したり、特定のホストを読取り専用レプリカか読取り/書込みサーバー(マスター)かに指定することができます。これにより、読取り専用レプリカに書込もうとすることから生じる不要な参照を回避できます。

- ロード・バランシング: Oracle Virtual Directoryの設計には、プロキシ設定されたLDAPディレクトリ・ソース間で負荷を分散し、障害を管理することのできる強力なロード・バランシング機能が組み込まれています。
Oracle Virtual Directoryの仮想ディレクトリ・ツリー機能により、大容量のディレクトリ情報のセットを複数の個別ディレクトリ・サーバーに細分化することができます。また、独立したディレクトリ・ツリー・ブランチを結合すれば、分割したデータ・セットを再び結合して1つの仮想ツリーに戻すこともできます。

特定のソースに対して複数のLDAPサーバーがある場合は、Oracle Virtual DirectoryのLDAPアダプタ自身でロード・バランシングとフェイルオーバーを実行できます。このロード・バランシングとフェイルオーバーは、クライアントから意識されることなく行われるので、ハードウェアの追加や、Oracle Virtual Directoryに接続しているクライアントへの変更は必要ありません。

データベース・アダプタは、下位のJDBCドライバにロード・バランシングとフェイルオーバー機能がある場合、この機能をサポートします。また、Oracle Virtual DirectoryはOracle Real Application Clusters(Oracle RAC)とともに使用できることが保証されています。Oracle Virtual DirectoryをOracle RACと使用する方法の詳細は、第4.1.6項「JDBCクライアント」を参照してください。

Oracle Virtual Directoryのルーティングも、ロード・バランシング機能を提供します。ルーティングでは、最適な検索ターゲットを決定するために、検索フィルタを検索ベースに追加することができます。この方法でロード・バランシングを行うと、仮想化された適切なディレクトリ・ソースに問合せが自動的にルーティングされるので、大量のディレクトリ・エントリも処理できるようになります。

注意:

Oracle Virtual Directoryの価値は、ディレクトリ・ストアとしてではなく、仮想化とプロキシのサービスとして発揮されます。可用性の高いディレクトリ・ストレージ・システムが必要な場合は、Oracle Internet Directoryの使用をお薦めします。

Oracle Virtual Directoryインスタンスのログ・ファイルは、インスタンスのホームにある次のディレクトリに保存されます。

ORACLE_INSTANCE/diagnostics/logs/OVD/OVDComponentName/

Oracle Virtual Directoryのログ・ファイルを使用したOracle Virtual Directoryに関する問題のトラブルシューティングについては、第8.4.6項「Oracle Virtual Directoryの高可用性のトラブルシューティング」を参照してください。

8.4.2.2 Oracle Virtual Directoryの前提条件

この項では、Oracle Virtual Directoryの前提条件について説明します。

注意:

Oracle Virtual Directoryを高可用性デプロイメントで使用する場合は、クラスタ・ノードのシステム・クロックを同期する必要があります。

8.4.2.2.1 Oracle Virtual Directory用のロード・バランサの仮想サーバー名

Oracle Virtual Directoryを高可用性構成でデプロイする場合は、Oracle Virtual Directoryインスタンスのフロントエンドに外部ロード・バランサを使用して、各種のOracle Virtual Directoryインスタンス間のLDAPリクエストをロード・バランシングすることをお薦めします。

詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。

8.4.3 Oracle Virtual Directoryの高可用性の構成手順

Oracle Virtual Directoryは、スタンドアロン・モードまたはWebLogicサーバー・ドメインの一部として可用性の高い構成にデプロイできます。

Oracle Virtual Directoryを効率的に管理するには、Oracle Directory Services ManagerとOracle Enterprise Manager Fusion Middleware Controlが必要であるため、Oracle Virtual DirectoryはOracle WebLogic Serverドメインの一部としてデプロイすることをお薦めします。コロケート構成でのOracle Virtual DirectoryとOracle Directory Services Managerの構成の詳細は、第8.7項「コロケート・アーキテクチャの高可用性」を参照してください。

高可用性環境では、Oracle Virtual Directoryをクラスタ・デプロイメント内に設定することをお薦めします。クラスタ化されたOracle Virtual Directoryインスタンスは、同じOracle RACデータベース・リポジトリ、またはLDAPリポジトリにアクセスします。

8.4.3.1 WebLogicドメインを使用しないOracle Virtual Directoryの構成

この項では、Oracle WebLogic Serverドメインを使用せずにOracle Virtual Directoryをデプロイする手順について説明します。

注意:

Oracle Identity Management 11gインストーラで、「ドメインなしで構成」オプションを使用してOracle Virtual Directoryをホストにインストールすると、インストーラによってデフォルトではovd1がOracle Virtual Directoryインスタンスのコンポーネント名として使用されます。

「ドメインなしで構成」でのインストール時に、インストーラでは、コンポーネント名ovd1を使用した別のOracle Virtual Directoryインスタンスがすでにホストに存在して、ドメインに登録されているかどうかは検出できません。

第8.4.3.1.1項「OVDHOST1でのOracle Virtual Directoryの構成」および第8.4.3.1.2項「OVDHOST2でのOracle Virtual Directoryの構成」でOVDHOST1およびOVDHOST2にインストールするOracle Virtual Directoryインスタンスは、「ドメインなしで構成」インストール・オプションを使用してインストールします。

8.4.3.1.1 OVDHOST1でのOracle Virtual Directoryの構成

次の手順に従ってOVDHOST1上のOracle Virtual Directoryインスタンスを構成します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOVDHOST1にインストールされ、アップグレードされていることを確認します。

3. 使用しているオペレーティング・システムに対して次のコマンドを発行して、ポート6501と7501がコンピュータ上の他のサービスに使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":6501"

netstat -an | grep LISTEN | grep ":7501"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr ":6501"

netstat -an | findstr "LISTEN" | findstr ":7501"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

/etc/servicesファイルでポート6501と7501のエントリを削除して、サービスまたはコンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Virtual Directoryのポート番号を指定する行は非コメント化)を割り当てます。

# The Non-SSL LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP= 6501
# The SSL LDAP Port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501

7. 次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. ドメインの選択画面で、「ドメインなしで構成」を選択して「次へ」をクリックします。

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。

- Oracleホーム・ディレクトリ:

/u01/app/oracle/product/fmw/idm_1

- Oracleインスタンスの場所:

/u01/app/oracle/admin/ora_inst1

- Oracleインスタンス名:

ora_inst1

注意:

OVDHOST1のOracleホームの場所を示すディレクトリ・ パスが、OVDHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OVDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。

/u01/app/oracle/product/fmw/idm_1

この場合、OVDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。

/u01/app/oracle/product/fmw/idm_1

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

11. 「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、「Oracle Virtual Directory」を選択し、「次へ」を選択します。

13. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。

14. 「仮想ディレクトリの指定」画面で、次の値を指定します。
「クライアント・リスナー」セクションで、次のように入力します。

- LDAP v3名前空間: Oracle Virtual Directoryの名前空間を入力します。デフォルト値はdc=us,dc=mycompany,dc=comです。

dc=us,dc=mycompany,dc=com

- HTTP Webゲートウェイ: このオプションを選択して、Oracle Virtual DirectoryのHTTP Webゲートウェイを有効化します。

- 保護: HTTP Webゲートウェイを有効化し、SSLを使用して保護する場合はこのオプションを選択します。

「OVD管理者」セクションで、次のように入力します。

- 管理者ユーザー名: Oracle Virtual Directory管理者のユーザー名を入力します(例: cn=orcladmin)。

- パスワード: Oracle Virtual Directory管理者のパスワードを入力します(例: *******)。

- パスワードの確認: Oracle Virtual Directory管理者のパスワードを再度入力します(例: *******)。

- 管理サーバーを保護モードで構成: このオプションを選択し、SSLを使用してOracle Virtual Directory管理リスナーを保護します。このオプションはデフォルトで選択されます。このオプションを選択することをお薦めします。

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

15. 「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。

16. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

17. 「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。

18. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.4.3.1.2 OVDHOST2でのOracle Virtual Directoryの構成

次の手順に従ってOVDHOST2上のOracle Virtual Directoryインスタンスを構成します。

注意:

この項で説明する手順は、11g Oracle Identity Managementの高可用性構成でOracle Virtual Directoryをスケール・アウトするときにも使用できます。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOVDHOST2にインストールされ、アップグレードされていることを確認します。

3. OVDHOST1では、 ポート6501と7501がOracle Virtual Directoryによって使用されています。OVDHOST2のOracle Virtual Directoryインスタンスにも同じポートを使用する必要があります。このため、ポート6501および7501がOVDHOST2上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":6501"

netstat -an | grep LISTEN | grep ":7501"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr ":6501"

netstat -an | findstr "LISTEN" | findstr ":7501"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

/etc/servicesファイルでポート6501と7501のエントリを削除して、サービスまたはコンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Virtual Directoryのポート番号を指定する行は非コメント化)を割り当てます。

# The Non-SSL LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501
# The SSL LDAP Port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501

7. 次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. ドメインの選択画面で、「ドメインなしで構成」を選択して「次へ」をクリックします。

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。

- Oracleホーム・ディレクトリ:

/u01/app/oracle/product/fmw/idm_1

- Oracleインスタンスの場所:

/u01/app/oracle/admin/ora_inst2

- Oracleインスタンス名:

ora_inst2

注意:

OVDHOST2のOracleホームの場所を示すディレクトリ・ パスが、OVDHOST1のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OVDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。

/u01/app/oracle/product/fmw/idm_1

この場合、OVDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。

/u01/app/oracle/product/fmw/idm_1

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

11. 「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、「Oracle Virtual Directory」を選択し、「次へ」を選択します。

13. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。

14. 「仮想ディレクトリの指定」画面で、次の値を指定します。
「クライアント・リスナー」セクションで、次のように入力します。

- LDAP v3名前空間: Oracle Virtual Directoryの名前空間を入力します。デフォルト値はdc=us,dc=mycompany,dc=comです。

dc=us,dc=mycompany,dc=com

- HTTP Webゲートウェイ: このオプションを選択して、Oracle Virtual DirectoryのHTTP Webゲートウェイを有効化します。

- 保護: HTTP Webゲートウェイを有効化し、SSLを使用して保護する場合はこのオプションを選択します。

「OVD管理者」セクションで、次のように入力します。

- 管理者ユーザー名: Oracle Virtual Directory管理者のユーザー名を入力します(例: cn=orcladmin)。

- パスワード: Oracle Virtual Directory管理者のパスワードを入力します(例: *******)。

- パスワードの確認: Oracle Virtual Directory管理者のパスワードを再度入力します(例: *******)。

- 管理サーバーを保護モードで構成: このオプションを選択し、SSLを使用してOracle Virtual Directory管理リスナーを保護します。このオプションはデフォルトで選択されます。このオプションを選択することをお薦めします。

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

15. 「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。

16. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

17. 「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。

18. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.4.3.1.3 WebLogicドメインへのOracle Virtual Directoryの登録

Oracle Virtual Directoryコンポーネントの管理には、Oracle Enterprise Manager Fusion Middleware Controlを使用することをお薦めします。Oracle Enterprise Manager Fusion Middleware Controlを使用してOracle Virtual Directoryを管理する場合は、コンポーネントとそれを含むOracle Fusion MiddlewareインスタンスをOracle WebLogic Serverドメインに登録する必要があります。インストール時またはOracleインスタンスの作成時に、Oracle Fusion MiddlewareインスタンスをWebLogicドメインに登録できますが、必須事項ではありません。Oracle Fusion MiddlewareインスタンスがWebLogicドメインに事前に登録されていない場合は、opmnctl registerinstanceを使用して登録できます。

opmnctl registerinstanceコマンドを使用してOracle Virtual DirectoryインスタンスをOracle WebLogic Serverドメインに登録する前に、WebLogic Serverがインストールされていることを確認します。

続いて、次の形式でopmnctl registerinstanceコマンドを実行します(各インストールで変数ORACLE_HOMEとORACLE_INSTANCEを設定してからOracle Virtual Directoryインスタンスのホーム・ディレクトリでこのコマンドを実行してください)。

opmnctl registerinstance -adminHost WLSHostName -adminPort WLSPort
-adminUsername adminUserName

例:

opmnctl registerinstance -adminHost idmhost1.mycompany.com -adminPort 7001
-adminUsername weblogic

Command requires login to weblogic admin server (idmhost1.mycompany.com)
Username: weblogic
Password: *******

WebLogicドメインにおけるOracle Virtual Directoryコンポーネントの登録の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのOPMNCTLを使用したOracleインスタンスの登録に関する項を参照してください。

8.4.3.2 WebLogicドメインを使用したOracle Virtual Directoryの構成

この項では、WebLogic Serverドメインの一部としてOracle Virtual Directoryの高可用性構成をデプロイする手順について説明します。

この構成では、1つ目のホストにOracle Virtual DirectoryとWebLogic Serverドメインが構成され、2つ目のホストにはOracle Virtual Directoryのみが構成されます。2つ目のホストのOracle Virtual Directoryインスタンスは、1つ目のホストで作成されたドメインに参加します。

8.4.3.2.1 OVDHOST1でのOracle Virtual Directoryの構成

次の手順に従ってOVDHOST1上のOracle Virtual Directoryインスタンスを構成します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOVDHOST1にインストールされ、アップグレードされていることを確認します。

3. ポート6501および7501がOVDHOST1上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":6501"

netstat -an | grep LISTEN | grep ":7501"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr ":6501"

netstat -an | findstr "LISTEN" | findstr ":7501"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

/etc/servicesファイルでポート6501と7501のエントリを削除して、サービスまたはコンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Virtual Directoryのポート番号を指定する行は非コメント化)を割り当てます。

# The Non-SSL LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501
# The SSL LDAP port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501

7. 次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. ドメインの選択画面で、新規ドメインの作成を選択して、次の値を指定します。

- ユーザー名: weblogic

- パスワード: <weblogicユーザーのパスワード>

- パスワードの確認: <weblogicユーザーのパスワードを再度入力します>

- ドメイン名: IDMDomain

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所:

/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ: idm

- WebLogic Serverのディレクトリ:

/u01/app/oracle/product/fmw/wlserver_10.3

- Oracleインスタンスの場所:

/u01/app/oracle/admin/ovd_inst1

- Oracleインスタンス名:

ovd_inst1

注意:

OVDHOST1のOracleホームの場所を示すディレクトリ・ パスが、OVDHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OVDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。

/u01/app/oracle/product/fmw/idm

この場合、OVDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。

/u01/app/oracle/product/fmw/idm

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

11. 「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、「Oracle Virtual Directory」を選択し、「次へ」を選択します。

注意:

このインストールでは、Oracle Directory Services ManagerとFusion Middleware Controlの管理コンポーネントが自動的に選択されます。この選択は解除できません。

13. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。

14. 「仮想ディレクトリの指定」画面で、次の値を指定します。
「クライアント・リスナー」セクションで、次のように入力します。

- LDAP v3名前空間: Oracle Virtual Directoryの名前空間を入力します。デフォルト値はdc=us,dc=mycompany,dc=comです。

dc=us,dc=mycompany,dc=com

- HTTP Webゲートウェイ: このオプションを選択して、Oracle Virtual DirectoryのHTTP Webゲートウェイを有効化します。

- 保護: HTTP Webゲートウェイを有効化し、SSLを使用して保護する場合はこのオプションを選択します。

「OVD管理者」セクションで、次のように入力します。

- 管理者ユーザー名: Oracle Virtual Directory管理者のユーザー名を入力します(例: cn=orcladmin)。

- パスワード: Oracle Virtual Directory管理者のパスワードを入力します(例: *******)。

- パスワードの確認: Oracle Virtual Directory管理者のパスワードを再度入力します(例: *******)。

- 管理サーバーを保護モードで構成: このオプションを選択し、SSLを使用してOracle Virtual Directory管理リスナーを保護します。このオプションはデフォルトで選択されます。このオプションを選択することをお薦めします。

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

15. 「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。

16. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

17. 「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。

18. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.4.3.2.2 OVDHOST1での管理サーバー用boot.propertiesの作成

この項では、OVDHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法を説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。

次の手順に従って、boot.propertiesファイルを作成します。

1. OVDHOST1で、次のディレクトリに移動します。

MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

例:

cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

2. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

username=adminUser
password=adminUserPassword

注意:

管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。

3. 管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。

4. MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OVDHOST1上の管理サーバーを起動します。

5. Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。

- WebLogic Server管理コンソール:

http://oidhost1.mycompany.com:7001/console

- Oracle Enterprise Manager Fusion Middleware Control:

http://oidhost1.mycompany.com:7001/em

weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

8.4.3.2.3 OVDHOST2でのOracle Virtual Directoryの構成

次の手順に従ってOVDHOST2上のOracle Virtual Directoryインスタンスを構成します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOVDHOST2にインストールされ、アップグレードされていることを確認します。

3. OVDHOST1では、 ポート6501と7501がOracle Virtual Directoryによって使用されています。OVDHOST2のOracle Virtual Directoryインスタンスにも同じポートを使用する必要があります。このため、ポート6501および7501がOVDHOST2上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":6501"

netstat -an | grep LISTEN | grep ":7501"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr ":6501"

netstat -an | findstr "LISTEN" | findstr ":7501"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

/etc/servicesファイルでポート6501と7501のエントリを削除して、サービスまたはコンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Virtual Directoryのポート番号を指定する行は非コメント化)を割り当てます。

# The Non-SSL LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501
# The SSL LDAP port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501

7. 次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. ドメインの選択画面で、既存ドメインの拡張を選択して、次の値を指定します。

- ホスト名: ovdhost1.mycompany.com(WebLogic管理サーバーを実行しているホスト)

- ポート: 7001(これは管理サーバーのポートです。)

- ユーザー名: weblogic

- パスワード: <weblogicユーザーのパスワード>

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所:

/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ: idm

- WebLogic Serverのディレクトリ:

/u01/app/oracle/product/fmw/wlserver_10.3

- Oracleインスタンスの場所:

/u01/app/oracle/admin/ovd_inst2

- Oracleインスタンス名:

ovd_inst2

注意:

OVDHOST1のOracleホームの場所を示すディレクトリ・パスが、OVDHOST2のOracleホームの場所を示すディレクトリ・パスと同じであることを確認してください。たとえば、OVDHOST1のOracleホームの場所として次のディレクトリ・パスを指定したとします。

/u01/app/oracle/product/fmw/idm

この場合、OVDHOST2のOracleホームの場所には次のディレクトリ・パスを指定する必要があります。

/u01/app/oracle/product/fmw/idm

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

11. 「セキュリティ更新用の電子メールの指定」画面で、次の値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、「Oracle Virtual Directory」を選択し、「次へ」を選択します。

注意:

このインストールでは、Oracle Directory Services ManagerとFusion Middleware Controlの管理コンポーネントが自動的に選択されます。

13. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。

14. 「仮想ディレクトリの指定」画面で、次の値を指定します。
「クライアント・リスナー」セクションで、次のように入力します。

- LDAP v3名前空間: Oracle Virtual Directoryの名前空間を入力します。デフォルト値はdc=us,dc=mycompany,dc=comです。

dc=us,dc=mycompany,dc=com

- HTTP Webゲートウェイ: このオプションを選択して、Oracle Virtual DirectoryのHTTP Webゲートウェイを有効化します。

- 保護: HTTP Webゲートウェイを有効化し、SSLを使用して保護する場合はこのオプションを選択します。

「OVD管理者」セクションで、次のように入力します。

- 管理者ユーザー名: Oracle Virtual Directory管理者のユーザー名を入力します(例: cn=orcladmin)。

- パスワード: Oracle Virtual Directory管理者のパスワードを入力します(例: *******)。

- パスワードの確認: Oracle Virtual Directory管理者のパスワードを再度入力します(例: *******)。

- 管理サーバーを保護モードで構成: このオプションを選択し、SSLを使用してOracle Virtual Directory管理リスナーを保護します。このオプションはデフォルトで選択されます。このオプションを選択することをお薦めします。

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

15. 「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。

16. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

17. 「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。

18. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.4.3.3 可用性の高いデータ・ソースを使用したOracle Virtual Directoryの構成

Oracle Virtual Directoryは、Oracle RACデータベース・リポジトリまたは可用性の高いLDAPリポジトリをデータ・ソースとして使用するように構成できます。

この項では、Oracle RACデータベース・リポジトリおよびLDAPリポジトリを使用した高可用性環境にOracle Virtual Directoryを構成する方法を説明します。

注意:

Oracle Virtual Directoryを高可用性トポロジで構成する場合は、すべてのノードで個別に構成手順を完了する必要があります。

8.4.3.3.1 Oracle RACデータベースを使用したOracle Virtual Directoryの構成

リポジトリとしてOracle RACデータベースを使用するOracle Virtual Directory高可用性環境では、Oracle Virtual Directoryデータベース・アダプタを作成して構成する必要があります。

Oracle Virtual Directoryアダプタの概要は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのOracle Virtual Directoryアダプタの理解に関する項を参照してください。

Oracle RACデータベースのデータベース・アダプタの作成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのRACデータベースのデータベース・アダプタの作成に関する項を参照してください。

データベース・アダプタの構成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのデータベース・アダプタの構成に関する項を参照してください。

8.4.3.3.2 LDAPを使用したOracle Virtual Directoryの構成

Oracle Virtual Directoryは、LDAPアダプタを介してOracle Internet DirectoryなどのLDAPリポジトリに接続します。高可用性環境では、ロード・バランシング・アルゴリズムを使用してノードのホストおよびポート情報を追加するか、LDAPリポジトリのロード・バランサのURLを追加することでLDAPアダプタを構成できます。

Oracle Virtual Directoryアダプタの概要は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのOracle Virtual Directoryアダプタの理解に関する項を参照してください。

LDAPアダプタの作成と構成の詳細は、Oracle Fusion Middleware Oracle Virtual Directory管理者ガイドのLDAPアダプタの構成に関する項を参照してください。

8.4.4 Oracle Virtual Directoryの高可用性の検証

可用性の高いデプロイメントでは、Oracle Virtual Directoryインスタンスは、ハードウェア・ロード・バランサによりフロントエンド処理されます。Oracle Virtual Directoryインスタンス間でリクエストのロード・バランシングが行われ、障害(インスタンス障害またはホスト障害)が発生した場合、ハードウェアのロード・バランサによって障害が検出され、障害が発生していないインスタンスにすべてのリクエストがルーティングされます。

Oracle Virtual Directoryの高可用性をテストするには、ノードを1つずつ停止し、ldapbindなどのツールを使用してロード・バランサのURLを経由しOracle Virtual Directoryインスタンスに接続します。ノードの1つが稼働しトポロジの構成が正しければ、接続は常に成功します。

ldapbindコマンドライン・ツールを使用し、ロード・バランサの仮想ホストを介してOracle Virtual Directoryインスタンスに接続します。ldapbindツールでは、サーバーに対してクライアントを認証できるかどうかを確認できます。

次の手順に従って、OVDHOST1およびOVDHOST2のOracle Virtual Directoryの高可用性設定を検証します。

1. Oracle Fusion Middleware Oracle Identity Managementリファレンスの環境の構成に関する項の手順に従って環境を構成します。この項には、ldapbindコマンドを使用する前に設定する必要がある環境変数の一覧があります。

2. OVDHOST1で、opmnctlコマンドを使用して、Oracle Virtual Directoryインスタンスを停止します。

ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1

3. OVDHOST2で、ldapbindを使用してロード・バランシング仮想アドレスにバインドし、Oracle Virtual Directoryのステータスをチェックします。
非SSL:

ldapbind -h ovd.mycompany.com -p 6501 -D "cn=orcladmin" -q

注意:

前述の-qオプションを指定すると、ユーザーのパスワードの入力が求められます。LDAPツールでは、環境変数LDAP_PASSWORD_PROMPTONLYがTRUEまたは1に設定されている場合、-w passwordおよび-P passwordの各オプションが無効になるよう変更されています。可能なかぎり、この機能を使用してください。

4. 正常にバインドされると、ロード・バランサによってすべてのトラフィックがOVDHOST2にルーティングされます。

5. OVDHOST1で、opmnctlコマンドを使用して、Oracle Virtual Directoryインスタンスを起動します。

ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running)
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1

6. OVDHOST2で、opmnctlコマンドを使用してOracle Virtual Directoryインスタンスを停止します。

ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1

7. OVDHOST1で、ldapbindを使用してロード・バランシング仮想アドレスにバインドし、Oracle Virtual Directoryのステータスをチェックします。
非SSL:

ldapbind -h ovd.mycompany.com -p 6501 -D "cn=orcladmin" -q

8. OVDHOST2で、opmnctlコマンドを使用してOracle Virtual Directoryインスタンスを起動します。

ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running)
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1

ldapbindコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Managementリファレンスのldapbindに関する項を参照してください。

8.4.4.1 SSLを使用したOracle Virtual Directoryの高可用性の検証

Oracle Virtual Directoryは、デフォルトではサーバーのみのSSL認証モードを使用するように構成されます。ldapbindなどのコマンドライン・ツールを使用して、SSLサーバー認証モードで保護された接続を使用する接続を検証する場合は、Oracleウォレットにサーバー証明書が格納されている必要があります。次の手順に従って、このタスクを実行します。

1. 次のコマンドを実行して、Oracleウォレットを作成します。

ORACLE_HOME/bin/orapki wallet create -wallet DIRECTORY_FOR_SSL_WALLET -pwd WALLET_PASSWORD

2. 次のコマンドを実行して、Oracle Virtual Directoryサーバー証明書をエクスポートします。

ORACLE_HOME/jdk/jre/bin/keytool -exportcert -keystore OVD_KEYSTORE_FILE
-storepass PASSWORD -alias OVD_SERVER_CERT_ALIAS -rfc -file
OVD_SERVER_CERT_FILE

3. 次のコマンドを実行して、Oracle Virtual Directoryサーバー証明書をOracleウォレットに追加します。

ORACLE_HOME/bin/orapki wallet add -wallet DIRECTORY_FOR_SSL_WALLET
-trusted_cert -cert OVD_SERVER_CERT_FILE -pwd WALLET_PASSWORD

4. 第8.4.4項「Oracle Virtual Directoryの高可用性の検証」の手順に従って次のldapbindコマンドを使用し、OVDHOST1およびOVDHOST2のOracle Virtual Directoryの高可用性設定を検証します。次のコマンドの実行中に、手順3からOracleウォレットを使用します。

ORACLE_HOME/bin/ldapbind -D cn=orcladmin -q -U 2 -h HOST -p SSL_PORT -W "file://DIRECTORY_FOR_SSL_WALLET" -q

5. Oracle Virtual Directoryの高可用性デプロイメントがロード・バランサによってフロントエンド処理される場合は、すべてのOracle Virtual Directoryノードのウォレットに、トポロジの構成要素であるすべてのOracle Virtual Directoryインスタンスのクライアント証明書が格納されている必要があります。トポロジ内のすべてのOracle Virtual Directoryインスタンスのクライアント証明書をトポロジ内の全ノードのウォレットに追加します。これによって、ロード・バランサのURLを経由する有効な接続リクエストが正常に処理されることが保証されます。

注意:

11g リリース1(11.1.1)のインストール後にデフォルトの設定を使用している場合は、この項に記載された変数に次の値を使用できます。

- OVD_KEYSTORE_FILEには、次を使用します。

ORACLE_INSTANCE/config/OVD/ovd1/keystores/keys.jks

- OVD_SERVER_CERT_ALIASには、serverselfsignedを使用します。

- -storepassオプションで使用するPASSWORDには、orcladminアカウントのパスワードを使用します。

8.4.5 Oracle Virtual Directoryのフェイルオーバーおよび予想される動作

この項では、Oracle Virtual DirectoryのフェイルオーバーとOracle RACのフェイルオーバーを実行する手順を説明します。

8.4.5.1 Oracle Virtual Directoryのフェイルオーバーの実行

次の手順に従って、Oracle Virtual Directoryインスタンスのフェイルオーバーを実行し、Oracle Virtual Directoryのステータスを調べます。

1. opmnctlコマンドを使用して、Oracle Virtual Directoryインスタンスを停止します。

ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1

2. opmnctlコマンドを使用して、Oracle Virtual Directoryインスタンスを起動します。

ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running)
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1

3. Oracle Virtual Directoryのステータスを確認します。

ORACLE_INSTANCE/bin/opmnctl status ias-component=ovd1

8.4.5.2 Oracle RACフェイルオーバーの実行

次の手順に従って、Oracle RACのフェイルオーバーを実行します。

1. srvctlコマンドを使用して、データベース・インスタンスを停止します。

srvctl stop instance -d db_unique_name -i inst_name_list

2. srvctlコマンドを使用して、データベース・インスタンスのステータスを確認します。

srvctl status database -d db_unique_name -v

3. Oracle Virtual Directoryのステータスを確認します。

ORACLE_INSTANCE/bin/opmnctl status ias-component=ovd1

4. srvctlコマンドを使用して、データベース・インスタンスを起動します。

srvctl start instance -d db_unique_name -i inst_name_list

注意:

Oracle RACデータベースに対するデータベース・アダプタを使用してOracle Virtual Directoryを構成している場合は、Oracle RACフェイルオーバー後の最初の検索に失敗します。ただし、その後の検索リクエストは問題なく正常に行われます。

8.4.6 Oracle Virtual Directoryの高可用性のトラブルシューティング

Oracle Virtual Directoryのログ・ファイルの情報は、Oracle Virtual Directoryに関する問題のトラブルシューティングに役立ちます。Oracle Virtual Directoryのログ・ファイルは、次のディレクトリにあります。

ORACLE_INSTANCE/diagnostics/log/OVD/<OVDComponentName>

トラブルシューティングの際に調査するログ・ファイルの順序は次のとおりです。

1. diagnostic.log: 診断メッセージが記録されます。

2. http-errors.log: HTTPエラーが記録されます。

3. access.log: Oracle Virtual Directoryインスタンスにアクセスするプロセスとクライアントに関する情報が記録されます。

8.4.6.1 LDAPアダプタ作成のトラブルシューティング

LDAPアダプタを作成するときは、アダプタ作成ウィザードの「接続」ページでLDAPサーバーのホスト名とポート番号を指定します。LDAPサーバーが「SSLサーバー認証のみ」モードまたは「相互認証」モードでリスニングしている場合、ODSMによってサーバー証明書がOracle Virtual Directoryのトラスト・ストアにインポートされます。ただし、複数のLDAPサーバーのフロントエンドに使用されるロード・バランサの名前を指定した場合、そのLDAPサーバーの証明書の1つのみがインポートされます。これにより、Oracle Virtual Directoryサーバーのリクエストが、証明書に信頼性がないLDAPサーバーにルーティングされる場合に問題が発生します。

この問題を回避するには、LDAPアダプタの作成中に、ロード・バランサ・ホストとポートの詳細を指定するだけでなく、ロード・バランサがフロント・エンドとして使用されるLDAPサーバーのホストとポートの詳細を指定し、すべてのLDAPサーバーの証明書がインポートされるようにします。アダプタを作成した後、アダプタ設定を編集し、物理LDAPサーバーのホストとポートの詳細を削除する、つまりそれらの重みを0(ゼロ)に設定することができます。

8.5 Oracle Directory Integration Platformの高可用性

この項では、Oracle Directory Integration Platformの概要、およびOracle Directory Integration PlatformとOracle Directory Services Managerの高可用性環境の設計とデプロイについて説明します。

Oracle Directory Services Managerの詳細は、第8.6項「Oracle Directory Services Managerの高可用性」を参照してください。

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

- 第8.5.1項「Oracle Directory Integration Platformコンポーネント・アーキテクチャ」

- 第8.5.2項「Oracle Directory Integration Platformの高可用性の概要」

- 第8.5.3項「Oracle Directory Integration PlatformおよびOracle Directory Services Managerの高可用性の構成手順」

- 第8.5.4項「Oracle Directory Integration Platformのフェイルオーバーおよび予想される動作」

- 第8.5.5項「Oracle Directory Integration Platformの高可用性のトラブルシューティング」

8.5.1 Oracle Directory Integration Platformコンポーネント・アーキテクチャ

Oracle Directory Integration Platformは、アプリケーションやディレクトリ(サード・パーティのLDAPディレクトリなど)とOracle Internet Directoryとの統合を可能にするJ2EEアプリケーションです。

Oracle Directory Integration Platformには、他のエンタープライズ・リポジトリとの同期ソリューションのデプロイを可能とするサービスとインタフェースが含まれています。Oracle Internet Directoryとサード・パーティのメタディレクトリ・ソリューションとの相互運用性を実現するためにも使用できます。

Oracle Directory Integration Platformには、必要な統合のタイプに応じた次の2つのサービスがあります。

- Oracle Directory Integration Platform Synchronization Serviceによる同期化では、中央のOracle Internet Directoryを使用して接続ディレクトリの整合性が保持されます。

- Oracle Directory Integration Platform Provisioning Serviceによる通知では、ターゲット・アプリケーションに定期的に通知が送信され、ユーザーのステータスや情報に対する変更が反映されます。

注意:

この章の以降では、次の用語を使用します。

- Oracle Directory Integration Platform Synchronization Serviceには「同期化サービス」を使用します。

- Oracle Directory Integration Platform Provisioning Serviceには「プロビジョニング・サービス」を使用します。

図8-6は、Oracle Directory Integration Platformのアーキテクチャを示しています。

図8-6 Oracle Directory Integration Platformのアーキテクチャ

「図8-6 Oracle Directory Integration Platformのアーキテクチャ」の説明

図8-6は、Oracle Directory Integration Platformの様々なコンポーネントを示しています。Oracle Internet Directoryは、Oracle Directory Integration Platformの同期化Enterprise JavaBeans(EJB)とクォーツ・スケジューラを使用して接続ディレクトリと同期化されます。

同様に、Oracle Internet Directoryでの変更は、Oracle Directory Integration PlatformのプロビジョニングEnterprise JavaBeans(EJB)とクォーツ・スケジューラを使用して各種アプリケーションに送信されます。

8.5.1.1 Oracle Directory Integration Platformコンポーネントの特性

Oracle Directory Integration Platformは、アプリケーションやディレクトリ(サード・パーティのLDAPディレクトリなど)とOracle Internet Directoryとの統合を可能にするJ2EEアプリケーションです。

Oracle Directory Integration Serverは、次で説明するように、同期化サービスによって各同期化サービスを、プロビジョニング・サービスによって各統合サービスを提供します。

- 同期化サービスには、次の機能があります。

- スケジュール: 事前定義済スケジュールに基づいた同期化プロファイルを処理します。

- マッピング: 接続ディレクトリとOracle Internet Directory間のデータ交換のルールを実行します。

- データの伝播: コネクタを使用して接続ディレクトリとデータを交換します。

- エラーを処理します。

- プロビジョニング・サービスには、次の機能があります。

- データの伝播: コネクタを使用して接続ディレクトリとデータを交換します。

- イベント通知: Oracle Internet Directoryに格納されたユーザーまたはグループ・データに関連する変更をアプリケーションに通知します。

- エラーを処理します。

Oracle Directory Integration Platformは、Oracle WebLogic Serverにデプロイされます。デフォルトでは、Oracle Directory Integration Platformは、Oracle Identity Managementソフトウェア・スタックの一部としてインストールされますが、アーキテクチャの要件に応じて、スタンドアロン・アプリケーションとしてインストールすることもできます。

8.5.1.1.1 ランタイム・プロセス

Oracle Directory Integration Serverには、次の機能があります。

- 同期化Enterprise JavaBeans(EJB)とクォーツ・スケジューラを使用した同期化サービス。同期化EJBは本質的にステートレスです。
クォーツ・スケジューラは、同期化EJBを起動し、すべての接続ディレクトリに対して該当する変更を同期します。

同期化サービスは、接続ディレクトリで必要とされるインタフェースとフォーマットを使用してこれらの変更を提供します。Oracle Directory Integration Platformコネクタを介した同期化では、Oracle Internet Directoryクライアントが必要とするすべての情報に対してOracle Internet Directoryが最新の状態に維持されることが保証されます。

- プロビジョニング・サービスでは、プロビジョニングEnterprise JavaBeans(EJB)とクォーツ・スケジューラが使用されます。プロビジョニングEJBは本質的にステートレスです。
クォーツ・スケジューラは、プロビジョニングEJBを起動し、プロビジョニングされた各アプリケーションに変更を通知します。

- UpdateJob EJBは、Oracle Internet Directory変更ログに対して同期またはプロビジョニング・プロファイルの変更のポーリングを定期的に行います。プロファイルの変更が検出されると、それに応じてクォーツ・スケジューラ・ジョブが更新されます。

8.5.1.1.2 プロセスのライフサイクル

Oracle Directory Integration Platformは、外部管理アプリケーションとしてOracle WebLogic Serverにデプロイされます。Oracle Directory Integration Platformアプリケーションはデフォルトで、起動、停止、監視および他のライフサイクル・イベントに、基礎となるWebLogic Serverインフラストラクチャを使用します。WebLogicノード・マネージャは、サーバー・プロセスを監視し、障害発生時にそのプロセスを再起動するように構成できます。

Oracle Directory Integration Platformは、デプロイされた管理対象サーバーの起動時に初期化されます。Oracle Directory Integration Platformアプリケーションが起動すると、初期化コードによって既存のディレクトリ統合プロファイルにジョブの初期セットが作成され、UpdateJobBean EJBが起動されます。

UpdateJobBeanは、クォーツ・スケジューラに送信されたジョブを更新します。

クォーツ・スケジューラはジョブに応じて、プロビジョニングEJBまたは同期化EJBを起動します。プロビジョニングEJBが起動された場合は、プロビジョニング対象の各アプリケーションに対してOracle Internet Directoryの変更が通知されます。同期化EJBが起動された場合は、すべての接続ディレクトリに対して該当する変更が同期化されます。

起動および停止

Oracle Directory Integration Platformのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理します。

- Oracle WebLogic Scripting Tool(WLST)

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle WebLogic Server管理コンソール

- Oracle WebLogicノード・マネージャ

8.5.1.1.3 リクエスト・フロー

Oracle Directory Integration Platformは、外部リクエストを処理しません。この主要機能は、作成されたプロファイルに基づいて、同期化とプロビジョニングをサポートすることです。

この項では、同期化およびプロビジョニングの際の情報フローについて説明します。

Oracle Directory Integration Platform Synchronization Serviceフロー

Oracle Directory Integration Platformは、ディレクトリ同期プロファイルに従ってOracle Internet Directoryと接続ディレクトリ間の変更を同期します。

変更が行われた場所に応じて、次のような同期化が発生します。

- 接続ディレクトリからOracle Internet Directoryへの同期化

- Oracle Internet Directoryから接続ディレクトリへの同期化

- 双方向での同期化

Oracle Internet Directoryから接続されたディレクトリへの同期化

Oracle Internet Directoryでは、ディレクトリ・オブジェクトに対する増分変更が保存される変更ログが管理されます。これには、変更ログ番号に基づいて連続的に変更が保存されます。

Oracle Internet Directoryから接続ディレクトリへの同期では、この変更ログが利用されます。このため、Oracle Directory Integration Platformの実行時には、変更ロギングが有効化されているデフォルト設定を使用してOracle Internet Directoryを起動する必要があります。

Oracle Directory Integration Platform Synchronization Serviceが同期プロファイルを処理するたびに、次の処理が行われます。

1. すべての変更が適用された最新の変更ログ番号が取得されます。

2. この番号より新しい変更ログ・エントリがそれぞれチェックされます。

3. プロファイルのフィルタリング・ルールを使用して、接続ディレクトリとの同期対象の変更が選択されます。

4. エントリにマッピング・ルールが適用され、接続ディレクトリで対応する変更が実行されます。

該当するエントリまたは属性がその接続ディレクトリで更新されます。接続ディレクトリで、DB、LDAP、タグ付き、またはLDIFの各形式が直接使用されていない場合は、プロファイルに指定されているエージェントが起動されます。正常に使用された最後の変更番号がプロファイルに保存されます。

Oracle Internet Directoryは、すべてのプロファイルが必要な変更ログを使用した後、変更ログをパージして、後続の同期の開始位置を示します。

接続されたディレクトリからOracle Internet Directoryへの同期化

接続ディレクトリで、DB、LDAP、タグ付き、またはLDIFの各形式が直接使用されている場合、そのエントリまたは属性に対する変更は、Oracle Directory Integration Platform Synchronization Serviceによって自動的に同期化されます。それ以外の場合、コネクタは同期プロファイルにエージェントを持ち、エージェントがLDIFまたはタグ付き形式でファイルへの変更を書き込みます。次に、Oracle Directory Integration Platform Synchronization Serviceは、この接続ディレクトリ・データのファイルを使用して、Oracle Internet Directoryを更新します。

プロビジョニング・フロー

プロビジョニングとは、ユーザー、グループおよび他のオブジェクトに対し、環境内で利用可能なアプリケーションや他のリソースへのアクセスを提供するプロセスです。プロビジョニング統合アプリケーションとは、プロビジョニング・イベント用に、Oracle Internet Directoryにプロビジョニング統合プロファイルが登録されているアプリケーションです。

Oracle Directory Integration Platform Provisioningでは、次の方法のいずれかを使用してアプリケーションをプロビジョニングできます。

- 同期プロビジョニング

- 非同期プロビジョニング

- プロビジョニングのデータ・フロー

それぞれのプロビジョニング方法については、後続の各項で説明します。

同期プロビジョニング

Oracle Internet Directoryでユーザー情報を管理するアプリケーションでは、データ・アクセスJavaプラグインを使用して、Oracle Internet Directoryに変更が発生するたびにユーザー・エントリを作成、変更および削除でき、同期的にプロビジョニングされます。これは、Oracle Identity Management(プロビジョニング・コンソールやコマンドラインLDAPツールなど)からデータ・アクセスJavaプラグインを直接起動できるためです。

Oracle Directory Integration Platform Provisioning Serviceの同期プロビジョニングは、Oracle Identity Managementツール(Oracle Fusion Middleware Controlのプロビジョニング・コンソールやbulkprovなど)、サード・パーティ・ディレクトリ、またはコマンドラインLDAPツールから起動できます。

Oracle Identity Managementツール(Oracle Fusion Middleware Controlのプロビジョニング・コンソール画面やprovProfileBulkProvコマンドによるバルク・プロビジョニングなど)、およびサード・パーティ・ディレクトリを使用したOracle Directory Integration Platform Provisioning Serviceの同期プロビジョニングは、次のプロセスに従います。

1. Oracle Internet Directoryに新規ユーザー・エントリが作成されます。

2. 新規ユーザー・エントリを作成したOracle Identity Managementコンポーネントは、データ・アクセスJavaプラグインを起動します。

3. データ・アクセスJavaプラグインは、アプリケーションにこの新規ユーザー・アカウントをプロビジョニングします。

コマンドラインLDAPツールを使用した同期プロビジョニングは、次のプロセスに従います。

1. コマンドラインLDAPツールによって、Oracle Internet Directoryに新規ユーザー・エントリが作成されます。

2. 次にスケジュールされた同期間隔で、Oracle Directory Integration Platformは、プロビジョニングの必要な新規ユーザー・エントリがOracle Internet Directoryに存在することを確認します。

3. Oracle Directory Integration Platformは、データ・アクセスJavaプラグインを起動します。

4. データ・アクセスJavaプラグインは、アプリケーションに新規ユーザー・アカウントをプロビジョニングします。

非同期プロビジョニング

非同期プロビジョニングでは、プロビジョニングは、任意のOracle Identity ManagementのコンポーネントではなくPL/SQLプラグインによって処理されます。

Oracle Directory Integration Platformは、PL/SQLイベントをプロビジョニング統合アプリケーションに伝播し、次に、このアプリケーションがイベントを処理するためにPL/SQLプラグインを実行します。PL/SQLプラグインの実行は、アプリケーション・リポジトリ内で発生し、任意のOracle Identity Managementコンポーネントのアドレス空間では発生しません。プロビジョニングは、任意のOracle Identity ManagementのコンポーネントではなくPL/SQLプラグインによって処理されるため、PL/SQLプラグインを実装するプロビジョニング統合アプリケーションは、非同期的にプロビジョニングされます。

Oracle Directory Integration Platform Provisioning Serviceを使用した非同期プロビジョニングは、Oracle Identity Managementツール(プロビジョニング・コンソールやbulkprovなど)、サード・パーティ・ディレクトリとの同期化、またはコマンドラインLDAPツールから起動できます。

Oracle Identity Managementツール(プロビジョニング・コンソール、provProfileBulkProvコマンドによるバルク・プロビジョニングなど)、およびサード・パーティ・ディレクトリからの非同期プロビジョニングは、次のプロセスに従います。

1. Oracle Internet Directoryに新規ユーザー・エントリとアプリケーション固有のユーザー・プリファレンスを含む関連エントリが作成されます。

2. 次にスケジュールされた同期間隔で、Oracle Directory Integration Platformは、プロビジョニングの必要な新規ユーザー・エントリがOracle Internet Directoryに存在することを確認します。

3. Oracle Directory Integration PlatformからPL/SQLプラグインにプロビジョニング・イベントが送信されます。

コマンドラインLDAPツールを使用した非同期プロビジョニングは、次のプロセスに従います。

1. コマンドラインLDAPツールを使用して、Oracle Internet Directoryに新規ユーザー・エントリが作成されます。

2. 次に、Oracle Directory Integration Platformはスケジュールされた同期間隔で、プロビジョニングの必要な新規ユーザー・エントリがOracle Internet Directoryに存在するか確認し、アプリケーション固有のユーザー・プリファレンスを含む関連エントリを作成します。

3. Oracle Directory Integration PlatformからPL/SQLプラグインにプロビジョニング・イベントが送信されます。

プロビジョニングのデータ・フロー

プロビジョニングが同期か非同期かにかかわらず、アプリケーションでは、プロビジョニング・インテリジェント機能を拡張してビジネス・ポリシーを実装するために、プレデータ・エントリ・プラグインとポストデータ・エントリ・プラグインを起動できます。どちらのプラグインも、Oracle Internet Directoryプロビジョニング・コンソールなどのOracle Identity ManagementコンポーネントやprovProfileBulkProvコマンドによるバルク・プロビジョニングから起動できます。

プレデータ・エントリ・プラグインは、プロビジョニング・ポリシーに基づいてフィールドを移入します。このプラグインの主な目的は、アプリケーションでユーザーをプロビジョニングするかどうかを決定することです。たとえば、財務管理アプリケーションにはマネージャのみをプロビジョニングするというポリシーを持つ組織の場合、プレデータ・エントリ・プラグインを使用することで、どのユーザー・エントリをプロビジョニングするかを特定できます。共通のユーザー属性は、このプラグインの起動時にすでに移入が行われているため、プロビジョニングの決定を行うための十分な情報がすでに存在していることになります。

ポストデータ・エントリ・プラグインは、主に、ユーザーによって入力された共通属性とアプリケーション固有属性に関するデータを検証します。プロビジョニングを続けるためには、このプラグインでの検証に成功する必要があります。

プロビジョニングのデータ・フローは、次のプロセスに従います。

1. ベース・ユーザー情報が作成されます。

2. プレデータ・エントリ・プラグインが起動し、ポリシーに基づいてフィールドの移入が行われます。

3. ポストデータ・エントリ・プラグインが起動し、ユーザーが入力したデータが検証されます。

4. プロビジョニング方式に応じて、非同期または同期プロビジョニング・プロシージャが起動します。

プロビジョニング・コンソールでプロビジョニングを実行する場合、管理者は、プレデータ・エントリ・プラグインが起動した後、かつポストデータ・エントリ・プラグインが起動する前にアプリケーション属性を変更できます。

8.5.1.1.4 構成アーティファクト

Oracle Directory Integration Platformに関する構成の詳細は、dip-config.xmlファイルで管理されます。この構成ファイルは、Oracle Directory Integration Platformアプリケーションの一部としてパッケージ化されています。dip-config.xmlファイルのデフォルトの場所は、次のとおりです。

MW_HOME/user_projects/domains/domainName/config/
fmwconfig/servers/serverName/applications/DIP_11.1.1.2.0/configuration

domainNameはドメインの名前で、serverNameは管理対象サーバーの名前です。

パラメータは、Config MBeansにより管理されます。表8-6は、Oracle Directory Integration Platformを起動するためにdip-config.xmlに必要な構成パラメータを示しています。

表8-6 Directory Integration Platformの起動に必要な構成パラメータ

パラメータ

説明

OIDホスト

Oracle Directory Integration Platformが接続する必要のあるOracle Internet Directoryのホスト名。

OIDポート

Oracle Internet Directoryのポート

SSLモード

Oracle Internet Directoryへの接続に使用されるSSLモード。有効な値は次のとおりです。

- 0: 非SSL

- 1: 認証なしのSSL(ハンドシェイクのみ)。これはデフォルトのモードです。

- 2: サーバーのみの認証に対応したSSL。認証はトラスト・ポイント証明書に基づいています。

JKSの場所

Javaキーストア(JKS)を格納するファイル・システムの場所

クォーツ・スレッド

プロセスをスケジュールするクォーツで使用できる最大スレッド数

Oracle Directory Integration Platformサーバーは、実行状態になると、同期化の処理および機能のプロビジョニングに関する詳細をOracle Internet Directoryから読み込みます。

同期プロファイルおよびプロビジョニング・プロファイル作成の詳細は、次を参照してください。

- Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイドの同期プロファイルの作成に関する項。

- Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイドのoidprovtoolを使用したプロビジョニング・プロファイルの管理に関する項。

8.5.1.1.5 外部依存性

Oracle Directory Integration Platformは、メタデータの格納にOracle Internet Directoryを使用します。クォーツ・スケジューラは、ODSSMスキーマを使用してデータベースにスケジュール情報を格納します。Oracle Internet DirectoryとOracle Directory Integration Platformは、同じデータベースを使用します。Oracle Directory Integration Platformに必要なODSSMスキーマは、Oracle Internet Directoryのスキーマ作成の一環として作成されます。

Oracle Directory Integration Platformは、Oracleが提供するセキュアなフレームワークであるOracle資格証明ストア・フレームワーク(CSF)、およびSSLを介したOracle Internet Directoryやサード・パーティのLDAPストアへの接続に使用されるウォレットと資格証明を保存するJavaキーストア(JKS)にも依存します。

Oracle Directory Integration Platformは、デフォルトでインストールされるOracle Fusion Middleware共通の監査フレームワークにも依存します。

8.5.1.1.6 Oracle Directory Integration Platformのログ・ファイル

Oracle Directory Integration Platformは、Oracle WebLogic Server上にデプロイされるJ2EEアプリケーションです。ログ・メッセージはすべて、アプリケーションがデプロイされるOracle WebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

8.5.2 Oracle Directory Integration Platformの高可用性の概要

この項では、Oracle Directory Integration Platformを高可用性構成で使用する場合の概要について説明します。

この項で説明するOracle Directory Integration Platformの高可用性構成では、2つのホスト上にOracle Directory Integration PlatformとOracle Directory Services Managerが、2ノードのアクティブ/アクティブの高可用性構成で、インストールおよび構成されています。

8.5.2.1 Oracle Directory Integration Platformの高可用性アーキテクチャ

図8-7は、Oracle Directory Integration PlatformとOracle Directory Services Managerのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。

図8-7 高可用性アーキテクチャのOracle Directory Integration PlatformとOracle Directory Services Manager

「図8-7 高可用性アーキテクチャのOracle Directory Integration PlatformとOracle Directory Services Manager」の説明

図8-7では、アプリケーション層にコンピュータIDMHOST1とIDMHOST2があります。

IDMHOST1では、次のインストールが実行されています。

- Oracle Directory Integration PlatformインスタンスとOracle Directory Services Managerインスタンスが、WLS_ODS1管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

- WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。

IDMHOST2では、次のインストールが実行されています。

- Oracle Directory Integration PlatformインスタンスとOracle Directory Services Managerインスタンスが、WLS_ODS2管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
IDMHOST2上のWLS_ODS2管理対象サーバーにあるインスタンスと、IDMHOST1上のWLS_ODS1管理対象サーバーにあるインスタンスは、CLUSTER_ODSクラスタとして構成されています。

- WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。IDMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。

8.5.2.1.1 クラスタの起動と停止

高可用性アーキテクチャでは、Oracle Directory Integration PlatformおよびOracle Directory Services ManagerはOracle WebLogicクラスタにデプロイされます。このクラスタには、その一部として少なくとも2つのサーバーが存在します。

WebLogic Serverはデフォルトで、アプリケーションの起動、停止および監視を行います。Oracle Directory Integration PlatformとOracle Directory Services Managerの各アプリケーションはともにデフォルトで、基盤となるWebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。ノード・マネージャがこのサーバーを再起動できない場合は、フロントエンドのロード・バランシング・ルーターによってクラスタ内のWebLogicインスタンスの障害が検出され、障害が発生していないインスタンスにトラフィックがルーティングされます。

8.5.2.1.2 クラスタワイドの構成変更

Oracle Internet Directoryをアクティブ/アクティブの高可用性構成にデプロイする場合は、そのクラスタに属するすべてのOracle Internet Directoryインスタンスが同じデータベースを共有します。いずれかのOracle Internet DirectoryノードのOracle Directory Integration Platformに加えられた変更は、クラスタ内のすべてのOracle Internet Directoryインスタンスに自動的に伝播されます。

次の各項では、Oracle Internet Directoryマルチマスター・レプリケーション・デプロイメントにおけるOracle Directory Integration Platformアプリケーションの構成変更について説明します。マルチマスター・レプリケーションでは、次に説明するように、クラスタ内のすべてのノードに構成の変更を適用する必要があります。

ディレクトリ統合プロファイル

デフォルトのOracle Internet Directoryマルチマスター・レプリケーション環境では、任意のOracle Internet Directoryノード上のディレクトリ統合プロファイルへの変更は、他のOracle Internet Directoryノードへは自動的にレプリケートされません。これらのファイルは、1次ノードから2次ノードに対して定期的に手動でコピーする必要があります。これにより、1次ノードで問題が発生した場合、2次ノードでディレクトリ同期プロファイルを実行できます。

Oracle Directory Integration Platformで使用されるパラメータの1つにorcllastappliedchangenumberがあります。ディレクトリ同期プロファイルのlastchangenumber属性に指定した値は、Oracle Directory Integration Platformが実行されているディレクトリ・サーバーによって異なります。アクティブ/アクティブ構成のOracle Directory Integration Platformでは、すべてのインスタンスのlastchangenumber属性を手動で更新する必要があります。

次の項では、同期プロファイルとプロビジョニング・プロファイルをマルチマスター・レプリケーション・デプロイメントの1次Oracle Internet Directoryから2次Oracle Internet Directoryにコピーする手順の詳細について説明します。

ディレクトリ同期プロファイル

エクスポート・プロファイルをターゲット・ノードにコピーした後、lastchangenumber属性をターゲット・ノードの値で更新する必要があります。値を更新する手順は次のとおりです。

1. 同期プロファイルを無効化します。

2. ldapsearchコマンドを使用して、ターゲット・ノードのlastchangenumber属性の値を取得します。

3. ldapsearchを使用して、プロファイル・エントリのLDIFダンプを取得します。

4. ldapaddを使用して、他のOracle Internet Directoryインスタンスにプロファイルを追加します。

5. manageSyncProfilesコマンドのupdatechgnum演算子を使用して、ターゲット・ノードにコピーしたエクスポート・プロファイルのlastchangenumber属性をステップ2で取得した値で更新します。

6. 同期プロファイルを有効化します。

ディレクトリ・プロビジョニング・プロファイル

デフォルトのOracle Internet Directoryマルチマスター・レプリケーション環境では、Oracle Directory Integration Platformは1次Oracle Internet Directoryと同じ場所にインストールされます。この項の情報と手順は、マルチマスター・レプリケーションが設定されている場合にのみ適用できます。

1次ノードで障害が発生した場合、そのノードにあるすべてのプロファイルに対するイベント伝播は停止します。イベントはキューに入れられ、1次ノードの停止中にも失われることはありませんが、どのアプリケーションにもイベントは伝播されません。バージョン1.0および2.0のプロファイルで、1次ノードが停止した場合でもイベントの伝播が継続されることを保証するには、ディレクトリ・プロビジョニング・プロファイルを他の2次ノードにコピーする必要があります。

ただし、ディレクトリ・プロビジョニング・プロファイルは、アプリケーションがインストールされた直後からOracle Internet Directoryでユーザー変更が行われる前にしか、1次ノードから任意の2次ノードに対してコピーされません。

1次ノードと2次ノード間でディレクトリ・プロビジョニング・プロファイルを同期するには、次の手順を実行する必要があります。

1. 1次ノードで、ldifwriteコマンドを使用してこのコンテナからエントリのLDIFダンプを作成します。

cn=provisioning profiles,cn=changelog subscriber,cn=oracle internet directory

2. LDIFダンプを2次ノードにコピーします。

3. ldapaddコマンドを使用して、2次ノードにプロファイルを追加します。

8.5.2.2 障害からの保護および予想される動作

この項では、Oracle Directory Integration Platformのアクティブ/アクティブ・クラスタにおける様々な障害からの保護について説明します。

8.5.2.2.1 プロセス障害

高可用性環境では、Oracle Directory Integration Platformアプリケーションは、少なくとも2つのWebLogicインスタンスで構成されるOracle WebLogic Serverクラスタにデプロイされます。

Oracle Directory Integration Platformアプリケーションはデフォルトで、基盤となるWebLogicクラスタの高可用性機能を利用します。Oracle Directory Integration Platformがデプロイされるときに、クォーツ・スケジューラはクラスタリング・オプションを使用して起動されます。クラスタリング・オプションを指定して起動されると、スケジューラはノードの負荷に応じて、クラスタ内の利用可能なノードのいずれかでジョブを実行します。1つ以上のノードでハードウェアなどの障害が発生すると、スケジューラは利用可能なノードでジョブを実行します。

さらに、高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。

Oracle Directory Integration Platformアプリケーション内では、クォーツ・スケジューラによって、実際の処理を行うプロビジョニングまたは同期化EJBが起動されます。クォーツ・スケジューラによってEJBが起動されるとただちに、そのEJBにはジョブ実行中のタグが付けられます。EJBがジョブに失敗した場合は、クォーツ・スケジューラはジョブに失敗のマークを付け、後で別のEJBで実行されるよう再スケジュールします。

8.5.2.2.2 障害発生時に予想されるクライアント・アプリケーションの動作

Oracle Directory Integration Platformのフェイルオーバーは、エンド・ユーザーに対して透過的ではありません。

高可用性トポロジにデプロイされたOracle Directory Integration Platformインスタンスに対する構成の変更は、トポロジ内のすべてのOracle Directory Integration Platformインスタンスに自動的には伝播されません。

トポロジ内のすべてのOracle Directory Integration Platformインスタンスに同一の構成変更を行うには、manageDIPServerConfigツールの使用をお薦めします。これにより、トポロジ内のすべてのOracle Directory Integration Platformインスタンスの構成が同一になることが保証されます。

manageDIPServerConfigツールの詳細は、Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイドを参照してください。

8.5.2.2.3 外部依存性の障害

Oracle Directory Integration Platformの起動時には、バックエンド・リポジトリ、Oracle Internet Directory、資格証明ストア・フレームワーク、およびWebLogic管理対象サーバーが使用可能である必要があります。これらのいずれかが使用できない場合、Oracle Directory Integration Platformは起動できません。

8.5.2.3 Oracle Directory Integration Platformの前提条件

この項では、Oracle Directory Integration Platformの高可用性アーキテクチャを設定するための前提条件について説明します。

注意:

Oracle Directory Integration Platformは、クォーツを使用して、データベース内のジョブとスケジュールを管理します。クォーツ・ジョブをクラスタ内の複数のOracle Directory Integration Platformノードで実行するには、クラスタ・ノードのシステム・クロックを同期させる必要があります。

Oracle Internet Directoryのインストールと構成は、次の各項の説明に従います。

- 第8.3.2.3項「Oracle Internet Directoryの前提条件」

- 第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」

8.5.3 Oracle Directory Integration PlatformおよびOracle Directory Services Managerの高可用性の構成手順

高可用性環境では、WebLogic Serverのユーティリティを使用してOracle Directory Integration PlatformインスタンスとOracle Directory Services Managerのクラスタ化、ロード・バランシングおよびフェイルオーバーを行うことをお薦めします。

この項では、IDMHOST1とIDMHOST2で次のインストールと構成を実行する手順について説明します。

- 第8.5.3.1項「IDMHOST1でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成」

- 第8.5.3.2項「IDMHOST1での管理サーバー用boot.propertiesの作成」

- 第8.5.3.3項「IDMHOST2でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成」

- 第8.5.3.4項「Oracle Directory Integration PlatformとOracle Directory Services Managerのインストール後の手順」

- 第8.5.3.5項「WEBHOST1およびWEBHOST2へのOracle Fusion Middlewareコンポーネントのインストール」

- 第8.5.3.6項「WEBHOST1およびWEBHOST2でのOracle HTTP Serverの構成」

Oracle Directory Integration PlatformおよびOracle Directory Services Managerは、同一インストール・セッション、同一管理対象サーバー、または同一ホストにインストールする必要はありません。この項のインストールと構成の手順は、Oracle Directory Integration PlatformとOracle Directory Services Managerを2ノードのアクティブ/アクティブ・クラスタにインストールする場合の一例です。

8.5.3.1 IDMHOST1でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成

次の手順に従って、IDMHOST1上のOracle Directory Integration PlatformとOracle Directory Services Managerを構成します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがIDMHOST1にインストールされ、アップグレードされていることを確認します。

3. ポート7006がIDMHOST1上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":7006"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr ":7006"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

ポート7006のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Directory Services Managerのポート番号を指定する行は非コメント化)を割り当てます。

# The port for ODSM server port
ODS Server Port No = 7006

7. 次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. ドメインの選択画面で、新規ドメインの作成を選択して、ドメインの詳細を入力します。

- ユーザー名: weblogic

- ユーザー・パスワード: ******

- パスワードの確認: ******

- ドメイン名: IDMDomain

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

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所: この値は入力済になっており、変更できません。

- Oracleホーム・ディレクトリ: この値は入力済になっており、変更できません。

ods

- WebLogic Serverのディレクトリ:

/u01/app/oracle/product/fmw/wlserver_10.3

- Oracleインスタンスの場所:

/u01/app/oracle/admin/ods_instance1

- Oracleインスタンス名:

ods_instance1

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

11. 「Oracle Configuration Managerの詳細の指定」画面で、次の値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、Oracle Directory Integration Platform、管理コンポーネント - Oracle Directory Services Managerを選択します。他のコンポーネントをすべて選択解除します。Oracle Internet Directoryを前提条件どおりに構成する必要があるという警告は無視します。
「クラスタ化」チェック・ボックスを選択します。

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

注意:

インストーラによって設定されるデフォルトのOracle WebLogic Serverのクラスタ・モードは、(マルチキャストではなく)ユニキャストになります。

13. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリにコピーしたstaticports.iniファイルのファイル名を入力します。
「次へ」をクリックします。

14. OID詳細の指定画面で、次のように指定します。

- ホスト名: oid.mycompany.com

- ポート: 636

- ユーザー名: cn=orcladmin

- パスワード: ******

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

15. 「スキーマ・データベースの指定」画面で、既存のスキーマの使用を選択し、次の値を指定します。

- 接続文字列:

infradbhost1-vip.mycompany.com:1521:oiddb1^infradbhost2-vip.mycompany.com:1521:oiddb2@oid.mycompany.com

注意:

Oracle RACデータベースの接続文字列の情報は、host1:port1:instance1^host2:port2:instance2@servicenameの書式で指定する必要があります。

このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。

前述のように指定した情報は、完全で正確である必要があります。具体的には、ホスト、ポート、およびインスタンス名が各Oracle RACインスタンスに正しく指定されている必要があります。また、指定したOracle RACインスタンスのすべてにサービス名が構成されている必要があります。

Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。

- ユーザー名: ODSSM

- パスワード: ******

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

16. 「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。

17. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

18. 「構成」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。終了したら、「次へ」をクリックします。

19. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.5.3.2 IDMHOST1での管理サーバー用boot.propertiesの作成

この項では、IDMHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法を説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。

次の手順に従って、boot.propertiesファイルを作成します。

1. IDMHOST1で、次のディレクトリに移動します。

MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

例:

cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

2. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

username=adminUser
password=adminUserPassword

注意:

管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。

3. 管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。

4. MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、IDMHOST1上の管理サーバーを起動します。

5. Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。

- WebLogic Server管理コンソール:

http://oidhost1.mycompany.com:7001/console

- Oracle Enterprise Manager Fusion Middleware Control:

http://oidhost1.mycompany.com:7001/em

weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

8.5.3.3 IDMHOST2でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成

IDMHOST2上のOracle Directory Integration PlatformとOracle Directory Services Managerを構成する手順は、次のとおりです。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがIDMHOST2にインストールされ、アップグレードされていることを確認します。

3. 次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

4. 「ようこそ」画面で「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

6. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。

7. ドメインの選択画面で、「クラスタを開く」オプションを選択して、次の例の値を指定します。

- ホスト名: idmhost1.mycompany.com

- ポート: 7001

- ユーザー名: weblogic

- パスワード: <weblogicユーザーのパスワード>

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

注意:

IDMHOST1上で、Oracle WebLogic管理サーバーが実行されています。

8. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所: 入力済になっており、変更できません。

/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ: 入力済になっており、変更できません。

ods

- WebLogic Serverのディレクトリ:

/u01/app/oracle/product/fmw/wlserver_10.3

- Oracleインスタンスの場所:

/u01/app/oracle/admin/ods_instance2

- Oracleインスタンス名:

ods_instance2

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

9. 「コンポーネントの構成」画面で、Oracle DIPおよび管理コンポーネントを除く全製品の選択を解除します。
「次へ」をクリックします。

10. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を選択し、一時ディレクトリで編集したstaticports.iniファイルへのフルパス名を入力します。
「次へ」をクリックします。

11. 「インストール・サマリー」画面で、選択した内容を確認します。なんらかの変更が必要な場合は、「戻る」をクリックします。選択が適切であれば、「インストール」をクリックします。

12. 「インストールの進行状況」画面で、インストールの進行状況を確認します。

13. UNIXシステムでは、インストールが終了すると、oracleRoot.shの確認ダイアログ・ボックスが開きます。これは、インストールを続行する前に構成スクリプトをrootとして実行する必要があることを説明しています。
確認ダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootとしてログインして、次のスクリプト・ファイルを実行します。

/u01/app/oracle/product/fmw/ods/oracleRoot.sh

14. 構成の進行状況画面で、構成の進行状況を確認します。

15. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.5.3.4 Oracle Directory Integration PlatformとOracle Directory Services Managerのインストール後の手順

前の項では、インストーラによってIDMHOST2に2つ目の管理対象サーバーwls_ods2が作成されました。ただし、IDMHOST2上にOracle Directory Integration Platformアプリケーションがデプロイされていないため、新たに作成した管理対象サーバーは自動的に起動されません。また、WebLogic管理コンソールには、IDMHOST2上のwls_ods2管理対象サーバーの状態がUNKNOWNと表示されます。

この項にあるインストール後の手順を実行して、IDMHOST2上のOracle Directory Integration PlatformとOracle Directory Services Managerアプリケーションのインストールと構成を完了します。

8.5.3.4.1 IDMHOST1からIDMHOST2へのOracle Directory Integration Platformの構成のコピー

IDMHOST1からIDMHOST2にOracle Directory Integration Platformアプリケーションを直接コピーする手順は、次のとおりです。

IDMHOST1にあるディレクトリMW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applicationsをIDMHOST2の場所MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ ods2にコピーします。

たとえば、IDMHOST1から次のコマンドを実行します。

scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applications/odsm user@IDMHOST2:/MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods2

8.5.3.4.2 クラスタ内のIDMHOST2での管理対象サーバーの再起動

クラスタ内のIDMHOST2上に新たに作成したwls_ods2管理対象サーバーを起動する手順は、次のとおりです。

1. このURLを使用して、Oracle WebLogic Server管理コンソールにアクセスします。

http://idmhost1.mycompany.com:7001/console

管理者の資格証明を使用して、コンソールにログインします。

2. 左側のペインで、「環境」を開き、「クラスタ」を選択します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。

3. 停止する管理対象サーバー(wls_ods2)が存在するクラスタ(cluster_ods)のリンクをクリックします。

4. 「制御」を選択します。

5. 「このクラスタの管理対象サーバーのインスタンス」で、起動する管理対象サーバー(wls_ods2)の横のチェック・ボックスを選択して「起動」をクリックします。

6. 「クラスタ・ライフサイクル・アシスタント」ページで、「はい」をクリックして確定します。

7. ノード・マネージャによって、ターゲット・マシン上のサーバーが起動されます。ノード・マネージャによる起動シーケンスが終了すると、「サーバー状態」表の「状態」列にサーバーの状態が表示されます。この状態はRUNNINGになります。

8.5.3.5 WEBHOST1およびWEBHOST2へのOracle Fusion Middlewareコンポーネントのインストール

この項では、Oracle HTTP Server用にOracleホーム(ORACLE_HOME)に必要なバイナリをインストールする方法について説明します。

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

8.5.3.5.1 Web Tier用のOracle HTTP Serverのインストール

この項では、Oracle HTTP Serverをインストールする方法について説明します。

システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合、この手順をスキップできます。

Oracle Web Tierコンポーネントのインストーラを起動します。

HOST1> ./runInstaller

その後、次のインストール手順を実行します。

1. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

2. 「インストール場所の指定」画面で、次の値を入力します。
MW_HOME: MW_HOMEの値を入力します。例:

/u01/app/product/fmw

ドロップダウン・リストから、すでにインストールされているMiddlewareホームを選択します。Oracle HTTP Server Oracleホーム(OHS_ORACLE_HOME)ディレクトリには、ディレクトリ名WEBを入力します。

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

3. 「サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。

4. 「インストール完了」画面で「終了」をクリックします。

8.5.3.5.2 Oracle HTTP Server Oracleホームのパッチ・セット3へのアップグレード

Oracle HTTP Serverソフトウェアを11.1.1.4(パッチ・セット3)にアップグレードする手順は、次のとおりです。

1. ./runinstallerを実行して、Web Tierアップグレード・インストーラを起動します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「前提条件のチェック」画面で、「次へ」をクリックします。

4. 「インストール場所の指定」画面で、Oracle MiddlewareホームへのパスおよびOracle HTTP Server Oracleホーム・ディレクトリの名前を指定します。

5. 「インストール・サマリー」画面で、選択内容を確認して「インストール」をクリックします。インストールが完了したら、oracleRoot.shの確認ダイアログ・ボックスが開きます。このダイアログ・ボックスは、インストールを続行する前に構成スクリプトをrootユーザーとして実行する必要があることを示しています。

6. 確認ダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootユーザーとしてログインして、スクリプト・ファイル/u01/app/oracle/product/fmw/id/oracleRoot.shを実行します。スクリプトが完了したら、「OK」をクリックします。

7. 「インストール完了」画面で「終了」をクリックして終了します。

8.5.3.6 WEBHOST1およびWEBHOST2でのOracle HTTP Serverの構成

この項では、Oracle HTTP ServerをWEBHOST1およびWEBHOST2で構成する方法について説明します。Oracle Directory Integration Platform以外にインストール済のコンポーネントがない場合は、Oracle HTTP Serverは必要ありません。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。

2. 第8.5.3.5項「WEBHOST1およびWEBHOST2へのOracle Fusion Middlewareコンポーネントのインストール」の説明に従って、Oracle HTTP ServerソフトウェアがWEBHOST1およびWEBHOST2にインストールされ、アップグレードされていることを確認します。

3. ポート7777がWEBHOST1またはWEBHOST2上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":7777"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr ":7777"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle HTTP Serverのポート番号を指定する行は非コメント化)を割り当てます。

# The http_main port for ohs component
OHS Port = 7777

7. 次のようにして、ORACLE_HOME/binディレクトリの下にあるOracle Fusion Middleware 11g Web Tierユーティリティの構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」を選択します。

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

10. 「WebLogicドメインの指定」画面で:
Oracle WebLogic Serverをインストールした場所を入力します。管理サーバーが実行されている必要があります。

- ドメイン・ホスト名: IDMHOST1

- ドメインのポート番号: 7001

- ユーザー名: weblogic

- パスワード: ******

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

11. 「コンポーネントの詳細の指定」画面で、次の操作を行います。

- WEBHOST1に次の値を入力します。

- インスタンス・ホームの場所: /u01/app/oracle/admin/ohs_inst1

- インスタンス名: ohs_inst1

- OHSコンポーネント名: ohs1

- WEBHOST2に次の値を入力します。

- インスタンス・ホームの場所: /u01/app/oracle/admin/ohs_inst2

- インスタンス名: ohs_inst2

- OHSコンポーネント名: ohs2

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

12. 「Web Tierポートの詳細の指定」画面で、次の操作を行います。

- 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

- Oracle HTTP Serverポートを入力します(例: 7777)。

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

13. 「Oracle Configuration Manager」画面で、次のように入力します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取ります。: このチェック・ボックスを選択します。

14. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「次へ」をクリックします。

15. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

16. 「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。

17. 「構成が完了しました」画面で「終了」をクリックして終了します。

8.5.3.6.1 Oracle Directory Services ManagerのためのOracle HTTP Serverの高可用性の構成

この項の手順に従って、Oracle Directory Services ManagerのためのOracle HTTP Serverの高可用性を構成します。

1. Oracle HTTP Serverで、ロード・バランシング・ルーターの仮想ホストを使用するように構成します。
WEBHOST1およびWEBHOST2上のOracle HTTP Serverインスタンスは、ロード・バランサの仮想ホストの設定を使用するように構成する必要があります。仮想ホストの詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。

Oracle HTTP Serverインスタンスでロード・バランシング・ルーターの仮想ホストを使用するように構成するには、httpd.confファイルを編集して、仮想ホストのディレクティブを次のように定義します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName admin.mycompany.com:7777
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>

httpd.confファイルは、WEBHOST1およびWEBHOST2上のORACLE_INSTANCE/config/OHS/componentNameディレクトリにあります。

2. Oracle HTTP ServerからOracle Directory Services Manager、Oracle Enterprise Manager Fusion Middleware Control、およびOracle WebLogic Server管理コンソールにルーティングされるように構成します。
Oracle HTTP Serverインスタンスで、IDMHOST1とIDMHOST2のOracle Directory Services Managerアプリケーションへのルーティングを有効にするには、WEBHOST1とWEBHOST2のORACLE_INSTANCE/config/OHS/componentNameディレクトリにあるmod_wl_ohs.confファイルに次のディレクティブを追加します。

<IfModule weblogic.module>
WebLogicHost IDMHOST1.MYCOMPANY.COM
WebLogicPort PORT
</IfModule>

<Location /odsm>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.MYCOMPANY.COM:<PORT>,IDMHOST2.MYCOMPANY.COM:<PORT>
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#AdminServer and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /odsm-config>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.MYCOMPANY.COM:<PORT>,IDMHOST2.MYCOMPANY.COM:<PORT>
</Location>

3. opmnctlコマンドを使用してOracle HTTP Serverの停止と起動を行います。

ORACLE_INSTANCE/bin/opmnctl stopall
ORACLE_INSTANCE/bin/opmnctl startall

4. ロード・バランシング・ルーターの仮想ホストを使用して、次の各コンソールにアクセスできることを確認します。
Oracle Directory Services Managerコンソール:

http://admin.mycompany.com:7777/odsm

Oracle WebLogic Server管理コンソール:

http://idmhost1.mycompany.com:7001/console

Oracle Enterprise Manager Fusion Middleware Control:

http://idmhost1.mycompany.com:7001/em

注意:

高可用性構成にデプロイされたOracle Directory Integration PlatformがサーバーのみのSSL認証(SSL Mode2)に対応している場合は、すべてのOracle Internet Directoryインスタンスの証明書を含む共通キーストアを使用する必要があります。共通キーストアは、すべてのOracle Internet Directoryインスタンスから証明書をインポートし、Oracle Directory Integration Platformが実行されているすべてのノードにそのキーストアをコピーすることによって作成できます。

Oracle Directory Integration PlatformにおけるSSLの使用の詳細は、Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイドを参照してください。

8.5.4 Oracle Directory Integration Platformのフェイルオーバーおよび予想される動作

高可用性環境では、Oracle Directory Integration Platformアプリケーションは、少なくとも2つのWebLogicインスタンスで構成されるOracle WebLogic Serverクラスタにデプロイされます。

Oracle Directory Integration Platformアプリケーションはデフォルトで、基盤となるWebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

さらに、高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。データベース・インスタンスの障害が発生した場合は、障害が発生していないOracle RACノードが残りのプロセスを引き継ぎます。第8.5.5項「Oracle Directory Integration Platformの高可用性のトラブルシューティング」で説明されているように、Oracle RACのフェイルオーバー時には、管理対象サーバー・ログに無害のエラーが記録される場合があります。

8.5.5 Oracle Directory Integration Platformの高可用性のトラブルシューティング

この項では、Oracle Directory Integration Platformの高可用性に関する問題に対処する方法について説明します。

8.5.5.1 Oracle RACフェイルオーバー時にOracle Directory Integration Platformに関して受信される管理対象サーバー・ログ・ファイルの例外

Oracle RACのフェイルオーバー時に、Oracle Directory Integration Platformアプリケーションを実行する管理対象サーバーのログ・ファイルに次のような例外が表示されることがあります。これらのエラーは、フェイルオーバー時に、WebLogic Serverプラットフォーム上に構成された複数のデータ・ソースによって、Oracle RAC データベースの状態の検証が試行されるときにスローされます。これらは無害なエラーであり、無視してかまいません。Oracle Directory Integration Platformアプリケーションは、数分の遅延の後、リカバリして正常動作を開始します。Oracle RACのフェイルオーバー時に、1つのOracle RACインスタンスが実行を続けていれば、Oracle Directory Integration Platformに停止時間は発生しません。

RuntimeException:
[2008-11-21T00:11:10.915-08:00] [wls_ods] [ERROR] []
[org.quartz.impl.jdbcjobstore.JobStoreTX] [tid: 25] [userId: <anonymous>]
[ecid: 0000Hqy69UiFW7V6u3FCEH199aj0000009,0] [APP: DIP] ClusterManager: Error
managing cluster: Failed to obtain DB connection from data source
'schedulerDS': java.sql.SQLException: Could not retrieve datasource via JNDI
url 'jdbc/schedulerDS' java.sql.SQLException: Cannot obtain connection:
driverURL = jdbc:weblogic:pool:schedulerDS, props =
{EmulateTwoPhaseCommit=false, connectionPoolID=schedulerDS,
jdbcTxDataSource=true, LoggingLastResource=false,
dataSourceName=schedulerDS}.[[
Nested Exception: java.lang.RuntimeException: Failed to setAutoCommit to true
for pool connection

AuthenticationException while connecting to OID:
[2008-11-21T00:12:08.812-08:00] [wls_ods] [ERROR] [DIP-10581] [oracle.dip]
[tid: 11] [userId: <anonymous>] [ecid: 0000Hqy6m54FW7V6u3FCEH199apO000000,0]
[APP: DIP] DIP was not able to get the context with the given details {0}[[
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]

ほとんどの例外は、スケジューラまたはLDAPに関連するものです。たとえば次のような例外です。

1. JNDI url 'jdbc/schedulerDS' java.sql.SQLExceptionによってデータ・ソースを取得できませんでした。

2. javax.naming.AuthenticationException: [LDAP: エラー・コード49 - 無効な資格証明]

8.5.5.2 WebLogicノード・マネージャの起動後に受信されたエラー・メッセージの処理

WebLogicノード・マネージャの起動後に次のエラー・メッセージが表示された場合は、エラー・メッセージの後に表示される手順に従います。

<Dec 15, 2008 8:40:05 PM> <Warning> <Uncaught exception in server handler:
javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was
received from stbee21.example.com - 152.68.64.2155. Check the peer to
determine why it rejected the certificate chain (trusted CA configuration,
hostname verification). SSL debug tracing may be required to determine the
exact reason the certificate was rejected.> javax.net.ssl.SSLKeyException:
[Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com -
152.68.64.215. Check the peer to determine why it rejected the certificate chain
(trusted CA configuration, hostname verification). SSL debug tracing may be
required to determine the exact reason the certificate was rejected.

1. まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. コンソールの左側のペインで、「サーバー」を開いて、「AdminServer (admin)」をクリックします。

3. 「構成」→「SSL」→詳細リンクを選択します。

4. 「ホスト名の検証」に「なし」を選択します。

5. 「保存」をクリックして設定を保存します。

6. これらの変更をアクティブにするには、管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックします。

7. すべてのサーバーを再起動します。

管理対象サーバーが管理モードで起動したら、次の手順を実行します。

1. まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. コンソールの左側のペインで、「サーバー」を開いて、ADMINモードで実行されているサーバーの名前をクリックします。

3. 「制御」→「起動と停止」タブを選択します。

4. サーバーの名前を選択します。

5. 「再開」をクリックします。

6. 「はい」をクリックしてサーバーを再開します。

8.5.5.3 WebLogicノード・マネージャが起動しない場合

WebLogicノード・マネージャの起動に失敗する場合は、次のドメイン・ファイルをIDMHOST1からIDMHOST2にコピーしてあることを確認します。

WL_HOME/common/nodemanager/nodemanager.domains

8.5.5.4 構成の変更が高可用性トポロジのすべてのOracle Directory Integration Platformインスタンスに自動的に伝播されない場合

高可用性トポロジのOracle Directory Integration Platformインスタンスの構成を変更した場合、この構成の変更はトポロジ内のすべてのOracle Directory Integration Platformインスタンスに自動的には伝播されません。

かわりに、manageDIPServerConfigツールを使用して、トポロジ内の各Oracle Directory Integration Platformインスタンスに対して同一の構成変更を行います。これにより、トポロジ内のすべてのOracle Directory Integration Platformインスタンスが同じ構成になります。manageDIPServerConfigツールの詳細は、Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイドを参照してください。

8.5.5.5 不明なエラー・メッセージのため操作を完了できない場合

manageSyncProfilesコマンドの使用時に次のエラー・メッセージが断続的に表示されることがあります。

OPERATION CANNOT BE COMPLETED FOR UNKNOWN ERRORS

このエラー・メッセージが表示される場合は、管理対象サーバー(wls_ods1またはwls_ods2)の起動と停止を行います。その後も問題が続く場合は、2つ目のノードにコピー・メソッドを実行します。

8.6 Oracle Directory Services Managerの高可用性

この項では、Oracle Directory Services Managerの概要、およびOracle Directory Integration PlatformとOracle Directory Services Managerに対して高可用性環境を設計およびデプロイする方法について説明します。

Oracle Directory Integration Platformの詳細は、第8.5項「Oracle Directory Integration Platformの高可用性」を参照してください。

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

- 第8.6.1項「Oracle Directory Services Managerコンポーネント・アーキテクチャ」

- 第8.6.2項「Oracle Directory Services Managerの高可用性の概要」

- 第8.6.3項「Oracle Directory Services Managerの高可用性の構成手順」

- 第8.6.4項「Oracle Directory Services Managerの高可用性の検証」

- 第8.6.5項「Oracle Directory Services Managerのフェイルオーバーおよび予想される動作」

- 第8.6.6項「Oracle Directory Services Managerのトラブルシューティング」

- 第8.6.7項「Oracle Directory Services Managerの高可用性に関するその他の考慮事項」

8.6.1 Oracle Directory Services Managerコンポーネント・アーキテクチャ

Oracle Directory Services Managerは、Oracle Internet DirectoryおよびOracle Virtual Directoryのインスタンスの管理用に統一されたグラフィカル・ユーザー・インタフェース(GUI)です。非推奨となったOracle Directory Managerにかわるものです。Oracle Directory Services Managerでは、ディレクトリ構造の構成、ディレクトリ内のオブジェクトの定義、ユーザー、グループおよびその他のエントリの追加と構成ができます。

エンド・ユーザーは、Oracle Directory Services Managerを使用して、各自のディレクトリ・エントリ、スキーマ、セキュリティおよびその他の機能を管理できます。

図8-8は、Oracle Directory Services Managerのアーキテクチャを示しています。

図8-8 Oracle Directory Services Managerのアーキテクチャ

「図8-8 Oracle Directory Services Managerのアーキテクチャ」の説明

図8-8は、非高可用性アーキテクチャにデプロイされたOracle Directory Services Managerを示しています。Oracle Directory Services ManagerはOracle WebLogic Server上にデプロイされます。Oracle Directory Services Managerは、管理対象となるOracle Virtual DirectoryとOracle Internet Directoryの各インスタンスと通信を行うよう構成されます。

Oracle Directory Services Managerでは、クライアント・ブラウザとの通信にHTTPプロトコルが使用されます。Oracle Internet Directoryとの通信には、LDAPプロトコルを使用し、Oracle Virtual Directoryとの通信はWebサービスを介して行われます。

8.6.1.1 Oracle Directory Services Managerコンポーネントの特性

Oracle Directory Services Managerは、Oracle Application Development Framework(ADF)ベースのJ2EEアプリケーションであり、Oracle WebLogic Server上にデプロイされます。デフォルトでは、Oracle Directory Services ManagerはWebLogicドメイン内の管理サーバーにデプロイされますが、使用環境の要件に応じて、管理対象サーバーにデプロイすることもできます。

Oracle Directory Services Managerは、Oracle Internet Directoryと同じノードまたは独立したノードにデプロイできます。

Oracle Directory Services Managerは、直接またはOracle Enterprise Manager Fusion Middleware Controlから起動できます。サポートされるブラウザには、Firefox 2、Firefox 3、およびInternet Explorer 7などがあります。

Oracle Directory Services Managerを直接起動するには、次のURLをブラウザのアドレス・フィールドに入力します。

http://host:port/odsm/faces/odsm.jspx

説明:

- hostは、Oracle Directory Services Managerが実行されている管理対象サーバーの名前です。

- portは、管理対象サーバーのポート番号です。

Oracle Directory Services ManagerをOracle Enterprise Manager Fusion Middleware Controlから起動する手順は次のとおりです。

- Oracle Internet Directoryターゲットの「Oracle Internet Directory」メニューで「Directory Services Manager」を選択して、「データ・ブラウザ」、「スキーマ」、「セキュリティ」、または「拡張」を選択します。

- Oracle Virtual Directoryターゲットの「Oracle Virtual Directory」メニューで「Directory Services Manager」を選択してから、「データ・ブラウザ」、「スキーマ」、「アダプタ」、「拡張機能」、または「クイック構成ウィザード」を選択します。

Oracle Directory Services Managerは、Oracle WebLogic Serverに対して外部的にステージングされたアプリケーションとしてデプロイされます。WebLogicサーバーは、Oracle Directory Services Managerアプリケーションの起動、停止、監視を管理します。Oracle Directory Services Managerは、管理対象サーバーの起動時に初期化を実行します。Oracleノード・マネージャは、サーバー・プロセスを監視して、障害発生時には再起動するように構成されます。

8.6.1.1.1 ライフサイクル管理

Oracle Directory Services Managerアプリケーションのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールのいずれかを使用して管理できます。

次のツールは、Oracle Directory Services Managerプロセスの起動と停止に使用できます。

- Oracle WebLogic Server Scripting Tool(WLST)

- Oracle Enterprise Manager Fusion Middleware Control

- WebLogic Server管理コンソール

- WebLogicノード・マネージャ

8.6.1.1.2 Oracle Directory Services Managerのログ・ファイル

Oracle Directory Services Managerのメッセージは、実行されているOracle WebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

8.6.2 Oracle Directory Services Managerの高可用性の概要

この項では、Oracle Directory Services Managerを高可用性構成で使用する場合の概要について説明します。

この項で説明するOracle Directory Services Managerの高可用性構成では、2つのホスト上にOracle Directory Services ManagerとOracle Directory Integration Platformが、2ノードのアクティブ/アクティブの高可用性構成でインストールおよび構成されています。

8.6.2.1 Oracle Directory Services Managerの高可用性アーキテクチャ

図8-9は、Oracle Directory Integration PlatformとOracle Directory Services Managerのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。

図8-9 高可用性アーキテクチャのOracle Directory Services ManagerとOracle Directory Integration Platform

「図8-9 高可用性アーキテクチャのOracle Directory Services ManagerとOracle Directory Integration Platform」の説明

図8-9では、アプリケーション層にコンピュータIDMHOST1とIDMHOST2があります。

IDMHOST1では、次のインストールが実行されています。

- Oracle Directory Integration PlatformインスタンスとOracle Directory Services Managerインスタンスが、WLS_ODS1管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

- WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。

IDMHOST2では、次のインストールが実行されています。

- Oracle Directory Integration PlatformインスタンスとOracle Directory Services Managerインスタンスが、WLS_ODS2管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
IDMHOST2上のWLS_ODS2管理対象サーバーにあるインスタンスと、IDMHOST1上のWLS_ODS1管理対象サーバーにあるインスタンスは、CLUSTER_ODSクラスタとして構成されています。

- WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。IDMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。

8.6.2.1.1 クラスタの起動と停止

高可用性アーキテクチャでは、Oracle Directory Integration PlatformおよびOracle Directory Services ManagerはOracle WebLogicクラスタにデプロイされます。このクラスタには、その一部として少なくとも2つのサーバーが存在します。

WebLogic Serverはデフォルトで、アプリケーションの起動、停止および監視を行います。Oracle Directory Integration PlatformとOracle Directory Services Managerの各アプリケーションはともにデフォルトで、基盤となるWebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。ノード・マネージャがこのサーバーを再起動できない場合は、フロントエンドのロード・バランシング・ルーターによってクラスタ内のWebLogicインスタンスの障害が検出され、障害が発生していないインスタンスにトラフィックがルーティングされます。

8.6.2.2 障害からの保護および予想される動作

この項では、Oracle Directory Services Managerのアクティブ/アクティブ・クラスタにおける様々な障害からの保護について説明します。

8.6.2.2.1 プロセス障害

高可用性環境では、Oracle Directory Services Managerアプリケーションは、少なくとも2つのWebLogicインスタンスで構成されるOracle WebLogic Serverクラスタにデプロイされます。

Oracle Directory Services Managerアプリケーションはデフォルトで、基盤となるWebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

さらに、高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。ノード・マネージャがこのサーバーを再起動できない場合は、Oracle HTTP Serverの一部として構成されているmod_wl_ohsによって、障害が発生していないWebLogicインスタンスにリクエストがルーティングされます。

OPMNは、Oracle HTTP Serverプロセスを監視し、障害発生時にはこのプロセスを再起動します。OPMNがHTTPプロセスを再起動できない場合は、フロントエンドのロード・バランシング・ルーターによってOracle HTTP Serverインスタンスの障害が検出され、障害が発生していないインスタンスにトラフィックがルーティングされます。

Oracle Directory Services Managerによって、セッション状態が管理されますが、障害発生時には、セッション状態の情報は障害が発生していないノードに対して引き継がれません。

8.6.2.2.2 障害発生時に予想されるクライアント・アプリケーションの動作

Oracle Directory Services Managerのフェイルオーバーは、透過的ではありません。Oracle WebLogic Serverインスタンスのフェイルオーバー時は、Oracle Directory Services Managerを使用して接続を再確立する必要があります。

8.6.2.2.3 予想される依存性の障害

Oracle Directory Services Managerでは、起動時にWebLogic管理対象サーバーが利用可能である必要があります。利用できない場合は、Oracle Directory Services Managerの起動に失敗します。

8.6.2.3 Oracle Directory Services Managerの前提条件

この項では、Oracle Directory Services Managerの高可用性アーキテクチャを設定するための前提条件について説明します。

注意:

Oracle Directory Services Managerを高可用性デプロイメントで使用する場合は、クラスタ・ノードのシステム・クロックを同期する必要があります。

Oracle Directory Services Managerをインストールする前に、次に示すコンポーネントをインストールして構成しておくことをお薦めします。前提条件、およびインストールと構成の手順については、次の各項を参照してください。

- Oracle Database
Oracle Real Application Clustersデータベースのインストールと構成は、次の各項の説明に従います。

- 第8.2項「Oracle Identity Managementの高可用性構成のための前提条件」

- 第8.2.2項「データベースに関する前提条件」

- 第8.2.3項「データベース・リポジトリのインストールと構成」

- Oracleリポジトリ作成ユーティリティ
Oracleリポジトリ作成ユーティリティをインストールして、必要なスキーマを作成しロードするには、次の各項の説明に従います。

- 第8.2.4項「リポジトリ作成ユーティリティ・ソフトウェアの取得」

- 第8.2.5項「Oracle Fusion Middleware 11gメタデータのデータベースの構成」

- ロード・バランサと仮想ホスト
ロード・バランサの構成と必要な仮想サーバーの作成の詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。

- Oracle Internet Directory
Oracle Internet Directoryのインストールと構成は、次の各項の説明に従います。

- 第8.3.2.3項「Oracle Internet Directoryの前提条件」

- 第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」

8.6.3 Oracle Directory Services Managerの高可用性の構成手順

図8-9に示されているアクティブ/アクティブの高可用性構成のインストールおよび構成の手順については、第8.5.3項「Oracle Directory Integration PlatformおよびOracle Directory Services Managerの高可用性の構成手順」を参照してください。

8.6.4 Oracle Directory Services Managerの高可用性の検証

この項では、高可用性構成のOracle Directory Services Managerを検証する方法について説明します。

8.6.4.1 WebLogic Serverインスタンスのフェイルオーバーの実行

Oracle HTTP Serverを通してOracle Directory Services Managerにアクセスしている間に、この項の手順を使用してWebLogic Serverインスタンスをフェイルオーバーし、フェイルオーバー後もOracle Directory Services Managerがアクセス可能であることを検証できます。

この例で使用するOracle HTTP Server仮想サーバー名は次のとおりです。

http://admin.mycompany.com

次の手順を実行します。

1. Oracle HTTP Server仮想サーバー名を使用してOracle Directory Services Managerにアクセスします。

http://admin.mycompany.com/odsm/faces/odsm.jspx

2. 「Oracle Directory Services Managerへようこそ」画面が表示されたら、Webブラウザを開いて次のURLを入力します。

http://hostname:port/console

hostnameは管理サーバーのDNS名、portは管理サーバーがリクエストをリスニングするポートのアドレス(デフォルトでは7001)です。

3. ログイン・ページで、管理サーバーの起動に使用するユーザー名とパスワードを入力して、「ログイン」をクリックします。

4. 次の手順に従って、Oracle Directory Services Managerがデプロイされている管理対象サーバーの1つを停止させます。

1. Oracle WebLogic Server管理コンソールの左側のペインで、「環境」を開いて、「サーバー」を選択します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。

2. 停止させる管理対象サーバーの名前をクリックします。(例:wls_ods1)。

3. wls_ods1の設定画面で「制御」→「起動と停止」タブを選択します。

4. 停止する管理対象サーバーの名前(wls_ods1)の横にあるチェック・ボックスを選択し、「停止」→「作業完了時」をクリックします。

5. 管理対象サーバー(wls_ods1)のステータスを確認します。

1. コンソールの左側のペインで、「環境」を開いて、「サーバー」を選択します。

2. 管理対象サーバー(wls_ods1)の状態はSHUTDOWNとなっているはずです。

6. Oracle HTTP Server仮想サーバー名を使用してOracle Directory Services Managerにアクセスします。

http://admin.mycompany.com/odsm/faces/odsm.jspx

「Oracle Directory Services Managerへようこそ」画面が表示されます。

8.6.4.2 Oracle RACデータベースのフェイルオーバーの実行

ロード・バランシング・ルーターを介してOracle Directory Services Managerにアクセスしている間に、この項の手順に従ってOracle RACデータベース・インスタンスを一度に1つずつフェイルオーバーし、フェイルオーバー後もOracle Directory Services Managerが機能していることを確認します。この例では、Oracle Directory Services Managerの確認だけでなく、Oracle Internet Directoryからデータベースへのアクセスも確認します。

この例で使用するOracle HTTP Server仮想サーバー名は次のとおりです。

http://admin.mycompany.com

この例で使用するLDAP仮想サーバー名は次のとおりです。

oid.mycompany.com:389

次の手順を実行します。

1. Oracle HTTP Server仮想サーバー名を使用してOracle Directory Services Managerにアクセスします。

http://admin.mycompany.com/odsm/faces/odsm.jspx

「Oracle Directory Services Managerへようこそ」画面が表示されます。

2. LDAP仮想サーバーを使用してOracle Internet Directoryに接続できることを確認します。

1. 右上隅にある「ディレクトリに接続」→「新規接続の作成」リンクを選択します。

2. 「新規接続」画面で、次の接続情報を入力し、「接続」をクリックします。

- ディレクトリ・タイプ: OID

- 名前: OIDHA

- サーバー: oid.mycompany.com

- ポート: 389

- SSL有効: 空白にしておきます。

- ユーザー名: cn=orcladmin

- パスワード: ********

- 開始ページ: Home(デフォルト)

3. INFRADBHOST1-VIP上のOracle Internet Directoryスキーマ・データベース・インスタンスを停止させるために、次のようにsrvctlコマンドを実行します(この例では、INFRADBというデータベース名を使用します)。

ORACLE_HOME/bin/srvctl stop instance -d infradb -i infradb1
ORACLE_HOME/bin/srvctl status database

4. Oracle Directory Services Managerの画面を再表示するか、タブ(「ホーム」、「データ・ブラウザ」、「スキーマ」、「セキュリティ」、「詳細」)の1つをクリックします。依然としてOracle Internet Directoryの情報にアクセスできるはずです。

5. INFRADBHOST1-VIP上でOracle Internet Directoryスキーマ・データベース・インスタンスを再起動させるために、次のようにsrvctlコマンドを実行します。

ORACLE_HOME/bin/srvctl start instance -d infradb -i infradb1
ORACLE_HOME/bin/srvctl status database

6. INFRADBHOST2-VIPでステップ3、4、および5を実行します。

8.6.5 Oracle Directory Services Managerのフェイルオーバーおよび予想される動作

この項では、Oracle Directory Services Managerを使用して、管理対象サーバー、Oracle Internet Directoryインスタンス、およびOracle RACデータベースのフェイルオーバーを検証する手順について説明します。

8.6.5.1 Oracle Directory Services Managerを使用した管理対象サーバーのフェイルオーバーの検証

Oracle Directory Services Managerを使用して、管理対象サーバーのフェイルオーバーを検証する手順は次のとおりです。

1. Webブラウザで、Oracle HTTP Serverのホストとポートを使用して、「Oracle Directory Services Manager」ページを起動します。例:

http://WEBHOST1:PORT/odsm/faces/odsm.jspx

2. Oracle Internet Directoryに接続します。

3. 管理コンソールに移動して、wls_ods1管理対象サーバーを停止します。

4. 「Oracle Directory Services Manager」ページに戻り、作業を続行します。

5. 「Oracle Directory Services Manager」ページの接続が切断されます。

6. 同じブラウザから、Oracle HTTP Serverのホストとポートを使用して「Oracle Directory Services Manager」ページを再起動します。

7. 接続を再確立します。

この動作が必要となる動作です。Oracle Directory Services Managerのフェイルオーバーは、透過的ではありません。WebLogic Serverインスタンスのフェイルオーバー時は、Oracle Directory Services Managerを使用して接続を再確立する必要があります。

8.6.5.2 Oracle Directory Services Managerを使用したOracle Internet Directoryインスタンスのフェイルオーバーの検証

Oracle Directory Services Managerを使用して、Oracle Internet Directoryインスタンスのフェイルオーバーを検証する手順は次のとおりです。

1. Webブラウザで、Oracle HTTP Serverのホストとポートを使用して、「Oracle Directory Services Manager」ページを起動します。例:

http://WEBHOST1:PORT/odsm/faces/odsm.jspx

2. Oracle Internet Directoryハードウェア・ロード・バランサに接続します。

3. 一度に1つずつOracle Internet Directoryインスタンスを停止します。

4. フェイルオーバー時には、「Oracle Directory Services Manager」ページに戻り、作業を続行します。

これは、Oracle Directory Services ManagerにOracle Internet Directoryが停止しているというメッセージのウィンドウが表示された場合に必要な対応です。Oracle Directory Services Managerは、Oracle Internet Directoryに再接続しますが、その接続はフェイルオーバー時には永続しないことがあります。詳細は、第8.6.6.4項「Oracle Internet Directoryのフェイルオーバー時に、メッセージ「LDAPサーバーが停止しています。」がOracle Directory Services Managerに表示される」を参照してください。

Oracle Directory Services Managerにアクセスしている間に、Oracle Internet Directoryインスタンスを一度に1つずつフェイルオーバーし、フェイルオーバー後もLDAPストアがアクセス可能であることを確認します。Oracle Directory Services ManagerからOracle Internet Directoryへの接続が永続的でない場合もあります。

8.6.5.3 Oracle Directory Services Managerを使用したOracle RACのフェイルオーバーの検証

Oracle Directory Services Managerを使用して、Oracle RACのフェイルオーバーを検証する手順は次のとおりです。

1. Webブラウザで、Oracle HTTP Serverのホストとポートを使用して、「Oracle Directory Services Manager」ページを起動します。例:

http://WEBHOST1:PORT/odsm/faces/odsm.jspx

2. 「Oracle Directory Services Manager」ページからOracle Internet Directoryに接続します。

3. 一度に1つずつOracle RACデータベース・インスタンスを停止します。

4. 「Oracle Directory Services Manager」ページに戻り、ステップ2で確立したOracle Internet Directoryの接続から作業を続行します。

Oracle RACのフェイルオーバー時に一時的に接続が失われますが、これはOracle Directory Services Managerに必要な動作です。Oracle RACのフェイルオーバー時にOracle Directory Services Managerに表示されるエラー・メッセージの詳細は、第8.6.6.5項「Oracle RACフェイルオーバー時のOracle Directory Services Managerの一時的な接続の消失」を参照してください。

ハードウェア・ロード・バランサを介してOracle Directory Services Managerへアクセスしている間に、Oracle RACデータベース・インスタンスを一度に1つずつフェイルオーバーし、フェイルオーバー後もOracle Directory Services Managerが機能していることを確認します。これによって、Oracle Directory Services Managerの確認だけでなく、Oracle Internet DirectoryからOracle RACデータベースへのアクセスも確認できます。

8.6.6 Oracle Directory Services Managerのトラブルシューティング

この項では、Oracle Directory Services Managerの高可用性に関する問題に対処する方法について説明します。

8.6.6.1 WebLogicノード・マネージャの起動後に受信されたエラー・メッセージの処理

WebLogicノード・マネージャの起動後に次のエラー・メッセージが表示された場合は、エラー・メッセージの後に表示される手順に従います。

<Dec 15, 2008 8:40:05 PM> <Warning> <Uncaught exception in server handler:
javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was
received from stbee21.example.com - 152.68.64.2155. Check the peer to
determine why it rejected the certificate chain (trusted CA configuration,
hostname verification). SSL debug tracing may be required to determine the
exact reason the certificate was rejected.> javax.net.ssl.SSLKeyException:
[Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com -
152.68.64.215. Check the peer to determine why it rejected the certificate chain
(trusted CA configuration, hostname verification). SSL debug tracing may be
required to determine the exact reason the certificate was rejected.

1. まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. コンソールの左側のペインで、「サーバー」を開いて、「AdminServer (admin)」をクリックします。

3. 「構成」→「SSL」→詳細リンクを選択します。

4. 「ホスト名の検証」に「なし」を選択します。

5. 「保存」をクリックします。

6. 管理コンソールの「チェンジ・センター」で、「変更のアクティブ化」をクリックします。

7. すべてのサーバーを再起動します。

管理対象サーバーが管理モードで起動したら、次の手順を実行します。

1. まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. コンソールの左側のペインで、「サーバー」を開いて、ADMINモードで実行されているサーバーの名前をクリックします。

3. 「制御」→「起動と停止」タブを選択します。

4. サーバーの名前を選択します。「再開」をクリックします。

5. 「はい」をクリックしてサーバーを再開します。

8.6.6.2 WebLogicノード・マネージャが起動しない場合

WebLogicノード・マネージャの起動に失敗する場合は、次のドメイン・ファイルをIDMHOST1からIDMHOST2にコピーしてあることを確認します。

WL_HOME/common/nodemanager/nodemanager.domains

8.6.6.3 Oracle HTTP Serverを使用したOracle Directory Services Managerのフェイルオーバーが透過的に行われない

Oracle HTTP Serverを使用してOracle Directory Services Managerのフェイルオーバーを実行する場合、このフェイルオーバーは透過的には行われません。次の手順を実行すると、この動作を確認できます。

1. Oracle HTTP Serverを使用して、Oracle Directory Services Managerをアクティブ/アクティブの高可用性構成にデプロイします。

2. Oracle HTTP Serverの名前とポート番号を使用して、「Oracle Directory Services Manager」ページを開きます。

3. Oracle Internet DirectoryサーバーやOracle Virtual DirectoryサーバーなどのLDAPサーバーに接続します。

4. 現行のOracle Directory Services ManagerのOracle HTTP Serverホストとポートを使用して、LDAPサーバーで作業します。

5. Oracle WebLogic Server管理コンソールを使用して、一度に1つずつ管理対象サーバーを停止します。

6. 「Oracle Directory Services Manager」ページとポート、およびすでに確立されているOracle Internet DirectoryまたはOracle Virtual Directoryの接続に戻ります。この操作を行うと、「Oracle Directory Services Manager」ページへの接続を再確立する必要があることを示すメッセージが表示されます。

このような場合は、次の手順を実行する必要があります。

1. Webブラウザで、現在の「Oracle Directory Services Manager」ページを終了します。

2. 新たにWebブラウザ・ページを起動して、同じOracle Directory Services ManagerのOracle HTTP Serverの名前とポートを指定します。

3. 前述の手順で作業中を行っていたLDAPサーバー(Oracle Internet DirectoryまたはOracle Virtual Directory)への接続を再確立します。

8.6.6.4 Oracle Internet Directoryのフェイルオーバー時に、メッセージ「LDAPサーバーが停止しています。」がOracle Directory Services Managerに表示される

Oracle Directory Services Managerがロード・バランサを介してOracle Internet Directoryに接続される高可用性構成では、Oracle Internet Directoryのインスタンス間のフェイルオーバー時にOracle Directory Services Managerにメッセージ「LDAPサーバーが停止しています。」が表示されます。

Oracle Internet Directoryのフェイルオーバーが完了すると、この接続は数分以内に再確立されるため、再ログインすることなく作業を続行できます。

8.6.6.5 Oracle RACフェイルオーバー時のOracle Directory Services Managerの一時的な接続の消失

Oracle Directory Services Managerでは、Oracle RACのフェイルオーバー時にOracle RACデータベースを使用中のOracle Internet Directoryインスタンスとの接続が一時的に失われます。Oracle Directory Services Managerに、メッセージFailure accessing Oracle database (oracle errcode=errcode)が表示されることがあります(errcodeは、次のいずれかです。値: 3113、3114、1092、28、1041、または1012)。

Oracle RACのフェイルオーバーが完了すると、この接続は数分以内に再確立されるため、再ログインすることなく作業を続行できます。

8.6.7 Oracle Directory Services Managerの高可用性に関するその他の考慮事項

Oracle Directory Services Managerを使用して、Oracle Internet Directoryクラスタを管理する場合は、接続文字列にロード・バランサの仮想アドレスを使用します。ただし、Oracle Directory Services Managerを使用してOracle Virtual Directoryクラスタを管理する場合は、具体的なOracle Virtual Directoryインスタンスのホスト名とポートを指定する必要があります。

8.7 コロケート・アーキテクチャの高可用性

この項では、Oracle Internet Directory、Oracle Directory Integration Platform、Oracle Virtual Directory、およびOracle Directory Services Managerをコロケートの高可用性環境に設計し、デプロイする方法について説明します。これらのコンポーネントの概要は、このマニュアルの前の項に記載されています。

この項では、Oracle Internet Directory、Oracle Directory Integration Platform、Oracle Virtual Directory、およびOracle Directory Services Managerを高可用性構成にデプロイする場合のコロケート・アーキテクチャについて説明します。

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

- 第8.7.1項「コロケート・アーキテクチャの概要」

- 第8.7.2項「コロケート・アーキテクチャの高可用性デプロイメント」

- 第8.7.3項「コロケート・コンポーネントの高可用性の検証」

- 第8.7.4項「コロケート・コンポーネント・マネージャの高可用性のトラブルシューティング」

- 第8.7.5項「コロケート・コンポーネントの高可用性に関するその他の考慮事項」

8.7.1 コロケート・アーキテクチャの概要

この項で説明するコロケート・アーキテクチャにおける各コンポーネントのアーキテクチャの概要は、次の各項を参照してください。

- Oracle Internet Directory: 第8.3.1項「Oracle Internet Directoryコンポーネント・アーキテクチャ」

- Oracle Virtual Directory: 第8.4.1項「Oracle Virtual Directoryコンポーネント・アーキテクチャ」

- Oracle Directory Integration Platform: 第8.5.1項「Oracle Directory Integration Platformコンポーネント・アーキテクチャ」

- Oracle Directory Services Manager: 第8.6.1項「Oracle Directory Services Managerコンポーネント・アーキテクチャ」

図8-10では、Oracle Internet Directory、Oracle Directory Integration Platform、Oracle Virtual Directory、およびOracle Directory Services Managerが、単一ホストにコロケートされており、非高可用性アーキテクチャにデプロイされています。

図8-10 コロケート・コンポーネント・アーキテクチャ

「図8-10 コロケート・コンポーネント・アーキテクチャ」の説明

図8-10のコンポーネントはすべて、同一ホストにデプロイされていますが、それぞれ個別のOracleホームとOracleインスタンスを持ちます。Oracle Internet Directoryは、セキュリティ・メタデータ・リポジトリとして、スタンドアロンのOracle Databaseを使用します。

8.7.2 コロケート・アーキテクチャの高可用性デプロイメント

図8-11では、Oracle Internet Directory、Oracle Virtual Directory、Oracle Directory Integration Platform、およびOracle Directory Services Managerが、IDMHOST1とIDMHOST2にコロケートされており、高可用性アーキテクチャでデプロイされています。

図8-11 高可用性アーキテクチャにコロケートされたコンポーネント

「図8-11 高可用性アーキテクチャにコロケートされたコンポーネント」の説明

8.7.2.1 コロケート・アーキテクチャの前提条件

この項で説明するコロケート・アーキテクチャにおける各コンポーネントの前提条件については、次の各項を参照してください。

- Oracle Internet Directory: 第8.3.2.3項「Oracle Internet Directoryの前提条件」

- Oracle Virtual Directory: 第8.4.2.2項「Oracle Virtual Directoryの前提条件」

- Oracle Directory Integration Platform: 第8.5.2.3項「Oracle Directory Integration Platformの前提条件」

- Oracle Directory Services Manager: 第8.6.2.3項「Oracle Directory Services Managerの前提条件」

- Oracle Identity Federation: 第8.13.2.3項「Oracle Identity Federationの前提条件」

8.7.2.2 高可用性のためのコロケートされたコンポーネントの構成

この項では、IDMHOST1とIDMHOST2にOracle Internet Directory、Oracle Directory Integration Platform、Oracle Virtual Directory、およびOracle Directory Services Managerを高可用性アーキテクチャでインストールし、構成する手順を説明します。

注意:

コロケート環境では、Oracle Identity Managementの各コンポーネントを個別のOracleホームにインストールする必要があります。これらのコンポーネントは同じMW_HOMEを共有できます。

各コンポーネントで、1つ目のインスタンスのOracleホームの場所のディレクトリ・パスが、2つ目のインスタンスのOracleホームの場所のディレクトリ・パスと同じであることを確認します。

たとえば、OIDHOST1の1つ目のOracle Internet DirectoryインスタンスのOracleホームの場所のディレクトリ・パスが/u01/app/oracle/product/fmw/idmである場合は、OIDHOST2の2つ目のOracle Internet DirectoryインスタンスのOracleホームの場所のディレクトリ・パスも/u01/app/oracle/product/fmw/idmである必要があります。

1. データベースをインストールします。詳細は、第8.2.3項「データベース・リポジトリのインストールと構成」を参照してください。

2. RCUをインストールします。詳細は、第8.2.4項「リポジトリ作成ユーティリティ・ソフトウェアの取得」を参照してください。

3. データベースを構成します。詳細は、第8.2.5項「Oracle Fusion Middleware 11gメタデータのデータベースの構成」を参照してください。

4. RCUを実行して、Oracle Internet DirectoryとOracle Identity Federationに必要なスキーマをインストールします。詳細は、第8.3.2.3.2項「RCUを使用したリポジトリへのOracle Internet Directoryスキーマの作成」と第8.13.2.3.1項「RCUを使用したリポジトリへのOracle Identity Federationスキーマの作成」を参照してください。

5. 1つ目のホストで、Oracle Internet Directoryのインストールと構成を行います。詳細は、第8.3.3.2.1項「OIDHOST1でのOracle Internet Directoryの構成」または第8.3.3.3.1項「OIDHOST1でのOracle Internet Directoryの構成」を参照してください。

6. 2つ目のホストで、Oracle Internet Directoryのインストールと構成を行います。詳細は、第8.3.3.2.3項「OIDHOST2でのOracle Internet Directoryの構成」または第8.3.3.3.3項「OIDHOST2でのOracle Internet Directoryの構成」を参照してください。

7. 1つ目のホストでOracle Virtual Directoryのインストールと構成を行います。詳細は、第8.4.3.1.1項「OVDHOST1でのOracle Virtual Directoryの構成」または第8.4.3.2.1項「OVDHOST1でのOracle Virtual Directoryの構成」を参照してください。

8. 2つ目のホストでOracle Virtual Directoryのインストールと構成を行います。詳細は、第8.4.3.1.2,項「OVDHOST2でのOracle Virtual Directoryの構成」または第8.4.3.2.3,項「OVDHOST2でのOracle Virtual Directoryの構成」を参照してください。

9. 1つ目のホストで、Oracle Directory Integration PlatformとOracle Directory Services Managerのインストールと構成を行います。詳細は、第8.5.3.1項「IDMHOST1でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成」を参照してください。

10. 2つ目のホストで、Oracle Directory Integration PlatformとOracle Directory Services Managerのインストールと構成を行います。詳細は、第8.5.3.3項「IDMHOST2でのOracle Directory Integration PlatformとOracle Directory Services Managerの構成」を参照してください。

8.7.3 コロケート・コンポーネントの高可用性の検証

高可用性アーキテクチャにコロケートされたコンポーネントの検証、およびこれらのコンポーネントとOracle RACをフェイルオーバーする方法の詳細は、次の各項を参照してください。

8.7.3.1 検証テスト

高可用性アーキテクチャにコロケートされた次のコンポーネントの検証については、次の各項を参照してください。

- Oracle Internet Directory: 第8.3.4項「Oracle Internet Directoryの高可用性の検証」

- Oracle Virtual Directory: 第8.4.4項「Oracle Virtual Directoryの高可用性の検証」

- Oracle Directory Integration Platform: 第8.6.4項「Oracle Directory Services Managerの高可用性の検証」

- Oracle Directory Services Manager: 第8.6.4項「Oracle Directory Services Managerの高可用性の検証」

- Oracle Identity Federation: 第8.13.3.6項「Oracle Identity Federationの高可用性の検証」

8.7.3.2 障害および予想される動作

高可用性アーキテクチャにコロケートされた次のコンポーネントの障害および予想される動作の詳細は、次の各項を参照してください。

- Oracle Internet Directory: 第8.3.5項「Oracle Internet Directoryのフェイルオーバーおよび予想される動作」

- Oracle Virtual Directory: 第8.4.5項「Oracle Virtual Directoryのフェイルオーバーおよび予想される動作」

- Oracle Directory Integration Platform: 第8.5.4項「Oracle Directory Integration Platformのフェイルオーバーおよび予想される動作」

- Oracle Directory Services Manager: 第8.6.5項「Oracle Directory Services Managerのフェイルオーバーおよび予想される動作」

- Oracle Identity Federation: 第8.13.4項「Oracle Identity Federationのフェイルオーバーおよび予想される動作」

8.7.4 コロケート・コンポーネント・マネージャの高可用性のトラブルシューティング

高可用性アーキテクチャにコロケートされた次のコンポーネントのトラブルシューティングについては、次の各項を参照してください。

- Oracle Internet Directory: 第8.3.6項「Oracle Internet Directoryの高可用性のトラブルシューティング」

- Oracle Virtual Directory: 第8.4.6項「Oracle Virtual Directoryの高可用性のトラブルシューティング」

- Oracle Directory Integration Platform: 第8.5.5項「Oracle Directory Integration Platformの高可用性のトラブルシューティング」

- Oracle Directory Services Manager: 第8.6.6項「Oracle Directory Services Managerのトラブルシューティング」

- Oracle Identity Federation: 第8.13.5項「Oracle Identity Federationの高可用性のトラブルシューティング」

8.7.5 コロケート・コンポーネントの高可用性に関するその他の考慮事項

高可用性アーキテクチャにコロケートされた次のコンポーネントのその他の考慮事項については、次の各項を参照してください。

- Oracle Internet Directory: 第8.3.7項「Oracle Internet Directoryの高可用性に関するその他の問題」

- Oracle Directory Services Manager: 第8.6.7項「Oracle Directory Services Managerの高可用性に関するその他の考慮事項」

8.8 Oracle Access Managerの高可用性

この項では、Oracle Access Manager 11gR1の概要、およびOracle Access Manager 11gR1の高可用性環境の設計およびデプロイ方法について説明します。

Oracle Access Manager 11gR1は、Oracle Access Manager 10g(アクセスのみ)とOracle Single Sign-On 10gの両方の後継製品です。Oracle Access Manager 11gR1によって、すべての認証および認可サービスの一元的な提供が可能になります。提供されるコア・サービスは、有効なセッション・トークンのチェック、セッション・トークンが無効であるか見つからない場合の資格証明の要求、セッション・トークンの発行、リソース・リクエストのインターセプト、およびリソースへのアクセスを制御するためのアクセス制御ポリシーの評価です。Oracle Access Manager 11gR1は、Pure Javaサーバーの機能を備えていますが、Oracle Single Sign-On 10gおよびOracle Access Manager 10gエージェント・コンポーネントも引き続き使用します。エージェントに関する11gR1の主な新しい機能は、WebGateごとの共有秘密鍵(SSKPWG)機能です。

Oracle Access Managerはシングル・サインオン機能を提供し、これにより、ユーザーは、一度認証された後に毎回再ログインせずに済みます。これは、ユーザー・セッションのライフ・サイクルを管理することによって実現します。これには、有効なユーザー・セッションにおけるすべてのリライイング・パーティにわたるログアウトをオーケストレートすることでグローバル・ログアウトを容易にすることも含まれます。また、Oracle Access Managerによって、ユーザーによるリソース・アクセスが指定済認可ポリシーに従って認可されるようになります。

Oracle Access Manager 10gとは異なり、Oracle Access Manager 11gR1にはアイデンティティ・サービスは備わっておらず、ネイティブLDAPやOracle Identity Managerなどの他のアイデンティティ管理サービスからのアイデンティティ情報が使用されます。

Oracle Access Manager 11gR1は、アクセス管理領域におけるアーキテクチャの進化であり、エンタープライズおよびWebシングル・サインオンのための統合された製品アーキテクチャを提供します。Oracle Access Managerのコンポーネントは、相互運用性とシームレスな統合に重点を置いており、一般的な基盤データ・モデル、共有基盤機能、一貫したセマンティックを持つJava EEミドルウェア・プラットフォームを活用します。Oracle Access Manager 11gR1は、既存のシングル・サインオン・デプロイメントに対して共存および増分移行することができます。

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

- 第8.8.1項「Oracle Access Managerコンポーネント・アーキテクチャ」

- 第8.8.2項「Oracle Access Managerの高可用性の概要」

- 第8.8.3項「Oracleセキュリティ・トークン・サービスの高可用性アーキテクチャ」

- 第8.8.4項「Oracle Access Managerの高可用性の構成手順」

8.8.1 Oracle Access Managerコンポーネント・アーキテクチャ

図8-12は、Oracle Access Manager 11gR1コンポーネントのアーキテクチャを示しています。

図8-12 Oracle Access Managerの単一インスタンス・アーキテクチャ

「図8-12 Oracle Access Managerの単一インスタンス・アーキテクチャ」の説明

図8-12は、次のコンポーネントを示しています。

- ユーザー・エージェント: これらには、Webブラウザ、Javaアプリケーション、およびWebサービス・アプリケーションが含まれます。ユーザー・エージェントは、HTTPを使用してアクセス・サーバーと管理および構成ツールにアクセスします。

- 保護されたリソース: 保護されたリソースとは、それへのアクセスが制限されたアプリケーションまたはWebページのことです。保護されたリソースへのアクセスは、WebGateまたはカスタム・エージェントによって制御されます。

- 管理および構成ツール: Oracle Access Managerは、Oracle Access Managerコンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Enterprise Manager Grid ControlおよびWebLogic Scripting Tool(WLST)を使用して管理および構成できます。

- アクセス・サーバー: アクセス・サーバーには、資格証明コレクタ、OSSOプロキシおよびOAMプロキシ・コンポーネントが含まれます。Coherence分散オブジェクト・キャッシュは、アクセス・サーバー間で構成ファイルの変更を伝播するために使用されます。

8.8.1.1 Oracle Access Managerコンポーネントの特性

Oracle Access Manager 11gR1デプロイメントは、次のシステム・エンティティで構成されます。

- Oracle Access Managerエージェント: Oracle Access Managerエージェントは、アクセス・サーバーの拡張機能であり、アクセス・サーバーで管理されているポリシーのとおりにアクセスが制御されるようにする役割を担います。エージェントは、Oracle Access Manager 11gR1によって保護される様々なWebリソースにアクセスするためにエンドユーザーによって使用されるクライアントおよびプログラム(WebGate、Javaエージェント、カスタム・エージェント、Oracle Single Sign-On Apacheモジュールなど)です。最もよく使用されるユーザー・エージェントはWebブラウザです。Oracle Access Manager 11gは、主に、HTTPを介してアクセス可能なリソース(URLによって識別されるリソース)およびカスタム・リソース・タイプの制御に焦点を当てたWebシングル・サインオン・ソリューションです。
エージェントがその機能を実行するには、アクセス・サーバー・コンポーネントが必要です。アクセス・サーバーが使用不可である場合、保護されるサーバーへのアクセスは許可されません(ユーザーはシステムからロックアウトされます)。

Oracle Access Manager 11gR1エージェントは、フロント・チャネルとバック・チャネルを介してアクセス・サーバーに接続します。ユーザーが認証を必要とする場合、フロント・チャネル通信はHTTP(S)を介して行われます。フロント・チャネル通信の存続時間は短い傾向があります。

Oracle Access Managerエージェントがフロント・チャネルHTTPバインディングを使用してアクセス・サーバーと通信する場合は、ロード・バランシング・ルーターを介して通信する必要があります。この情報は、エージェントに渡され、認証スキームでチャレンジ・リダイレクトURLとして構成されます。

バック・チャネル通信は、TCP接続を介して行われるOracle Access Protocol(OAP)と呼ばれる専用プロトコルを使用して行われます。エージェントは、認可の決定を行うためにすべてのリソース・アクセス・リクエストに対してアクセス・サーバーとのバック・チャネル通信を使用します。したがって、これらのバック・チャネル接続は永続的であり、存続時間が長くなります。

Oracle Access Managerエージェントがバック・チャネルOAPバインディングを使用してアクセス・サーバーと通信する場合は、プライマリ/セカンダリ・モデルを使用するように構成されています。

Oracle Access Managerエージェントは、外部ステージング(Web層にデプロイ)されます。それはこれが最良のスケーラビリティを提供するためです。

WebGateは、リソース・リクエストおよび認証スキームに関する情報をキャッシュします。WebGateキャッシュは、構成済タイムアウトまたはサーバーによって開始されるキャッシュ・パージに基づいてフラッシュされます。

WebGateは、60秒ごとにサーバーをポーリングすることで構成をリフレッシュします。構成の変更が検出された時点で、その変更内容が永続化されます。接続情報が変更された場合は、既存の接続を終了してから、新しい接続が作成されます。

WebGateの構成には、エージェントのアイデンティティに関する情報、エージェント資格証明、エージェント・サーバー・セキュリティ・コンテキストおよび接続パラメータが含まれます。

- 保護されたリソース: これらは、Oracle Access Manager11gR1によって保護されたアプリケーションです(パートナ・アプリケーションとも呼ばれます)。これらのリソースへのアクセスは、Oracle Access Manager 11gR1のアクセス制御ポリシーに従って行われ、保護されたリソースのアクセス・パスにデプロイされたOracle Access Managerエージェント(WebサーバーにデプロイされたOracle Access Managerエージェント、アプリケーション・サーバーにデプロイされたJ2EEエージェントなど)によって制御されます。エージェントは、保護されたアプリケーションへのアクセスをセキュリティ・ポリシーに基づいて制御するエンティティです。リソース・アクセス・パスに配置されたエージェントは、すべてのリソース・アクセス・リクエストをインターセプトし、リソースを保護するセキュリティ・ポリシーを適用します。

- アクセス・サーバー: コア・ランタイム・アクセス管理サービスを提供するサーバー・サイド・コンポーネントです。これは、コアOracle Access Managerサービスを実現するイベントベースの設計パターンを使用しています。アクセス・サーバーは、EARファイルとしてパッケージ化されたJ2EEアプリケーションであり、Javaクラスに加えてサーブレットとJSPで構成されています。これは、様々なアイデンティティ・プロバイダ(IDP)サービスを提供します。Oracle Access Manager 11gR1のアクセス・サーバーは、シングル・サインオン、認証、および認可サービスを提供します。

- JMX Mbean: ランタイムMBeanは、アクセス・サーバー・パッケージの一部としてパッケージ化されています。構成Mbeanは、スタンドアロンWARファイルとしてパッケージ化されています。

- WebLogic 11g SSPIプロバイダは、Access Java Access JDKとともにSSPIインタフェースを実現するJavaクラスで構成されています。AccessGateは、Pure Java Access JDKを使用して構築されています。

- 管理コンソール: Oracle Access Manager管理コンソールは、管理コンソールをホストするJ2EEアプリケーションであり、Oracle Access Manager 11gR1デプロイメントを管理するための管理や構成などのサービスを提供します。Oracle Access Manager 11gR1では、このコンポーネントはWebLogic Administration Serverにデプロイする必要があります。

- WebLogic Scripting Tool(WLST)は、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。Oracle Access Manager 11gR1デプロイメントの管理の一部は、コマンドラインからサポートされます。

- Fusion Middleware ControlおよびEnterprise Manager Grid Control: Oracle Access Manager 11gR1は、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。

- Coherence分散オブジェクト・キャッシュ: Oracle Access Manager 11gR1コンポーネントは、このインフラストラクチャに依存して、変更をリアルタイムに伝播します。

- 外部資格証明コレクタは、一連のJSPです。

- Oracle Access Manager Proxyは、Apache MINAサーバーのカスタマイズ・バージョン(JCAアーキテクチャに基づく)であり、Javaサーバー・クラスに加えてMessageDrivenBeanおよびResourceAdapterが含まれています。これは、アクセス・サーバー・パッケージに含まれています。

- Oracle Single Sign-On(OSSO)プロキシは、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。

- データ・リポジトリ: Oracle Access Manager 11gR1は、次のようなアイデンティティ、ポリシー、パートナ、セッション、一時データを含む様々なタイプの情報を処理します。

- アイデンティティ・データ用LDAP

- 構成およびパートナ・データ用ファイル

- セッションおよび一時データ用Coherenceインメモリー

- ポリシー・データはファイルまたはRDBMSに格納されます

- Oracle Access Manager 10g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。

- Oracle Single Sign-On Apacheモジュールは、Oracle HTTP Server Webサーバーにデプロイすることを意図したCベースのエージェントです。

- Oracle Access Manager 11g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。

8.8.1.1.1 Oracle Access Managerの状態情報

認証ユーザー・セッション情報は、Coherence分散オブジェクト・キャッシュを介して永続化されます。Oracle Access Manager 11gR1に対しては、Coherence分散オブジェクト・キャッシュ・インメモリー・モードを使用します。

Oracle Access Managerによって、ログイン処理中に、認証されていないユーザーに対して一時状態が作成されることがあります。この状態は、通常、Oracle Access Managerノード間でレプリケートされません。ログイン処理中のノードの障害の影響を防止するために、オプションでその状態を暗号化されたクライアントCookieに格納することができます。

認証されていないユーザーの一時状態をログイン処理中に格納するには、次の手順に従ってOracle Access Managerサーバー・パラメータRequestCacheTypeをBASICからCOOKIEに変更します。

1. 次のコマンドを実行して、WLSTの環境を設定します。

DOMAIN_HOME/bin/setDomainEnv.sh

2. 次のコマンドを発行して、WLSTを起動します。

Start WLST by issuing this command:
ORACLE_HOME/common/bin/wlst.sh

3. ドメインに接続します。

wls:/IDM_Domain/serverConfig> connect()

4. WebLogic管理ユーザー名とパスワードを入力し、管理サーバーのURLを次の形式で入力します。

t3://OAMHOST1.mycompany.com:7001

5. 次のコマンドを発行します。

wls:/IDM_Domain/serverConfig> configRequestCacheType(type="COOKIE")

6. 次のコマンドを発行して、コマンドが動作したことを確認します。

wls:/IDM_Domain/serverConfig> displayRequestCacheType()

7. Oracle Access Manager管理対象サーバーを再起動します。

8.8.1.1.2 Oracle Access Managerのリクエスト・フロー

次に、Oracle Access Managerのリクエスト・フローを示します。

1. ユーザーが、Oracle Access Manager 11gR1によって保護されたWebリソースに、自身のWebブラウザを使用してアクセスしようとします。

2. Oracle Access Managerエージェント脚注1 によって、そのリクエストはインターセプトされ、ユーザーが認証済セッションを持っているかどうかの確認が試みられます。

3. これは、ユーザーの最初のアクセスであるため、ユーザーは認証のためにOracle Access Manager 11gR1アクセス・サーバーにリダイレクトされます。

4. アクセス・サーバーの資格証明コレクタ脚注2 ・コンポーネントによってログイン・フォームが表示されます。脚注3 ユーザーは、自身の資格証明をアクセス・サーバーに送信します。

5. アクセス・サーバーによって、ユーザーの資格証明が検証され、セキュリティ・トークンが生成されます。ユーザーは、ステップ1でアクセスを試みたリソースにリダイレクトされます。

6. Oracle Access Managerエージェントによってリクエストがインターセプトされ、セキュリティ・トークン(Cookie)が抽出されます。

7. 次に、Oracle Access Managerエージェントによってアクセス・サーバーにバック・チャネル呼出し脚注4 (TCPを介したOAP)が行われ、セッションが検証され、リクエストが認可されます。

8. Oracle Access Managerによって、LDAPリポジトリを利用してユーザーが認証されます。

9. アクセス・サーバーによって、そのWebリソースの構成済ポリシーに対してユーザーの権限が検証されます。

10. アクセス・サーバーは、WebGateリクエストに応答し、そのアクセスが許可されることを示します。

11. Oracle Access Managerエージェントによってリクエストの転送が許可されます。脚注5

12. ユーザーは、ステップ1でアクセスを試みたWebリソースにアクセスできるようになります。

8.8.1.1.3 Oracle Access Managerプロセスのライフサイクル

アクセス・サーバーと管理コンソールは、WebLogic Serverの提供するユーザー・インタフェースおよびコマンドライン・ツールから起動できます。

アクセス・サーバーは、障害の検出のためにロード・バランサで使用できるヘルス・チェック・リクエスト(HTTPを介したpingリクエスト)をサポートしています。

Oracle Access Managerエージェントは、保護されたアプリケーション環境に常駐するネイティブ・アプリケーションです。OAM 11gR1の一部として提供されているツールはありませんが、環境固有のツールが使用可能な場合は、それが前述の目的で使用されます。

Oracle Access Manager 11gR1は、サーバー・サイド・メトリック用(DMSを使用)にインスツルメント処理されており、この情報は管理コンソールに公開されます。コンポーネントの監視のかわりとして、DMSメトリック収集を使用してエージェントおよびサーバー・コンポーネント・メトリックを監視できます。さらに、Oracle Access Manager 11gR1は、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。

アクセス・サーバーは、起動時にバックエンド・リポジトリへの接続を初期化します。リポジトリに到達不能な場合、アクセス・サーバーはリポジトリへの接続を再試行します。この接続の再試行には指数関数的に増加するタイムアウトが使用されます。タイムアウトの上限は構成可能です。

アクセス・サーバーは、バックエンド接続が停止した場合はローカルにキャッシュしたデータに基づいてサービスの継続性を提供します。これは、キャッシュが失効するか、バックエンド接続が復活するまで継続されます。

8.8.1.1.4 Oracle Access Managerの構成アーティファクト

Oracle Access Managerの構成アーティファクトには、次のファイルが含まれています。

- DOMAIN_HOME/config/fmwconfig/oam-configuration.xml
構成ファイル。インスタンス固有の情報が含まれています。

- DOMAIN_HOME/config/fmwconfig/oam-policy.xml

- DOMAIN_HOME/config/fmwconfig/.oamkeystore
これは、対称鍵および非対称鍵の格納に使用されます。

- DOMAIN_HOME/config/fmwconfig/component_events.xml
監査定義に使用されます。

- DOMAIN_HOME/config/fmwconfig/jazn-data.xml
管理コンソールの権限に使用されます。

- DOMAIN_HOME/config/fmwconfig/servers/インスタンス名/logging.xml
ロギング構成に使用されます。

- DOMAIN_HOME/config/fmwconfig/servers/インスタンス名/dms_config.xml
トレース・ロギングに使用されます。

- DOMAIN_HOME/config/fmwconfig/cwallet.sso
パスワードに使用されます。

8.8.1.1.5 Oracle Access Managerの外部依存性

Oracle Access Managerは、次のものに対して外部ランタイム依存性があります。

- LDAPベースのアイデンティティ・ストア

- ユーザー・アイデンティティ・リポジトリ

- ユーザー/ロールAPIによって抽象化されるLDAPアクセス

注意:

Oracle Access Managerは、常に1つのアイデンティティ・ストアに接続します。そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Oracle Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。

- OCSPレスポンダ・サービス

- リアルタイムX.509認証検証

- RDBMSポリシー・ストア

- ポリシー(認証および認可)リポジトリ

- OAMポリシー・エンジンによって抽象化されるRDBMSアクセス

- Oracle Identity Manager(OIMベースのパスワード管理が有効化されている場合)

- Oracle Identity Managerは、パスワード管理サービスを提供するために使用され、Oracle Access Manager 10g Identity Serverのかわりとなります。

- Oracle Identity Managerポリシー・ストア(Oracle Identity Managerベースのパスワード管理が有効化されている場合)

- 構成、メタデータなどを格納するために使用されるOblixスキーマ要素を含むLDAPリポジトリ

- Oracle Adaptive Access Manager(Oracle Adaptive Access Managerの拡張認証スキームが選択されている場合)

- Oracle Identity Federation(Oracle Identity Federationの認証スキームが選択されている場合)

8.8.1.1.6 Oracle Access Managerのログ・ファイルの場所

Oracle Access Managerは、WebLogic Server上にデプロイされるJ2EEアプリケーションです。すべてのログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

8.8.2 Oracle Access Managerの高可用性の概要

この項では、Oracle Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。

8.8.2.1 Oracle Access Managerの高可用性アーキテクチャ

図8-13は、Oracle Access Managerの高可用性アーキテクチャを示しています。

図8-13 Oracle Access Managerの高可用性アーキテクチャ

「図8-13 Oracle Access Managerの高可用性アーキテクチャ」の説明

図8-13では、着信認証リクエストは、ハードウェア・ロード・バランサによって受信されてからWeb層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohsが使用されてWebLogic管理対象サーバーにリクエストが転送されます。

ロード・バランシング・ルーターは、HTTPトラフィックに対してのみセッション・スティックネスを使用する必要があります。OAPトラフィックは、ロード・バランシング・ルーターを使用しません。そのため、OAPトラフィックに対してはセッション・スティックネスは必要ありません。

他のOracle HTTP Serverからアクセスされ、アクセスが制限されているリソースを持つアプリケーションには、WebGate、Oracle Single Sign-On Serverエージェント(mod_ossoエージェント)、またはカスタム・エージェントを構成する必要があります。WEBHOST3上のWebGateは、OAPを使用してアプリケーション層のOAMHOST1およびOAMHOST2上のアクセス・サーバーと通信します。WEBHOST3は、アプリケーションWebサーバーであり、認証のためにHTTPリダイレクトを使用して、リクエストをロード・バランサへ、そしてWEBHOST1およびWEBHOST2にルーティングします。高可用性デプロイメントにするために、オプションでWEBHOST3と同じコンポーネントを持つホストをもう1つ(たとえばWEBHOST4)を構成できます。

OAMHOST1およびOAMHOST2は、Oracle Access Serverアプリケーションをホストする管理対象サーバーをデプロイします。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。

Oracle WebLogic管理サーバーは、OAMHOST1上で実行され、WebLogic管理コンソールとOracle Enterprise Manager Fusion Middleware Control、およびOracle Access Managerコンソールをデプロイします。管理サーバーは、OAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAMHOST1が使用不可になった場合に、管理サーバーをOAMHOST2上で手動で起動できます。

ディレクトリ層で、仮想IP ovd.mycompany.comは、Oracle Virtual DirectoryリクエストをOVDHOST1とOVDHOST2にルーティングするように設定されます。OVDHOST1とOVDHOST2は、アクティブ/アクティブのOracle Virtual Directoryクラスタを構成します。仮想IP oid.mycompany.comは、Oracle Internet DirectoryリクエストをOIDHOST1とOIDHOST2にルーティングするように設定されます。OIDHOST1とOIDHOST2は、アクティブ/アクティブのOracle Internet Directoryクラスタを構成します。

Oracle RACデータベースは、データ層における高可用性を提供します。

Oracle Access Manager 11gR1では、WebLogic ServerドメインごとにサポートされるOracle Access Managerクラスタは1つのみです。さらに、Oracle Access Managerクラスタは、複数のWebLogic Serverドメインにわたることはできません。

単一インスタンスのOracle Access Manager 11gR1デプロイメントは、次の高可用性要件を満たします。

- ロード処理

- 外部接続管理と監視

- リカバリ

- フォルト包含

- フォルト診断

- 管理サーバーのオフライン

複数インスタンスのOracle Access Manager 11gR1デプロイメントは、さらに次の高可用性要件を満たします。

- 冗長性

- クライアント接続のフェイルオーバー/継続性

- クライアントのロード・バランシング

- 状態管理

インバウンドHTTP接続の場合は、外部ロード・バランシング・ルーターの使用をお薦めします。LDAPサーバー(またはOAMポリシー・エンジンPDP/PIP)へのアウトバウンド外部接続はロード・バランシングされ、接続フェイルオーバーに対してもサポートされます。Oracle Access Managerエージェントは、複数のアクセス・サーバーにわたる接続をロード・バランシングできます。

Oracle Access Managerエージェントは、アクセス・サーバーへの永続TCP接続を開きます。これには、TCP接続の早すぎる終了を回避するためにファイアウォール接続タイムアウトを十分大きい値にする必要があります。

アクセス・サーバーとOracle Access Manager管理コンソールは、ポリシー評価および管理のために、OAMポリシー・エンジンと連動します。OAMポリシー・エンジンは、ポリシー・リポジトリとしてのデータベースに内部依存します。データベースの相互作用はOAMポリシー・エンジン内にカプセル化され、Oracle Access Managerからは、その接続構成情報のみ管理できます。Oracle Access ManagerとOAMポリシー・エンジン間の相互作用の高可用性の特性は、次のとおりです。

- データベース接続情報は、Oracle Access Managerインスタンス間で同期されるOracle Access Manager構成ファイルで構成されます。データベース接続情報が実行時に変更された場合、アクセス・サーバー・インスタンスがOESを再初期化し、変更のアクティブ化を完了します。

- データベース通信はOAMポリシー・エンジン内で管理され、通常、Oracle Access ManagerとOAMポリシー・エンジンの相互作用からは分離されます。ただし、Oracle Access Managerサーバー・インスタンスの最初の起動は、データベースに到達不能な場合、失敗します。OAMポリシー・エンジンのブートストラップの障害はOracle Access Managerによって致命的として処理され、起動操作は中断されます。

- 一時的なデータベースの使用不能は、OAMポリシー・エンジン・ポリシー評価サービスによって透過的に許容され、Oracle Access Managerサーバー・ランタイムは中断されることなく継続的に機能します。最初のOAMポリシー・エンジンのブートストラップの後、データベースが到達不能でも、Oracle Access Managerインスタンスは再起動できます。OAMポリシー・エンジンはそのローカルにキャッシュされたポリシーに対して処理を継続します。

- Oracle Access Managerポリシー管理インタフェース(Oracle Access Manager管理コンソールおよびCLIツール内)は、OAMポリシー・エンジン管理サービス・インタフェースからみてデータベースが到達不能である場合に失敗します。操作は後で再試行できますが、管理操作に対して自動化された再試行は提供されていません。

- データベース・リポジトリでポリシーが変更されると、Oracle Access Managerサーバー・ランタイムのOAMポリシー・エンジン・レイヤーが、(Oracle Access Managerの構成で構成される)構成可能なOAMポリシー・エンジン・データベース・ポーリング間隔内でその変更を取得し、アクティブ化します。ポリシー変更の肯定応答を、各Oracle Access Managerサーバー・ランタイムから受信する必要があります。それ以外の場合は、そのポリシー変更はアクティブ化に成功したとみなされません。管理者は、Oracle Access Manager管理コンソールを使用して、サービスから、ポリシー・アクティブ化が失敗したOracle Access Managerインスタンスを削除できます。

8.8.2.1.1 クラスタの起動と停止

高可用性アーキテクチャでは、Oracle Access Managerサーバーは、Oracle WebLogicクラスタにデプロイされます。このクラスタには、その一部として少なくとも2つのサーバーが存在します。

デフォルトでは、Oracle WebLogic Serverによって、このアプリケーションの起動、停止、監視および様々なライフサイクル・イベントの監視が行われます。Oracle Access Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

高可用性環境では、WebLogicノード・マネージャはOracle WebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。

高可用性環境では、ハードウェア・ロード・バランサを使用して、複数のOracle Access Managerインスタンス間のリクエストをロード・バランシングします。Oracle Access Managerインスタンスのいずれかに障害が発生した場合は、ロード・バランサによって障害が検出され、障害が発生していないインスタンスにリクエストがルーティングされます。

8.8.2.1.2 クラスタワイドの構成変更

Oracle Access Managerが使用する標準Java EEアーティファクトは、Oracle Access ManagerがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Oracle Access Managerコンポーネントで使用されるライブラリを同期します。

さらに、Oracle Access Managerのアプリケーション・レベルの構成は、Oracle Access Managerリポジトリに格納されます。すべてのクラスタ・メンバーへのOracle Access Managerの構成変更の伝播は、Coherence分散オブジェクト・キャッシュを活用する配布メカニズムに基づきます。すべてのOracle Access Managerコンポーネントは、変更イベントをCoherenceレイヤーから通知されて取得します。変更の原子性を確保するために、Oracle Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。

Oracle Access Managerの構成は、クラスタ内のすべてのインスタンスに適用されます。Oracle Access Manager 11gでサポートされる前述の構成(インスタンス固有の構成)の例外は、Oracle Access Managerプロキシ・ホスト、Oracle Access Managerプロキシ・ポート、およびインスタンス固有のCoherence構成(Well Knownアドレス(WKA)が使用されている場合)のみです。プロキシ・ホストのIPアドレスおよびプロキシ・ポートは、構成ファイルに格納されます。Oracle Access Managerプロキシ・ポートは、エージェントからのOAPリクエストのエンドポイントです。Coherence WKAのIPアドレスも、構成ファイルに格納されます。Coherence WKAは、Oracle Access Manager固有のトラフィックを受信する権限を付与されたCoherenceノードを判別するために使用されます。oam-configuration.xmlファイルは、この構成情報を格納する構成ファイルです。

Oracle Access Managerプロキシのクライアントが、この仮想IP(論理IP)を使用してサービスにアクセスするように構成できます。

Oracle Access Managerプロキシは、論理IPおよびコンポーネント・インスタンスが、同様に構成された他の物理的に異なるマシンに移行されている場合に、デプロイできます(そして、そのクライアントは依然としてサービスにアクセスできます)。

アクセス・サーバー・インスタンスの追加および削除は、クラスタ内の他のOracle Access Manager Access Serverインスタンスに対して透過的です。ただし、特定のアクセス・サーバーの削除が、エージェントのロード・バランシングとフェイルオーバーの特性に影響を与えないように注意してください。

Oracle Access Manager Access Serverを再起動しても、クラスタ内の他の実行中のコンポーネントやメンバーには影響ありません。

オンライン・アプリケーション・デプロイメントによって問題が発生することはありません。

8.8.2.2 障害からの保護および予想される動作

この項では、Oracle Identity Managementの高可用性クラスタのデプロイメントでコンポーネントがどのようにして障害から保護されるかを説明します。この項では、コンポーネントの障害が発生した場合の予想される動作についても説明します。

WebLogic Serverインフラストラクチャにより、Identity Managementサービス・インフラストラクチャ・システムは、あらゆるプロセス障害から保護されます。

また、次の機能もOracle Access Managerの高可用性構成を障害から保護します。

- セッションの状態は、Coherence分散オブジェクト・キャッシュで保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。Coherenceはインメモリー・モードで使用されるため、この情報は、すべてのOracle Access Managerコンポーネントが同時に再起動された場合は保持されません。

- アクセス・サーバーで障害が発生した場合、そのサーバーへの永続接続を持つWebGateは、接続がタイムアウトするまで待機し、その後にセカンダリ(バックアップ)アクセス・サーバーに切り替えます。未処理のリクエストは、セカンダリ・サーバーにフェイルオーバーされます。

- Oracle Access Manager Access Serverは、ハート・ビート・チェック(HTTPを介したpingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視し、アプリケーションが実行されていない場合は再起動することができます。

- WebLogic Serverノードで障害が発生した場合、外部接続のフェイルオーバーは、構成、再試行のタイムアウトおよび再試行回数に基づいて行われます。Oracle Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。

- ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、それはセッション状態をCoherence分散オブジェクト・キャッシュから取得し、処理を実行します。

- バック・チャネルOAPバインディングでは、フェイルオーバーのためにプライマリ/セカンダリ・モデルが使用されます。フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。

- 接続の存続時間が期限切れした場合、保留中のリクエストは接続が終了する前に完了できます。接続オブジェクトは、プールに返されます。

- 別のサービスから例外を受信した場合、Oracle Access Managerは、外部接続リクエストを再試行します。再試行の回数は構成可能であり、no retriesに設定することもできます。

8.8.2.2.1 WebLogic Serverのクラッシュ

ユーザーが保護されたリソースへのアクセスを最初に要求したときに、Oracle HTTP ServerによってOracle Access Serverとの接続が確立され、最初のユーザー認証の後、Oracle Access Managerエージェント(たとえば、WebGate)によって、2つのアクセス・サーバーに対してブラウザCookieにエントリが配置されます。この時点から、クライアント・アプリケーションは、Cookieで識別されるアクセス・サーバーの1つと直接通信します。そのアクセス・サーバーが使用不可になった場合、アプリケーションは、Cookieで識別される代替アクセス・サーバーと通信します。両方のサーバーが使用不可になった場合は、ユーザーの再認証が必要になります。

WLS_OAMxサーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。

HTTP Serverからの処理中のリクエストはタイムアウトして、新しいリクエストは他のWLS_OAMxサーバーに送られます。障害が発生したノードでサーバーが正常に再起動されると、Oracle HTTP Serverは、受信したリクエストのサーバーへのルーティングを再開します。

注意:

Oracle Access Managerサーバーは、ハートビート・チェックもサポートしています。このハートビートによって、アクセス・サーバーがリクエストを処理できるかどうかを判別します。これにより、次のようなものがチェックされます。

- LDAPストアにアクセスできるかどうか。

- ポリシー・ストアにアクセスできるかどうか。

ハートビート・チェックに成功した場合、アクセス・サーバーはリクエストに対してサービス提供可能であり、リクエストがそれに送信されます。ハードビット・チェックに失敗した場合、リクエストは、問題のあるアクセス・サーバーにルーティングされることはありません。

8.8.2.2.2 ノード障害

ノード障害は、WebLogic Serverの障害と同じ方法で処理されます。

8.8.2.2.3 データベース障害

Oracle Access Managerサービス・インフラストラクチャは、マルチ・データ・ソースの使用によりデータベースの障害から保護されます。通常、これらのマルチ・データ・ソースは、システムの初期設定時に構成されます(Oracle Fusion Middleware構成ウィザードで、インストール時にこれらのマルチプールを直接定義できます)。これらのソースによって、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。

Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

8.8.3 Oracle Security Token Serviceの高可用性

この項では、Oracle Security Token Service(OSTS)の高可用性について説明します。

Oracle Security Token Serviceは、共有Webサービス(JAX-WS)であり、様々なIdentityドメインとインフラストラクチャ層との間での信頼を仲介する機能が統合された標準ベースのメカニズムを提供します。Oracle Security Token Serviceは、Webサービス・コンシューマ(WSC)とWebサービス・プロバイダ(WSP)との間での信頼を仲介し、プロバイダとコンシューマに対してセキュリティ・トークンのライフサイクル管理サービスを提供します。Oracle Security Token Serviceでは、標準化されたインタフェースのセットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。

Oracle Security Token Serviceの高可用性デプロイメントは、OAMに依存します。Oracle Access Manager(OAM)アプリケーションには、Oracle Security Token Serviceのサーバー・ランタイムが含まれています。Oracle Security Token Serviceの高可用性デプロイメントは、OAMがなければ成り立ちません。Oracle Access ManagerとOracle Security Token Serviceは、どちらもOAM J2EEアプリケーションEARファイルに同梱されていて、WebLogicドメイン内の同じ管理対象サーバーに両方ともにインストールされデプロイされます。さらに、Oracle Security Token Serviceは、Oracle Access Managerコンソールに統合されます。

Oracle Security Token Serviceの管理と構成の詳細は、Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイドを参照してください。

- Oracle Security Token Serviceの主な用語と概要

- Oracle Access Managerを使用するOracle Security Token Serviceについて

- Oracle Security Token Serviceのデプロイメントについて

- Oracle Security Token Serviceの管理について

- Oracle Security Token Serviceの実装シナリオ

- Oracle Security Token Serviceの設定値と設定の管理

- Oracle Security Token Serviceの証明書と鍵の管理

- テンプレート、エンドポイントおよびポリシーの管理

- Token Serviceパートナとパートナ・プロファイルの管理

パッチの適用については、Oracle Access Managerの管理の第11.1.1.3.0項から第11.1.1.6.0項を参照してください。

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

- 第8.8.3.1項「Oracle Security Token Serviceの高可用性アーキテクチャ」

- 第8.8.3.2項「Oracle Security Token Serviceコンポーネントの特性」

- 第8.8.3.3項「Oracle Security Token Serviceの高可用性の構成手順」

- 第8.8.3.4項「Oracle Security Token Serviceの高可用性の検証」

- 第8.8.3.5項「Oracle Security Token Serviceの障害と予想される動作」

- 第8.8.3.6項「Oracle Security Token Serviceの無効化および有効化」

- 第8.8.3.7項「Oracle Security Token Serviceのトラブルシューティング」

- 第8.8.3.8項「ログ・ファイルの場所」

8.8.3.1 Oracle Security Token Serviceの高可用性アーキテクチャ

次の図は、高可用性アーキテクチャのOracle Security Token Serviceを示しています。

図8-14 Oracle Security Token Serviceの高可用性アーキテクチャ

「図8-14 Oracle Security Token Serviceの高可用性アーキテクチャ」の説明

この図は、Oracle Access Manager/Oracle Security Token Serviceコンポーネントの2ノード・デプロイメントを示しています。この項では、Oracle Security Token Serviceの高可用性デプロイメントについて詳しく説明します。これの一部としてデプロイされるOracle Access Managerの全体的な高可用性アーキテクチャについては、第8.8.2.1項「Oracle Access Managerの高可用性アーキテクチャ」を参照してください。

Security Token Serviceは、WS-Trustプロトコルのサポートを実装するサーバー側コンポーネントです。

ロード・バランサはトークン・リクエストを受信すると、そのリクエストをSecurity Token Service(STS)にルーティングします。

Oracle Access Manager管理コンソールは、Oracle Security Token Serviceデプロイメントを管理するためのサービスを提供するJ2EEアプリケーションです。OAMデプロイメントの一部として、管理コンソールをWeblogic管理サーバーにデプロイする必要があります。

Oracle Security Token Serviceの場合、各WLSドメインで1つのOracle Security Token Serviceクラスタをサポートします。OAM/Oracle Security Token Serviceクラスタは、WebLogic Serverドメイン間にまたがることはできません。

Oracle Security Token Serviceは、主にOASIS WS-Trustプロトコルを基盤とします。ただし、Oracle Security Token Serviceは、SOAPメッセージに含まれるその他のWS-*プロトコルの処理を、JAX-WSスタックに委任します。

HTTP/SOAPのインバウンド接続には、外部ロード・バランサを使用することをお薦めします。LDAPに対するアウトバウンド外部接続は、接続フェイルオーバーのサポートとともにロード・バランシングされます。

8.8.3.1.1 クライアントとクライアント接続

WS-Trustプロトコルを実装するWebサービス・クライアントは、トークンの発行および検証のために、Oracle Security Token Serviceと対話します。STSサーバーと対話するように設計されたクライアント(OWSMクライアントなど)は、リライイング・パーティへのWebサービス・コールの一環として、Oracle Security Token Serviceを呼び出すことができます。

このクライアント接続は、次のように処理されます。

1. Webサービス・クライアントは、httpまたはhttpsによってSOAPメッセージを送信します。
WSSプロトコルによって、メッセージを保護します。ペイロードには、実行する操作、発行または検証するトークンの種類、およびトークンの特性についての追加情報を示すWS-Trustリクエスト(RST)が格納されます。

2. サーバーはリクエストを処理して、そのリクエストをサーバーが受信したチャネルと同じチャネルでレスポンスを送信します。
WSSプロトコルによって、メッセージを保護します。処理が成功したときには、ペイロードにWS-Trustレスポンス(RSTRC)が格納されます。エラーが発生したときには、SOAP障害が格納されます。

8.8.3.1.2 クラスタワイドの構成変更

Oracle Security Token Serviceアクセス・サーバーの各インスタンスは、他のインスタンスのピアになりますがインスタンス間の通信はありません。サーバーがリクエストを受信できるようになる前に、すべての初期化が組込のスロット機能と同時に行われるため、WebLogic ServerはOracle Security Token Serviceアクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく急増する条件を適切に処理します。

クラスタが停止すると、Oracle Security Token Serviceは新しいリクエストを拒否し、アクセス・サーバーのアプリケーションが停止する前に既存のリクエストを完了できるようにします。強制停止が行われた場合、Oracle Security Token Serviceはその強制停止によって破損または無効になったデータをリカバリできます。

構成の変更は、Coherence分散オブジェクト・キャッシュを利用する分散メカニズムに基づいて、すべてのクラスタ・メンバー伝播されます。Coherenceレイヤーは、すべてのOracle Security Token Serviceコンポーネントに変更イベントを通知します。その後、このコンポーネントはそれらの変更を取り込みます。OAMコンポーネントは、そのコンポーネントの構成全体を変更が行われる度にリロードします。

注意:

アクセス・サーバーのインスタンスの追加または削除は、クラスタ内の他のOracle Security Token Serviceインスタンスに対して透過的になります。特定のOracle Security Token Serviceサーバーの削除が、ロードに影響しないことを確認してください。

8.8.3.2 Oracle Security Token Serviceコンポーネントの特性

この項では、Oracle Security Token Serviceコンポーネントの特性と、次の項目について説明します。

- 第8.8.3.2.1項「Oracle Security Token Serviceコンポーネントのライフサイクル」

- 第8.8.3.2.2項「ランタイム・プロセス」

- 第8.8.3.2.3項「Oracle Security Token Serviceの起動と停止」

- 第8.8.3.2.4項「J2EEのコンポーネントとサブコンポーネント」

- 第8.8.3.2.5項「セッションの状態情報」

- 第8.8.3.2.6項「構成アーティファクト」

- 第8.8.3.2.7項「外部依存性」

8.8.3.2.1 Oracle Security Token Serviceコンポーネントのライフサイクル

起動時に、OAMとOracle Security Token Service Serverは、バックエンド・リポジトリへの接続を初期化します。このリポジトリにアクセスできない場合、OAMとOracle Security Token Serviceサーバーは、指数関数的に増加するタイムアウトを使用してリポジトリへの接続を再試行します(このタイムアウトは上限を構成できます)。

OAMとOracle Security Token Service Serverは、バックエンドの接続が停止したときには、ローカルにキャッシュしたデータに基づいてサービスの持続性を提供します。サービスは、キャッシュの有効性が失われるか、バックエンドの接続が回復するまで持続されます。

8.8.3.2.2 ランタイム・プロセス

次の図は、Oracle Security Token Serviceのランタイム・プロセスを示しています。

図8-15 Oracle Security Token Serviceのランタイム・プロセス

「図8-15 Oracle Security Tokenのランタイム・プロセス」の説明

Oracle Security Token Serviceのランタイム・プロセスは、次の説明のように動作します。

1. Webサービス・コンシューマ(WSC)は、WSPが要求するセキュリティ・トークのタイプについてのWeb Services-Trust(WS-Trust)Request Security Token(RST)メッセージを送信します。クライアントの認証は、トランスポート・レイヤーの認証を使用するか、WSSトークンをRSTメッセージにバインドすることで行われます。

2. Security Token Service(STS)はRSTメッセージを検証し、リクエストを認証してから、要求された操作の権限を付与します。

3. RSTメッセージによって指定されたメタデータに応じて、適切なセキュリティ・トークンが生成されます。ポリシー主導型の交換ユースケースでは、STSが適切なトークン生成ポリシーを検索し、該当するセキュリティ・トークンを生成します。

4. STSは、生成されたセキュリティ・トークンを格納するRSTメッセージを生成し、このメッセージをレスポンスとしてWSCに送信します。

注意:

WSPによるセキュリティ・トークンの検証は、トークンのタイプに応じて異なります。STSが信頼の仲介者としてのみ機能する場合は、Kerberosなどの基幹セキュリティ・インフラストラクチャに対する検証が実行されます。

8.8.3.2.3 Oracle Security Token Serviceの起動と停止

アクセス・サーバー(Oracle Security Token Serviceのデプロイ先)と管理コンソールは、どちらもJ2EEアプリケーションであるため、アプリケーション・サーバーが提供するユーザー・インタフェースやコマンドライン・ツールから起動できます。

8.8.3.2.4 J2EEのコンポーネントとサブコンポーネント

J2EEのコンポーネントとサブコンポーネントには、次のものがあります。

- STS: イベント・ベースの設計パターンであり、コアOracle Security Token Service 11g-PS1を実装します。WARアプリケーションとしてOAM EARファイルにパッケージ化されています。WSプロバイダ・サーブレットとJavaクラスが含まれています。STS Webアプリケーションは、/stsルート・パスにバインドされます。

- 管理コンソール: ADF/IDMシェルに基づくスタンドアロン・コンソールであり、EARファイルとしてパッケージ化されています。

- JMX Mbeans: アクセス・サーバー・パッケージにパッケージ化されています。コンフィグMbeanは、スタンドアロンのJARファイルとしてパッケージ化されています。

- WSLTコマンド: OAM/Oracle Security Token Serviceパッケージに含まれているJavaクラスで構成されています。

- OWSMエージェント: WSSプロトコルのサポートを提供するWebサービスのインターセプタです。JRFに含まれます。

- ORAProvider: JRF Webサービス・プロバイダです。

8.8.3.2.5 セッションの状態情報

Oracle Security Token Serviceは、ステートレスのJ2EEアプリケーションですが、ユーザー名トークン用のNonceキャッシュがあります。OSTSはリプレイ攻撃を防止するために、Nonceが存在する場合は、提示されたユーザー名トークンを記録します。

8.8.3.2.6 構成アーティファクト

Oracle Access ManagerとOracle Security Token Serviceは一組になるように構築され、構成やロギングなどのプロセスに同一のモジュールを使用します。Oracle Security Token Serviceの構成アーティファクトには、次のファイルが含まれます。

- DOMAIN_HOME/config/fmwconfig/oam-config.xml — インスタンス固有の情報を格納する構成ファイルです。

- DOMAIN_HOME/config/fmwconfig/oam-policy.xml — OES Micro SMが使用されていない場合にのみ存在します。

- DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml — ロギング構成です。

- DOMAIN_HOME/config/fmwconfig/cwallet.sso — パスワードです。

- DOMAIN_HOME/config/fmwconfig/oamkeystore — OAM/Oracle Security Token Serviceが所有する鍵と証明書を格納するキーストアです。

- DOMAIN_HOME/config/fmwconfig/amtruststore — X509証明書の検証に使用されるトラスト・アンカーを格納するキーストアです。

- DOMAIN_HOME/config/fmwconfig/amcrl.jar — 証明書失効に使用するCRLを格納するzipファイルです。

- DOMAIN_HOME/config/fmwconfig/default-keystore.jks — OWSMエージェントが使用する鍵と証明書を格納するOWSMキーストアです。また、WSS操作のためのX.509証明書の検証に使用されるトラステッド・アンカーも格納されます。

8.8.3.2.7 外部依存性

Oracle Security Token Serviceは、次の項目に依存します。

- LDAPベースのアイデンティティ・ストア

- ユーザー・アイデンティティ・リポジトリ

- ユーザー/ロールAPIによって抽象化されるLDAPアクセス

注意:

Oracle Access Managerは、常に1つのアイデンティティ・ストアに接続します。そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Oracle Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。

- OCSPレスポンダ・サービス

- リアルタイムX.509認証検証

- RDBMSポリシー・ストア

- ポリシー(認証および認可)リポジトリ

- OAMポリシー・エンジンによって抽象化されるRDBMSアクセス

8.8.3.3 Oracle Security Token Serviceの高可用性の構成手順

Oracle Security Token Serviceの高可用性は、Oracle Access Managerの一部として構成されます。Oracle Security Token Serviceシステムのすべての構成は、Oracle Access Managerコンソールを使用して実行します。OAMを構成する手順は、第8.8.4項「Oracle Access Managerの高可用性の構成手順」を参照してください。

8.8.3.4 Oracle Security Token Serviceの高可用性の検証

個別のOracle Security Token Serviceサーバー上のOracle Security Token Serviceのエンドポイントが稼働状態であり実行中であることを検証できます。これを実行するには、Oracle Security Token ServiceのエンドポイントのWSDLドキュメントに、次のように直接アクセスします: http(s)://[hostname:port]/sts/[ENDPOINT]?WSDL

[ENDPOINT]の部分は、既存の公開エンドポイントに置換してください。

8.8.3.5 Oracle Security Token Serviceのフェイルオーバーと予想される動作

この項では、高可用性環境におけるOracle Security Token Serviceのフェイルオーバーの特性について説明します。

Oracle Access Managerアクセス・サーバーは、ハートビート・チェック(HTTPによるPingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視して、そのアプリケーションを必要に応じて再起動できます。

WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Oracle Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。

ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出すると、後続のクライアント接続はアクティブなインスタンスにルーティングされます。このインスタンスは、セッション状態をCoherence分散オブジェクト・キャッシュから取得して処理を継続します。

フロント・チャネルHTTPバインディングは、フェイルオーバーにロード・バランシング・ルーターを使用します。

別のサービスから例外を受信した場合、Oracle Access Managerは、外部接続リクエストを再試行します。再試行の回数は構成可能であり、no retriesのオプションもあります。

詳細は次のトピックを参照してください。

- 第8.8.2.2.1項「WebLogic Serverのクラッシュ」

- 第8.8.2.2.2項「ノード障害」

- 第8.8.2.2.3項「データベース障害」

8.8.3.5.1 障害検出と再起動

OAM/Oracle Security Token Serviceアクセス・サーバーは、HTTPでPingリクエストを送信する方式によるハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャでは、アプリケーションを監視して、イベントが実行されていない場合にはアプリケーションを再起動できます。OAMアクセス・サーバーを再起動しても、その他のクラスタ・コンポーネントまたはメンバーに影響はありません。

8.8.3.5.2 ノード障害

外部接続のフェイルオーバーは、構成、再試行のタイムアウトおよび再試行の回数に基づいて行われます。LBRまたはプロキシ・サーバーはノード障害を検出すると、後続のクライアント接続をアクティブなインスタンスにルーティングします。このインスタンスは、Coherence DOCからセッション状態を取得して処理を継続します。

8.8.3.6 Oracle Security Token Serviceの有効化および無効化

Oracle Security Token Serviceは、デフォルトで有効化されています。Oracle Security Token Serviceを無効化するには、Oracle Access Managerコンソールを使用します。Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイドの使用可能なサービスの有効化または無効化に関する項を参照してください。

8.8.3.7 Oracle Security Token Serviceのトラブルシューティング

Oracle Security Token Serviceのログは、管理対象サーバーのログ・ファイルに記録されます。ただし、logging.xmlを編集すると、OSTS情報を個別のログ・ファイルdiagnostic.logに記録できます。このログファイルは、<DomainHome>/config/fmwconfig/servers/<servername>/sts/log/フォルダに格納されます。

Oracle Security Token Serviceをトラブルシューティングするために、Oracle Security Token Serviceのログ・ファイルを作成する手順は次のとおりです。

1. ファイル<DomainHome>/config/fmwconfig/servers/<servername>/logging.xmlを開きます。

2. 次を、適切なセクションに追加します。

<log_handler name='sts-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='sts/log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
</log_handler>

<logger name='oracle.security.fed' level='TRACE:32'>
<handler name='sts-handler'/>
</logger>

8.8.3.8 ログ・ファイルの場所

すべてのログ・メッセージは、アプリケーションがデプロイされたWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

8.8.3.9 その他の考慮事項

Oracle Security Token Serviceサーバーは、リプレイ攻撃などの偽のリクエストを検出できます。リプレイ攻撃は、リクエストからトークン・データを不正入手しようとして、同じトークンで別のリクエストを送信した場合に発生することがあります。この場合には、サーバーは2番目の偽のリクエストを検出します。2番目に発行された<Env: Body>に同一のトークンを持つリクエストは、Oracle Security Token Serviceサーバーに送られます。このサーバーは、UNTトークン・キャッシュを確認して、リプレイ攻撃を示すリクエストを拒否します。

8.8.4 Oracle Access Managerの高可用性の構成手順

この項では、Oracle Access Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAMサーバーに配布します。これらのOAMサーバーは、Oracle Real Application Clusters(Oracle RAC)データベースおよびオプションで外部LDAPストアと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。

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

- 第8.8.4.1項「Oracle Access Managerの構成のための前提条件」

- 第8.8.4.2項「データベースにOAMスキーマを作成するためのリポジトリ作成ユーティリティの実行」

- 第8.8.4.3項「Oracle WebLogic Serverのインストール」

- 第8.8.4.4項「Oracle Access Manager Application Tierのインストールと構成」

- 第8.8.4.5項「OAMHOST1での管理サーバー用boot.propertiesの作成」

- 第8.8.4.6項「OAMHOST1の起動」

- 第8.8.4.7項「OAMHOST1の検証」

- 第8.8.4.8項「OAMHOST2でのOAMの構成」

- 第8.8.4.9項「OAMHOST2の起動」

- 第8.8.4.10項「OAMHOST2の検証」

- 第8.8.4.11項「Oracle HTTP Serverと連携するためのOracle Access Managerの構成」

- 第8.8.4.12項「外部LDAPストアを使用するためのOracle Access Managerの構成」

- 第8.8.4.13項「Oracle Access Managerの構成の検証」

- 第8.8.4.14項「構成ファイルの同期を保つためのOracle Coherenceの構成」

- 第8.8.4.15項「Oracle Access Managerトポロジのスケール・アップとスケール・アウト」

8.8.4.1 Oracle Access Managerの構成のための前提条件

Oracle Access Managerを高可用性のために構成する前に、次の手順を実行しておく必要があります。

- データベースにOAMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。
OAMスキーマを作成するためのリポジトリ作成ユーティリティの実行手順は、第8.8.4.2項「データベースにOAMスキーマを作成するためのリポジトリ作成ユーティリティの実行」を参照してください。

- OAMHOST1およびOAMHOST2にOracle WebLogic Serverをインストールします。
第8.8.4.3項「Oracle WebLogic Serverのインストール」の手順に従い、OAMHOST1およびOAMHOST2にOracle WebLogic Serverをインストールします。

- OAMHOST1およびOAMHOST2にOracle Identity Management実行可能ファイルをインストールします。
第8.8.4.4項「Oracle Access Manager Application Tierのインストールと構成」の手順に従い、OAMHOST1およびOAMHOST2にOracle Identity Management実行可能ファイルをインストールします。

- 高可用性LDAP実装が使用可能であることを確認します。Oracle Internet Directoryのインストールと構成の詳細は、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。Oracle Virtual Directoryのインストールと構成の詳細は、第8.4.3項「Oracle Virtual Directoryの高可用性の構成手順」を参照してください。

8.8.4.2 データベースにOAMスキーマを作成するためのリポジトリ作成ユーティリティの実行

データベース・リポジトリにOAMスキーマを作成するためのリポジトリ作成ユーティリティの実行手順は、第8.2.4.1項「リポジトリ作成ユーティリティの実行」を参照してください。

8.8.4.3 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールする前に、お使いのマシンが、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』に指定されているシステム、パッチ、カーネルなどの要件を満たしていることを確認します。

インストーラを起動し、次の手順を実行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。

ORACLE_BASE/product/fmw

注意:

ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracleの値をお薦めします。

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

3. セキュリティ・アップデートが通知されるようにするために、連絡先情報を入力します。
「次へ」をクリックします。

4. 「インストール・タイプの選択」画面で、「カスタム」を選択します。
「次へ」をクリックします。

5. 「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。

6. 「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。
「次へ」をクリックします。

7. 「インストールの概要」画面で「次へ」をクリックします。

8. 「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
「完了」をクリックします。

8.8.4.4 Oracle Access Manager Application Tierのインストールと構成

この項では、Oracle Fusion MiddlewareコンポーネントをOAMHOST1およびOAMHOST2にインストールする方法について説明します。

8.8.4.4.1 アイデンティティ管理用のOracle Fusion Middlewareのインストール

この項では、Oracle Identity Managementソフトウェアを、前に作成したミドルウェア・ホーム・ディレクトリにインストールする手順について説明します。この手順を、OAMHOST1およびOAMHOST2で実行します。

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

次のようにOracle Fusion Middlewareのインストーラを起動します。

OAMHOST1> runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_<バージョン>のように入力します。

次の手順を実行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

3. 「インストール場所の指定」画面で、次の値を入力します。

- Oracleミドルウェア・ホーム: MW_HOMEのリストから前にインストールしたミドルウェア・ホームを選択します。例:

/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ: idmを入力します。

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

4. 「インストール・サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。

5. 「インストール完了」画面で「終了」をクリックします。

8.8.4.4.2 OAMHOST1でのOracle Identity Managementの構成

この項では、OAMHOST1にOracle Identity Managementドメインを作成します。

次のコマンドを実行して、構成ウィザードを起動します。

MW_HOME/oracle_common/common/bin/config.sh

次の手順を実行します。

1. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

2. 「ドメイン・ソースの選択」画面で、次を選択します。
「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

次の製品を選択します。

- Oracle Enterprise Manager

- Oracle JRF(デフォルトで選択)

- Oracle Access Managerおよびデータベース・ポリシー・ストア

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

3. 「ドメイン名と場所の指定」画面で、次を入力します。

- ドメイン名: IDM_Domain

- ドメインの場所: デフォルトを受け入れます。

- アプリケーション・ディレクトリ: デフォルトを受け入れます。

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

4. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。

5. 「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。

- WebLogicドメインの起動モード: 「本番モード」を選択します。

- JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。

6. 「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
「次へ」をクリックします。

7. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAM管理サーバーを選択し、次の項目を入力します。

- データ・ソース: OAM

- サービス名: oam.mycompany.com

- ユーザー名: OAM_OAM(OAMがRCU接頭辞として使用されていたと想定)

- パスワード: 前述のアカウント用のパスワード

右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。

- ホスト名: OAMDBHOST1

- インスタンス名: oamdb1

- ポート: 1521

再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。

- ホスト名: OAMDBHOST2

- インスタンス名: oamdb2

- ポート: 1521

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

8. 「コンポーネント・スキーマのテスト」画面で、データ・ソースの検証が試行されます。
データ・ソースの検証が成功したら、「次へ」をクリックします。

失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。

9. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

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

10. 「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。

11. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- Listen address: OAMHOST1.mycompany.com

- Listen port: 7001

- SSLリスニング・ポート: 適用なし

- SSL有効: 選択を解除

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

12. 「管理対象サーバーの構成」画面で、トポロジのOAMHOSTごとにエントリを作成します。つまり、OAMHOST1上で実行されているOAMサーバーに対して1つと、OAMHOST2上で実行されているOAMサーバーに対して1つ作成します。
OAM_SERVERエントリを選択し、そのエントリを次の値に変更します。

- Name: WLS_OAM1

- Listen address: OAMHOST1.mycompany.com

- Listen port: 14100

2つ目のOAM_SERVERに対して、「追加」をクリックし、次の情報を入力します。

- Name: WLS_OAM2

- Listen address: OAMHOST2.mycompany.com

- Listen port: 14100

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

13. 「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前としてOAM_Clusterを入力します。

その他すべてのフィールドはデフォルトの設定のままにします。

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

14. 「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。

- 右のウィンドウでクラスタ名OAM_Clusterをクリックします。

- 管理対象サーバーWLS_OAM1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。

- 管理対象サーバーWLS_OAM2に対しても同様に繰り返します。

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

15. 「マシンの構成」画面で、トポロジ内の各サーバーのマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を入力します。

- 名前: ホストの名前。ベスト・プラクティスは、DNS名(OAMHOST1)を使用することです。

- ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAMHOST1.mycompany.com)

- ノード・マネージャ・ポート: ノード・マネージャが使用するポート。

OAMHOST2に対しても次のように手順を繰り返します。

- 名前: ホストの名前。ベスト・プラクティスは、DNS名(OAMHOST2)を使用することです。

- ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAMHOST2.mycompany.com)

- ノード・マネージャ・ポート: ノード・マネージャが使用するポート。

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

16. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。

- 右のウィンドウでマシンOAMHOST1をクリックします。

- 左のウィンドウで管理対象サーバーWLS_OAM1をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAMHOST1に割り当てます。

- 右のウィンドウでマシンOAMHOST2をクリックします。

- 左のウィンドウで管理対象サーバーWLS_OAM2をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAMHOST2に割り当てます。

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

17. 「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。

注意:

構成を変更するためにconfig.shスクリプトを2回実行することはできません。構成に追加の変更を行う場合は、別のツールを使用する必要があります(Fusion Middleware ControlのMBeansブラウザなど)。

8.8.4.5 OAMHOST1での管理サーバー用boot.propertiesの作成

この項では、OAMHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法について説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。

次の手順に従って、boot.propertiesファイルを作成します。

1. OAMHOST1で、次のディレクトリに移動します。

MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

例:

cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

2. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

username=adminUser
password=adminUserPassword

注意:

管理サーバーの起動時に、このファイルのユーザー名とパスワードのエントリは暗号化されます。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。

3. 管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。

4. MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OAMHOST1の管理サーバーを起動します。

5. Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。

- WebLogic Server管理コンソール:

http://oamhost1.mycompany.com:7001/console

- Oracle Enterprise Manager Fusion Middleware Control:

http://oamhost1.mycompany.com:7001/em

weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

8.8.4.6 OAMHOST1の起動

この項では、OAMHOST1の起動手順について説明します。

8.8.4.6.1 OAMHOST1でのノード・マネージャ・プロパティ・ファイルの作成

コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:

OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

8.8.4.6.2 ノード・マネージャの起動

次のコマンドを発行してノード・マネージャを起動します。

OAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

8.8.4.6.3 OAMHOST1上のOracle Access Managerの起動

OAMHOST1上のOracle Access Managerを起動する手順は、次のとおりです。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oamhost1.mycompany.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを指定します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバーWLS_OAM1をクリックします。

6. 「起動」をクリックします。

7. 「OK」をクリックし、サーバーを起動することを確認します。

8.8.4.7 OAMHOST1の検証

次のURLにあるOAMコンソールに接続することによって実装を検証します。

http://OAMHOST1.mycompany.com:7001/oamconsole

OAM管理コンソールのログイン・ページが表示され、WebLogic administratorアカウントを使用してログインできる場合、実装は有効です。

8.8.4.8 OAMHOST2でのOAMの構成

OAMHOST1において構成が完了すると、これをOAMHOST2に伝播できます。これを実行するには、OAMHOST1でpackスクリプトを使用してドメインをパックし、OAMHOST2でunpackスクリプトを使用してドメインを解凍します。

スクリプトは両方とも、MW_HOME/oracle_common/common/binディレクトリにあります。

OAMHOST1で、次のように入力します。

pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true

これにより、/tmpディレクトリにidm_domain.jarというファイルが作成されます。このファイルをOAMHOST2にコピーします。

OAMHOST2で、次のように入力します。

unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar

8.8.4.9 OAMHOST2の起動

この項では、OAMHOST2を起動する手順について説明します。

8.8.4.9.1 OAMHOST2でのノード・マネージャ・プロパティ・ファイルの作成

コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:

OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

8.8.4.9.2 ノード・マネージャの起動

次のコマンドを発行してノード・マネージャを起動します。

OAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

8.8.4.9.3 OAMHOST2上のOracle Access Managerの起動

OAMHOST2上のOracle Access Managerを起動する手順は、次のとおりです。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oamhost2.mycompany.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを指定します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバーWLS_OAM2をクリックします。

6. 「起動」をクリックします。

7. 「OK」をクリックし、サーバーを起動することを確認します。

8.8.4.10 OAMHOST2の検証

次のURLを使用してOAMサーバーに接続することによって実装を検証します。

http://OAMHOST2.mycompany.com:14100/oam

OAMログイン・ページが表示される場合、実装は有効です。この時点では、アクションが失敗したことを示すエラーがページに表示されることに注意してください。これは、ログイン・リクエストとしてではなくページに直接アクセスしたためであり、正常な動作です。

8.8.4.11 Oracle HTTP Serverと連携するためのOracle Access Managerの構成

この項では、Oracle HTTP Serverと連携するためのOracle Access Managerの構成手順について説明します。

8.8.4.11.1 Oracle HTTP Server構成の更新

WEBHOST1およびWEBHOST2で、次のディレクトリにoam.confというファイルを作成します。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

次の行を指定してファイルを作成します。

NameVirtualHost *:7777
<VirtualHost *:7777>

ServerName sso.mycompany.com:7777
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster oamhost1.mycompany.com:14100,oamhost2.mycompany.com:14100
</Location>

</VirtualHost>

8.8.4.11.2 Oracle HTTP Serverの再起動

WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1>opmnctl stopall
WEBHOST1>opmnctl startall

WEBHOST2>opmnctl stopall
WEBHOST2>opmnctl startall

8.8.4.11.3 Oracle Access Manager Serverにロード・バランサを認識させる

デフォルトでは、Oracle Access Managerではローカル・サーバーにあるログイン・ページにリクエストに送信します。高可用性デプロイメントでは、この設定を変更してログイン・ページ・リクエストがローカル・バランサに送信されるようにする必要があります。

Oracle Access Managerにロード・バランサを認識させる手順は、次のとおりです。

1. 次のURLで、Oracle Access Managerコンソールにweblogicユーザーとしてログインします。

http://IDMHOST1.mycompany.com/oamconsole

2. 「システム構成」タブをクリックします。

3. Access Managerの設定を開きます。

4. Access Managerの設定をダブルクリックします。

5. 次の情報を入力します。

- OAMサーバー・ホスト: sso.mycompany.com

- OAMサーバー・ポート: 7777

- OAMサーバー・プロトコル: http

6. 「適用」をクリックします。

7. 管理対象サーバーWLS_OAM1およびWLS_OAM2を再起動します。

8.8.4.12 外部LDAPストアを使用するためのOracle Access Managerの構成

デフォルトでは、Oracle Access Managerは、組込みLDAPサーバーに含まれるそれ自体のLDAPストアを使用します。高可用性構成では、ディレクトリ・ストアとして外部LDAPディレクトリを使用することをお薦めします。この項では、外部LDAPストアの設定方法について説明します。

注意:

この項で説明する手順を実行する前に、環境およびLDAPストアをバックアップしておくことをお薦めします。

8.8.4.12.1 Oracle Access Manager用のディレクトリ・スキーマの拡張

アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。

Oracle Access Managerのためにディレクトリ・スキーマを拡張するには、OAMHOST1上で次のタスクを実行します。

1. 環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
IDM_HOMEをIDM_ORACLE_HOMEに設定します。

ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

2. 次の項目を含む、プロパティ・ファイルextend.propsを作成します。

IDSTORE_HOST : idstore.mycompany.com

IDSTORE_PORT : 389

IDSTORE_BINDDN : cn=orcladmin

IDSTORE_USERNAMEATTRIBUTE: cn

IDSTORE_LOGINATTRIBUTE: uid

IDSTORE_USERSEARCHBASE:cn=Users,dc=mycompany,dc=com

IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com

IDSTORE_SEARCHBASE: dc=mycompany,dc=com

IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com

説明:

- IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。非OIDディレクトリを使用している場合は、Oracle Virtual Directoryのホストを指定します。これは、IDSTORE.mycompany.comになるはずです。

- IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。

- IDSTORE_USERSEARCHBASEは、ユーザーを配置するアイデンティティ・ストアの場所です。

- IDSTORE_GROUPSEARCHBASEは、グループを配置するアイデンティティ・ストアの場所です。

- IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。

- IDSTORE_SYSTEMIDBASEは、Oracle Identity Managerリコンシリエーション・ユーザーを配置するディレクトリの場所です。

- IDSTORE_SYSTEMIDBASEは、メイン・ユーザー・コンテナに配置する必要のないユーザーを配置できるディレクトリにあるコンテナの場所です。このような事態はほとんどありませんが、その一例としてOracle Virtual DirectoryアダプタのバインドDNユーザーにも使用されるOracle Identity Managerリコンシリエーション・ユーザーがあげられます。

3. idmConfigToolコマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
Linuxコマンドの構文:

idmConfigTool.sh -preConfigIDStore input_file=configfile

Windowsコマンドの構文:

idmConfigTool.bat -prepareIDStore input_file=configfile

例:

idmConfigTool.sh -preConfigIDStore input_file=extend.props

このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。

次に、コマンドの出力例を示します。

./preconfig_id.sh
Enter ID Store Bind DN password :
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif
The tool has completed its operation. Details have been logged to automation.log

4. ログ・ファイルを確認して、エラーや警告を修正します。

8.8.4.12.2 LDAPでのユーザーとグループの作成

Oracle Access Managerが必要とするユーザーをアイデンティティ・ストアに追加する手順は、次のとおりです。

1. 環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。

- IDM_HOMEをIDM_ORACLE_HOMEに設定します。

- ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

2. 次の項目を含む、プロパティ・ファイルoam.propsを作成します。

IDSTORE_HOST : idstore.mycompany.com

IDSTORE_PORT : 389

IDSTORE_BINDDN : cn=orcladmin

IDSTORE_USERNAMEATTRIBUTE: cn

IDSTORE_LOGINATTRIBUTE: uid

IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com

IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com

IDSTORE_SEARCHBASE: dc=mycompany,dc=com

POLICYSTORE_SHARES_IDSTORE: true

OAM11G_IDSTORE_ROLE_SECURITY_ADMIN:OAMAdministrators

IDSTORE_OAMSOFTWAREUSER:oamLDAP

IDSTORE_OAMADMINUSER:oamadmin

説明:

- IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。

- IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。

- IDSTORE_USERSEARCHBASEは、ユーザーが格納されるディレクトリの場所です。

- IDSTORE_GROUPSEARCHBASEは、グループが格納されるディレクトリの場所です。

- IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。

- POLICYSTORE_SHARES_IDSTOREは、ポリシー・ストアとアイデンティティ・ストアが同じディレクトリに存在する場合にはtrueを設定します。そうでない場合は、falseを設定します。

- IDSTORE_OAMADMINUSERは、Oracle Access Manager管理者として作成するユーザーの名前です。

- IDSTORE_OAMSOFTWAREUSERは、LDAPに作成されるユーザーです。これは、Oracle Access Managerが実行中にLDAPサーバーに接続するために使用されます。

3. idmConfigToolコマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
Linuxコマンドの構文:

idmConfigTool.sh -prepareIDStore mode=OAM input_file=configfile

Windowsコマンドの構文:

idmConfigTool.bat -prepareIDStore mode=OAM input_file=configfile

例:

idmConfigTool.sh -prepareIDStore mode=OAM input_file=oam.props

このコマンドを実行すると、IDストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。

次に、コマンドの出力例を示します。

Enter ID Store Bind DN password :
Apr 5, 2011 3:53:28 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_schema_add.ldif
Apr 5, 2011 3:54:12 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_schema_index_add.ldif
Apr 5, 2011 3:55:10 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_pwd_schema_add.ldif
Apr 5, 2011 3:55:11 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oim_pwd_schema_add.ldif
*** Creation of Oblix Anonymous User ***
Apr 5, 2011 3:55:11 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_10g_anonymous_user_template.ldif
Enter User Password for oblixanonymous:
Confirm User Password for oblixanonymous:
Apr 5, 2011 3:55:53 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_group_member_template.ldif
The tool has completed its operation. Details have been logged to automation.log

4. ログ・ファイルを確認して、エラーや警告を修正します。

idmConfigToolコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Management Suite統合概要を参照してください。

8.8.4.12.3 ユーザー・アイデンティティ・ストアの作成

ユーザー・アイデンティティ・ストアを作成する手順は、次のとおりです。

1. 次のURLのOracle Access Managerコンソールに移動します。

http://adminvhn.mycompany.com:7001/oamconsole

2. WebLogic管理ユーザーを使用してログインします。

3. 「ユーザー・アイデンティティ・ストアの追加」をクリックして、次の情報を入力します。

- ストア名: LDAP_DIR

- ストア・タイプ: OVD

- 説明: ディレクトリ・ストアの説明を入力します

- SSLの有効化: これは、SSLを使用してディレクトリと通信する場合に選択します

- 場所: 場所を入力します(例: ovd.mycompany.com:389)

- バインドDN: LDAPストアを検索する権限を与えるユーザーを入力します。例: cn=orcladmin

- パスワード: oracleadminパスワードを入力します

- ユーザー名属性: たとえば、uidとします。

- ユーザー検索ベース: LDAPストアのユーザーの場所を入力します。例: cn=Users,dc=mycompany,dc=com

- グループ名属性: 例: orclguid

- グループ検索ベース: LDAPストアのグループの場所を入力します。例: cn=Groups,dc=mycompany,dc=com

- OAM管理者ロール: OAMAdministrator

4. 「適用」をクリックします。

5. 「接続テスト」をクリックし、LDAPサーバーへの接続を検証します。

8.8.4.12.4 システム・ストアおよびデフォルト・ストアへのLDAPの設定

LDAPアイデンティティ・ストアを定義したので、プライマリ認証ストアとして設定する必要があります。これを行うには、Oracle Access Managerコンソールで次の手順を実行します。

1. 「システム構成」タブをクリックします。

2. ナビゲーション・ペインから「データ・ソース - ユーザー・アイデンティティ・ストア」を選択します。

3. LDAP_DIRをクリックします。

4. 「アクション」メニューから「開く」を選択します。

5. 「デフォルト・ストアとして設定」をクリックします。

6. 「システム・ストアとして設定」をクリックします。

7. 「アクセス・システム管理者」の追加[+]アイコンをクリックします。

8. 検索名フィールドにOAM*を入力して、「検索」をクリックします。

9. 検索結果からOAMAdministratorを選択して、「選択済の追加」をクリックします。

10. 「適用」をクリックします。

11. 「システム管理者の検証」ウィンドウで、OAM管理者のユーザー名とパスワード(例: oamadmi)を入力します。

12. 「検証」をクリックします。

13. 「接続テスト」をクリックして接続をテストします。

8.8.4.12.5 外部LDAPを使用する認証の設定

デフォルトでは、Oracle Access Managerは、ユーザーの検証に統合LDAPストアを使用します。LDAP認証モジュールを更新して、そのモジュールが新しい外部LDAPストアに対してユーザーを認証できるようにします。

LDAP認証モジュールが外部LDAPを使用するように更新する手順は、次のとおりです。

1. 「システム構成」タブをクリックします。

2. 「Access Managerの設定」→「認証モジュール」→「LDAP認証モジュール」を選択します。

3. 「LDAP」をクリックします。

4. 「アクション」メニューから「開く」を選択します。

5. 「ユーザー・アイデンティティ・ストア」をLDAP_DIRに設定します。

6. 「適用」をクリックします。

7. 管理対象サーバーの管理サーバー、WLS_OAM1およびWLS_OAM2を再起動します。

8.8.4.13 Oracle Access Managerの構成の検証

http://oamhost1.mycompany.com:7001/oamconsoleでOracle Access Managerコンソールにoamadminとしてログインすることで、構成を検証します。

8.8.4.14 構成ファイルの同期を保つためのOracle Coherenceの構成

高可用性環境では、Oracleでは、Oracle Coherenceを使用して構成ファイルの同期を保ちます。Oracle Coherenceは、デフォルトではポート9095を使用しますが、これはOracle Access Managerコンソールを使用して変更できます。

URL http://admin.example.com/oamconsoleを使用して、コンソールにログインし、次の手順を実行します。

1. 「システム構成」タブをクリックします。

2. ナビゲータでサーバーを展開します。

3. ポートを変更する管理対象サーバーをダブルクリックします。

4. 「コヒーレンス」タブをクリックします。

5. 「ローカル・ポート」の値を目的の値に変更します。

6. 「適用」をクリックします。

7. 管理サーバーと、更新された管理対象サーバーと同じクラスタに配置されている管理対象サーバーすべてを再起動します。

8.8.4.15 Oracle Access Managerトポロジのスケール・アップとスケール・アウト

この項では、Oracle Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいOracle Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいOracle Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。

8.8.4.15.1 Oracle Access Managerのスケール・アップ

OAMをスケール・アップする手順は、次のとおりです。

Oracle WebLogic Server管理コンソール(http://oamhost1.mycompany.com:7001/console)にログインします。

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーの概要」ページが表示されます。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 拡張するホストで既存のサーバーを選択します。例: WLS_OAM1

4. 「クローンの作成」をクリックします。

5. 次の情報を入力します。

- サーバー名: サーバーの新しい名前。例: WLS_OAM3

- サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。

6. 「OK」をクリックします。

7. 新しく作成したサーバーWLS_OAM3をクリックします。

8. SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。

9. 「保存」をクリックします。

10. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOAMHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。表の「名前」列で「WLS_OAM3」を選択します。

4. 「SSL」タブをクリックします。「詳細」をクリックします。

5. 「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。

11. 「チェンジ・センター」メニューで構成のアクティブ化をクリックします。

新しい管理対象サーバーをOAMに登録します。この時点で、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。Oracle OAMコンソールでこれを行います。

1. OAMコンソール(http://oamhost1.mycompany.com:7001/oamconsole)にoamadminユーザーとしてログインします。

2. 「システム構成」タブをクリックします。「サーバー・インスタンス」をクリックします。

3. 「アクション」メニューから「作成」を選択します。

4. 次の情報を入力します。

- サーバー名: WLS_OAM3

- ホスト: サーバーを実行するホスト。

- ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート

- OAMプロキシ・ポート: OAMプロキシを実行するポート。これは、ホストに対して一意です。

- プロキシ・サーバーID: AccessServerConfigProxy

- モード: Open

5. 「コヒーレンス」タブをクリックします。
「ローカル・ポート」をそのホストで一意の値に設定します。

「適用」をクリックします。

6. 「適用」をクリックします。

これでアクセス・サーバーを起動できます。このアクセス・サーバーを使用するには、その存在をWebgateに通知する必要があります。次の手順を実行します。

1. OAMコンソール(http://oamhost1.mycompany.com:7001/oamconsole)にoamadminユーザーとしてログインします。

2. 「システム構成」タブをクリックします。

3. エージェント→OAMエージェント→10gエージェント」(10g WebGatesの場合)、またはエージェント→OAMエージェント→11gエージェント(11g WebGatesの場合)を開きます。

4. 変更するWebGateをダブルクリックします。

5. 「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。

6. リストからサーバー名を選択します。

7. 「適用」をクリックします。

8.8.4.15.2 Oracle Access Managerのスケール・アウト

スケール・アウトはスケール・アップと非常によく似ていますが、スケール・アウトでは、新しいノードにインストールされるソフトウェアが必要です。

1. 第8.8.4.3項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。

2. 第8.8.4.4項「Oracle Access Manager Application Tierのインストールと構成」の手順に従い、新しいホストにOracle Fusion Middleware Identity Managementコンポーネントをインストールします。

3. Oracle WebLogic Server管理コンソール(http://oamhost1.mycompany.com:7001/oamconsole)にログインします。

4. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーの概要」ページが表示されます。

5. 「チェンジ・センター」で、「ロックして編集」をクリックします。

6. 拡張するホストで既存のサーバーを選択します。例: WLS_OAM1

7. 「クローンの作成」をクリックします。

8. 次の情報を入力します。

- サーバー名: サーバーの新しい名前。例: WLS_OAM3

- サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。

9. 「OK」をクリックします。

10. 新しく作成したサーバーWLS_OAM3をクリックします。

11. SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。

12. 「保存」をクリックします。

13. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOAMHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

14. 「チェンジ・センター」メニューで構成のアクティブ化をクリックします。

15. 次のコマンドを使用してOAMHOST1上のドメインをパックします。

pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true

pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。

16. 次のコマンドを使用して新しいホスト上のドメインを解凍します。

unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications

unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。

17. コンソールから管理対象サーバーを起動する前に、OAMHOST3上にノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binにあるsetNMProps.shスクリプトを実行することによって行います。次のように入力します。

MW_HOME/oracle_common/common/bin/setNMProps.sh

新しい管理対象サーバーをOAMに登録します。ここで、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。これは、Oracle OAMコンソールから次のように実行します。

1. OAMコンソール(http://oamhost1.mycompany.com:7001/oamconsole)にoamadminユーザーとしてログインします。

2. 「システム構成」タブをクリックします。

3. 「サーバー・インスタンス」をクリックします。

4. 「アクション」メニューから「作成」を選択します。

5. 次の情報を入力します。

- サーバー名: WLS_OAM3

- ホスト: サーバーを実行するホスト、OAMHOST3。

- ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート。

- OAMプロキシ・ポート: OAMプロキシを実行するポート。これは、ホストに対して一意です。

- プロキシ・サーバーID: AccessServerConfigProxy

- モード: Open

6. 「適用」をクリックします。

これでアクセス・サーバーを起動できます。このサーバーを使用するには、その存在をWebgateに通知する必要があります。次の手順を実行します。

1. OAMコンソール(http://oamhost1.mycompany.com:7001/oamconsole)にoamadminユーザーとしてログインします。

2. 「システム構成」タブをクリックします。

3. 「エージェント」→「OAMエージェント」→「10gエージェント」を展開します。

4. 変更するWebGateをダブルクリックします。

5. 「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。

6. リストからサーバー名を選択します。

7. 「適用」をクリックします。

Web層を更新します。これで、新しい管理対象サーバーが作成されて起動され、Web層はリクエストをその管理対象サーバーに転送するようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。

これを行うには、各Web層でファイルOAM.confを更新します。このファイルは、ディレクトリORACLE_INSTANCE/config/OHS/component name/moduleconfにあります。

新しいサーバーをファイル内のWebLogicClusterディレクティブに追加します。次に例を示します。

<Location /OAM_admin>
SetHandler weblogic-handler
WebLogicCluster
OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200
</Location>

前述の行を次のように変更します。

<Location /OAM_admin>
SetHandler weblogic-handler
WebLogicCluster
OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200,OAMhsot3.mycompany.com:14300
</Location>

8.9 Oracle Identity Managerの高可用性

この項では、Oracle Identity Managerの概要およびOracle Identity Managerの高可用性環境の設計とデプロイについて説明します。

Oracle Identity Managerは、アプリケーションおよびディレクトリからユーザー・アカウントを追加、更新および削除するプロセスを自動化するユーザー・プロビジョニングおよび管理ソリューションです。また、誰が何にアクセスしたかを示すきめ細かいレポートを提供することで、法規制コンプライアンスの向上にも寄与します。Oracle Identity Managerは、スタンドアロン製品として、またはOracle Identity and Access Management Suiteの一部として使用可能です。

ユーザー・アイデンティティのプロビジョニングを自動化すると、情報テクノロジ(IT)の管理コストを削減し、セキュリティを高めることができます。プロビジョニングは、法規制コンプライアンスにおいても重要な役割を果たします。Oracle Identity Managerの主要な機能には、パスワード管理、ワークフローおよびポリシー管理、アイデンティティの調整、レポート作成と監査、およびアダプタを介した拡張性があります。

Oracle Identity Managerの主な機能は、次のとおりです。

- ユーザー管理

- ワークフローおよびポリシー

- パスワード管理

- 監査およびコンプライアンス管理

- ユーザー・プロビジョニング

- 組織およびロール管理

Oracle Identity Managerの詳細は、Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドを参照してください。

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

- 第8.9.1項「Oracle Identity Managerコンポーネント・アーキテクチャ」

- 第8.9.2項「Oracle Identity Managerの高可用性の概要」

- 第8.9.3項「Oracle Identity Managerの高可用性の構成手順」

8.9.1 Oracle Identity Managerコンポーネント・アーキテクチャ

図8-16は、Oracle Identity Managerのアーキテクチャを示しています。

図8-16 Oracle Identity Managerコンポーネント・アーキテクチャ

「図8-16 Oracle Identity Managerコンポーネント・アーキテクチャ」の説明

8.9.1.1 Oracle Identity Managerコンポーネントの特性

Oracle Identity Manager Serverは、Java EE標準に準拠した、スタンドアロンの自己完結型アイデンティティ管理ソリューションです。ユーザー管理、ワークフローおよびポリシー、パスワード管理、監査およびコンプライアンス管理、ユーザー・プロビジョニング、および組織およびロール管理機能を提供します。

Oracle Identity Managerは、標準Java EEアプリケーションであり、Oracle WebLogic Server上にデプロイされ、データベースを使用してランタイムおよび構成データを格納します。MDSスキーマには構成情報が含まれ、OIMスキーマにはランタイムおよびユーザー情報が格納されます。

Oracle Identity Managerは、RMIを使用してSOA管理対象サーバーに接続し、SOA EJBを呼び出します。

Oracle Identity Managerは、Oracle SOA Suiteのヒューマン・ワークフロー・モジュールを使用して、そのリクエスト・ワークフローを管理します。Oracle Identity Managerは、SOA Webサービスに接続するためのSOA Soapurlを使用してSOAに接続します。これは、SOA用のフロントエンドURLであり、クラスタ化SOAサーバーの場合は、ロード・バランサまたはWebサーバーのURLです。ワークフローが完了した場合、SOAはOIMFrontEndURLを使用してOracle Identity Manager Webサービスをコールバックします。Oracle SOAは、Oracle Identity Managerとともにデプロイされます。

いくつかのOracle Identity ManagerモジュールはJMSキューを使用します。各キューは、個別のメッセージドリブンBean(MDB)によって処理されます。MDBもOracle Identity Managerアプリケーションの一部です。メッセージ・プロデューサもOracle Identity Managerアプリケーションの一部です。

Oracle Identity Managerは、埋込みOracle Entitlements Server(マイクロカーネル)を使用します。これもOracle Identity Managerエンジンの一部です。Oracle Entitlements Server(OES)は、Oracle Identity Manager内部で認可の確認に使用されます。たとえば、ポリシー制約の1つで、特定のロールを持つユーザーのみがユーザーの作成を許可されると決定されているとします。これは、Oracle Identity Managerユーザー・インタフェースを使用して定義します。

Oracle Identity Managerは、スケジュール済アクティビティのためにクォーツ・ベースのスケジューラを使用します。バックグラウンドで実行される様々なスケジュール済アクティビティがあります。たとえば、スケジュール済タスクの1つは、ユーザーの終了日後にそのユーザーを無効化することです。

Oracle Identity Managerは、すべてのレポート作成機能のためにOracle BI Publisherと連携します。BI Publisherは、異なるドメインまたは同じドメインに配置され、単純な静的なURL統合のみで統合されます。BI PublisherとOracle Identity Managerランタイム・コンポーネントとの間に相互作用はありません。BI Publisherは、レポート作成のために同じOIMデータベース・スキーマを使用するように構成されます。

LDAPSyncが外部ディレクトリ・サーバー(Oracle Internet Directory、ODSEE、Microsoft Active Directoryなど)と直接通信できるようにすると、高可用性とフェイルオーバー機能をサポートするためにIdentity Virtualization Library (libOVD)の構成が必要になります。

libOVDを構成するには、WLSTコマンドのaddLDAPHostを使用します。libOVDを管理する場合は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのIdentity Virtualization Library(libOVD)アダプタの管理に関する項でWLSTコマンドの一覧を参照してください。

8.9.1.2 ランタイム・プロセス

Oracle Identity Managerは、Oracle WebLogic ServerにステージなしアプリケーションとしてデプロイされるJava EEアプリケーションです。Oracle Identity Managerサーバーは、それがデプロイされたWebLogic Serverの起動時に初期化されます。アプリケーションの初期化の一部として、クォーツ・ベースのスケジューラも起動されます。初期化が完了すると、システムはクライアントからリクエストを受信できるようになります。

Remote ManagerおよびDesign Consoleは別にスタンドアロンのユーティリティとして起動する必要があります。

8.9.1.3 コンポーネントとプロセスのライフサイクル

Oracle Identity Managerは、外部的に管理されるアプリケーションとしてOracle WebLogic Serverにデプロイされます。Oracle WebLogic Serverはデフォルトで、Oracle Identity Managerアプリケーションに対する他のライフサイクル・イベントの起動、停止、監視、および管理を行います。

Oracle Identity Managerは、標準Java EEアプリケーションであり、アプリケーション・サーバー・コンポーネントが起動した後に起動します。また、Oracle Identity Managerでは、Oracle Identity Managerコンポーネント・メカニズムの一部である認証システムも使用され、それはWebLogic JNDIが初期化されてアプリケーションが起動する前に起動されます。これは、OIM ORACLE_HOMEからロードされます。

Oracle Identity Managerでは、クォーツ・ベースのスケジューラが使用されます。クォーツは、すべてのWebLogic Serverインスタンスでスケジューラ・スレッドを起動します。データベースが、スケジュール済アクティビティの選択と実行のための中央記憶域として使用されます。スケジューラ・インスタンスの1つがジョブを選択した場合、その他のインスタンスがその同じジョブを選択することはありません。

Oracle Identity Managerは、データベースから、サーバー・インスタンスのメモリー内のキャッシュに特定のシステム構成値をキャッシュします。これらのキャッシュは独立してロードされ、サーバー間で共有されません。システム構成が変更されると、キャッシュがクリーンアップされます、このプロセスにより、クラスタ内のすべてのサーバーに通知されます。Oracle Identity Managerは、この目的のためにOSCache、JGroupsを使用します。JGroupsはマルチキャスト・アドレスを使用します。有効なマルチキャスト・アドレスは、インストール中にランダムに生成され、Oracle Identity Managerメタデータ・リポジトリ・ファイルにシードされます。

WebLogicノード・マネージャは、サーバー・プロセスを監視し、障害発生時にそのプロセスを再起動するように構成できます。

Oracle Enterprise Manager Fusion Middleware Controlは、アプリケーションの監視および構成の変更に使用します。

8.9.1.4 Oracle Identity Managerの起動と停止

Oracle Identity Managerのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理できます。

- Oracle WebLogic Scripting Tool(WLST)

- Oracle WebLogic Server管理コンソール

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle WebLogicノード・マネージャ

8.9.1.5 構成アーティファクト

Oracle Identity Managerサーバーの構成は、MDSリポジトリに格納され、MBeanを使用して管理されます。oim-config.xmlファイルがメイン構成ファイルです。OIM構成は、Oracle Enterprise Manager Fusion Middleware ControlまたはコマンドラインMDSユーティリティを介してMBeanブラウザを使用して管理できます。oim-config.xmlファイルは、MDSリポジトリの/db/oim-config.xmlの場所に格納されています。

MDSユーティリティの詳細は、Oracle Fusion Middleware Oracle Identity Manager開発者ガイドのMDSユーティリティに関する項を参照してください。

JMSは、インストーラによってすぐに使用可能な状態に構成されます。JMSキュー、接続プール、データ・ソースなど必要なものはすべて、WebLogicアプリケーション・サーバー上に構成されます。次のキューが、Oracle Identity Managerをデプロイするときに作成されます。

- oimAttestationQueue

- oimAuditQueue

- oimDefaultQueue

- oimKernelQueue

- oimProcessQueue

- oimReconQueue

- oimSODQueue

Design ConsoleおよびRemote Managerの構成は、xlconfig.xmlファイルに格納されます。

8.9.1.6 外部依存性

Oracle Identity Managerは、Oracle WebLogic管理対象サーバーにデプロイされるJava EEアプリケーションです。Oracle Identity Managerは、Oracle SOA Suiteのワークリストおよびヒューマン・ワークフロー・モジュールを使用して、そのリクエスト・フローを管理します。Oracle Identity Managerは、外部リポジトリと対話して、構成およびランタイム・データを格納します。Oracle Identity Managerでは、初期化およびランタイム時に、これらのリポジトリが使用可能である必要があります。Oracle Identity Managerの資格証明はすべて、OIMリポジトリに格納されます。Oracle Identity Managerサーバーの機能に必要な外部コンポーネントは次のとおりです。

- Oracle WebLogic Server

- 管理サーバー

- 管理対象サーバー

- データ・リポジトリ

- 構成リポジトリ(MDSスキーマ)

- ランタイム・リポジトリ(OIMスキーマ)

- ユーザー・リポジトリ(OIMスキーマ)

- SOAリポジトリ(SOAスキーマ)

- 外部LDAPストア(LDAP同期を使用する場合)

- BI Publisher

Design Consoleは、管理者が、開発とカスタマイズのために使用するツールです。Design Consoleは、Oracle Identity Managerエンジンと直接通信し、Oracle Identity Managerサーバーが依存するものと同じコンポーネントに依存します。

Remote Managerは、オプションの独立したスタンドアロン・アプリケーションであり、ローカル・システムのカスタムAPIを呼び出します。そのため、それらのカスタムAPIのJARファイルがそのクラスパスに含まれている必要があります。

8.9.1.7 Oracle Identity Managerのログ・ファイルの場所

Oracle Identity Managerは、Oracle WebLogic ServerにデプロイされるJava EEアプリケーションです。サーバーに関連するログ・メッセージはすべて、サーバーのログ・ファイルに記録され、Oracle Identity Managerに固有のメッセージはすべて、アプリケーションがデプロイされたOracle WebLogic Serverの診断ログ・ファイルに記録されます。

Oracle WebLogic Serverのログ・ファイルは、次のディレクトリに配置されます。

DOMAIN_HOME/servers/serverName/logs

メイン・ログ・ファイルは、serverName.log、serverName.out、およびserverName-diagnostic.logの3つです。ここでserverNameはOracle WebLogic Serverの名前です。たとえば、Oracle WebLogic Server名がwls_OIM1の場合、診断ログ・ファイル名はwls_OIM1-diagnostic.logになります。

このログ・ファイルは、Oracle Enterprise Manager Fusion Middleware Controlを使用して表示できます。

8.9.2 Oracle Identity Managerの高可用性の概要

この項では、Oracle Identity Managementの高可用性の概要およびOracle Identity Managerの高可用性環境の設計とデプロイについて説明します。

注意:

Oracle Identity Managerを高可用性構成にデプロイする場合は、次のことに注意してください。

- Oracle Identity ManagerはOracle RACデータベースにデプロイできますが、Oracle RACのフェイルオーバーは、このリリースではOracle Identity Managerに対して透過的ではありません。Oracle RACのフェイルオーバーが発生すると、エンド・ユーザーは、各自のリクエストを再送信する必要がある場合があります。

- Oracle Identity Managerは常に、SOAクラスタ内で少なくとも1つのノードが使用可能であることを必要とします。SOAクラスタが使用可能でない場合、エンド・ユーザーのリクエストは失敗します。Oracle Identity Managerノードは、失敗したSOA呼出しに対して再試行しません。そのため、SOA呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。

8.9.2.1 Oracle Identity Managerの高可用性アーキテクチャ

図8-17は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたOracle Identity Managerを示しています。

図8-17 Oracle Identity Managerの高可用性アーキテクチャ

「図8-17 Oracle Identity Managerの高可用性アーキテクチャ」の説明

OIMHOST1では、次のインストールが実行されています。

- Oracle Identity ManagerインスタンスはWLS_OIM1管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA1管理対象サーバーにインストールされています。

- Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

- WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。

OIMHOST2では、次のインストールが実行されています。

- Oracle Identity ManagerインスタンスはWLS_OIM2管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA2管理対象サーバーにインストールされています。

- Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

- OIMHOST1およびOIMHOST2上のWLS_OIM1およびWLS_OIM2管理対象サーバーのインスタンスは、OIM_Clusterクラスタとして構成されています。

- OIMHOST1およびOIMHOST2上のWLS_SOA1およびWLS_SOA2管理対象サーバーのインスタンスは、SOA_Clusterクラスタとして構成されています。

- WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OIMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。

図8-17のOracle Identity Managerの高可用性構成では、次の仮想ホスト名が使用されています。

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

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

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

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

- VHNは、Oracle Real Application Clusters(Oracle RAC)データベース・ホストの仮想IPアドレスを指します。

8.9.2.2 Oracle Identity Managerクラスタの起動と停止

高可用性アーキテクチャでは、Oracle Identity Managerは、Oracle WebLogicクラスタにデプロイされます。このクラスタには、クラスタのメンバーとして少なくとも2つのサーバーが存在します。

デフォルトでは、Oracle WebLogic Serverによって、このアプリケーションの起動、停止、監視および様々なライフサイクル・イベントの監視が行われます。Oracle Identity Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

Oracle Identity Managerのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理できます。

- Oracle WebLogic Server管理コンソール

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle WebLogic Scripting Tool(WLST)

8.9.2.3 クラスタワイドの構成変更

高可用性環境では、1つのOracle Identity Managerインスタンスの構成変更により、他のすべてのインスタンスの構成が変更されます。これは、すべてのOracle Identity Managerインスタンスが同じ構成リポジトリを共有しているためです。

8.9.2.4 LDAPとの同期に関する考慮事項

LDAPとOracle Identity Managerデータベースとの間の同期情報は、調整と呼ばれるプロセスによって処理されます。このプロセスは、主にバックグラウンドで実行されるスケジュール済プロセスです。このプロセスは手動で実行することもできます。

同期プロセス中にLDAPが停止した場合、Oracle Identity Managerによって取得されていないデータは、調整タスクの次回の実行時に取得されます。

8.9.3 Oracle Identity Managerの高可用性の構成手順

この項では、Oracle Identity Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。

この項には、高可用性を得るためのOracle Identity Managementの構成に関する次の項目があります。

- 第8.9.3.1項「Oracle Identity Managerの構成のための前提条件」

- 第8.9.3.2項「OIMHOST1でのOIMとSOAのためのWebLogicドメインの作成と構成」

- 第8.9.3.3項「OIMHOST1でのインストール後の手順」

- 第8.9.3.4項「OIMHOST1でのOracle Identity Managerの構成」

- 第8.9.3.5項「管理対象サーバーに対する構成後の手順」

- 第8.9.3.6項「OIMHOST1でのOracle Identity Managerインスタンスの検証」

- 第8.9.3.7項「OIMHOST2へのOracle Identity Managerの伝播」

- 第8.9.3.8項「OIMHOST2でのインストール後の手順」

- 第8.9.3.9項「OIMHOST2でのOracle Identity Managerインスタンスの検証」

- 第8.9.3.10項「LDAP構成ポストセットアップ・スクリプトを使用したOracle Internet Directoryの構成」

- 第8.9.3.11項「OIMおよびSOA管理対象サーバーに対するサーバーの移行の構成」

- 第8.9.3.12項「共有JMS永続ストアの構成」

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

- 第8.9.3.14項「WEBHOST1およびWEBHOST2へのOracle HTTP Serverのインストール」

- 第8.9.3.15項「Web Tierと連携するためのOracle Identity Managerの構成」

- 第8.9.3.16項「Oracle HTTP Serverの構成の検証」

- 第8.9.3.17項「Oracle Identity Managerのフェイルオーバーおよび予想される動作」

- 第8.9.3.18項「Oracle Identity Managerの高可用性のトラブルシューティング」

- 第8.9.3.19項「Oracle Identity Managerトポロジのスケール・アップとスケール・アウト」

8.9.3.1 Oracle Identity Managerの構成のための前提条件

Oracle Identity Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。

- データベースに OIMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。
OIMスキーマを作成するためのリポジトリ作成ユーティリティの実行手順は、第8.9.3.1.1項「データベースにOIMスキーマを作成するためのRCUの実行」を参照してください。

- OIMHOST1およびOIMHOST2にOracle WebLogic Serverをインストールします。
第8.9.3.1.2項「Oracle WebLogic Serverのインストール」の手順に従い、OIMHOST1およびOIMHOST2にOracle WebLogic Serverをインストールします。

- OIMHOST1およびOIMHOST2にOracle SOA Suiteをインストールします。
第8.9.3.1.3項「OIMHOST1およびOIMHOST2へのOracle SOA Suiteのインストール」の手順に従い、OIMHOST1およびOIMHOST2にOracle SOA Suiteソフトウェアをインストールします。

- OIMHOST1およびOIMHOST2にOracle Identity Managementソフトウェアをインストールします。
第8.9.3.1.4項「OIMHOST1およびOIMHOST2へのOracle Identity Managerのインストール」の手順に従い、OIMHOST1およびOIMHOST2にOracle Identity Managementソフトウェアをインストールします。

- 高可用性LDAP実装が使用可能であることを確認します。

注意:

この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managerと統合されているOracle Identity Managerインストールでのみ必要です。

LDAPSyncオプションの有効化や、Oracle Access Managerとの統合を計画していない場合は、この項をスキップできます。

Oracle Internet Directoryのインストールと構成の詳細は、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。Oracle Virtual Directoryのインストールと構成の詳細は、第8.4.3項「Oracle Virtual Directoryの高可用性の構成手順」を参照してください。Oracle Identity Managerは、Oracle Internet Directoryと直接通信しないことに注意してください。それは、Oracle Virtual Directoryと通信し、Oracle Virtual DirectoryがOracle Internet Directoryと通信します。

- wlfullclient.jarファイルを、OIMHOST1およびOIMHOST2で作成します。
Oracle Identity Managerは、特定の操作にwlfullclient.jarライブラリを使用します。このライブラリは出荷されていないため、手動で作成する必要があります。このライブラリは、環境のアプリケーション層にあるすべてのマシンのMW_HOME/wlserver_10.3/server/libディレクトリの下に作成することをお薦めします。このライブラリは、OIDHOST1、OIDHOST2、OVDHOST1、OVDHOST2などのディレクトリ層マシンに作成する必要はありません。

次の手順に従って、wlfullclient.jarファイルを作成します。

1. MW_HOME/wlserver_10.3/server/libディレクトリに移動します。

2. JAVA_HOMEをMW_HOME/jdk160_18に設定し、JAVA_HOME/binディレクトリがパスに含まれていることを確認します。

3. 次のファイルを実行することによって、wlfullclient.jarファイルを作成します。
java -jar wljarbuilder.jar

8.9.3.1.1 データベースにOIMスキーマを作成するためのRCUの実行

OIMHOST1およびOIMHOST2にOracle Identity ManagerおよびSOAインスタンスをインストールする前に、リポジトリ作成ユーティリティ(RCU)を使用して、Oracle Identity Managerで使用するスキーマのコレクションを作成しておく必要があります。

RCUは、Oracle Fusion Middleware 11gキットの部品として付属する専用のCDに収録されています。

次の手順に従って、RCUを実行し、Oracle RACデータベース・リポジトリにOracle Identity Managerスキーマを作成します。

1. 次のコマンドを発行します。

prompt> RCU_HOME/bin/rcu &

2. 「ようこそ」画面で「次へ」をクリックします。

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

4. 「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。

- データベース・タイプ: Oracle Database

- ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: OIMDBHOST1-VIPまたはOIMDBHOST2-VIP

- ポート: データベースのポート番号。例: 1521

- サービス名: データベースのサービス名。例: oim.mycompany.com

- ユーザー名: SYS

- パスワード: SYSユーザーのパスワード

- ロール: SYSDBA

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

5. グローバルな前提条件が完了したら、「前提条件チェック」画面で「OK」をクリックします。

6. 「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: ha

コンポーネント:

- 「Identity Management」の下では次のように指定します。

- Oracle Identity Manager - OIM

- デフォルトで、「Metadata Services - MDS」が選択されていることに注意してください。

- 「SOAおよびBAMインフラストラクチャ」の下で:

- SOAインフラストラクチャ: デフォルトで、SOAINFRAが選択済です。

- ユーザー・メッセージング・サービス: デフォルトで、ORASDPMが選択済です。

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

7. コンポーネントの前提条件が完了したら、「前提条件チェック」画面で「OK」をクリックします。

8. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。

9. 「表領域のマップ」画面で、コンポーネントの表領域を選択します。

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

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

8.9.3.1.2 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールする前に、お使いのマシンが、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』に指定されているシステム、パッチ、カーネルなどの要件を満たしていることを確認します。

インストーラを起動し、OIMHOST1およびOIMHOST2で次の手順を実行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。

ORACLE_BASE/product/fmw

注意:

ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracleの値をお薦めします。

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

3. セキュリティ・アップデートが通知されるようにするために、「セキュリティ更新のための登録」画面で連絡先情報を入力します。
「次へ」をクリックします。

4. 「インストール・タイプの選択」画面で、「カスタム」を選択します。
「次へ」をクリックします。

5. 「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。

6. 「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。
「次へ」をクリックします。

7. 「インストールの概要」画面で「次へ」をクリックします。

8. 「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
「完了」をクリックします。

8.9.3.1.3 OIMHOST1およびOIMHOST2へのOracle SOA Suiteのインストール

次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOIMHOST1およびOIMHOST2にインストールします。

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

次のようにOracle Fusion Middlewareコンポーネントのインストーラを起動します。

HOST1> runInstaller

インストーラで、JRE/JDKの場所を入力するよう求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_14_<バージョン>のように入力します。

次の手順を実行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

3. 「インストール場所の指定」画面で、次の値を入力します。

- Oracleミドルウェア・ホーム: MW_HOMEのリストから前にインストールしたミドルウェア・ホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ:

- ORACLE_HOMEにOracle SOA Suiteをインストールするときに、Oracleホーム・ディレクトリ名としてsoaを入力します。

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

4. 「インストール・サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。

5. 「インストール完了」画面で「終了」をクリックします。

8.9.3.1.4 OIMHOST1およびOIMHOST2へのOracle Identity Managerのインストール

次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOIMHOST1およびOIMHOST2にインストールします。

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

次のようにOracle Fusion Middlewareコンポーネントのインストーラを起動します。

HOST1> runInstaller

インストーラで、JRE/JDKの場所を入力するよう求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_<バージョン>のように入力します。

次の手順を実行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

3. 「インストール場所の指定」画面で、次の値を入力します。

- Oracleミドルウェア・ホーム: MW_HOMEのリストから前にインストールしたミドルウェア・ホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ:

- ORACLE_HOMEにOracle Identity and Access Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてiamを入力します。

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

4. 「インストール・サマリー」画面で「インストール」をクリックします。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。

5. 「インストール完了」画面で「終了」をクリックします。

8.9.3.2 OIMHOST1でのOIMとSOAのためのWebLogicドメインの作成と構成

OIMHOST1にドメインを作成する必要があります。次の手順を実行します。

1. このコマンドを実行して、構成ウィザードを起動します。

MW_HOME/oracle_common/common/bin/config.sh

2. 「ようこそ」画面で、「WebLogicドメインの作成」を選択します。
「次へ」をクリックします。

3. 「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
リストから、次のように選択します。

- Oracle Identity Manager
Oracle SOA SuiteとOracle WSM Policy Managerが自動的に選択されます。

- Oracle Enterprise Manager
Oracle JRFが自動的に選択されます。

4. 「ドメイン名と場所の指定」画面で、ドメインおよびそのすべてのアプリケーションの名前と場所を入力します。
次の項目を入力します。

- ドメイン名: IDMDomain

- ドメインの場所: デフォルトを受け入れます。

- アプリケーションの場所: デフォルトを受け入れます。

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

5. 管理サーバーのユーザー名とパスワードの構成画面で、次のように入力します。

- Name: weblogic

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

- Confirm User Password: weblogicユーザーのパスワードを入力します。

- Description: ユーザーの説明を入力します。

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

6. 「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JRockit SDK 1.6.n」を選択します。
「次へ」をクリックします。

7. 「JDBCコンポーネント・スキーマの構成」画面で、次に示すコンポーネント・スキーマを選択します。

- SOAインフラストラクチャ

- ユーザー・メッセージング・サービス

- OIM MDSスキーマ

- OWSM MDSスキーマ

- SOA MDSスキーマ

- OIMスキーマ

「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」の横のチェック・ボックスを選択します。

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

8. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、すべてのマルチ・データ・ソース・スキーマを選択し、次のように入力します。

- サービス名: oim.mycompany.com

- 最初のRACノードの場合は、次のように入力します。

- ホスト名: OIMDBHOST1-VIP.mycompany.com

- インスタンス名: oimdb1

- ポート: 1521

- 2つ目のRACノードの場合は、次のように入力します。

- ホスト名: OIMDBHOST2-VIP.mycompany.com

- インスタンス名: oimdb2

- ポート: 1521

各スキーマを個別に選択し、スキーマのユーザー名とパスワードを表8-7に示すように入力します。

表8-7 各マルチ・データ・ソース・スキーマのスキーマ所有者とパスワードの入力

スキーマ名

スキーマ所有者

パスワード

SOAインフラストラクチャ

HA_SOAINFRA

<パスワードを入力>

ユーザー・メッセージング・サービス

HA_ORASDPM

<パスワードを入力>

OIM MDSスキーマ

HA_MDS

<パスワードを入力>

OWSM MDSスキーマ

HA_MDS

<パスワードを入力>

SOA MDSスキーマ

HA_MDS

<パスワードを入力>

OIMスキーマ

HA_OIM

<パスワードを入力>

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

9. 「コンポーネント・スキーマのテスト」画面で、すべてのスキーマを選択して「接続のテスト」をクリックします。すべてのスキーマに対するテストが正常に完了したことを確認します。
「次へ」をクリックします。

10. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

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

11. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- Listen address: oimhost1.mycompany.com

- Listen port: 7001

- SSLリスニング・ポート: 適用なし

- SSL有効: 選択を解除

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

12. 「JMS分散宛先タイプの選択」画面で、リストされているすべてのJMSシステム・リソースが共通分散宛先であることを確認します。そのようになっていない場合は、ドロップダウン・ボックスから「UDD」を選択します。エントリが表8-8に示すように設定されていることを確認します。

表8-8 JMSシステム・リソースに対して選択する値

JMSシステム・リソース

共通/重み設定された分散宛先

UMSJMSSystemResource

UDD

SOAJMSModule

UDD

OIMJMSModule

UDD

BPMJMSModule

UDD

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

次のメッセージの「オーバーライドの警告」ダイアログ・ボックスが表示されます。

「CFGFWK-40915: 共通分散宛先(UDD)への変換対象として少なくとも1つのJMSシステム・リソースが選択されています。この変換は、JMSシステム・リソースがクラスタに割り当てられている場合にのみ行われます。」

「警告」ボックスで「OK」をクリックします。

13. 「管理対象サーバーの構成」画面を初めて表示した場合、構成ウィザードによって2つのデフォルト管理対象サーバー(oim_server1とsoa_server1)が作成されています。デフォルトの管理対象サーバーの詳細を変更し、2つ目の管理対象サーバーを追加します。次の手順に従います。
oim_server1エントリについては、そのエントリを次の値に変更します。

- Name: WLS_OIM1

- Listen address: OIMVHN1

- Listen port: 14000

soa_server1エントリについては、そのエントリを次の値に変更します。

- Name: WLS_SOA1

- Listen address: SOAVHN1

- Listen port: 8001

2つ目のOIMサーバーに対して、「追加」をクリックし、次の情報を入力します。

- Name: WLS_OIM2

- Listen address: OIMVHN2

- Listen port: 14000

2つ目のSOAサーバーに対して、「追加」をクリックし、次の情報を入力します。

- Name: WLS_SOA2

- Listen address: SOAVHN2

- Listen port: 8001

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

注意:

さらに管理対象サーバーを追加するには、2つ目の管理対象サーバーを追加するための手順に従ってください。

14. 「クラスタの構成」画面で、「追加」をクリックして2つのクラスタを作成します。
OIMクラスタに関して次の情報を入力します。

- 名前: oim_cluster

- クラスタのメッセージング・モード: unicast

SOAクラスタに関して次の情報を入力します。

- 名前: soa_cluster

- クラスタのメッセージング・モード: unicast

その他すべてのフィールドをデフォルトの設定のままにして、「次へ」をクリックします。

15. 「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。右のウィンドウでクラスタ名をクリックします。
サーバーの下の管理対象サーバーをクリックし、矢印をクリックしてそれをクラスタに割り当てます。

WLS_OIM1およびWLS_OIM2管理対象サーバーをoim_clusterのメンバーになるように割り当てます。

WLS_SOA1およびWLS_SOA2管理対象サーバーをsoa_clusterのメンバーになるように割り当てます。

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

16. 「マシンの構成」画面で、トポロジ内の各サーバーのマシンを作成します。
ホストでいずれかのタイプのUnixオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」をクリックします。

次の情報を入力します。

- 名前: ホストの名前。ここでは、DNS名を使用することをお薦めします。

- ノード・マネージャ・リスニング・アドレス: ここにマシンのDNS名を入力します。

- ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。

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

注意:

UNIXでは、「マシン」タブの下のデフォルト・ローカル・マシン・エントリを削除します。

17. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
右側のウィンドウでマシンをクリックします。

左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。

矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。

すべての管理対象サーバーが適切なマシンに割り当てられるまで、この手順を繰り返します。

一般的な例は、次のようになります。

- Host1: Admin Server、WLS_OIM1、およびWLS_SOA1

- Host2: WLS_OIM2およびWLS_SOA2

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

18. 「構成のサマリー」画面で、「作成」をクリックしてドメインを作成します。

8.9.3.3 OIMHOST1でのインストール後の手順

この項では、OIMHOST1で実行するインストール後の手順について説明します。これらの項目が含まれます。

- 第8.9.3.3.1項「OIMHOST1での管理サーバー用boot.propertiesの作成」

- 第8.9.3.3.2項「OIMHOST1でのノード・マネージャの更新」

- 第8.9.3.3.3項「OIMHOST1でのノード・マネージャの起動」

- 第8.9.3.3.4項「OIMHOST1での管理サーバーの起動」

8.9.3.3.1 OIMHOST1での管理サーバー用boot.propertiesの作成

この項では、OIMHOST1上の管理サーバー用boot.propertiesファイルを作成する方法を説明します。boot.propertiesファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。

次の手順に従って、boot.propertiesファイルを作成します。

1. OIMHOST1で、次のディレクトリを作成します。

MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

例:

$ mkdir -p
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

2. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

username=adminUser
password=adminUserPassword

注意:

管理サーバーの起動時に、このファイルのユーザー名とパスワードのエントリは暗号化されます。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。

8.9.3.3.2 OIMHOST1でのノード・マネージャの更新

WebLogic管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャではStartScriptEnabledプロパティがtrueに設定されていることが必要です。

これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。

MW_HOME/oracle_common/common/bin

8.9.3.3.3 OIMHOST1でのノード・マネージャの起動

次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST1上のノード・マネージャを起動します。

MW_HOME/wlserver_10.3/server/bin

8.9.3.3.4 OIMHOST1での管理サーバーの起動

次の手順に従い、管理サーバーを起動し、その起動を確認します。

1. 次のコマンドを実行し、OIMHOST1上の管理サーバーを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

2. Webブラウザを開いて次のページにアクセスし、管理サーバーの起動が正常に行われたことを確認します。

- WebLogic Server管理コンソール:

http://oimhost1.mycompany.com:7001/console

- Oracle Enterprise Manager Fusion Middleware Control:

http://oimhost1.mycompany.com:7001/em

weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

8.9.3.4 OIMHOST1でのOracle Identity Managerの構成

この項では、Oracle Identity ManagerとSOA管理対象サーバーの起動前の構成方法について説明します。

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

- 第8.9.3.4.1項「Oracle Identity Managerの構成のための前提条件」

- 第8.9.3.4.2項「Oracle Identity Management構成ウィザードの実行」

8.9.3.4.1 Oracle Identity Managerの構成のための前提条件

Oracle Identity Managerを構成する前に、次のタスクが実行済であることを確認します。

注意:

この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managerと統合されているOracle Identity Managerインストールでのみ必要です。

LDAPSyncオプションの有効化や、Oracle Access Managerとの統合を計画していない場合は、この項をスキップできます。

1. 「Oracle Identity Manager用のディレクトリ・スキーマの拡張」

2. 「Oracle Identity Manager用のユーザーとグループの作成」

3. 「Oracle Virtual Directoryでのアダプタの作成」

Oracle Identity Manager用のディレクトリ・スキーマの拡張

アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。

アイデンティティ・ストアを事前構成するには、OIMHOST1で次の手順を実行します。

1. 環境変数MW_HOME、JAVA_HOMEおよびORACLE_HOMEを設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

2. 次の項目を含む、プロパティ・ファイルextend.propsを作成します。

IDSTORE_HOST : idstore.mycompany.com

IDSTORE_PORT : 389

IDSTORE_BINDDN: cn=orcladmin

IDSTORE_USERNAMEATTRIBUTE: cn

IDSTORE_LOGINATTRIBUTE: uid

IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com

IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com

IDSTORE_SEARCHBASE: dc=mycompany,dc=com

IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com

説明:

- IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。非OIDディレクトリを使用している場合は、Oracle Virtual Directoryのホストを指定します(これは、IDSTORE.mycompany.comになるはずです)。

- IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。

- IDSTORE_USERSEARCHBASEは、ユーザーが格納されるディレクトリの場所です。

- IDSTORE_GROUPSEARCHBASEは、グループが格納されるディレクトリの場所です。

- IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。

- IDSTORE_SYSTEMIDBASEは、メイン・ユーザー・コンテナに配置する必要のないユーザーを配置できるディレクトリにあるコンテナの場所です。このような事態はほとんどありませんが、その一例としてOracle Virtual DirectoryアダプタのバインドDNユーザーにも使用されるOracle Identity Managerリコンシリエーション・ユーザーがあげられます。

3. idmConfigToolコマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
Linuxのコマンド構文:

idmConfigTool.sh -preConfigIDStore input_file=configfile

Windowsのコマンド構文:

idmConfigTool.bat -preConfigIDStore input_file=configfile

例:

idmConfigTool.sh -preConfigIDStore input_file=extend.props

このコマンドを実行すると、IDストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。

次に、コマンドの出力例を示します。

./preconfig_id.sh
Enter ID Store Bind DN password :
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif
The tool has completed its operation. Details have been logged to automation.log

4. ログ・ファイルを確認して、エラーや警告を修正します。

Oracle Identity Manager用のユーザーとグループの作成

oimadminユーザーをアイデンティティ・ストアに追加する手順を実行して、そのユーザーをOracle Identity Manager管理者グループに割り当てます。また、リコンシリエーションを実行するために、標準の場所cn=Users以外にもユーザーを作成します。Oracle Virtual Directoryを使用したディレクトリに直接接続するときには、このユーザーをバインドDNとして選択することをお薦めします。

注意:

このコマンドでは、アイデンティティ・ストアに予約用のコンテナも作成します。

xelsysadmユーザーをアイデンティティ・ストアに追加して、そのユーザーを管理グループに割り当てるには、OIMHOST1で次のタスクを実行します。

1. 環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
IDM_HOMEをIDM_ORACLE_HOMEに設定します。

ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

2. 次の項目を含む、プロパティ・ファイルoim.propsを作成します。

IDSTORE_HOST : idstore.mycompany.com

IDSTORE_PORT : 389

IDSTORE_BINDDN : cn=orcladmin

IDSTORE_USERNAMEATTRIBUTE: cn

IDSTORE_LOGINATTRIBUTE: uid

IDSTORE_USERSEARCHBASE:cn=Users,dc=mycompany,dc=com

IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com

IDSTORE_SEARCHBASE: dc=mycompany,dc=com

POLICYSTORE_SHARES_IDSTORE: true

IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com

IDSTORE_OIMADMINUSER: oimadmin

IDSTORE_OIMADMINGROUP:OIMAdministrators

説明:

- IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。

- IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。

- IDSTORE_OIMADMINUSERは、Oracle Identity Managerコンソールにログインするために使用する、管理ユーザーの名前です。

- IDSTORE_OIMADMINGROUPは、Oracle Identity Manager管理ユーザーを保持するために作成するグループの名前です。

- IDSTORE_USERSEARCHBASEは、ユーザーを配置するアイデンティティ・ストアの場所です。

- IDSTORE_GROUPSEARCHBASEは、グループを配置するアイデンティティ・ストアの場所です。

- IDSTORE_SYSTEMIDBASEは、Oracle Identity Managerリコンシリエーション・ユーザーを配置するディレクトリの場所です。

- POLICYSTORE_SHARES_IDSTOREは、ポリシー・ストアとアイデンティティ・ストアが同じディレクトリに存在する場合にはtrueを設定します。そうでない場合は、falseを設定します。

3. idmConfigToolコマンドを使用してアイデンティティ・ストアを構成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
Linuxコマンドの構文:

idmConfigTool.sh -prepareIDStore mode=OIM input_file=configfile

Windowsコマンドの構文:

idmConfigTool.bat -prepareIDStore mode=OIM input_file=configfile

例:

idmConfigTool.sh -prepareIDStore mode=OIM input_file=oim.props

このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。また、システムは、そのアカウントに割り当てるパスワードの入力も要求します。

IDSTORE_OIMADMINUSER
oimadmin

oimadminは、Oracle Identity Manager構成の一部として作成したアカウントと同じ値を設定するようにお薦めします。

次に、コマンドの出力例を示します。

Enter ID Store Bind DN password :
*** Creation of oimadmin ***
Apr 5, 2011 4:58:51 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_user_template.ldif
Enter User Password for oimadmin:
Confirm User Password for oimadmin:
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_template.ldif
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_member_template.ldif
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_groups_acl_template.ldif
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_reserve_template.ldif
*** Creation of Xel Sys Admin User ***
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_user_template.ldif
Enter User Password for xelsysadm:
Confirm User Password for xelsysadm:
The tool has completed its operation. Details have been logged to /home/oracle/idmtools/oim.log

4. ログ・ファイルを確認して、エラーや警告を修正します。

Oracle Virtual Directoryでのアダプタの作成

Oracle Identity Managerは、Oracle Virtual Directoryを使用して外部LDAPストアに接続します。Oracle Identity ManagerがOracle Internet Directoryなどの外部LDAPストアに接続できるようにするには、ユーザー・アダプタと変更ログ・アダプタをOracle Virtual Directoryに作成する必要があります。次の手順に従って、アダプタを作成します。

注意:

Oracle Internet Directoryのみを実装する場合は、Oracle Virtual Directoryにアダプタを作成する必要はありません。

ユーザー・アダプタ

OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれにユーザー・アダプタを作成します。

Oracle Directory Services Managerを使用して、Oracle Virtual Directoryにユーザー・アダプタを作成する手順は次のとおりです。

1. ブラウザを開き、ODSMコンソール(http://admin.mycompany.com/odsm)を表示します。

注意:

Oracle Directory Services Managerは、図8-17には記載されていませんが、Oracle Internet DirectoryとOracle Virtual Directoryを管理するために必要です。環境にOracle Directory Services Managerが存在していることを想定しています。

2. OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれへの接続がまだ存在していない場合は、作成します。

3. 適切な接続エントリを使用して、各Oracle Virtual Directoryインスタンスに接続します。

4. ホームページで、「アダプタ」タブをクリックします。

5. アダプタ・ウィンドウの上部にある「アダプタの作成」をクリックして、「新規アダプタ・ウィザード」を起動します。

6. 「新規アダプタ・ウィザード」で次のパラメータを指定して、新しいアダプタを作成します。

注意:

前にユーザー・アダプタを作成した場合は、アダプタを作成する手順をスキップし、アダプタを編集する手順に従います。

画面

フィールド

値/手順

タイプ

アダプタ・タイプ

LDAP

アダプタ名

ユーザー・アダプタ

アダプタ・テンプレート

User_OID

接続

DNS設定を使用

いいえ

ホスト

oid.mycompany.com

ポート

389

サーバー・プロキシ・バインドDN

cn=oimadmin,cn=systemids,dc=mycompany,dc=com

プロキシ・パスワード

oimadminのパスワード。これは、「Oracle Identity Manager用のディレクトリ・スキーマの拡張」で指定したパスワードと同じにします。

接続テスト

テストが正常に行われたことを確認します。

ネームスペース

リモート・ベース

dc=mycompany,dc=com

マップされたネームスペース

dc=mycompany,dc=com

概要

概要に誤りがないことを確認し、「終了」をクリックします。

7. ユーザー・アダプタを次のように編集します。

1. OIMユーザー・アダプタを選択します。

2. 「プラグイン」タブをクリックします。

3. 「ユーザー管理」プラグインをクリックし、プラグイン表で「編集」をクリックします。プラグインの編集ウィンドウが表示されます。

4. 「パラメータ」表で、次のようにパラメータ値を更新します。

パラメータ

値

directoryType

oid

pwdMaxFailure

10

oamEnabled

true

5. 「OK」をクリックします。

6. 「適用」をクリックします。

変更ログ・アダプタ

OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれに変更ログ・アダプタを作成します。次の手順に従い、Oracle Directory Services Managerを使用してOracle Virtual Directoryに変更ログ・アダプタを作成します。

1. ブラウザを開き、ODSMコンソール(http://admin.mycompany.com/odsm)を表示します。

2. OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれへの接続がまだ存在していない場合は、作成します。

3. 適切な接続エントリを使用して、Oracle Virtual Directoryインスタンスに接続します。

4. ホームページで、「アダプタ」タブをクリックします。

5. アダプタ・ウィンドウの上部にある「アダプタの作成」をクリックして、「新規アダプタ・ウィザード」を起動します。

6. 「新規アダプタ・ウィザード」で次のパラメータを指定して、新しいアダプタを作成します。

画面

フィールド

値/手順

タイプ

アダプタ・タイプ

LDAP

アダプタ名

OIM変更ログ・アダプタ

アダプタ・テンプレート

Changelog_OID

接続

DNS設定を使用

いいえ

ホスト

oid.mycompany.com

ポート

389

サーバー・プロキシ・バインドDN

cn=oimAdminUser,cn=systemids,dc=mycompany,dc=com

プロキシ・パスワード

oimadminのパスワード。これは、「Oracle Identity Manager用のディレクトリ・スキーマの拡張」で指定したパスワードと同じにします。

接続テスト

テストが正常に行われたことを確認します。

ネームスペース

リモート・ベース

cn=changelog

マップされたネームスペース

cn=changelog

概要

概要に間違いがないことを確認してから、「終了」をクリックします。

7. 変更アダプタを編集する手順は、次のとおりです。

1. OIM変更ログ・アダプタを選択します。

2. 「プラグイン」タブをクリックします。

3. 「デプロイ済プラグイン」表で、「変更ログ」プラグインをクリックし、プラグイン表で「編集」をクリックします。プラグインの編集ウィンドウが表示されます。

4. 「パラメータ」表で、パラメータ値を更新します。

5. 「OK」をクリックします。

6. 「適用」をクリックします。

変更ログ・アダプタを編集してプロパティを追加または変更し、それらが次の表に示す値に一致するようにします。mapObjectclass、modifierDNFilter、sizeLimit、およびtargetDNFilterプロパティをアダプタに追加する必要があります。

パラメータ

値

directoryType

oid

mapAttribute

targetGUID=orclguid

requiredAttribute

orclguid

modifierDNFilter

cn=oimadmin,cn=users,cn=OIM,cn=Products,cn=OracleContext

sizeLimit

1000

targetDNFilter

dc=mycompany,dc=com

調整が必要な検索ベース。この値は、OIMのインストール時に指定したLDAP SearchDNと同一である必要があります。

mapUserState

true

oamEnabled

true

Oracle Internet DirectoryとOracle Virtual Directoryの起動と停止

次のインスタンスを起動および停止します。

- OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンス。

- OIDHOST1とOIDHOST2上で実行されているOracle Internet Directoryインスタンス。

手順については、第8.14項「コンポーネントの起動および停止」を参照してください。

8.9.3.4.2 Oracle Identity Management構成ウィザードの実行

Oracle Identity ManagerおよびSOA管理対象サーバーを起動する前に、Oracle Identity Managerサーバー・インスタンスを構成しておく必要があります。これらの構成手順を実行する必要があるのは、一度のみ(たとえば、ドメインを最初に作成するとき)です。Oracle Identity Management構成ウィザードによって、OIMメタデータがデータベースにロードされ、インスタンスが構成されます。

続行する前に、次の条件を満たしていることを確認します。

- 管理サーバーが起動されて、実行中であること。

- 環境変数DOMAIN_HOMEおよびWL_HOMEが現在のシェル内で設定されていないこと。

Oracle Identity Management構成ウィザードは、Identity Management Oracleホームの下にあります。次のように入力します。

IAM_ORACLE_HOME/bin/config.sh

次の手順を実行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 構成するコンポーネント画面で、OIMサーバーを選択します。トポロジに必要な場合は、OIM Remote Managerを選択します。
「次へ」をクリックします。

3. 「データベース」画面で、次の値を指定します。

- 接続文字列: OIMデータベースの接続文字列。例:
oimdbhost1-vip.mycompany.com:1521:oimdb1^oimdbhost2-vip.mycompany.com:1521:oimdb2@oim.mycompany.com

- OIMスキーマ・ユーザー名: HA_OIM

- OIMスキーマ・パスワード: password

- MDSスキーマ・ユーザー名: HA_MDS

- MDSスキーマ・パスワード: password

「次へ」を選択します。

4. WebLogic管理サーバー画面で、WebLogic管理サーバーについて次の詳細を入力します。

- URL: WebLogic管理サーバーに接続するためのURL。例: t3://oimhost1.mycompany.com:7001

- ユーザー名: weblogic

- パスワード: weblogicユーザーのパスワード

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

5. OIMサーバー画面で、次の値を指定します。

- OIM管理者パスワード: OIM管理者のパスワード。これは、xelsysadmユーザーのパスワードです。このパスワードは、事前にidmconfigtoolで入力したパスワードと同じにします。

- パスワードの確認: パスワードの再入力·

- OIM HTTP URL: OIMサーバーのプロキシURL。これは、OIM用のOHSサーバーのフロントエンドに配置されているハードウェア・ロード・バランサのURLです。例: http://oiminternal.mycompany.com:80

- キーストア・パスワード: キー・ストア・パスワード。パスワードには、大文字と数字を含める必要があります。例: MyPassword1

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

6. 環境に必要な場合は、LDAP同期とOAM画面で、BI Publisherの構成を選択し、BI Publisher URLに値を指定します。環境においてBI Publisherに接続するためのURLを入力します。
LDAP同期の有効化を選択します。

メモ:

- OAMとのアイデンティティ管理の統合の有効化は選択しないでください。

- BI Publisherは、IDMDomainの一部ではありません。BI Publisherの高可用性の詳細は、第15.2項「Oracle Business Intelligence Publisherの高可用性」を参照してください。

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

7. 「LDAPサーバー」画面で、次のLDAPサーバーの詳細を指定します。

注意:

このリリースのOracle Identity Manager LDAPSyncモジュールは、Oracle Virtual Directoryを介したOracle Internet Directoryへの接続のみをサポートしています。

この手順および次の手順のLDAPサーバーとは、Oracle Virtual Directoryのことを指します。

- ディレクトリ・サーバー・タイプ: ディレクトリ・サーバーのタイプです。OID、ACTIVE_DIRECTORY、IPLANETまたはOVDを選択します。デフォルトはOIDです。

- ディレクトリ・サーバーID: ディレクトリ・サーバーのIDです。

- サーバーURL: LDAPサーバーにアクセスするためのURLです。例: Oracle Virtual Directory Serverを使用する場合はldap://ovd.mycompany.com:389、Oracle Internet Directoryを使用する場合はldap://oid.mycompany.com:389。

- サーバーのユーザー: サーバーに接続するためのユーザー名前。例: cn=orcladmin·

- サーバー・パスワード: LDAPサーバーに接続するためのパスワード。

- サーバー検索DN: 検索DN。例: dc=mycompany,dc=com

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

8. LDAPサーバー(続き)画面で、次のLDAPサーバー詳細を入力します。

- LDAPロール・コンテナ: ロール・コンテナ用DN。これは、OIMロールが格納されているコンテナです。例: cn=Groups,dc=mycompany,dc=com

- LDAPユーザー・コンテナ: ユーザー・コンテナ用DN。これは、OIMユーザーが格納されているコンテナです。例: cn=Users,dc=mycompany,dc=com·

- ユーザー予約コンテナ: ユーザー予約コンテナ用DN。

注意:

「Oracle Identity Manager用のユーザーとグループの作成」の手順のidmconfigtoolで作成したコンテナDN値と同じ値を使用してください。

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

9. Remote Manager画面で、次の値を指定します。

注意:

この画面は、ステップ2でRemote Managerユーティリティを選択した場合にのみ表示されます。

- サービス名: HA_RManager

- RMIレジストリ・ポート: 12345

- リスニング・ポート(SSL): 12346

10. 「構成サマリー」画面で、サマリー情報を確認します。
「構成」をクリックし、Oracle Identity Managerインスタンスを構成します。

11. 「構成の進行状況」画面で構成が正常に完了したら、「次へ」をクリックします。

12. 「構成が完了しました」画面で、構成されたOracle Identity Managerインスタンスの詳細を表示します。
「終了」をクリックして、構成アシスタントを終了します。

13. 第8.14項「コンポーネントの起動および停止」の説明に従い、WebLogic管理サーバーを停止します。

14. 第8.14項「コンポーネントの起動および停止」の説明に従い、WebLogic管理サーバーを起動します。

8.9.3.5 管理対象サーバーに対する構成後の手順

この項では、管理対象サーバーの構成後の手順について説明します。

- 第8.9.3.5.1項「OIMHOST1でのWLS_SOA1およびWLS_OIM1管理対象サーバーの起動」

- 第8.9.3.5.2項「CoherenceクラスタのためのCoherenceの構成の更新」

8.9.3.5.1 OIMHOST1でのWLS_SOA1およびWLS_OIM1管理対象サーバーの起動

次の手順に従い、OIMHOST1上のWLS_SOA1およびWLS_OIM1管理対象サーバーを起動します。

1. OIMHOST1上のWebLogic管理サーバーを停止します。WebLogic管理コンソールを使用して、管理サーバーを停止します。

2. $DOMAIN_HOME/binディレクトリの下にあるstartWebLogic.shスクリプトを使用して、OIMHOST1上のWebLogic管理サーバーを起動します。例:

/u01/app/oracle/admin/OIM/bin/startWebLogic.sh > /tmp/admin.out 2>1&

3. WebLogic管理コンソールを表示して、WebLogic管理サーバーが正常に起動されたことを確認します。

4. WebLogic管理コンソールを使用して、WLS_SOA1管理対象サーバーを起動します。

5. WebLogic管理コンソールを使用して、WLS_OIM1管理対象サーバーを起動します。

8.9.3.5.2 CoherenceクラスタのためのCoherenceの構成の更新

次の手順に従い、SOA管理対象サーバーのCoherence構成を更新します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。

5. 「サーバーの起動」タブをクリックします。

6. 「引数」フィールドで、WLS_SOA1とWLS_SOA2について次のように入力します。
WLS_SOA1について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1

WLS_SOA2について、改行を入れず、1行で次のように入力します。

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1

7. 「保存」をクリックして、変更をアクティブ化します。

8. この変更を適用するには、SOAサーバーを再起動する必要があります。

8.9.3.6 OIMHOST1でのOracle Identity Managerインスタンスの検証

Webブラウザを使用してOracle Identity Managerコンソールを起動することによって、OIMHOST1上のOracle Identity Managerサーバー・インスタンスを検証します。

Oracle Identity ManagerコンソールのURLは、次のとおりです。

http://oimvhn1.mycompany.com:14000/oim

xelsysadmパスワードを使用してログインします。

8.9.3.7 OIMHOST2へのOracle Identity Managerの伝播

OIMHOST1で構成を完了したら、その構成をOIMHOST2に伝播できます。これを行うには、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。

次の手順に従い、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。

1. OIMHOST1上で、MW_HOME/oracle_common/common/binディレクトリにあるpackユーティリティを呼び出します。

pack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
template =/u01/app/oracle/admin/templates/oim_domain.jar -
template_name="OIM Domain" -managed=true

2. 前の手順で作成したoim_domain.jarファイルは、次のディレクトリにあります。

/u01/app/oracle/admin/templates

このoim_domain.jarファイルをOIMHOST1からOIMHOST2上の一時ディレクトリにコピーします。

3. OIMHOST2上で、MW_HOME/oracle_common/common/binディレクトリにあるunpackユーティリティを呼び出し、その一時ディレクトリにあるoim_domain.jarファイルの場所を指定します。

unpack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
template=/tmp/oim_domain.jar

8.9.3.8 OIMHOST2におけるインストール後の手順

この項では、OIMHOST2で実行するインストール後の手順について説明します。これらの項目が含まれます。

- 第8.9.3.8.1項「OIMHOST2でのノード・マネージャの更新」

- 第8.9.3.8.2項「OIMHOST2でのノード・マネージャの起動」

- 第8.9.3.8.3項「OIMHOST2でのWLS_SOA2およびWLS_OIM2管理対象サーバーの起動」

8.9.3.8.1 OIMHOST2でのノード・マネージャの更新

WebLogic管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャでStartScriptEnabledプロパティがtrueに設定されていることが必要です。

これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。

MW_HOME/oracle_common/common/bin

8.9.3.8.2 OIMHOST2でのノード・マネージャの起動

次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST2上のノード・マネージャを起動します。

MW_HOME/wlserver_10.3/server/bin

8.9.3.8.3 OIMHOST2でのWLS_SOA2およびWLS_OIM2管理対象サーバーの起動

次の手順に従い、OIMHOST2上のWLS_SOA2およびWLS_OIM2管理対象サーバーを起動します。

1. WebLogic管理コンソールを表示して、WebLogic管理サーバーが正常に起動されたことを確認します。

2. WebLogic管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。

3. WebLogic管理コンソールを使用して、WLS_OIM2管理対象サーバーを起動します。WLS_OIM2管理対象サーバーを起動する前に、WLS_SOA2管理対象サーバーを起動してください。

8.9.3.9 OIMHOST2でのOracle Identity Managerインスタンスの検証

Webブラウザを使用してOracle Identity Managerコンソールを起動することによって、OIMHOST2上のOracle Identity Managerサーバー・インスタンスを検証します。

Oracle Identity ManagerコンソールのURLは、次のとおりです。

http://oimvhn2.mycompany.com:14000/oim

xelsysadmパスワードを使用してログインします。

8.9.3.10 LDAP構成ポストセットアップ・スクリプトを使用したOracle Internet Directoryの構成

注意:

この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managerと統合されているOracle Identity Managerインストールでのみ必要です。

LDAP同期オプションの有効化や、Oracle Access Managerとの統合を計画していない場合は、この項をスキップできます。

Oracle Identity Manager LDAP構成ポストセットアップ・スクリプトは、Oracle Internet Directoryからの最後の変更番号でOracle Identity Manager LDAP同期スケジュール済ジョブを更新します。LDAP構成ポストセットアップ・スクリプトは、IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあります。スクリプトを実行する手順は、次のとおりです。

1. wlfullclient.jarファイルが、第8.9.3.1項「Oracle Identity Managerの構成のための前提条件」の説明に従って作成されていることを確認します。

2. IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあるldapconfig.propsファイルを編集し、次の値を設定します。

- OIMProviderURL: t3://oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000

- OIDURL: ldap://oid.mycompany.com:389

- OIDAdminUsername: cn=orcladmin

- OIDSearchBase: dc=mycompany,dc=com

- UserContainerName: cn=Users

- RoleContainerName: cn=Groups

- ReservationContainerName: cn=Reserve

3. ファイルを保存します。

4. WL_HOMEおよびJAVA_HOME環境変数を設定します。

5. LDAPConfigPostSetup.shを実行します。このスクリプトでは、OID管理パスワードとOIM管理パスワードの入力が求められます。例:

Prompt> ./LDAPConfigPostSetup.sh
[Enter OID admin password: ]
[Enter OIM admin password: ]

ここで、OID admin passwordは、Oracle Internet Directoryの管理用の管理アカウントのパスワード、OIM admin passwordは、Oracle Identity ManagerがLDAP同期を必要とするアクションで使用するためにLDAPリポジトリ内に作成される管理LDAPアカウントのパスワードです。

注意:

xelsysadmは、OIMのトップレベルの管理者であり、OIMの管理パスワードになります。

8.9.3.11 OIMおよびSOA管理対象サーバーに対するサーバーの移行の構成

この高可用性トポロジでは、管理対象サーバーWLS_OIM1、WLS_SOA1、WLS_OIM2、WLS_SOA2に対してサーバー移行を構成することをお薦めします。

- OIMHOST1上のWLS_OIM1およびWLS_SOA1管理対象サーバーは、OIMHOST1で障害が発生した場合に、OIMHOST2で自動的に再起動するように構成されます。

- OIMHOST2上のWLS_OIM2およびWLS_SOA2管理対象サーバーは、OIMHOST2で障害が発生した場合に、OIMHOST1で自動的に再起動するように構成されます。

このような構成では、WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2サーバーは、WebLogicサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。

次の手順を実行すると、WLS_OIM1、WLS_SOA1、WLS_OIM2、およびWLS_SOA2管理対象サーバーのサーバー移行を行うことができ、これにより、サーバーまたはプロセスの障害時に、管理対象サーバーは別のノードにフェイルオーバーできます。

- ステップ1: サーバー移行leasing表のユーザーと表領域を設定する

- ステップ2: Oracle WebLogic管理コンソールを使用してマルチ・データ・ソースを作成する

- ステップ3: ノード・マネージャのプロパティ・ファイルを編集する

- ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する

- ステップ5: サーバー移行ターゲットを構成する

- ステップ6: サーバー移行をテストする

8.9.3.11.1 サーバー移行leasing表のユーザーおよび表領域の設定

最初の手順では、サーバー移行leasing表のユーザーと表領域を設定します。

注意:

同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。この場合、データベース・リース用にデータ・ソースおよびマルチ・データ・ソースを再作成する必要はありませんが、これらをサーバー移行用に構成しているクラスタにターゲット指定しなおす必要があります。

1. leasingという名前の表領域を作成します。たとえば、ユーザーsysdbaでSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;

2. ユーザーleasingを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by welcome1;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

3. leasing.ddlスクリプトを使用してleasing表を作成します。

1. WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。

2. データベースにleasingユーザーとして接続します。

3. SQL*Plusでleasing.ddlスクリプトを実行します。

SQL> @Copy_Location/leasing.ddl;

8.9.3.11.2 Oracle WebLogic管理コンソールを使用したマルチ・データ・ソースの作成

マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。

- このデータ・ソースが非XAデータ・ソースであることを確認します。

- マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。

- Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。

- データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。

- これらのデータ・ソースをクラスタにターゲット指定します。

- データ・ソースの接続プールの初期容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」、「接続プール」タブの順にクリックし、「初期容量」フィールドに0(ゼロ)を入力します。

マルチ・データ・ソースの作成

マルチ・データ・ソースを作成する手順は、次のとおりです。

1. 管理者の資格証明を使用して、Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「サービス」ノードを開き、次に、「データ・ソース」ノードを開きます。

3. 「チェンジ・センター」で「ロックして編集」をクリックします。

4. 「新規」をクリックしてから、「マルチ・データ・ソース」をクリックします。

5. 名前として、leasingと入力します。

6. JNDI名として、jdbc/leasingと入力します。

7. アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。「次」をクリックします。

8. ターゲット・クラスタを選択します。「次」をクリックします。

9. 「非XAドライバ」(デフォルト)を選択します。「次へ」をクリックします。

10. 「新しいデータ・ソースの作成」をクリックします。

11. 名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。

注意:

leasing表のマルチ・データ・ソースを作成する場合は、名前を<MultiDS>-rac0や<MultiDS>-rac1などの形式で入力します。

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

13. 「グローバル・トランザクションのサポート」の選択を解除します。「次へ」をクリックします。

14. leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次」をクリックします。

15. 「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。

注意:

作成するデータ・ソースすべての作成を完了するまで、「終了」をクリックしないでください。作成したデータ・ソースが表示されない場合は、「終了」をクリックするのが早すぎたことを示しています。「終了」をクリックすると、データ・ソースをターゲット指定する画面が管理コンソールに表示されなくなります。

16. データ・ソースをクラスタにターゲット指定します。

17. データ・ソースを選択して、右の画面に追加します。

18. Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。

19. 2つ目のデータ・ソースをマルチ・データ・ソースに追加します。

20. 保存して、「変更のアクティブ化」をクリックします。

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

nodemanager.propertiesファイルを編集して、サーバー移行を構成するノードごとに次のプロパティを追加する必要があります。

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

- Interface: 浮動IPのインタフェース名(eth0など)を指定します。

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

注意:

Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: Interface="Local Area Connection"

- NetMask: 浮動IPのインタフェースのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります(255.255.255.0は一例です)。実際の値は、ネットワークにより異なります。

- UseMACBroadcast: ARPパケットの送信時にノードのMACアドレスを使用するかどうか、つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力で、次のようなエントリが表示されることを確認します。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:

サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合、次の手順は必要ありません。

1. nodemanager.propertiesファイルで、StartScriptEnabledプロパティをtrueに設定します。

2. WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、OIMHOST1とOIMHOST2でノード・マネージャを起動します。

注意:

共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個々のパラメータを指定します。たとえば、HOSTnで異なるインタフェース(eth3)を使用するには、Interface環境変数をHOSTn> export JAVA_OPTIONS=-DInterface=eth3のように使用して、この変数がシェル内で設定された後にノード・マネージャを起動します。

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

サーバー移行を構成するノードごとにwlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は、次のとおりです。

注意:

Windowsでは、このスクリプトはwlsifconfig.cmdであり、管理者権限を持つユーザーがこれを実行できます。

1. PATH環境変数に次のファイルが含まれていることを確認します。

表8-9 PATH環境変数に必要なファイル

ファイル

格納されているディレクトリ

wlsifconfig.sh

DOMAIN_HOME/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

WL_HOME/common

2. wlsifconfig.shスクリプトに対するsudo構成権限を付与します。

- パスワード・プロンプトを使用しないで機能するsudoを構成します。

- セキュリティ上の理由から、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定することをお薦めします。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。

- WebLogicユーザー(oracle)に、パスワードによる制限なしのsudo権限を付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

- WebLogicユーザーがこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。

oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

注意:

この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。

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

まず、すべての使用可能なノードをクラスタのメンバーに割り当て、次に、サーバー移行用に構成された各サーバーに候補となるマシン(適切な順序で)を指定します。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。

3. 「名前」列で、移行を構成するクラスタをクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。

8. 「保存」をクリックします。

9. 「変更のアクティブ化」をクリックします。

10. サーバー移行の候補マシンを設定します。このタスクは、次の手順に従って、すべての管理対象サーバーについて実行する必要があります。

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

ヒント:

「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックして、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動し、サーバーが実行されているマシンを表示します。サーバーが自動的に移行される場合、これは実際の構成とは異なります。

2. 移行を構成するサーバーを選択します。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。

5. 「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

6. 「保存」をクリックしてから、「変更のアクティブ化」をクリックします。

7. 追加の管理対象サーバーに対して、前述の手順を繰り返します。

8. 管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。

8.9.3.11.6 サーバー移行のテスト

サーバー移行が適切に機能していることを確認する手順は次のとおりです。

OIMHOST1から次の処理を実行します。

1. WLS_OIM1管理対象サーバーを停止します。これを行うには、このコマンドを実行します:

OIMHOST1> kill -9 pid

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

OIMHOST1> ps -ef | grep WLS_OIM1

2. ノード・マネージャのコンソールを確認します。WLS_OIM1の浮動IPが無効になっていることを示すメッセージが表示されることを確認します。

3. ノード・マネージャがWLS_OIM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

OIMHOST2から次の処理を実行します。

1. ローカルのノード・マネージャのコンソールを確認します。OIMHOST1でWLS_OIM1の再起動が最後に試行されてから30秒経過した後、OIMHOST2のノード・マネージャによって、WLS_OIM1の浮動IPが有効化されていること、およびこのノードでサーバーが再起動されていることが表示されます。

2. 同じIPのsoa-infraコンソールにアクセスします。

前述の手順に従い、WLS_OIM2、WLS_SOA1、およびWLS_SOA2管理対象サーバーのサーバー移行をテストします。

表8-10は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。

表8-10 WLS_OIM1、WLS_OIM2、WLS_SOA1、WLS_SOA2サーバー移行

管理対象サーバー

移行元

移行先

WLS_OIM1

OIMHOST1

OIMHOST2

WLS_OIM2

OIMHOST2

OIMHOST1

WLS_SOA1

OIMHOST1

OIMHOST2

WLS_SOA2

OIMHOST2

OIMHOST1

管理コンソールからの検証

管理コンソールで移行を検証することもできます。

1. 管理者の資格証明を使用して、Oracle WebLogic Server管理コンソール(http://oimhost1.mycompany.com:7001/console)にログインします。

2. 左側のコンソールで、「ドメイン」をクリックします。

3. 「監視」タブ→「移行」サブタブをクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

8.9.3.12 共有JMS永続ストアの構成

OIMHOST1とOIMHOST2の両方から参照できる共有ディレクトリに、すべての永続ストアの場所を構成します。JMSメッセージは、各サーバーのローカル・ファイル・システムのファイル・システムで永続化されているため、WebLogicサーバー移行のためにはJMS永続ストア用の共有記憶域が必要です。共有記憶域がない場合、移行先サーバーからは保留中のJMSメッセージにアクセスできなくなります。

注意:

JMSメッセージ、トランザクション・ログおよびファイル・ストアでのロックの解放の詳細は、「NFSでのファイル・ストアの使用に関する考慮事項」を参照してください。

共有のベース・ディレクトリを使用するように、すべての永続ストアを変更する手順は、次のとおりです。

1. 管理者の資格証明を使用して、Oracle WebLogic Server管理コンソール(http://oimhost1.mycompany.com:7001/console)にログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアの概要」ページが表示されます。

3. 表BPM、SOA、OIMおよびUMSの「名前」列から、永続ストアのハイパーリンクを選択します。その永続ストアの「設定」ページが表示されます。

4. 「構成」タブの「ディレクトリ」フィールドに、クラスタ内の他のサーバーで使用可能な永続記憶域ソリューション(NASやSANなど)の場所を入力します。この場所を指定することで、保留中のJMSメッセージを送信できます。

5. 場所は、次のディレクトリ構造に従う必要があります。

- WLS_SOA1およびWLS_SOA2サーバーについては、次のようなディレクトリ構造を使用します。

ORACLE_BASE/admin/domainName/soaClusterName/jms

- WLS_OIM1およびWLS_OIM2サーバーについては、次のようなディレクトリ構造を使用します。

ORACLE_BASE/admin/domainName/oimClusterName/jms

注意:

WLS_OIM1およびWLS_OIM2サーバーは、このディレクトリにアクセスできる必要があります。

WLS_SOA1およびWLS_SOA2 サーバーは、このディレクトリにアクセスできる必要があります。

このディレクトリは、サーバーを再起動する前に存在している必要があります。

6. 保存してアクティブ化をクリックします。

7. サーバーを再起動して、永続ストア内の変更を有効化します。

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

各Oracle WebLogic管理対象サーバーにはトランザクション・ログがあり、サーバーによって調整された、未完了の可能性のある、進行中のトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、クラスタ内のすべてのサーバーからアクセス可能な場所にトランザクション・ログを格納します。共有記憶域がないと、サーバーに障害が発生したときにクラスタ内の他のサーバーがトランザクション・リカバリを実行できず、操作の再試行が必要になることがあります。

注意:

可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。

Oracle Identity ManagerおよびSOAサーバーのデフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. 管理者の資格証明を使用して、Oracle WebLogic Server管理コンソール(http://oimhost1.mycompany.com:7001/console)にログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。

3. 表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)を選択します。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。

4. 「サービス」タブをクリックします。

5. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようにする必要があります。

- WLS_SOA1およびWLS_SOA2サーバーについては、次のようなディレクトリ構造を使用します。

ORACLE_BASE/admin/domainName/soaClusterName/tlogs

- WLS_OIM1およびWLS_OIM2サーバーについては、次のようなディレクトリ構造を使用します。

ORACLE_BASE/admin/domainName/oimClusterName/tlogs

6. 「保存」をクリックします。

注意:

トランザクション回復サービスの移行機能を有効化するには、クラスタ内の管理対象サーバーで利用可能な永続記憶域ソリューション上の場所を指定します。WLS_SOA1、WLS_SOA2、WLS_OIM1、およびWLS_OIM2は、このディレクトリにアクセスできる必要があります。

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

WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールする手順は、第8.5.3.5.1項「Web Tier用のOracle HTTP Serverのインストール」を参照してください。

8.9.3.15 Web Tierと連携するためのOracle Identity Managerの構成

この項では、Oracle Web Tierと連携するためのOracle Identity Managerの構成手順について説明します。

8.9.3.15.1 前提条件

次のタスクが実行済であることを確認します。

1. Oracle Web TierがWEBHOST1およびWEBHOST2にインストール済であること。

2. Oracle Identity ManagerがOIMHOST1およびOIMHOST2にインストールされ、構成済であること。

3. ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(sso.mycompany.com)で構成済であること。

4. ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(oiminternal.mycompany.com)で構成済であること。

5. ロード・バランサのVIPの構成の詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。

8.9.3.15.2 OIMおよびSOA管理対象サーバーのフロントエンドに使用できるようにするためのOracle HTTP Serverの構成

1. WEBHOST1およびWEBHOST2上の各Webサーバーに対して、ディレクトリORACLE_INSTANCE/config/OHS/component/moduleconfにoim.confというファイルを作成します。このファイルは、次の情報を含む必要があります。

# oim admin console(idmshell based)
<Location /admin>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# oim self and advanced admin webapp consoles(canonic webapp)

<Location /oim>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
<Location /sodcheck>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.mycompany.com:8001,oimvhn2.mycompany.com:8001
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Callback webservice for SOA. SOA calls this when a request is approved/rejected
# Provide the SOA Managed Server Port
<Location /workflowservice>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# xlWebApp - Legacy 9.x webapp (struts based)
<Location /xlWebApp>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# Nexaweb WebApp - used for workflow designer and DM
<Location /Nexaweb>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# used for FA Callback service.
<Location /callbackResponseService>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# spml xsd profile
<Location /spml-xsd>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /HTTPClnt>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

2. ORACLE_INSTANCE/config/OHS/component/moduleconfにvirtual_hosts.confというファイルを作成します。このファイルは、次の情報を含む必要があります。

NameVirtualHost *:7777
<VirtualHost *:7777>

ServerName http://sso.mycompany.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:7777>
ServerName http://oiminternal.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

3. このファイルをWEBHOST1とWEBHOST2の両方に保存します。

4. 第8.14項「コンポーネントの起動および停止」の説明に従い、WEBHOST1およびWEBHOST2上のOracle HTTP Serverインスタンスを停止および起動します。

8.9.3.16 Oracle HTTP Serverの構成の検証

Oracle HTTP Serverが適切に構成されていることを検証する手順は次のとおりです。

1. Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。

http://sso.mycompany.com:7777/oim

Oracle Identity Managerコンソール・ログイン・ページが表示されます。

2. xelsysadmユーザーの資格証明を使用してOracle Identity Managerコンソールにログインします。

8.9.3.17 Oracle Identity Managerのフェイルオーバーおよび予想される動作

高可用性環境では、WebLogicノード・マネージャはOracle WebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。

高可用性環境では、ハードウェア・ロード・バランサを使用して、複数のOracle Identity Managerインスタンス間のリクエストをロード・バランシングします。Oracle Identity Managerインスタンスのいずれかに障害が発生した場合は、ロード・バランサによって障害が検出され、障害が発生していないインスタンスにリクエストがルーティングされます。

高可用性環境では、状態情報と構成情報は、クラスタ内のすべてのメンバーが共有するデータベースに格納されます。

状態情報が共有データベースに格納されており、クラスタ内のすべてのメンバーがこの情報を使用できるため、障害が発生していないOracle Identity Managerインスタンスでは、障害が発生したインスタンスで開始された未完了のトランザクションの処理をシームレスに継続します。

Oracle Identity Managerインスタンスのいずれかで障害が発生すると、そのデータベースとLDAP接続は解放されます。アクティブ/アクティブ・デプロイメント内にある障害が発生していないインスタンスは、独自の接続を行い、障害が発生したインスタンス上にある未完了のトランザクションの処理を継続します。

Oracle Identity Managerを高可用性構成にデプロイする場合は、次のことに注意してください。

- Oracle Identity ManagerはOracle RACデータベースにデプロイできますが、Oracle RACのフェイルオーバーは、このリリースではOracle Identity Managerに対して透過的ではありません。Oracle RACのフェイルオーバーが発生すると、エンド・ユーザーは、各自のリクエストを再送信する必要がある場合があります。

- Oracle Identity Managerは常に、SOAクラスタ内で少なくとも1つのノードが使用可能であることを必要とします。SOAクラスタが使用可能でない場合、エンド・ユーザーのリクエストは失敗します。Oracle Identity Managerノードは、失敗したSOA呼出しに対して再試行しません。そのため、SOA呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。

8.9.3.18 Oracle Identity Managerの高可用性のトラブルシューティング

アクティブ/アクティブOracle Identity Manager構成において、Oracle Identity Managerでユーザーを作成していて(Oracle Identity Managerにログインし、「管理」タブをクリックして、「ユーザーの作成」リンクをクリックし、フィールドに必要な情報を入力してから、「保存」をクリックします)、そのリクエストを処理中のOracle Identity Managerサーバーに障害が発生した場合、Oracle Identity Managerログ・ファイルに次のようなResourceConnectionValidationxceptionが記述されることがあります。

[2010-06-14T15:14:48.738-07:00] [oim_server2] [ERROR] [] [XELLERATE.SERVER]
[tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: xelsysadm] [ecid:
004YGJGmYrtEkJV6u3M6UH00073A0005EI,0:1] [APP: oim#11.1.1.3.0] [dcid:
12eb0f9c6e8796f4:-785b18b3:12938857792:-7ffd-0000000000000037] [URI:
/admin/faces/pages/Admin.jspx] Class/Method:
PooledResourceConnection/heartbeat encounter some problems: Operation timed
out[[
com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception: Operation
timed out
at
oracle.iam.ldapsync.impl.repository.LDAPConnection.heartbeat(LDAPConnection.ja
va:162)
at
com.oracle.oim.gcp.ucp.PooledResourceConnection.heartbeat(PooledResourceConnec
tion.java:52)
.
.
.

この例外を受け取った場合でも、ユーザーは正常に作成されます。

8.9.3.19 Oracle Identity Managerトポロジのスケール・アップとスケール・アウト

Oracle Identity Manager高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。

8.9.3.19.1 Oracle Identity Managerのスケール・アップ

この場合は、SOAコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードには、既存の管理対象サーバーのMiddlewareホーム、Oracleホーム(SOA)およびドメイン・ディレクトリが含まれます。

新しいWLS_OIMおよびWLS_SOAサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。OIMおよびSOAのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。

トポロジをスケール・アップするには、次の手順を実行します。

1. 管理コンソールを使用して、WLS_OIM1またはWLS_SOA1のクローンを新しい管理対象サーバーに作成します。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。

1. 管理コンソールから「環境」→「サーバー」を選択します。

2. クローンを作成する管理対象サーバー(WLS_OIM1やWLS_SOA1など)を選択します。

3. 「クローンの作成」を選択します。

4. 新しい管理対象サーバーにWLS_OIMnまたはWLS_SOAnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。

この後の手順では、すでにWLS_SOA1およびWLS_OIM1を実行しているOIMHOST1に新しいサーバーを追加することを想定しています。

2. リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPを割り当てます。このサーバーに対して推奨されている、サーバー移行の使用を計画している場合は、VIP(浮動IPともいう)を割り当てて他のノードに移動できるようにします。VIPは、すでに実行されている管理対象サーバーで使用されているものとは別のものである必要があります。

3. 新しい管理対象サーバーにSOA、OIM、BPMおよびUMSのJMSサーバーを作成します。

1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_nのような名前を付けます。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

2. SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n)。このJMSサーバーに対して、SOAJMSFileStore_nを使用します。SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

3. 新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。

4. UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。このJMSサーバーに対して、UMSJMSFileStore_nを使用します。UMSJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

5. 新しいOIMJMSServerの新しい永続ストアを作成します(たとえば、OIMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいOIM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。

6. OIMの新しいJMSサーバーを作成します(たとえば、OIMJMSServer_n)。このJMSサーバーに対して、OIMJMSFileStore_nを使用します。OIMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。

7. 新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。

8. サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。

9. 新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUCMJMSServerXXXXXXという形式のランダム名です。

10. サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

11. 新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。

12. サブデプロイメント「OIMMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。

4. 第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、コンポジットをデプロイする場合のOracle Coherenceを構成します。

注意:

サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例:

Dtangosol.coherence.localhost=SOAHOST1VHNn

5. 新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。

6. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。表の「名前」列で「WLS_SOAn」を選択します。

4. 「SSL」タブをクリックします。「詳細設定」をクリックします。

5. 「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。

7. 管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーを停止します。

2. 新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。

3. 新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。

8. 新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

これはスケール・アップ操作であるため、ノード・マネージャ、サーバー移行に対して構成された環境および新しいSOA管理対象サーバーの浮動IPがあらかじめノードに用意されている必要があります。

サーバー移行を構成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左側のペインで、「環境」を開き、「サーバー」を選択します。

3. 移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。
たとえば、すでにWLS_SOA1が実行されているSOAHOST1上の新しい管理対象サーバーには、SOAHOST2を選択します。すでにWLS_SOA2が実行されているSOAHOST2上の新しい管理対象サーバーには、SOAHOST1を選択します。

移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

9. 新しく作成したWLS_OIMn管理対象サーバーに対してサーバー移行を構成するために、このリストの手順を繰り返します。

9. この新規サーバーのサーバー移行をテストするには、新規サーバーの追加先となったノードで、次の手順を実行します。

1. 管理対象サーバーWLS_SOAnを停止します。
そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを入力します。

2. ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

8.9.3.19.2 Oracle Identity Managerのスケール・アウト

トポロジのスケール・アウトでは、SOAで構成された新しい管理対象サーバーを新しいノードに追加します。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

- SOAで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。

- 新しいノードが、WebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやSOAバイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります)。

注意:

共有記憶域にインストールが存在しない場合は、第5.13項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」の説明に従って、新しいノードにWebLogic ServerとSOAをインストールする必要があります。

注意:

ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、user_home/bea/beahomelistファイルを編集します。次の手順を参照してください。

トポロジをスケール・アウトするには、次の手順を実行します。

1. 新しいノードで、SOAのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
SOAHOSTn>./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管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。このサーバーにWLS_SOAnという名前を付けます。nは番号です。

注意:

これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。

7. 新しい管理対象サーバーでその管理対象サーバーのリスニング・アドレスに使用するホスト名またはIPを割り当てます。
このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーのVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、既存の管理対象サーバーで使用されているものとは別のものである必要があります。

8. 新しい管理対象サーバーにSOA、OIM(該当する場合)およびUMSのJMSサーバーを作成します。

1. Oracle WebLogic Server管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_nのような名前を付けます。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_n

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

2. SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n)。このJMSサーバーに対して、SOAJMSFileStore_nを使用します。SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

3. 新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。

4. UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。このJMSサーバーに対して、UMSJMSFileStore_nを使用します。UMSJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

5. 新しいOIMJMSServerの新しい永続ストアを作成します(たとえば、OIMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいOIM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。明瞭さと独立性を保つため、次の手順に従って、個別の永続ストアを使用します。

6. OIMの新しいJMSサーバーを作成します(たとえば、OIMJMSServer_n)。このJMSサーバーに対して、OIMJMSFileStore_nを使用します。OIMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。

7. 新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。

8. サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。

9. 新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUCMJMSServerXXXXXXという形式のランダム名です。

10. サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

11. 新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。そのためには、「サービス」ノードを開いてから、「メッセージング」ノードを開きます。Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。

12. サブデプロイメント「OIMMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。

9. 次のようにpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true/
-domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをSOAHOSTnにコピーします。

SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/
ORACLE_BASE/product/fmw/soa/common/bin

次のようにSOAHOSTnでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。

SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/common/bin
SOAHOSTN> ./unpack.sh /
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar

10. 第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、コンポジットをデプロイする場合のOracle Coherenceを構成します。

注意:

サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例:

Dtangosol.coherence.localhost=SOAHOST1VHNn

11. 新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。

12. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

13. 新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。

SOAHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip

14. 管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーを停止します。

2. 新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。

3. 新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。

15. 新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャと、ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しいSOA管理対象サーバーの浮動IPが存在します。

次の手順を実行してサーバー移行を構成します。

1. 管理コンソールにログインします。

2. 左側のペインで、「環境」を開き、「サーバー」を選択します。

3. 移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。

注意:

新しいサーバーの移行ターゲットには、負荷が最小のマシンを指定します。このノードのリソースが追加の管理対象サーバーの持続に十分対応できるように、必須の容量計画を立てる必要があります。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

16. この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。

1. 管理対象サーバーWLS_SOAnを停止します。
そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは、ps -ef | grep WLS_SOAnを使用して確認できます。

2. ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは、この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

8.10 認可ポリシー・マネージャの高可用性

この項では、認可ポリシー・マネージャ11gの概要および認可ポリシー・マネージャの高可用性環境の設計とデプロイについて説明します。

高可用性アクティブ/パッシブ・コールド・フェイルオーバー・クラスタで認可ポリシー・マネージャを使用するには、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」のアクティブ/パッシブ・コールド・フェイルオーバー・クラスタでのWebLogicサーバーの設定手順に従います。

認可ポリシー・マネージャは、WebLogic管理サーバーJVMにデプロイされるため、高可用性アクティブ/アクティブ・デプロイメントでは使用されません。

認可ポリシー・マネージャは、アプリケーション・ポリシーを管理するためのグラフィカル・インタフェース・ツールです。

認可ポリシー・マネージャの対象ユーザーは、セキュリティ管理者です。このツールを使用することで、管理者はエンタープライズ・アプリケーション全体にわたるポリシーを表示および管理できます。管理者は、ドメイン内で実行されているすべてのアプリケーションを管理することも、アプリケーションのサブセットのみを管理することもできます。

認可ポリシー・マネージャは、次の条件が満たされていることを必要とします。

- ドメイン・ポリシー・ストアがLDAPベースであること。サポートされているポリシー・ストアはOracle Internet Directoryです。

- ドメイン・アイデンティティ・ストアがLDAPベースであること。サポートされているアイデンティティ・ストア・タイプは、Oracle Internet Directory、Oracle Virtual Directory、Oracle WebLogic Server組込みLDAP、Sun Java System Directory Serviceバージョン6.3、Active Directory 2003および2008、Novell eDirectory 8.8、およびOpenLDAP 2.2および2.4です。

- 2つの特別なデータ・ソース(mds-ApplicationMDSDBとapm-DBDS)を設定します。これらのデータ・ソースは、WebLogicコンソール(「JDBC」→「データ・ソース」の下)で構成できます。

認可ポリシー・マネージャの使用方法の詳細は、Oracle Fusion Middleware Authorization Policy Manager管理者ガイドを参照してください。

8.11 Oracle Identity Navigatorの高可用性

Oracle Identity Management Navigatorは、Oracle Identity Management製品のスタート地点として機能するよう設計されている管理ポータルです。これは、個々の製品コンソールに代わるものではありません。1つのサイトからOracle Identity Managementの各コンソールにアクセスできるようにするためのものです。Oracle Identity Management Navigatorの詳細は、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドを参照してください。

Oracle Identity Navigatorは、WebLogic管理サーバーJVMにデプロイされるため、高可用性アクティブ/アクティブ・デプロイメントでは使用されません。

高可用性アクティブ/パッシブ・コールド・フェイルオーバー・クラスタでOracle Identity Navigatorを使用するには、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」のアクティブ/パッシブ・コールド・フェイルオーバー・クラスタでのWebLogicサーバーの設定手順に従います。

8.12 Oracle Adaptive Access Managerの高可用性

この項では、Oracle Adaptive Access Managerの概要およびOracle Adaptive Access Managerの高可用性環境の設計とデプロイについて説明します。

Oracle Adaptive Access Managerは、プラットフォームのプレゼンテーション層、ビジネス・ロジック層、およびデータ層を分けた、J2EEベースの複数層デプロイメント・アーキテクチャに構築されています。層がこのように分離されているため、Oracle Adaptive Access Managerは、お客様のパフォーマンス要件に合せてすばやくスケールできます。このアーキテクチャでは、Java、XML、およびオブジェクト・テクノロジを組み合せた、最も柔軟なサポートされているクロス・プラットフォームJ2EEサービスを利用できます。Oracle Adaptive Access Managerは、このアーキテクチャによって、スケーラブルでフォルト・トレラントなソリューションとなっています。

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

- 第8.12.1項「Oracle Adaptive Access Managerコンポーネント・アーキテクチャ」

- 第8.12.2項「Oracle Adaptive Access Managerの高可用性の概要」

- 第8.12.3項「Oracle Adaptive Access Managerの高可用性の構成手順」

8.12.1 Oracle Adaptive Access Managerコンポーネント・アーキテクチャ

図8-18は、Oracle Adaptive Access Managerの単一インスタンスのアーキテクチャを示しています。

図8-18 Oracle Adaptive Access Managerの単一インスタンス・アーキテクチャ

「図8-18 Oracle Adaptive Access Managerの単一インスタンス・アーキテクチャ」の説明

図8-18に示すOracle Adaptive Access Managerの単一インスタンス・アーキテクチャでは、エンド・ユーザーは、カスタマWebアプリケーションにアクセスし、それがSOAPを使用してOAAM Serverアプリケーションおよびそのポリシーと通信します。かわりに、OAAMプロキシを設定して、エンド・ユーザーがそのマシンと通信し、それがHTTP(S)を使用してOAAM_Serverアプリケーションと通信することもできます。エンド・ユーザーは、認可された場合、カスタマWebアプリケーションにアクセスできます。OAAM_ADMINコンポーネントは、OAAM_SERVERアプリケーションの管理と構成のために使用されます。OAAM_Serverアプリケーションの管理と構成を担当する管理者は、Webブラウザを使用してOAAM_ADMINアプリケーションにアクセスします。ポリシーと構成情報の格納にはOracle RACデータベースが使用されます。

8.12.1.1 Oracle Adaptive Access Managerコンポーネントの特性

Oracle Adaptive Access Managerは、次の2つのコンポーネントで構成されています。

- OAAM_ADMIN: このコンポーネントは、OAAM_SERVERアプリケーションの管理と構成のために使用されます。このコンポーネントは、Oracle JAVA ADF FrameworkのIdentity Managementシェルを使用して開発されており、J2EEコンテナにWebアプリケーションとしてデプロイされます。これは、EARファイルとしてパッケージされています。

- OAAM_SERVER: このコンポーネントは、1つのWebアプリケーション内にOAAM AdminサブコンポーネントとOAAM Serverサブコンポーネントが含まれています。OAAM_SERVERコンポーネントはEARファイルとしてパッケージ化されており、Javaクラスに加えてサーブレットとJSPで構成されています。OAAM_SERVERのサブコンポーネントについては、次にレイヤー別に説明します。

- プレゼンテーション・レイヤー: 通常、JSP、サーブレットなどのサービスを提供するWebアプリケーション。プレゼンテーション・レイヤーは、厳密認証機能を提供します。これはビジネス・レイヤーによって提供されるインタフェース(SOAPまたはJavaネイティブ)を使用してそのサービスにアクセスします。

- ビジネス・ロジック・レイヤー: このレイヤーには、リスク分析エンジンを実装するコア・アプリケーション・ロジックが含まれています。このレイヤーは、プレゼンテーション・レイヤーのためのJavaおよびSOAPインタフェースを提供します。Javaインタフェースを使用する場合、ビジネス・ロジック・レイヤーとプレゼンテーション・レイヤーを1つのWebアプリケーションの一部とすることができます。SOAPインタフェースの場合は、これらのレイヤーは異なるアプリケーションとしてデプロイされます。

- データ・アクセス・レイヤー: サポートされているリレーショナル・データベースに接続するためのデータ・アクセス・コンポーネントが含まれています。Oracle Adaptive Access Managerは、リレーショナル・データベースにJavaオブジェクトを格納するための強力で柔軟なフレームワークを提供するOracle TopLinkを使用します。

次に示すコンポーネントも、Oracle Adaptive Access Manager 11gR1デプロイメントで使用できます。

- Fusion Middleware ControlおよびEnterprise Manager Grid Control: Oracle Adaptive Access Managerは、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。Oracle Adaptive Access Managerは、DMSおよびDiscovery Mbeanを使用してEnterprise Managerと統合します。Enterprise Managerは、コンポーネント・トレースの向上と、監査の構成のためにも使用されます。
Enterprise Managerは、ドメイン内の各管理対象サーバーのログ・ファイルの表示するため、およびトレースをデバッグ・レベル、トレース・レベル、および情報レベルに高めるためにも使用できます。

- データ・リポジトリ: Oracle Adaptive Access Managerは、RDBMSデータベースをそのデータ・ストアとして使用します。Oracle Adaptive Access Managerがサポートし、機能するデータベース・トポロジは、次のとおりです。

- Oracle Real Application Cluster

- Oracle Data Guard

- レプリケーション・ストリーム

- データベース・パーティション化

Oracle Adaptive Access Managerは、RCUを使用してデータベースにそのスキーマを作成します。

8.12.1.1.1 Oracle Adaptive Access Managerの状態情報

OAAM_Serverコンポーネントには、OAAM ServerサブコンポーネントとOAAM Adminサブコンポーネントが含まれています。

- OAAM Serverは、HTTPセッションに状態を格納するステートフル・アプリケーションです。

- OAAM Adminは、データベースにそのセッション情報を格納するステートフル・アプリケーションです。

OAAM_Adminコンポーネントは、ADFおよびアイデンティティ管理UIシェルベース・アプリケーションです。それは、ステートレス・アプリケーションであり、そのアプリケーションの状態は、ADFフレームワークによって保持されます。

8.12.1.1.2 Oracle Adaptive Access Managerランタイム・プロセス

Oracle Adaptive Access Manager管理コンソールを使用して次のランタイム・タスクを実行できます。

- カスタマ・ケア・アプリケーション・タスク

- ポリシー、グループ、およびプロパティを含むシステム構成タスク

- セッション・データ情報の表示

- システム統計ダッシュボードの表示

たとえば、次の管理フローを実行できます。

1. 最近のユーザー問合せ:

1. 最近のログインとセッションの詳細を表示します。

2. 問合せを実行します。

3. 「セッションの詳細」をクリックします。

4. ログアウトします。

2. 手動によるCSRとエージェント・エースの作成:

1. カスタマ・ケアをリセットするには、ログインします。

2. ケースを作成します。

3. カスタマをリセットします。

4. ログアウトします。

Oracle Adaptive Access Manager Serverを使用してランタイム処理も実行できます。

8.12.1.1.3 Oracle Adaptive Access Managerプロセスのライフサイクル

Oracle Adaptive Access Manager Serverでは、次のランタイム処理が実行されます。

1. Oracle Adaptive Access Managerが、デプロイされ、カスタマのアプリケーションと統合されています。

2. ユーザーがカスタマのアプリケーションにアクセスし、ユーザー資格証明を入力します。

3. OAAMで構成されたシステムとルールに基づき、次のように様々なログイン・フローがあります。
ユーザー登録: 登録フロー

1. フローR1: (新規ユーザーとして)ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録をスキップしてログアウトします。

2. フローR2: ログインし、パスワードを入力し、登録をスキップしてログアウトします。

3. フローR3: ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行してログアウトします。

4. フローR4: ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行して無効なアンサーを入力し、検証してログアウトします。

5. フローR5: (新規デバイスに新規ユーザーとして)ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行してログアウトします。

ログイン・フロー:

1. フローL1: ログインし、誤ったパスワードを入力します(「ログイン」画面)。

2. フローL2: ログインし、正しいパスワードを入力し、チャレンジオンが表示される場合は正しい答えを入力し、ログインします。

3. フローL3: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、正しい答えを入力し、ログインします。

4. フローL4: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、誤った答えを入力し、チャレンジオンが再表示され、正しい答えを入力し、ログインします。

5. フローL5: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、誤った答えを入力し、ログインがブロックされます。

6. フローL6: ログインし、正しいパスワードを入力し、ログインがブロックされます(「ログイン」画面)。

7. フローL7: ログインし、正しいパスワードを入力し、ログインします。

8. フローLNU1: (新規ユーザーとしてログイン)ログインし、正しいパスワードを入力し、ログインします。

9. フローLND1: (既存のユーザー)新しいデバイスでログインし、正しいパスワードを入力し、ログインします。

10. フローLNUD1: (新規ユーザー)新しいデバイスでログインし、正しいパスワードを入力し、ログインします。

セッション内トランザクション・フロー: ログインし、パスワードを入力し、トランザクションを作成し、トランザクションを更新し、ログアウトします。

4. OAAMは、次のデータ要素を追跡し、登録します。

1. ユーザー・ログイン

2. ユーザー名

3. デバイス(Cookie、ブラウザ・ヘッダー、提供されたフラッシュ・データ)

4. IPアドレス

5. トランザクション・データ

5. OAAMは、ログイン動作に基づいて適切なポリシーをトリガーします。

Oracle Adaptive Access Manager Serverと管理コンソールは、J2EEアプリケーションとして、WebLogic Serverから提供されるユーザー・インタフェースおよびコマンドライン・ツールを使用して起動できます。

Oracle Adaptive Access Manager Serverは、障害の検出のためにロード・バランサが使用できるヘルス・チェック・リクエスト(HTTPを介したpingリクエスト)をサポートしています。

Oracle Adaptive Access Managerは、サーバー・サイド・メトリック用(DMSを使用)にインスツルメント処理されており、この情報は管理コンソールに公開されます。DMSメトリック収集が有効化されている場合、エージェントおよびサーバー・コンポーネント・メトリックの監視は、コンポーネントの監視のかわりとして使用できます。さらに、Oracle Adaptive Access Managerは、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。

8.12.1.1.4 Oracle Adaptive Access Managerの構成アーティファクト

Oracle Adaptive Access Managerは、その構成情報をデータベースに格納します。これらの構成プロパティは、Oracle Adaptive Access Manager管理コンソールを使用して変更できます。

Oracle Adaptive Access Managerは、構成情報をファイル・システムや展開したEARファイルに格納することはありません。

8.12.1.1.5 Oracle Adaptive Access Managerのデプロイメント・アーティファクト

Oracle Adaptive Access Managerは、デプロイメント・ステージングのnostageモードをサポートします。つまり、すべてのデプロイメント・ファイルはローカルです。

8.12.1.1.6 Oracle Adaptive Access Managerの外部依存性

Oracle Adaptive Access Managerは、RDBMSデータベースに外部依存し、それに構成情報を格納します。

Oracle Adaptive Access Managerは、Oracle RACデータベースのためにWebLogic Serverマルチ・データ・ソースを使用します。

Oracle Adaptive Access Managerは、標準Oracle TopLinkオブジェクト・キャッシュ・メカニズムを使用します。

Oracle Adaptive Access Managerは、標準セッション・オブジェクト・シリアライズを使用して、オブジェクトの永続状態を保持します。

Oracle Adaptive Access Managerは、どのようなホスト名、IPアドレス、またはポートにも依存しません。コンテナ固有のポートまたはホスト名で機能します。

8.12.1.1.7 Oracle Adaptive Access Managerのログ・ファイルの場所

Oracle Adaptive Access Managerは、WebLogic Server上にデプロイされるJ2EEアプリケーションです。すべてのログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

8.12.2 Oracle Adaptive Access Managerの高可用性の概要

この項では、Oracle Adaptive Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。

8.12.2.1 Oracle Adaptive Access Managerの高可用性アーキテクチャ

図8-19は、Oracle Adaptive Access Managerの高可用性アーキテクチャを示しています。

図8-19 Oracle Adaptive Access Managerの高可用性アーキテクチャ

「図8-19 Oracle Adaptive Access Managerの高可用性アーキテクチャ」の説明

図8-19では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてからWeb層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohsが使用されてOAAMHOST1およびOAAMHOST2上のWebLogic管理対象サーバーにリクエストが転送されます。

OAAMHOST1とOAAMHOST2には、Oracle Adaptive Access Manager ServerアプリケーションとOracle Adaptive Access Manager Adminアプリケーションをホストする管理対象サーバーが含まれています。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。

WebLogic管理サーバーは、OAAMHOST1上で実行され、WebLogic管理コンソールとOracle Enterprise Manager Fusion Middleware Controlを含んでいます。管理サーバーは、OAAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAAMHOST1が使用不可になった場合に、管理サーバーをOAAMHOST2上で手動で起動できます。

ディレクトリ層で、仮想IP ovd.mycompany.comは、Oracle Virtual DirectoryリクエストをOVDHOST1とOVDHOST2にルーティングするように設定されます。OVDHOST1とOVDHOST2は、アクティブ/アクティブのOracle Virtual Directoryクラスタを構成します。仮想IP oid.mycompany.comは、Oracle Internet DirectoryリクエストをOIDHOST1とOIDHOST2にルーティングするように設定されます。OIDHOST1とOIDHOST2は、アクティブ/アクティブのOracle Internet Directoryクラスタを構成します。

Oracle RACデータベースは、データ層における高可用性を提供します。

図8-19は、OAAMの高可用性構成アーキテクチャを示しています。図では、ロード・バランサによって、WEBHOST1およびWEBHOST2上の2つのOracle HTTP Serverインスタンスを介してOAAMHOST1およびOAAMHOST2にリクエストがルーティングされます。OAAM管理サーバー・インスタンスおよびOAAM管理対象サーバー・インスタンスは、OAAMHOST1およびOAAMHOST2にインストールされ、これらのインストールは、OAAM Serverクラスタ(OAAM_Cluster)およびOAAM Adminクラスタ(OAAM_Admin_Cluster)として構成されます。OAAM ServerクラスタはOAAM Serverデータ・ソースを使用し、OAAM AdminクラスタはOAAM Adminデータ・ソースを使用して、Oracle RACデータベースと通信します。

図8-19に示すように、1つのWebLogic ServerドメインでサポートされるOracle Adaptive Access Manager ServerクラスタとOracle Adaptive Access Manager Administrationクラスタはそれぞれ1つです。さらに、Oracle Adaptive Access Manager関連のクラスタは、複数のWebLogic Serverドメインにわたることはできません。

単一インスタンスのOracle Adaptive Access Managerデプロイメントは、次の高可用性要件を満たします。

- ロード処理

- 外部接続管理と監視

- リカバリ

- フォルト包含

- フォルト診断

- Oracle Adaptive Access Manager AdminまたはServerのオフライン

複数インスタンスのOracle Adaptive Access Managerデプロイメントは、次の追加の高可用性要件を満たします。

- 冗長性

- クライアント接続のフェイルオーバー/継続性

- クライアントのロード・バランシング

- 状態管理

インバウンドHTTP接続の場合は、外部ロード・バランシング・ルーターの使用をお薦めします。

Webセッションは、Oracle Adaptive Access Manager管理コンソールおよびサーバーへの永続TCP接続を開きます。これには、TCP接続の早すぎる終了を回避するために、ロード・バランシング・ルーターとファイアウォール接続タイムアウトを十分大きい値にする必要があります。

8.12.2.1.1 クラスタの起動と停止

各Oracle Adaptive Access Manager管理コンソールおよびサーバー・インスタンスは、他のインスタンスのピアです。すべての初期化は、サーバーがリクエストを受信できるようになる前に行われることと、組込みのスロットル機能のために、サージ状態はOracle Adaptive Access Manager 11gR1アクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく正常に処理されます。

クラスタが停止した場合、新しいリクエストは拒否され、既存のリクエストはOracle Adaptive Access Manager管理コンソールおよびサーバー・アプリケーションが停止する前に完了できます。強制シャットダウンが行われた場合、Oracle Adaptive Access Manager 11gR1は、その強制シャットダウンによって破損または無効になったデータをリカバリします。

Oracle Adaptive Access Managerコンポーネントは、Pure J2EEアプリケーションであり、それ自体に起動および停止の機能はありません。かわりに、それらは、コンテナ固有の起動および停止機能に依存します。

Oracle Adaptive Access Managerコンポーネントは、WebLogic Server管理対象サーバー・ノードにデプロイされます。ノード・マネージャを使用してコンポーネントを再起動します。

8.12.2.1.2 クラスタワイドの構成変更

Oracle Adaptive Access Managerは、構成全体をデータベースに格納するため、構成変更のすべてのクラスタ・メンバーへの伝播は透過的です。すべてのOracle Adaptive Access Managerコンポーネントは、変更イベントを内部レイヤーから通知されて取得します。変更の原子性を確保するために、Oracle Adaptive Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。

Oracle Adaptive Access Managerの構成は、クラスタ内のすべてのインスタンスに適用されます。

Oracle Adaptive Access Manager管理コンソールおよびサーバー・インスタンスの追加および削除は、クラスタ内の他のOracle Adaptive Access Managerインスタンスに対して透過的です。

Oracle Adaptive Access Managerクラスタには、任意の数のインスタンスを含めることができます。1つのクラスタ当たりのインスタンス数に制限はありません。

オンライン・アプリケーション・デプロイメントによって問題が発生することはありません。

8.12.2.2 障害からの保護および予想される動作

次の機能が、Oracle Adaptive Access Managerの高可用性構成を障害から保護します。

- クラスタのセッションの状態は、メモリー内に保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。

- Oracle Adaptive Access Managerサーバーは、ハート・ビート・チェック(HTTPを介したpingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視し、アプリケーションが実行されていない場合は再起動することができます。Oracle Adaptive Access Managerサーバーを再起動しても、他の実行中のコンポーネントやクラスタ・メンバーには影響ありません。

- WebLogic Serverノードで障害が発生した場合、外部接続のフェイルオーバーは、構成、再試行のタイムアウトおよび再試行回数に基づいて行われます。

- ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、それはその後の処理のためにそのセッション状態を取得します。

- Oracle Adaptive Access Managerセッションが、Oracle RACデータベース・ノードの障害に直接影響を与えることはありません。それは、WebLogic Serverがそのデータベース接続の状態を保持しているためです。

8.12.3 Oracle Adaptive Access Managerの高可用性の構成手順

この項では、Oracle Adaptive Access Managerで最大限の高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAAMサーバーに配布します。これらのOAAMサーバーは、Oracle Real Application Clusters(Oracle RAC)データベースと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。

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

- 第8.12.3.1項「Oracle Adaptive Access Managerの構成のための前提条件」

- 第8.12.3.2項「データベースにOAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行」

- 第8.12.3.3項「Oracle WebLogic Serverのインストール」

- 第8.12.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」

- 第8.12.3.5項「OAAMHOST1での管理サーバー用boot.propertiesの作成」

- 第8.12.3.6項「Oracle Adaptive Access Manager管理ユーザーの作成」

- 第8.12.3.7項「OAAMHOST1の起動」

- 第8.12.3.8項「OAAMHOST1の検証」

- 第8.12.3.9項「OAAMHOST2でのOracle Adaptive Access Managerの構成」

- 第8.12.3.10項「OAAMHOST2の起動」

- 第8.12.3.11項「OAAMHOST2の検証」

- 第8.12.3.12項「Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成」

- 第8.12.3.13項「Oracle Adaptive Access Managerの構成の検証」

- 第8.12.3.14項「Oracle Adaptive Access Managerトポロジのスケール・アップとスケール・アウト」

注意:

Oracle Adaptive Access Managerのオフラインをインストールおよび構成するには、Oracle Adaptive Access Managerインストールおよび構成ガイドのAdaptive Access Managerのオフラインのインストールと構成に関する説明を参照してください。

8.12.3.1 Oracle Adaptive Access Managerの構成のための前提条件

Oracle Adaptive Access Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。

- データベースにOAAMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。
OAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行手順は、第8.12.3.2項「データベースにOAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行」を参照してください。

- OAAMHOST1およびOAAMHOST2にOracle WebLogic Serverをインストールします。
第8.12.3.3項「Oracle WebLogic Serverのインストール」の手順に従い、OAMHOST1およびOAMHOST2にOracle WebLogic Serverをインストールします。

- OAAMHOST1およびOAAMHOST2にOracle Identity Management実行可能ファイルをインストールし、構成します。
第8.12.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」の手順に従い、OAAMHOST1およびOAAMHOST2にOracle Identity Management実行可能ファイルをインストールします。

8.12.3.2 データベースにOAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行

データベース・リポジトリにOAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行手順は、第8.2.4.1項「リポジトリ作成ユーティリティの実行」を参照してください。

8.12.3.3 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールする前に、お使いのマシンが、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』に指定されているシステム、パッチ、カーネルなどの要件を満たしていることを確認します。

インストーラを起動し、次の手順を実行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。

ORACLE_BASE/product/fmw

注意:

ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracleの値をお薦めします。

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

3. セキュリティ・アップデートが通知されるようにするために、「セキュリティ更新のための登録」画面で連絡先情報を入力します。
「次へ」をクリックします。

4. 「インストール・タイプの選択」画面で、「カスタム」を選択します。
「次へ」をクリックします。

5. 「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。

6. 「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。
「次へ」をクリックします。

7. 「インストールの概要」画面で「次へ」をクリックします。

8. 「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
「完了」をクリックします。

8.12.3.4 Oracle Adaptive Access Manager Application Tierのインストールと構成

次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOAAMHOST1およびOAAMHOST2にインストールします。

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

次のようにOracle Fusion Middlewareのインストーラを起動します。

OAAMHOST1> runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_<バージョン>のように入力します。

次の手順を実行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

3. 「インストール場所の指定」画面で、次の値を入力します。

- Oracleミドルウェア・ホーム: MW_HOMEのリストから前にインストールしたミドルウェア・ホームを選択します。例:

/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ:

- IDM_ORACLE_HOMEにOracle Identity Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてidmを入力します。

- IAM_ORACLE_HOMEにOracle Identity and Access Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてiamを入力します。SOA_ORACLE_HOMEにOracle SOA Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてsoaを入力します。

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

4. 「インストール・サマリー」画面で「インストールと構成」をクリックします。

5. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

6. 「ドメイン・ソースの選択」画面で、次を選択します。
「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

次の製品を選択します。

- Oracle Enterprise Manager

- Oracle JRF(デフォルトで選択)

- Oracle Adaptive Access Manager - Server

- Oracle Adaptive Access Manager管理サーバー

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

7. 「ドメイン名と場所の指定」画面で、次を入力します。

- ドメイン名: IDM_Domain

- ドメイン・ディレクトリ: デフォルトを受け入れます。

- アプリケーション・ディレクトリ: デフォルトを受け入れます。

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

8. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。

9. 「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。

- WebLogicドメインの起動モード: 「本番モード」を選択します。

- JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。

10. 「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
「次へ」をクリックします。

11. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAAM Admin Serverを選択し、次の項目を入力します。

- データ・ソース: OAAM Admin Server

- サービス名: oaam.mycompany.com

- ユーザー名: OAAM_OAAM(OAAMがRCU接頭辞として使用されていたと想定)

- パスワード: 前述のアカウント用のパスワード

右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。

- ホスト名: OAAMDBHOST1

- インスタンス名: oaamdb1

- ポート: 1521

再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。

- ホスト名: OAAMDBHOST2

- インスタンス名: oaamdb2

- ポート: 1521

このデータ・ソースの選択を解除します。次のデータ・ソースであるOAAM Admin MDSスキーマを選択し、次の情報を入力します。

- データ・ソース: OAAM Admin MDSスキーマ

- サービス名: oaam.mycompany.com

- ユーザー名: OAAM_MDS(OAAMがRCU接頭辞として使用されていたと想定)

- パスワード: OAAM_MDSアカウント用パスワードです。

右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。

- ホスト名: OAAMDBHOST1

- インスタンス名: oaamdb1

- ポート: 1521

再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。

- ホスト名: OAAMDBHOST2

- インスタンス名: oaamdb2

- ポート: 1521

このデータ・ソースの選択を解除します。次のデータ・ソースであるOAAM Serverを選択し、次の情報を入力します。

- データ・ソース: OAAM Server

- サービス名: oaam.mycompany.com

- ユーザー名: OAAM_OAAM(OAAMがRCU接頭辞として使用されていたと想定)

- パスワード: OAAM_OAAMアカウント用パスワードです。

右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。

- ホスト名: OAAMDBHOST1

- インスタンス名: oaamdb1

- ポート: 1521

再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。

- ホスト名: OAAMDBHOST2

- インスタンス名: oaamdb2

- ポート: 1521

このデータ・ソースの選択を解除します。次のデータ・ソースであるOWSM MDSスキーマを選択し、次の情報を入力します。

- データ・ソース: OWSM MDSスキーマ

- サービス名: oaam.mycompany.com

- ユーザー名: OAAM_MDS(OAAMがRCU接頭辞として使用されていたと想定)

- パスワード: OAAM_MDSアカウント用パスワードです。

右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。

- ホスト名: INFRADBHOST1

- インスタンス名: oaamdb1

- ポート: 1521

再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。

- ホスト名: INFRADBHOST2

- インスタンス名: oaamdb2

- ポート: 1521

このデータ・ソースの選択を解除します。

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

12. 「コンポーネント・スキーマのテスト」画面で、データ・ソースの検証が試行されます。
データ・ソースの検証が成功したら、「次へ」をクリックします。

失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。

13. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

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

14. 「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。

15. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- Listen address: 管理サーバーの仮想ホスト名を入力します(例: OAAMHOST1.mycompany.com)。

- Listen port: 7001

- SSLリスニング・ポート: 適用なし

- SSL有効: 選択を解除

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

16. 「管理対象サーバーの構成」画面で、トポロジのOAAMHOSTごとに2つのエントリを作成します。つまり、OAAM Serverに対して1つと、OAAM Admin Serverに対して1つ作成します。
OAAM_SERVERエントリを選択し、そのエントリを次の値に変更します。

- Name: WLS_OAAM1

- Listen address: OAAMHOST1.mycompany.com

- Listen port: 14300

- SSLリスニング・ポート: 14301

- SSL有効: 選択

2つ目のOAAM_SERVERに対して、「追加」をクリックし、次の情報を入力します。

- Name: WLS_OAAM2

- Listen address: OAAMHOST2.mycompany.com

- Listen port: 14300

- SSLリスニング・ポート: 14301

- SSL有効: 選択

OAAM_ADMIN_SERVERエントリを選択し、そのエントリを次の値に変更します。

- Name: WLS_OAAM_ADMIN1

- Listen address: OAAMHOST1.mycompany.com

- Listen port: 14200

- SSLリスニング・ポート: 14201

- SSL有効: 選択

2つ目のOAAM_ADMIN_SERVERに対して、「追加」をクリックし、次の情報を入力します。

- Name: WLS_OAAM_ADMIN2

- Listen address: OAAMHOST2.mycompany.com

- Listen port: 14200

- SSLリスニング・ポート: 14201

- SSL有効: 選択

その他すべてのフィールドはデフォルトの設定のままにします。

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

17. 「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前としてOAAM_Clusterを入力します。

「追加」をクリックし、2つ目のクラスタを作成します。

名前としてOAAM_Admin_Clusterを入力します。

その他すべてのフィールドはデフォルトの設定のままにします。

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

18. 「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。

- 右のウィンドウでクラスタ名OAAM_Clusterをクリックします。

- 管理対象サーバーWLS_OAAM1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。

- 管理対象サーバーWLS_OAAM2に対しても同様に繰り返します。

続いて、次のように操作します。

- 右のウィンドウでクラスタ名OAAM_Admin_Clusterをクリックします。

- 管理対象サーバーWLS_OAAM_ADMIN1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。

- 管理対象サーバーWLS_OAAM_ADMIN2に対しても同様に繰り返します。

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

19. 「マシンの構成」画面で、トポロジ内の各サーバーのマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を入力します。

- 名前: ホストの名前。ベスト・プラクティスは、DNS名(OAAMHOST1)を使用することです。

- ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAAMHOST1.mycompany.com)

- ノード・マネージャ・ポート: ノード・マネージャが使用するポート。

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

20. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。
OAAMHOST1について、次のように操作します。

- 右のウィンドウでマシンOAAMHOST1をクリックします。

- 左のウィンドウで管理対象サーバーWLS_OAAM1をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。

- 左のウィンドウで管理対象サーバーWLS_OAAM_ADMIN1をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。

OAAMHOST2について、次のように操作します。

- 右のウィンドウでマシンOAAMHOST2をクリックします。

- 左のウィンドウで管理対象サーバーWLS_OAAM2をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。

- 左のウィンドウで管理対象サーバーWLS_OAAM_ADMIN2をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。

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

21. 「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。
プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。

8.12.3.5 OAAMHOST1での管理サーバー用boot.propertiesの作成

この項では、OAAMHOST1上の管理サーバーに対してboot.propertiesファイルを作成する方法について説明します。boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。

次の手順に従って、boot.propertiesファイルを作成します。

1. 管理サーバーを起動します。

2. OAAMHOST1で、次のディレクトリに移動します。

MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

例:

cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

3. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

username=adminUser
password=adminUserPassword

注意:

管理サーバーの起動時に、このファイルのユーザー名とパスワードのエントリは暗号化されます。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。

4. 管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。

5. MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OAAMHOST1上の管理サーバーを起動します。

6. Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。

- WebLogic Server管理コンソール:

http://oaamhost1.mycompany.com:7001/console

- Oracle Enterprise Manager Fusion Middleware Control:

http://oaamhost1.mycompany.com:7001/em

weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

8.12.3.6 Oracle Adaptive Access Manager管理ユーザーの作成

OAAMコンソールへのアクセスに使用する管理ユーザーを作成します。そのためには、次の手順を実行してください。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oaamhost1.mycompany.com:7001/console

2. 「ドメイン構造」メニューで、「セキュリティ・レルム」→「myrealm」を選択します。

3. 「ユーザーとグループ」タブをクリックします。

4. 「ユーザー」サブタブをクリックします。

5. 新規をクリックします。

6. 次の値を入力します。

- 名前: ユーザーの名前。例: oaam_admin

- プロバイダ: デフォルト認証システム

- パスワード/確認: ユーザーのパスワード

「OK」をクリックします。

7. ユーザーを作成したら、そのユーザー名をクリックします。

8. 「グループ」サブタブをクリックします。

9. ユーザーを次のグループに割り当てます。

- OAAMCSRGroup

- OAAMCSRManagerGroup

- OAAMInvestigatorGroup

- OAAMInvestigationManagerGroup

- OAAMRuleAdministratorGroup

- OAAMEnvAdminGroup

- OAAMSOAPServicesGroup

「保存」をクリックします。

8.12.3.7 OAAMHOST1の起動

OAAMHOST1を起動します。

この項では、OAAMHOST1の起動手順について説明します。

8.12.3.7.1 OAAMHOST1でのノード・マネージャ・プロパティ・ファイルの作成

コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:

OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

8.12.3.7.2 ノード・マネージャの起動

次のコマンドを発行してノード・マネージャを起動します。

OAAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

8.12.3.7.3 OAAMHOST1でのOracle Adaptive Access Managerの起動

OAAMHOST1上のOracle Adaptive Access Managerを起動する手順は、次のとおりです。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oaamhost1.mycompany.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを指定します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバーWLS_OAAM1およびWLS_OAAM_ADMIN1をクリックします。

6. 「起動」をクリックします。

7. 「OK」をクリックし、サーバーを起動することを確認します。

8.12.3.8 OAAMHOST1の検証

次のURLにあるOAAM管理サーバーに接続することによって実装を検証します。

http://OAAMHOST1.mycompany.com:14200/oaam_admin

OAAM管理コンソールのログイン・ページが表示され、第8.12.3.6項「Oracle Adaptive Access Manager管理ユーザーの作成」で作成したoaamadminアカウントを使用してログインできる場合、実装は有効です。

次の場所にあるOAAMサーバーに接続することによって実装を検証します:

http://OAAMHOST1.mycompany.com:14300/oaam_server

OAAMサーバーのログイン・ページが表示される場合、実装は有効です。

8.12.3.9 OAAMHOST2でのOracle Adaptive Access Managerの構成

OAAMHOST1で構成を完了したら、それをOAAMHOST2に伝播できます。これを実行するには、OAAMHOST1でpackスクリプトを使用してドメインをパックし、OAAMHOST2でunpackスクリプトを使用してドメインを解凍します。

スクリプトは両方とも、MW_HOME/oracle_common/common/binディレクトリにあります。

OAAMHOST1で、次のように入力します。

pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar -template_name="OAAM Domain" -managed=true

これにより、/tmpディレクトリにidm_domain.jarというファイルが作成されます。このファイルをOAAMHOST2にコピーします。

OAAMHOST2で、次のように入力します。

unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
-template=/tmp/idm_domain.jar

8.12.3.10 OAAMHOST2の起動

OAAMHOST2を起動します。

この項では、OAAMHOST2の起動手順について説明します。

8.12.3.10.1 OAAMHOST2でのノード・マネージャ・プロパティ・ファイルの作成

コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:

OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

8.12.3.10.2 ノード・マネージャの起動

次のコマンドを発行してノード・マネージャを起動します。

OAAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

8.12.3.10.3 OAAMHOST2でのOracle Adaptive Access Managerの起動

OAAMHOST2上のOracle Adaptive Access Managerを起動する手順は、次のとおりです。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oaamhost2.mycompany.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを指定します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバーWLS_OAAM2およびWLS_OAAM_ADMIN2をクリックします。

6. 「起動」をクリックします。

7. 「OK」をクリックし、サーバーを起動することを確認します。

8.12.3.11 OAAMHOST2の検証

次のURLにあるOAAM管理サーバーに接続することによって実装を検証します。

http://OAAMHOST2.mycompany.com:14200/oaam_admin

OAAM管理コンソールのログイン・ページが表示され、第8.12.3.6項「Oracle Adaptive Access Manager管理ユーザーの作成」で作成したoaamadminアカウントを使用してログインできる場合、実装は有効です。

次の場所にあるOAAMサーバーに接続することによって実装を検証します:

http://OAAMHOST2.mycompany.com:14300/oaam_server

OAAMサーバーのログイン・ページが表示される場合、実装は有効です。

8.12.3.12 Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成

この項では、Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成手順について説明します。

8.12.3.12.1 Oracle HTTP Server構成の更新

WEBHOST1およびWEBHOST2で、次のディレクトリにoaam.confというファイルを作成します。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

次の行を指定してファイルを作成します。

NameVirtualHost *:7777
<VirtualHost *:7777>

ServerName oaam.mycompany.com:7777
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /oaam_server>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.mycompany.com:14300,oaamhost2.mycompany.com:14300
</Location>

<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200
WebLogicPort 7001
</Location>

</VirtualHost>

8.12.3.12.2 Oracle HTTP Serverの再起動

WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1>opmnctl stopall
WEBHOST1>opmnctl startall

WEBHOST2>opmnctl stopall
WEBHOST2>opmnctl startall

8.12.3.12.3 WebLogicにおけるホスト・アサーションの変更

Oracle HTTP Serverは、WebLogicのプロキシとして機能するため、デフォルトでは、特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。

そのためには、次のWebLogic管理コンソールにログインします。

http://oaamhost1.mycompany.com:7001/console

次の手順を実行します。

1. ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。

2. 「チェンジ・センター」ウィンドウで「ロックして編集」をクリックし、編集可能にします。

3. クラスタ名(oaam_cluster)をクリックします。

4. 「一般」タブで、「拡張プロパティ」セクションのボックスを選択して、WebLogicプラグインを「有効」に設定します。

5. 「保存」をクリックします。

6. 「HTTP」を選択し、次の値を入力します。

- フロントエンド・ホスト: oaam.mycompany.com

- フロントエンドHTTPポート: 7777

- フロントエンドHTTPSポート: SSL通信を使用している場合は、ロード・バランサ上のSSLポートまたはOracle HTTP Server SSLポートに設定します。

これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート443または80に送られます。

7. 「保存」をクリックします。

8. ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。

9. クラスタ名(oaam_admin_cluster)をクリックします。

10. 「一般」タブで、「拡張プロパティ」セクションのボックスを選択して、WebLogicプラグインを「有効」に設定します。

11. 「保存」をクリックします。

12. 「HTTP」を選択し、次の値を入力します。

- フロントエンド・ホスト: oaam.mycompany.com

- フロントエンドHTTPポート: 7777

- フロントエンドHTTPSポート: SSL通信を使用している場合は、ロード・バランサ上のSSLポートまたはOracle HTTP Server SSLポートに設定します。

13. 「保存」をクリックします。

14. 「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックし、変更を保存します。

15. 管理対象サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1、およびWLS_OAAM_ADMIN2を次のようにして再起動します。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oaamhost1.mycompany.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを指定します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2をクリックします。

6. 「停止 - ただちに強制停止」を選択します。

7. 「はい」をクリックし、サーバーを停止することを確認します。

8. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

9. 「制御」タブをクリックします。

10. サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2をクリックします。

11. 「起動」をクリックします。

12. 「はい」をクリックし、サーバーを起動することを確認します。

16. 管理サーバーを再起動します。

8.12.3.13 Oracle Adaptive Access Managerの構成の検証

Oracle Adaptive Access Manager管理コンソール(http://oaam.mycompany.com:7777/oaam_admin)に、作成したoaamadminアカウントを使用してログインします。

Oracle Adaptive Access Managerサーバー(http://oaam.mycompany.com:7777/oaam_server)に、作成したoaamadminアカウントおよびパスワード・テストを使用してログインします。

8.12.3.14 Oracle Adaptive Access Managerトポロジのスケール・アップとスケール・アウト

この項では、Oracle Adaptive Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいOracle Adaptive Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいOracle Adaptive Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。

8.12.3.14.1 Oracle Adaptive Access Managerのスケール・アップ

OAAMをスケール・アップするには、OAAMサーバーとOAAM管理サーバーの両方に対して同じ手順を使用します。

Oracle WebLogic Serverコンソール(http://oaamhost1.mycompany.com:7001/console)にログインします。次の手順を実行します。

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーの概要」ページが表示されます。

2. 「チェンジ・センター」メニューで「ロックして編集」をクリックします。

3. 拡張するホストで既存のサーバーを選択します。例: WLS_OAAM1またはWLS_OAAM_ADMIN1

4. 「クローンの作成」をクリックします。

5. 次の情報を入力します。

- サーバー名: サーバーの新しい名前。例: WLS_OAAM3

- サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。

6. 「OK」をクリックします。

7. 新しく作成したサーバーWLS_OAAM3をクリックします。

8. SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。

9. 「保存」をクリックします。

10. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOAAMHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

11. 「チェンジ・センター」メニューで構成のアクティブ化をクリックします。

8.12.3.14.2 Oracle Adaptive Access Managerのスケール・アウト

スケール・アウトはスケール・アップと非常によく似ていますが、スケール・アウトでは、新しいノードにインストールされるソフトウェアが必要です。次の手順を実行します。

1. 第8.12.3.3項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。

2. 第8.12.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」の手順に従い、新しいホストにOracle Fusion Middleware Identity Managementコンポーネントをインストールします。

3. WebLogicコンソール(http://oaamhost1.mycompany.com:7001/console)にログインします。

4. Oracle WebLogic Server管理コンソールの「ドメイン構造」ペインで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーの概要」ページが表示されます。

5. 「チェンジ・センター」メニューで「ロックして編集」をクリックします。

6. 拡張するホストで既存のサーバーを選択します。例: WLS_OAAM1またはWLS_OAAM_ADMIN1

7. 「クローンの作成」をクリックします。

8. 次の情報を入力します。

- サーバー名: サーバーの新しい名前。例: WLS_OAAM3

- サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。

9. 「OK」をクリックします。

10. 新しく作成したサーバーWLS_OAAM3をクリックします。

11. SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。

12. 「保存」をクリックします。

13. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとOAAMHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーの概要」ページが表示されます。

4. 表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

14. 「チェンジ・センター」メニューで構成のアクティブ化をクリックします。

15. 次のコマンドを使用してOAAMHOST1上のドメインをパックします。

pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAAM Domain" -managed=true

pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。

16. 次のコマンドを使用して新しいホスト上のドメインを解凍します。

unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications

unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。

17. コンソールから管理対象サーバーを起動する前に、スクリプトsetNMProps.shを実行してOAAMHOST2上にノード・マネージャのプロパティ・ファイルを作成しておく必要があります。setNMProps.shスクリプトは、MW_HOME/oracle_common/common/binにあります。次のように入力します。

OAAMHOST2> $MW_HOME/oracle_common/common/bin/setNMProps.sh

18. 新しいホストでノード・マネージャと新しい管理対象サーバーを起動します。

19. これで、新しい管理対象サーバーが作成されて起動され、Web層はリクエストをその管理対象サーバーに転送するようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
これを行うには、各Web層でファイルoaam.confを更新します。このファイルは、ディレクトリORACLE_INSTANCE/config/OHS/component_name/moduleconfにあります。

新しいサーバーをファイル内のWebLogicClusterディレクティブに追加します。次に例を示します。

<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200
</Location>

前述の行を次のように変更します。

<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster
oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200,oaamhost3.mycompany.com:14300
</Location>

8.13 Oracle Identity Federationの高可用性

この項では、Oracle Identity Federationの概要およびOracle Identity Federationの高可用性環境の設計とデプロイについて説明します。

8.13.1 Oracle Identity Federationコンポーネント・アーキテクチャ

Oracle Identity Federationは、複数ドメインのアイデンティティ・ネットワークのシングル・サインオンと認証を提供し、もっとも広範なフェデレーション標準のセットをサポートするスタンドアロンの自己完結型フェデレーション・サーバーです。これにより、ソリューション・セットでその他のOracle Identity Management製品が実装されているかどうかに関係なく、異種環境とビジネス結合に属するユーザーのフェデレーションが可能になります。

これは、アイデンティティ・プロバイダ(IdP)およびサービス・プロバイダ(SP)両方の役割を果たすマルチプロトコル・ハブとしてデプロイできます。

Oracle Identity Federationは、SPとして機能することで、帯域外の複数のセキュリティ・ドメイン間でユーザー同期をせずに、実際のユーザー認証をIdPにオフロードする間もリソース管理を可能にします。IdPで認証されると、SPは、ローカル・アクセス・ポリシーに応じて、そのSPのアプリケーションに対するユーザーのアクセスを許可または拒否できます。

ユーザーがそのIdPに対するアカウントを持っていない場合、フェデレーションは終了し、そのユーザーのドメイン間でのシングル・サインオンは自動的に無効化されます。Oracle Identity FederationをIdPとして利用すると、信頼できるプロバイダからの連携リクエストに基づいて、ローカル・ユーザーの管理と認証が実行できます。

Oracle Identity Federationの主要な機能には、次のサポートが含まれます。

- SAML 1.x、SAML 2.0、WS-Federation、SAML 1.x/2.0属性共有機能、Liberty ID-FF 1.1/ Liberty ID-FF 1.2などの複数の主要なフェデレーション・プロトコル

- プロトコルを超えたシングル・サインオンおよびサインアウト

- サービス・プロバイダのフェデレーション情報の共有化およびフェデレーションの数の削減によるアフィリエーション

- X.509証明書検証

- Oracle Access ManagerおよびOracle Single Sign-Onとの統合

- Oracle Internet Directoryとの統合および広範な認証エンジン、ユーザー・データ・リポジトリ、リレーショナル・データベースのサポート

- アイデンティティ・プロバイダおよびサービス・プロバイダの両方が含まれる環境でのサイトを超えたアクセスと認証の実装

- 外部サイトを構成、有効化および無効化する機能

- シングル・サインオンを使用した宛先サイトのアプリケーションへのアクセス

図8-20 非高可用性アーキテクチャのOracle Identity Federation

「図8-20 非高可用性アーキテクチャのOracle Identity Federation」の説明

図8-20は、非高可用性アーキテクチャのOracle WebLogic ServerにデプロイされたOracle Identity Federationと、他のフェデレーション・コンポーネントとの関係を示しています。

図8-20は、他のアイデンティティ・プロバイダ(IdP)およびサービス・プロバイダ(SP)間のフェデレーション・メンバーとしてのOracle Identity Federationを示しています。

Oracle Identity Federation認証サービスは次のように構成できます。

- Oracle Single Sign-On(Oracle Internet Directoryユーザー・リポジトリを使用)またはOracle Access Manager(各種リポジトリを使用)により保護されたリソースへのシングル・サインオン・アクセスを可能にします。リソースとして、Oracle Collaboration Suite、Oracle E-Business Suite、PeopleSoftモジュールなどを含めることができます。

- LDAPディレクトリ、RDBMSデータベース、Oracle Access Managerなどのアイデンティティおよびアクセス管理ソリューションと相互運用できます。

注意:

Oracle Identity FederationとOracle Single Sign-Onの両方がリソースを保護している環境では、いずれかのコンポーネントを、ユーザー・リクエストが保護リソースにアクセスした場合に認証メカニズムとして動作するように構成できます。また、Oracle Identity FederationとOracle Access Managerの両方を含む環境にも同様の機能があります。

Oracle Identity Federation認証の詳細は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドを参照してください。

8.13.1.1 Oracle Identity Federationコンポーネントの特性

Oracle Identity Federationは、J2EE標準に準拠した、スタンドアロンの自己完結型フェデレーション・サーバーです。複数ドメインのアイデンティティ・ネットワークのシングル・サインオンと認証を提供し、SAML 1.x、SAML 2.0、WS-Federation、およびSAML 1.x/2.0属性共有機能など、広範なフェデレーション標準のセットをサポートします。

Oracle Identity Federationは、デフォルトでは、Oracle WebLogic Serverに対して外部的にステージングされたアプリケーションとしてデプロイされます。

8.13.1.1.1 ランタイム・プロセス

Oracle Identity Federationは、Oracle WebLogic Serverに対して外部的にステージングされたアプリケーションとしてデプロイされるJ2EEアプリケーションです。Oracle Identity Federationサーバーは、デプロイされたWebLogic Serverの起動時に初期化されます。

Oracle Identity Federationアプリケーションは、資格証明ストア・フレームワークにアクセスして、バックエンド・サーバーに接続するための資格証明を取得します。この処理が完了すると、Oracle Identity Federationサーバーは実行状態となり、リクエストを受け入れて処理する準備ができます。

8.13.1.1.2 プロセスのライフサイクル

Oracle Identity Federationは、外部的に管理されるアプリケーションとしてOracle WebLogic Serverにデプロイされます。Oracle WebLogic Serverはデフォルトで、Oracle Identity Federationアプリケーションに対する他のライフサイクル・イベントの起動、停止、監視、および管理を行います。

このアプリケーションは、デプロイされるOracle WebLogic Serverの起動時に初期化され、WebLogic Serverの停止時に停止されます。

WebLogicノード・マネージャは、サーバー・プロセスを監視し、障害発生時にそのプロセスを再起動するように構成できます。

Oracle Enterprise Manager Fusion Middleware Controlは、アプリケーションの監視および構成の変更に使用します。

起動および停止

Oracle Identity Federationのライフサイクル・イベントは、次に示すコマンドライン・ツールおよびコンソールを1つ以上使用して管理できます。

- Oracle WebLogic Scripting Tool(WLST)

- Oracle WebLogic Server管理コンソール

- Oracle Enterprise Manager Fusion Middleware Control

- WebLogicノード・マネージャ

8.13.1.1.3 リクエスト・フロー

通常、ユーザーは、会社のポータルを介して複数のドメインのアプリケーションにアクセスします。たとえば、Alpha Corporationが、Alphaのユーザー・ログイン、ページのパーソナライズなどを管理するポータル・サーバーを備えているとします。そのポータル・サーバーは、アプリケーション・サーバー内で動作する自社製ロジックで構成されている場合や、市販の製品の場合があります。パートナ会社であるBeta Corporationは、MyBeta.comというタイプのポータルを使用して、その技術的なデータベース・アプリケーションを提供できます。この場合、それぞれが自社ポータル・サーバーを運用していることになります。

プロセス・フローは次のようになります。

1. ユーザーは、Oracle Access ManagerやOracle Single Sign-OnなどのWebアクセス管理(WAM)システムによりアクセスが管理されているAlphaポータルにログインします。

2. ユーザーは、実際にはBeta Corporationがホストしているリソースをクリックしてリクエストを開始します。

3. アイデンティティ・プロバイダ(IdP)として動作しているAlphaポータルのOracle Identity Federationインスタンスが、ユーザー情報をWAMシステムに送信します。

4. WAMシステムは、ローカル・アイデンティティ・ストアのアイデンティティにユーザーをマッピングした後、セッションを作成します。

5. WAMシステムにより、成功したレスポンスとセッション・トークンがAlphaポータルのOracle Identity Federation IdPサーバーに戻されます。

6. 前述の情報を使用して、AlphaポータルのIdPはSAMLアイデンティティ・アサーションを作成し、プライベート署名キーを使用して署名します。このレスポンスは、Beta Corporationのサービス・プロバイダ(SP)として動作するOracle Identity Federationインスタンスに送信されます。

7. Beta CorporationのSPとして動作するOracle Identity Federationサーバーは、署名キーに関連付けられたIdPのパブリック証明書を使用して署名付きレスポンスを検証します。

8. Beta CorporationのOracle Identity Federationサービス・プロバイダはアサーションを抽出し、ユーザー・セッションをローカル認証システムにマッピングした後、アサーションに対するユーザー・セッションを作成します。

9. Oracle Identity Federationサービス・プロバイダは、ユーザーのブラウザにリクエストされたリソースへのリダイレクトを送信します。

10. ユーザーのブラウザは、サービス・プロバイダによって作成されたユーザー・セッションを介して、ターゲット・リソースへのリクエストを送信します。

8.13.1.1.4 構成アーティファクト

Oracle Identity Federationサーバーの構成は、MBeansによって管理されます。Oracle Identity Federationの構成データは、次の3つのメイン・ファイルに格納されます。

- config.xml: サーバー全体の構成が格納されます。

- cot.xml: プロバイダ固有の構成が格納されます。

- datastore.xml: バックエンドのデータ・ストアの構成が格納されます。

Oracle Identity Federationアプリケーションは、Oracle Identity Management 11gインストーラによって、EARファイルとしてデプロイされます。Oracle Identity Federationアプリケーションは、ORACLE_HOME/fed/install/oif.earディレクトリの下にあります。

Oracle Identity Federation構成アーティファクトは、アプリケーションがデプロイされた管理対象サーバーのDOMAIN_HOME/config/fmwconfig/servers/serverName/applications/OIF_11.1.1.2.0/configurationディレクトリの下にあります。

Oracle Enterprise Manager Fusion Middleware Controlを使用して構成を変更すると、ノード間での構成の不整合を回避できます。これは、アプリケーションが高可用性構成にデプロイされている場合、特に有効です。ただし、WLSTスクリプトおよびJMX MBeansを使用してOracle Identity Federationサーバーを構成することもできます。

8.13.1.1.5 外部依存性

Oracle Identity Federationサーバーは、Oracle WebLogic管理対象サーバーにデプロイされるJ2EEアプリケーションです。Oracle Identity Federationサーバーは外部構成データ、ランタイム一時データ(メッセージ、ユーザー・セッション)、およびフェデレーション・データを格納するリポジトリと対話して、ユーザーの認証を行います。Oracle Identity Federationサーバーでは、初期化またはランタイム時に、これらのリポジトリが使用可能である必要があります。Oracle Identity Federationサーバーの機能に必要な外部コンポーネントは次のとおりです。

- Oracle WebLogic Server

- 管理サーバー

- 管理対象サーバー

- データ・リポジトリ

- メッセージ・データ・ストアおよびユーザー・セッション・データ・ストア(一時データ・ストア)

- 構成データ・ストア

- ユーザー・データ・ストア

- フェデレーション・データ・ストア

- 認証エンジン

- サービス・プロバイダ・エンジン

これらの外部コンポーネントがOracle Identity Federationを使用してどのように機能するかについては、次の各項を参照してください。

Oracle WebLogic Server

Oracle Identity Federationサーバーは、Oracle WebLogic管理対象サーバーにデプロイされるJ2EEアプリケーションです。このサーバーは、Oracle Enterprise Manager Fusion Middlewareを使用して管理されます。

管理対象サーバーが実行されていない場合は、アプリケーションを起動できません。管理サーバーが使用できない場合は、このサーバーは現行の状態で実行を続けますが、構成の変更はできません。

データ・リポジトリ

Oracle Identity Federationサーバーは、様々な外部データ・リポジトリを使用して、構成、ユーザー・セッション、メッセージ、およびフェデレーション・データを格納します。このサーバーでは、初期化またはランタイム時、あるいはその両方で、これらのデータ・ストアが使用可能である必要があります。リポジトリの詳細は次のとおりです。

- メッセージ・データ・ストアとユーザー・セッション・データ・ストア(一時データ・ストア)
Oracle Identity Federationサーバーは、フェデレーション・プロトコル/セッションの状態などの一時データの格納にメッセージ・データ・ストアとユーザー・データ・ストアを使用します。メッセージ・データ・ストアはユーザー・セッション・データ・ストアとともに、一時データ・ストアとも呼ばれます。

Oracle Identity Federationサーバーのデプロイメント・オプションに応じて、一時データは、メモリーまたはリレーショナル・データベースに格納されます。表8-11は、デプロイメント・オプションとそのオプションに必要な一時データ・ストアのタイプとの関係を示しています。

表8-11 Oracle Identity Federationのデプロイメント・オプションに対応する一時データ・ストアのタイプ

デプロイメント・オプション

ストア・タイプ

非高可用性/スタンドアロン

メモリー内のストア

リレーショナル・データベース・ストア

高可用性

リレーショナル・データベース・ストア

- 構成データ・ストア
Oracle Identity Federationアプリケーションは、構成データ・ストアを使用して、構成アーティファクトを格納します。Oracle Identity Federationサーバーのデプロイメント・オプションに応じて、構成データ・ストアはXMLファイル、またはリレーショナル・データベースに格納されます。

表8-12は、デプロイメント・オプションとそのオプションに必要な構成データ・ストアのタイプとの関係を示しています。

表8-12 Oracle Identity Federationのデプロイメント・オプションに対応する構成データ・ストアのタイプ

デプロイメント・オプション

ストア・タイプ

非高可用性/スタンドアロン

XML

リレーショナル・データベース・ストア

高可用性

リレーショナル・データベース・ストア

Oracle Identity Federationアプリケーションは、プロセスの起動時に、構成データ・ストアに接続して構成データを取得します。構成データ・ストアが使用できない場合は、アプリケーションを起動できません。

- ユーザー・データ・ストア
Oracle Identity Federationサーバーでは、ローカル認証の後、またはSAMLアサーションの受信処理の後にユーザーを特定するとき、およびユーザー固有の属性を取得するときに、ユーザー・データ・ストアを使用します。ユーザー・データ・リポジトリは、リレーショナル・データベースまたはLDAPリポジトリになります。

Oracle Identity Federationサーバーでは、Oracle Internet Directory、Sun Java System Directory Server、Microsoft Active DirectoryなどのLDAPリポジトリ、およびリレーショナル・データベースと使用した場合の動作が保証されます。

ユーザー・データ・リポジトリの役割は、Oracle Identity Federationをアイデンティティ・プロバイダ(IdP)またはサービス・プロバイダ(SP)のどちらとして構成するかによって異なります。

- IdPとして構成する場合

- Oracle Identity Federationは、ユーザー・アイデンティティの検証およびプロトコル・アサーションの構築にリポジトリを使用します。

- SPとして構成する場合

- Oracle Identity Federationは、リポジトリを使用して、受信したアサーションの情報を宛先のユーザー・アイデンティティにマッピングしてから、ユーザーに対して保護されたリソースへのアクセスを認可します。

- 新たにフェデレーションを作成する場合、Oracle Identity Federationは、リポジトリを使用してユーザーを特定し、新しいフェデレーションをそのユーザーのアカウントにリンクします。

Oracle Identity Federationアプリケーションでは、起動時にユーザー・データ・ストアが使用可能である必要はありません。ユーザー・データ・ストアはランタイム時に必要になります。

注意:

Oracle Identity Federationでは、Oracle Databaseバージョン10.2.0.4以上またはOracle Database 11.1.0.7以上を使用した場合のみ、動作が保証されます。

- フェデレーション・データ・ストア
フェデレーション・データ・ストアには、XML、RDBMS、またはLDAPを使用できます。高可用性モードでは、RDBMSまたはLDAPのみを使用して、クラスタ内のすべてのノードでフェデレーション・データ・ストアを使用できるようにします。

Oracle Identity Federationサーバーは、フェデレーション・データ・ストアを使用して、ユーザーのフェデレーション・レコードを永続化します。アイデンティティ・フェデレーションとは、あるトラスト・サークル内の1つ以上のアイデンティティ・プロバイダまたはサービス・プロバイダで、プリンシパルによって保持される可能性のある2つ以上のアカウントのリンクです。ユーザーが複数のビジネスに対して持っている、相互に孤立している個別のアカウント(ローカル・アイデンティティ)をフェデレートすると、2つのエンティティ間にリレーションシップ(任意の数のサービス・プロバイダとアイデンティティ・プロバイダで構成される関連付け)が作成されます。

Oracle Identity Federationサーバーでは、Oracle Internet Directory、Sun Java System Directory Server、およびMicrosoft Active Directoryなどの業界標準のLDAPリポジトリ、またはリレーショナル・データベースが保証されています。

表8-13は、デプロイメント・オプションとそのオプションに必要なフェデレーション・データ・ストアのタイプとの関係を示しています。

表8-13 Oracle Identity Federationのデプロイメント・オプションに対応するフェデレーション・データ・ストアのタイプ

デプロイメント・オプション

ストア・タイプ

非高可用性/スタンドアロン

なし、またはXML

高可用性

なし、LDAP、またはリレーショナル・データベース・ストア

フェデレーション・データ・ストアは、プロトコルの交換の際に永続的な名前識別子フォーマットを使用する場合にかぎり、ランタイム時に必要となります。電子メール・アドレスなど不透明でない名前識別子を使用する場合は、実行時のフェデレーション・データ・ストアはオプションになります。

注意:

Oracle Identity Federationでは、Oracle Databaseバージョン10.2.0.4以上またはOracle Database 11.1.0.7以上を使用した場合のみ、動作が保証されます。

Oracle Identity Federationのフェデレーション・データ・ストアの詳細は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドのフェデレーション・データ・ストアに関する項を参照してください。

- 認証エンジン
Oracle Identity FederationのIdPおよびSPプロトコルの操作(シングル・サインオン、フェデレーションの作成、フェデレーションの終了、および名前ID登録など)では、ユーザーの認証が必要です。Oracle Identity Federationの認証モジュールは、ユーザー認証に対応しています。認証モジュールは、ユーザー認証で次の2つの異なる役割を果たします。

- Oracle Identity Federationがアイデンティティ・プロバイダとしてデプロイされる場合は、認証モジュールは、ローカル認証メカニズムとして動作します。認証モジュールでは、認証を委任することも、各種のリポジトリやアイデンティティ管理ソリューションと直接対話することも可能です。

- Oracle Identity Federationがサービス・プロバイダとしてデプロイされる場合は、フェデレーション・プロトコルを使用して、ピア・アイデンティティ・プロバイダでユーザーを認証します。Oracle Identity Federationは、ユーザーを認証モジュールに転送します。このモジュールは、SPにデプロイされたアイデンティティ管理ソリューションに認証済のユーザー・セッションを伝播し作成します。これにより、リクエストされた保護リソースへのアクセスが順に可能になります。

サポート対象のRDBMSおよびLDAPリポジトリには、Oracle Database、Oracle Internet Directory、Sun Java System Directory Server、およびMicrosoft Active Directoryなどがあります。

サポート対象のリポジトリおよびアイデンティティ管理ソリューションには、Oracle Access Manager、Oracle Single Sign Onなどがあります。

認証モジュールのランタイム時には、外部の認証エンジンが使用できるだけでかまいません。

- サービス・プロバイダ・エンジン
サービス・プロバイダ統合エンジン(SP統合エンジン)は、アイデンティティとアクセス管理(IAM)サーバーの認証済ユーザー・セッションの作成に使用します。SPエンジンを付属したOracle Identity Federationには、各種IAMサーバーとの相互運用を可能にする、次のような内部プラグインが含まれています。

- Oracle Single Sign-On

- Oracle Access Manager

- Oracle Identity Federationテスト・アプリケーション

Oracle Identity Federationでは、サード・パーティのIAMフレームワークと統合するためのフレームワークが提供されています。カスタマイズされたSP統合モジュールが内部のJ2EEサーブレット転送を使用してOracle Identity Federationと対話し、サード・パーティのIAMシステムと通信して認証済ユーザー・セッションを作成します。

いずれのカスタムSPエンジン・モジュールも、クラスタ内の各管理対象サーバーにデプロイされる必要があります。

8.13.1.1.6 Oracle Identity Federationのログ・ファイルの場所

Oracle Identity Federationは、Oracle WebLogic Server上にデプロイされるJ2EEアプリケーションです。サーバーに関連するログ・メッセージはすべて、サーバーのログ・ファイルに記録され、Oracle Identity Federationに固有のメッセージはすべて、アプリケーションがデプロイされたOracle WebLogic Serverの診断ログ・ファイルに記録されます。

Oracle WebLogic Serverのログ・ファイルのデフォルトの場所は次のとおりです。

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

Oracle Identity Federationのログ・ファイルの名前は、serverName-diagnostic.logです。たとえば、Oracle WebLogic Server名がwls_oif1の場合、ログ・ファイル名はwls_oif1-diagnostic.logになります。

ログ・ファイルを表示するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。

8.13.2 Oracle Identity Federationの高可用性の概要

この項では、Oracle Identity Federationの概要およびOracle Identity Federationの高可用性環境の設計とデプロイについて説明します。

Oracle Identity Federationを高可用性構成でデプロイする場合のガイドラインを次に示します。

- 一時データおよび構成データは、常に共有リレーショナル・データベースに格納する必要があります。これは、次の場合に必要です。

- Oracle Identity FederationがIdPとして機能し、アーティファクトSSOプロファイルが使用される場合。この場合、ユーザーは、アサーションが作成されるIdP #1と対話します。その後アーティファクトが間接参照されるときに、SPがIdP #2に接続します。2つのOracle Identity Federationサーバーが同じメッセージ・ストアを共有していない場合、IdP #2は、IdP #1が作成したアーティファクトのアサーションをロケーティングできません。

- Oracle Identity FederationがSPとして機能し、POST SSOプロファイルが使用される場合。POSTプロファイルでは、ユーザーのブラウザによってアサーションが行われるため、そのアサーションのOracle Identity Federation SPへの再送信が可能になります。潜在的なリプレイ攻撃に対処するため、Oracle Identity Federation SPサーバーは、受信したアサーションを追跡して、同じアサーションが再度使用されないようにします。

- Oracle Identity Federationが認証問合せ局として機能する場合。Oracle Identity Federationサーバーは、Oracle Identity Federationサーバーの特定ユーザーの既存セッションを示すアサーションを返すことによって、リモート・プロバイダからの問合せに応じます。このため、Oracle Identity Federationサーバーは一時セッション・ストアを共有する必要があります。

- Oracle Identity FederationがIdP/属性認証局として機能し、アサーションIDレスポンダ機能が有効化されている場合。この機能を使用すると、リモート・プロバイダはIdPに対して問合せを行い、以前のSAMLフローで作成されたアサーションを取得します。このため、レスポンダは、作成されるすべてのアサーションを格納するストアに、アクセスできる必要があります。

- 高可用性環境では、Oracle HTTP ServerインスタンスがOracle Identity Federationアプリケーションのフロントエンドに使用されていない場合、次のようにすることをお薦めします。

- Oracle Identity Federationアプリケーションのフロントエンドに使用されているハードウェア・ロード・バランサでスティッキー・セッションを有効化します。

- スティッキー・セッションにより、ユーザー・リクエストはそのセッションの間は同じOracle Identity Federationサーバーに送信されるようになります。

注意:

HTTPセッションの状態は、Oracle Identity FederationがHTTPリクエストを処理する際、ランタイム時に使用されます。HTTPセッション状態に格納される情報は短期間しか保持されません。情報の有効期間は、シングル・サインオンなどのフェデレーション操作の長さに相当します。

HTTPセッション・レプリケーションでは、ノード間でセッション情報がレプリケートされるため、メモリーが大量に消費されるので、お薦めしません。

デフォルトでは、HTTPセッションは有効化されていません。

Oracle Identity Managementソフトウェアを高可用性構成でデプロイする場合に、ロード・バランサでの有効化が必要な機能についての説明は、第8.2.5.4.1項「ロード・バランサ」を参照してください。

- Oracle Identity Federationサーバーでは、次の2つのタイプのHTTPセッション・レプリケーションがサポートされます。

- メモリー内のセッション・レプリケーション

- JDBCセッション・レプリケーション

- メモリー内のセッション・レプリケーションには、次のような特性があります。

- セッション作成時に、クラスタ内でOracle Identity Federationアプリケーションを実行するすべての管理対象サーバーが起動されている必要があります。

- パフォーマンスが低下する可能性があります。

- セッション・レプリケーションが完了する前に、サーバーがリクエストを受信すると、サーバーからエラーがスローされます。

- これを回避するために、DOMAIN_HOME/config/fmwconfig/servers/serverName/applications/OIF_11.1.1.2.0/configurationディレクトリのconfig.xmlファイル内の、次に示すパラメータを更新します。これは、Oracle Identity Federationアプリケーションを実行しているすべてのノードで行う必要があります。

- sessionreplicationenabled: これをtrueに設定します。

- sessionreplicationtimeout: これは、デフォルトで2000に設定されています。必要に応じてこの値を大きくします。

- JDBCセッション・レプリケーションには、次のような特性があります。

- 堅牢性を備えています。

- データベース呼出しに余分なオーバーヘッドがかかるため、メモリー内のセッション・レプリケーションに比べてパフォーマンスが低下します。

- セッションの永続性の状態が、共有リレーショナル・データベースに格納されます。

- JDBCセッションの永続性のためにOracle WebLogic Serverを構成するには、『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の永続記憶域(JDBC永続性)のためのデータベースの使用に関する項を参照してください。

8.13.2.1 Oracle Identity Federationの高可用性アーキテクチャ

図8-21は、Oracle Identity Federationのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。

図8-21 高可用性アーキテクチャのOracle Identity Federation

「図8-21 高可用性アーキテクチャのOracle Identity Federation」の説明

図8-21では、アプリケーション層にコンピュータIDMHOST1とIDMHOST2があります。

IDMHOST1では、次のインストールが実行されています。

- Oracle Identity FederationインスタンスがWLS_OIF1管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

- WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。

IDMHOST2では、次のインストールが実行されています。

- Oracle Identity FederationインスタンスがWLS_OIF2管理対象サーバーにインストールされています。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
IDMHOST2上のWLS_OIF2管理対象サーバーにあるインスタンスと、IDMHOST1上のWLS_OIF1管理対象サーバーにあるインスタンスは、CLUSTER_OIFクラスタとして構成されています。

- WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。IDMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。

8.13.2.1.1 クラスタの起動と停止

高可用性アーキテクチャでは、Oracle Identity Federationサーバーは、Oracle WebLogicクラスタにデプロイされます。このクラスタには、その一部として少なくとも2つのサーバーが存在します。

デフォルトでは、Oracle WebLogic Serverによって、このアプリケーションの起動、停止、監視および様々なライフサイクル・イベントの監視が行われます。Oracle Identity Federationアプリケーションは、基盤となるWebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

高可用性環境では、WebLogicノード・マネージャはOracle WebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。

高可用性環境では、ハードウェア・ロード・バランサを使用して、複数のOracle Identity Federationインスタンス間のリクエストをロード・バランシングします。Oracle Identity Federationインスタンスのいずれかに障害が発生した場合は、ロード・バランサによって障害が検出され、障害が発生していないインスタンスにリクエストがルーティングされます。

高可用性環境では、状態情報と構成情報は、クラスタ内のすべてのメンバーが共有するデータベースに格納されます。

状態情報が共有データベースに格納されており、クラスタ内のすべてのメンバーがこの情報を使用できるため、障害が発生していないOracle Identity Federationインスタンスでは、障害が発生したインスタンスで開始された未完了のトランザクションの処理をシームレスに継続します。

Oracle Identity Federationインスタンスのいずれかで障害が発生すると、そのデータベースとLDAP接続は解放されます。アクティブ/アクティブ・デプロイメント内にある障害が発生していないインスタンスは、独自の接続を行い、障害が発生したインスタンス上にある未完了のトランザクションの処理を継続します。

Oracle Identity Federationアプリケーションのライフサイクル・イベントは、次に示すコマンドライン・ツールまたはコンソールのいずれかを使用して管理できます。

- Oracle WebLogic Server管理コンソール

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle WebLogic Scripting Tool(WLST)

8.13.2.1.2 クラスタワイドの構成変更

1つのクラスタ・メンバーによって加えられた構成変更は、その構成が共有データベースに格納されているため、すべてのメンバーに自動的に伝播されます。

注意:

デフォルトでは、HTTPセッション・レプリケーションは無効化されており、お薦めしません。これはノード間でセッション情報をレプリケートするため、メモリーが大量に消費されます。ただし、環境で、HTTPセッション・レプリケーションを有効化する必要がある場合は、次の手順に従ってください。

セッション・レプリケーションのオンとオフを切り替えるには、Oracle Identity Federationがデプロイされているすべての管理対象サーバーで、次のようにweblogic.xmlファイルを更新する必要があります。

1. ORACLE_HOME/fed/install/oif.earファイルを一時的な場所にコピーします。

2. oif.earファイルに含まれているweb.warファイルからMETA-INF/weblogic.xmlファイルを抽出します。

3. パラメータset persistent-store-typeをreplicated_if_clusteredに更新します。

4. weblogic.xmlファイルを保存します。

5. Oracle Identity Federationアプリケーションを適切なツールを使用して再度パッケージ化します。

6. 更新したoif.earファイルを、Oracle Identity Federationを実行しているすべてのノードのORACLE_HOME/fed/installディレクトリにコピーします。

7. 更新したOracle Identity Federationアプリケーションを、環境内の、そのアプリケーションを実行しているすべてのノードで再起動します。

8. 管理対象サーバーを再起動します。

HTTPセッション・レプリケーションを無効化するには、前の手順に従い、ステップ3でパラメータset persistent-store-type to memoryを更新します。

注意:

これらの手動の手順は、すべてのパッチ・セットで環境を更新してから実行する必要があります。そのようにしない場合は、セッション・レプリケーションの変更は失われます。

8.13.2.2 Oracle Access Managerとの統合における高可用性の考慮事項

この項では、Oracle Identity FederationとOracle Access Managerを高可用性トポロジで統合する際に必要な手順を説明します。

1. 高可用性モードでOracle Identity Federationをデプロイすることに加えて、Oracle Access Managerも高可用性モードでデプロイする必要があります。

2. クラスタ内のすべてのOracle Identity Federationサーバーに、Oracle Access Server SDKをインストールする必要があります。Oracle Identity Federationは、SDKをインストールしたディレクトリを参照するように構成する必要があります。SDKがドメインのホーム・ディレクトリにインストールされている場合は、ドメイン・ホーム・フォルダからの相対パスを使用してSDKを参照できます。SDKが別の場所にインストールされている場合は、Oracle Identity Federationは、絶対パスを使用してSDKフォルダを参照する必要があります。
高可用性環境でOracle Identity Federationを使用する場合は、Oracle Identity Federationがインストールされているすべてのコンピュータで同じディレクトリ名を使用して、Access Server SDKをドメイン・ホーム・フォルダにインストールすることをお薦めします。すべてのOracle Identity Federationインスタンスは、同じ構成、具体的にはAccess Server SDKがインストールされているディレクトリを共有するため、これはOracle Identity FederationとOracle Access Managerで可用性の高い統合を行う場合の要件となります。相対パスを使用することにより、Oracle Identity Federationインスタンスで同一の構成を共有できます。

3. Oracle Fusion Middleware Oracle Identity Federation管理者ガイドのSP統合モジュールとしてのOracle Access Managerの統合に関する項のSP統合モジュールとしてのOracle Access Managerの統合に関する説明に従って、各Oracle Identity Federationサーバー上のSDKインスタンスとOracle Access Managerを統合します。

4. 必要に応じて、ドメイン・ライブラリに必要なファイルをコピーし、各Oracle Identity FederationサーバーのWebLogic Server起動スクリプトを更新して、SDK jarファイルをクラスパスに追加し、LD_LIBRARY_PATH環境変数およびLD_ASSUME_KERNEL環境変数を設定します。詳細は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドのOracle WebLogic Server環境の更新に関する項を参照してください。

8.13.2.3 Oracle Identity Federationの前提条件

Oracle Identity Federationには、次のコンポーネントが必要です。

- Oracle JRockit SDK(インストールにバンドル)

- Oracle WebLogic Server(インストールにバンドル)

- ユーザー・データ・ストア。通常はLDAPディレクトリですが、オプションでデータベース・ストアにすることもできます。

- フェデレーション・データ・ストア。これは、Oracle Internet Directory、Microsoft Active Directory、Sun Java System Directory Serverなどの、標準のLDAPディレクトリです。

注意:

Oracle Identity Federationではユーザー・フェデレーション・データ・ストアがすべての場合に必ず必要になるとは限りません。Liberty 1.xおよびSAML 2.0の不透明な永続識別子には必要ですが、SAML 1.x、WS-Federation、およびSAML 2.0の不透明でない識別子(電子メール・アドレス、サブジェクトDNなど)では任意です。

- Oracle Databaseバージョン10.2.0.4.0以上、またはRDBMS一時データ・ストアの場合は11.1.0.7以上。

- プロキシ実装用のOracle HTTP Server。これはOracle Identity Federationでサポートされる唯一のプロキシ・サーバーで、インストールにバンドルされています。

注意:

Oracle Identity Federationを高可用性デプロイメントで使用する場合は、クラスタ・ノードのシステム・クロックを同期する必要があります。

8.13.2.3.1 RCUを使用したリポジトリへのOracle Identity Federationスキーマの作成

OIFHOST1およびOIFHOST2にOracle Internet Directoryインスタンスをインストールする前に、最新バージョンのリポジトリ作成ユーティリティ(RCU)を使用して、Oracle Identity Federationで使用するスキーマのコレクションを作成します。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

次の手順に従って、RCUを実行し、Oracle RACデータベース・リポジトリにOracle Identity Federationスキーマを作成します。

1. 次のコマンドを発行します。
prompt> RCU_HOME/bin/rcu &

2. 「ようこそ」画面で「次へ」をクリックします。

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

4. 「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。
データベース・タイプ: Oracle Database

ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: INFRADBHOST1-VIPまたはINFRADBHOST2-VIP

ポート: データベースのポート番号。例: 1521

サービス名: データベースのサービス名。例: oif.mycompany.com

ユーザー名: SYS

パスワード: SYSユーザーのパスワード

ロール: SYSDBA

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

5. 「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: idm

コンポーネント: Identity Management(Oracle Identity Federation - OIF)を選択します.その他のスキーマは選択を解除します。

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

6. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。

7. 「表領域のマップ」画面で、コンポーネントの表領域を選択します。

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

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

8.13.3 Oracle Identity Federationの高可用性の構成手順

高可用性環境では、Oracle WebLogic Serverのユーティリティを使用してOracle Identity Federationインスタンスのクラスタ化、ロード・バランシングおよびフェイルオーバーを行うことをお薦めします。

スキーマ・データベースが稼働中であることを確認してから、次の手順に従ってインストールします。

この項では、OIFHOST1およびOIFHOST2にOracle Identity Federationインスタンスをインストールして、構成する手順について説明します。

- 第8.13.3.1項「OIFHOST1でのOracle Identity Federationの構成」

- 第8.13.3.2項「OIFHOST1での管理サーバー用boot.propertiesの作成」

- 第8.13.3.3項「OIFHOST2でのOracle Identity Federationの構成」

- 第8.13.3.4項「Oracle Identity Federationのインストール後の手順」

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

- 第8.13.3.6項「Oracle Identity Federationの高可用性の検証」

- 第8.13.3.7項「Oracle Identity Federationと可用性の高いLDAPサーバーとの統合」

8.13.3.1 OIFHOST1でのOracle Identity Federationの構成

次の手順に従って、OIFHOST1上のOracle Identity Federationの1つ目のインスタンスを構成します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIFHOST1にインストールされ、アップグレードされていることを確認します。

3. ポート7499がこのコンピュータ上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":7499"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr "7499"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

ポート7499のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Identity Federationのポート番号を指定する行は非コメント化)を割り当てます。

# The port for OIF Server port
OIF Server Port No = 7499

7. 次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. ドメインの選択画面で、新規ドメインの作成を選択して、次の値を指定します。
ホスト名: OIFHOST1.MYCOMPANY.COM

ポート: 7001

ユーザー名: weblogic

パスワード: <weblogicユーザーのパスワード>

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

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所: この値は入力済になっており、更新できません。

/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ: この値は入力済になっており、更新できません。

oif

- WebLogic Serverのディレクトリ:

/u01/app/oracle/product/fmw/wlserver_10.3

- Oracleインスタンスの場所:

/u01/app/oracle/admin/oif_inst1

- インスタンス名: oif_inst1

注意:

OIFHOST1のOracleホームの場所を示すディレクトリ・パスが、OIFHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OIFHOST1のOracleホームの場所のディレクトリ・パスが/u01/app/oracle/product/fmw/oifである場合は、OIFHOST2のOracleホームの場所のディレクトリ・パスも/u01/app/oracle/product/fmw/oifである必要があります。

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

11. 「Oracle Configuration Managerの詳細の指定」画面で、次の例で示すように値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、Oracle Identity Federationコンポーネントを除く全製品の選択を解除します。Oracle Identity Federationコンポーネントには、Oracle Identity FederationとOracle HTTP Serverが含まれています。「クラスタ化」チェック・ボックスを選択します。
「次へ」をクリックします。

注意:

インストーラによって設定されるデフォルトのOracle WebLogic Serverのクラスタ・モードは、(マルチキャストではなく)ユニキャストになります。

図oifscreenshot1.gifの説明

13. 「ポートの構成」画面で、「構成ファイルを使用してポートを指定」を指定します。一時ディレクトリにコピーしたstaticports.iniファイルへのパスを入力します。
「次へ」をクリックします。

14. OIF詳細の指定画面で、次の値を指定します。

- PKCS12パスワード: <パスワード>

- パスワードの確認: <入力したパスワードの再入力>

- サーバーID: oif_OIFDomain

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

15. OIF拡張フロー属性の選択画面で、次の値を指定します。

- 認証タイプ: LDAP

- ユーザー・ストア: LDAP

- フェデレーション・ストア: LDAP

- ユーザー・セッション・ストア: RDBMS(デフォルトの選択、クラスタに対する変更は不可)

- メッセージ・ストア: RDBMS(デフォルトの選択、クラスタに対する変更は不可)

- 構成ストア: RDBMS(デフォルトの選択、クラスタに対する変更は不可)

注意:

拡張インストールの際にセッション、メッセージ、および構成のデータ・ストアにRDBMSを選択した場合は、インストーラによって、これら3つのすべてのデータ・ストアに対してデータ・ソースが1つ作成されます。

これらの各ストアに個別のデータベースを設定する場合は、インストール後に構成する必要があります。

図oifscreenshot2.gifの説明

16. 認証LDAPの詳細の指定画面で、次の例で示すように値を指定します。

- LDAPタイプ: ドロップ・ダウンから「Oracle Internet Directory」を選択します。

- LDAP URL: LDAPストアに接続するLDAP URLを次の形式で指定します(ldap://host:portまたはldaps://host:port)。例:

ldaps://oid.mycompany.com:636

- LDAPバインドDN: cn=orcladmin

- LDAPパスワード: <orcladminのパスワード>

- ユーザー資格証明ID属性: uid

- ユーザーの一意ID属性: orclguid

- 個人オブジェクト・クラス: inetOrgPerson

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

図oifscreenshot3.gifの説明

17. ユーザー・データ・ストアのLDAP属性の指定画面で、次の例で示すように値を指定します。

- LDAPタイプ: ドロップ・ダウンから「Oracle Internet Directory」を選択します。

- LDAP URL: LDAPストアに接続するLDAP URLを次の形式で指定します(ldap://host:portまたはldaps://host:port)。例:

ldaps://oid.mycompany.com:636

- LDAPバインドDN: cn=orcladmin

- LDAPパスワード: <orcladminのパスワード>

- ユーザー説明属性: uid

- ユーザーID属性: orclguid

- 個人オブジェクト・クラス: inetOrgPerson

- ベースDN: dc=us,dc=mycompany,dc=com

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

図oifscreenshot4.gifの説明

18. フェデレーション・データ・ストアのLDAP属性の指定画面で、次の例で示すように値を指定します。

- LDAPタイプ: ドロップ・ダウンから「Oracle Internet Directory」を選択します。

- LDAP URL: LDAPストアに接続するLDAP URLを次の形式で指定します(ldap://host:portまたはldaps://host:port)。例:

ldaps://oid.mycompany.com:636

- LDAPバインドDN: cn=orcladmin

- LDAPパスワード: <orcladminのパスワード>

- ユーザー・フェデレーション・レコード・コンテキスト: cn=myfed,dc=us,dc=mycompany,dc=com

- コンテナ・オブジェクト・クラス: Oracle Identity FederationがLDAPコンテナを作成するときに、このコンテナがまだ存在しない場合に使用するユーザー・フェデレーション・レコード・コンテキストのタイプです。このフィールドが空白の場合は、applicationprocessに値が設定されます。Microsoft Active Directoryの場合は、このフィールドをcontainerに設定する必要があります。

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

図oifscreenshot5.gifの説明

19. 一時ストア・データベースの詳細の指定画面で、次の例で示すように値を指定します。

- 接続文字列: データベースへの接続文字列を入力します。例:

infradbhost1-vip.mycompany.com:1521:oifdb1^infradbhost2-vip.mycompany.com:
1521:oifdb2@oif.mycompany.com

注意:

Oracle RACデータベースの接続文字列の情報は、host1:port1:instance1^host2:port2:instance2@servicenameの書式で指定する必要があります。

このインストール時に、すべてのOracle RACインスタンスを起動する必要はありません。1つのOracle RACインスタンスが起動されていれば、インストールを続行できます。

前述のように指定した情報は、完全で正確である必要があります。具体的には、ホスト、ポート、およびインスタンス名が各Oracle RACインスタンスに正しく指定されている必要があります。また、指定したOracle RACインスタンスのすべてにサービス名が構成されている必要があります。

Oracle RACデータベース接続文字列に入力した情報に誤りがある場合は、インストール後に手動で修正する必要があります。

- ユーザー名: OIFスキーマのユーザー名を入力します(例: ha_oif)。

- パスワード: oifユーザーのパスワード

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

図oifscreenshot6.gifの説明

20. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は「戻る」をクリックして前の画面に戻り、修正します。「インストール」をクリックします。

21. 「インストールの進行状況」画面で、インストールの進行状況を確認します。
インストールが終了すると、oracleRoot.shの確認ダイアログ・ボックスが表示されます。このダイアログ・ボックスは、インストールを続行する前に構成スクリプトをrootユーザーとして実行する必要があることを示しています。このダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootユーザーとしてログインして、次のスクリプト・ファイルを実行します。

/u01/app/oracle/product/fmw/oif/oracleRoot.sh

22. 構成の進行状況画面で、構成の進行状況を確認します。

23. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.13.3.2 OIFHOST1での管理サーバー用boot.propertiesの作成

boot.propertiesファイルを使用すると、administratorのユーザー名とパスワードの入力を求められることなく管理サーバーを起動できます。

boot.propertiesファイルを作成する手順は次のとおりです。

1. OIFHOST1で、次のディレクトリに移動します。

MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

例:

cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

2. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

username=adminUser
password=adminUserPassword

注意:

管理サーバーの起動時に、このファイルのユーザー名とパスワードのエントリは暗号化されます。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。

3. 管理サーバーが実行されている場合は停止します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。

4. MW_HOME/user_projects/domains/domainName/binディレクトリにある、startWebLogic.shスクリプトを使用して、OIFHOST1上の管理サーバーを起動します。

5. Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。

- WebLogic Server管理コンソール:

http://oidhost1.mycompany.com:7001/console

- Oracle Enterprise Manager Fusion Middleware Control:

http://oidhost1.mycompany.com:7001/em

weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

8.13.3.3 OIFHOST2におけるOracle Identity Federationの構成

次の手順に従って、OIFHOST2上のOracle Identity Federationの2つ目のインスタンスを構成します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

2. 第8.3.3.1項「Oracle Fusion Middlewareコンポーネントのインストール」の説明に従ってOracle Identity ManagementソフトウェアがOIFHOST2にインストールされ、アップグレードされていることを確認します。

3. OIFHOST1では、 Oracle Identity Federationによってポート7499が使用されています。OIFHOST2上のOracle Identity Federationインスタンスにも同じポートを使用する必要があります。ポート7499がOIFHOST2上のサービスによって使用されていないことを確認するために、次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep LISTEN | grep ":7499"

Windowsの場合:

netstat -an | findstr "LISTEN" | findstr "7499"

4. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

ポート7499のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

5. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

6. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle Identity Federationのポート番号を指定する行は非コメント化)を割り当てます。

# The port for OIF Server port
OIF Server Port No = 7499

7. 次のようにして、ORACLE_HOME/binディレクトリの下のOracle Identity Management 11g構成アシスタントを起動します。
UNIXでは、コマンド./config.shを発行します。

Windowsでは、config.exeをダブルクリックします。

8. 「ようこそ」画面で「次へ」をクリックします。

9. ドメインの選択画面で、「クラスタを開く」オプションを選択して、次の値を指定します。
ホスト名: OIFHOST1.MYCOMPANY.COM

ポート: 7001

ユーザー名: weblogic

パスワード: <weblogicユーザーのパスワード>

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

10. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所: この値は入力済になっており、更新できません。

/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ: この値は入力済になっており、更新できません。

oif

- WebLogic Serverのディレクトリ:

/u01/app/oracle/product/fmw/wlserver_10.3

- Oracleインスタンスの場所:

/u01/app/oracle/admin/oif_inst2

- インスタンス名: oif_inst2

注意:

OIFHOST1のOracleホームの場所を示すディレクトリ・パスが、OIFHOST2のOracleホームの場所を示すパスと同じであることを確認してください。たとえば、OIFHOST1のOracleホームの場所のディレクトリ・パスが/u01/app/oracle/product/fmw/oifである場合は、OIFHOST2のOracleホームの場所のディレクトリ・パスも/u01/app/oracle/product/fmw/oifである必要があります。

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

11. 「Oracle Configuration Managerの詳細の指定」画面で、次の例で示すように値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取るフィールドの横のチェック・ボックスを選択します。

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

12. 「コンポーネントの構成」画面で、Oracle Identity Federationコンポーネントを除く全製品の選択を解除します。Oracle Identity Federationコンポーネントには、Oracle Identity FederationとOracle HTTP Serverが含まれています。
「次へ」をクリックします。

13. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は「戻る」をクリックして前の画面に戻り、修正します。「インストール」をクリックします。

14. 「インストールの進行状況」画面で、インストールの進行状況を確認します。
インストールが終了すると、oracleRoot.shの確認ダイアログ・ボックスが表示されます。このダイアログ・ボックスは、インストールを続行する前に構成スクリプトをrootユーザーとして実行する必要があることを示しています。このダイアログ・ボックスを開いたままにして、別のシェル・ウィンドウを開き、rootユーザーとしてログインして、次のスクリプト・ファイルを実行します。

/u01/app/oracle/product/fmw/oif/oracleRoot.sh

15. 構成の進行状況画面で、構成の進行状況を確認します。

16. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

8.13.3.4 Oracle Identity Federationのインストール後の手順

この項のインストール後の手順に従って、Oracle Identity Federationアプリケーションのインストールと構成を完了します。

8.13.3.4.1 OIFHOST1からOIFHOST2へのOracle Identity Federation構成ディレクトリのコピー

OIFHOST1からOIFHOST2にOracle Identity Federation構成ディレクトリをコピーする手順は、次のとおりです。

OIFHOST1にあるディレクトリMW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif1/applicationsを、OIFHOST2のMW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif2/applicationsの場所にコピーします。

たとえば、OIFHOST1から次のコマンドを実行します。

scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif1/applicationsuser@OIFHOST2:/MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif2/applications

8.13.3.4.2 クラスタ内のOIFHOST2での管理対象サーバーの起動

次の手順に従って、クラスタ内でOIFHOST2上に新たに作成したwls_oif2管理対象サーバーを起動します。

1. WebLogic Server管理コンソールの左側のペインで、「環境」を開いて、「クラスタ」を選択します。
WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。

2. 停止する管理対象サーバー(wls_oif2)が存在するクラスタ(cluster_oif)のリンクをクリックします。

3. 「制御」を選択します。

4. 「このクラスタの管理対象サーバーのインスタンス」で、起動する管理対象サーバー(wls_oif2)の横のチェック・ボックスを選択して「起動」をクリックします。

5. 「クラスタ・ライフサイクル・アシスタント」ページで、「はい」をクリックして確定します。

ノード・マネージャによって、ターゲット・マシン上のサーバーが起動されます。ノード・マネージャによる起動シーケンスが終了すると、「サーバー状態」表の「状態」列にサーバーの状態が表示されます。

8.13.3.4.3 Oracle HTTP Serverの構成

Oracle HTTP Serverは、OIFHOST1およびOIFHOST2上にOracle Identity Federationサーバーとともにインストールされます。次の手順に従って、Oracle HTTP Serverを構成します。

1. OIFHOST1で、INSTANCE_HOME/config/OHS/ohsName/moduleconfディレクトリにあるoif.confファイルを編集します。

2. アイデンティティ管理インストールがスタンドアロン・モードの場合は、Oracle Identity Federationが実行されているWebLogic Serverの管理対象サーバーが反映されるようにWebLogicHostおよびWebLogicPort変数を非コメント化して設定します(例: oifhost1.mycompany.comと7499)。

3. アイデンティティ管理インストールがクラスタ化ノード内にある場合は、Oracle Identity Federationが実行されているWebLogic Server管理対象サーバーが反映されるようにWebLogicCluster変数を非コメント化して設定します(例: oifhost1.mycompany.com:7499、oifhost2.mycompany.com:7499)。

4. oif.confファイルを保存して終了します。

5. Oracle HTTP Serverを再起動します。

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

高可用性構成では、外部ロード・バランサをフロントエンドに使用して、様々なOracle Identity Federationインスタンス間のリクエストをロード・バランシングすることをお薦めします。

高可用性環境では、Oracle HTTP ServerインスタンスがOracle Identity Federationアプリケーションのフロントエンドに使用されていない場合、ハードウェア・ロード・バランサでスティッキー・セッションを有効化することをお薦めします。

8.13.3.5.1 ロード・バランサの仮想サーバー名の設定

詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。

8.13.3.5.2 Oracle Identity Federationの構成

ロード・バランサVIPを使用するようにOracle Identity Federationアプリケーションを構成する手順は、次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlで、「管理」→「サーバー・プロパティ」に移動します。

2. ホスト名とポートを変更し、ロード・バランサのホストとポートを反映するようにします。

3. Oracle Enterprise Manager Fusion Middleware Controlで、「管理」→「アイデンティティ・プロバイダ」に移動します。

4. URLをhttp://LoadBalancerHost:LoadBalancerPortに変更します。

5. Oracle Enterprise Manager Fusion Middleware Controlで、「管理」→「サービス・プロバイダ」に移動します。

6. URLをhttp://LoadBalancerHost:LoadBalancerPortに変更します。

7. Oracle Identity Federationがデプロイされている各管理対象サーバーで、この手順を実行します。

8.13.3.6 Oracle Identity Federationの高可用性の検証

高可用性構成のOracle Identity Federationを検証する手順は次のとおりです。

1. 正しく構成されていれば、Webブラウザで次のURLにアクセスできます。

http://<LoadBalancerHost>:<LoadBalancerPort>/fed/sp/metadata

http://<LoadBalancerHost>:<LoadBalancerPort>/fed/idp/metadata

2. Oracle Fusion Middleware Oracle Identity Federation管理者ガイドのサーバー・メタデータの取得に関する項と信頼できるプロバイダの追加に関する項の手順に従って、SPからメタデータをIdPに、IDPメタデータをSPにインポートします。

3. 次のURLに移動して、シングル・サインオンの操作を実行します。

http://<SP_Host>:<SP_port>/fed/user/testspsso

8.13.3.7 Oracle Identity Federationと可用性の高いLDAPサーバーとの統合

Oracle Identity Federationは、デフォルトでは、高可用性構成にデプロイされたLDAPサーバーと統合するように構成されていません。Oracle Identity Federationを可用性の高いLDAPサーバーと統合して、ユーザー・データ・ストア、フェデレーション・データ・ストア、または認証エンジンとして機能させるには、LDAPサーバーの機能に基づいてOracle Identity Federationを構成する必要があります。$ORACLE_HOME/common/binディレクトリの下にあるWLSTスクリプトを使用します。

Oracle Identity FederationにWLSTスクリプト環境を入力してから、必要に応じて次のプロパティを設定します。

- ユーザー・データ・ストアを可用性の高いLDAPサーバーと統合するには、datastoreグループのuserldaphaenabledブール型プロパティをtrueに設定します。統合しない場合はfalseに設定します。

setConfigProperty('datastore','userldaphaenabled', 'true', 'boolean')

- フェデレーション・データ・ストアを可用性の高いLDAPサーバーと統合するには、datastoreグループのfedldaphaenabledブール型プロパティをtrueに設定します。統合しない場合はfalseに設定します。

setConfigProperty('datastore', 'fedldaphaenabled','true', 'boolean')

- LDAP認証エンジンを可用性の高いLDAPサーバーと統合するには、authnenginesグループのldaphaenabledブール型プロパティをtrueに設定します。統合しない場合はfalseに設定します。

setConfigProperty('authnengines','ldaphaenabled', 'true', 'boolean')

8.13.4 Oracle Identity Federationのフェイルオーバーおよび予想される動作

この項では、高可用性環境にデプロイされたOracle Identity Federationインスタンスの様々なフェイルオーバー操作の実行手順と、予想される動作について説明します。この項の手順に従って、次の操作を実行します。

- Oracle Identity Federationインスタンスのフェイルオーバー

- Oracle Real Application Clustersのフェイルオーバー

8.13.4.1 Oracle Identity Federationのフェイルオーバーの実行

次の手順に従って、Oracle Identity Federationインスタンスのフェイルオーバーのテストを実行し、Oracle Identity Federationのステータスを確認します。

注意:

次の手順で指定されているtestspsso URLは、Oracle Identity Federation 11gにバンドルされているTest SP SSOサービスです。

テスト・サービスはデフォルトで有効化されていますが、管理者により無効にできます。本番環境では、Test SP SSOサービスを無効にできます。

Test SP SSOサービスが無効化されている場合は、SPからフェデレーションSSOフローを起動するように統合したサービスであればどのサービスでも使用できます。

1. フェデレーション・シングル・サインオン操作を実行できるように、Oracle Identity Federationを設定します。

2. サービス・プロバイダとして動作するOracle Identity Federationから、シングル・サインオン操作を開始します。これを実行する1つの方法として、http://<SPhost>:<SPport>/fed/user/testspsso URLを使用して、「アーティファクト」プロファイルを選択します。

3. IdPのログイン・ページで、「管理対象サーバー」ページからwls_oif1を停止し、ユーザー名とパスワードを入力します。

4. シングル・サインオン操作が正常に行われます。

8.13.4.2 Oracle RACフェイルオーバーの実行

Oracle RACフェイルオーバーを実行する手順は次のとおりです。

1. OIFスキーマがインストールされているデータベース・ホストの1つ(infradbhost1-vip)で、srvctlコマンドを使用してデータベース・インスタンスを停止します。

srvctl stop instance -d db_unique_name -i inst_name_list

2. srvctlコマンドを使用して、データベース・インスタンスのステータスを確認します。

srvctl status database -d db_unique_name -v

3. Oracle Identity Federationの操作を実行します。

ORACLE_INSTANCE/bin/opmnctl status ias-component=oif1

4. srvctlコマンドを使用して、データベース・インスタンスを起動します。

srvctl start instance -d db_unique_name -i inst_name_list

8.13.5 Oracle Identity Federationの高可用性のトラブルシューティング

次の情報は、Oracle Identity Federationに関する問題のトラブルシューティングに役立ちます。

- Oracle Identity Federationのメッセージは、Oracle WebLogic Server管理対象サーバーのログ・ファイルに記録されます。たとえば、次のファイルがあります。

DOMAIN_HOME/servers/wls_oif1/logs/wls_oif1-diagnostic.log

Oracle Enterprise Manager Fusion Controlを使用して、「Identity and Access」→OIF→「ログ」→「ログ・メッセージの表示」を選択することで、ログ・ファイルを表示することをお薦めします。

- Oracle Identity Federationで使用するデータベースに古い構成データがないことを確認します。古いデータが存在する場合、新しいデータで上書きされることがあります。Oracle Identity Federationがデータベースをポイントする前に、Oracle Identity Federation構成データベース表の古いデータを削除するか、スキーマを作成しなおします。

- Oracle Identity Federationサーバー構成のホスト名とポートには、ロード・バランサのホストとポートを設定してください(このように設定しない場合、シングル・サインオン操作でエラーが発生します)。

- IdPとSPが実行されている各コンピュータのクロックの時間が異なると、シングル・サインオンの際にエラーが発生します。これを修正するには、同じ時間になるようにシステム・クロックの時間を設定するか、Oracle Enterprise Manager Fusion Middleware Controlの「サーバー・プロパティ」ページを使用してサーバー・ドリフトを調整します。

- ProviderIdは、IdP/SPを一意に識別する文字列です。クラスタ内のすべてのサーバーのProviderIdを同じにする必要があります。インストール時のProviderIdのデフォルトは、host:port/fed/<sp|idp>です。必要に応じて、インストール後にこの値を変更または設定します。運用時には変更しないでください。

Oracle Identity Federationのトラブルシューティングの詳細は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドを参照してください。

8.14 コンポーネントの起動と停止

コンポーネントを起動および停止するには、『Oracle Fusion Middleware管理者ガイド』のコンポーネントの起動と停止に関する説明に記載されている手順を参照してください。

脚注の説明文
脚注 1: 使用されるエージェントはデプロイメント固有であり、デプロイメントによって(異なる機能を持つ)様々なタイプのエージェントを使用できます。
脚注 2: Oracle Access Managerは、組込み資格証明コレクタだけでなく、外部資格証明コレクタもサポートできます。
脚注 3: 資格証明収集は、非ユーザー名およびパスワード認証スキームでは異なります。
脚注 4: WebGateのみが、バック・チャネル通信をサポートします。
脚注 5: エージェントは、Webリソースへのリクエストの転送を許可する前に、セッション・リフレッシュなどのいくつかのハウスキーピング・タスクを実行することがあります。

9 Web層コンポーネントの高可用性の構成

Web層は、それぞれの受信HTTPリクエストを受信し、リクエストされたアプリケーションのビジネス・ロジックの処理を呼び出します。処理結果とモデルの状態に基づいて、次に表示するするビューが選択されます。選択されたビューは、表示するクライアントに送信されます。

この章では、Oracle HTTP ServerおよびOracle Web Cacheの高可用性の概要と構成手順について説明します。この章の項目は次のとおりです。

- 第9.1項「Web層について」

- 第9.2項「Oracle HTTP Serverと高可用性の概要」

- 第9.3項「Oracle Web Cacheと高可用性の概要」

9.1 Web層について

Java EEアプリケーション・サーバーのWeb層は、主にHTTPリクエストとレスポンスの形式で、Webブラウザなどのエンド・ユーザーと対話します。これは、アプリケーション・サーバーでは最も外側の層であり、エンド・ユーザーに最も近くなります。最も高いレベルでは、Web層は次の4つの基本的なタスクを行います。

- クライアント・リクエストの解釈

- ビジネス・ロジックをカプセル化するオブジェクト(Enterprise Java Beanなど)へのリクエストのディスパッチ

- 次に表示するビューの選択

- 次のビューの生成および配信

Web層は、それぞれの受信HTTPリクエストを受信し、リクエストされたアプリケーションのビジネス・ロジックの処理を呼び出します。処理結果とモデルの状態に基づいて、次に表示するするビューが選択されます。選択されたビューは、表示するクライアントに送信されます。

Oracle Web Cacheは、Web層に対しコンテンツを認識するサーバー・アクセラレータ、つまりリバース・プロキシであり、Oracle HTTP Serverで実行されるWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。

Oracle Web Cacheは、Oracle Fusion Middlewareで提供される主要なキャッシュ・メカニズムです。キャッシュにより、アクセス頻度の高いURLがメモリーに保存されて、Oracle Application Serverで実行するWebサイトのパフォーマンス、スケーラビリティ、および可用性が向上します。

アクセス頻度の高いURLをメモリーに保存することにより、Oracle Web Cacheは、データベース層およびアプリケーションWebサーバーのURLに対して、繰り返しリクエスト処理をする必要がなくなります。静的オブジェクトのみを処理するレガシー・プロキシとは異なり、Oracle Web Cacheでは、1つ以上のアプリケーションWebサーバーで生成されたコンテンツを、静的および動的にキャッシュされます。Oracle Web Cacheでは、レガシー・プロキシより多くのコンテンツをキャッシュできます。これにより、アプリケーションWebサーバーおよびデータベース層の負荷が大幅に削減され、最適なパフォーマンスが得られます。Oracle Web Cacheは外部キャッシュであるため、アプリケーション層内で実行されるオブジェクト・キャッシュよりも、処理が格段に速くなります。

Web Cacheは、HTTP 1.0および1.1の仕様に完全に準拠しているため、ApacheやIISなどの標準的な任意のWebサーバーでホストされるWebサイトの処理速度を向上させることができます。Oracle Fusion Middlewareでは、Oracle Web Cacheは、1つ以上のOracle HTTP Serverインスタンスの前面に配置します。HTTPリクエストに基づいたブラウザへのレスポンスは、Oracle HTTP Serverインスタンスに送られて、Oracle Web Cacheを介して送信されます。Oracle Web Cacheインスタンスでは、標準HTTPプロトコルで送信されたあらゆるWebコンテンツを処理できます。

9.2 Oracle HTTP Serverと高可用性の概要

Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。Oracle WebLogic Server用のリスナーと、静的および動的なページおよびアプリケーションをホストするフレームワークがWeb経由で提供されます。

9.2.1 Oracle HTTP Serverの単一インスタンスの特性

Oracle HTTP Serverは、Apache 2.2.10 インフラストラクチャをベースとしており、Oracleが専用に開発したモジュールが含まれます。シングル・サインオン、クラスタ・デプロイメント、高可用性の機能により、Oracle HTTP Serverの操作性が向上します。Oracle HTTP Serverには、クライアント・リクエストを処理する次のコンポーネントがあります。

- HTTPリスナー。受信リクエストを処理し、それを処理する適切なユーティリティにルーティングします。

- モジュール(mod)。Oracle HTTP Serverの基本的な機能を実装および拡張します。標準的なApacheモジュールの多くは、Oracle HTTP Serverに組み込まれています。また、Oracle HTTP Serverとその他のOracle Fusion Middlewareコンポーネントとの統合をサポートするために、Oracle Fusion Middlewareに固有のモジュールもいくつか組み込まれています。

- Perlインタプリタ。 mod_perlを介してOracle HTTP Serverに組み込まれた永続的なPerlのランタイム環境です。

Oracle HTTP Serverにより、開発者は次のような様々な言語およびテクノロジを使用してそのサイトをプログラムできます。

- Perl(mod_perlおよびCGIを使用)

- C(CGIおよび FastCGIを使用)

- C++(FastCGIを使用)

- PHP(mod_phpを使用)

- Oracle PL/SQL

Oracle HTTP Serverは、フォワードおよびリバースの両方で、プロキシ・サーバーとしても使用できます。リバース・プロキシでは、様々なサーバーで処理されたコンテンツを1つのサーバーから送信されたように処理することができます。

Oracle HTTP Serverは、本質的にはステートレスなアプリケーションです。セッションの状態はブラウザ・ベースのCookieを使用して保持できます。

図9-1 Oracle HTTP Serverアーキテクチャ

「図9-1 Oracle HTTP Serverアーキテクチャ」の説明

図9-1は、次のOracle HTTP Serverコンポーネントを示しています。

- Oracle Process Manager and Notification Server(OPMN)は、Oracle HTTP Serverを起動、停止および監視するために使用されます。OPMNでは定期的にOracle HTTP Serverをポーリングして、実行中であることを確認します。Oracle HTTP Serverが稼働していない場合は、OPMNによって適切な処置が取られ、障害が発生したコンポーネントは再起動されて、サービスの維持が保証されます。

- Oracle HTTP Serverは、業界トップのApache Webサーバーをベースとしています。Oracle HTTP Serverの中核機能は、次のモジュールを使用して拡張できます。

- mod_dmsモジュールにより、Oracle Dynamic Monitoring Service(DMS)を使用して、サイトのコンポーネントのパフォーマンスを監視できます。

- mod_onsintモジュールにより、Oracle Notification Service(ONS)とOPMNとの統合サポートを提供します。

- mod_oradavモジュールは、Cで記述されたOracle Call Interface(OCI)アプリケーションであり、mod_davの実装を拡張します。mod_oradavディレクティブは、ローカル・ファイルまたはOracle Databaseに対する読取りおよび書込みができます。

- mod_osslモジュールにより、Oracle HTTP Serverに対する強力な暗号化が有効になります。このOracleモジュールは、サーバーでのSSLの使用を可能にするOracle HTTP Serverへのプラグインです。

- mod_ossoモジュールにより、Oracle Single Sign-onを使用できます。

- mod_perlモジュールにより、PerlインタプリタがOracle HTTP Serverに組み込まれます。これにより、起動時のオーバーヘッドが排除され、Oracle HTTP Serverを介してPerlアプリケーションにアクセスできます。

- mod_plsqlモジュールにより、Oracle HTTP ServerはOracle Databaseに接続され、Oracleストアド・プロシージャを使用してWebアプリケーションを作成できるようになります。

- mod_wl_ohsモジュールにより、Oracle HTTP ServerからOracle WebLogic Serverへのリクエストをプロキシ処理できます。

9.2.1.1 Oracle HTTP ServerとOracle WebLogic Server

Oracle HTTP Serverに、Oracle WebLogicドメインは必要ありません。ただし、Oracle HTTP Serverは、通常、Oracle WebLogicドメインと連携して使用されます。

Oracle WebLogic管理対象サーバーへのリンクは、モジュールmod_wl_ohsを介して処理されます。このモジュールは、特定のタイプ(JSPなど)のリクエストのルーティング、およびURL、つまり特定のWebLogic管理対象サーバーへのリクエストのルーティングによって構成されています。非高可用性デプロイメントでは、WebLogic管理サーバーが配置されるホスト名およびポートを指定することでこのルーティング先を定義します。

高可用性デプロイメントでは、多くの場合WebLogic管理対象サーバーはまとめてクラスタ化されます。そのようなデプロイメントでは、特殊なmod_wl_ohsディレクティブWebLogicClusterにより、クラスタ・メンバーをカンマ区切りリストで指定します。このリストは、クラスタ・メンバーの完全なリストである必要はありません。WebLogic管理対象サーバーを必要とするリクエストが受信されると、mod_wl_ohsはそのリクエストを、ディレクティブにリストされているWebLogicクラスタ・メンバーの1つに送信します。WebLogic管理対象サーバーがリクエストを受信すると、そのリクエストを処理して、クラスタ・メンバーの完全なリストをmod_wl_ohsに送信して返します。mod_wl_ohsがその更新されたリストを受信すると、未知のサーバーが既知のサーバーのリストに動的に追加され、後続のリクエストはすべて完全なクラスタ・メンバー・リスト間でロード・バランシングされます。このプロセスは、mod_wl_ohsの更新またはOracle HTTP Serverの追加をせずに新しい管理対象サーバーをクラスタに追加できるというメリットがあります。

たとえば、WLS1、WLS2、WLS3で構成されたWebLogicクラスタがあるとします。ここで、WLS1とWLS2はmod_wl_ohsに認識されているとします。

mod_wl_ohsは、まず、リクエストを受信すると、そのリクエストをWLS1またはWLS2のいずれかへの送信を試みます。送信が成功すると、リストは更新され、以降のリクエストに対してWLS3も含まれます。ただし、WLS1とWLS2が使用不可でWLS3が使用可能な場合は、mod_wl_ohsがWLS3の存在を認識する方法がないため、リクエストは拒否されます。

Oracle WebLogicドメインでOracle HTTP Serverを使用する場合、Oracle HTTP ServerとWebLogicドメインを関連付けることをお薦めします。そうすることで、Oracle HTTP ServerをOracle Fusion Middlewareコンソールに組み込み、一元的な管理および監視が可能になります。

Oracle WebLogicクラスタの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。

9.2.1.2 Oracle HTTP Serverの外部依存性

Oracle HTTP Serverは、HTTPサーバー自らを起動するためにOracle Process Management and Notification Serverに依存します。

Oracle WebLogicやOracle Single Sign-Onなどその他のリソースにアクセスするには、Oracle HTTP Serverは適切なApacheモジュールをロードする必要があります。

9.2.2 Oracle HTTP Serverの起動とシャットダウンのライフサイクル

Oracle HTTP Serverプロセスは、OPMNを介して間接的に呼び出されます。OPMNがOracle HTTP Serverを起動するリクエストを受信すると、Oracle HTTP Serverプロセス(httpd)を起動します。

Oracle HTTP Serverが起動すると、HTTP(S)リクエストのリスニングおよび応答の準備が整います。Microsoft Windowsシステム上のリクエスト処理モデルは、UNIXシステム上のものとは異なります。

- Microsoft Windowsの場合、1つの親プロセスと1つの子プロセスが存在します。子プロセスは、クライアント・リクエストを処理するスレッドを作成します。作成されるスレッド数は静的で、パフォーマンスに応じて構成できます。

- UNIXでは、複数の子プロセスを管理する1つの親プロセスがあります。子プロセスは、リクエストの処理を行います。親プロセスは、構成に基づき、必要に応じて追加の子プロセスを生成します。サーバーには追加の子プロセスを動的に生成する機能がありますが、子プロセスを増加させることなくリクエストを処理できるように、最初に十分な数の子プロセスを起動するようにサーバーを構成しておくことをお薦めします。

9.2.3 Oracle HTTP Serverの起動と停止

Fusion Middleware Controlまたはopmnctlコマンドを使用して、Oracle HTTP Serverを起動および停止できます。

注意:

Oracle HTTP Serverの管理にapachectlユーティリティを使用しないでください。

opmnctlを使用して、次のようにOracle HTTP Serverのステータスを確認できます。

opmnctl status

Processes in Instance: instance1
---------------------------------+--------------------+---------+---------
ias-component                    | process-type       |     pid | status
---------------------------------+--------------------+---------+---------
webcache1                        | WebCache-admin     |   19556 | Alive
webcache1                        | WebCache           |   19555 | Alive
ohs1                             | OHS                |    7249 | Alive

9.2.3.1 PIDファイルの理解

Oracle HTTP Serverは起動時に、親httpdプロセスのプロセスID(PID)をhttpd.pidファイルに書き込みます。デフォルトでは、このファイルは次のディレクトリにあります。

ORACLE_INSTANCE/diagnostics/logs/OHSComponent/ohs1/

管理者は、デーモンを再起動および停止する場合にプロセスIDを使用できます。プロセスが異常終了した場合は、killコマンドを使用してhttpd子プロセスを停止する必要があります。

httpd.confのPidFileディレクティブで、PIDファイルの場所を指定します。

注意:

UNIXプラットフォームでPidFileディレクティブを編集する場合は、ORACLE_HOME/ohs/bin/apachectlファイルを編集して、PIDファイルの新しい場所を指定する必要もあります。

関連項目:

PidFileディレクティブの詳細は、次のサイトにあるApacheサーバーのドキュメントを参照してください。

http://httpd.apache.org/docs/

9.2.3.2 Oracle Fusion Middleware Controlを使用したOracle HTTP Serverの起動と停止

Fusion Middleware Controlを使用してOracle HTTP Serverを起動するには、次の手順を実行します。

1. Oracle HTTP Serverのホーム・ページへ移動します。

2. 「Oracle HTTP Server」メニューから「コントロール」を選択します。

3. 「コントロール」メニューから「起動」を選択します。

Fusion Middleware Controlを使用してOracle HTTP Serverを停止するには、次の手順を実行します。

1. Oracle HTTP Serverのホーム・ページへ移動します。

2. 「Oracle HTTP Server」メニューから「コントロール」を選択します。

3. 「コントロール」メニューから「停止」を選択します。

9.2.3.3 opmnctlを使用したOracle HTTP Serverの起動と停止

opmnctlを使用して、OracleインスタンスのすべてのOracle HTTP Serverコンポーネントを起動するには、次を実行します。

opmnctl startproc process-type=OHS

opmnctlを使用して、ohs1など、特定のOracle HTTP Serverコンポーネントを起動するには、次を実行します。

opmnctl startproc ias-component=ohs1

opmnctlを使用して、OracleインスタンスのすべてのOracle HTTP Serverコンポーネントを停止するには、次を実行します。

opmnctl stopproc process-type=OHS

opmnctlを使用して、ohs1など、特定のOracle HTTP Serverコンポーネントを停止するには、次を実行します。

opmnctl stopproc ias-component=ohs1

9.2.4 Oracle HTTP Serverの構成アーティファクト

Oracle HTTP Serverは、いくつかのオペレーティング・システム・ファイルを使用して構成されます。Oracle HTTP Serverをデプロイする場合、その構成情報は次のディレクトリ構造に配置されます。

- ORACLE_INSTANCE/config/OHS/OHS_NAME/

- ORACLE_INSTANCE/config/OHS/OHS_NAME/moduleconf

メインの構成ファイルは、ORACLE_INSTANCE/config/OHS/OHS_NAMEにあるhttpd.confです。その他の構成ファイルはすべて、このメイン・コントロール・ファイルから呼び出されます。

注意:

http.confファイルには、一般的なincludeディレクティブがあります。そのため、moduleconfディレクトリにある.conf拡張子のファイルはすべて自動的に構成に組み込まれます。Oracle PortalやOracle Formsなど、Oracleアプリケーションの多くのOracle HTTPディレクティブは、このディレクトリにあるファイルに配置されます。

9.2.5 Oracle HTTP Serverログ・ファイルの場所

Oracle HTTP Serverには2種類のログ・ファイルがあります。

- エラー・ログ。サーバーの問題が記録されます。

- アクセス・ログ。アクセスされたコンポーネントとアプリケーション、およびアクセスしたユーザーが記録されます。

Oracle Fusion Middleware Controlまたはテキスト・エディタを使用して、Oracle Fusion Middlewareログ・ファイルを表示できます。Oracle HTTP Serverのログ・ファイルは、次のディレクトリに配置されます。

ORACLE_INSTANCE/diagnostics/logs/OHS/OHS_NAME

ログ・ファイルのデフォルト名は、ohs_name.logです。

Oracle HTTP Serverログ・ファイルの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

9.2.6 Oracle HTTP Serverの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

図9-2は、ロード・バランサの後方に配置された2つのOracle HTTP Serverを示しています。ロード・バランサは、ユーザーからリクエストを受信して、それを接続されたOracle HTTP Serverに転送します。この例では、ロード・バランサは標準のHTTP/HTTPSポート(80/443)でリクエストを受信しますが、完全に別のポートを使用してOracle HTTP Serverにこのリクエストを送ります。これには、次のような利点があります。

- ユーザーからは実際のポートが見えなくなります。

- ユーザーは、ポート番号をURLに付加する必要がなくなります。

Unixベースのシステムでは、Oracle HTTP Serverをroot権限で起動する必要はありません。1024未満のポートを使用するプロセスを起動できるのは、rootのみです。

ロード・バランサは、稼働中のOracle HTTP Serverにリクエストをルーティングします。

図9-2 Oracle HTTP Serverの高可用性アーキテクチャ

「図9-2 Oracle HTTP Serverの高可用性アーキテクチャ」の説明

図9-2は、Oracle HTTP ServerがWeb Logic管理対象サーバーにリクエストを分散させるしくみを示しています。高可用性の場合、コンポーネントの各ペア(Oracle HTTP ServerとWeb Logic管理対象サーバー)は、別のホストに存在することを前提としています。

このアーキテクチャは、2つのサーバーに分けられています。また、より複雑な実装では、各コンポーネントは完全に別のサーバーに配置することもできます。

9.2.7 Oracle HTTP Serverの障害からの保護および予想される動作

Oracle HTTP Serverの障害は、プロセス障害とノード障害という2つのカテゴリに分類できます。Oracle HTTP Serverに障害が発生すると、個々のオペレーティング・システム・プロセスに障害が発生したり、ノード障害によりホスト全体に影響する場合があります。

プロセス障害

Oracle HTTP Serverプロセスは、Oracle Process Manager and Notification(OPMN)システムによって保護されます。Oracle HTTP Serverプロセスに障害が発生すると、OPMNは自動的にプロセスを再起動します。

ノード障害

ノード全体に障害が発生したときに、1つ目のOracle HTTP Serverが応答しない場合、またはURLのpingを使用して障害が発生していると判断された場合は、その前面にあるロード・バランサまたはOracle Web Cacheがリクエストを別のOracle HTTP Serverに送信します。

WebLogic管理対象サーバーの障害

高可用性デプロイメントでは、Oracle WebLogic管理対象サーバーはクラスタの一部になります。管理対象サーバーのいずれかに障害が発生した場合、mod_wl_ohsによってアクティブなクラスタ・メンバーのいずれかにリクエストが自動的にリダイレクトされます。アプリケーションに状態が格納されている場合、状態のレプリケーションがクラスタ内で使用可能になり、これにより、リダイレクトされたリクエストが、同じ状態情報にアクセスできます。

データベース障害

mod_oradavまたはmod_plsqlが使用されている場合にかぎり、データベース障害の問題が発生する可能性があります。このデータベースがOracle Real Application Clusters(Oracle RAC)データベースの場合は、定義済のOracle RAC接続により障害の特性が判断されます。

クライアント接続のフェイルオーバーが構成されている場合、進行中のすべてのトランザクションはロールバックされ、データベースへの再接続が必要になります。

透過的アプリケーション・フェイルオーバー(TAF)が構成されている場合は、進行中のすべてのデータベースの書込みはロールバックされますが、データベースへの再接続が自動的に行われ、select文は自動的にリカバリされます。このシナリオでは、TAFはselect文のみをフェイルオーバーし、パッケージ変数は失われます。

9.2.8 Oracle HTTP Serverのクラスタワイドの構成変更

Oracle HTTP Serversは、クラスタ化されたフレームワークにはデプロイされません。Oracle HTTPサーバー構成はファイルベースであるため、いずれかのOracle HTTP Serverに対して行われた変更は、その構成において他のOracle HTTP Serverに手動でコピーする必要があります。これは、htdocsディレクトリに格納されている静的HTMLファイルにも適用されます。

9.2.9 高可用性のためのOracle HTTP Serverの構成

この項では、例として、Oracle HTTP Serverの高可用性デプロイメントを構成する前提条件および手順について説明します。

9.2.9.1 前提条件

Oracle HTTP Serverの高可用性デプロイメントを構成する前に、次の前提条件を考慮します。

9.2.9.1.1 ロード・バランサ

Oracle HTTP Serverにリクエストを分散させるには、外部ロード・バランサまたはOracle Web Cacheの形式でのロード・バランサが必要となります。外部ロード・バランサを使用する場合は、次の機能が必要です。

- 仮想サーバー名とポートを構成する機能

- プロセス障害を検出する機能

- Oracle HTTPおよびHTTPSのためにポート(HTTP、HTTPS)を監視する機能

- SSLプロトコル交換(必要な場合)

ロード・バランサの仮想サーバー名とポートの構成

myapp.mycompany.comなどの各アプリケーションに対して、ロード・バランサの仮想サーバー名および関連するポートを構成します。Oracle HTTP Serverのインストールでは、これらの仮想サーバーはHTTP接続に対して構成され、この接続はHTTPサーバー全体に分散されます。

サイトでHTTPおよびHTTPS接続のリクエストを処理する場合は、HTTPSリクエストはロード・バランサで終了し、そのリクエストをHTTPリクエストとして通過させることをお薦めします。そのためには、ロード・バランサはプロトコル変換を実行できることが必要です。また、永続HTTPセッションを実行できるように構成する必要があります。

この例では、ロード・バランサが次のように構成されていることを想定します。

- 仮想ホスト: Myapp.mycompany.com

- 仮想ポート: 7777

- サーバー・プール: Map

- サーバー: WEBHOST1、ポート7777、WEBHOST2、ポート7777

ポート番号の管理

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

ほとんどのポート番号は、インストール時に割り当てられます。Oracle HTTP ServerからOracle WebLogic Serverに送信されるすべてのトラフィックは、すべてのファイアウォールを通じてアクセスできることが重要です。

9.2.9.1.2 Oracle HTTP ServerとWebLogicドメインとの関連付け

Oracle HTTP ServerをWebLogic管理サーバーに登録する場合は、そのサーバーが稼働しており、JMXリクエストを受け入れるように構成されている必要があります。

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

Oracle Fusion Middleware Web Tier and Plug-ins 11g(11.1.1.1.0)DVDインストールのOracle Universal Installerを、次のように起動します。

UNIXでは、runInstallerコマンドを実行します。

Windowsでは、setup.exeをダブルクリックします。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して、「次へ」をクリックします。

3. 「インストール場所の指定」画面で、次のインストールの場所を入力します。
/u01/app/oracle/product/FMW/Web1

4. 「前提条件のチェック」画面で、「次へ」をクリックします。

5. 「コンポーネントの構成」画面で、「Oracle HTTP Server」を選択して、「次へ」をクリックします。

注意:

このインストールをWebLogicドメインに関連付ける場合は、「選択されたコンポーネントとWebLogicドメインの関連付け」チェック・ボックスを選択します。

このインストールをWebLogicドメインに関連付けない場合は、「選択されたコンポーネントとWebLogicドメインの関連付け」チェック・ボックスの選択を解除します。この関連付けは、必要に応じて、インストール後に作成することもできます。

6. 「Weblogicドメインの詳細の指定」画面(オプション)で、次の値を入力します。

- ドメイン・ホスト名: WebLogic管理サーバーをホストしているサーバーの名前です(例: wladmin.mycompany.com)。

- ドメインのポート番号: WebLogic管理サーバーのポートです(例: 7001)。

- ユーザー名: WebLogic管理サーバーのユーザーです(例:WebLogic)。

- パスワード: 管理サーバーのパスワードです。

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

8. 「コンポーネントの詳細の指定」画面で、次の値を入力します。

- インスタンス・ホームの場所: /u01/app/oracle/admin/web1

- ASインスタンス名: web1

- OHSコンポーネント名: ohs1

- Webcacheコンポーネント名: webcache1

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

10. Web Cache管理者パスワード画面で、Web Cache管理者のパスワードを指定します。
有効なパスワード長は、5から30文字です。パスワードは英字で開始し、英数字、アンダースコア(_)、ドル記号($)、またはシャープ記号(#)のみを使用し、少なくとも1つの数字を含める必要があります。

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

12. 「Web Tierポートの詳細の指定」画面で、次のエントリを含むファイルを作成します。

- [OHS]#: OHSコンポーネントのhttp_mainポート

- OHSポート = 7777

ファイルを保存し、「構成」ファイル・オプションを使用して、ポートの指定を選択した後に「ファイル名」フィールドでファイル名を指定します。

注意:

すべてのWeb層のインスタンスで必ずしも同じポート番号にする必要はありませんが、同じにすることをお薦めします。この構成の例では、そのように想定されています。

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

14. 「構成サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は「戻る」をクリックして前の画面に戻り、修正します。

15. 「インストール」をクリックします。

16. 「構成」画面で、複数の構成アシスタントが連続して開始されます。この処理が終了したら、「次へ」をクリックします。
「インストール完了」画面が表示されます。

17. 「終了」をクリックします。

インストールの確認

次のOracle HTTP Serverホーム・ページにアクセスするURLを使用して、インストールを確認します。

http://webhost1:7777/

9.2.9.2.1 仮想ホストの構成

使用するそれぞれの仮想ホストまたはサイト名に対して、Oracle HTTP Serverの構成にエントリを追加します。次の内容を含むvirtual_hosts.confというファイルを、ORACLE_INSTANCE/config/OHS/ohs_component_name /moduleconfディレクトリに作成します。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName http://myapp.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

SSL/SSLターミネーション(*)を使用する場合は、次のようになります

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://myapp.mycompany.com:443
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

9.2.9.2.2 mod_wl_ohsの構成

Oracle HTTP Serverをインストールして構成したら、ORACLE_INSTANCE/config/OHS/ohs_nameディレクトリにあるmod_wl_ohs.confファイルを編集して、定義済のいずれかのWebLogic管理対象サーバーにOracle HTTP Serverをリンクします。

次にmod_wl_ohs.confエントリの例を示します。

LoadModule weblogic_module ORACLE_HOME/ohs/modules/mod_wl_22.so

<IfModule mod_weblogic.c>
WebLogicCluster apphost1.mycompany.com:7050, apphost2.mycompany.com:7050
Debug ON
WLLogFile /u01/app/oracle/admin/WL1/logs/mod_wl_ohs.log
MatchExpression *.jsp
</IfModule>

<Location /weblogic>
SetHandler weblogic-handler
WebLogicCluster apphost1.mycompany.com:7050,apphost2.com:7050
Debug ERR
WLLogFile /u01/app/oracle/admin/WL1/logs/mod_wl_ohs.log
DefaultFileName index.jsp
</Location>

注意:

SSLターミネーションを使用しており、なおかつWebLogicにリクエストをルーティングしている場合、次の追加の構成が必要です。

WebLogicコンソールで、「WebLogicプラグインの有効化を、ドメイン、クラスタ、または管理対象サーバーのレベルでtrueに設定する必要があります。

WebLogic管理対象サーバーにリクエストを転送するLocationブロックに、次の行も追加する必要があります。

WLProxySSL ON
WLProxySSLPassThrough ON

例:

<Location /weblogic>
SetHandler weblogic-handler
WebLogicCluster apphost1.mycompany.com:7050,apphost2.com:7050
WLProxySSL On
WLProxySSLPassThrough ON
Debug ERR
WLLogFile /u01/app/oracle/admin/WL1/logs/mod_wl_ohs.log
DefaultFileName index.jsp
</Location>

WebLogicプラグインを有効化した後、管理サーバーを再起動します。

この例は、Oracle WebLogic管理対象サーバーにリクエストをルーティングする2つの方法を示しています。

- <ifModule>ブロックでは、*.jspで終わるすべてのリクエストがApphost1およびApphost2上にあるWebLogic管理対象サーバーのクラスタに送信されます。

- <Location>ブロックでは、/weblogicで始まるURLのすべてのリクエストがApphost1およびApphost2上にあるWebLogic管理対象サーバーのクラスタに送信されます。

9.2.9.2.3 Oracle HTTP Serverの再起動

次のコマンドを使用して、Oracle HTTP Serverを再起動します。

opmnctl restartproc process-type=OHS

9.2.9.2.4 Oracle HTTP Serverの構成の検証

構成を検証するには、次のURLを使用します。

http://myapp.mycompany.com:7777/weblogic

http://myapp.mycompany.com:7777/weblogic

9.2.9.3 WEBHOST2へのOracle HTTP Serverのインストール

WEBHOST2で、第9.2.9.2項「WEBHOST1へのOracle HTTP Serverのインストール」の手順を実行します。

インストールの確認

次のOracle HTTP Serverホーム・ページにアクセスするURLを使用して、インストールを確認します。

http://webhost2:7777/

9.2.9.3.1 仮想ホストの構成

それぞれの仮想ホストまたはサイト名のエントリに対して、Oracle HTTP Serverの構成にエントリを追加します。virtual_hosts.confファイルをWEBHOST1からWEBHOST2にコピーします。このファイルは、ORACLE_INSTANCE/config/OHS/ohs_component_name/moduleconfディレクトリにあります。

9.2.9.3.2 mod_wl_ohsの構成

Oracle HTTP Serverをインストールして構成したら、WEBHOST1のORACLE_INSTANCE/config/OHS/ohs_component_nameディレクトリにあるmod_wl_ohs.confファイルをコピーして、定義済のいずれかのWebLogic ServerインスタンスにOracle HTTP Serverをリンクします。

9.2.9.3.3 Oracle HTTP Serverの再起動

次のコマンドを使用して、HTTP Serverを再起動します。

opmnctl restartproc process-type=OHS

9.2.9.3.4 Oracle HTTP Serverの構成の検証

構成を検証するには、次のURLを使用します。

http://myapp.mycompany.com/

https://myapp.mycompany.com(SSL/SSLターミネーションを使用している場合)

http://myapp.mycompany.com:7777/weblogic

9.3 Oracle Web Cacheと高可用性の概要

Oracle Web Cacheは、Web層に対しコンテンツを認識するサーバー・アクセラレータ、つまりリバース・プロキシであり、Oracle HTTP Serverで実行されるWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。Oracle Web Cacheは、Oracle Fusion Middlewareで提供される主要なキャッシュ・メカニズムです。キャッシュにより、アクセス頻度の高いURLがメモリーに保存されて、Oracle Application Serverで実行するWebサイトのパフォーマンス、スケーラビリティ、および可用性が向上します。アクセス頻度の高いURLをメモリーに保存することにより、Oracle Web Cacheは、データベース層およびアプリケーションWebサーバーのURLに対して、繰り返しリクエスト処理をする必要がなくなります。静的オブジェクトのみを処理するレガシー・プロキシとは異なり、Oracle Web Cacheでは、1つ以上のアプリケーションWebサーバーで生成されたコンテンツを、静的および動的にキャッシュされます。Oracle Web Cacheでは、レガシー・プロキシより多くのコンテンツをキャッシュできます。これにより、アプリケーションWebサーバーおよびデータベース層の負荷が大幅に削減され、最適なパフォーマンスが得られます。Oracle Web Cacheは外部キャッシュであるため、アプリケーション層内で実行されるオブジェクト・キャッシュよりも、処理が格段に速くなります。

9.3.1 Oracle Web Cacheの単一ノードの特性

Oracle Web Cacheは、HTTP 1.0および1.1の仕様に完全に準拠しています。そのため、ApacheやIISなどの標準的な任意のWebサーバーでホストされるWebサイトの処理速度を向上させることができます。Oracle Fusion Middlewareでは、Oracle Web Cacheは、1つ以上のOracle HTTP Serverインスタンスの前面に配置します。HTTPリクエストに基づいたブラウザへのレスポンスは、Oracle HTTP Serverインスタンスに送られて、Oracle Web Cacheを介して送信されます。Oracle Web Cacheインスタンスでは、標準HTTPプロトコルで送信されたあらゆるWebコンテンツを処理できます。

リバース・プロキシはクライアントからはコンテンツ・サーバーのように見えますが、内部的にはプロキシとしてそのオブジェクトを他のバックエンド・オリジナル・サーバーから取得します。リバース・プロキシは、オリジナル・サーバーのゲートウェイとして機能します。これは、ファイアウォール外部からのリクエストをファイアウォールの後方にあるオリジナル・サーバーに中継し、取得したコンテンツをクライアントに戻します。

図9-3は、リバース・プロキシのWebキャッシュの動作の概要を示しています。Oracle Web CacheのIPアドレスは144.25.190.241であり、アプリケーションWebサーバーのIPアドレスは144.25.190.242です。

ブラウザがOracle Web Cacheと対話する手順は、次のとおりです。

1. ブラウザはwww.company.com:80というWebサイトにリクエストを送信します。
このリクエストは、このWebサイトのIPアドレスについて ドメイン・ネーム・システム(DNS)へのリクエストを生成します。

2. DNSは、このサイトのロード・バランサのIPアドレス(144.25.190.240)を返します。

3. ブラウザは、Webページへのリクエストをロード・バランサに送信します。ロード・バランサは、このリクエストをOracle Web Cacheサーバー(144.25.190.241)に送信します。

4. リクエストされたコンテンツがキャッシュにあれば、Oracle Web Cacheはそのコンテンツを直接ブラウザに送信します。これは、キャッシュ・ヒットと呼ばれます。

5. Oracle Web Cacheにリクエストされたコンテンツがない場合、あるいはコンテンツが失効または無効な場合は、そのリクエストをアプリケーションWebサーバー(144.25.190.242)に送ります。これは、キャッシュ・ミスと呼ばれます。

6. アプリケーションWebサーバーは、Oracle Web Cacheにコンテンツを送信します。

7. Oracle Web Cacheは、このコンテンツをクライアントに送信して、ページのコピーをキャッシュに保存します。
キャッシュに保存されたページは、無効または期限切れになると削除されます。

図9-3 Webサーバーのアクセラレーション

「図9-3 Webサーバーのアクセラレーション」の説明

9.3.1.1 Oracle Web Cacheコンポーネントの特性

Oracle Web Cacheシステム・コンポーネントは、cacheサーバー・プロセスとadminサーバー・プロセスという2つのパフォーマンス指向のネイティブ・プロセスで構成されます。cacheサーバー・プロセスは、クライアントのリクエストを処理し、コンテンツをクライアントに返します。adminサーバー・プロセスは、管理、構成、および監視機能を提供します。

9.3.1.2 Oracle Web Cacheのプロセス監視

cacheおよびadminサーバー・プロセスは、Oracle Fusion Middleware Oracle Web Cache管理者ガイドの説明に従って、Oracle Process Manager and Notification Server(OPMN)で、Fusion Middleware Control、Oracle Web Cache Managerまたはopmnctlユーティリティを使用して管理します。

9.3.1.3 Oracle Web Cacheの起動とシャットダウンのライフサイクル

OPMNは、cacheおよびadminサーバー・プロセスを直接起動、停止、再起動、および監視します。Oracle Web Cacheの構成が静的に変更された場合は必ず、Oracle Web Cacheのプロセスを停止して再起動する必要があります。

cacheプロセスの実行可能ファイルはwebcachedであり、adminサーバー・プロセスの実行可能ファイルはwebcacheaです。これらの実行可能ファイルは、次のディレクトリにあります。

(UNIX) ORACLE_HOME/webache/bin
(Windows) ORACLE_HOME\bin

Oracle Web Cacheを停止すると、すべてのオブジェクトはキャッシュから削除されます。さらに、すべての統計も削除されます。

Oracle Web Cacheを構成したら、Oracle Web Cacheを再起動します。また、administratorのパスワードを変更した場合は、adminサーバーを再起動します。

Oracle Web Cacheを再起動するには、次のいずれかのツールを使用します。

- Fusion Middleware Controlまたはopmnctlコマンドライン・ユーティリティを使用して、cacheまたはadminサーバー・プロセスを再起動します。

- Oracle Web Cache Managerを使用して、cacheサーバー・プロセスを再起動します。

次のいずれかの構成設定を変更した場合は、cacheおよびadminサーバー・プロセスの両方を再起動する必要があります。

- 管理ポート・プロパティ

- 信頼できるサブネット

- ユーザーおよびグループID情報

Oracle Web Cacheの起動と停止の詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。

9.3.1.4 Oracle Web Cacheのリクエスト・フロー

図9-4は、Oracle Web Cache層内でのリクエスト・フローの詳細を示しています。

図9-4 Web層内でのOracle Web Cacheへのリクエスト・フロー

「図9-4 Web層内でのOracle Web Cacheへのリクエスト・フロー」の説明

図9-4に示しているように、Oracle Web Cache層内では次の処理が発生します。

1. 受信したブラウザ・リクエストは、HTTPフォーマットが正しいか分析されます。

2. そのブラウザ・リクエストはさらに分析され、それがHTTPSフォーマットであるか判断されます。

1. ブラウザ・リクエストがHTTPSフォーマットの場合は、Oracle Web CacheはSSLを復号化します。

2. ブラウザ・リクエストがHTTPSフォーマットでない場合は、Oracle Web Cacheはリクエストを解析します。

3. リクエストが解析されたら、一連の規定済のフィルタリング・ルールによりフィルタされます。

4. キャッシュ検索が実行され、このHTTPリクエストが以前に送信されキャッシュに残っているかを確認します。
リクエストがキャッシュ内に存在している場合(キャッシュ・ヒット)、リクエストは圧縮され、コンテンツが直接ブラウザに送信されます。

リクエストがキャッシュに存在しない(キャッシュ・ミス)場合は、次のいずれかが実行されます。

1. リクエストは、直接オリジナル・サーバーに送信されます。

2. リクエストは、ロード・バランシングされたオリジナル・サーバーに送信します。

ロード・バランシングされたそれぞれのオリジナル・サーバーは、定期的に各Oracle Web Cacheサーバーにpingしてキャッシュの状態をチェックします。ロード・バランサは、受信したリクエストをキャッシュ・クラスタ・メンバー間に分散させます。リクエストされたコンテンツがOracle Web Cacheにない場合、またはコンテンツが失効または無効な場合は、そのリクエストをアプリケーションWebサーバーに送ります。アプリケーションWebサーバーは、Oracle Web Cacheにコンテンツを送信します。Oracle Web Cacheは、このコンテンツをクライアントに送信して、ページのコピーをキャッシュに保存します。

オリジナル・サーバーのかわりに、プロキシ・サーバーはよりセキュアでないゾーン(非武装地帯(DMZ))に配置されます。

キャッシュ・ルールにより、キャッシュするオブジェクトが決定されます。特定のURLに対してキャッシュ・ルールを作成した場合、そのURLにあるオブジェクトは、クライアント・リクエストがあるまでキャッシュされません。クライアントが最初にオブジェクトをリクエストする場合は、Oracle Web Cacheはそのリクエストをオリジナル・サーバーに送信します。このリクエストはキャッシュ・ミスとなります。このURLには関連付けられたキャッシュ・ルールがあるため、Oracle Web Cacheは後続のリクエストのためにそのオブジェクトをキャッシュします。Oracle Web Cacheが同じオブジェクトに対して2回目のリクエストを受信した場合は、Oracle Web Cacheは、キャッシュからクライアントにオブジェクトを返します。このリクエストは、キャッシュ・ヒットとなります。

Oracle Web Cacheを停止すると、すべてのオブジェクトがキャッシュから削除されます。さらに、Oracle Web Cacheは統計を削除してリセットします。

9.3.1.5 Oracle Web Cacheの構成アーティファクト

Oracle Web Cacheの構成は、webcache.xmlファイルに保存されます。このファイルは、次のディレクトリにあります。

(UNIX) ORACLE_INSTANCE/instance_name/config/WebCache/webcache_name
(Windows) ORACLE_INSTANCE\instance_name\config\WebCache\webcache_name

構成ファイルを管理するために、2つのツールが用意されています。

- Fusion Middleware Control

- Oracle Web Cache Manager

特定の手順で、webcache.xml構成ファイルの編集が必要にならないかぎり、ファイルの編集はせず、これらのツールを使用してすべての管理タスクを実行します。ファイルを編集すると、設定に一貫性がなくなり、問題が発生する場合があります。

これらのツールの詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。

9.3.1.6 ログ・ファイルの場所

Oracle Web Cacheでは、イベントやエラーの情報はイベント・ログに記録されます。イベント・ログ・エントリにより、キャッシュに挿入されたオブジェクトの確認や、キャッシュ関連の問題についての警告ができます。Oracle Web Cacheは、リクエストを内部的に保存し、保存した内容をリクエストの最後にまとめて書き出します。リクエストベースのロギングにより、すべてのリクエストはまとめてグループ化されます。

デフォルトでは、Oracle Diagnostic Logging(ODL)テキスト形式のOracle Web Cacheのイベント・ログ・ファイル名はevent_logであり、ODL XML形式の名前はlog.xmlです。

Oracle Web Cacheでは、受信したHTTPリクエストに関する情報はアクセス・ログに記録されます。デフォルトでは、アクセス・ログの名前はaccess_logです。

Oracle Web Cacheではデフォルトで、次のディレクトリにログ・ファイルが保存されます。

(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

これらのツールの詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。

9.3.2 Oracle Web Cacheの高可用性に関する考慮事項

次の各項では、Oracle Web Cacheで使用可能な高可用性ソリューションについて説明します。

- 第9.3.2.1項「Oracle Web Cacheのステートレス・ロード・バランシング」

- 第9.3.2.2項「Oracle Web Cacheのバックエンドでのフェイルオーバー」

- 第9.3.2.3項「Oracle Web Cacheのセッション・バインディング」

- 第9.3.2.4項「Oracle Web Cacheのクラスタワイドの構成変更」

- 第9.3.2.5項「ソフトウェア・ロード・バランサとしてのOracle Web Cache」

9.3.2.1 Oracle Web Cacheのステートレス・ロード・バランシング

ほとんどのWebサイトでは、HTTPおよびHTTPSリクエストの負荷を共有する複数のコンピュータ上で稼働する複数のオリジナル・サーバーによって、サービスが提供されています。Oracle Web Cacheで処理できないリクエストは、すべてオリジナル・サーバーに送られます。Oracle Web Cacheでは、使用可能な容量の割合、各オリジナル・サーバーで重み付けされた使用可能な容量の割合を特定して、オリジナル・サーバー間で負荷を分散します。Oracle Web Cacheでは、最も高く重み付けされた使用可能な容量を持つオリジナル・サーバーにリクエストが送信されます。重み付けされた使用可能な容量は、次の式で求められます。

(Capacity - Load) / Capacity

説明:

- Capacityは、オリジナル・サーバーが受け入れ可能な同時接続の最大数です。

- Loadは、現在使用中の接続数です。

重み付けされた使用可能な容量が複数のオリジナル・サーバーで等しい場合は、Oracle Web Cacheではラウンドロビンを使用してリクエストをオリジナル・サーバーに送信します。ラウンドロビンを使用すると、構成されているサーバーのリストの最初のオリジナル・サーバーがリクエストを受信し、2番目のオリジナル・サーバーが2番目のリクエストを受信します。重み付けされた使用可能な容量が異なる場合、Oracle Web Cacheは、使用可能な容量が最も大きいオリジナル・サーバーにリクエストを送信します。

オリジナル・サーバーの負荷が同じ場合は、オリジナル・サーバーの容量が異なっていても、Oracle Web Cacheはラウンドロビンを使用し続けます。そのため、等しい容量で構成されていなくても、リクエストがオリジナル・サーバーに均等に分散されることもあります。

サイトのロード・バランシングを構成するには、各オリジナル・サーバーの容量を設定し、サイトとサーバー間のマップを1つ作成して、すべての適用可能なオリジナル・サーバーをこのサイトにマップします。

図9-5は、www.company.com:80とwww.server.com:80の2つのサイトを示しています。サイトwww.company.com:80は、アプリケーションWebサーバーcompany-host1とcompany-host2でサポートされ、それぞれの容量は50です。サイトwww.server.com:80は、アプリケーションWebサーバーserver-host1、server-host2、およびserver-host3でサポートされ、それぞれの容量は150、50、50です。

図9-5 ロード・バランシング

「図9-5 ロード・バランシング」の説明

すべてのアプリケーションWebサーバーの初期負荷が0とすると、www.company.com:80とwww.server.com:80へのリクエストは、次のように分散されます。

- www.company.com:80へのリクエストは、ラウンドロビンを使用して2つのオリジナル・サーバーに分散されます。
company-host1とcompany-host2へのリクエストは、負荷が等しく維持されるように、2つのオリジナル・サーバーに分散されます。最初のリクエストは、company-host1に送信されます。2番目のリクエストは、company-host1で最初のリクエストを処理中であれば、company-host2に送信されます。3番目以降のリクエストは、最も高く重み付けされた使用可能な容量を持つオリジナル・サーバーに送信されます。

容量が等しい場合、Oracle Web Cacheはラウンドロビンを使用してリクエストを分散させます。

- www.server.com:80へのリクエストは、重み付けされた使用可能な容量の割合を使用して3つのオリジナル・サーバーに分散されます。
www.server.com:80への最初のリクエストは、server-host1が構成リストの先頭にあるため、そこに送信されます。2番目のリクエストは、server-host2に送信されます。これは、server-host1が最初のリクエストを処理中であり、重み付けされた使用可能な容量は99.3 %となり、server-host2の重み付けされた使用可能な容量が100 %であるためです。3番目のリクエストは、server-host3に送信されます。これは、server-host2がリクエストを処理中で重み付けされた使用可能な容量は98 %となり、server-host3の重み付けされた使用可能な容量が100 %であるためです。4番目のリクエストは、server-host1に送信されます。これは、server-host2とserver-host3がリクエストを処理中で重み付けされた使用可能な容量が98 %となるためです。5番目のリクエストは、server-host1に送信されます。これは重み付けされた使用可能な容量が98.6 %となり、これがserver-host2とserver-host3それぞれよりも依然として大きいためです。

容量および負荷が異なる場合、Oracle Web Cacheは重み付けされた使用可能な容量を使用してリクエストを分散させます。新しいリクエストを受信する前にリクエストが処理されている場合、3つのオリジナル・サーバーはすべて負荷が0である可能性がありますその場合、Oracle Web Cacheはラウンドロビンを使用します。

容量の指定およびサイト・サーバー間マッピングの作成の詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。

9.3.2.2 Oracle Web Cacheのバックエンドのフェイルオーバー

指定された数の連続したリクエストの処理が失敗すると、Oracle Web Cacheはオリジナル・サーバーに障害が発生したとみなします。オリジナル・サーバーに障害が発生すると、Oracle Web Cacheは自動的に残りのオリジナル・サーバー間に負荷を分散させます。また、障害が発生したオリジナル・サーバーにポーリングし、そのサーバーがオンラインに戻るまで、稼働中または停止中かステータスを確認します。障害が発生したオリジナル・サーバーへの既存のリクエストはエラーとなります。ただし、新しいリクエストは、別のオリジナル・サーバーに送信されます。障害が発生したサーバーが再び運用されると、Oracle Web Cacheはそのサーバーを重み付けされた使用可能な容量に加え、リクエストをロード・バランシングします。

障害時のしくみを図9-6に示します。server-host3(障害直前の容量は50)の障害によって、リクエストの75 %がserver-host1に分散され、25 %がserver-host2に分散されます。

図9-6 フェイルオーバー

「図9-6 フェイルオーバー」の説明

フェイルオーバーのしきい値の指定方法は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。

9.3.2.3 Oracle Web Cacheのセッション・バインディング

Oracle Web Cacheを構成して、セッション・バインディングをサポートできます。これにより、特定のサイトのユーザー・セッションは、オリジナル・サーバーにバインドされ、一定の期間、状態が保持されます。この機能を使用するには、オリジナル・サーバー自体が状態を維持する(ステートフルである)必要があります。

セッション・バインディングが必要なオブジェクトに対するリクエストがオリジナル・サーバーに転送される場合、オリジナル・サーバーは、セッションCookieの形式でOracle Web Cacheを使用するか、埋込みURLパラメータを使用して、クライアントへのセッション情報を組み込み、ユーザー・セッションを作成します。Oracle Web Cacheでは、パラメータの値またはCookieを処理せず、情報をクライアント・ブラウザに返します。クライアントで後続リクエストにセッション情報が組み込まれた場合、Oracle Web Cacheは、そのリクエストをユーザー・セッションが最初に作成されたオリジナル・サーバーに転送します。Oracle Web Cacheは、ユーザー・セッションをその特定のオリジナル・サーバーにバインドします。

図9-7は、Oracle Web Cacheでセッション・バインディングを使用するオブジェクトをサポートするしくみを示しています。

図9-7 セッション・バインディング

「図9-7 セッション・バインディング」の説明

リクエストのセッション・バインディングを機能させるための手順は次のとおりです。

1. Oracle Web Cacheは、リクエストを初めて受信したときに、ロード・バランシング機能を使用してリクエストを転送するオリジン・サーバーを決定します。この例では、アプリケーションWebサーバーwww.server2.comが選択されています。

2. リクエストされたオブジェクトにセッション・バインディングが必要な場合、オリジナル・サーバーは、Cookie形式でOracle Web Cacheを使用するか、埋込みURLパラメータを使用して、セッション情報をクライアントに返します。

3. Oracle Web Cacheでは、このセッションの後続のリクエストを、ロード・バランシングをバイパスして、セッションを確立したオリジナル・サーバーに送信します。この例では、アプリケーションWebサーバーwww.server2.comで後続のリクエストを処理しています。

キャッシュ・クラスタを構成している場合、セッション・バインディングを構成する際に「内部-トラッキング」メカニズム・オプションは選択しないでください(これは、キャッシュ・クラスタでは機能しません)。キャッシュ・クラスタのその他のメカニズムは機能します。

セッション・バインディングの構成方法は、第9.3.2.3項「Oracle Web Cacheのセッション・バインディング」を参照してください。

9.3.2.4 Oracle Web Cacheのクラスタワイドの構成変更

Oracle Web Cacheでは、キャッシュ・クラスタを介して、クラスタワイドの機能を提供します。キャッシュ・クラスタでは、Oracle Web Cacheの複数のシステム・コンポーネントが1つの論理キャッシュとして機能します。この1つの論理キャッシュをキャッシュ・クラスタ・メンバーといいます。キャッシュ・クラスタ・メンバーは、相互に通信して、別のキャッシュ・クラスタ・メンバーでキャッシュされたキャッシュ可能なコンテンツをリクエストします。また、キャッシュ・クラスタ・メンバーに障害が発生した場合はそれを検出します。

図9-8は、3つのキャッシュ・クラスタ・メンバーを含むOracle Web Cacheクラスタを示しています。この図に示すように、クラスタ・メンバーは相互に通信し、さらにアプリケーションWebサーバーおよびクライアントとも通信します。

図9-8 Oracle Web Cacheのクラスタ・アーキテクチャ

「図9-8 Oracle Web Cacheのクラスタ・アーキテクチャ」の説明

Oracle Web Cacheでは、各キャッシュ・インスタンスの相対容量を使用して、キャッシュ・コンテンツをキャッシュ・クラスタ・メンバー間で分散させます。実際には、特定のオブジェクトの所有者になるキャッシュ・クラスタ・メンバーに割り当てられます。このコンテンツを所有されたコンテンツと呼びます。

所有されたコンテンツのほかに、Oracle Web Cacheでは、使用頻度の高いオブジェクトも各クラスタ・メンバーのキャッシュに保存されます。これらのオブジェクトは、オンデマンド・コンテンツと呼ばれます。オンデマンド・コンテンツを保存することによって、Oracle Web Cacheがそれらのオブジェクトに対するリクエストに迅速に応答するため、キャッシュ・ミス数が減少します。アプリケーションWebサーバーに送信されるリクエスト数も減少します。そのため、パフォーマンスが改善されます。

キャッシュ・クラスタでは、すべてのクラスタ・メンバーに同期化される1つの構成を使用します。その構成には、セキュリティ、セッション情報、キャッシュ・ルールなど、全般的な情報が含まれます。この構成は、すべてのクラスタ・メンバーで同じ内容になります。これには、容量、管理、その他のポート、リソース制限、ログ・ファイルなど、各クラスタ・メンバーのキャッシュ固有の情報も含まれます。

各メンバーをキャッシュ・クラスタに追加する前には、認証が必要になります。この認証には、Oracle Web Cacheインスタンスの管理ユーザー名とパスワードが必要です。クラスタの管理ユーザー名およびパスワードと同じものを、Oracle Web Cacheインスタンスの管理ユーザー名およびパスワードとして追加する必要があります。

キャッシュをクラスタに追加する場合、新しいクラスタ・メンバーのキャッシュ固有の情報は、キャッシュ・クラスタの構成に追加されます。次に、Oracle Web Cacheは、この構成をクラスタのすべてのメンバーに同期化します。新しいメンバーが追加されると各Webキャッシュの相対容量が変化するため、Oracle Web Cacheは容量に関する情報を使用して、各クラスタ・メンバーで所有するコンテンツを再計算します。

キャッシュ・クラスタ・メンバーで他のクラスタ・メンバーの障害を検出した場合は、残りのキャッシュ・クラスタ・メンバーが自動的に障害メンバーのコンテンツの所有権を引き継ぎます。そのキャッシュ・クラスタ・メンバーに再びアクセスできるようになると、Oracle Web Cacheはコンテンツの所有権を再割当てします。

キャッシュ・クラスタからWebキャッシュを削除する場合は、残りのキャッシュ・クラスタ・メンバーが削除されたメンバーのコンテンツの所有権を引き継ぎます。また、削除されたメンバーに関する構成情報は構成から削除され、修正された構成が残りのキャッシュ・クラスタ・メンバーに同期されます。

キャッシュ・クラスタの構成方法は、第9.3.3.2項「キャッシュ・クラスタの構成」を参照してください。

9.3.2.5 ソフトウェア・ロード・バランサとしてのOracle Web Cache

Oracle Web Cache専用のモードを構成し、Oracle Web CacheをHTTPトラフィックのソフトウェア・ロード・バランサとして単体で使用することができます。この構成モードは、次の用途に有効です。

- ボリュームの小さいサイト、部門レベルのサイト、またはテストWebサイトの管理

- ハードウェア・ロード・バランサとOracle PortalまたはOracle Single Sign-Onを使用したアプリケーション間のDMZのトラフィックの管理

このモードでは、キャッシュはすべてキャッシュされず、次の機能はサポートされません。

- 圧縮: Oracle Web Cacheはすべての圧縮設定を無視します。

- リクエスト・フィルタリング: Oracle Web Cacheはすべての構成リクエスト・フィルタおよびルールを無視します。

- ESI: Oracle Web CacheはESIコンテンツをアセンブルしません。

- キャッシュ階層: キャッシュ階層に2つのキャッシュ構成を計画している場合、キャッシュの1つをロード・バランサとして構成しないでください。

単一のOracle Web Cacheサーバーをロード・バランサとしてデプロイできます。ただしこのデプロイメントでは、Oracle Web Cacheサーバーがアプリケーションのシングル・ポイント障害になります。そのかわりに、オペレーティング・システムのロード・バランシング機能と連携し、複数のOracle Web Cacheサーバーを使用してキャッシュ・クラスタを構成できます。この項の前半で説明されている容量の変化に注意してください。

このモードでは、ESIを使用するアプリケーションの前面、または別のOracle Web Cacheの前面で、HTTPトラフィックをロード・バランシングするようにOracle Web Cacheを構成できます。Oracle Web Cacheのロード・バランサでは、ESIコンテンツの処理や階層キャッシュへの参加は行われません。たとえば、一般的なOracle Portalデプロイメントには、ESIアセンブリに使用される組込みのOracle Web Cacheがあります。このような構成では、ESIアセンブリに使用するOracle Web Cacheを、ロード・バランサとして構成しないでください。

キャッシュや圧縮のサポートなど、その他のOracle Web Cacheの機能が必要な場合は、このモードを構成しないでください。かわりに、ハードウェア・ロード・バランサまたはオペレーティング・システムのロード・バランシングのサポートを構成し、ロード・バランシング機能を使用してオリジナル・サーバーへのリクエストを管理します。

このモードの構成方法は、第9.3.3.3項「ソフトウェア・ロード・バランサとしてのOracle Web Cacheの構成」を参照してください。

9.3.3 Oracle Web Cacheの高可用性ソリューションの構成

次の各項では、それぞれの高可用性ソリューションを構成する方法について説明します。

- 第9.3.3.1項「Oracle Web Cacheのセッション・バインディングの構成」

- 第9.3.3.2項「キャッシュ・クラスタの構成」

- 第9.3.3.3項「ソフトウェア・ロード・バランサとしてのOracle Web Cacheの構成」

9.3.3.1 Oracle Web Cacheのセッション・バインディングの構成

セッション・バインディングを構成するには、一連のセッション・バインディング・ルールを指定して、そのルールをサイトに適用する必要があります。デフォルトでは、サイトはデフォルト・ルールを使用するように構成されます。デフォルト・ルールを使用することもできますが、サイト用にカスタマイズした別のルールを選択することもできます。

デフォルトのセッション・バインディング・ルールの値を変更する場合は、このルールで現在構成されているすべての名前付きサイトには、セッション・バインディングが必要になります。セッション・バインディングが不要なサイトがある場合は、デフォルト・ルールの値は変更せず、かわりにそのサイトに対するセッション・バインディング設定を指定します。

セッション・バインディングを構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。

2. 「Webキャッシュ」メニューから「管理」を選択して、「セッション構成」を選択します。

3. 「サイト」リストから、カスタマイズされたセッション・バインディングを作成するサイトを選択します。
「グローバル」を選択して、いずれの定義済サイトにも一致しないサイトおよびリクエストに対するデフォルト設定を指定します。カスタマイズされたセッション・バインディングをサイトに指定しない場合は、「グローバル設定を使用」オプションをクリックして、「グローバル」で指定した設定を適用します。「グローバル」のデフォルトの選択は、「セッション・バインディング無効化」です。「サイト」リストから「グローバル」を選択し、その他のセッション・バインディングに関する項目を選択して、デフォルトの設定を変更します。

4. 「セッション定義」表で、セッション定義を作成します。
- グローバル設定を使用: 構成したセッション・バインディング設定を「サイト」リストで選択した「グローバル」に適用する場合は、このオプションを選択します。

デフォルトでは、Oracle Web Cacheはすべてのリクエストに対してセッション・バインディングを無効にします。「グローバル」のデフォルトの選択は、「セッション・バインディング無効化」です。初めてサイトを作成する場合は、デフォルトでグローバル・セッション・バインディング設定を使用するように設定されます。

- セッション・バインディング無効化: セッション・バインディングを無効にする場合は、このオプションを選択します。これは、「グローバル」サイトのデフォルトの選択です。「サイト」リストから「グローバル」を選択し、その他のセッション・バインディングに関する項目を選択して、デフォルトの設定を変更します。

- Set-Cookieを使用したCookieに基づくセッション・バインディング: クライアントでCookieがサポートされ、アプリケーション・サーバーでセッション状態に1つ以上のCookieを使用する場合は、このオプションを選択します。Oracle Web Cacheでは、独自のCookieを使用してセッションを追跡します。このCookieは、ルーティング情報を含んでおり、Oracle Web Cacheとクライアントのブラウザとの間で保持されます。クライアントとアプリケーション・サーバーのバインディングは、アプリケーション・サーバーがクライアントに送信する最初のCookieにより初期化されます。

- セッションを使用したバインド: 特定のセッションのバインディングを有効にするには、このオプションを選択して、次の手順を実行します。

1. 「セッション名」リストから、特定のセッションに対するバインディングを有効にするセッションを選択します。

2. 「セッション・バインディング方式」リストから、選択したセッション定義に対して次のバインディング・メカニズムのいずれかを選択します。

3. 選択したセッション定義に対して次のバインディング・メカニズムのいずれかを選択します。
- Cookieに基づく: クライアントでCookieがサポートされている場合に選択します。Oracle Web Cacheでは、独自のCookieを使用してセッションを追跡します。このCookieは、ルーティング情報を含んでおり、Oracle Web Cacheとクライアントのブラウザとの間で保持されます。

- セッション・バインディングIAS: アプリケーションがOC4Jベースの場合に選択します。Oracle Web Cacheは、Oracle HTTP Serverを介して、各リクエストのルーティング情報をOC4Jに転送します。

- 内部-トラッキング: クライアントでCookieがサポートされておらず、アプリケーションがOracle HTTP ServerおよびOC4Jをベースとしていない場合に選択します。このオプションは、以前のリリースのOracle Web Cacheとの下位互換のために用意されています。Oracle Web Cacheでは、メモリー内ルーティング表を保持します。この表の各エントリでセッションIDとオリジナル・サーバーをマップします。ルーティング表は、クラスタ・ノード間で共有されません。このオプションを選択した場合、キャッシュ・クラスタ構成があると、ロード・バランサ層でもバインドを行う必要があります。

5. 「適用」をクリックして、変更を送信します。

6. Oracle Web Cacheを再起動します。

9.3.3.2 キャッシュ・クラスタの構成

キャッシュ・クラスタを構成するには、複数のOracle Web Cacheインスタンスをクラスタ・メンバーとして構成し、クラスタのプロパティを指定します。

キャッシュ・クラスタでは、現在のキャッシュ(クライアント・ブラウザが接続しているキャッシュ)からすべてのクラスタ・メンバーに同期化される1つの構成を使用します。この構成には、すべてのクラスタ・メンバーで同一の設定と、各クラスタ・メンバーのキャッシュ固有の設定が含まれます。

この項の項目は次のとおりです。ここでは、すべてのキャッシュが同じOracle WebLogic Serverに関連付けられる環境におけるキャッシュ・クラスタを構成できます。次の項目では、Fusion Middleware Controlを使用してクラスタを構成する方法について説明します。その環境では、すべてのキャッシュ・メンバーで同じOracle WebLogic Serverを使用する必要があります。

- 第9.3.3.2.1項「構成の前提条件」

- 第9.3.3.2.2項「フェイルオーバーのしきい値および容量設定の理解」

- 第9.3.3.2.3項「タスク1: クラスタへのキャッシュの追加とプロパティの構成」

- 第9.3.3.2.4項「作業2: セッション・バインディングのトラッキングの有効化」

- 第9.3.3.2.5項「タスク3: クラスタ・メンバーへの構成の同期化」

また、クラスタの構成の詳細は、次を参照してください。

- 第9.3.3.2.6項「クラスタからのキャッシュ・メンバーの削除」

- 第9.3.3.2.7項「管理および無効化専用のクラスタの構成」

複数のキャッシュが、異なるOracle WebLogic Serverと関連付けられている構成に対してキャッシュ・クラスタを構成する場合は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドの手順に従います。

9.3.3.2.1 構成の前提条件

キャッシュ・クラスタは2つ以上のOracle Web Cacheのインスタンスで構成されるため、キャッシュ・クラスタを構成する前に、1つ以上のノードに2つ以上のOracle Web Cacheインスタンスをインストールしておく必要があります。それらのインスタンスは、同じバージョンのOracle Web Cacheにする必要があります。また、Oracle Web Cacheの管理者および無効化用ユーザーinvalidatorの個々のパスワードは、クラスタ・メンバー間で同じにする必要があります。これらのパスワードが異なる場合は、キャッシュのadminサーバーに接続して管理パスワードを変更する必要があります。

9.3.3.2.2 フェイルオーバーのしきい値および容量設定の理解

構成を容易にするには、次のキャッシュ・クラスタおよびそのメンバーの主要な構成設定を理解します。

- キャッシュ・クラスタのフェイルオーバーのしきい値

- キャッシュ・クラスタ・メンバーの容量

キャッシュ・クラスタのフェイルオーバーのしきい値

キャッシュ・クラスタ・プロパティを構成する場合は、フェイルオーバーのしきい値を設定します。この設定は、Oracle Web Cacheが、別のキャッシュ・クラスタ・メンバーで障害が発生したことを認識するまでに許容される連続リクエスト失敗数を表しています。Oracle Web Cacheは、障害の発生したメンバーに対して一定の回数だけ連続して再試行した後で、そのキャッシュ・メンバーが停止しているとみなします。Oracle Web Cacheが再試行できる回数を、フェイルオーバーのしきい値と呼びます。

Oracle Web Cacheは、次の場合に、別のキャッシュ・クラスタ・メンバーへのリクエストが失敗したとみなします。

- なんらかのネットワーク・エラーがあった場合

- HTTPレスポンス・ステータス・コードが100未満の場合、または、次のいずれかの場合。500: サーバー内部エラー、502: 不正なゲートウェイ、503: サービス使用不可、504: ゲートウェイ・タイムアウト。

失敗した各リクエストに対して、Oracle Web Cacheはそのクラスタ・メンバーの失敗カウンタをインクリメントします。このカウンタは、各クラスタ・メンバー別に保持されます。リクエストがクラスタ・メンバーで正しく処理されると、Oracle Web Cacheは失敗カウンタをリセットします。

フェイルオーバーのしきい値に達すると、Oracle Web Cacheは、そのキャッシュ・クラスタ・メンバーに障害が発生したとみなします。Oracle Web Cacheは残りのキャッシュ・クラスタ・メンバーの相対容量を再計算します。次に、キャッシュ・コンテンツの所有権を再割当てします。

キャッシュ・クラスタ・メンバーが停止すると、Oracle Web Cacheは、そのキャッシュ・クラスタ・メンバーに対してポーリングを開始します。これは、指定したpingのURLにリクエストを送信することで実行されます。Oracle Web Cacheがそのキャッシュ・クラスタ・メンバーから成功レスポンスを受信すると、そのキャッシュ・クラスタ・メンバーが稼働を再開したとみなします。これは、キャッシュ・クラスタ・メンバーの相対容量を再計算し、キャッシュ・コンテンツの所有権を再割当てします。

キャッシュ・クラスタ・メンバーの容量

キャッシュ・クラスタ・メンバーを構成する場合は、そのメンバーの容量を指定します。

Oracle Web Cacheでは、次の2つの方法で容量を使用します。

- 他のすべてのキャッシュ・クラスタ・メンバーからこのキャッシュ・クラスタ・メンバーへの同時着信接続数に対する絶対容量として。
この接続を使用して、他のキャッシュ・クラスタ・メンバーから、所有されたコンテンツのリクエストを受信します。接続数は、他のクラスタ・メンバー間で分割されます。たとえば、3つのキャッシュ・クラスタがあり、Cache_Aの容量を50とすると、Cache_BとCache_CはCache_Aに対して、それぞれ25ずつ接続を開くことができます。

他のキャッシュ・クラスタ・メンバーのキャッシュにデータがほとんどない、または全くない場合は、より多くの接続が使用されます。たとえば、最初の起動時、障害のリカバリ時、または無効化の後などです。そのような場合、クラスタ・メンバーは多くのリクエストをそのピア(コンテンツの所有者)に送信します。多くの場合、これらのリクエストはオリジナル・サーバーへのリクエストより迅速に処理されます。その場合、接続数が多くなるにつれて、パフォーマンスが向上し、完全にキャッシュをロードする時間が短縮されます。キャッシュが完全にロードされると、使用される接続数は減少します。未使用の接続にオーバーヘッドはありません。

- キャッシュ・クラスタ・メンバーの相対容量として。
キャッシュ・クラスタ・メンバーの容量は、すべてのアクティブなキャッシュ・クラスタ・メンバーの合計容量に対して重み付けされます。容量を設定すると、Oracle Web Cacheによって、クラスタ・メンバーに所有権の配列の割合が割り当てられます。これは、クラスタ・メンバーが所有するキャッシュ・コンテンツの量を示します。割合は、次の式を使用して計算されます。

cluster_member_capacity / total_capacity_of_all_active_cluster_members

たとえば、キャッシュ・クラスタ・メンバーCache_Aに100の容量があり、キャッシュ・クラスタ・メンバーCache_Bに300の容量があり、合計で400の容量があった場合、Cache_Aには所有権配列の25 %が割り当てられ、Cache_Bには75 %が割り当てられます。つまり、Cache_Aはキャッシュ・コンテンツの25 %を所有します。

相対容量を計算する場合、Oracle Web Cacheはアクティブなクラスタ・メンバーの容量を考慮し、障害が発生したと判断したクラスタ・メンバーの容量は考慮しません。

それぞれのキャッシュ・クラスタ・メンバーの初期容量は、「最大着信接続数」の設定の10 %に設定します。

アプリケーションの容量の要件およびヒット率に対してより適切な案があれば、容量を微調整します。次の2つの前提がキャッシュ・クラスタに適用される場合、次の式を適用して各クラスタ・メンバーの容量を決定します:

1. 着信トラフィックが、すべてのキャッシュ・クラスタ・メンバーに均等に分散されます。

2. コンテンツの所有権が、すべてのキャッシュ・クラスタ・メンバー間で均等に分散されます。

次の式で、デフォルト値とmax_incoming_connections式を比較して大きい方の値を選択します。

max(default_value, (max_incoming_connections * (cacheable_misses%/100) * (number_of_caches - 1) / number_of_caches))

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

- default_valueは、次のいずれかの値です。

- 本番環境の場合、100

- テスト環境の場合、30

- 無効化専用クラスタの場合、0

容量が増加すると、Oracle Web Cacheで必要なファイル記述子の数も増加します。

- max_incoming_connectionsは、Fusion Middleware Controlの「リソース制限」ページの「最大着信接続数」設定の値です。

- cacheable_misses%は、Oracle Web Cacheからは直接処理されず、Oracle Web Cacheがオリジナル・サーバーからコンテンツをフェッチした後に処理されたキャッシュ可能オブジェクトに対するリクエストの割合です。
「キャッシュ可能ミス」設定は、Fusion Middleware Controlの「Web Cache統計」ページで確認できます。

たとえば、4つのメンバーを持つキャッシュ・クラスタがあるとします。Oracle Web Cacheが最大1500の着信接続を30%のキャッシュ可能なミス率で処理する場合、この構成の容量の計算式は次のようになります。

(1500 * (30/100) * (4 - 1) / 4

計算結果は337.5になります。これを切り上げて338とし、各キャッシュ・クラスタ・メンバーの容量にこの値を入力します。

1500 * .3 * 3 / 4 = 337.5

クラスタ・メンバーの容量に0を割り当てると、そのクラスタ・メンバーは他のクラスタ・メンバーからリクエストを受信しません。ただし、そのクラスタ・メンバーは、他のクラスタ・メンバー、つまりコンテンツの所有者にリクエストを転送します。すべてのクラスタ・メンバーの容量に0を割り当てると、クラスタ・メンバー間でリクエストの転送は行われません。容量が0に設定されていても、構成の同期化は可能です。また、Oracle Web Cacheは、無効化リクエストをクラスタ・メンバーに自動的に伝播します。

9.3.3.2.3 タスク1: クラスタへのキャッシュの追加とプロパティの構成

キャッシュをクラスタに追加する前に、第9.3.3.2.1項「構成の前提条件」で説明されている条件が満たされていることを確認します。

キャッシュ・メンバーをクラスタに追加するには、次の手順を実行します。

1. いずれかのOracle Web CacheインスタンスのFusion Middleware Controlで「Webキャッシュ・メンバー」ページに移動します。

2. 「Webキャッシュ」メニューから「管理」を選択して、「クラスタ」を選択します。

3. 追加するそれぞれのキャッシュ・メンバーに、次の手順を実行します。

1. 「追加」をクリックします。

2. 「コンポーネント」フィールドで、各メンバーの名前を入力します。
「容量」フィールドには、デフォルト値が自動的に入力されます。この値は変更できます。容量の詳細は、第9.3.3.2.2項「フェイルオーバーのしきい値および容量設定の理解」を参照してください。

4. 「フェイルオーバーのしきい値」フィールドで、Oracle Web Cacheが別のキャッシュ・クラスタ・メンバーで障害が発生したことを認識するまでに許容される連続リクエスト失敗数を入力します。
デフォルトの失敗数は5です。

このフィールドの詳細は、第9.3.3.2.2項「フェイルオーバーのしきい値および容量設定の理解」を参照してください。

5. 「pingのURL」フィールドに、フェイルオーバーのしきい値に達したキャッシュ・クラスタ・メンバーに、他のキャッシュ・クラスタ・メンバーがアクセスを試行する際に使用するURLを入力します。
キャッシュ可能で、各キャッシュに確実に保存できるURLを使用します。デフォルトは_oracle_http_server_webcache_static_.htmlで、キャッシュに保存されます。

6. 「pingの間隔」フィールドに、クラスタ・メンバーが障害クラスタ・メンバーにアクセスを試行する間隔の時間を秒単位で入力します。
デフォルトの10秒は、多くの環境で妥当な間隔です。

7. 「適用」をクリックします。

9.3.3.2.4 作業2: セッション・バインディングのトラッキングの有効化

キャッシュ・クラスタでは、最初はキャッシュ・クラスタ・メンバーを1つのみ介してリクエストがルーティングされましたが、すべてのキャッシュ・クラスタ・メンバーが、セッションを確立したオリジナル・サーバーを特定できる必要があります。

第9.3.3.2.3項「タスク1: クラスタへのキャッシュの追加とプロパティの構成」で、プロパティを設定したOracle Web Cacheに対して、セッション・バインディング・メカニズムによるセッション・バインディングを構成します。「内部-トラッキング」オプションは、キャッシュ・クラスタでは機能しないため、使用しないでください。

セッション・バインディングを構成するには、第9.3.3.1項「Oracle Web Cacheのセッション・バインディングの構成」を参照してください。

9.3.3.2.5 タスク3: クラスタ・メンバーへの構成の同期化

クラスタを変更してそれを適用すると、Oracle Web Cacheにより、新しいキャッシュ・クラスタ・メンバーのキャッシュ固有の情報が構成に追加されます。それらの変更をすべてのクラスタ・メンバーで有効にするには、構成を同期化してクラスタ・メンバーを再起動する必要があります。

新しく追加したキャッシュ・メンバーからクラスタ内の別のキャッシュに構成を同期化するには、次の手順を実行します。

1. 第9.3.3.2.3項「タスク1: クラスタへのキャッシュの追加とプロパティの構成」でプロパティを設定したOracle Web CacheのFusion Middleware Controlで「Webキャッシュ・メンバー」ページに移動します。

2. 「Webキャッシュ」メニューから「管理」を選択して、「クラスタ」を選択します。

3. クラスタ内の他のメンバーを選択して、「同期化」をクリックします。

4. すべてのキャッシュ・メンバーを選択し、キャッシュで処理を開始する時間調整の間隔を選択して、「起動」をクリックします。

これでキャッシュ・クラスタを使用する準備ができました。

9.3.3.2.6 クラスタからのキャッシュ・メンバーの削除

クラスタからキャッシュ・メンバーを削除する場合は、残りのクラスタ・メンバーがそのキャッシュをクラスタ内に含んでいないこと、および削除されたキャッシュがクラスタの一部とみなされないことを確認する必要があります。

Oracle Web Cache Managerでクラスタからキャッシュを削除するには、次の手順を実行します。

1. いずれかのOracle Web CacheインスタンスのFusion Middleware Controlで「Webキャッシュ・メンバー」ページに移動します(これはクラスタから削除するキャッシュではありません)。

2. 「Webキャッシュ」メニューから「管理」を選択して、「クラスタ」を選択します。

3. 削除するキャッシュを選択して、「削除」をクリックします。

4. クラスタ内の他のメンバーを選択して、「同期化」をクリックします。

5. 他のキャッシュを選択した状態で、「再起動」をクリックします。
これで、クラスタ内の残りのキャッシュはすべて、削除されたキャッシュをクラスタの一部と認識しなくなります。ただし、削除されたキャッシュでは、まだクラスタの一部と認識しています。この状況には、次の手順で対処します。

6. クラスタから削除したキャッシュのFusion Middleware Controlで「Webキャッシュ・メンバー」ページに移動します。

7. 「Webキャッシュ」メニューから「管理」を選択して、「クラスタ」を選択します。

8. 現在のキャッシュ以外のキャッシュを選択して、「削除」をクリックします。「クラスタ・メンバー」リストに現在のキャッシュのみが残るまで繰り返します。

9. 「再起動」をクリックします。

9.3.3.2.7 管理および無効化専用のクラスタの構成

すべてのキャッシュ・クラスタ・メンバー間で、構成および無効化リクエストの同期化をサポートするクラスタを構成できますが、リクエストはキャッシュ・クラスタ・メンバー間で転送されません。つまり、リクエストの処理時に、各クラスタ・メンバーは個々のキャッシュとして機能し、ピア・クラスタ・メンバーからのオブジェクトをリクエストしません。ただし、構成の変更および無効化リクエストは、クラスタ・メンバーへ同期化されます。

この構成を使用して、多くのキャッシュの管理を簡素化できます。これは、メンバーがファイアウォールで分けられているクラスタで必要になる可能性があります。たとえば、イントラネットとインターネットを分けるファイアウォールの両側に2つのキャッシュを配置するクラスタを構成できます。(そのようなネットワーク設定(片方のキャッシュにインターネット・トラフィックを送信し、もう一方にイントラネット・トラフィックを送信する設定)は、このドキュメントでは対象範囲外です。)

これらのキャッシュをクラスタとして管理し、キャッシュ間でコンテンツを共有しないようにするには、次の手順を実行します。

1. 第9.3.3.2.3項「タスク1: クラスタへのキャッシュの追加とプロパティの構成」および第9.3.3.2.4項「タスク2: セッション・バインディングの追跡の有効化」の説明に従って、クラスタを作成してメンバーをそれに追加しますが、次の例外があります:

- 各クラスタ・メンバーで、容量を0に設定します。

- 「クラスタ・プロパティ」セクションで、「任意のクラスタ・メンバーに送信された無効化リクエストは、すべてのクラスタ・メンバーに伝播されます。」オプションを選択します。

2. 第9.3.3.2.5項「タスク3: クラスタ・メンバーへの構成の同期化」の説明に従って、すべてのクラスタ・メンバーに構成を同期化します。

9.3.3.3 ソフトウェア・ロード・バランサとしてのOracle Web Cacheの構成

単一のOracle Web Cacheサーバーをソフトウェア・ロード・バランサとして構成するには、次の手順を実行します。

1. テキスト・エディタを使用して、次の場所にあるwebcache.xmlを開きます。

(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>

2. CACHE要素を探します。

3. ROUTINGONLY属性をCACHE要素に追加します。例:

...
<CACHE WCDEBUGON="NO" CHRONOSONPERNODE="NO" CAPACITY="301" VOTES="1"
INSTANCENAME="instance_name" COMPONENTNAME="component_name"  ORACLEINSTANCE="instance" HOSTNAME="host"
ORACLEHOME="directory" NAME="web_cache_name"
ROUTINGONLY="YES">
...

4. webcache.xmlを保存します。

5. 次のコマンドを使用して、Oracle Web Cacheを再起動します。

opmnctl restartproc ias-component=component_name

この実行ファイルは、次のディレクトリにあります。

(UNIX) ORACLE_INSTANCE/bin
(Windows) ORACLE_INSTANCE\bin

6. Oracle Web Cache Managerで、Oracle Web Cacheがロード・バランサ・モードで稼働していることを確認します。これは、「変更を適用」および「変更の取消」ボタンの下に表示される次のステータス・メッセージで確認できます。

Web Cache running in Routing Only Mode with current configuration

Fusion Middleware Controlのコンソールでは、同じ検証ステータスは表示されません。

7. Oracle Fusion Middleware Oracle Web Cache管理者ガイドの説明に従って、オリジナル・サーバーを構成します。

8. Oracle Fusion Middleware Oracle Web Cache管理者ガイドの説明に従って、サイト定義を作成し、それらをオリジナル・サーバーにマッピングします。

9. アプリケーション・デプロイメントにスティッキー・セッションが必要な場合は、セッション・バインディングを有効にします。第9.3.2.3項「Oracle Web Cacheのセッション・バインディング」を参照してください。

10 高可用性を最大化するIdentity Managementの構成

この章では、Oracle Identity Managementで最大限の 高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、地理的に異なる場所にある2つのサイトで構成されています。これは、デプロイメントが正常に機能している場合は、両方のサイトが同時にアクティブになるアクティブ/アクティブ・デプロイメントです。一方のサイトで障害が発生すると、障害が発生していないサイトで機能が続行されます。

各サイトは、2ノードのOracle Internet Directoryクラスタ構成で構成されており、Oracle Internet Directoryの高可用性を提供します。各サイトのOracle Internet Directoryクラスタ構成では、セキュリティ・ストアとしてOracle Real Applications Cluster(Oracle RAC)データベースを使用し、データベースの高可用性を提供します。第8章「Identity Managementコンポーネントの高可用性の構成」で、Oracle Internet Directoryクラスタ構成の高可用性の概要が説明されています。

マルチマスター・ レプリケーションでは、マスター・サイトからレプリカ・サイトへデータをレプリケートします。

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

- 第10.1項「高可用性を最大化するIdentity Managementデプロイメントの概要」

- 第10.2項「レプリケーションの概要」

- 第10.3項「マルチマスター・レプリケーションの設定」

10.1 高可用性を最大化するIdentity Managementデプロイメントの概要

図10-1は、Oracle Identity Managementの最大の高可用性デプロイメントを示しています。

図10-1 高可用性を最大化するマルチマスター・レプリケーション・デプロイメント

「図10-1 高可用性を最大化するマルチマスター・レプリケーション・デプロイメント」の説明

マスター・サイトはニューヨークに、レプリカ・サイトはロサンゼルスにあります。

各サイトは、可用性の高い2ノードのOracle Internet Directoryクラスタ構成で構成されており、可用性の高いセキュリティ・ストアとしてOracle RACデータベースを使用しています。2ノード・クラスタにはそれぞれ、ロード・バランサが1つ配置されています。2ノードOracle Internet Directoryクラスタの設定の詳細は、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。

ニューヨークのマスター・サイトの構成は次のとおりです。

- OIDHOST1およびOIDHOST2
クラスタ化された2つのホストがあり、Oracle Internet Directoryがインストールされています。

- RAC_DB1
OIDHOST1およびOIDHOST2上のOracle Internet Directoryインスタンスのセキュリティ・ストアとして機能するOracle RACデータベースです。マルチマスター・レプリケーションでは、ニューヨークのRAC_DB1とロサンゼルスのRAC_DB2との間でデータをレプリケートします。

ロサンゼルスのレプリカ・サイトの構成は次のとおりです。

- OIDHOST3およびOIDHOST4
クラスタ化された2つのホストがあり、Oracle Internet Directoryがインストールされています。

- RAC_DB2
これは、OIDHOST3およびOIDHOST4上のOracle Internet Directoryインスタンスのセキュリティ・ストアとして機能するOracle RACデータベースです。マルチマスター・レプリケーションによって、ニューヨークのRAC_DB1とロサンゼルスのRAC_DB2との間でデータがレプリケートされます。

10.2 レプリケーションの概要

Oracle Internet Directoryで使用できる レプリケーションのタイプは次のとおりです。

- LDAPマルチマスター・レプリケーション
レプリケーション転送メカニズムに、業界標準のLightweight Directory Access Protocol Version 3を使用します。このプロトコルは、レプリケーションへの使用に推奨されています。

- Oracle Advanced Databaseマルチマスター・レプリケーション
Oracle Databaseのレプリケーション機能を使用しますが、これはアドバンスト・レプリケーションとも呼ばれます。

- 双方向のファンアウト・レプリケーション
このレプリケーション・メソッドでは、マスター・サイトとレプリカ・サイトの両方で、レプリケートされたデータの読取り/書込みが行われます。ファンアウト・レプリケーションでは、転送メカニズムにLDAPを使用します。

- 一方向のファンアウト・レプリケーション
このレプリケーション・メソッドでは、レプリケートされたデータは、レプリカ・サイトで読取り専用になります。ファンアウト・レプリケーションでは、転送メカニズムにLDAPを使用します。

Oracle Internet Directoryのレプリケーション・タイプの詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドを参照してください。

図10-1で示した、最大可用性のデプロイメントには、LDAPまたはOracle Advanced Databaseマルチマスター・レプリケーションを設定できます。

10.3 マルチマスター・レプリケーションの設定

この項では、図10-1で示した最大高可用性のOracle Internet DirectoryデプロイメントでLDAPマルチマスター・レプリケーションまたはOracle Advanced Databaseマルチマスター・レプリケーションを設定する方法について説明します。

注意:

図10-1で示したニューヨークとロサンゼルスのマルチマスター・トポロジに、Oracle Internet Directoryを2ノード・クラスタでインストールする方法の詳細は、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。

Oracle Internet Directoryデプロイメントの高可用性を最大化するには、LDAPマルチマスター・レプリケーションの使用をお薦めします。

注意:

Oracle Fusion Middleware 11gを新たに使用して、11g Oracle Internet Directoryに10.1.4.3以降のOracle Single Sign-OnおよびOracle Delegated Administration Servicesのインストールと構成を行い、マルチマスター・レプリケーションを設定する場合は、次の手順を参照してください。

1. 10.1.4.3 Oracle Single Sign-OnおよびOracle Delegated Administration Servicesを、11g Oracle Internet Directoryに対して実行するように構成するには、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOracle Single Sign-OnおよびOracle Delegated Administration Servicesユーザーに対する特別な指示に関する項を参照してください。

2. 10.1.4.3のOracle Single Sign-OnおよびOracle Delegated Administration Servicesをインストールしてマルチマスター・レプリケーションを構成するには、リリース10.1.4.0.1のOracle Fusion Middleware高可用性ガイド(原本部品番号B28186-01)の、マルチマスター・レプリケーションを使用したIdentity Managementのデプロイに関する章にある次の各項の手順を実行します。

- 第10.1.4項「マスター・ノードへのOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesのインストール」

- 第10.1.5項「OracleAS Single Sign-Onスキーマ・パスワードの同期化」

- 第10.1.6項「レプリカ・ノードへのOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesのインストール」

- 第10.1.7項「SSLモードで実行する場合」

10.3.1 LDAPマルチマスター・レプリケーションの設定

LDAPマルチマスター・レプリケーションを設定するには、Oracle Enterprise Manager Fusion Middleware Controlで次の手順を実行します。

1. Oracle Internet Directoryインスタンスのホーム・ページの「Oracle Internet Directory」メニューで、「管理」を選択し、「レプリケーション管理」を選択します。

2. レプリケーションDNアカウントにログインするように求められます。マスター・サイト(図10-1のニューヨーク・クラスタ)にある、いずれかのOracle Internet Directoryサーバーのホスト、ポート、レプリケーションDN、およびレプリケーションDNパスワードを入力します。このOracle Internet Directoryコンポーネントで匿名バインドが有効化されている場合は、ホストとポートを入力すると「レプリケーションDN」フィールドが自動的に入力されます。

3. 「作成」をクリックします。

4. 「タイプ」画面で、レプリケーション・タイプに「マルチマスター・レプリケーション」を選択します。

5. 「次へ」をクリックします。選択したレプリケーション・タイプが「レプリカ」画面に表示されます。

6. すべてのノード間で一意であるアグリーメント名を指定します。

7. マルチマスター・レプリケーションに対して、1次ノードおよびすべての2次ノードの各ホスト、ポート、ユーザー名(レプリケーションDN)、およびレプリケーション・パスワードを入力します。

注意:

クラスタ内の任意のOracle Internet Directoryインスタンスのホスト/ポートを入力します。

8. 「次」をクリックして「設定」ページに移動します。

9. レプリケーション・サーバーで同じ接続を使用して複数のLDAP操作を実行する場合は、「LDAP接続」フィールドで、「キープ・アライブ」を選択します。それぞれのLDAP操作に対して新規に接続を開始する場合は、「常に新規の接続を使用」を選択します。

10. 「レプリケーション頻度」を入力します。

11. 「管理者操作キュー・スケジュール」を入力します。これは、ディレクトリ・レプリケーション・サーバーが変更適用プロセスを繰返し実行する分単位の時間間隔です。

12. 「レプリケーション・サーバー起動詳細」画面には、レプリケーション・サーバーを起動し、ブートストラップを有効にするオプションがあります。「サーバーの起動」を選択して、適切なサーバー・インスタンスを起動します。「ブートストラップの有効化」を選択して、ブートストラップを有効化することもできます。サーバーを起動するには、ドロップダウン・リストから、「インスタンス名」と「コンポーネント名」を選択する必要があります。

13. 「次へ」をクリックして「有効範囲」ページに移動します。デフォルトのプライマリ・ネーミング・コンテキストが入力されます。デフォルトの設定を保持します。

14. 「次へ」をクリックします。「サマリー」ページに作成するレプリケーション承諾のサマリーが表示されます。「サマリー」ページの情報を変更するには、「戻る」をクリックします。

15. 「終了」をクリックして、レプリケーション承諾を作成します。

LDAPマルチマスター・レプリケーションの設定の詳細は、Oracle Enterprise ManagerツールチップまたはOracle Fusion Middleware Oracle Internet Directory管理者ガイドを参照してください。

10.3.1.1 LDAPマルチマスター・レプリケーションへのノードの追加

LDAPマルチマスター・レプリケーション・デプロイメントにノードを追加するには、Oracle Enterprise Manager Fusion Middleware Controlで次の手順を実行します。

1. Oracle Internet Directoryインスタンスのホーム・ページの「Oracle Internet Directory」メニューで、「管理」を選択し、「レプリケーション管理」を選択します。

2. レプリケーションDNアカウントにログインするように求められたら、マルチマスター・レプリケーション・デプロイメントにある、任意のレプリカのホスト、ポートおよびレプリケーションDNパスワードを入力します。

3. 画面の上部で、該当するマルチマスター・レプリケーション承諾の行をクリックして、編集可能にします。

4. 「レプリケーション承諾」ページで、「編集」をクリックします。

5. 画面の下部の「レプリカ」タブをクリックします。

6. マルチマスター・レプリケーション・デプロイメントに新しいレプリカを追加するには、「作成」をクリックします。

7. 新しいノードのホスト、ポートおよびレプリケーションDNパスワードの詳細を入力します。「追加」をクリックします。

8. 「適用」をクリックします。既存のマルチマスター・ディレクトリ・レプリケーション・グループ(DRG)にレプリカが追加されます。

詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。

10.3.1.2 LDAPマルチマスター・レプリケーションからのノードの削除

LDAPマルチマスター・レプリケーション・デプロイメントからノードを削除するには、Oracle Enterprise Manager Fusion Middleware Controlで次の手順を実行します。

1. Oracle Internet Directoryインスタンスのホーム・ページの「Oracle Internet Directory」メニューで、「管理」を選択し、「レプリケーション管理」を選択します。

2. レプリケーションDNアカウントにログインするように求められます。マルチマスター・レプリケーション・デプロイメントにある、任意のレプリカのホスト、ポート、およびレプリケーションDNパスワードを入力します。

3. 画面の上部で、該当するマルチマスター・レプリケーション承諾の行をクリックして、編集可能にします。

4. 「レプリケーション承諾」画面で、「編集」をクリックします。

5. 画面の下部の「レプリカ」タブをクリックします。

6. マルチマスター・レプリケーション・デプロイメントから削除するレプリカをクリックします。

7. 「削除」をクリックします。

8. 「適用」ボタンをクリックして、LDAPマルチマスター・ディレクトリ・レプリケーション・グループ(DRG)からレプリカを削除します。

LDAPマルチマスター・レプリケーション・デプロイメントにおけるノードの削除の詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドを参照してください。

10.3.2 Oracle Advanced Databaseマルチマスター・レプリケーションの設定

Oracle Advanced Databaseマルチマスター・レプリケーションのセットアップの詳細な手順は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのOracle Databaseアドバンスト・レプリケーションベース・マルチマスター・レプリケーション・グループのインストールとセットアップに関する項に記載されています。

表10-1は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のOracle Databaseアドバンスト・レプリケーションベース・マルチマスター・レプリケーション・グループのインストールとセットアップに関する項に含まれる各項を示しています。また、図10-1に示す最高の高可用性Oracle Internet Directoryデプロイメントに対してOracle Advanced Databaseマルチマスター・レプリケーションをセットアップするために各項で実行する手順も説明しています。

表10-1 Oracle Databaseアドバンスト・マルチマスター・レプリケーションの設定手順

項

手順

タスク1: マスター定義サイト(MDS)へのOracle Internet Directoryのインストール

このタスクは、第10.3項「マルチマスター・レプリケーションの設定」の注意に従って、事前に実行しておく必要があります。

タスク2: リモート・マスター・サイト(RMS)へのOracle Internet Directoryのインストール

このタスクは、第10.3項「マルチマスター・レプリケーションの設定」の注意に従って、事前に実行しておく必要があります。

既存のマスターをリモート・マスター・サイトとして使用する場合

任意のサイト(ニューヨーク・サイト)をマスター定義サイト(MDS)として設定します。次に、そのマスター・サイトのクラスタ内に、任意のOracle Internet Directoryノード(OIDHOST1)を設定して、マスター・ホストにします。OIDHOST1は、マスター・サイト・クラスタ内のホストになります。また、ホスト上で実行するレプリケーション・サーバーが構成されます。設定手順の中で、MDSに対するレプリケーション・サーバー、プロセス、またはポートへの参照が必要となった場合は、OIDHOST1の値を正確に指定します。

別のサイト(ロサンゼルス・サイト)をリモート・マスター・サイト(RMS)として設定します。次に、そのリモート・サイトのクラスタ内に、任意のOracle Internet Directoryノード(OIDHOST3)を設定して、レプリカ・ホストとします。(「既存のマスターをリモート・マスター・サイトとして使用する場合」の項では、このレプリカ・ホストは「新しいノード」と呼ばれています)。OIDHOST3は、ロサンゼルス・クラスタ内のホストになります。また、ホスト上で実行するレプリケーション・サーバーが構成されます。設定手順の中で、RMSに対するレプリケーション・サーバー、プロセス、またはポートへの参照が必要となった場合は、OIDHOST3の値を正確に指定します。

タスク3: ディレクトリ・レプリケーション・グループのアドバンスト・レプリケーションの設定

次のタスクの説明に従います。

すべてのノードで、レプリケーションのためのOracle Net Services環境を準備します。

ニューヨークとロサンゼルス・サイトのすべてのデータベースのOracleホーム、およびすべてのOracle Internet DirectoryのOracleホームで、この項の手順を実行します。

MDSから、ディレクトリ・レプリケーションのアドバンスト・レプリケーションを構成します。

次の場合を除いて、ニューヨークとロサンゼルスのすべてのOracle Internet DirectoryのOracleホームで、この項の手順を実行します。

レプリケーション環境管理ツールを使用してアドバンスト・レプリケーションを構成する場合は、このコマンドをMDSサイトのマスター・ホスト(ニューヨークのOIDHOST1)でのみ実行します。レプリケーションは、1つのOracle Internet Directoryホストでのみ、起動する必要があります。

タスク4(オプション): ディレクトリへのデータのロード

bulkloadユーティリティの使用を選択する場合、すべてのOracle Internet Directoryホームで、すべてのOracle Internet Directoryインスタンスを停止し、Oracle Internet Directoryインスタンスのいずれか1つのみを使用して、bulkload操作を実行します。

タスク5: 全ノードでのOracle Directory Serverインスタンスの起動の確認

このタスクは、すべてのOracle Internet DirectoryのOracleホーム・ディレクトリで実行します。

タスク6: ディレクトリ・レプリケーション・グループ内の全ノードでのレプリケーション・サーバーの起動

ニューヨークのOIDHOST1とロサンゼルスのOIDHOST3でのみ、レプリケーション・サーバーを起動します。

10.3.2.1 Oracle Advanced Databaseマルチマスター・レプリケーションへのノードの追加

Oracle Advanced Databaseマルチマスター・レプリケーション・デプロイメントのノードの追加の詳細な手順は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのOracle Databaseアドバンスト・レプリケーションベース・マルチマスター・レプリケーション・グループのノードの追加に関する項に記載されています。

表10-2は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのOracle Databaseアドバンスト・レプリケーションベース・マルチマスター・レプリケーション・グループのノードの追加に関する項に含まれる各項を示しています。また、図10-1に示す最高の高可用性Oracle Internet Directoryデプロイメントにノードを追加するために各項で実行する手順も説明しています。

表10-2 Oracle Databaseアドバンスト・レプリケーションでのノードの追加手順

項

手順

Oracle Net Services環境の準備

マスター定義サイト(ニューヨーク・サイト)およびリモート・マスター定義サイト(ロサンゼルス・サイト)のすべてのデータベースのOracleホームとすべてのOracle Internet DirectoryのOracleホームで、この項の手順を実行します。

また、追加する新しいクラスタについても、データベースのOracleホームとすべてのOracle Internet DirectoryのOracleホームで、この手順を実行します。

タスク1: 全ノードでのディレクトリ・レプリケーション・サーバーの停止

ニューヨークのOIDHOST1、およびロサンゼルスのOIDHOST3上のレプリケーション・サーバーを停止します。

タスク2: スポンサ・ノードの特定とリモート・サイトでのOracle Internet Directoryのインストール

ニューヨーク・クラスタのOIDHOST1が、スポンサ・ノードおよびMDSになります。

タスク3: スポンサ・ノードの読取り専用モードへの切替え

このタスクは、OIDHOST1およびOIDHOST2上のOracle Internet DirectoryのOracleホームで実行します。

タスク4: ldifwriteを使用したスポンサ・ノードのバックアップ

このタスクは、OIDHOST1上のOracle Internet DirectoryのOracleホームで実行します。

タスク5: アドバンスト・レプリケーション追加ノードでの設定の実行

このタスクは、OIDHOST1上のOracle Internet DirectoryのOracleホームで実行します。

タスク6: スポンサ・ノードの更新可能モードへの切替え

このタスクは、OIDHOST1およびOIDHOST2上のOracle Internet DirectoryのOracleホームで実行します。

タスク7: 新しいノード以外の全ノードでのディレクトリ・レプリケーション・サーバーの起動

このタスクは、ニューヨーク・クラスタのOIDHOST1およびロサンゼルス・クラスタのOIDHOST3で実行します。

タスク8: bulkloadを使用した新しいノードへのデータのロード

このタスクは、追加する新しいクラスタのいずれかのOracle Internet DirectoryのOracleホームで実行します。

bulkloadを使用する前に、新しいノードのすべてのOracle Internet Directoryプロセスを停止します。

タスク9: 新しいノードでのディレクトリ・サーバーの起動

このタスクは、追加する新しいクラスタのすべてのOracle Internet Directoryノードで実行します。

タスク10: 新しいノードでのディレクトリ・レプリケーション・サーバーの起動

このタスクは、追加する新しいクラスタのいずれかのOracle Internet DirectoryのOracleホームで実行します。

10.3.2.2 Oracle Advanced Databaseマルチマスター・レプリケーションでのノードの削除

Oracle Advanced Databaseマルチマスター・レプリケーション・デプロイメントのノードの削除の詳細な手順は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのマルチマスター・レプリケーション・グループからのノードの削除に関する項に記載されています。

表10-3は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのマルチマスター・レプリケーション・グループからのノードの削除に関する項に含まれる各項を示しています。また、図10-1に示す最高の高可用性Oracle Internet Directoryデプロイメントのノードを削除するために各項で実行する手順も説明しています。この手順では、MDSをニューヨーク・サイトとしています。

表10-3 Oracle Advanced Databaseレプリケーションでのノードの削除手順

項

手順

タスク1: 全ノードでのディレクトリ・レプリケーション・サーバーの停止

このタスクは、ディレクトリ・レプリケーション・グループ(DRG)の各ノードで実行します。

タスク2: 削除対象ノードでの全Oracle Internet Directoryプロセスの停止

このタスクは、削除対象のノードで実行します。

タスク3: マスター定義サイトからのノードの削除

このタスクは、OIDHOST1上のOracle Internet DirectoryのOracleホームで実行します。

タスク4: 全ノードでのディレクトリ・レプリケーション・サーバーの起動

このタスクは、DRG内の残りのノードすべてで実行します。

11 WebCenter Contentの高可用性の構成

Oracle WebCenter Contentは、Oracle Fusion Middlewareコンポーネントの1つで、コンテンツを管理するために設計された統合的な製品スイートです。業界最先端のドキュメント管理、Webコンテンツ管理、デジタル資産管理およびレコード管理機能を利用して、ビジネス・アプリケーションを構築できます。コンテンツおよびアプリケーションの戦略的なエンタープライズ・コンテンツ管理インフラストラクチャを構築することで、コストの削減、エンタープライズを横断する容易なコンテンツの共有、リスクの最小化、時間を浪費する高価な手動プロセスの自動化、および複数のWebサイトの単一のプラットフォームへの統合化を支援します。

Oracle WebCenter Contentには次のような利点があります。

- 優れたユーザビリティ: エンド・ユーザー、ワークグループ、コンテンツ・エキスパート、プロセスの所有者、管理者、およびWebマスターに対する組込みのサポート

- 最適化された管理: ドキュメント、ファイル、Webコンテンツ、およびデジタル資産を安全に管理するための統合されたアーキテクチャ

- ホットプラガブル: Oracleおよびサード・パーティのリポジトリ、セキュリティ・システム、およびエンタープライズ・アプリケーションに対するインストール時からのサポート

この章では、Oracle WebCenter Contentコンポーネントについて、高可用性の観点から説明します。この章では、高可用性を備えたデプロイメントの設計に重要な単一インスタンスの概念について概要を説明します。

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

- 第11.1項「Oracle WebCenter Content: Imagingの高可用性」

- 第11.2項「Oracle WebCenter Contentの高可用性」

- 第11.3項「Oracle WebCenter Contentの高可用性の構成手順」

11.1 Oracle WebCenter Content: Imagingの高可用性

この項では、Oracle WebCenter Content: Imaging (Imaging)の概要、およびImagingの高可用性環境の設計とデプロイ方法について説明します。

11.1.1 Imagingコンポーネントのアーキテクチャ

Imagingでは、プロセス指向のイメージング・アプリケーション、およびOracle E-Business SuiteやPeopleSoft Enterpriseなどのイメージ対応のビジネス・アプリケーションに焦点を当てたスケーラブルなソリューションを組織に提供します。これにより、イメージの注釈およびマークアップの対応、ルーティングおよび承認の自動化、大量のアイテムに対応する高容量アプリケーションのサポートを実現します。

Imagingは、ビジネス・トランザクションまたはプロセスの一環としてそれぞれのドキュメントを管理する、トランザクション・コンテンツ管理ツールです。トランザクション・ドキュメントは、通常は比較的短期間のトランザクションの発生時に重要になります。

図11-1は、Imagingの内部コンポーネント(Imagingパッケージ内のコンポーネント)を示しています。

図11-1 単一インスタンスのImagingコンポーネント

「図11-1 単一インスタンスのImagingコンポーネント」の説明

Imagingの構成の設定を開始する前に、次の点に注意してください。

- Imagingは、Oracle Universal Content Manager(WebCenter Content)リポジトリの最上位にある比較的薄い機能層です。Imagingでは、WebCenter Contentでのイメージ・ファサードを提供します。リポジトリによって、リソース利用の大部分が実行されます。そのため、すべてのImagingインスタンスにWebCenter Contentインスタンスを配置することでWebCenter Contentを構成するようにお薦めします。この構成によって、ハードウェアを最適に利用できます。

- Imagingの最大のパフォーマンス要素は、ドキュメント・コンテンツの移動です。通常、Imagingは、毎日数十万ものドキュメントを収集するような大容量シナリオで使用されます。これらのドキュメントは、一日中、頻繁に検索、取得および表示されます。システム内外とのドキュメント・コンテンツのやりとりは、パフォーマンスに大きく影響します。Imagingでは、平均25KバイトのサイズのTIFドキュメントを保存します。ただし、TIFドキュメントには複数のページが含まれていることがあり、それによってドキュメントのサイズは増加します。さらに、Imagingでは、その他にも様々なサイズの400のファイル形式をサポートしています。これらのファイルには、より大きなサイズのものもあります。

11.1.1.1 Imagingコンポーネントの特性

Imagingは、WebLogic Server管理対象サーバー環境で稼働するJava EEアプリケーションです。これには、次のコンポーネントおよびサブコンポーネントが含まれます。

- サーブレット: Imagingには、REST APIおよびImagingアプレット・ビューアがシステムのパブリックAPI関数にアクセスするメカニズムを提供する、内部で使用するためのサーブレットがあります。

- EJB: Imagingでは、内部的にいくつかのEJBの概念を利用していますが、外向きのEJBはありません。

- Imagingでは、JMSを使用してその入力エージェントとそのBPELエージェント・メッセージ駆動Bean(MDB)の両方を駆動します。図11-1で、BPELエージェントはBPEL MDBの集合です。これらのキューは永続するため、配信は保証されます。これによりクラスタ間でも作業が配信されます。

- Imagingでは、JAX-WSおよびJAX-Bを使用して、そのWebサービスおよびシリアライズ・メカニズムを実装します。

- Imagingでは、定義の保存および構成にTopLinkを使用します。この目的は、一般的にはアプリケーションおよび検索を定義することです。また、TopLinkはユーザーおよびシステム・プリファレンスの取得にも使用されます。

- Imagingでは、リポジトリからのドキュメントの取得や表示するドキュメントの処理に内部キャッシュとしてJava Object Cache(JOC)を使用します。これらのキャッシュはローカルにのみ存在し、サーバー間で共有することはありません。

- AXFとBPEL間の相互作用は、EJBを介してRMIを使用するBPELリモートAPIによって実行されます。

注意:

Imagingでは、複数コンポーネントのトランザクションをサポートしないため、Java Transaction API(JTA)を使用しません。

11.1.1.1.1 Imagingの状態情報

ImagingにはステートフルなUIを備えていますが、セッション・レプリケーションをサポートしていないため、スティッキーなロード・バランシング・ルーターが必要になります。

Imaging APIを使用したImagingサービスの呼出しは、ステートレスです。

11.1.1.1.2 Imagingのランタイム・プロセス

Imagingのコアでは、中央API、UI、およびWebサービス・インタフェースを含むサービスベースのアーキテクチャを使用します。このADFベースのUIは、ImagingのパブリックAPIを使用して、コア・サービスにアクセスします。エンド・ユーザーは、Webサービスを開始してこのAPIにアクセスします。Java開発者には、より便利なパッケージでこれらのWebサービスを公開するシンJavaクライアント・ライブラリも提供します。

Imagingには、バックグラウンド処理を実行するための次のエージェントがあります。

- 入力エージェントは、インジェストするドキュメントの受信リストの入力ディレクトリを監視します。

- BPELエージェントは、ドキュメント作成イベントに応答して、そのドキュメントおよびURLからメタデータを含む新しいBPELプロセス・インスタンスをアタッチするドキュメントに作成します。図11-1で、BPELエージェントはBPEL MDBの集合です。

- チケット・エージェントは、タイマーなしで呼び出されるステートレスのEJBです。これは、図11-1には示されていません。チケット・エージェントは、有効期限が切れたURLチケットの特定および削除を行います。これらのチケットは、パラメータを使用しないクリーンなURLを作成するために使用されます。

Imagingサービスでは、スキャン・ドキュメントの保存にWebCenter Contentドキュメント・リポジトリを使用します。WebCenter Contentリポジトリは、RIDCと呼ばれるWebCenter Contentで提供されるTCP/IPストックベースの接続メカニズムを介してImagingと通信するスタンドアロン製品です。

11.1.1.1.3 Imagingプロセスのライフサイクル

これは特定の障害検出を提供するものではありませんが、WebLogic Serverノード・マネージャを使用して継続的にサーバーを稼働することができます。

Imagingプロセス・ライフサイクルのステップは次のとおりです。

1. Imagingは、ほとんどの場合、ドメイン構成が行われた後、初期化されます。Imagingが起動して最初のユーザーがログオンすると、残りの初期化が実行されます。

2. 最初のユーザーがログオンしたときに、そのユーザーはそれ以降の他のユーザーに権限を付与できるという前提の下で、完全なセキュリティ権限が付与されます。Imagingは、セルフ・シード・データベース・セキュリティ・メカニズムを提供します。Imagingが起動したときにセキュリティが定義されていない場合、システムに最初にログインしたユーザーはすべてのものにアクセスする権限が付与されます。

3. Imagingが初めて起動した直後は、Imagingは「空」です。WebCenter Contentドキュメント・リポジトリおよびBPELサーバーへの接続は、管理ユーザーの責任で作成します。

4. 最初のUCM接続が作成されると、Imagingで使用するWebCenter Contentリポジトリは初期化されます。

5. ここで、アプリケーション、検索、入力などを含む適切なビジネス・オブジェクトを作成する必要があります。管理ユーザーは、これらをゼロから作成するかわりに、そのビジネス・オブジェクトをインポートすることもできます。

6. ステップ1でエージェント・ユーザーが指定された場合、エージェントはサーバーが再起動した後JMSキュー・イベントがその処理を開始するのを待ちます。

7. サーバーが稼働してJAX-WSメカニズムの準備ができたら、Imagingはクライアント・リクエストを受信できます。

11.1.1.1.4 Imagingの構成アーティファクト

Imagingには、次のような構成アーティファクトがあります。

- すべてのImaging構成データは、Imagingデータベースの中に保存されます。構成は、ローカル・ファイルには保存されません。構成パラメータは、(Enterprise ManagerまたはWLSTから使用できる)適切なMBeanまたはImagingのUIを介して公開されます。

- その他のImaging構成アーティファクトは、第11.1.1.1.5項「Imagingの外部依存性」で説明されている定義オブジェクトです。

- Imagingでは、WebCenter Contentメカニズムを使用して、UCMプロファイルおよび情報フィールドの管理を含め、Imagingで使用するためにWebCenter Contentをカスタマイズします。

11.1.1.1.5 Imagingの外部依存性

Imagingには、次の外部依存性があります。

- Imagingには、構成を格納するためのデータベースが必要です。データベースは最初にRCUを介して作成され、WebLogic Server JDBCデータ・ソースを介して管理されます。データベースには、TopLinkを介してアクセスします。

- Imagingでは、JAX-WS、JAX-B、ADF、TopLink、JMSなどの様々なOracleおよびJavaテクノロジを活用します。これらはインストールに含まれ、外部構成は不要です。

- Imagingには、構成用のMbeanが用意されています。これらは、WLSTおよびEM Mbeanブラウザを介して使用できます。Imagingには、いくつかのカスタムWLSTコマンドが用意されています。

- Imagingは、WebCenter Contentリポジトリが存在するかどうかに依存しています。

次のクライアントはImagingに依存します。

- Imaging UIは、パブリック・ツールキット(Imaging API)で構築されます。UIおよびコアAPIは、同じEARファイルで配信されます。

- Imagingには他の製品と統合するためのWebサービスが用意されており、他の製品と統合するためのJavaの便利な機能としてこれらのWebサービスをラップするJavaクラスのセットも用意されています。

- Imagingには、他のアプリケーションとImagingの検索およびコンテンツとの相互作用を円滑にするURLツールキットが用意されています。

- Imagingには、Webプレゼンテーションのドキュメントの個々のページを参照するためのRESTツールキットが用意されています。

クライアントは、次のいずれかを介してImagingに接続します。

- WebサービスまたはJavaクライアント用のJAX-WSを介した接続。これらの接続はステートレスで、単一の機能を実行します。

- 次のような、URLにアクセスするためのHTTPおよびRESTツール。

- RESTリクエストはステートレスで、単一の機能を実行します。

- URLツールはImaging UIにログインして、関連するUIコンポーネントを含むよりステートフルな体験を提供します。

11.1.1.1.6 Imagingのログ・ファイルの場所

ログ・メッセージはすべて、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。

診断ログ・ファイルのデフォルトの場所は次のとおりです。

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

Oracle Enterprise Managerを使用して、これらのログ・ファイルの検索および解析を簡単に行えます。

11.1.2 Imagingの高可用性の概要

この項では、Imagingを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。

11.1.2.1 Imagingの高可用性アーキテクチャ

図11-2は、Imagingの高可用性アーキテクチャを示しています。

図11-2 Imagingの高可用性アーキテクチャの図

「図11-2 Imagingの高可用性アーキテクチャの図」の説明

Imagingは、標準的な2ノードのアクティブ/アクティブの高可用性構成で構成できます。ImagingのUI層はアクティブ・サーバー間でフェイルオーバーされませんが、その他のバックグラウンド・プロセスはフェイルオーバーされます。

図11-2は、Imagingの高可用性構成を示しています。

- Imagingノードは、お互いに同一なレプリカです。高可用性構成のすべてのノードは、同一のサービスを実行し、中央の構成データベースで構成されます。すべてのサーバーはこのデータベースからその構成を取得します。

- Imagingノードのフロントエンドには、スティッキーなセッション・ルーティングを持つロード・バランシング・ルーターを使用する必要があります。この目的のためにOracle HTTP Serverを使用できます。

- Imagingは、WebLogic Serverクラスタ内でもクラスタなしでも実行できます。

- すべてのImagingインスタンスは、同じデータベース接続を共有する必要があります。そうすることで、Oracle RACの高可用性の潜在機能が高まります。Imagingは、データベース処理にTopLinkを使用します。

- Imagingには共通の共有ディレクトリが必要で、入力エージェントはインジェスト用にステージングされたインバウンド・データファイルをここから取得します。入力エージェントが入力定義ファイルを取得したら、関連する入力ファイルおよびイメージの処理は、そのWebLogic Serverインスタンスから分離されます。

11.1.2.1.1 クラスタの起動と停止

Imagingのエージェント(入力エージェント、BPELエージェント)は、クラスタ内のWebLogic Serverに存在するImagingアプリケーションの不可欠な機能として起動します。JMSキューの未処理の作業(これらは障害を越えて永続的に保存されます)に基づいて、即座に処理が開始されます。入力エージェントは、インバウンド・ファイル・ディレクトリでも作業を検索します。処理対象のファイルがある場合、それらは対応するJMSキューにプッシュされ、クラスタ内のサーバーはそれを使用して関連するイメージを処理します。WebLogic Serverワークロード・マネージャは、BPELエージェントおよび入力エージェント専用のスレッドの数を制御します。

クラスタ内のサーバーが停止すると、エージェントはそのアクティビティを終了します。BPELエージェントの実行サイクルは短く、すべての処理はシャットダウン前に完了することが見込まれます。進行中のBPEL呼出しは3回再試行され、JMSログは保留中の操作を保存します。入力エージェントは大規模なサイズのファイルを処理できます(大きな入力ファイルの場合、処理に数時間かかる場合があります)。停止後に保留された作業の量は、関連するJMS永続ストアに保存されます。入力エージェントをホストするサーバーを再起動すると、エージェントは残されていた処理を開始します。イメージ・ファイルの処理は、再起動またはサーバーの移行後に、対応する入力ファイルを最初に使用するサーバーで継続されます。

11.1.2.1.2 クラスタワイドの構成変更

Imaging構成は、Imagingデータベースに格納され、クラスタ内のすべてのImagingインスタンスによって共有されます。

特定のImagingインスタンスのBPELエージェントおよび入力エージェントのスレッド数はWebLogic Serverプロパティで指定し(Imagingアプリケーションの構成として保存されます)、管理コンソールまたはWLSTコマンドで制御します。

11.1.2.2 障害からの保護および予想される動作

Imagingの高可用性構成を障害から保護するには、次の手順を実行します。

- Imagingノードのフロントエンドには、スティッキーなセッション・ルーティングを持つロード・バランシング・ルーターを使用します。この目的のためにOracle HTTP Serverを使用できます。

- Imagingでアップロードまたは取得される表示用のドキュメントのサイズに基づいて、ロード・バランシング・ルーターのタイムアウトを構成します。

また、次の機能もImagingの高可用性構成での障害からの保護に役立ちます。

- JMSフェイルオーバーは、WebLogic ServersのJMS実装で提供されます。

- TopLinkには、データベースの再試行ロジックが用意されています。

- WebCenter Contentに接続する際に、ネットワーク障害の解決を即座に再試行するために、再試行ロジックが存在します。Imagingには、クラスタ内の他のWebCenter Contentサーバーを検索するフェイルオーバー・メカニズムが用意されています。ImagingとWebCenter Contentの間にロード・バランサを使用して、ロード・バランシング/フェイルオーバーの目的を実現できます。

- BPELに接続する際に、Imagingは即座に再試行を実行し、タイムアウト時間(5分間)を超えたら失敗したアイテムを関連する再試行用のJMSキューに押し戻します。このJMS再試行メカニズムは、3回実行されます。失敗し続けるオブジェクトは、ユーザー操作用の保存キューに格納されます。

- APIレベル統合(JPSなど)は再試行されず、内部的な再試行ロジックで処理されます。

ノード障害

Oracle/IPMノードで障害が発生すると、そのノードのエージェント・プロセスに影響します。未完了のトランザクションは、廃棄されて失われます。フェイルオーバー時に、そのノードのImaging UIのユーザー・セッションは失われます。ユーザーは、再度ログインして再起動する必要があります。それぞれのImagingクラスタ・ノードは独立しているので、フェイルオーバーはロード・バランシング・ルーターで管理され、Imagingで直接管理されることはありません。

すべてのImaging構成情報はデータベースに保存され、すべてのノードはお互いにレプリカになるため、構成情報はフェイルオーバー後に新しいノードで即座に使用できます。

外部リソースでのImagingノード障害の影響は次のとおりです。

- JMSトランザクションでは、JMSに対して実行されたアトミック・アクションは内部的にトランザクション処理され、未完了のキューから受信したすべてのメッセージは再送信されることが想定されています。BPELエージェントおよび入力エージェントの障害回復は、ローカル・メッセージのファイル・システムへの永続性に依存します。メッセージがローカル・ノードに存在するイベントは、そのノードの起動時に続行されます。その他のメッセージは、稼働しているノードで取得されます。

- データベース・トランザクションでは、接続が切断されたときに暗黙的なロールバック処理を強制する場合を除いて、データベースがクライアントの障害に対処することはありません。データベース障害時のデータベース・トランザクションは、必要なデータベース機能により管理されます(たとえば、Oracle RACデータベースが使用されていればフェイルオーバーが行われ、単一ノードのデータベースが使用されていればフェイルオーバーは行われません)。データベースへのアクセス中にノード障害が発生すると、多くの場合、ユーザーは再度ログインして、UI操作を再試行することになります。

- Imagingサーバーの障害発生時は、Imaging内のユーザー・セッションは失われます。Imaging UIを介してドキュメントをアップロードしているときにImagingサーバーの障害が発生すると、手動のドキュメントのアップロードが成功したという確認通知が受信されない場合があります。その場合、それを再度アップロードする前に、サーバー障害発生時にアップロードしていたドキュメントがあるかどうか探してみることをお薦めします。そうすることで、ドキュメントの重複作成が回避されます。

外部アプリケーションがWebService呼出しを使用してImagingクラスタにアクセスする場合、Imagingサーバーに障害が発生すると、フロントエンド・ロード・バランサで適切なフェイルオーバー・ロジックが提供されることが想定されます。入力ディレクトリにファイルを直接プッシュすることでアプリケーションがImagingシステムと相互作用する場合、ファイル・システムで障害が発生したときの再試行は、アプリケーションで処理します。

障害発生時に入力定義ファイルが処理中の場合、Imagingはファイルの詳細を保持し、その特定のノードの再起動時に、ローカルJMSキューでその再試行するJMSメッセージを再作成します。再試行時に、入力インジェスタはシャットダウンが発生したときのファイル内の場所の特定を試みて、バッチのドキュメントが失われないように未処理の場所を取得します。定義ファイルを処理していたノードが完全に再起動してファイルの処理が終了するまで、定義ファイルはStageディレクトリに保持されます。

入力ファイルは、入力エージェントがスケジュール設定および処理できる作業の最小単位です。最高のパフォーマンス、スケーラビリティ、および可用性を実現するために、いくつかの考慮事項があります。

- Imagingクラスタ内のすべてのマシンは、共通の入力ディレクトリを共有します。

- このディレクトリからの入力ファイルは、JMSキューを介してそれぞれのマシンに配信されます。

- このディレクトリで新しいファイルをポーリングする頻度は、CheckInterval MBean構成設定を使用して構成できます。

- それぞれのマシンには、指定された数の入力インジェスタが配置されます。入力インジェクタは、入力定義ファイルの解析を行います。インジェスタの数は、InputAgentのワークロード・マネージャを介して制御し、WebLogic Serverで管理します。

次のような場合に最適なパフォーマンスを実現できます。

- それぞれのImagingクラスタ・ノードに、ユーザー・インタフェースやWebサービスなどの他のImagingアクティビティのパフォーマンスを損ねることなく、ワーク・マネージャを介して構成された最適な最大数の解析エージェントがある場合。

- ドキュメントのインバウンド・フローは、最適な数のドキュメントを含む入力ファイルに分割されます。平均では、クラスタ内の解析エージェントごとに2つの入力ファイルをキューに格納する必要があります。

- クラスタ内で1台以上のマシンに障害が発生した場合、アクティブなマシンが入力ファイルの処理を続行します。障害が発生したマシンの入力ファイルは、サーバーが再起動するまで処理されません。入力ファイルを小さくすることで、マシンの障害によって大量のドキュメントが未処理の状態にならないようにします。

例: 2台のサーバーが1時間当たり10,000のインバウンド・ドキュメントを処理します。サーバーごとに2つの解析エージェントを構成すると、全体的に適度なパフォーマンスが実現され、エージェントごとに2ドキュメント/秒でインジェストされます。2ドキュメント/秒の解析エージェントが4つある場合、8ドキュメント/秒(28,800ドキュメント/時)で処理されます。10,000ドキュメントの単一の入力ファイルは、1時間では処理できません(これは、7,200ドキュメント/時で処理する単一の解析エージェントは処理を完了できないためです)。ただし、その入力ファイルを8つに分割して1,250ドキュメントずつにすると、4つのすべての解析エージェントはフルに活用され、1時間の期間内に10,000ドキュメントの処理が完了するようになります。また、1つのサーバーで障害が発生した場合、処理が正常に終了するまでもう一方のサーバーで解析エージェントに残っている処理を続行できます。

Imagingが依存するコンポーネントの障害

ImagingはOracle SOA Suiteと統合します。SOAサーバーが停止すると、Imagingでは障害が発生します。Imagingでは、再試行が3回行われます。それぞれの試行を繰り返す前に、構成可能な遅延時間が後に続きます。3回の試行の後もアクションが完了できない場合、これらのリクエストはデータベース・テーブルのキューに格納され、後で再送信されます。再送信は、WLSTコマンドを使用して実行します。

ImagingはOracle WebCenterポータルに依存していません。

その他のOracle ADFアプリケーションは、Imagingの操作には影響しません。

Imaging UIでは、接続先となるWebCenter Contentサーバーのリストを指定できます。これは、プライマリ・サーバーを使用して、複数のセカンダリ・サーバーに接続して指定できます。プライマリUCMサーバーで障害が発生すると、Imagingはリストの次のUCMサーバーを再試行します。すべてのUCMサーバーが停止した場合、例外が返され、Imagingサーバーのログにトレースされます。

11.1.2.3 クラスタでのImagingアーティファクトの作成

検索、入力、アプリケーション(すべてImaging構造構成)は、Imagingデータベースの中に保存されます。これらは、Web UI層を含め、クラスタ内のすべてのマシンで即座に使用可能になります。新しいエントリがクラスタ内の別のImagingサーバーまたは別のユーザー・セッションの同じサーバーで作成された場合、Web UIは自動的にはリフレッシュしませんが、Webブラウザをリフレッシュしてイメージ・アプリケーションのナビゲーション・バーをリフレッシュすることはできます。

11.1.2.4 Imagingのトラブルシューティング

この項では、高可用性環境でImagingサーバー、アドバンスト・ビューア、入力エージェントをトラブルシューティングする方法について説明します。

追加のImagingトラブルシューティング情報は、Oracle WebCenter Content for Imaging管理者ガイドに記載されています。

Imagingサーバーのトラブルシューティング

Oracle/IPMは、WebLogic ServerにデプロイされたJava EEアプリケーションです。ログ・メッセージはすべて、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。

診断ログ・ファイルのデフォルトの場所は次のとおりです。

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

Oracle Enterprise Managerを使用して、これらのログ・ファイルの検索および解析を簡単に行えます。

アドバンスト・ビューアのトラブルシューティング

Imagingでは、主にサーバー側でロギング機能を提供しますが、クライアント側にアドバンスト・ビューアというコンポーネントもあります。このJavaアプレットでは、標準的なロギング・ユーティリティを使用します。ただし、これらのユーティリティは、クライアントでは無効です。Javaプラグインのlogging.propertiesファイルを適切に変更して、ログの出力をファイルまたはJavaコンソールのいずれかに送信するようにこれらのユーティリティを構成できます。

入力エージェントのトラブルシューティング

Imagingの入力エージェントでドキュメントをアップロードするときに、Oracle WebCenter Contentで障害が発生すると、次のようなメッセージが生成されます。

Filing Invoices Input completed successfully with 48 documents processed
successfully out of 50 documents.

また、次のような例外も生成されます。

[2009-07-01T16:43:01.549-07:00] [IPM_server2] [ERROR] [TCM-00787]
[oracle.imaging.repository.ucm] [tid: [ACTIVE] .ExecuteThread: '10' for queue:
'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid:
0000I8sgmWtCgon54nM6Ui1AIvEo00005N,0] [APP: imaging#11.1.1.1.0]
A repository error has occurred.
Contact your system administrator for assistance.
[[oracle.imaging.ImagingException: TCM-00787: A repository error has occurred.

Contact your system administrator for assistance.
stackTraceId: 5482-1246491781549
faultType: SYSTEM
faultDetails:
ErrorCode = oracle.stellent.ridc.protocol.ServiceException,
ErrorMessage = Network message format error.
at
oracle.imaging.repository.ucm.UcmErrors.convertRepositoryError(UcmErrors.
java:109
.
.
.

入力エージェントは、失敗したドキュメントをエラー・ファイルに配置することでエラーを処理します。そのような状況下で、このような動作およびエラー・メッセージが生成されることが想定されます。

11.2 Oracle WebCenter Contentの高可用性

この項では、Oracle WebCenter Content(WebCenter Content)の概要、およびWebCenter Contentの高可用性環境の設計とデプロイ方法について説明します。

11.2.1 Oracle WebCenter Contentコンポーネント・アーキテクチャ

図11-3は、WebCenter Contentの単一インスタンスのアーキテクチャを示しています。

図11-3 Oracle WebCenter Contentの単一インスタンス・アーキテクチャ

「図11-3 Oracle WebCenter Contentの単一インスタンス・アーキテクチャ」の説明

WebCenter Contentのインスタンスは、Oracle WebLogic管理対象サーバー環境内で稼働します。WebLogic Serverは、アプリケーションの起動と停止など、WebCenter Contentアプリケーションのライフサイクルを管理します。

WebCenter Contentアプリケーションへのエントリ・ポイントは2つあります。1つはリスニングTCPソケットであり、このソケットは、ImagingやOracle WebCenterポータルなどのクライアントからの接続を受理できます。もう1つはHTTPリスニング・ポートです。これは、Webサービス呼出しを受理できます。HTTPポートは、管理対象サーバーのリスニング・ポートと同じポートです。

UCMサーバーには、いくつかの埋込みアプリケーションも含まれています。これらは、クライアント・ブラウザ内でアプレットとして実行できます。これらには、ファイル管理および索引機能のリポジトリ・マネージャ(RM)およびユーザー・ワークフローを設定するためのワークフロー管理などがあります。これらのアプリケーションの詳細は、Oracle Fusion Middleware Content Serverアプリケーション管理者ガイドを参照してください。

UCM Serverには、3タイプの永続ストアがあります。それらのタイプは、リポジトリ(Oracle Databaseに格納可能)、検索索引(Oracle Databaseに格納可能)、メタデータおよびWebレイアウト情報(ファイル・システムに格納可能)です。

11.2.1.1 WebCenter Contentコンポーネントの特性

WebCenter Contentは、WebLogic Serverに存在するサーブレットです。サーブレット・リクエストは、UCMリクエストのラッパーです。

WebCenter Contentには、BatchLoaderやIdcAnalyzerなどの様々なスタンドアロンの管理ユーティリティが含まれます。

JMSおよびJTAは、WebCenter Contentでは使用されません。

11.2.1.1.1 WebCenter Contentの状態情報

WebCenter Contentのリクエストはステートレスです。認証情報を保持するために、セッションをデータベースに保存できます。

11.2.1.1.2 WebCenter Contentのラインタイム・プロセス

WebCenter Contentは、サービス指向アーキテクチャを採用しています。それぞれのリクエストは、サービスとしてシステムに受け入れられます。共有サービス層では、リクエストを解析し、そのリクエストを正しいハンドラに渡します。通常、ハンドラは基になるリポジトリにアクセスして、リクエストを処理します。3種類のリポジトリとそれぞれで保存するデータを図11-3に示します。

11.2.1.1.3 WebCenter Contentプロセスのライフサイクル

WebCenter Contentは、WebLogic Server管理対象サーバーとして起動および停止できます。UCM管理サーバーも、UCMインスタンスの起動、停止、および構成に使用できます。UCM管理サーバーは、WebLogic管理コンソールが採用されているため非推奨ですが、従来どおりWebLogic Server環境で機能します。ロード・バランサは、PING_SERVERサービスを使用して、UCMインスタンスのステータスを監視できます。

起動時に、WebCenter Contentは初期化ファイルおよびデータ定義をロードして、データベース接続を初期化し、ローカライゼーション文字列をロードします。WebCenter Content内部コンポーネント・アーキテクチャを介して、起動シーケンスでシステムにインストールおよび有効化されている内部コンポーネントを検出し、それらのコンポーネントを初期化します。検索/索引エンジンおよびファイル・ストレージ・インフラストラクチャも初期化されます。

通常、クライアント・リクエストは1つのWebCenter Contentインスタンスですべて処理されます。クラスタ内に他のインスタンスが存在しても、クライアント・リクエストには影響しません。

11.2.1.1.4 WebCenter Contentの構成アーティファクト

初期化ファイルは、ファイル・システムで保存され、WebCenter Contentシステム・ディレクトリに格納されます。

11.2.1.1.5 WebCenter Contentのデプロイメント・アーティファクト

WebCenter Contentでは、nostageデプロイメントを使用します。つまり、すべてのデプロイメント・ファイルはローカルです。

11.2.1.1.6 WebCenter Contentの外部依存性

WebCenter Contentには、WebLogic Serverおよび外部Oracle Databaseが必要です。

次のクライアントはWebCenter Contentに依存します。

- Oracle WebCenter Content: Records(Records)

- Oracle WebCenter Content: Imaging(Imaging)

- Oracle WebCenterポータル

クライアントからの接続は短時間で、セッションレス・サービスの期間にのみ必要です。

クライアントは、HTTP、SOAP/Web Services、JCR、およびVCRプロトコルを使用して、WebCenter Contentに接続できます。

11.2.1.1.7 WebCenter Contentのログ・ファイルの場所

WebCenter Contentは、WebLogic ServerにデプロイされたJ2EEアプリケーションです。ログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

WebCenter Contentは、次の場所にもログを記録します。

WebLayoutDir/groups/secure/logs

WebCenter Contentトレース・ファイルは、次の場所に記録および格納するように構成できます。

IntraDocDir/data/trace

WebCenter ContentのGUIを使用してログ・ファイルを表示するには、「UCM」メニュー→「管理」→「ログ」を選択します。

WebCenter ContentのGUIを使用してトレース・ファイルを表示するには、「UCM」メニュー→「システム監査情報」を選択します。「サーバー出力の表示」および「捕捉された出力の表示」リンクをクリックすると、現在のトレースおよび記録されたトレースが表示されます。

11.2.2 WebCenter Contentの高可用性の概要

この項では、WebCenter Contentを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。

11.2.2.1 WebCenter Contentの高可用性アーキテクチャ

図11-4は、2ノードのアクティブ/アクティブOracle WebCenter Contentクラスタを示しています。

図11-4 Oracle WebCenter Contentの2ノード・クラスタ

「図11-4 Oracle WebCenter Contentの2ノード・クラスタ」の説明

図11-4は、WebCenter Contentの高可用性構成を示しています。

- それぞれのノードは、共有ファイル・システム、同じデータベース・スキーマ、同じ検索索引に対して独立に稼働します。クライアント・リクエストは、すべて単一ノードで処理されます。

- WebCenter Contentは、WebLogic Serverクラスタまたは外部ロード・バランサで稼働できます。WebCenter Contentは、Oracle RACおよび複数のデータ・ソース構成に対しても透過的です。

- WebCenter Contentは、独立にスケーラビリティを持つことができ、ノード間の通信は限定的です。ノードどうしは、共有ファイル・システムへの読書きを介して通信します。この共有ファイル・システムは、書込み操作の同期化をサポートする必要があります。

11.2.2.1.1 クラスタの起動と停止

クラスタが起動すると、それぞれのWebCenter Contentノードは通常の初期化シーケンスが実行され、初期化シーケンスでは、リソースの解析、準備、およびキャッシュ処理、および接続の準備などが行われます。ノードがクラスタの一部である場合、他のクラスタ・メンバーが使用可能であれば、メモリー内のレプリケーションが開始されます。1つまたすべてのクラスタ・メンバーを同時に起動することができます。

クラスタ・メンバーをシャットダウンすると、そのクラスタ・メンバーはリクエストに対応できなくなります。サーバーを正常にシャットダウンすると、現在のリクエストの処理を終了して、使用不可になることを通知し、すべての共有リソースを開放して、そのファイルおよびデータベース接続を閉じます。すべてのセッション状態はレプリケートされ、このクラスタ・メンバーに接続されていたユーザーは、他のクラスタ・メンバーにフェイルオーバーされます。

11.2.2.1.2 クラスタワイドの構成変更

クラスタ・レベルでは、WebCenter Contentの内部コンポーネントを使用した新しいWebCenter Contentの機能や動作のカスタマイズ機能が導入されました。新しい変更を取得するには、ノードを再起動する必要があります。

たとえば、メタデータ・モデルでシステム全体を変更できます(メタデータ・フィールドの追加、変更、削除など)。これらのメタデータ・フィールドで駆動されたシステムの動作は変更できます。この変更は、ノード間の通知を介して、クラスタ・ノートで自動的に取得されます。

各クラスタ・メンバーで変更を適用するには、最初のノードで共有フォルダを構成する必要があります。それぞれのクラスタ・ノードのすべての共有フォルダが同じマウント・ポイントを持っていれば、他のノードでWebLogic Serverのpack/unpackを使用して手動で変更を行う必要はありません。

11.2.2.2 WebCenter ContentおよびInbound Refineryの高可用性アーキテクチャ

WebCenter Contentを1つ以上のInbound Refineryインスタンスで構成して、ドキュメントの変換を行うことができます。

Inbound Refineryは、ドキュメント、デジタル・イメージ、動画ビデオなどの電子ドキュメントのファイルの変換を管理する変換サーバーです。また、ドキュメントおよびイメージのサムネイル機能、デジタル・イメージからEXIFを抽出および使用する機能、Adobe PhotoshopおよびAdobe Illustratorなどのプログラムから生成された電子ファイルからXMPデータを抽出および使用する機能、およびビデオのストーリーボード作成機能も用意されています。Inbound Refineryの詳細は、Oracle Fusion Middleware変換についての管理者ガイドを参照してください。

インストールが必要なInbound Refineryインスタンス数は、サポートが必要な変換の量によって異なります。可用性を高めるために、少なくとも2つのInbound Refineryインスタンスをインストールすることをお薦めします。すべてのInbound Refineryインスタンスは、プロバイダとしてContent Serverクラスタのすべてのメンバーから使用できる必要があります。

11.2.2.2.1 Content ServerとInbound Refineryの通信

Content ServerとInbound Refinery間の通信は、Content Serverで開始されます。開始処理には次のような処理が含まれます。

- ステータスを決定するための、使用可能なすべてのInbound Refineryインスタンスの定期的なチェック

- ジョブ・リクエストの開始

- 完了したジョブの取得

ステータスには、Inbound Refineryがリクエストを受理できるかどうかを示す情報が含まれます。これは、Inbound Refineryの稼働量に依存します。使用できるInbound Refineryインスタンスがない場合、リクエストは再試行されます。

ジョブが完了すると、Content Serverのステータス・リクエストの一部としてこの情報が表示されます。そのような場合、Content Serverは完了したジョブのダウンロードを開始します。

11.2.2.2.2 Content ServerクラスタおよびInbound Refineryインスタンス

Content Serverクラスタでは、クラスタ・メンバーが使用可能なInbound Refineryインスタンスのリストを共有します。つまり、新しいInbound Refineryインスタンスが追加されると、それは任意のContent Serverクラスタ・メンバーで使用できるようになります。

ただし、各Content Serverは使用可能なすべてのInbound Refineryインスタンスと独立的に通信します。Content Serverクラスタには、共有ステータスはありません。

同様に、すべてのInbound Refineryインスタンスでは、Content Serverからのリクエストに対応して、完全に独立して操作を行います。Inbound Refineryインスタンスでは、一切の情報を共有しません。

11.2.2.2.3 Inbound Refineryインスタンスとロード・バランサ

次の理由のため、一連のInbound Refineryインスタンスの前面でロード・バランサを使用することはできません。

- Content Serverは、Inbound Refineryと直接接続して、ステータスおよび可用性の情報を取得できる必要があります。

- ジョブが終了したら、Content Serverは特定のジョブを持つ1つのInbound Refineryにアクセスしてダウンロード開始できるようになる必要があります。

11.2.2.2.4 Inbound Refineryの可用性

すべてのリクエストはContent Serverを介した非同期リクエストになるので、Inbound Refineryへのリクエストはリアルタイムには発生しません。ユーザーがContent Serverにアクセスすると、Content Serverは使用可能なInbound Refineryインスタンスにリクエストを委任します。1つまたは複数のインスタンスで障害が発生しても、サービス・リクエストに対応できるInbound Refineryインスタンスがその他にも常に存在するように、十分なInbound Refineryインスタンスを構成する必要があります。

Content Serverでは、Inbound Refineryを「失敗」とマークすることはありません。あるInbound Refineryに接続できない場合、Content Serverは別の使用可能なInbound Refineryを選び、引き続きすべてのInbound Refineryインスタンスの可用性をチェックします。失敗したInbound Refineryインスタンスは、システム管理者の責任でContent Serverリストから手動で削除します。

11.2.2.3 Recordsの高可用性

RecordsとWebCenter Contentは、同じアーキテクチャを共有します。そのため、WebCenter Contentに適用されるすべての高可用性に関する考慮事項は、WebCenter Contentにも適用されます。

高可用性を構成する場合、WebCenter ContentとRecordsでは注意する相違点が2つあります。

1. Recordsは、WebCenter Contentと異なるディレクトリに、ファイル・システム・メタデータを保存します。

2. Recordsクラスタの前面のHTTPサーバーを構成する場合、WebCenter Contentと異なるセッションCookie名を使用する必要があります。

これら2つの構成の違いの詳細は、後述する「Oracle WebCenter Contentの高可用性の構成手順」を参照してください。

11.2.2.4 障害からの保護および必要な対応

次の機能は、WebCenter Contentノードの障害からの保護に役立ちます。

- 外部ロード・バランサを使用することで、ロード・バランシングを実現できます。セッションには、認証情報よりさらにスティッキーな状態データは不要です。

- ロード・バランサは、WebCenter Contentの前面に構成できます。Oracle RACをサポートするWebCenter Contentで、複数のデータ・ソースを構成できます。タイムアウトおよび再試行もサポートされます。

- WebCenter Contentでは、標準のWebLogic Server永続セッションを使用します。

- WebCenter ContentではEJBを使用しません。

- WebCenter Content PING_SERVERサービスを使用して、障害を検出します。ノードを再起動するときに、クラスタ内の他のノードに影響することはありません。

- フェイルオーバーは、WebCenter Contentノードの前面のロード・バランサまたはApacheのWLSモジュールによって処理されます。クライアントからの処理中のリクエストは失敗しますが、後続のリクエストはアクティブ・ノードにルーティングされます。終了していないトランザクションは完了しません。

- ノードからの構成情報は、共有ファイル・システムおよびデータベースに保存されているので、失われます。

- ノードに障害が発生すると、データベースはノードとデータベース間の接続を再要求します。

- 通常、インスタンスはハングしませんが、WebCenter Content製品またはWebCenter Contentのカスタマイズされたバージョンでの不明のデッドロック状態が原因でハングすることがあります。

- アクティブ・セッションがあるユーザーは、セッションがアクティブ・サーバーにフェイルオーバーされるため、ダウンタイムが発生することはありません。これは、UCM管理アプレットを開いているユーザーも含まれます。

- WebCenter Contentのインストールが完了したら、config.cfgファイルに次の値を設定する必要があります。これによって、Oracle RACフェイルオーバー中の再試行ロジックが有効になります。

ServiceAllowRetry=true

この値が設定されていない場合、フェイルオーバーが開始されたときに、ユーザーは処理中の任意の操作を手動で再試行する必要があります。

値は、次のURLにあるWebCenter Content用の管理コンソールを使用して設定できます。

http://<hostname>:<port>/cs

「管理」→「管理サーバー」→「一般構成」を選択し、ServiceAllowRetry=trueを「追加の構成変数」に追加します。保存して、すべてのUCM管理対象サーバーを再起動します。新しい値がconfig.cfg内の次の位置に表示されます。

SHARED_DISK_LOCATION_FOR_UCM/ucm/cs/config/config.cfg

11.2.2.5 WebCenter Contentの高可能性のトラブルシューティング

WebCenter Contentをトラブルシューティングするには、ログ・ファイルを調べてからトレース・ファイルを調べます。

WebCenter Contentのログ・ファイルおよびトレース・ファイルの場所、およびWebCenter ContentのGUIを使用してログ・ファイルおよびトレース・ファイルを表示する方法の詳細は、第11.2.1.1.7項「WebCenter Contentのログ・ファイルの場所」を参照してください。

11.3 Oracle WebCenter Contentの高可用性の構成手順

図11-5のような高可用性環境の場合、Oracle WebCenter Content製品は、クラスタ・デプロイメントで設定することをお薦めします(そうすることで、クラスタ化されたインスタンスはOracle Real Applications Cluster(Oracle RAC)データベースのコンテンツ・リポジトリにアクセスし、共通の構成を保存するために共有ディスクが使用されます)。

ハードウェア・ロード・バランサは、リクエストを複数のOracle HTTP Serverインスタンスにルーティングしてから、クラスタ化されたOracle WebCenter Contentサーバーにルーティングします。

この項では、図11-5で示されるOracle WebCenter Contentの高可用性構成のインストールおよび構成手順について説明します。

次の項目が含まれます。

- 第11.3.1項「共有記憶域」

- 第11.3.2項「Oracle Databaseの構成」

- 第11.3.3項「WCCHOST1のインストールと構成」

- 第11.3.4項「WEBHOST1のインストールと構成」

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

- 第11.3.6項「WCCHOST2のインストールと構成」

- 第11.3.7項「WEBHOST2のインストールと構成」

- 第11.3.8項「Imaging管理対象サーバーの構成」

- 第11.3.9項「Inbound Refineryインスタンスの構成」

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

図11-5 Oracle WebCenter Contentの高可用性アーキテクチャ

「図11-5 Oracle WebCenterの高可用性アーキテクチャ」の説明

構成には次の製品が含まれます。

- Imaging

- WebCenter Content

- Oracle Universal Records Manager(URM)

- Oracle WebCenter Content: Inbound Refinery(Inbound Refinery)

すべての製品は同じマシン上にインストールされますが、Inbound Refineryだけはリモート・マシン上に想定されています。

ImagingまたはRecordsをインストールしない場合は、構成手順の当該製品の箇所を無視してください。

11.3.1 共有記憶域

クラスタ・メンバーは、同じ構成ファイルにアクセスするために、共有記憶域を必要とします。これは、クラスタのすべてのノードからアクセスできるように設定する必要があります。

WebCenter ContentやURMクラスタを構成する場合、次の要件に従ってください。

- WebCenter Contentクラスタでは、すべてのクラスタ・メンバーは同じ構成ディレクトリを指す必要があります。このディレクトリは、クラスタのすべてのメンバーからアクセス可能な共有ディスクに配置されている必要があります。

- Recordsクラスタでは、すべてのクラスタ・メンバーは同じ構成ディレクトリを指す必要があります。このディレクトリは、クラスタのすべてのメンバーからアクセス可能な共有ディスクに配置されている必要があります。

11.3.2 Oracle Databaseの構成

Oracle RACデータベースを構成してから、ここで説明する手順を完了してください。

リポジトリ作成ユーティリティ(RCU)は、Oracle Fusion Middleware 11gキットの部品として付属する専用のCDに収録されています。

RCUを実行して、Oracle RACデータベース・リポジトリにWebCenter Contentスキーマを作成するには、任意の使用可能なホストで次の手順を実行します。

1. 次のコマンドを発行します。
prompt> RCU_HOME/bin/rcu &

2. 「ようこそ」画面で「次へ」をクリックします。

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

4. 「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。
データベース・タイプ: Oracle Database

ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: WCCDBHOST1-VIPまたはWCCDBHOST2-VIP

ポート: データベースのポート番号。例: 1521

サービス名: データベースのサービス名。例: wccdb.mycompany.com

ユーザー名: SYS

パスワード: SYSユーザーのパスワード

ロール: SYSDBA

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

すべての項目が正しく入力されると、「操作が完了しました。」というメッセージがダイアログ・ボックスに表示されます。その場合、「OK」をクリックします。それ以外は、「メッセージ」の下に、「データベースに接続できません。」や「無効なユーザー名/パスワード」などのエラーが表示されます。

5. 「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: DEVなど

コンポーネント: スキーマを作成するコンポーネントのみを選択します。「Oracle ASリポジトリ・コンポーネント」→「WebCenter Content」を選択し、次のコンポーネントを選択します。

- Oracle WebCenter Content Server 11g - Complete

- Oracle WebCenter Content: Records 11g

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

すべての項目が正しく入力されると、操作が完了したことを示す文言のあるダイアログ・ボックスが表示されます。その場合、「OK」をクリックします。それ以外の場合は、「メッセージ」の下にエラーが表示されます。これは、続行する前に解決する必要があります。

6. 「スキーマ・パスワード」画面で、「すべてのスキーマに同じパスワードを使用」が選択されていること確認します。このパスワードは、後でContent Serverがこのデータベース・スキーマに接続する手順で使用されます。
「次へ」をクリックします。

7. 「表領域のマップ」画面で「次へ」をクリックします。
警告ダイアログ・ボックスが表示されたときには、「OK」をクリックします。

表領域の作成の結果が、「操作が完了しました」というテキストとともにダイアログに表示されることを確認します。「OK」をクリックします。

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

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

11.3.3 WCCHOST1のインストールと構成

この項では、WCCHOST1のインストールおよび構成手順について説明します。

11.3.3.1 WCCHOST1へのOracle WebLogic Serverのインストール

WCCHOST1で、インストーラ実行可能ファイルを実行して、Oracle WebLogic Serverのインストールを開始します。

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

Oracle WebLogic Serverインストーラを起動します。

インストーラが起動したら、次の手順に従ってOracle WebLogic Serverをインストールします。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、Oracle WebLogicソフトウェアのインストール先となるディレクトリを選択します。
「ミドルウェア・ホーム・ディレクトリ」に、次の値を指定します。

/u01/app/oracle/product/fmw

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

3. 「セキュリティ更新のための登録」画面で、「My Oracle Support」のユーザー名とパスワードを入力します。

4. 「インストール・タイプの選択」画面では、完全インストールまたはカスタム・インストールのどちらを実行するかを指定するためのプロンプトが表示されます。
「標準」または「カスタム」を選択します。

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

5. 「製品インストール・ディレクトリの選択」画面で、次の値を指定します。
WebLogic Server:

/u01/app/oracle/product/fmw/wlserver_10.3

Oracle Coherence:

/u01/app/oracle/product/fmw/coherence_3.5.2

6. 「インストール・サマリー」画面に、インストール対象として選択したコンポーネントの一覧と、それらをインストールするために使用されるディスク領域の概算値が表示されます。
「次へ」をクリックします。

7. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除します。
「完了」をクリックします。

11.3.3.2 WCCHOST1へのOracle WebCenter Contentのインストール

Oracle WebCenter Contentインストーラを起動するには、次の手順を実行します。

注意:

UNIXでrunInstallerコマンドを実行する前に、DISPLAY環境変数が正しく設定されていることを確認します。

- UNIXの場合(次の例はLinuxの場合):

./runInstaller -jreLoc file-specification-for-jdk6

Windowsの場合:

setup.exe

JREの場所を指定します(C:\Oracle\Middleware\jdk160_11など)

インストーラで次の手順に従ってOracle WebCenter Contentをシステムにインストールします。

1. 初回インストールの場合は、Oracleインベントリの指定画面が表示されます。
デフォルトを受け入れて「OK」をクリックします。

通常の(root以外の)ユーザーとしてインストールする場合、「インベントリの場所の確認」ダイアログ・ボックスが表示されます。その指示に従うか、ローカル・インベントリでインストールを続行するを選択して「OK」をクリックします。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。

4. 「インストール場所の指定」画面で、次の値を入力します。
「ミドルウェア・ホーム・ディレクトリ」に、次の値を指定します。

/u01/app/oracle/product/fmw

「Oracleホーム・ディレクトリ」に、Oracle WebCenter Contentをインストールするサブディレクトリの名前を入力するか、デフォルトを使用します。次の場所はWCC_HOMEと呼ばれます。

/u01/app/oracle/product/fmw/wcc

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

5. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして前の画面で選択内容を変更し、「インストール」をクリックします。

6. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログ・ボックスが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

7. 「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

注意:

第11.3.3.3項「高可用性のドメインの作成」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareが最新バージョンになるように、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチがMiddlewareホームに適用されていることを確認してください。

最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

11.3.3.3 高可用性のドメインの作成

この項では、Oracle Fusion Middleware構成ウィザードを実行して、アプリケーションおよびライブラリをデプロイできる高可用性のドメインを作成および構成する方法について説明します。

Oracle Fusion Middleware構成ウィザードを起動する手順は次のとおりです。

- UNIXの場合(次の例はLinuxの場合):

WCC_HOME/common/bin/config.sh

前述のコマンドを発行する前に、DISPLAY環境変数が正しく設定されていることを確認します。

Windowsの場合:

WCC_HOME/config.cmd

Oracle WebCenter Contentドメインをコンピュータ上に作成および構成する手順は、次のとおりです。

1. 「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択します。
「次へ」をクリックします。

2. 「ドメイン・ソースの選択」画面で、インストールするアプリケーションを選択します。

- Oracle WebCenter Content Imaging - 11.1.1.0

- Oracle WebCenter Content: Records - 11.1.1.0

- Oracle WebCenter Content - Inbound Refinery - 11.1.1.0

- Oracle WebCenter Content: Imaging - 11.1.1.0

Oracle JRFやOracle Enterprise Managerなどのその他の製品も自動的に選択されます。

3. 「ドメイン名と場所の指定」画面で、次のエントリを作成します。

- ドメイン名をwccdomainに変更するか、デフォルトのbase_domainを使用します。次のように、このドメインのディレクトリが作成されます。

MW_HOME/user_projects/domains/wccdomain

- ドメインの場所: デフォルトを受け入れます。

- アプリケーションの場所: デフォルトを受け入れます。

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

4. 「管理者ユーザー名およびパスワードの構成」画面で次の操作を行います。

- 「ユーザー名」フィールドで、ドメイン管理者のユーザー名を入力するか、デフォルトのユーザー名weblogicを使用します。

- 「パスワード」フィールドで、8文字以上のユーザーのパスワードを入力します(welcome1など)。

- 「ユーザー・パスワードの確認」フィールドで、再度ユーザーのパスワードを入力します。

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

5. 「サーバーの起動モードおよびJDKの構成」画面で次の操作を行います。

- WebLogicドメインの起動モード: 「本番モード」を選択します。

- JDKの選択: 使用可能なJDKのリストからJDKを選択するか、デフォルトを受け入れます。

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

6. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

1. 下部にある表に表示されるコンポーネント・スキーマ(UCMスキーマ、IPMスキーマおよびURMスキーマ)をすべて選択します。

2. 「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択します。単一のデータベース構成の場合は、「変換しない」を選択します。

3. 画面に次のデータ・ソースが表示されていることを確認します。表11-1に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にDEVが使用されていることを想定しています。
Oracle RACでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照してください。

Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

表11-1 データソースの値の構成

コンポーネント・スキーマ

スキーマ所有者

UCMスキーマ

DEV_OCS

IPMスキーマ

DEV_IPM

URMスキーマ

DEV_URMSERVER

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

7. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
マルチ・データ・ソースの場合は、次のフィールドに値を入力します。

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

「図11-6 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面」の説明

GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。

図11-7 GridLink RACコンポーネント・スキーマの構成

「図11-7 GridLink RACコンポーネント・スキーマの構成」の説明

1. ドライバ: RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

2. サービス名 : データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(例: example.com)を含むRACサービス名を登録または追加することをお薦めします。

3. ユーザー名接頭辞: スキーマの接頭辞を入力します。表11-1に示されているユーザー名は、RCUからのスキーマ作成で、接頭辞にDEVが使用されていることを想定しています。

4. 「パスワード」と「パスワードの確認」: スキーマにアクセスするときのパスワードを入力します。

5. GridLinkデータ・ソースの場合は、SCANアドレスをリスナー・アドレス・フィールドに入力し、「ポート」フィールドにSCANポートを入力します。「ONSホスト」と「ポート」の各フィールドに、ONSホストおよびポート情報を入力します。

注意:

WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、SCANアドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、ネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。

マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。

6. 一度に1つのデータ・ソースを選択し、適切な詳細を追加することにより、各スキーマを更新します。
すべてのスキーマ(UCMスキーマ、IPMスキーマおよびURMスキーマ)に情報が入力されていることを確認します。

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

8. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常に接続できない場合は、「前へ」をクリックしてエントリを修正します。
すべてのスキーマが正しく指定されたら、「次へ」をクリックします。

9. 「JMS分散宛先」、「管理サーバー」および「管理対象サーバー、クラスタ、およびマシン」を選択します。

10. 「JMS分散宛先タイプの選択」画面で、すべてのOracle Fusion MiddlewareコンポーネントのJMSモジュールのドロップダウン・リストからUDDを選択します。
「次へ」をクリックします。

11. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- Listen address: ホストまたは仮想ホスト名を入力します。

- Listen port: 7001

- SSLリスニング・ポート: 適用なし

- SSL有効: このチェック・ボックスは選択解除したままにします。

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

12. 「管理対象サーバーの構成」画面で、既存の各サーバーに対して管理対象サーバーを追加します。たとえば、WLS_UCM1に対応したWLS_UCM2を追加します。2番目の管理対象サーバーのリスニング・ポートは、1番目のポートと同じにする必要があります。すべてのサーバーのリスニング・アドレスは、管理対象サーバーが稼働しているホスト名に設定します。
例:

WLS_UCM1

Listen Address: WCCHOST1

Listen port: 16200

WLS_UCM2

Listen Address: WCCHOST2

Listen port: 16200

すべての管理対象サーバーに対してこれを実行します。

Imagingサーバーは、管理対象サーバーのリスニング・アドレスとして仮想ホスト名が必要です。これらの仮想ホスト名および対応する仮想IPは、Imagingコンポーネントのサーバー移行を有効にするために必要です。WCCHOST1ではWCCHOST1VHN1、WCCHOST2ではWCCHOST2VHN1にVIPマッピングを有効にして、トポロジで使用されるネットワーク・システムでもホスト名を(DNSサーバーまたはhosts解決のいずれかで)正しく解決する必要があります。

Inbound Refineryは、個別のリモート・サーバーに存在するように構成する必要があります(たとえば、WCCHOST3上のIBR_Server1、WCCHOST4上のIBR_Server2など)。

13. 「クラスタの構成」画面で、サーバーの各ペアのクラスタを作成します。たとえば、UCMでは次のように作成します。

- 名前: UCM_Cluster

- クラスタ・メッセージング・モード: unicast

- マルチキャスト・アドレス: 適用なし

- マルチキャスト・ポート: 適用なし

- クラスタ・アドレス: 適用なし

他の製品用に同じように追加: IPM_Cluster、URM_Clusterなど

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

14. 「サーバーのクラスタへの割当」画面で、新しく作成したクラスタに管理対象サーバーの各ペアを割り当てます。
UCMクラスタ:

- WLS_UCM1

- WLS_UCM2

この項の前の手順で作成したすべてのクラスタに対して(IPM_Cluster、URM_Cluster、およびIBR_Cluster)これを実行します。

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

15. 「マシンの構成」画面で「Unixマシン」タブをクリックし、次のマシンを追加します。

- WCCHOST1

- WCCHOST2

- WCCHOST3(Inbound Refineryが構成されている場合)

- WCCHOST4(Inbound Refineryが構成されている場合)

16. 「サーバーのマシンへの割当」画面で次の操作を実行します。

- WCCHOST1マシンに対して、AdminServerおよびすべての*1サーバー(WLS_UCM1、WLS_IPM1、WLS_URM1)を割り当てます。

- WCCHOST2マシンに対して、すべての*2サーバー(WLS_UCM2、WLS_IPM2、WLS_URM2)を割り当てます。

- Inbound Refineryを構成する場合、WLS_IBR1をWCCHOST3に追加し、WLS_IBR2をWCCHOST4に追加します。

17. 「構成のサマリー」画面で、「作成」をクリックしてドメインを作成します。

11.3.3.4 WCCHOST1での管理サーバーおよび管理対象サーバーの起動

管理サーバーを起動します。

cd DOMAIN_HOME/bin
startWebLogic.sh &

ノード・マネージャを構成および起動します。

WCCHOST1> MW_HOME/oracle_common/common/bin/setNMProps.sh
WCCHOST1> MW_HOME/wlserver 10.3/server/bin/startNodeManager.sh
MW_HOME/oracle_common/common/bin/setNMProps.sh
MW_HOME/wlserver 10.3/server/bin/startNodeManager.sh

管理コンソール(http://WCCHOST1:7001/console)にアクセスします。管理コンソールで、WLS_UCM1、WLS_URM1、およびWLS_IPM1管理対象サーバーを停止します。

11.3.3.5 WCCHOST1およびWCCHOST2の管理サーバーおよび管理対象サーバーに対するホスト名の検証の無効化

この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。

ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。

WCCHOST1でホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールで、「サーバー」、「AdminServer」の順に選択します。

2. 「SSL」→「詳細」を選択します。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. プロンプトが表示されたら、変更内容を保存してアクティブ化します。

5. 「ホスト名の検証」を「なし」に設定します。

6. 「WLS_UCM1」→「SSL」→「詳細」を選択します。

7. 「ホスト名の検証」を「なし」に設定します。

8. WLS_URM1とWLS_IPM1に対し、ステップ6と7を繰り返します。

9. 管理サーバーおよびすべての管理対象サーバー(WLS_UCM1、WLS_URM1、WLS_IPM1など)を再起動します。

WCCHOST2でホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールで、「WLS_UCM2」、「SSL」、「詳細」の順に選択します。

2. 「ホスト名の検証」を「なし」に設定します。

3. WLS_URM2とWLS_IPM2に対し、ステップ1と2を繰り返します。

4. 管理サーバーおよびすべての管理対象サーバー(WLS_UCM2、WLS_URM2、WLS_IPM2など)を再起動します。

11.3.3.6 WLS_UCM1管理対象サーバーの構成

WLS_UCM1構成ページ(http://WCCHOST1:16200/cs)にアクセスします。

ログインすると、構成ページが開きます。WebCenter Content構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/u01/app/oracle/admin/domainName/ucm_clusterと想定しています。

構成ページの次の項目を、ここで示す値に設定します。

- コンテンツ・サーバーのインスタンス・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/cs

- ネイティブ・ファイル・リポジトリの場所: /u01/app/oracle/admin/domainName/ucm_cluster/cs/vault

- Webレイアウト・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/cs/weblayout

- サーバー・ソケット: ポート4444

- ソケット接続アドレス・セキュリティ・フィルタ: ローカル・ホストとHTTP Serverホストのリストをパイプで区切って設定します(127.0.0.1|WEBHOST1|WEBHOST2)。

- WebサーバーのHTTPアドレス: ロード・バランサHTTPのホストとポートを設定します(wcc.mycompany.com:80)。

これらの更新を適用するには、「送信」をクリックして、WLS_UCM1管理対象サーバーを再起動します。

11.3.3.7 WLS_URM1管理対象サーバーの構成

WLS_URM1構成ページ(http://WCCHOST1:16250/urm)にアクセスします。

ログインすると、構成ページが開きます。Records構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/u01/app/oracle/admin/domainName/ucm_clusterと想定しています。

構成ページの次の項目を、ここで示す値に設定します。

- コンテンツ・サーバーのインスタンス・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/urm

- ネイティブ・ファイル・リポジトリの場所: /u01/app/oracle/admin/domainName/ucm_cluster/urm/vault

- Webレイアウト・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/urm/weblayout

「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。

これらの更新を行ったら、「送信」をクリックし、WLS_URM1管理対象サーバーを再起動します。

11.3.4 WEBHOST1のインストールと構成

この項では、WEBHOST1で実行するインストールおよび構成手順について説明します。

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

この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。

2. ポート7777がWEBHOST1上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに対して次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep "7777"

Windowsの場合:

netstat -an | findstr :7777

3. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

4. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

5. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle HTTP Serverのポート番号を指定する行は非コメント化)を割り当てます。

# The port for Oracle HTTP server
Oracle HTTP Server port = 7777

6. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンドrunInstallerを発行します。

Windowsでは、setup.exeをダブルクリックします。

runInstallerとsetup.exeの各ファイルは、../install/platformディレクトリにあります。このplatformとは、LinuxやWin32などのプラットフォームです。

7. 「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /u01/app/oraInventory

オペレーティング・システムのグループ名: oinstall

次のメッセージのダイアログ・ボックスが開きます。

「インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください」

rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。

これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。

注意:

すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールでOracleインベントリ画面が表示されない場合は、次の内容を確認してください。

1. /etc/oraInst.locファイルが存在しているか。

2. このファイルが存在する場合は、表示されているインベントリ・ディレクトリが有効か。

3. インストールを実行しているユーザーがインベントリ・ディレクトリに対する書込み権限を持っているか。

8. 「ようこそ」画面で「次へ」をクリックします。

9. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

10. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。

11. 「インストール場所の指定」画面で、次の操作を行います。

- WEBHOST1で、「場所」を次のように設定します。

/u01/app/oracle/admin

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

12. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」を選択します。

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

13. 「WebLogicドメインの指定」画面で:
Oracle WebLogic Serverをインストールした場所を入力します。管理サーバーが実行されている必要があります。

- ドメイン・ホスト名: WCCHOST1

- ドメインのポート番号: 7001

- ユーザー名: weblogic

- パスワード: ******

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

14. 「コンポーネントの詳細の指定」画面で、次の操作を行います。

- WEBHOST1に次の値を入力します。

- インスタンス・ホームの場所: /u01/app/oracle/admin/ohs_inst1

- インスタンス名: ohs_inst1

- OHSコンポーネント名: ohs1

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

15. 「Web Tierポートの詳細の指定」画面で、次の操作を行います。

- 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

- Oracle HTTP Serverポートを入力します(例: 7777)。

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

16. 「Oracle Configuration Manager」画面で、次のように入力します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取ります。: このチェック・ボックスを選択します。

17. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「次へ」をクリックします。

18. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

19. 「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。

20. 「構成が完了しました」画面で「終了」をクリックして終了します。

11.3.4.2 WEBHOST1でのOracle HTTP Serverの構成

Oracle HTTP ServerをWEBHOST1にインストールしたら、次の行をOHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに追加します。

# UCM
<Location /cs>
WebLogicCluster wcchost1:16200,wcchost2:16200
SetHandler weblogic-handler
WLCookieName JSESSIONID

</Location>

<Location /adfAuthentication>
WebLogicCluster wcchost1:16200,wcchost2:16200
SetHandler weblogic-handler
WLCookieName JSESSIONID

</Location>

# URM
<Location /urm>
WebLogicCluster wcchost1:16250,wcchost2:16250
SetHandler weblogic-handler
WLCookieName JSESSIONID
</Location>

<Location /urm/adfAuthentication>
WebLogicCluster wcchost1:16250,wcchost2:16250
SetHandler weblogic-handler
WLCookieName JSESSIONID

</Location>

# IBR
<Location /ibr>
WebLogicCluster wcchost1:16300,wcchost2:16300
SetHandler weblogic-handler
WLCookieName JSESSIONID

</Location>

<Location /ibr/adfAuthentication>
WebLogicCluster wcchost1:16300,wcchost2:16300
SetHandler weblogic-handler
WLCookieName JSESSIONID

</Location>

# Imaging Application
<Location /imaging>
SetHandler weblogic-handler
WebLogicCluster WCCHOST1VHN1:16000,WCCHOST2VHN1:16000
</Location>

# AXF WS Invocation
<Location /axf-ws>
SetHandler weblogic-handler
WebLogicCluster WCCHOST1VHN1:16000,WCCHOST2VHN1:16000
</Location>

これらの行では、WEBHOST1上のOracle HTTP Serverを構成して、WCCHOST1およびWCCHOST2のクラスタ化されたアプリケーションにリクエストをルーティングします。

注意:

WLCookieNameの値は、以前のソフトウェア・リリースの値とは異なります。以前のリリースでは、この値はIDCCS_SESSIONIDでしたが、このリリースではJSESSIONIDになります。

これらの行を追加したら、Oracle HTTP Serverを再起動し、次を指定してアプリケーションにアクセスできることを確認します。

http://WEBHOST1:7777/cs
http://WEBHOST1:7777/urm
http://WEBHOST1:7777/imaging

注意:

アプリケーションの使用方法に応じて、「More Location」タグを追加する必要がある場合があります。たとえば、WebCenter ContentはWebDavへのアクセスには/_dav、Webサービスへのアクセスには/idcwsにアクセスする必要があります。詳細は、製品のドキュメントを参照してください。

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

ラウンドロビン・ロード・バランシングを使用して仮想ホスト(ucm.mycompany.com)が使用可能なOracle HTTP Serverにルーティングされるように、ロード・バランサを構成します。

また、各Oracle HTTP ServerでHTTPおよびHTTPSリスニング・ポートを監視するように、ロード・バランサを構成する必要があります。

http://WEBHOST1:7777/csでOracle WebCenter Content Serverにアクセスできることを確認します。

11.3.6 WCCHOST2のインストールと構成

この項では、WCCHOST2で実行するインストールおよび構成手順について説明します。

11.3.6.1 WCCHOST2でのOracle WebLogic Serverのインストール

WCCHOST2にOracle WebLogic Serverをインストールするには、第11.3.3.1項「WCCHOST1へのOracle WebLogic Serverのインストール」の手順をWCCHOST2で実行します。

11.3.6.2 WCCHOST2でのWCCのインストール

WCCHOST2にOracle WebCenter Contentをインストールするには、第11.3.3.2項「WCCHOST1へのOracle WebCenter Contentのインストール」の手順をWCCHOST2で実行します。

11.3.6.3 packおよびunpackを使用したWCCHOST1のドメインへの参加

packおよびunpackコマンドを使用して、WCCHOST2のWLS_UCM2管理対象サーバーをWCCHOST1のOracle WebCenter Contentドメインに参加できるようにします。

最初に、WCCHOST1でpackコマンドを実行します。

pack -managed=true -domain=/u01/app/oracle/product/WLS/11G/user_projects/domains
/wccdomain -template=wcc_template.jar -template_name="my wcc domain"

wcc_template.jarファイルをWCCHOST2にコピーした後に、WCCHOST2でunpackコマンドを実行します。

unpack -domain=/u01/app/oracle/product/WLS/11G/user_projects/domains/wccdomain
-template=wcc_template.jar

11.3.6.4 WCCHOST2でのノード・マネージャおよびWLS_UCM2サーバーの起動

WCCHOST2でノード・マネージャを起動するには、次のコマンドを使用します。

WCCHOST2> MW_HOME/oracle_common/common/bin/setNMProps.sh
WCCHOST2> WL_HOME/wlserver_10.3/bin/startNodeManager.sh

管理コンソール(http://WCCHOST1:7001/console)にアクセスします。管理コンソールで、WLS_UCM2管理対象サーバーを起動します。

11.3.6.5 WCCHOST2での管理対象サーバーの起動

管理コンソール(http://WCCHOST2:7001/console)にアクセスします。管理コンソールで、WLS_UCM2、WLS_URM2、およびWLS_IPM2管理対象サーバーを停止します。

11.3.6.6 WLS_UCM2管理対象サーバーの構成

WLS_UCM2構成ページ(http://WCCHOST2:16200/cs)にアクセスします。

ログインすると、構成ページが開きます。WebCenter Content構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/orashare/orcl/ucmと想定しています。

構成ページの次の項目を、ここで示す値に設定します。

- コンテンツ・サーバーのインスタンス・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/cs

- ネイティブ・ファイル・リポジトリの場所: /u01/app/oracle/admin/domainName/ucm_cluster/cs/vault

- Webレイアウト・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/cs/weblayout

「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。

これらの更新を行ったら、「送信」をクリックしてWLS_UCM2管理対象サーバーを再起動します。

11.3.6.7 WLS_URM2管理対象サーバーの構成

WLS_URM2構成ページ(http://WCCHOST2:16250/urm)にアクセスします。

ログインすると、構成ページが開きます。Records構成ファイルは、共有ディスクに配置されている必要があります。この例では、共有ディスクを/u01/app/oracle/admin/domainName/ucm_clusterと想定しています。

構成ページの次の項目を、ここで示す値に設定します。

- コンテンツ・サーバーのインスタンス・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/urm

- ネイティブ・ファイル・リポジトリの場所: /u01/app/oracle/admin/domainName/ucm_cluster/urm/vault

- Webレイアウト・フォルダ: /u01/app/oracle/admin/domainName/ucm_cluster/urm/weblayout

「コンテンツ・サーバーの新規インスタンス」チェック・ボックスが選択されていないことを確認します。

これらの更新を行ったら、「送信」をクリックし、WLS_URM2管理対象サーバーを再起動します。

11.3.7 WEBHOST2のインストールと構成

この項では、WEBHOST2で実行するインストールおよび構成手順について説明します。

11.3.7.1 WEBHOST2へのOracle HTTP Serverのインストール

この項では、WEBHOST2にOracle HTTP Serverをインストールする方法について説明します。

1. システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。

2. ポート7777がWEBHOST2上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに対して次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep "7777"

Windowsの場合:

netstat -an | findstr :7777

3. ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。
UNIXの場合:

ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

4. staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

5. 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle HTTP Serverのポート番号を指定する行は非コメント化)を割り当てます。

# The port for Oracle HTTP server
Oracle HTTP Server port = 7777

6. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンドrunInstallerを発行します。

Windowsでは、setup.exeをダブルクリックします。

runInstallerとsetup.exeの各ファイルは、../install/platformディレクトリにあります。このplatformとは、LinuxやWin32などのプラットフォームです。

Oracleインベントリの指定画面が表示されます。

7. 「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /u01/app/oraInventory

オペレーティング・システムのグループ名: oinstall

次のメッセージのダイアログ・ボックスが表示されます。

「インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください」

rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。

これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。

注意:

すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールでOracleインベントリ画面が表示されない場合は、次の内容を確認してください。

1. /etc/oraInst.locファイルが存在しているか。

2. このファイルが存在する場合は、表示されているインベントリ・ディレクトリが有効か。

3. インストールを実行しているユーザーがインベントリ・ディレクトリに対する書込み権限を持っているか。

8. 「ようこそ」画面で「次へ」をクリックします。

9. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

10. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。

11. 「インストール場所の指定」画面で、次の操作を行います。

- WEBHOST2で、「場所」を次のように設定します。

/u01/app/oracle/admin

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

12. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」を選択します。

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

13. 「WebLogicドメインの指定」画面で:
Oracle WebLogic Serverをインストールした場所を入力します。管理サーバーが実行されている必要があります。

- ドメイン・ホスト名: WCCHOST1

- ドメインのポート番号: 7001

- ユーザー名: weblogic

- パスワード: ******

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

14. 「コンポーネントの詳細の指定」画面で、次の操作を行います。

- WEBHOST2に次の値を入力します。

- インスタンス・ホームの場所: /u01/app/oracle/admin/ohs_inst2

- インスタンス名: ohs_inst2

- OHSコンポーネント名: ohs2

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

15. 「Web Tierポートの詳細の指定」画面で、次の操作を行います。

- 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

- Oracle HTTP Serverポートを入力します(例: 7777)。

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

16. 「Oracle Configuration Manager」画面で、次のように入力します。

- 電子メール・アドレス: My Oracle Supportアカウントの電子メール・アドレスを指定します。

- My Oracle Supportパスワード: My Oracle Supportアカウントのパスワードを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取ります。: このチェック・ボックスを選択します。

17. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「次へ」をクリックします。

18. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

19. 「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。

20. 「構成が完了しました」画面で「終了」をクリックして終了します。

11.3.7.2 WEBHOST2でのOracle HTTP Serverの構成

WEBHOST2にOracle HTTP Serverをインストールするには、第11.3.4.2項「WEBHOST1でのOracle HTTP Serverの構成」の手順をWEBHOST2で実行します。

11.3.8 Imaging管理対象サーバーの構成

この項では、Imaging JMSのJMS永続ストアの構成方法、トランザクション・リカバリのためのデフォルトの永続ストアの構成方法、およびWebCenter Content管理対象サーバーでのImaging管理対象サーバーの構成方法について説明します。最後に、Imaging管理対象サーバーのサーバー移行を構成する手順についても説明します。

11.3.8.1 Imaging JMS用のJMS永続ストアの構成

2つのノードから参照できるディレクトリとして、JMS永続ストアの場所を構成します。デフォルトでは、Imagingで使用されるJMSサーバーに永続ストアは構成されず、WebLogic Serverのストア(ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/store/default)を使用しています。次のように、共有ベースのディレクトリを使用するように、ImagingのJMSサーバーの永続ストアを変更する必要があります。

注意:

JMSメッセージ、トランザクション・ログおよびファイル・ストアでのロックの解放の詳細は、「NFSでのファイル・ストアの使用に関する考慮事項」を参照してください。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。

5. 名前(たとえば「IPMJMSServer1Store」により、作成対象のサービスを特定できます)およびターゲットのWLS_IPM1を入力します。WCCHOST1とWCCHOST2の両方からアクセスできる共有記憶域にあるディレクトリを入力します(ORACLE_BASE/admin/domain_name/ipm_cluster/jms)。

6. 「OK」をクリックして、変更をアクティブ化します。

7. 「ドメイン構造」ウィンドウで、「サービス」ノードを開き、「メッセージング」→「JMSサーバー」ノードをクリックします。

8. 表の「名前」列から「IpmJmsServer1 JMS Server」(ハイパーリンクで表示)をクリックします。

9. 「チェンジ・センター」で、「ロックして編集」をクリックします。

10. 「永続ストア」ドロップダウン・リストで、「IPMJMSServer1Store」を選択します。

11. 「保存」→「変更のアクティブ化」をクリックします。

12. 手順を繰り返して、IPMJMSServer2のIPMJMSServer2Storeを作成します。

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

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。

WLS_IPM1のデフォルト永続ストアの場所を設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

3. 「WLS_IPM1」(表の「名前」列にハイパーリンクとして表示)をクリックします。

4. 「サービス」タブをクリックします。

5. 「チェンジ・センター」で、「ロックして編集」をクリックします。

6. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。そのパス・ディレクトリ構造は次のとおりです。
ORACLE_BASE/admin/domain_name/ipm_cluster_name/tlogs

7. 「保存」をクリックして、変更をアクティブ化します。

8. WLS_IPM2サーバーに対してこの手順を繰り返します。

注意:

トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。WCCHOST1およびWCCHOST2の両方からこのディレクトリにアクセスできる必要があり、サーバーの再起動前に、このディレクトリが存在している必要があります。

11.3.8.3 WebCenter ContentでのImagingの構成

Oracle IP/Mクラスタは、WebCenter Contentクラスタにアクセスするように構成する必要があります。

11.3.8.3.1 UCMでのImagingの有効化

Oracle WebCenter Content ServerでImagingを有効化するには、次の手順を実行します。

1. Oracle WebCenter Content Server(http://WCCHOST1:16200/cs)にログインします。

2. 「管理」トレイまたはメニューを開いて、「管理サーバー」を選択します。

3. 「コンポーネント・マネージャ」をクリックします。

4. IpmRepositoryコンポーネントを有効にします。

5. UCMクラスタ内のすべての管理対象サーバーを再起動します。

11.3.8.3.2 デフォルトのファイル・ストアのアップグレード

次の手順を実行して、Oracle WebCenter Content Serverのデフォルトのファイル・ストアをアップグレードします。

1. Oracle WebCenter Content Server(http://WCCHOST1:16200/cs)にログインします。

2. 「管理」トレイまたはメニューを開いて、「プロバイダ」を選択します。

3. 「DefaultFileStore」の「情報」リンクをクリックします。

4. 「編集」をクリックし、「更新」をクリックします。

5. クラスタ内のすべてのコンテンツ・サーバーを再起動します。

11.3.8.3.3 UCMの許可されたホストのリストへのImagingサーバーのリスニング・アドレスの追加

WLS_IPM1およびWLS_IPM2管理対象サーバー(それぞれ、WCCHOST1VHN1およびWCCHOST2VHN1)のImagingサーバーのリスニング・アドレスをUCMの許可されたホストのリストに追加する手順は、次のとおりです。

1. ファイル/u01/app/oracle/admin/domainName/ucm_cluster/config/config.cfgを編集して、次の行を削除またはコメント・アウトします。

SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1

2. WLS_IPM1およびWLS_IPM2リスニング・アドレスをUCMに接続できるアドレスのリストに含めるために、次の2行を追加します。

SocketHostNameSecurityFilter=localhost|localhost.mydomain.com|wcchost1vhn1|wcchost2vhn1
AlwaysReverseLookupForHost=Yes

UCMサーバーを再起動して、変更を有効にします。

11.3.8.3.4 UCMシステムへの接続の作成

次の手順を実行して、UCMシステムへの接続を作成します。

1. WLS_IPM1イメージング・コンソール(http://WCCHOST1:16200/ imaging)にログインします。

2. 左側のペインで、「接続の管理」→「Content Server接続の作成」をクリックします。

3. 新しい接続の名前と説明を入力し、「次へ」をクリックします。

4. 「接続設定」画面で、次の操作を実行します。

- 「ローカルContent Serverの使用」が選択されていることを確認します。

- Content Serverポートを4444に設定します。

- 2つのサーバーを「Content Serverプール」に追加します。

- WCCHOST1:4444

- WCCHOST2:4444

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

5. 「接続セキュリティ」画面で、WebLogicユーザーに対するデフォルトの選択をそのまま受け入れて、「次へ」をクリックします。

6. 接続の詳細を確認し、「送信」をクリックします。

11.3.8.4 BPEL CSF資格証明の構成

ImagingからBPELシステムに接続する場合、SOAシステムと通信するために必要な資格証明を構成する必要があります。これらの資格証明を追加する手順は次のとおりです。

1. (管理サーバーが存在する)WCCHOST1のOracle WebCenter Content Oracleホームの下のcommon/binにディレクトリを変更します。

WCCHOST1>cd ORACLE_HOME/common/bin

(ORACLE_HOMEは、MW_HOME/wccの下のOracle WebCenter Contentホームです。)

2. Oracle WebLogic Scripting Tool(WLST)を実行します。

WCCHOST1>./wlst.sh

3. connect()を実行して、ユーザー名、パスワード、および管理サーバーのURL(t3://WCCHOST1:7001)を指定します。

wls:/offline> connect()

4. CSF(資格証明ストア・フレームワーク)資格証明を作成します。この資格証明は、ImagingがBPELシステムへの接続に使用する資格証明です。これをBPEL管理ユーザーにします。CSF資格証明は、「alias」がキーとなり、CSFの「map」という中に保存されるユーザー名/パスワードのペアです。OWSM Webサービスと統合するため、Imagingは現在oracle.wsm.securityという標準のOWSM CSFマップを使用しています。資格証明を作成するには、createCred WLSTコマンドを使用します。

wls:/wcc_domain/serverConfig> createCred(map="oracle.wsm.security", key="basic.credential", user="weblogic", password="password_for_credential")

コマンドの「key」は、Imaging管理ユーザー・インタフェースのBPEL接続定義の「資格証明別名」プロパティに使用される「alias」です(APIのConnection.CONNECTION_BPEL_CSFKEY_KEYプロパティにも使用されます)。OWSMおよびBPELで使用される標準のデフォルト名であるため、この例では別名「basic.credential」を使用します。ただし、別名はマップ内で一意であれば、任意に指定できます。

5. 資格証明のリストコマンドを実行して、資格証明が作成されたことを確認します。

wls:/wcc_domain/serverConfig> listCred(map="oracle.wsm.security", key="basic.credential")
{map=oracle.wsm.security, key=basic.credential}
Already in Domain Runtime Tree

[Name : weblogic, Description : null, expiry Date : null]
PASSWORD: password_for_credential

11.3.8.5 BPEL接続の構成

BPEL接続を構成する手順は次のとおりです。

1. WLS_IPM1イメージング・コンソール(http://WCCHOST1VHN1:16000/imaging)にログインします。

2. 左側のペインで、「接続の管理」→「ワークフロー接続の作成」をクリックします。

3. 「BPEL接続の作成」をクリックします。

4. BPELマシン名、およびオプションで説明を入力します。

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

6. 「接続設定」画面で、次の操作を実行します。

1. プロバイダ名フィールドに、2つのSOAサーバー・リスニング・アドレスをカンマで区切って入力します: SOAHOST1VHN2, SOAHOST2VHN1

2. BPELポートを指定します: 8001

3. ターゲットBPELシステムに必要な場合、「SSL」オプションを選択します。

4. 「BPEL CSF資格証明の構成」の項で作成した資格証明の別名を指定します。

5. 「接続のテスト」ボタンをクリックして、接続パラメータを確認し、BPELマシンに存在するコンポジットを確かめます。

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

7. 必要に応じて、付与するセキュリティを変更します。

8. 「次へ」をクリックしてから、「送信」をクリックします。

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

Oracle WebLogic Server ImagingクラスタのフロントエンドHTTPホストおよびポートを設定する必要があります。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「クラスタ」をクリックします。

5. 「IPM_Cluster」を選択します。

6. 「HTTP」タブをクリックします。

7. 次の値を設定します。

- フロントエンド・ホスト: wcc.mycompany.com

- フロントエンドHTTPSポート: 443

- フロントエンドHTTPポート: 80(SSLを使用しない場合)

8. 「保存」をクリックします。

9. 管理コンソールの「チェンジ・センター」セクションで「変更のアクティブ化」をクリックします。

10. サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。

11.3.8.7 Imagingインスタンスのサーバー移行の構成

この項では、Imagingインスタンスのサーバー移行を構成する方法について説明します。

11.3.8.7.1 サーバー移行の構成について

次の手順では、Imaging管理対象サーバーのサーバー移行を有効にします。これにより、サーバーまたはプロセスの障害時に、Imaging管理対象サーバーは別のノードにフェイルオーバーできます。

WebLogic管理対象サーバーに対してサーバー移行を構成する手順は次のとおりです。

- ステップ1: サーバー移行leasing表のユーザーと表領域を設定する

- ステップ2: Oracle WebLogic管理コンソールを使用してGridLinkデータ・ソースまたはマルチ・データ・ソースを作成する

- ステップ3: ノード・マネージャのプロパティ・ファイルを編集する

- ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する

- ステップ5: サーバー移行ターゲットを構成する

- ステップ6: サーバー移行をテストする

11.3.8.7.2 Oracle WebLogic管理コンソールを使用したGridLinkデータ・ソースまたはマルチ・データ・ソースの作成

マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。

- このデータ・ソースが非XAデータ・ソースであることを確認します。

- Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。

- データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。

- これらのデータ・ソースをクラスタにターゲット指定します。

- データ・ソースの接続プールの初期容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」、「接続プール」タブの順にクリックし、「初期容量」フィールドに0(ゼロ)を入力します。

- ONSデーモンがデータベース・サーバーで常に実行中であることを確認します。ONSデーモンをデータベース・サーバーで起動するには、onsctlコマンド(start)を実行します。

GridLinkデータソースの作成

GridLinkデータ・ソースを作成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. 「データ・ソースの概要」ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択します。

5. 次の情報を入力します。

1. 「名前」フィールドで、データ・ソースの論理名を入力します。たとえば、gridlinkと入力します。

2. JNDIの名前を入力します。たとえば、jdbc/gridlinkと入力します。

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

6. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。

7. 「個別のリスナー情報の入力」を選択して、「次へ」をクリックします。

8. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名name example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。

注意:

Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名(例: example.com)を含むRACサービス名を登録または追加することをお薦めします。

- ホスト名: データベースをホストするサーバーのDNS名またはIPアドレス。Oracle GridLinkサービスとインスタンス間の接続の場合、特定のマルチ・データ・ソースの各データ・ソースで同じ名前にする必要があります。

- Port: データベース・サーバーが接続リクエストをリスニングするポート。

- データベース・ユーザー名: データベース・ユーザー名。たとえば、myDataBaseと入力します。

- パスワード: パスワード。たとえば、myPassword1です。

- パスワードを確認して、「次へ」をクリックします。

ヒント:

詳細は、Oracle Fusion Middleware管理コンソール・オンラインに関するヘルプを参照してください。

コンソールにより、完全なJDBC URLが自動的に生成されます。例:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1234))(ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))

9. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。
Oracle WebLogicにより、管理サーバーからデータベースへの接続の作成が試行されます。接続テストの結果がページの上部に表示されます。テストに失敗した場合は、構成エラーをすべて修正してテストを再試行します。

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

10. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- 「ONSホストとポート」で、ONSベースのFANイベントを受け取るためにONSデーモンが接続するリスニング・アドレスとリスニング・ポートのカンマ区切りのリストを入力します。単一クライアント・アクセス名(SCAN)アドレスを使用すると、FAN通知にアクセスできます。

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

11. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
「次へ」をクリックします。

12. 「ターゲットの選択」ページで「Dept1_Cluster1」をターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。

13. 「終了」をクリックします。

14. 「変更のアクティブ化」をクリックします。

マルチ・データ・ソースの作成

マルチ・データ・ソースを作成する手順は、次のとおりです。

1. 管理者資格証明を使用して、管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「サービス」ノードを開き、次に、「データ・ソース」ノードを開きます。

3. 「チェンジ・センター」で「ロックして編集」をクリックします。

4. 「新規」をクリックしてから、「マルチ・データ・ソース」をクリックします。

5. 名前として、leasingと入力します。JNDI名として、jdbc/leasingと入力します。

6. アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。「次へ」をクリックします。

7. ターゲット・クラスタを選択します。「次へ」をクリックします。

8. 「非XAドライバ」(デフォルト)を選択します。「次へ」をクリックします。

9. 「新しいデータ・ソースの作成」をクリックします。

10. 名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。

注意:

leasing表のマルチ・データ・ソースを作成する場合は、名前を<MultiDS>-rac0や<MultiDS>-rac1などの形式で入力します。

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

12. 「グローバル・トランザクションのサポート」の選択を解除します。「次へ」をクリックします。

13. leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。

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

15. 「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。

16. データ・ソースをクラスタにターゲット指定します。

17. データ・ソースを選択して、右の画面に追加します。

18. Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。

19. 2つ目のデータ・ソースをマルチ・データ・ソースに追加します。

20. 保存して、「変更のアクティブ化」をクリックします。

11.3.8.7.3 サーバー移行のテスト

最後の手順は、サーバー移行をテストすることです。サーバー移行が適切に機能していることを確認するには、次の手順を実行します。

WCCHOST1から次の処理を実行します。

1. 管理対象サーバーWLS_IPM1を停止します。これを行うには、このコマンドを実行します:

WCCHOST1> kill -9 pid

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

WCCHOST1> ps -ef | grep WLS_IPM1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、管理対象サーバーWLS_IPMnのpidを確認します。

MW_HOME\jrockit_160_20_D1.0.1-2124\bin\jps -l -v

2. ノード・マネージャのコンソールを確認します。WLS_IPM1の浮動IPが無効になっていることを示すメッセージが表示されることを確認します。

3. ノード・マネージャがWLS_IPM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

WCCHOST2から次の処理を実行します。

1. ローカルのノード・マネージャのコンソールを確認します。WCCHOST1で最後にWLS_IPM1の再起動が最後に試行されてから30秒経過した後、WCCHOST2のノード・マネージャによって、WLS_IPM1の浮動IPが有効化されていること、およびこのノードでサーバーが再起動されていることが表示されます。

2. 同じIPのsoa-infraコンソールにアクセスします。

管理コンソールからの検証

「移行ステータス」表に、移行の状態に関する情報が表示されます。

管理コンソールで移行を検証する手順は、次のとおりです。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

11.3.9 Inbound Refineryインスタンスの構成

この項では、Inbound Refineryの構成情報について説明します。

11.3.9.1 Inbound RefineryとInbound Refineryクラスタの概要

Inbound Refineryインスタンスはクラスタ化できません。このインスタンスは、完全に個別に動作します。複数のInbound Refineryインスタンスを同じWebLogicドメインに追加できますが、次の制限を遵守する必要があります。

- マシンごとのドメインごとに複数のInbound Refineryをインストールできません。

- 個別のマシン上のInbound Refineryインスタンスは、その構成を共有ディスク上でなくすべてローカルで行う必要があります。

ローカル・コンテンツの要件は、Content Serverインストールが存在するマシン上にInbound Refineryインスタンスをインストールする場合に重要になります。Content Serverクラスタの構成は共有する必要がありますが、Inbound Refineryインスタンスの構成情報は他のInbound Refineryインスタンスと共有することはできません。

11.3.9.2 Content ServerとInbound Refineryの構成

1つ以上のInbound Refineryインスタンスを使用するようにContent Serverを構成することも、同一のInbound Refineryが1つ以上のContent Serverに対するプロバイダとして機能するように構成することもできます。Inbound Refineryインスタンスを構成するには、Oracle Fusion Middleware変換についての管理者ガイドを参照してください。

前の構成で作成されたすべてのInbound Refineryは、UCMまたはURMクラスタに追加することをお薦めします。そうすることで多対多の関係が構築され、UCM/URMクラスタのすべてのメンバーはInbound Refineryクラスタの任意のメンバーからの変換をリクエストできます。

Inbound Refineryインスタンスは、独自のドメインにインストールすることも、既存のドメインの拡張としてインストールすることもできます。

11.3.9.3 Inbound RefineryインスタンスとOracle HTTP Server

Inbound RefineryにはHTTPを介して1回のみアクセスして、その構成を初期化する必要があります。これは、管理対象サーバーのリスニング・アドレスで直接実行できます。Inbound Refineryは、HTTPサーバーの背後に配置しないでください。

Inbound Refineryへのすべての後続のアクセスは、ソケット・リスナーを介して行われます。

12 Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ

この章では、アクティブ/パッシブ・トポロジを構成して管理する方法について説明します。次の項目が含まれます。

- 第12.1項「Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジの概要」

- 第12.2項「アクティブ/パッシブ・デプロイメントのためのOracle Fusion Middlewareの構成」

- 第12.3項「Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジ例」

- 第12.4項「コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換」

12.1 Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジの概要

Oracle Fusion Middlewareは、Oracle Fusion Middleware Cold Failover Cluster(コールド・フェイルオーバー・クラスタ)を使用して、すべてのコンポーネントにアクティブ/パッシブ・モデルを提供します。コールド・フェイルオーバー・クラスタ構成では、複数のアプリケーション・サーバー・インスタンスが同じアプリケーション・ワークロードを処理するように構成されますが、アクティブになるインスタンスは常に1つのみです。

2つのノードのコールド・フェイルオーバー・クラスタを使用すると、Oracle Application Server中間層コンポーネントのアクティブ/パッシブ構成の可用性を実現できます。コールド・フェイルオーバー・クラスタでは、1つのノードがアクティブになり、別のノードはスタンバイ・ノードとしてパッシブになります。アクティブ・ノードで障害が発生すると、スタンバイ・ノードがアクティブ化され、中間層コンポーネントはそのノードからクライアント・リクエストの処理を続行します。すべての中間層コンポーネントが新しいアクティブ・ノードにフェイルオーバーします。フェイルオーバー後、障害ノードでは中間層コンポーネントは実行されなくなります。

コールド・フェイルオーバー・クラスタ構成の最も一般的なプロパティは、次のとおりです。

- 共有記憶域: 共有記憶域は、コールド・フェイルオーバー・クラスタにおける主要プロパティです。アクティブ/パッシブ構成におけるOracle Fusion Middlewareパッシブ・インスタンスは、アクティブ・インスタンスと同じように、Oracleバイナリ、構成ファイル、ドメイン・ディレクトリおよびデータにアクセスできます。コールド・フェイルオーバー・クラスタ構成にあるすべての参加ノードでアクセス可能な記憶域にこれらのアーティファクトを配置することで、このアクセスを構成します。通常、アクティブ・ノードでは共有記憶域がマウントされて、パッシブ・ノードではアンマウント状態になりますが、ノードがアクティブになるとこの記憶域にアクセス可能になります。この共有記憶域は、両方のノードでアクセス可能な二重ポート対応ディスク・デバイスにできますし、NASやSANなどのデバイスベース記憶域にもできます。共有記憶域は通常のファイル・システム上にインストールできます。コールド・フェイルオーバー・クラスタの場合、ボリュームをマウントするノードは一度に1つのみです。

- 仮想ホスト名: コールド・フェイルオーバー・クラスタ・ソリューションでは、2つのノードが1つの仮想ホスト名と1つの仮想IPを共有します(仮想ホスト名と仮想IPは対応するもので、このガイドでは互換的に使用します)。ただし、この仮想IPを使用できるノードは、常に1つのアクティブ・ノードに限定されます。アクティブ・ノードで障害が発生してスタンバイ・ノードがアクティブになると、仮想IPが新しいアクティブ・ノードに移行します。この新しいアクティブ・ノードでは仮想IPによりすべてのリクエストが処理されます。仮想ホスト名により、デプロイメントの単一システム・ビューが実現されます。コールド・フェイルオーバー・クラスタのデプロイメントは、この仮想IP上でリスニングするように構成されます。たとえば、ハードウェア・クラスタの2つの物理ホスト名がnode1.mycompany.comおよびnode2.mycompany.comである場合、名前cfcvip.mycompany.comによって、このクラスタの単一のビューが提供されます。DNSでは、cfcvip.mycompany.comが仮想IPにマップされます。この仮想IPは、ノード1とノード2との間で変動します。ハードウェア・クラスタを使用すると、仮想IPのフェイルオーバーが管理されるため、どの物理ノードがアクティブでリクエストを実際に処理しているのかを中間層のクライアントでは検出されません。

- ハードウェア・クラスタ: 通常、コールド・フェイルオーバー・クラスタ・デプロイメントでは、ハードウェア・クラスタを使用します。ハードウェア・クラスタでは、そのアーキテクチャにおいて共有記憶域と仮想IPが管理されます。これは、これらの共有リソースの高信頼性フェイルオーバーの役割を果たし、堅牢なアクティブ/パッシブ・ソリューションを実現します。ほとんどのコールド・フェイルオーバー・クラスタは、次のもので構成されるハードウェア・クラスタにデプロイされます。

- 同じサブユニット内にある2つのノード

- 2つのノード間における高速プライベート・インターコネクト

- パブリック・ネットワーク・インタフェース: このインタフェース上でクライアント・リクエストが処理され、仮想IPが有効化されます。

- 2つのノードからアクセス可能な共有記憶域:これには、クォーラム・デバイスとして機能する共有記憶域と、Oracle Fusion Middlewareインストールとデータベース・インストールの共有記憶域が含まれます。

- ノードとコンポーネントの障害を管理するために実行されるクラスタウェア

- 予定のスイッチオーバーと予定外のフェイルオーバー: コールド・フェイルオーバー・クラスタの一般的デプロイメントは、2つのノードのハードウェア・クラスタです。使用率を最大にするために、通常、これらのノードにはどちらも、実行しているデプロイメントの要素がいくつかあり、必要に応じて一方のノードが他方のノードの要素のバックアップ・ノードの役割を果たします。たとえば、あるノードでアプリケーション層(WebLogicコンテナ)が実行され、別のノードでWeb層(Oracle HTTP Server)が実行されるデプロイメントなどがあります。どちらか一方のノードをメンテナンスのために停止した場合や、どちらか一方のノードで障害が発生した場合には、停止していないノードが現在のサービスのホスト処理が継続しながら、停止したノードのサービスのホスト処理を実行します。
スタンバイ・ノードにスイッチオーバーするための高レベル手順は次のとおりです。

1. 1次ノード上の中間層サービスを停止します(そのノードが利用可能な場合)。

2. 現在のアクティブ・ノードからパッシブ・ノードへ仮想IPをフェイルオーバーさせます。現在のノードでそれを停止してから、パッシブ・ノードで有効化し起動します。

3. 現在のアクティブ・ノードからパッシブ・ノードへ共有ディスクをフェイルオーバーさせます。この操作には、現在のノードから共有ディスクをアンマウントしてからパッシブ・ノードにマウントする操作が含まれます。

4. パッシブ・ノード上で中間層サービスを起動し、アクティブにします。

フェイルオーバー管理には、次の2つの方法があります。

- クラスタ・マネージャ機能を使用した自動フェイルオーバー
クラスタ・マネージャではサービスを提供しており、これによって、サービスの状態を監視するパッケージを開発できます。サービスやノードの停止(計画停止の操作または計画外停止の操作)が検出されると、あるノードから別のノードへサービスが自動的にフェイルオーバーします。フェイルオーバー前に、所定のノード上でサービスの再起動を試みるようにパッケージを開発できます。同様に、アクティブ・ノード自体が停止した場合、クラスタウェアでノードの停止状態が検出され、指定のパッシブ・ノード上で起動を試行できます。任意のクラスタウェアを使用してこれらの操作を自動化すると、完全な自動フェイルオーバー機能を実現できます。

Oracle Fusion MiddlewareではOracle Clusterwareを使用してこの機能を実現します。Oracle Cluster Ready Servicesによるコールド・フェイルオーバー・クラスタ環境の管理の詳細は、第13章「Oracle Cluster Ready Servicesの使用」を参照してください。クラスタ・フェイルオーバーの管理には、任意の利用可能クラスタウェアを使用できます。

- 手動フェイルオーバー
このアプローチでは、計画スイッチオーバーの手順を手動で実行します(障害の検出およびフェイルオーバーは手動です)。この方法では、長時間サービスが使用できなくなる可能性があります。

アクティブ/パッシブ・デプロイメントの場合、通常、サービスが停止する時間は短時間です。これは、同じノード上でインスタンスを再起動するのに要する時間、またはパッシブ・ノードにインスタンスをフェイルオーバーするに要する時間になります。

アクティブ/パッシブ・トポロジ: 長所

- 可用性の向上
アクティブ・インスタンスに障害が発生した場合や、アクティブ・インスタンスをオフラインにする必要がある場合、いつでも同一構成のパッシブ・インスタンスで処理の引継ぎができます。この構成では、通常の単一インスタンス型デプロイメントより可用性のレベルが高くなります。また、アクティブ/パッシブ・デプロイメントは、ハードウェアの計画メンテナンス操作や計画外メンテナンス操作に対して可用性と保護機能を実現します。計画メンテナンスのためにノードを停止する必要がある場合、パッシブ・ノード上のミドルウェア・サービスを起動できます。適切な時点で元のノードへスイッチバックします。

- 運用コストの削減
アクティブ/パッシブ構成では、1つのプロセス・セットのみが稼働して、リクエストを処理します。アクティブ・インスタンスの管理では通常、複数のアクティブ・インスタンスの配列の管理より低コストです。

- コールド・フェイルオーバー・クラスタ・トポロジの実装はそれほど難しくありません。それらのクラスタではロード・バランサが不要ですが、アクティブ/アクティブ・トポロジでは必要になるからです。

- ロード・バランシング・アルゴリズム、クラスタリング、レプリケーションなどのオプションを構成する必要がないため、コールド・フェイルオーバー・クラスタ・トポロジの実装は、アクティブ/アクティブ・トポロジほど難しくありません。

- アクティブ/パッシブ・トポロジでは、アクティブ/アクティブ・トポロジより正確に、1つのインスタンスのトポロジがシミュレートされます。

- アプリケーションの非依存性
一部のアプリケーションは、アクティブ/アクティブ構成に適さない場合があります。このようなアプリケーションには、アプリケーションの状態への依存度が高いアプリケーションや、ローカルに格納された情報への依存度が高いアプリケーションなどあります。シングルトン・アプリケーションには、アクティブ/パッシブ・デプロイメントが適しています。アクティブ/パッシブ構成では、常に1つのインスタンスのみがリクエストを処理します。

アクティブ/パッシブ・トポロジ: 短所

- アクティブ/パッシブ・トポロジは、アクティブ/アクティブ・トポロジほどスケーラビリティが高くありません。ノードをトポロジに追加して処理能力を増強することはできません。

- HTTPセッションの状態およびEJBステートフル・セッションBeanからの状態情報は、レプリケートされないため、ノードが予期せずに終了すると失われます。そのような状態は、データベースまたは共有記憶域にあるファイル・システムに永続的に保持されます。ただし、これは余分なオーバーヘッドを必要とするため、単一ノードのコールド・フェイルオーバー・クラスタ・デプロイメントのパフォーマンスに影響する可能性があります。

- アクティブ/パッシブ・デプロイメントでは、単一ノードのデプロイメントよりも停止時間が短縮されます。ただし、アクティブ/アクティブ・デプロイメントでは、さらに停止時間が短縮されます。

12.2 アクティブ/パッシブ・デプロイメントのためのOracle Fusion Middlewareの構成

Oracle Fusion Middlewareコンポーネントには、様々な種類の、Java EEコンテナにデプロイされたコンポーネントと非Java EEコンポーネントがあります。Oracle Internet Directory、Oracle Virtual DirectoryおよびOracle Reportsはシステム・コンポーネントです。Oracle SOA SuiteやOracle WebCenterポータルは、Oracle WebLogic ServerにデプロイされるJava EEコンポーネントです。

管理コンソールとOracle Enterprise Manager Fusion Middleware ControlもWebLogicコンテナにデプロイされます。Java EEコンポーネントとシステム・コンポーネントのどちらも、コールド・フェイルオーバー・クラスタ環境にデプロイでき、同じシステム上または異なるシステム上で共存させることができます。同じシステムに配置すると、同じ仮想IPを共有して単一ユニットとしてフェイルオーバーするように構成できますし、別々の仮想IPを使用して個別にフェイルオーバーするようにも構成できます。ほとんどのOracle Fusion Middlewareデプロイメントでは、リポジトリ作成ユーティリティ(RCU)を使用して作成されたコンポーネント・メタデータ用やアプリケーション・データ用にデータベースが使用されます。多くの場合、コールド・フェイルオーバー・クラスタ中間層デプロイメントでは、同じクラスタにデプロイされたコールド・フェイルオーバー・クラスタ・データベースが使用されます。一般的なデプロイメントには、同じハードウェア・クラスタにある異なる共有ディスクと異なるVIPを使用して別々のフェイルオーバー・ユニットとして構成されたコンポーネントが2つあります。

Oracle Fusion Middlewareにおいて、アクティブ/パッシブ・トポロジを作成するには、次の手順を実行します。

1. 単一インスタンス構成としてコンポーネントをインストールします。このインスタンスをコールド・フェイルオーバー・クラスタ・デプロイメントに変換する予定がある場合、共有ディスクを使用してインストールします。つまり、Middlewareホーム、インスタンス・ホーム(システム・コンポーネントの場合)およびドメイン・ディレクトリ(WebLogicデプロイメントの場合)を共有ディスク上に配置します。1つのユニットとしてフェイルオーバーするものはすべて、共有ディスク上に配置する必要があります。

2. インストール後、デプロイメントをコールド・フェイルオーバー・クラスタ・デプロイメントに変換し、仮想IP上でリスニングするように構成します。この仮想IPは現在のアクティブ・ノード上で構成します。障害が発生すると、Oracle Fusion Middlewareデプロイメントとともにパッシブ・ノードにフェイルオーバーします。

この一般的手順は、コールド・フェイルオーバー・クラスタのOracle Databaseに適用されます。たとえば、Oracle Databaseインスタンスを単一インスタンスのデプロイメントとしてインストールしてから、コールド・フェイルオーバー・クラスタ用に変換します。コールド・フェイルオーバー・クラスタのOracle Fusion Middlewareデプロイメントでは、Oracle Real Application Cluster(Oracle RAC)データベースも使用できます。

次の各項では、インストール後の構成手順について説明します。この手順によって単一インスタンスのデプロイメントをコールド・フェイルオーバー・クラスタ・デプロイメントに変換します。

この章の残りの部分では、Oracle Fusion Middlewareスイートの個別コンポーネントごとに、コールド・フェイルオーバー・クラスタを変換する方法について説明します。最初の項では、基本インフラストラクチャ・コンポーネントの手順について詳細に説明します。そしてその後続の項では、Oracle Fusion Middlewareの個別コンポーネントの手順について詳細に説明します。Oracleインスタンスやドメインなど、あらゆるデプロイメントでは、これらの複数のコンポーネントがマシンにインストールされます。インスタンスやドメインの全体を変換する手順は次のとおりです。

- フェイルオーバー・ユニットに組み込むコンポーネントを決定します。

- それらを同じ共有ディスク上にデプロイします。

注意:

Oracle Fusion Middlewareコンポーネントのインストールとデプロイの詳細は、それぞれのFusion Middlewareコンポーネントのインストレーション・ガイドを参照してください。

- このフェイルオーバー・ユニットで使用する仮想IPを決定します。通常、すべてのコンポーネントで同じ仮想IPを使用しますが、別々のIPも使用できます。ただし、すべてのコンポーネントをまとめてフェイルオーバーさせます。

- 個々のコンポーネントごとに変換手順を適用して、デプロイメント全体を変換します。インストールのコールド・フェイルオーバー・クラスタ変換には複数の項の手順が適用されるため、必ず次の順序で変換を実行してください。

- 管理サーバーまたはEnterprise Managerインスタンス(該当する場合)を変換します。

- デプロイメントにあるすべての管理対象サーバーを変換します。

- Oracleインスタンス(非Java EEデプロイメント)を変換します。

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

- 第12.2.1項「コールド・フェイルオーバー・クラスタの要件」

- 第12.2.2項「ディレクトリおよび環境変数の用語」

- 第12.2.3項「Oracle Fusion Middlewareインフラストラクチャ・コンポーネントの変換」

- 第12.2.4項「Oracle Fusion Middlewareコンポーネントの変換」

- 第12.2.5項「Oracle Databaseの変換」

12.2.1 コールド・フェイルオーバー・クラスタの要件

コールド・フェイルオーバー・クラスタのデプロイには、2つ以上のノードを使用します。これらのノードの1つにインストールを行い、もう一方のノードはパッシブ・ノードとなります。両方のノードの要件は、次のとおりです。

- 各ノードはオペレーティング・システム・レベルのあらゆる面で同じである必要があります。たとえば、オペレーティング・システム、バージョンおよびパッチ・レベルが同一である必要があります。

- 各ノードはハードウェアの特性が同じである必要があります。それによって、通常の運用中とフェイルオーバー時のパフォーマンスが予測可能になります。通常の役割を処理できる処理能力に加えて、フェイルオーバー・シナリオに対応するために対応が必要な負荷が増大しても処理できるように、各ノードを設計することをお薦めします。停止シナリオ中におけるパフォーマンスの低下がサービス・レベル合意(SLA)で許容される場合のみ、その必要はありません。

- 通常の運用中とフェイルオーバー時のどちらでも同じノードに対して共有記憶域をマウントできるように、各ノードで同じマウント・ポイントが解放されている必要があります。

- 2つのノードのユーザーIDとグループIDが類似しており、インスタンスを所有するユーザーのユーザーIDとグループIDが両方のノードで同じである必要があります。

- oraInventoryの場所が両方のノードで同じであり、インスタンスまたはドメインの所有者のアクセス・レベルが類似している必要があります。oraInst.locファイルの場所だけでなくbeahomelistファイルの場所も同じである必要があります。

- 指定インスタンスでは、現在アクティブになっているマシンには関係なく、同じリスニング・ポートを使用するため、コールド・フェイルオーバー・クラスタのインスタンスで使用するポートが両方のノードで解放されていることを確認します。

注意:

変換を開始する前に、ドメイン全体のバックアップを実行してください。また、編集前にローカル・バックアップ・ファイルを作成することをお薦めします。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。次のバックアップを作成することをお薦めします。

- すべてのドメイン・ディレクトリ

- すべてのインスタンス・ホーム

- データベース・リポジトリとMiddlewareホーム(オプション)

12.2.2 ディレクトリおよび環境変数の用語

次のリストは、この章で使用するディレクトリと変数について説明しています。

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

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

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

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

- ORACLE_COMMON_HOME: すべてのOracle Fusion Middlewareソフトウェア・スイートに共通するバイナリおよびライブラリ・ファイルを含むOracleホームです。特に、Oracle共通ホームには、Oracle Enterprise Manager Fusion Middleware Control(Fusion Middlewareの管理に使用される)に必要なファイルとOracle Java Required Files(JRF)が含まれています。

- DOMAIN_HOME: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。

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

- /localdisk: FMWインストール(MW_HOMEまたはDOMAIN_HOME)がローカル・ディスク上にある場合のディレクトリ・ツリーのルート。それはローカル・ディスクのMW_HOMEを表すために使用されます。

- /shareddisk: FMWインストール(MW_HOMEまたはDOMAIN_HOME)がCFC構成のいずれかのノードによってマウントされている共有ストレージ・システム上にある場合に、ディレクトリ・ツリーのルート。それは、共有ディスクのMW_HOMEを表すために使用されます。

これらのディレクトリで一貫性を保つためにこのガイドで使用しておりお薦めする値の例は、次のとおりです。

- ORACLE_BASE: /u01/app/oracle

- MW_HOME(アプリケーション層): ORACLE_BASE/product/fmw

- ORACLE_COMMON_HOME: MW_HOME/oracle_common

- WL_HOME: MW_HOME/wlserver_10.3

アプリケーション・ディレクトリの場所の例: ORACLE_BASE/admin/domain_name/apps

Oracleインスタンスの場所の例: ORACLE_BASE/admin/instance_name

共有記憶域のマウント・ポイントにはORACLE_BASEをお薦めします。多くの場合、この場所に、フェイルオーバー・ユニットのすべての永続ビットが同じ共有記憶域に格納されることになります。1つのノードに複数のコールド・フェイルオーバー・クラスタが存在する場合に、それぞれが独立してフェイルオーバーすると、フェイルオーバー・ユニットのそれぞれに対して異なるマウント・ポイントが存在します。

12.2.3 Oracle Fusion Middlewareインフラストラクチャ・コンポーネントの変換

Oracle Fusion Middlewareデプロイメントは、すべての製品セットに共通する基本インフラストラクチャ・コンポーネントで構成されます。この項では、これらのコンポーネントのコールド・フェイルオーバー・クラスタ変換手順について説明します。

コールド・フェイルオーバー・クラスタ構成では、2つの管理サーバー・トロポジがサポートされています。次の各項では、これら2つのトポロジについて説明します。また、コールド・フェイルオーバー・クラスタ変換用に管理サーバーを準備するためにインストールと構成を行う手順についても説明します。

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

- 第12.2.3.1項「管理サーバーのトポロジ1」

- 第12.2.3.2項「トポロジ1のインストール手順」

- 第12.2.3.3項「管理サーバーのトポロジ2」

- 第12.2.3.4項「トポロジ2のインストール手順」

- 第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」

- 第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」

- 第12.2.3.7項「ノード・マネージャの変換」

- 第12.2.3.8項「Oracle Process Management and Notification Serverの変換」

- 第12.2.3.9項「OracleインスタンスのOracle Enterprise Managerの変換」

- 第12.2.3.10項「Web層のコンポーネントとクライアントの変換」

- 第12.2.3.11項「インスタンス固有の考慮事項」

12.2.3.1 管理サーバーのトポロジ1

図12-1は、Oracle Cold Failover Clusterにおける最初のサポート対象トポロジを示しています。

図12-1 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ1

「図12-1 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ1」の説明

図12-1では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。Middlewareホームとドメイン・ディレクトリは、ある時点でノード1またはノード2にマウントされている共有ディスク上にあります。Middlewareホームとドメイン・ディレクトリは両方とも、同じ共有ディスク上、またはいっしょにフェイルオーバーできる複数の共有ディスク上にあります。複数のアプリケーションまたは環境用に複数のFusion Middlewareドメインがある企業では、管理サーバーの高可用性にはこのトポロジが最適です。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。それぞれの管理サーバーでは、その仮想IPおよび一連の共有ディスクを使用して、ドメイン・サービスの高可用性を実現できます。

12.2.3.2. トポロジ1のインストール手順

このトロポジのアプリケーション・サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。

Middlewareホームのインストール

このインストールには、共有ディスク上におけるOracleホーム、WebLogicホームおよびドメイン・ホームが含まれます。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。ストレージ・サブシステムにおいて複数のノードでの同時マウントが可能な場合でも、これが推奨構成になります。これは、通常の単一インスタンス型インストールとして実行されます。管理サーバー(およびEnterprise Manager)の単体インストールの詳細は、当該コンポーネントに関連する章を参照してください。各スイートの全体的な手順は次のとおりです。

Oracle SOAまたはOracle WebCenterポータルの場合:

1. WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

2. Oracle SOAまたはWebCenterのOracleホームをインストールします。
『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』またはOracle Fusion Middleware Oracle WebCenterポータル・インストレーション・ガイドを参照してください。

3. 構成ウィザードを起動して、管理サーバーのみのドメインを作成します。
「ドメイン・ソースの選択」画面で、次を選択します。

- 以下の製品をサポートするために、自動的に構成されたドメインを生成する

- Enterprise ManagerとOracle JRFを選択します。

Oracle Identity Managementの場合:

1. WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

2. Oracle Identity Management 11gのインストーラで、ドメイン作成オプションを使用してIDMドメインをインストールおよび構成します。「コンポーネントの構成」画面で、Enterprise Manager(デフォルトで選択されています)以外のすべての選択を解除します。
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

Oracle Portal、Forms、ReportsおよびDiscovererの場合:

1. WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

2. Oracle Fusion Middleware 11g Portal、Forms、ReportsおよびDiscovererのインストーラで、ドメイン作成オプションを使用してクラシック・ドメインをインストールおよび構成します。「コンポーネントの構成」画面で、Enterprise Managerが選択されていることを確認します。

注意:

この場合、製品コンポーネント用に1つ以上の管理対象サーバーがこのプロセスでインストールされます(管理サーバー単独のインストールはできません)。この管理対象サーバーは、該当コンポーネントの手順に従ってCFCに変換する必要があります。これは、管理サーバーのユニットと同じフェイルオーバー・ユニットの一部になります。

Oracle Business Intelligenceの場合:

1. WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

2. Oracle Fusion Middleware 11g Business Intelligenceインストーラで、BIシステムを新規作成するオプションを使用して、Business Intelligenceドメインのインストールと構成を実行します。

注意:

この場合、製品コンポーネント用に1つ以上の管理対象サーバーがこのプロセスでインストールされます(管理サーバー単独のインストールはできません)。この管理対象サーバーは、該当コンポーネントの手順に従ってCFCに変換する必要があります。これは、管理サーバーのユニットと同じフェイルオーバー・ユニットの一部になります。

コールド・フェイルオーバー・クラスタ用の管理サーバーの構成

コールド・フェイルオーバー・クラスタ用に管理サーバーを構成する手順は次のとおりです。

1. rootユーザーとして次のコマンドを使用して、仮想IPをプロビジョニングします。
Linuxの場合

/sbin/ifconfig interface:index IP_Address netmask netmask
/sbin/arping -q -U -c 3 -I interface IP_Address

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIPアドレスが有効化されます。

/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0
/sbin/arping -q -U -c 3 -I eth0 130.35.46.17

Windowsの場合:

netsh interface ip add address interface IP Address netmask

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、"Local Area Connection"のインタフェースでIPアドレスが有効化されます。

netsh interface ip add address "Local Area connection" 130.35.46.17 255.255.224.0

2. 第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。

3. 仮想IP上でコンソールにアクセスして、管理サーバーの変換を検証します。
http://cfcvip.mycompany.com:7001/console

http://cfcvip.mycompany.com:7001/em

4. 次の手順に従って、管理サーバーを2番目のノードに手動でフェイルオーバーさせます。

1. 管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。

2. Middlewareホームとドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。

3. 記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。

4. rootユーザーとして次のコマンドを使用して、ノード1で仮想IPを無効化します。
Linuxの場合:

/sbin/ifconfig interface:index down

ここで、IP Addressは仮想IPです。次の例では、eth0インタフェースでIPアドレスが無効化されます。

/sbin/ifconfig eth0:1 down

Windowsの場合:

netsh interface ip delete address interface IP_Address

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、Local Area ConnectionのインタフェースでIPアドレスが有効化されます。

netsh interface ip delete address "Local Area connection" 130.35.46.17

5. ステップ1と同様のコマンドを使用して、ノード2で仮想IPを有効化します。

6. 管理サーバー・プロセスを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。

7. 管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。

12.2.3.3 管理サーバーのトポロジ2

図12-2は、Oracle Cold Failover Clusterにおける2番目のサポート対象管理サーバー・トポロジを示しています。

図12-2 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ2

「図12-2 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ2」の説明

図12-2では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。管理サーバーが使用するドメイン・ディレクトリは、共有ディスク上にあります。これは必須です。この共有ディスクは、ある時点でノード1またはノード2にマウントされます。ソフトウェアを格納するMiddlewareホーム(WebLogicホームとOracleホーム)は、共有ディスク上でなくてもかまいません。ローカル・ディスクにも配置できます。管理サーバーをノード1で実行する場合は、ソフトウェアにノード1のMiddlewareホームを使用し、ノード2で実行する場合は、ノード2のMiddlewareホームを使用します。2つのMiddlewareホームは、デプロイされた製品、Oracleホームおよびパッチに関して同じ状態に維持する必要があります。どちらの場合も、共有ドメイン・ディレクトリやドメイン・ホームで利用できる構成を使用します。これは共有されるため、フェイルオーバーの前後で同じ構成が使用されるようになります。

この共有ドメイン・ディレクトリでは、他の管理対象サーバーも実行できます。また、管理サーバー専用にも使用できます。ドメイン・ディレクトリを他の管理対象サーバーと共有する場合、管理サーバーがフェイルオーバーされるときのために、それらのフェイルオーバーに関して適切に考慮する必要があります。考慮事項の一部を次に示します。

1. 読取りや書込みを行うために複数のノードで同時に共有記憶域をマウントできる場合は、管理サーバーのドメイン・ディレクトリを他の管理対象サーバーと共有できます。また、管理対象サーバーとは別にフェイルオーバーすることもできます。管理サーバーをフェイルオーバーして、指定ノードで独立して管理対象サーバーの実行を継続できます。これが可能な理由は、この場合、管理サーバーはVIPのフェイルオーバーのみを必要とし、共有ディスクのフェイルオーバーは必要としないためです。管理対象サーバーは、引き続きドメイン・ディレクトリやドメイン・ホームを利用できます。このような記憶域の例として、クラスタ・ファイル・システムに接続されたNASやSAN/Directなどの記憶域があります。

2. 一度に1つのノードのみ共有記憶域をマウントできる場合、管理サーバーのドメイン・ディレクトリを管理対象サーバーと共有することは、管理サーバーがフェイルオーバーされると、同じドメイン・ディレクトリから切り離される管理対象サーバーを停止する必要があることを意味します。

このトポロジでは、ハードウェア・クラスタを使用するとフェイルオーバーの自動化に役立ちます(適切に構成されたクラスタウェアを使用した場合)。ただし、これは必須ではありません。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。各管理サーバーでそれぞれ固有の仮想IPと共有ディスク・セットを使用して、ドメイン・サービスの高可用性を実現できます。

このトポロジは、Oracle SOA SuiteおよびOracle WebCenterポータルSuiteに対してのみサポートされています。

注意:

Oracle Identity Managementについては、コールド・フェイルオーバー・クラスタのための代替トポロジもサポートされています。詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

12.2.3.4 トポロジ2のインストール手順

このトロポジの管理サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。

Middlewareホームのインストール

OracleホームとWebLogicホームを含むMiddlewareホームを、ドメインにある2つのノードに個別にインストールします。管理サーバー・ドメイン・ディレクトリは共有ディスク上に作成します。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。これは、通常の単一インスタンス型インストールです。管理サーバーおよびEnterprise Managerの単体インストールの詳細は、製品スイートを参照してください。

Oracle SOA SuiteまたはOracle WebCenterポータル用にMiddlewareホームをインストールする手順は、次のとおりです。

1. ノード1にOracle WebLogic Serverソフトウェアをインストールします。

2. ノード1にSOAまたはWebCenterのOracleホームをインストールします。

3. ノード2でステップ1とステップ2を繰り返します。

4. ノード1で構成ウィザードを起動して、管理サーバーのみのドメインを作成します。
「ドメイン・ソースの選択」画面で、次を選択します。

- 以下の製品をサポートするために、自動的に構成されたドメインを生成する

- Enterprise ManagerとOracle JRFを選択します。

5. 「ドメイン名と場所の指定」画面で、ドメイン名を入力し、ドメイン・ディレクトリがディレクトリと共有記憶域のマウント・ポイントに一致していることを確認します。

コールド・フェイルオーバー・クラスタ用のMiddlewareホームの構成

コールド・フェイルオーバー・クラスタ用にMiddlewareホームを構成する手順は次のとおりです。

1. 仮想IPをプロビジョニングします。例:
Linuxの場合:

/sbin/ifconfig eth0:1 IP_Address netmask netmask
/sbin/arping -q -U -c 3 -I eth0 IP_Address

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIPアドレスが有効化されます。

/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0
/sbin/arping -q -U -c 3 -I eth0 130.35.46.17

Windowsの場合:

netsh interface ip add address interface IP_Adress netmask

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、"Local Area Connection"のインタフェースでIPアドレスが有効化されます。

netsh interface ip add address "Local Area connection" 130.35.46.17 255.255.224.0

2. 第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。

3. 仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.mycompany.com:7001/console

http://cfcvip.mycompany.com:7001/em

4. 管理サーバーを2番目のノードに手動でフェイルオーバーさせます。

1. 管理サーバー・プロセス、および指定されているMiddlewareホームの外部で実行されているその他のプロセスを停止します。

2. Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。

3. 記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。

4. ノード1で仮想IPを無効化します。
Linuxの場合:

/sbin/ifconfig interface:index down

次の例では、eth0インタフェースでIPアドレスが無効化されます。

/sbin/ifconfig eth0:1 down

Windowsの場合:

netsh interface ip delete address interface addr=IP Address

この場合、IP Addressは仮想IPアドレスです。次の例では、'Local Area Connection'のインタフェースでIPアドレスが有効化されます。

netsh interface ip delete address 'Local Area connection' addr=130.35.46.17

5. ノード2で仮想IPを有効化します。

6. 次のコマンドを使用して、管理サーバー・プロセスを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。

7. 管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。

12.2.3.5 コールド・フェイルオーバー・クラスタ用の管理サーバーの変換

共有ディスクにインストールされている管理サーバーをノード1から変換するには、この項の手順に従ってください。この手順ではコンテナを変換するため、管理コンソールとOracle Enterprise Manager Fusion Middleware Controlの両方がコールド・フェイルオーバー・クラスタ用に変換されます。それにより、このコンテナにデプロイされるOWSM-PMなどの他のコンポーネントも、コールド・フェイルオーバー・クラスタ対応になります。これらすべてのサービスのアドレスがcfcvip.mycompany.comに変換されます。インストール後、コールド・フェイルオーバー・クラスタでないインスタンスをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 仮想ホスト用のノードを作成します。

1. 「環境」、「マシン」の順に選択します。

2. 「チェンジ・センター」で、「ロックして編集」、「新規」の順にクリックします。

3. 「名前」フィールドにcfcvip.mycompany.comと入力します。

注意:

「リスニング・アドレス」フィールドはlocalhostに設定したままにします(CFCソリューションはこの設定に依存します)。これを仮想IPアドレスまたはその他の値に変更しないでください。

4. 「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。

5. 「次」、「終了」の順にクリックします。

6. 「マシンのサマリー」タブで、作成したばかりのマシンの名前をクリックします。

7. 「サーバー」タブをクリックしてから、「追加」をクリックします。

8. 既存のサーバーを選択して、このマシンに関連付けます。
サーバー選択のドロップダウン・リストで、「AdminServer」が選択されていることを確認します。

9. 「変更のアクティブ化」をクリックします。

3. cfcvip.mycompany.com上でリスニングするように管理サーバーを構成します。

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 管理サーバー(AdminServer)をクリックします。

4. リスニング・アドレスをcfcvip.mycompany.comに変更します。

5. 「保存」をクリックします。

6. 「変更のアクティブ化」をクリックします。

7. 管理サーバーを再起動します。

注意:

通常、管理サーバーのコールド・フェイルオーバー・クラスタへの変換はドメイン作成時に実行されることが期待されるため、ドメインにおいて他の部分への変更は行われないものと考えられます。この変更がドメイン作成後に行われ、他のコンポーネントがドメインにインストールされている場合、次の管理サーバー変換項で説明している手順に従ってください。

管理サーバーのクライアント側構成の変更

ドメインにある既存エンティティでは、管理サーバーとの通信に新しいアドレスを使用する必要があります。たとえば、管理対象サーバーを手動で起動する際、管理サーバーのアドレスをcfcvip.mycompany.comとして指定します。

INSTANCE_HOME/config/OPMN/opmnディレクトリにあるinstance.propertiesファイルで、次の変更を行います。

adminHost=cfcvip.mycompany.com

OPMN登録コマンドを使用して、コールド・フェイルオーバー・クラスタ管理サーバーにOracleインスタンスを登録したり再登録する場合は、opmnctlコマンドのAdminHostの場所で管理サーバーの新しい場所(cfcvip.mycompany.com)を参照します。

Oracle Enterprise Managerのクライアント側構成の変更

Enterprise Managerは管理サーバーが稼働する同じコンテナの一部であるため、管理サーバーをコールド・フェイルオーバー・クラスタに変換すると、Enterprise Managerも変換されます。ドメインの一部として構成されたEnterprise Managerエージェントが存在する場合は、それらのエージェント構成でEnterprise Managerの新しい場所を使用する必要があります。Enterprise Managerの新しい場所を構成するには、エージェントごとに次の手順を行います。

1. ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_asinst_ 1/sysman/configに設定します。

2. emd.propertiesファイルで、次の属性内のnode1.mycompany.comをcfcvip.mycompany.comに変更します。

- REPOSITORY_URL

- EmdWalletSrcUrl

3. 次のコマンドを使用して、エージェントを停止してから再起動します。

cd INSTANCE_HOME/EMAGENT/emagent_dir/bin
./emctl stop agent
./emctl start agent
./emctl status agent

これによってリポジトリのURLが表示されます。このURLは新しいホストを指します。

12.2.3.6 Oracle WebLogic管理対象サーバーの変換

すべてのOracle Fusion Middlewareコンポーネントは、管理対象サーバーにデプロイされます。Oracle WebLogic Serverにデプロイされたアプリケーションやコンポーネントをコールド・フェイルオーバー・クラスタに変換する際の重要な手順としては、使用する仮想IPにリスニング・アドレスを変更することがあります。この変更は、対象のコンポーネントがデプロイされている特定の管理対象サーバーに対して実行します。この変更には、管理コンソールまたはWLSTコマンドを使用できます。

次の例では、WLS_EXMPLという管理対象サーバーをコールド・フェイルオーバー・クラスタに変換する一般的手順について説明します。これらの手順は、Fusion Middlewareコンポーネントの管理対象サーバーに適用されます。

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

- 第12.2.3.6.1項「Fusion Middleware管理コンソールによるOracle WebLogic Managed Serverの変換」

- 第12.2.3.6.2項「WLSTコマンドラインによるOracle WebLogic管理対象サーバーの変換」

12.2.3.6.1 Fusion Middleware管理コンソールによるOracle WebLogic管理対象サーバーの変換

次の手順で、cfcvip.mycompany.comはコールド・フェイルオーバー・クラスタに使用する仮想IPで、WLS_EXMPLは変換対象となる管理対象サーバーです。

1. 管理コンソールにログインします。

2. 仮想ホストのマシンを作成します。

1. 「環境」→「マシン」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックし「新規」をクリックします。

3. 「名前」フィールドでは、cfcvip.mycompany.comと入力します。

4. 「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。

5. 「Next」をクリックして、「Finish」をクリックします。

6. 新規に作成された「ノード」をクリックします。

7. 「ノード・マネージャ」タブをクリックします。

8. リスニング・アドレスをcfcvip.mycompany.comに更新します。

9. 「保存」をクリックします。

10. 「変更のアクティブ化」をクリックします。

3. WLS_EXMPL管理対象サーバーを停止します。

1. 「環境」→「サーバー」を選択します。

2. 「制御」をクリックします。

3. 「WLS_EXMPL」を選択します。

4. 「停止」ドロップダウン・メニューで、「ただちに強制停止」を選択します。

4. WLS_EXMPL管理対象サーバーを仮想ホストのマシンに関連付けます。

1. 「環境」→「サーバー」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「構成」をクリックします。

4. 「WLS_EXMPL」を選択します。

5. 「ノード」では、プルダウン・メニューから新規作成ノードを指定して割り当てます。

6. 「リスニング・アドレス」にcfcvip.mycompany.comと入力します。

7. 「保存」をクリックします。

8. 「変更のアクティブ化」をクリックします。

5. 管理対象サーバーWLS_EXMPLを起動します。

1. 「環境」→「サーバー」を選択します。

2. 「制御」をクリックします。

3. 「WLS_EXMPL」を選択します。

4. 「起動」をクリックします。

12.2.3.6.2 WLSTコマンドラインによるOracle WebLogic管理対象サーバーの変換

WLSTコマンドを使用してもOracle WebLogic管理対象サーバーを変換できます。

次の手順を実行する前に、変換対象となる管理対象サーバーを停止することをお薦めします。

オンライン・モード(WebLogic Server管理サーバーが稼働している状態)でWLSTコマンドラインを使用して管理対象サーバーを変換する手順は次のとおりです。

1. コマンドラインで次のように入力します。

WL_HOME/server/bin/setWLSEnv.sh
WL_HOME/common/bin/wlst.sh

2. WLSTで、次のコマンドを入力します。

wls:/offline>connect(<username>,<password>,<AdminServer location>)

例:

wls:/offline>connect('WebLogic', 'welcome1', 't3://admin.mycompany.com:7001')

wls:/DomainName/serverConfig> edit()
wls:/DomainName/edit> startEdit()
wls:/DomainName/edit !> create('cfcvip.mycompany.com','Machine')
wls:/DomainName/edit !> cd('Machines/cfcvip.mycompany.com/NodeManager/cfcvip.mycompany.com')
wls:/DomainName/edit !> set('ListenAddress', 'cfcvip.mycompany.com')
wls:/DomainName/edit !>cd ('Servers')
wls:/DomainName/edit/Servers !>cd ('WLS_EXMPL')
wls:/DomainName/edit/Servers/WLS_EXMPL !>set('Machine',' cfcvip.mycompany.com ')
wls:/DomainName/edit/Servers/WLS_EXMPL !>set('ListenAddress',' cfcvip.mycompany.com ')
wls:/DomainName/edit/Servers/WLS_EXMPL !> save()
wls:/DomainName/edit/Servers/WLS_EXMPL !> activate()
wls:/DomainName/edit/Servers/WLS_EXMPL> exit()

3. 管理対象サーバーを停止してから(停止していない場合)、再起動します。

管理対象サーバーの変換の完了後に、このサーバーに対するすべての参照で新しいリスニング・アドレスcfcvip.mycompany.comが使用されていることを確認します。Oracle HTTP Serverがこの管理対象サーバーのフロントエンドとして機能している場合、この管理対象サーバー上のアプリケーションを参照しているマウント・ポイントでmod_wls_ohs構成をすべて変更して、新しいリスニング・エンド・ポイントにルーティングします。

12.2.3.7 ノード・マネージャの変換

コールド・フェイルオーバー・クラスタ環境ではノード・マネージャを使用できます。次の構成が可能です。

- 仮想IP上で同様にリスニングし、コールド・フェイルオーバー・クラスタ・スタックの残りの部分とともにフェイルオーバーするノード・マネージャ。ASCRSベースのデプロイメントでは、コールド・フェイルオーバー・クラスタのFusion Middlewareインスタンスが稼働しているMiddlewareホームと同じMiddlewareホームにノード・マネージャが属している必要があります。このノード・マネージャはこのFusion Middlewareインスタンス専用であることが前提になります。この場合は、ローカル・ホストでリスニングするネットワーク・チャネルを別に構成することをお薦めします。他のポートでリスニングするボックス上に他のノード・マネージャを共存させることができます。詳細は、第13章「Oracle Cluster Ready Servicesの使用」を参照してください。

- コールド・フェイルオーバー・クラスタ・スタックの残りの部分とともにフェイルオーバーしないノード・マネージャ。この場合、ノード・マネージャはコールド・フェイルオーバー・クラスタ用に構成されずに、コールド・フェイルオーバー・クラスタの仮想IPだけでなく、マシン上のすべてのIPをリスニングします。また、フェイルオーバー・ノードには、同様に構成されているノード・マネージャが配置され、構成済になっています。WebLogicインスタンスに関連付けられたノードは、ローカル・ホスト上のノード・マネージャと通信します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』を参照してください。

一般的にコールド・フェイルオーバー・クラスタの場合、フェイルオーバー発生時にポートが競合しないように、ポートの使用を計画する必要があります。

ノード・マネージャをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。

1. ノード・マネージャが実行されている場合は停止します。
ノード・マネージャが最初に起動された後にのみ、nodemanager.propertiesファイルは作成されます。

必要に応じて、ノード・マネージャを再起動します。

2. WL_HOME/common/nodemanager/ディレクトリにあるnodemanager.propertiesファイルで、ListenAddressを仮想IPに設定します。
例:

ListenAddress=cfcvip.mycompany.com

3. WL_HOME/server/binディレクトリにあるStartNodeManager.shファイルを使用して、ノード・マネージャを再起動します。ASCRSベースのデプロイメントの場合は、WL_HOME/server/bin/cfcStartNodemanager.shを使用してノード・マネージャを起動します。
詳細は、第13章「Oracle Cluster Ready Servicesの使用」を参照してください。

注意:

必要に応じて、startNodeManager.shスクリプトのかわりにcfcStartNodemanager.shスクリプトのみを使用して、ノード・マネージャを起動します。

注意:

WebLogic管理対象サーバーおよび管理サーバーでは、ホスト名の検証は特定のインストールで有効化または無効化できます。検証が有効でノード・マネージャがこれらのインスタンスを管理しているCFCインストールでは、ホスト名の検証の手順の中で仮想IPのcfcvip.mycompany.comの証明書を使用する必要があります。

12.2.3.8 Oracle Process Management and Notification Serverの変換

Oracle Process Management and Notification Server(OPMN)は、システム・コンポーネントのプロセス管理に使用され、アプリケーション・サーバー・インスタンスの一部です。

コールド・フェイルオーバー・クラスタ環境にデフォルトのOPMN構成を維持することをお薦めします。OPMNプロセス自体のコールド・フェイルオーバー・クラスタ変換で他に必要な手順はありません。

コールド・フェイルオーバー・クラスタ用にOracleインスタンスを変換する場合で、これが管理サーバーに登録されているときは、これらのファイルで次の変更を行います。

1. 管理サーバー・ドメインのDOMAIN_HOME/opmnディレクトリにあるtopology.xmlファイルで、このOracleインスタンス(コールド・フェイルオーバー・クラスタ変換の対象)のホスト名エントリをcfcvip.mycompany.comに変更します。
たとえば、Oracle HTTP Serverインスタンスをコールド・フェイルオーバー・クラスタに変換するには、topology.xmlファイルで次のように設定します。

<property name="HTTPMachine" value="cfcvip.mycompany.com"/>

インスタンス自体:

<ias-instance id="asinst " instance-home="/11gas3/MW/asinst" host="cfcvip.mycompany.com" port="6701">

2. INSTANCE_HOME/config/OPMN/opmnディレクトリのopmn.xmlファイルで、<physicalhostname>をcfcvip.mycompany.comに置き換えます。

</ias-component><ias-component id="ReportsServer_<physicalhostname>_asinst_2">
<process-set id="ReportsServer_<physicalhostname>_asinst_2" restart-on-death="true" numprocs="1">

3. INSTANCE_HOME/config/OPMN/opmnディレクトリのinstance.propertiesファイルで、adminHost=<physical hostname>をadminHost=<cfcvip.mycompany.com>に置き換えます。

4. すべてのコンポーネントを再起動します。

12.2.3.9 OracleインスタンスのOracle Enterprise Managerの変換

Oracle Internet Directory、Oracle Virtual Directory、Web層コンポーネント、Oracle Portal、Forms、ReportsおよびDiscovererコンポーネントなどのOracleインスタンスをコールド・フェイルオーバー・クラスタに変換する場合は、そのOracleインスタンスの一部であるEnterprise Managerエージェントもコールド・フェイルオーバー・クラスタに変換する必要があります。

Enterprise Managerエージェントを変換する手順は次のとおりです。

1. 次のコマンドを使用して、Enterprise Managerエージェントを停止します。

cd INSTANCE_HOME/EMAGENT/emagent_dir/bin
./emctl stop agent

2. ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_instance name/sysman/configに設定します。

3. emd.propertiesファイルで、emd_url属性のnode1.mycompany.comをcfcvip.mycompany.comに変更します。

4. エージェント側のtargets.xmlファイルを変更します。

cd INSTANCE_HOME/EMAGENT/emagent_dir/cp targets.xml targets.xml.org

ホストとoracle_emdに関連付けられたターゲットのみが含まれるように、targets.xmlを変更します。他のエントリはすべて削除します。例:

<Targets AGENT_TOKEN="ad4e5899e7341bfe8c36ac4459a4d569ddbf03bc">
<Target TYPE="oracle_emd" NAME=cfcvip.mycompany.com:port"/>
<Target TYPE="host" NAME=cfcvip.mycompany.com  DISPLAY_NAME=cfcvip.mycompany.com/>
</Targets>

5. エージェントを停止してから再起動します。

cd INSTANCE_HOME/EMAGENT/emagent_dir/bin
./emctl start agent

管理サーバーのドメイン・ディレクトリにあるEnterprise Managerサーバーに対して、次の変更を行います。

1. 使用ディレクトリをMW_HOME/user_projects/domains/domain_name/sysman/stateに設定します。

2. MW_HOME/user_projects/domains/domain_name/sysman/stateディレクトリにあるtargets.xmlファイルで、ホスト名をnode1.mycompany.comからcfcvip.mycompany.comに変更します。

12.2.3.10 Web層のコンポーネントとクライアントの変換

Web層は、2つの主要コンポーネントであるOracle HTTP ServerとOracle Web Cacheで構成されます。次の2つの項では、Oracle HTTP ServerとOracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する方法について説明します。

12.2.3.10.1 Oracle HTTP Serverの変換

Oracle HTTP Serverをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。

INSTANCE_HOME/config/OHS/component_name/httpd.confで、次の属性を変更します。

Listen cfcvip.mycompany.com:port #OHS_LISTEN_PORT
Listen cfcvip.mycompany.com:port #OHS_PROXY_PORT
ServerName cfcvip.mycompany.com

また、第12.2.4.14項「シングル・サインオンの再登録(必要な場合)」で説明されているシングル・サインオンの再登録も実行します。

Oracle HTTP Serverのクライアント

コールド・フェイルオーバー・クラスタに変換したOracle HTTP ServerにOracle Web Cacheインスタンスがルーティングされる場合は、INSTANCE_HOME/config/WebCache/component_name/webcache.xmlで次の属性を変更します。

node1.mycompany.comをcfcvip.mycompany.comに変更します。このnode1.mycompany.comは、変換前のOracle HTTP Serverのアドレスです。

HOST ID="h1" NAME="cfcvip.mycompany.com" PORT="8888" LOADLIMIT="100"
OSSTATE="ON"/>
<HOST ID="h2" NAME="cfcvip.mycompany.com" PORT="8890" LOADLIMIT="100" OSSTATE="ON"
SSLENABLED="SSL"/>

12.2.3.10.2 Oracle Web Cacheの変換

Oracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。

1. クラスタの両方のノードにある/etc/hostsで、物理ホスト名に別名を設定します。
これはノードのIPアドレスの別名です。Linuxの場合は/etc/hostsでこれを設定し、Windowsの場合はWindowsの場所でこれを設定します。この別名は、wcprfx.mycompany.comです。たとえば、ノード1では、/etc/hostsファイル(UNIXの場合)のエントリはn.n.n.n node1 node1.mycompany.com wcprfx wcprfx.mycompany.comになります。

フェイルオーバー・ノードのノード2では、/etc/hostsファイル(UNIXの場合)のエントリはn.n.n.m node2 node2.mycompany.com wcprfx wcprfx.mycompany.comになります。

Windowsの場合は、すべてのノードにおいてC:\SystemRoot\system32\drivers\etc\hostsにあるファイルでこの変更を行います。SystemRootはWinntまたはWindowsです。

2. INSTANCE_HOME/config/WebCache/wc1/webcache.xmlで、次の操作を行います。

- node1.mycompany.comをcfcvip.mycompany.comに変更します(node1.mycompany.comはOracle Web Cacheがインストールされている場所であり、変換前にリスニング対象となるホスト・アドレスです)。

SITE NAME="cfcvip.mycompany.com"

- SSLポートと非SSLポートで仮想ホスト名のエントリをcfcvip.mycompany.comに変更します。例:

<HOST SSLENABLED="NONE" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8888"
NAME="cfcvip.mycompany.com" ID="h0"/>
<HOST SSLENABLED="SSL" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8890"
NAME="cfcvip.mycompany.com" ID="h3"/>
<VIRTUALHOSTMAP PORT="8094" NAME="cfcvip.mycompany.com">
<HOSTREF HOSTID="h3"/>
</VIRTUALHOSTMAP>
<VIRTUALHOSTMAP PORT="8090" NAME="cfcvip.mycompany.com">
<HOSTREF HOSTID="h0"/>
</VIRTUALHOSTMAP>

- wcprfx.mycompany.comに基づくように、キャッシュ名エントリを変更します。wcprfx.mycompany.comは、クラスタにあるすべてのノードの/etc/hostsで作成された別名です。例:

<CACHE WCDEBUGON="NO" CAPACITY="30" VOTES="1" INSTANCENAME="asinst_1"
COMPONENTNAME="wc1" ORACLEINSTANCE="ORACLE_INSTANCE_HOME"
HOSTNAME="wcprfx.mycompany.com" ORACLEHOME="ORACLE_HOME"
NAME=" wcprfx.mycompany.com-WebCache">

- MULTIPORTセクションで、次の構成のIPADDRをANYからcfcvip.mycompany.comに変更します。

PORTTYPE="NORM"
SSLENABLED="SSL" PORTTYPE="NORM"
PORTTYPE="ADMINISTRATION"
PORTTYPE="INVALIDATION"
PORTTYPE="STATISTICS"

例:

<MULTIPORT>
<LISTEN PORTTYPE="NORM" PORT="8090"
IPADDR="cfcvip.mycompany.com"/>
<LISTEN SSLENABLED="SSL" PORTTYPE="NORM" PORT="8094"
IPADDR="cfcvip.mycompany.com">
<WALLET>ORACLE_INSTANCE/config/WebCache/wc1/keystores/
default</WALLET>
</LISTEN>
<LISTEN PORTTYPE="ADMINISTRATION" PORT="8091"
IPADDR="cfcvip.mycompany.com"/>
<LISTEN PORTTYPE="INVALIDATION" PORT="8093" IPADDR="
cfcvip.mycompany.com"/>
<LISTEN PORTTYPE="STATISTICS" PORT="8092"
IPADDR="cfcvip.mycompany.com"/>
</MULTIPORT>

12.2.3.11 インスタンス固有の考慮事項

コールド・フェイルオーバー・クラスタ環境では、フェイルオーバー・ノード(node2.mycompany.com)をすべての面でインストール・マシン(node1.mycompany.com)と同じにする必要があります。フェイルオーバー・ノードをインストール・ノードと同じにするには、フェイルオーバー・インスタンスで次の手順を実行します。

12.2.3.11.1 UNIXプラットフォーム

UNIXプラットフォームでの手順は次のとおりです。

1. 前述のマウントおよびアンマウントの手順に従って、ノード1(インストール・ノード)からフェイルオーバー・ノード(ノード2)へMiddlewareホームをフェイルオーバーさせます。

2. rootとして、次の操作を行います。

- ノード1にあるものと同一のoraInst.locファイルを/etcディレクトリに作成します。

- ORACLE_HOMEディレクトリにあるroot.shファイルをノード2で実行します(これは、製品スイートで利用可能な場合や必要に応じて実行します)。

3. ORACLE_HOME/oui/bin/attachHome.shディレクトリにあるattachHomeコマンドを使用して、oraInventoryを2番目のノードで作成します。

12.2.3.11.2 Windowsプラットフォーム

Windowsでの手順は次のとおりです。

アプリケーション・サーバー・インスタンス(Web層、IDMインストールのOID/OVD、Oracle Portal、Form、ReportsおよびDiscoverer)の場合:

1. ノード2でOPMNサービスを作成するには、次のコマンドを実行します。

sc create OracleProcessManager_instance_name  binPath= "ORACLE_HOME\opmn\bin\opmn.exe -S -I Instance_Home"

例:

sc create OracleProcessManager_asinst binPath= "X:\Middleware\im_oh\opmn\bin\opmn.exe -S -I X:\Middleware\asinst"

2. ノード1とノード2の両方で、OracleProcessManager_instance_nameサービスが手動で起動するように設定します。

sc config OracleProcessManager_instance_name start= demand

Oracle Business Intelligenceのインストールの場合:

コールド・フェイルオーバー・クラスタでOracle Business Intelligenceを使用するときには、Oracle Business Intelligenceが使用する特定のWindowsレジストリのエントリを、アクティブ・ノードとパッシブ・ノードで完全に同じにする必要があります。このレジストリのエントリをアクティブ・ノードとパッシブ・ノードで確実に同じにするには、ノード1でレジストリ・エントリをエクスポートして、そのレジストリ・エントリをノード2でインポートします(ノード1はアクティブ・ノードを表し、ノード2はパッシブ・ノードを表します)。これを実行する手順は、次のとおりです。

ノード1でのOracle Business Intelligenceレジストリ・エントリのエクスポート

次の手順を実行して、ノード1でOracle Business Intelligenceのレジストリ・エントリをエクスポートします。

1. ノード1で、Windowsのレジストリ・エディタを起動します。これを行うには、次のコマンドをWindowsのコマンドラインから入力します。

C:\>regedit

2. レジストリ・エディタで、ノードHKEY_LOCAL_MACHINE\SOFTWARE\Oracleに移動して、このノードを選択します。このノードを右クリックして、「エクスポート」を選択します。それらのエントリを、一意の名前を付けた.regファイルとして保存します。

3. ノードHKEY_LOCAL_MACHINE\SOFTWARE\ODBCに移動して、このノードを選択します。このノードを右クリックして、「エクスポート」を選択します。それらのエントリを、一意の名前を付けた.regファイルとして保存します。

4. ノードHKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Servicesに移動して、このノードを選択します。このノード内にあるOracleで始まる各ノードを、一意の名前を付けた.regファイルにエクスポートします。

5. ノードHKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Servicesに移動して、このノードを選択します。このノード内にあるOracleで始まる各ノードを、一意の名前を付けた.regファイルにエクスポートします。

6. ノードHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesに移動して、このノードを選択します。このノード内にあるOracleで始まる各ノードを、一意の名前を付けた.regファイルにエクスポートします。

7. 作成したすべての.regファイルをノード2にコピーします。

8. レジストリ・エディタを終了します。

ノード2でのOracle Business Intelligenceレジストリ・エントリのインポート

次の手順を実行して、ノード1でのOracle Business Intelligenceのレジストリ・エントリをノード2にインポートします。

1. ノード2で、Oracle_BI1\bifoundation\install\vc80\vcredist_x86.exeをダブルクリックします。

2. ノード1からコピーした各.regファイルをダブルクリックします。毎回、「はい」をクリックして、ファイルの内容をレジストリにインポートします。

すべてのインストールの場合:

ノード1のシステム環境変数Pathになんらかのインスタンス固有の情報が含まれている場合、これと同じ情報をノード2の同じ変数にも設定します。また、ノード1からレジストリHKEY_LOCAL_MACHINE\SOFTWARE\Oracleをエクスポートして、それをノード2にインポートします。

ノード1からノード2にスタート・メニューをコピーするため、ノード1のC:\Document and Settings\All Users\スタート・メニュー\プログラム\<メニュー>にあるファイルをノード2にコピーしますこの操作には、Windowsバックアップ・ツールやZipユーティリティを使用できます。たとえば、Windowsバックアップ・ユーティリティを使用する場合、次のように実行します。

1. 「アクセサリ」、「システム ツール」、「バックアップ」の順に選択して、Windowsバックアップ・ユーティリティを起動します。

2. C:\Document and Settings\All Users\スタート メニュー\プログラム\<メニュー>を選択します。

3. バックアップ・ファイルを2番目のノードにコピーします。

4. 同じ場所(C:\Document and Settings\All Users\スタート メニュー\プログラム\)でバックアップをリストアします。

ノード・マネージャについては、WebLogic Serverの標準手順に従って、ノード・マネージャをサービスとして構成します。

ノード・マネージャをサービスとして構成するには、WL_HOME\server\bin\installNodeMgrSvc.cmdコマンドを使用します。ノード・マネージャの構成の要件は次のとおりです。

- 両方のノードに設定する必要があります。

- 両方のノードで、手動で起動するようにノード・マネージャを設定する必要があります。

ノードにノード・マネージャを構成する手順は次のとおりです。

1. マシンでMiddlewareホームが使用できることを確認します。

2. 前述のコマンドを実行して、サービスをインストールします。

3. 次のコマンドを使用して、手動で起動するようにサービスを設定します。

sc config nodemanager_service_name start= demand

12.2.4 Oracle Fusion Middlewareコンポーネントの変換

この項では、Oracle製品スイートごとの考慮事項と変換手順について説明します。製品コンポーネントの詳細は、このガイドで適切なコンポーネントに関連する章を参照してください。

12.2.4.1 Oracle Internet Directoryおよびそのクライアントの変換

この項では、Oracle Internet Directoryとそのクライアントを変換する方法について説明します。

12.2.4.1.1 Transforming Oracle Internetの変換

Oracle Internet DirectoryサーバーをPS1から変換する手順は次のとおりです。

1. テキスト・エディタで、Oracle Internet Directoryサーバーに対して仮想IPのcfcvip.mycompany.comを設定するoidcfc.ldifというファイルを次のように作成します。

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclhostname
orclhostname: cfcvip.mycompany.com

2. 次のコマンドを実行します。

ORACLE_HOME/bin/ldapmodify -p <oidPort> -h <oidHost> -D cn=orcladmin –w
<adminPasswd> -f oidcfc.ldif

このコマンドの実行時に、OIDが稼働している必要があります。oidHostは、OIDのインストールに使用された物理ホスト名のリスニング・エンド・ポイントです。

3. opmnctlを使用して、Oracle Internet Directoryサーバーを停止してから再起動します。
例:

ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1

4. OIDを管理サーバーに再登録します。

ORACLE_INSTANCE/bin/opmnctl updatecomponentregistration -adminHost
myAdminHost -adminPort 7001 -adminUsername weblogic -componentType OID
-componentName oid1 -Host cfcvip.mycompany.com

Oracle Internet DirectoryをPS1からアップグレードするには、次を実行します。

ORACLE_HOME/opmn/bin/upgradenonj2eeapp.sh -oracleInstance ORACLE_INSTANCE

12.2.4.1.2 Transforming Oracle Internet Directoryクライアントの変換

Oracle Internet Directoryクライアントを変換する手順は次のとおりです。

1. Oracle Internet Directoryサーバーのすべてのクライアントは、仮想IPのcfcvip.mycompany.comを使用してそのOracle Internet Directoryサーバーにアクセスします。

2. Oracle Internet Directoryサーバーを使用するOracle Directory Integration Platformインストールでは、仮想IPを使用してOracle Internet Directoryサーバーにアクセスする必要があります。そのための手順は次のとおりです。

1. テキスト・エディタで、DOMAIN_HOME/config/fmwconfig/servers/wls_ods1/applications/DIP_<version_number>/configurationディレクトリにあるdip-config.xmlファイルを開きます。
例:

MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/
wls_ods1/applications/DIP_11.1.1.2.0/configuration

2. 次の値を入力し、LDAPアドレスを仮想IPに設定します。

OID_NODE_HOST>cfcvip.mycompany.com</OID_NODE_HOST>

3. Oracle Internet Directoryサーバーを管理するOracle Directory Services Managerインスタンス(第12.2.3.10.1項「Oracle HTTP Serverの変換」を参照)は、仮想IPを使用してOracle Internet Directoryサーバーに接続する必要があります。
たとえば、「Oracle Directory Services Manager」画面で、仮想サーバーを使用してOracle Internet Directoryに接続できることを次の手順で検証します。

1. 右上隅にある「ディレクトリに接続」→「新規接続の作成」リンクを選択します。

2. 「新規接続」画面で、次の接続情報を入力し、「接続」をクリックします。

- ディレクトリ・タイプ: OID

- 名前: OIDHA

- サーバー: cfcvip.mycompany.com

- ポート: 389

- SSL有効: 空白にしておきます。

- ユーザー名: cn=orcladmin

- パスワード: ********

- 開始ページ: Home(デフォルト)

12.2.4.2 Oracle Virtual Directoryおよびそのクライアントの変換

この項では、Oracle Virtual Directoryとそのクライアントを変換する方法について説明します。

12.2.4.2.1 Oracle Virtual Directoryの変換

Oracle Virtual Directoryサーバーを変換する手順は次のとおりです。

1. テキスト・エディタで、ORACLE_INSTANCE/config/OVD/componentnameディレクトリにあるlisteners.os_xmlファイルを開きます。

2. 次の値を入力し、LDAPアドレスを仮想IPに設定します。

<host>cfcvip.mycompany.com</host>

3. opmnctlを使用して、Oracle Virtual Directoryサーバーを再起動します。
例:

ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1

12.2.4.2.2 Oracle Virtual Directoryクライアントの変換

Oracle Virtual Directoryのすべてのクライアントは、仮想IPのcfcvip.mycompany.comを使用して、Oracle Virtual Directoryにアクセスする必要があります。たとえば、Oracle Directory Services Managerを使用してコールド・フェイルオーバー・クラスタのOracle Virtual Directoryインスタンスを管理する場合は、Oracle Virtual Directoryインスタンスの場所としてcfcvip.mycompany.comを使用して接続を作成します。

12.2.4.3 Oracle Directory Integration PlatformおよびOracle Directory Services Managerとそれぞれのクライアントの変換

この項では、Oracle Directory Integration Platform、Oracle Directory Services Managerおよびそれぞれのクライアントを変換する方法について説明します。

12.2.4.3.1 Oracle Directory Integration PlatformとOracle Directory Services Managerの変換

Oracle Directory Integration PlatformとOracle Directory Services Managerは管理対象サーバーにデプロイされます。CFC変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成します。第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_ODS管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。

12.2.4.3.2 Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントの変換

次の手順に従って、Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントを変換します。

1. Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントは、仮想IPのcfcvip.mycompany.comを使用してこれらのアプリケーションにアクセスする必要があります。

2. Oracle HTTP ServerがOracle Directory Services Managerのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_ODS管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、Oracle HTTP ServerおよびOracle Directory Services Managerで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

#Oracle Directory Services Manager
<Location /odsm>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

12.2.4.4 Oracle Identity Federationおよびそのクライアントの変換

この項では、Oracle Identity Federationとそのクライアントを変換する方法について説明します。

12.2.4.4.1 Oracle Identity Federationの変換

Oracle Identity Federationは、管理サーバーにデプロイされるコンポーネントです。コールド・フェイルオーバー・クラスタ変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成します。第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OIF管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Oracle Identity Federationコールド・フェイルオーバー・クラスタ・デプロイメントは通常、サービス・プロバイダとアイデンティティ・プロバイダに分割されるため、特定のデプロイメントに複数のWLS_OIFインスタンスが存在する場合があります。どちらのWLS_OIFインスタンスに対しても、同じコールド・フェイルオーバー・クラスタ手順を適用してください。

cfcvip.mycompany.comの仮想IP上でリスニングするように管理対象サーバーを構成した後、Oracle Enterprise Manager Fusion Middleware Controlにログインして、次の手順を実行します。

1. 「ファーム」→「Identity and Access」→OIFに移動します。

2. 右側のフレームで、「Oracle Identity Federation」→「管理」に移動し、次の変更を行います。

1. サーバー・プロパティ: ホストをcfcvip.mycompany.comに変更します。

2. 「アイデンティティ・プロバイダ」→「共通」: providerIdをcfcvip.mycompany.comに変更します。

3. 「サービス・プロバイダ」→「共通」: providerIdをcfcvip.mycompany.comに変更します。

4. データ・ストア: データ・ストアがLDAPの場合は、ユーザー・データ・ストアとフェデレーション・データ・ストアの接続URLの値をcfcvip.mycompany.comに置き換えます。

5. 「認証エンジン」→「LDAPディレクトリ」: ConnectionURLをcfcvip.mycompany.comに設定します。

前述の変更を行った後にメタデータを生成する必要があります。

12.2.4.4.2 Oracle Identity Federationクライアントの変換

次の手順に従って、Oracle Identity Federationクライアントを変換します。

1. Oracle Identity Federationクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。

2. Oracle HTTP ServerがOracle Identity Federationのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_OIF管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、Oracle HTTP ServerおよびOracle Directory Services Managerで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

#Oracle Identity Federation
<Location /oif>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

12.2.4.5 Oracle SOA Suiteの変換

Oracle SOA Suiteは、管理対象サーバーにデプロイされるJava EEコンポーネントで構成されます。一般的な構成では、OWSM-PMアプリケーションとSOAアプリケーションのデプロイメントがあります。SOAアプリケーションは必ず、個別の管理対象サーバーにデプロイされます。多くのコールド・フェイルオーバー・クラスタ・デプロイメントでは、OWSM-PMは管理サーバーにデプロイされますが、管理対象サーバー自体(WLS_OWSMなど)やSOA管理対象サーバーにもデプロイできます。WLS_SOAコンテナには、デプロイされたBPEL、UMS、B2Bなどのアプリケーションが含まれ、さらにデプロイされたBPMコンポーネントが含まれる場合もあります。これらはJava EEコンポーネントであるため、すべての場合で、コールド・フェイルオーバー・クラスタ変換手順には、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーのWLS_OWSMおよびWLS_SOAを変換する方法の詳細は、第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」を参照してください。

また、次の手順に従って、SOAコンポーネントの管理対象サーバーを変換します。

1. WLS_SOA管理対象サーバーのフロントエンド・ホストをcfcvip.mycompany.comに設定します。

1. 管理コンソールにログインします。

2. 「環境」セクションで「サーバー」を選択します。

3. 管理対象サーバー名を選択します。

4. 「プロトコル」を選択してから、「HTTP」を選択します。

5. 「フロントエンド・ホスト」フィールドで、ホスト名をcfcvip.mycompany.comとして入力します。

6. フロントエンド・ポートをHTTPポートに設定します。

7. 「保存」をクリックします。

8. 変更をアクティブ化します。

9. 管理対象サーバーを再起動します。

2. Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_OWSMとWLS_SOAにデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。そのためには、SOAコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

#SOA soa-infra app
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

# Worklist
<Location /integration/>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

# B2B
<Location /b2b>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

# UMS
<Location /sdpmessaging/ >
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com WebLogicPort port
</Location>

# UMS WS
<Location /ucs/messaging/webservice >
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

# WSM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

# workflow
<Location /workflow>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

#Required if attachments are added for workflow tasks
<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

# Required if SOA is being used for Oracle Image and Process Management
# SOA inspection.wsil
<Location /inspection.wsil>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

12.2.4.6 Oracle Access Managerおよびそのクライアントの変換

この項では、Oracle Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定すること、および管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.mycompany.com)に指定することによって設定可能です。この場合、明確な変換手順は不要です。

12.2.4.6.1 Oracle Access Managerの変換

Oracle Access Managerは管理対象サーバー(WLS_OAM1など)にデプロイされ、CFC変換を行うためには、この管理対象サーバーを、仮想IPのcfcvip.mycompany.comでリスニングするように構成します。第12.2.3.6,項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OAM1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

Oracle Access Managerコンソールは、ドメインの管理サーバーの一部としてデプロイされます。このコンソールのコールド・フェイルオーバー・クラスタ構成では、管理サーバー全体をアクティブ/パッシブで構成する必要があります。管理サーバーは、同じ仮想IPのcfcvip.mycompany.comを共有することも、個別の仮想IPと共有ディスクを使用して独立してフェイルオーバーするように構成することもできます。同じ仮想IPを使用している場合、管理サーバーとOracle Access Manager管理対象サーバーは1つのユニットとしてフェイルオーバーします。

12.2.4.6.2 Oracle Access Managerクライアントの変換

次の手順に従って、Oracle Access Managerクライアントを変換します。

1. Oracle Access Managerクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Identity ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.mycompany.comを使用してアプリケーションにアクセスする必要があります。

2. Oracle HTTP ServerがOracle Access Managerのフロントエンドである場合、Oracle Access Managerに関するmod_weblogic構成では、Oracle Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

#Oracle Access Manager
<Location /oam>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:port
</Location>

3. Oracle管理サーバーの一部としてOracle Access Managerコンソールもアクティブ/パッシブに構成し、Oracle HTTP Serverがその管理サーバーのフロントエンドに配置されるように構成する場合、Webサーバー・プロキシ・プラグイン構成ファイルのWebLogicホスト構成を変更する必要があります。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

#Oracle Access Manager Admin Console deployed to the Admin Server
<Location /oamconsole>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WebLogicPort 7001
</Location>

12.2.4.7 Oracle Adaptive Access Managerおよびそのクライアントの変換

この項では、Oracle Adaptive Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.mycompany.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。

12.2.4.7.1 Oracle Adaptive Access Managerの変換

Oracle Adaptive Access Managerは管理対象サーバーにデプロイされます。両方とも単一のユニットとしてフェイルオーバーするようにデプロイされ、そのために同じ仮想IPと同じ共有記憶域を共有します。OAAM Admin管理対象サーバーおよびOAAM Server管理対象サーバーをCFC変換のために変換するには、これらの管理対象サーバーを、仮想IPのcfcvip.mycompany.comでリスニングするように構成します。第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

12.2.4.7.2 Oracle Adaptive Access Managerクライアントの変換

次の手順に従って、Oracle Adaptive Access Managerクライアントを変換します。

1. Oracle Adaptive Access Managerクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Identity Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.mycompany.comを使用してアプリケーションにアクセスする必要があります。

2. Oracle HTTP ServerがOracle Adaptive Access Managerのフロントエンドである場合、Oracle Adaptive Access Managerに関するmod_weblogic構成では、Oracle Adaptive Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

#Oracle Adaptive Access Manager
<Location /oaam_server>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com WebLogicPort port
</Location>

#Oracle Adaptive Access Manager Admin Console
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:port
</Location>

12.2.4.8 Oracle Identity Managerおよびそのクライアントの変換

この項では、Oracle Identity Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.mycompany.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。

12.2.4.8.1 Oracle Identity Managerの変換

Oracle Identity Managerは、管理対象サーバーにデプロイされます。一般的なCFCデプロイメントでは、Oracle Identity Manager管理対象サーバーと、Oracle SOAおよびOracle Web Services Managerを含む別の管理対象サーバーは1つのユニットとしてフェイルオーバーするようにデプロイされ、そのために同じ仮想IPと同じ共有記憶域を共有します。この両方の管理対象サーバーをCFC変換のために変換するには、これらの管理対象サーバーを、仮想IPのcfcvip.mycompany.comでリスニングするように構成します。第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

12.2.4.8.2 Oracle Identity Managerクライアントの変換

次の手順に従って、Oracle Identity Managerクライアントを変換します。

1. Oracle Identity Managerクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.mycompany.comを使用してアプリケーションにアクセスする必要があります。SOAもOracle Identity Managerでフェイルオーバーするように構成されているので、Oracle Identity ManagerからSOAへの接続でも共通の仮想IPを使用する必要があります。

2. Oracle HTTP ServerがOracle Identity Managerのフロントエンドである場合、Oracle Identity Managerに関するmod_weblogic構成では、管理対象サーバーのアドレスとして仮想IPのcfcvip.mycompany.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルまたはoim.confファイルを次のように編集します。

#Oracle Identity Manager
<Location /oim>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:port
WebLogicPort port
</Location>

Oracle Identity Managerでの構成変更の詳細は、Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドを参照してください。

12.2.4.9 Oracle WebCenterポータルSuiteの変換

WebCenter SuiteはJava EEコンポーネントで構成されています。一般的なWebCenter Suiteデプロイメントには4つの管理対象サーバーが含まれますが、WebCenterポータル・アプリケーションを開発すると、それより多くの追加の管理対象サーバーを含めることができます。一般的な管理対象サーバー・デプロイメントは次のとおりです。

- WC_SPACES

- WC_PORTLETS

- WC_COLLABORATION

- WC_UTILITIES

これらはJava EEコンポーネントであるため、コールド・フェイルオーバー・クラスタ変換手順では、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成します。Oracle WebCenterポータルのコールド・フェイルオーバー・クラスタ・デプロイメントでは、多くの場合、OWSM-PMをWC_PORTLETSおよびWC_SPACESコンテナにデプロイすることになります。Oracle WebCenterポータルSuite管理対象サーバーを変換する方法の詳細は、第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」を参照してください。

Oracle HTTP Serverをフロントエンドとして使用している場合は、WebCenter Suiteアプリケーションに関するmod_weblogic構成で、管理対象サーバーのアドレスのかわりとしてVIPのcfcvip.mycompany.comを指定します。これを行うには、WebCenterコンポーネントが使用するマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。

管理対象サーバーのアドレスとして仮想ホストを使用する手順は、次のとおりです。

1. 管理対象サーバーを実行するマシンで、仮想ホストcfcvip.mycompany.comが有効になっていることを確認します。

2. 管理対象サーバーのリスニング・アドレスがcfcvip.mycompany.comに設定されていることを確認します。

3. mod_wl_ohs.confファイルの、アドレスcfcvip.mycompany.comを使用します。

12.2.4.10 Oracle Portal、Forms、ReportsおよびDiscovererの変換

コールド・フェイルオーバー・クラスタ構成は、それぞれのOracle Portal、Forms、ReportsおよびDiscovererコンポーネントごとに異なります。この項では、Oracle Portal、Forms、ReportsおよびDiscovererのコールド・フェイルオーバー・クラスタ変換手順について説明します。

12.2.4.10.1 コールド・フェイルオーバー・クラスタ用のOracle Formsの変換

Oracle FormsはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Formsをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。

注意:

この変換プロセスでは、これらのファイルの編集前にドメインを停止する必要があります。

1. WLS_FORMS管理対象サーバーを変換します。この手順の詳細は、第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。

2. Oracle Forms OPMNを変換します。この手順の詳細は、第12.2.3.8項「Oracle Process Management and Notification Serverの変換」を参照してください。

3. Enterprise Managerを変換します。この手順の詳細は、第12.2.3.9項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。

4. Oracle Forms Web層コンポーネントを変換します。この手順の詳細は、第12.2.3.10項「Web層のコンポーネントとクライアントの変換」を参照してください。

5. 第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従って、シングル・サインオンを再登録します。

6. INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるforms.confファイルで、mod_weblogic構成を変更します。
WebLogicドメイン内の管理サーバーと管理対象サーバーだけでなくOracleインスタンスも起動して、コールド・フェイルオーバー・クラスタ・インストールを検証します。

<Location /Forms>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
DynamicServerList OFF
</Location>

12.2.4.10.2 コールド・フェイルオーバー・クラスタ用のOracle Reportsの変換

Oracle ReportsはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Reportsをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。

1. WLS_REPORTS管理対象サーバーを変換します。この手順の詳細は、第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。

2. Oracle Reports OPMNを変換します。この手順の詳細は、第12.2.3.8項「Oracle Process Management and Notification Serverの変換」を参照してください。
また、次の操作を行います。

1. INSTANCE_HOME/config/OPMN/opmnディレクトリにあるopmn.xmlファイルで、ias-componentのReports Server名を新しい名前に変更して、新しい名前を反映させます。
例:

<ias-component id="ReportsServer_virtual_hostname_instance_name">
<process-set id="ReportsServer_virtual_hostname_instance_name"
restart-on-death="true" numprocs="1">
</ias-component>

例:

<ias-component id="ReportsServer_cfcvip_asinst1">
<process-set id="ReportsServer_ cfcvip asinst1"restart-on-death="true"
numprocs="1">
</ias-component>

2. 管理サーバー・ドメイン・ホームのDOMAIN_HOME/opmn/topology.xmlで、このファイル内で、Reports Server名のすべての記述をReportsServer_physical hostname_instance_name (例: ReportsServer_node1_asinst)からReportsServer_virtual_hostname_instance_name (例: ReportsServer_cfcvip_asinst)に変更します。

3. Oracle Enterprise Managerを変換します。この手順の詳細は、第12.2.3.9項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。

4. Oracle Reports Web層コンポーネントを変換します。この手順の詳細は、第12.2.3.10項「Web層のコンポーネントとクライアントの変換」を参照してください。

5. シングル・サインオンを再登録します。そのためには、第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従ってください。

6. INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるreports_ohs.confファイルで、次を変更します。

<Location /reports>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

7. INSTANCE_HOME/config/ReportsServerComponentディレクトリで、次のディレクトリ名を探して、その名前を変更します。

ReportsServer_physical_hostname_instance_name (for example: ReportsServer_node1_asinst)

前述の名前を次のように変更します。

ReportsServer_VIP_instance_name (for example: ReportsServer_cfcvip_asinst)

注意:

インスタンスの再起動後、レポート・サーバーの新しいログはすべて、ReportsServer_virtual_hostname_instance_nameに送信されます。

8. 名前を変更したディレクトリで、次のファイルに記載された物理ホスト名を仮想ホスト名に置き換えます。

- component-logs.xml

- logging.xml

9. INSTANCE_HOME/EMAGENT/emagent_dir/sysman/emdディレクトリにあるtargets.xmlファイルで、次の変更を行います。

1. すべてのホスト名をnode1.mycompany.comからcfcvip.mycompany.comに変更します。

2. 次の2つの要素に関して、Reports Server名をReportsServer_physical_hostname_instance_name (例: ReportsServer_node1_asinst)からReportsServer_virtual_hostname_instance_name (例: ReportsServer_cfcvip_asinst)に変更します。
Target TYPE="oracle_repserv"

Target TYPE="oracle_repapp"

10. INSTANCE_HOME/reportsディレクトリにあるreports_install.propertiesで、物理ホスト名を仮想ホスト名に置き換えます。

11. INSTANCE_HOME/reports/serverディレクトリにある次のファイルの名前を変更します。

- reportsserver_physical_hostname_instance name.datをreportsserver_virtual_ hostname_instance namedatに変更

- rep_wls_reports_physical_ hostname_instance name.datをrep_wls_reports_virtual_hostname_instance_name.datに変更

12. DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_<version_number>/1ww3jm/configurationディレクトリ(たとえばDOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_11.1.1.3.0/1ww3jm/configurationディレクトリ)にあるrwservlet.propertiesファイルで、物理ホスト名を仮想ホスト名に置き換えます(Reports Server名のすべての記述に関する変更を含む)。

13. DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_<version_number>/1ww3jm/META-INFディレクトリ(たとえばDOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_11.1.1.3.0/1ww3jm/META-INFディレクトリ)にあるmbeans.xmlファイルで、物理ホスト名を仮想ホスト名に置き換えます(Reports Server名のすべての記述に関する変更を含む)。

14. WebLogicドメイン内の管理サーバーと管理対象サーバーだけでなくOracleインスタンスも起動して、コールド・フェイルオーバー・クラスタ・インストールを検証します。

12.2.4.10.3 コールド・フェイルオーバー・クラスタ用のOracle Discovererの変換

Oracle DiscovererはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Discovererをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。

1. WLS_DISCO管理対象サーバーを変換します。この手順の詳細は、第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。

2. Oracle Discoverer OPMNを変換します。この手順の詳細は、第12.2.3.8項「Oracle Process Management and Notification Serverの変換」を参照してください。

3. Oracle Enterprise Managerを変換します。この手順の詳細は、第12.2.3.9項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。

4. Oracle Discoverer Web層コンポーネントを変換します。この手順の詳細は、第12.2.3.10項「Web層のコンポーネントとクライアントの変換」を参照してください。

5. シングル・サインオンを再登録します。そのためには、第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従ってください。

6. INSTANCE_HOME/config/OHS/ohs1/moduleconfディレクトリにあるreports_ohs.confファイルで、次を変更します。

<IfModule mod_weblogic.c><Location /discoverer>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
DynamicServerList ON
</Location>
</IfModule>

12.2.4.10.4 コールド・フェイルオーバー・クラスタ用のOracle Portalの変換

Oracle PortalはJava EEコンポーネントとシステム・コンポーネントの両方で構成されます。Oracle Portalをコールド・フェイルオーバー・クラスタ用に構成する手順は次のとおりです。

1. WLS_PORTAL管理対象サーバーを変換します。この手順の詳細は、第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」を参照してください。管理対象サーバーを変換する際、ドメイン管理サーバーを起動します。管理対象サーバーの変換が終了したら、管理サーバーを停止します。

2. Oracle Portal OPMNを変換します。この手順の詳細は、第12.2.3.8項「Oracle Process Management and Notification Serverの変換」を参照してください。

3. Oracle Enterprise Managerを変換します。この手順の詳細は、第12.2.3.9項「OracleインスタンスのOracle Enterprise Managerの変換」を参照してください。

4. Oracle Portal Web層コンポーネントを変換します。この手順の詳細は、第12.2.3.10項「Web層のコンポーネントとクライアントの変換」を参照してください。

5. シングル・サインオンを再登録します。そのためには、第14.6.4.9.4項「シングル・サインオンの有効化」で説明している手順に従ってください。

6. INSTANCE_HOME/config/config/OHS/ohs1/moduleconfにあるportal.confファイルで、mod weblogic構成を変更して、mod weblogic構成を変更します。

# WLS routing configuration
<Location /portal>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

<Location /portalTools>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

<Location /wsrp-tools>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

<Location /richtextportlet>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

<Location /jpdk>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

<Location /portalHelp>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

<Location /portalHelp2>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

7. Portalレジストリをリワイヤします。

1. 次のURLを使用して、WebLogic Server Enterprise Managerにログインします。
http://cfcvip.mycompany.com:7001/em

2. InValidationおよび管理者パスワードを変更します。
「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

wc1コンポーネントをクリックします。

ページの最上部にあるドロップダウン・リストから「管理 - パスワード」を選択します。

新しい無効化パスワードの入力と確認を行ってから、「適用」をクリックします。

新しい管理者パスワードの入力と確認を行ってから、「適用」をクリックします。

3. 左側のペインで、「Fusion Middleware」メニューを開きます。

4. 「Classic」を選択します。

5. 「Portal」をクリックします。
ポータル・ドメイン情報ページが表示されます。

6. 「Portal」を右クリックして、「設定」、「ワイヤ構成」の順に選択します。

7. 「ポータル中間層」に関して次の情報を入力します。
ホスト: Webキャッシュ・ホストのcfcvip.mycompany.comのコールド・フェイルオーバー・クラスタ仮想IP名を入力します。

ポート: 使用するWebキャッシュ・ポート(HTTPまたは非HTTP)を入力します。

SSLプロトコル: 該当する場合は、この値を入力します。

8. 「Webキャッシュ」に関して次の情報を入力します。
ホスト: Webキャッシュ・ホストのcfcvip.mycompany.comとmysite.mycompany.comのコールド・フェイルオーバー・クラスタ仮想IP名を入力します。

無効化ポート: 9401などの無効化ポートを入力します。

無効化ユーザー名: Portal無効化のユーザー名を入力します。

無効化パスワード: このアカウントのパスワードを入力します。

9. 「適用」をクリックし、リワイヤを開始します。

10. リワイヤが完了したら、「Portal」メニュー・オプションを再びクリックして、URLが次のようになっていることを確認します。
https://cfcvip.mycompany.com:WCHTTPPort/portal/pls/portal

8. Oracle WebLogic Serverにおけるホスト・アサーションを変更します。
Oracle HTTP ServerはWebLogicのプロキシとして機能するため、デフォルトでは、ホストやポートなどの特定のCGI変数はWebLogicに渡されません。仮想サイト名とポートを使用していることをWebLogicに認識させ、内部URLが適切に生成できるようにする手順は次のとおりです。

1. 次のURLを使用して、管理コンソールにログインします。
http://cfcvip.mycompany.com:7001/console

2. ホーム・ページから「WLS_PORTAL」を選択するか、「ドメイン構造」メニューから「環境」、「クラスタ」の順に選択します。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 「プロトコル」をクリックしてから、「HTTP」を選択します。

5. 次の値を入力します。
「フロントエンド・ホスト」: cfcvip.mycompany.com

フロントエンドHTTPポート: WCHTTPPort(8090)

フロントエンドHTTPSポート: WCHTTPSPort(8094)

これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート443に送られます。

6. 「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックして、編集可能にします。

7. WLS_PORTAL管理対象サーバーを再起動します。

12.2.4.10.5 Oracle Business Activity Management(BAM)の変換

Oracle BAMは、管理対象サーバーにデプロイされるJava EEコンポーネントで構成されます。これらはJava EEコンポーネントであることから、コールド・フェイルオーバー・クラスタ変換手順には、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーのWLS_BAMを変換する方法の詳細は、第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」を参照してください。

Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_BAMにデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。そのためには、SOAコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

# BAM Web Application
<Location /OracleBAM >
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

12.2.4.10.6 カスタムADFデプロイメントの変換

カスタムADFアプリケーションを使用するデプロイメントでも、あらゆるFusion Middlewareデプロイメントと同じように、コールド・フェイルオーバー・クラスタを使用します。この場合、Oracle Application DeveloperのDVDからのインストールを使用して、ドメインを作成します。これは主にJava EEコンポーネントであるため、コールド・フェイルオーバー・クラスタ変換手順は、デプロイ先の管理対象サーバーを仮想IP上でリスニングするように構成する作業が含まれます。管理対象サーバーを変換する方法の詳細は、第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」を参照してください。

Oracle HTTP Serverをフロントエンドとして使用している場合は、WLS_ADF(カスタマ・アプリケーションの管理対象サーバーの名前)にデプロイされたアプリケーションに関するmod_weblogic構成で、これらの管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを指定します。そのためには、SOAコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

# BAM Web Application
<Location /ADFApplicationMountPoint >
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

12.2.4.11 Oracle WebCenter Contentの変換

Oracle WebCenter Contentには、Oracle WebCenter Content: Imaging(Imaging)、Oracle WebCenter Content(WebCenter Content)、Oracle WebCenter Content: Records、Oracle WebCenter Content: Inbound Refineryなどの製品が含まれます。

Oracle WebCenter Contentをインストールする場合には、通常、次の管理対象サーバーが含まれます。

- Imaging (WLS_IPM)

- WebCenter Content (WLS_UCM)

- Records (WLS_URM)

- Inbound Refinery (WLS_IBR)

コールド・フェイルオーバー・デプロイメントでは、この章の前の項でCFCデプロイメントに推奨されているアプリケーション層およびWeb層の設定を行い、これらの管理対象サーバーに対してコールド・フェイルオーバー・クラスタ変換の手順を実行することをお薦めします。Imaging、UCM(またはURM)、およびIBR管理対象サーバーを変換する方法の詳細は、第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」を参照してください。

Oracle WebCenter Contentのコールド・フェイルオーバー・クラスタ・デプロイメントについては、さらに次も考慮してください。

- Oracle WebCenter Contentの多くのコールド・フェイルオーバー・クラスタ・デプロイメントでは、次のようなデプロイメント・トポロジになります。

- I/PMとUCMの両方ともハードウェア・クラスタの同じノードにデプロイされます。

- ハードウェア・クラスタの一方のノードにI/PM、もう一方のノードにUCMというデプロイメントで、相互的なフェイルオーバーに構成されます。

- I/PMサーバーがフェイルオーバーするときにアクセスする必要があるすべてのI/PM関連のファイルも、共有ディスクに配置する必要があります。これには、入力ファイルやイメージなどが含まれます。CFC構成のすべてのノードからアクセスできるように、これらは必ず共有ディスクに配置してください。入力ファイルとイメージ・ファイルは個別のボリュームを用意することをお薦めします。

- JMSやTLogsなどで使用される永続ストアも、すべて共有ディスクに配置する必要があります。

- Inbound Refineryに関連するすべての制限は、CFC構成において引き続き適用されます。Inbound Refineryインスタンスの構成の詳細は、Oracle Fusion Middleware変換についての管理者ガイドを参照してください。

- UCMのコンテンツに関するすべてのフォルダも同様に共有ディスクに配置する必要があります。これは、UCMサーバー構成とともに1つのユニットとしてフェイルオーバーされます。これには、次のようなフォルダが含まれます。

- コンテンツ・サーバー・インスタンス・フォルダ

- ネイティブ・ファイル・リポジトリの場所

- Webレイアウト・フォルダ

- http://cfcvip.mycompany.com:port/csを使用してUCMまたはURMを構成する場合、「WebサーバーのHTTPアドレス」がWCC管理対象サーバーのフロントエンドとなるHTTPサーバーのホスト名および場所になります。HTTPサーバーの高可用性構成に応じて、これはロード・バランサのアドレス、物理ホスト、または仮想ホストになります。Oracle HTTP ServerもCFCデプロイメントに含まれる場合、上の値はOracle HTTP Serverの仮想IPに設定する必要があります。Oracle HTTP ServerがWCCサーバーと同じハードウェア・クラスタに存在する場合、これはcfcvip.mycompany.comのようになります。

- UCMがコールド・フェイルオーバー・クラスタで構成され(上の例に含まれます)、I/PMがUCMに接続されている場合、UCMの仮想IPアドレスを使用することをお薦めします。http://cfcvip.mycompany.com:port/imagingを使用してこの構成を行う場合、次の手順を実行します。

1. 左側のペインで、「接続の管理」→「Content Server接続の作成」をクリックします。

2. 新しい接続の名前と説明を入力し、「次へ」をクリックします。

3. 「接続設定」画面で、次を入力します。

- コンテンツ・サーバー・バージョン: CS 11g

- プライマリ: cfcvip.mycompany.com:4444

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

4. 接続セキュリティ画面で、WebLogicユーザーに対するデフォルトの選択をそのまま受け入れ、「次へ」をクリックします。

5. 接続の詳細を確認し、「送信」をクリックします。

- また、Oracle HTTP ServerをOracle WebCenter Contentアプリケーションのフロントエンドとして使用している場合、mod_weblogic構成で、管理対象サーバーのアドレスとしてVIPのcfcvip.mycompany.comを使用する必要があります。そのためには、WCCコンポーネントで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

# Content Server
<Location /cs>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
WLCookieName IDCCS_SESSIONID
</Location>

# URM
<Location /urm>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
WLCookieName IDCURM_SESSIONID
</Location>

# IBR
<Location /ibr>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
WLCookieName IDCIBR_SESSIONID
</Location>

# IPM
<Location /imaging>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogic port
</Location>

12.2.4.12 Oracle Business Intelligenceの変換

Oracle Business Intelligenceは、ビジネス・ユーザーに組織の全体像を提供する統合ビジネス・インテリジェンス(BI)ソリューションです。Oracle Business Intelligenceは、迅速かつ簡単に様々なデータ・ソースを統合し、データベースの情報を検索し、データベース情報を共有して、企業およびその顧客に関する情報を得るためにデータを有効に利用することを目的として設計されています。

この項では、Oracle Business Intelligence Enterprise Edition、Oracle Business Intelligence PublisherおよびOracle Real-Time Decisionsに対するアクティブ/パッシブによる高可用性構成について説明します。

Oracle Business Intelligenceの変換に関する要件

Oracle BIを変換する前に、OPMNを変換するために行ったOPMNの変更が有効であることを確認する必要があります。(第12.2.3.8項「Oracle Process Management and Notification Serverの変換」では、OPMN変換の手順について説明しています。)

OPMNの変更を有効にするには、次の手順を行います。

1. 管理サーバーを再起動します。

2. OPMNを再起動します。OPMNの再起動の詳細は、Oracle Fusion Middleware Oracle Process Manager and Notification Serverに関する管理者ガイドのOPMNの使用に関する説明を参照してください。

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

- 第12.2.4.12.1項「Oracle Business Intelligence Enterprise Editionおよびそのクライアントの変換」

- 第12.2.4.12.2項「Oracle Business Intelligence Publisherおよびそのクライアントの変換

- 第12.2.4.12.3項「Oracle Real-Time Decisionsおよびそのクライアントの変換

12.2.4.12.1 Oracle Business Intelligence Enterprise Editionおよびそのクライアントの変換

この項では、Oracle Business Intelligence Enterprise Edition(Oracle BI EE)をコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

管理対象サーバーの変換

Oracle BI Enterprise Editionは管理対象サーバー(BI_SERVER1など)にデプロイされ、コールド・フェイルオーバー・クラスタ変換の手順はこの管理対象サーバーをインストール後に仮想IPのcfcvip.mycompany.comでリスニングするように構成することになります。第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、BI_SERVER1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。この手順の後で、管理コンソールまたはWLSTコマンドラインを使用して、管理対象サーバーを再起動します。

Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関するすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。Oracle BI Enterprise Editionのコールド・フェイルオーバー・クラスタ・デプロイメントに固有の要件は、次のアーティファクトも共有ディスクに確実に存在し、フェイルオーバー・クラスタの両方のノードの同じマウント・ポイントで確実にアクセスできるということです。デフォルトのインストールで構成する場合、暗黙的にこのようになります。

- BIEEプレゼンテーション・カタログ

- BIEEリポジトリの公開ディレクトリ(RPD)

Oracle BI EEコンポーネントの管理対象サーバーを変換する手順は、次のとおりです。

1. biee-domain.xmlファイルを編集して、ホスト名をcfcvip.mycompany.comに置換します。このbiee-domain.xmlファイルは、次のディレクトリにあります。

MW_HOME/user_projects/domains/bifoundation_domain/config/fmwconfig

2. BI_SERVER管理対象サーバーのフロントエンド・ホストをcfcvip.mycompany.comに設定します。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「環境」セクションで「サーバー」を選択します。

4. 管理対象サーバー名を選択します。

5. 「プロトコル」を選択してから、「HTTP」を選択します。

6. 「フロントエンド・ホスト」フィールドで、ホスト名をcfcvip.mycompany.comとして入力します。

7. フロントエンド・ポートをHTTPポートに設定します。

8. 「保存」をクリックします。

9. 変更をアクティブ化します。

10. 管理対象サーバーを再起動します。

システム・コンポーネントの変換

システム・コンポーネントを変換する手順は、次のとおりです。

1. ドメインのOracle Fusion Middlewareコンソールにログインします。

2. 「Business Intelligence」→コア・アプリケーション→「容量管理」→「スケーラビリティ」に移動します。

3. Oracleインスタンス(instance1)については、「リスニング・アドレス」をcfcvip.mycompany.comに変更します。

4. 「構成をロックして編集」をクリックして、「リスニング・アドレス」をcfcvip.mycompany.comに変更します。

5. 「適用」をクリックします。

6. 「変更のアクティブ化」をクリックします。

7. 管理対象サーバーとシステム・コンポーネントの両方を再起動します(opmnctlを使用します)。

Oracle BI Enterprise Editionのクライアントの変換

注意:

管理対象サーバーをCFCに変換する前に、BI Enterprise Editionのインスタンスを参照するデータ・ソースを変更します。手順4を参照してください。

Oracle BI Enterprise Editionのクライアントを変換する手順は次のとおりです。

1. Oracle BI Enterprise Editionのクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。

2. WSM-PMは同じ管理対象サーバーにデプロイされるため、WSM-PMで必要なクライアント側の構成変更も完了していることを確認してください。

3. BI Enterprise Edition製品スイートに含まれるその他のコンポーネントで、Oracle BI Publisherのように仮想ホスト名を使用するサービスを利用するためにOracle BI Enterprise Editionのサービスを使用するコンポーネントを構成します。

4. BI Publisherでは、BI Enterprise Editionのインスタンスを参照するデータ・ソースを変更するか、作成する必要があります(新規作成する場合は新しい仮想ホストを使用)。変更する手順は次のとおりです。

1. BI Publisherの管理コンソールに移動します。

2. 「データソース」の下にある「JDBC接続」をクリックします。

3. このインスタンスのBI Enterprise Editionのデータ・ソースをすべて編集して、cfcvip.mycompany.comに接続するようにします。

5. BI PublisherがBIEEデプロイメントに統合されている場合は、新しい仮想アドレスでBI PublisherがPresentation Servicesを検出するように構成します。この手順の詳細は、この章のBI Publisherの項を確認してください。

6. Oracle HTTP ServerがOracle BI Enterprise Editionのフロントエンドである場合、仮想IPのcfcvip.mycompany.comをOracle BI Server管理対象サーバーのアドレスとして指定するように、mod_wl_ohsファイルをテキスト・エディタで更新します。次の例を参照してください。

# BIEE Analytics
<Location /analytics>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:<port>
</Location>

<Location /analytics-ws>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:<port>
</Location>

<Location /bimiddleware>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:<port>
</Location>

Windowsに関する特別な考慮事項

Windowsプラットフォームでコールド・フェイルオーバー・クラスタ・デプロイメントを実現する手順は、次のとおりです。

1. ドライブ(たとえば、E:\)で共有ディスクを使用できるようにします。

2. BI EEスイートをE:\上のWindowsクラスタのノード1にインストールします(ソフトウェアのみのインストール)。

3. Middlewareホームを削除することで、E:\からソフトウェアのみのインストールを削除します。

4. 同じ共有ディスクをノード2にフェイルオーバーして、その共有ディスクをノード2で同じドライブ(E:\)として使用できるようにします。

5. BI EEスイートをE:\上のWindowsクラスタのノード2にインストールします(ソフトウェアのみのインストール)。

6. OUI構成ウィザードを起動して、E:\上にWLSドメインとOracleインスタンスを作成します。

7. ノード1:

1. regeditを実行します。

2. ノードHKEY_LOCAL_MACHINE\SOFTWARE\ORACLEを検索します。

3. このノードを右クリックして「エクスポート」をクリックし、ファイル名を入力します。

4. ノードHKEY_LOCAL_MACHINE\SOFTWARE\ODBCを検索します。

5. このノードを右クリックして、「エクスポート」をクリックします。ファイル名を入力します。

6. ノードHKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Servicesを検索します。このノード内のOracleで始まる各ノードを.regファイルにエクスポートします。

7. ノードHKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Servicesを検索します。このノード内のOracleで始まる各ノードを.regファイルにエクスポートします。

8. ノードHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesを検索します。このノード内にあるOracleで始まる各ノードを、.regファイルにエクスポートします。

9. エクスポートしたすべての.regファイルをノード2にコピーします。

ノード2:

1. Oracle_BI1\bifoundation\install\vc80\vcredist_x86.exeをダブルクリックします。

2. ノード1からコピーした各.regファイルをダブルクリックします。ファイルごとに、「はい」をクリックして、ファイルの内容をレジストリにインポートします。

8. 現在のノード(ノード2)で仮想IPを有効にして、このBIスイート・インストールの変換手順(第12.2.4.12.1項「Oracle Business Intelligence Enterprise Editionおよびそのクライアントの変換」)を実行します。

12.2.4.12.2 Oracle Business Intelligence Publisherおよびそのクライアントの変換

この項では、Oracle Business Intelligence Publisher(Oracle BI Publisher)をコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

Oracle Business Intelligence Publisherの変換

注意:

管理対象サーバーをCFCに変換する前に、BIプレゼンテーション・サーバーへのBIP接続を手動で編集する必要があります。MW_HOME/user_projects/domains/bifoundation_domain/config/bipublisher/repository/Admin/Configuration/xmlp-server-config.xmlのプロパティSAW_SERVERでホスト名を変更します。

Oracle BI Publisherをコールド・フェイルオーバー・クラスタ環境で機能するよう変換する手順は、次のとおりです。

1. http://hostname:port/xmlpserverでBI Publisherアプリケーションを開いてログインします。

2. BIスケジューラのJMS構成を変更します。

1. 「管理」をクリックします。

2. 「システム・メンテナンス」で「スケジューラ構成」をクリックします。

3. WeblogicのJNDI URLをt3://cfcvip.mycompany.com:9704に変更します。

4. 「適用」をクリックします。

管理対象サーバーの変換

Oracle BI Publisherが管理対象サーバー(BI_SERVER1など)にデプロイされたら、コールド・フェイルオーバー・クラスタ変換を行う手順として、この管理対象サーバーをインストール後に仮想IPのcfcvip.mycompany.comでリスニングするように構成します。第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」を参照して、BI_SERVER1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。

次に、管理コンソールまたはWLSTコマンドラインを使用して、管理対象サーバーを再起動します。

Middlewareホームの配置に関するすべての要件およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトが、第12.2.1項「コールド・フェイルオーバー・クラスタの要件」に説明されているように適用されます。Oracle BI Publisherのコールド・フェイルオーバー・クラスタに固有の要件によって、次のアーティファクトが共有ディスクにも存在し、フェイルオーバー・クラスタの両方のノードから同じマウント・ポイントにアクセスできることが確実になります。デフォルトのインストールで構成する場合、暗黙的にこのようになります。

- トランザクション・ログおよびJMS永続的ストア

- BI Publisher構成フォルダ

- BI Publisherカタログ・リポジトリ

- BI Publisher Scheduler一時ディレクトリ

BI EEの統合

BI PublisherとBI EEをまとめてデプロイすると、BI PublisherはBI EEプレゼンテーション・サービスを使用するように統合されます。この設定のBI EEデプロイメントは、通常、同一の仮想ホスト名cfcvip.mycompany.comをリスニングする、コールド・フェイルオーバー・クラスタ・デプロイメントにもなります。この場合は、BI EEの統合に関連するBI Publisher構成を変更して、この新しいアドレスでBI Publisherが確実にBI EEプレゼンテーション・サービスを検出できるようにする必要があります。そのための手順は次のとおりです。

1. BI PublisherアプリケーションURL http://hostname:port/xmlpserverを入力してログインします。

2. BIスケジューラのJMS構成を変更します。

1. 「管理」をクリックします。

2. 「システム・メンテナンス」で「スケジューラ構成」をクリックします。

3. WeblogicのJNDI URLをt3://cfcvip.mycompany.com:9704に変更します。

4. 「適用」をクリックします。

3. 管理サーバーのコンソールまたはコマンドラインを使用して、管理対象サーバーを再起動します。

Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関するすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。Oracle Business Intelligence PublisherのCFCデプロイメントについての要件は、次に示すアーティファクトも共有ディスク上に確実に存在して、それらがフェイルオーバー・クラスタの両方のノードの同じマウント・ポイントで確実に使用できることです。

- トランザクション・ログおよびJMS永続的ストア

- BI Publisher構成フォルダ

- BI Publisherカタログ・リポジトリ

- BI Publisher Scheduler一時ディレクトリ

Oracle BI Publisherクライアントの変換

Oracle BI Publisherクライアントを変換する手順は、次のとおりです。

1. Oracle BI Publisherクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。

2. WSM-PMは同じ管理対象サーバーにデプロイされるため、WSM-PMで必要なクライアント側の構成変更が同じように実行されていることを確認してください。

3. Oracle HTTP ServerがOracle BI Publisherのフロントエンドである場合、テキスト・エディタを使用して、次の例に示すように、mod_wl_ohsファイルを更新して仮想IPのcfcvip.mycompany.comをOracle BI Publisher管理対象サーバーのアドレスとして指定します。

# BI Publisher
<Location /xmlpserver>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:<port>
</Location>

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster APPHOST1:9704, APPHOST2:9704
</Location>

12.2.4.12.3 Oracle Real-Time Decisionsおよびそのクライアントの変換

この項では、Oracle Real-Time Decisions(Oracle RTD)をコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

Oracle RTDの変換

Oracle RTDをコールド・フェイルオーバー・クラスタ・デプロイメントに変換するには、この項の手順を実行します。

Oracle RTDは管理対象サーバー(BI_SERVER1など)にデプロイされます。コールド・フェイルオーバー・クラスタ変換の手順はこの管理対象サーバーをインストール後に仮想IPのcfcvip.mycompany.comでリスニングするように構成することになります。第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、BI_SERVER1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。

Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関するすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

Oracle RTDクライアントの変換

Oracle RTDクライアントを変換する手順は次のとおりです。

1. Oracle RTDクライアントは、仮想IPのcfcvip.mycompany.comを使用してこのアプリケーションにアクセスする必要があります。

2. WSM-PMは同じ管理対象サーバーにデプロイされるため、WSM-PMで必要なクライアント側の構成変更が同じように実行されていることを確認してください。

3. Oracle HTTP ServerがOracle RTDのフロントエンドである場合、テキスト・エディタを使用して、次の例に示すように、mod_wl_ohsファイルを更新して仮想IPのcfcvip.mycompany.comをOracle RTD管理対象サーバーのアドレスとして指定します。

<Location /rtis>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:<port>
</Location>

<Location /schemas>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:<port>
</Location>

<Location /ws>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com:<port>
</Location>

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster APPHOST1:9704, APPHOST2:9704
</Location>

# RTD
<Location /ui>
SetHandler weblogic-handler
WebLogicCluster APPHOST1:9704, APPHOST2:9704
</Location>

12.2.4.13 Oracle BI for Microsoft Officeおよびそのクライアントの変換

この項では、Oracle BI for Microsoft Officeをコールド・フェイルオーバー・クラスタ環境で機能するように変換する手順について説明します。

Oracle BI for Microsoft Officeは管理対象サーバー(BI_Server1など)にデプロイされ、コールド・フェイルオーバー・クラスタ変換を行うには、仮想IPのcfcvip.mycompany.comでリスニングするようにこのサーバーを構成します。第12.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、BI_SERVER1管理対象サーバーを、cfcvip.mycompany.comの仮想IP上でリスニングするように構成してください。

Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他のドメイン・アーティファクトに関するすべての要件は、第12.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

注意:

BI OfficeをCFC構成内で適切に機能させるには、bioffice.xmlファイル内のローカル・ホスト値を新しい仮想IP値に変更する必要があります。/bidomain/servers/bi_server1/tmp/_WL_user/bioffice_11.1.1/cvsibb/war/WEB-INFのbioffice.xmlファイルを参照してください。

Oracle BI for Microsoft Officeクライアントの変換

BI Officeのすべてのクライアントの起動でcfcvip.mycompany.comを使用する必要があります。OHSがBIOFFICEのフロントエンドである場合、テキスト・エディタを使用して、mod_wl_ohsファイルを更新し、仮想IPのcfcvip.mycompany.comをOracle BI for Microsoft Office管理対象サーバーのアドレスとして指定します。次の例を参照してください。

# BI Office
<Location /bioffice>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogicPort port
</Location>

<Location /biofficeclient>
SetHandler weblogic-handler
WebLogicHost cfcvip.mycompany.com
WebLogicPort port
</Location>

12.2.4.14 シングル・サインオンの再登録(必要な場合)

シングル・サインオン(SSO)の再登録は通常、Oracle Portal、Forms、ReportsおよびDiscovererにのみ適用されます。この層のOracle HTTP Server上のフロントエンド・リスニング・エンドポイントが仮想IPに変更された後で、保護されるURLを仮想IPによって構成するために、SSOの再登録が必要になります。SSOを再登録するには、SSOサーバーが配置されているIdentity Management 10.1.xインストールに対して次の手順を実行します。

1. ORACLE_HOME変数をSSOのORACLE_HOMEの場所に設定します。

2. 次のパラメータを指定して、ORACLE_HOME/sso/bin/ssoreg.sh (Windowsの場合はssoreg.bat)を実行します。

-site_name cfcvip.mycompany.com:port
-mod_osso_url http://cfcvip.mycompany.com
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier

3. 次に示す中間層ホームの場所に/tmp/osso.confファイルをコピーします。
ORACLE_INSTANCE/config/OHS/ohs1

4. ORACLE_HOME/opmn/bin/directoryから次のコマンドを実行して、Oracle HTTP Serverを実行します。

./opmnctl restartproc process-type=OHS

5. 次のURLでSSOサーバーにログインします。

http://login.mycompany.com/pls/orasso

6. 「管理」ページ、「パートナ・アプリケーション管理」の順に選択して、node1.mycompany.comのエントリを削除します。

12.2.5 Oracle Databaseの変換

Oracle Fusion Middlewareの一般的コールド・フェイルオーバー・クラスタ・デプロイメントでは、データベースもコールド・フェイルオーバー・クラスタとしてデプロイされます。この項では、単一インスタンスのOracle Databaseをコールド・フェイルオーバー・クラスタ・データベースに変換する方法について説明します。まず、この変換を実行してから、RCUを使用してデータベースをシードします。その後で、このシード済データベースを使用してFusion Middlewareをインストールします。

データベースをコールド・フェイルオーバー・クラスタ用に有効化する手順は次のとおりです。

1. データベース・インスタンスによって使用されるリスナー構成をlistener.oraファイルで変更します。
リスナー構成のホスト名では値として仮想ホスト名が指定されていることを確認します。さらに、リスナー・ポートを使用している他のプロセス(Oracleまたはサード・パーティ)が存在しないことも確認します。

<listener_name>  =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <virtual hostname>)(PORT = port))
)
)

例:

LISTENER_CFCDB =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST cfcdbhost.mycompany.com)(PORT = 1521))
)
)

2. tnsnames.oraファイルを変更します。
既存のTNSサービス別名エントリを変更するか、新しいエントリを作成します。

<tns alias name> =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = <virtual hostname>)(PORT = port))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = <db service name>)
(INSTANCE_NAME = <db instance name>)
)
)

)

例:

CFCDB =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = cfcdbhost.mycompany.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = cfcdb)
(INSTANCE_NAME = cfcdb)
)
)

3. ローカルのspファイルを変更して、インスタンスのlocal_listenerパラメータを更新します。
SQL*Plusを使用して、sysdbaとしてログインします。

SQL> alter system set local_listener='<tns alias name>' scope=both;
)

例:

SQL> alter system set local_listener='CFCDB' scope=both;

4. リスナーを停止してから再起動します。

5. データベース・インスタンスを停止してから再起動します。

6. アプリケーション・サーバーのデータベース・サービスを作成します。
Oracle Application Serverで使用するデフォルト・データベース・サービスとは別に、専用のサービスを作成することをお薦めします。このサービスを作成するには、次のSQL*Plusコマンドを実行します。

SQL> execute DBMS_SERVICE.CREATE_SERVICE(
'<cfc db service name>' ,  '<cfc db network name>' ) \

例:

SQL> execute DBMS_SERVICE.CREATE_SERVICE(
'cfcdb_asservice' ,  'cfcdb_asservice' )

このサービスを開始するには、次のSQL*PLUSコマンドを実行します。

SQL> execute DBMS_SERVICE.START_SERVICE(   'cfcdb_asservice' )

インストールの必要性に応じて、このサービスに追加パラメータを設定することもできます。DBMS_SERVICEコマンドの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

12.2.5.1 データベース・インスタンス・プラットフォーム固有の考慮事項

UnixおよびWindowsプラットフォームのデータベース・インスタンスについて次の手順を検討してください。

Unixの場合:

1. 前述のマウントおよびアンマウントの手順に従って、ノード1(インストール・ノード)からフェイルオーバー・ノード(ノード2)へ手動でデータベースのOracleホームをフェイルオーバーさせます。

2. rootとして、次の操作を行います。

- ノード1にあるものと同一のoraInst.locファイルを/etcディレクトリに作成します。

- ノード1にあるものと同一のoratabファイルを/etcディレクトリに作成します。

- ORACLE_HOMEディレクトリにあるoracleRoot.shファイルをノード2で実行します。これは、製品スイートで利用可能な場合や必要に応じて実行します。

3. ORACLE_HOME/oui/bin/attachHome.shディレクトリにあるattachHomeコマンドを使用して、oraInventoryファイルを2番目のノードで作成します。

Windowsの場合:

ノード1のシステム環境変数Pathにこのデータベースに関するなんらかの情報が含まれている場合、ノード2の同じ変数にも必ずその情報を設定します。ノード1からレジストリHKEY_LOCAL_MACHINE\SOFTWARE\Oracleをエクスポートして、それをノード2にインポートします。ノード2のORA_DBAグループにもユーザーsystemが存在することを確認します。

Windowsリソース・キットのSCツールを使用して、次のサービスを作成します。

- dbサービス

sc create OracleService<oracle_sid> start= demand  binPath= "ORACLE_HOME\bin\ORACLE.EXE <oracle_sid>"

例:

sc create OracleServiceORCL start= auto
binPath= "C:\Oracle\db\product\11.1.0\bin\ORACLE.EXE <oracle_sid>"

注意:

oracle_sidは大文字で指定する必要があります。

- リスナー

sc create Oracle<home name>TNSListener start= demand binPath= "ORACLE_HOME\bin\TNSLSNR"

例:

sc create OracleINFRATNSListener start= demand
binPath= "C:\Oracle\db\product\11.1.0\bin\TNSLSNR"

- クラスタ・サービス

sc create OracleCSService start= auto
binPath= "ORACLE_HOME\bin\ocssd.exe service"

例:

sc create OracleCSService start= auto
binPath= "INFRAHOME\bin\ocssd.exe service"

- データベース・コンソール

sc create OracleDBConsole<oracle_sid> start= auto
binPath= "ORACLE_HOME\bin\nmesrvc service"

例:

sc create OracleDBConsoleorcl start= auto
binPath= " C:\Oracle\db\product\11.1.0\bin\nmesrvc service"

- ジョブ・スケジューラ

sc create OracleJobScheduler<oracle_sid> start= demand
binPath= "ORACLE_HOME\bin\extjob.exe <oracle_sid>"

例:

sc create OracleJobSchedulerORCL start= auto
binPath= "C:\Oracle\db\product\11.1.0\INFRAHOME\bin\extjob.exe <oracle_sid>"

注意:

oracle_sidは大文字で指定する必要があります。

- Vssサービス

sc create OracleVssWriter<oracle_sid> start= demand binPath= "ORACLE_HOME\bin\OraVSSW.exe <oracle_sid>"

例:

sc create OracleJobSchedulerORCL start= auto
binPath= "C:\Oracle\db\product\11.1.0\INFRAHOME\bin\ OraVSSW.exe <oracle_sid>"

注意:

oracle_sidは大文字で指定する必要があります。

12.3 Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジ例

この項では、コールド・フェイルオーバー・クラスタのトポロジ例について説明します。トポロジでは様々な組合せが考えられるため、ここで示すトポロジは例にすぎません。これらのトポロジを実現するには、複数の変換手順が適用されます。変換を構成する方法の詳細は、前述の各手順を参照してください。

12.3.1 トポロジ例1

図12-3は、Oracle WebCenterポータルのコールド・フェイルオーバー・クラスタ・デプロイメントを示しています。ドメイン内には管理サーバーとWebCenter管理対象サーバーの両方があり、1つのユニットとしてフェイルオーバーします。したがって、これらは同じ仮想IPを共有し、同じ共有ディスク上にまとめてインストールされています。このトポロジのフロントエンドとしてOracle HTTP Serverも使用できます。このトポロジ例では、別のノードに配置されています。同じノードに配置して、コールド・フェイルオーバー・クラスタ・デプロイメントの一部とすることも可能です。この例では、データベースも別のノードに配置されています。しかし、データベースも同様に、同じクラスタ上に配置して、コールド・フェイルオーバー・クラスタベースにする場合もあります(仮想IPと共有ディスクは専用のものを使用)。

図12-3 コールド・フェイルオーバー・クラスタのトポロジ例1

「図12-3 コールド・フェイルオーバー・クラスタのトポロジ例1」の説明

12.3.2 トポロジ例2

図12-4は、SOAコールド・フェイルオーバー・クラスタ・デプロイメント例を示しています。この例では、SOAインスタンスのみがコールド・フェイルオーバー・クラスタとしてデプロイされ、管理サーバーは別のノードに配置されています。このトポロジ例では、データベースも別のノードに配置されています。この例では、Oracle HTTP Serverはコールド・フェイルオーバー・クラスタ・デプロイメントの一部であり、SOA管理対象サーバーと同じフェイルオーバー・ユニットの一部になります。このトポロジの重要なバリエーションの1つは、同じハードウェア・クラスタにコールド・フェイルオーバー・クラスタ管理サーバーを組み込むことです。この場合、仮想IPと共有ディスクをSOA管理対象サーバーと共有するか(管理サーバーをSOAと同じフェイルオーバー・ユニットに組み込む)、別の仮想IPと共有ディスクを使用(管理サーバーを別個にフェイルオーバーさせる)できます。同様に、マシンの処理能力に応じて、データベース・インスタンスも同じハードウェア・クラスタに配置できます。

図12-4 コールド・フェイルオーバー・クラスタのトポロジ例2

「図12-4 コールド・フェイルオーバー・クラスタのトポロジ例2」の説明

12.3.3 トポロジ例3

図12-5は、Oracle Identity Managementデプロイメントを示しています。このトポロジ例では、すべてのコンポーネントが、2つのノードのハードウェア・クラスタに配置されています。Identity Managementは1つのユニットとしてフェイルオーバーし、Java EEコンポーネント(管理サーバーとWLS_ods管理対象サーバー)とシステム・コンポーネントの両方が、同じフェイルオーバー・ユニットの一部となっています。これらは同じ仮想IP(cfcvip1.mycompany.com)と共有ディスクを使用しています。データベースも同じハードウェア・クラスタに配置されています。異なる仮想IP cfcvip2.mycompany.comと、異なる共有ディスク・セットを使用しています。通常の運用中では、データベースはノード2で実行し、IDMスタックはノード1で実行します。それぞれのノードは互いにバックアップ・ノードとして機能します。

このトポロジは、ほとんどのコールド・フェイルオーバー・クラスタ・デプロイメントの推奨トポロジです。例ではIdentity Managementを使用していますが、Oracle SOA、Oracle WebCenterポータル、Oracle Portal、Forms、ReportsおよびDiscovererスイートにも有効です。推奨アーキテクチャでは、Oracle Fusion Middlewareはハードウェア・クラスタの1つのノードとして実行します。別のノードではOracle Databaseを実行します。各ノードは互いにバックアップ・ノードになります。Oracle Fusion Middlewareインスタンスとデータベース・インスタンスは、異なる共有ディスクと異なるVIPを使用し、互いに独立してフェイルオーバーします。また、このアーキテクチャでは、ハードウェア・クラスタ・リソースの使用率が最適化されます。

図12-5 コールド・フェイルオーバー・クラスタのトポロジ例3

「図12-5 コールド・フェイルオーバー・クラスタのトポロジ例3」の説明

12.4 コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換

この項では、既存のドメインの管理サーバーをコールド・フェイルオーバー・クラスタに変換する手順について説明します。

注意:

管理サーバーの変換後、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」で述べられているように、管理サーバーおよびEnterprise Managerのクライアント側の変更が必要になる場合があります。

前提事項

この項の手順は、次を前提としています。

- すべてのFusion Middlewareコンポーネントは、nostageデプロイメントに配置されています。

- 起動トポロジが製品スイートのアクティブ/アクティブ・クラスタです(ノード1およびノード2)。

- 開始する管理サーバーはノード1です。

- ノード1の管理対象サーバーと同じドメイン・ホームを共有しています。

- MW_HOMEパスがノード1とノード2で同じです。

開始トポロジ

トポロジの起動を実行するには、次の項を参照してください。

- Oracle SOA Suite: 第5.13項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」

- Oracle ADF: 第6.2項「Oracle ADFの高可用性デプロイメントの構成」

- Oracle WebCenterポータル: 第6.4項「WebCenterポータルの高可用性の構成」

- Oracle Identity Manager: 第8章「Identity Managementコンポーネントの高可用性の構成」

これらの手順は、前提が満たされていれば、Oracle WebLogicクラスタ・インストールにデプロイされているカスタマ・アプリケーションにも適用されます。

図12-6は、管理サーバーを変換する前の開始トポロジの例を示しています。

図12-6 コールド・フェイルオーバー・クラスタの開始トポロジ例

「図12-6 コールド・フェイルオーバー・クラスタの開始トポロジ例」の説明

12.4.1 変換後トポロジ

図12-7に、コールド・フェイルオーバー・クラスタ用に管理サーバーを変換した後の可能なトポロジを示します。このトポロジは、次のような特性を持ちます。

- 管理サーバー・ドメイン・ホームは、ノード1とノード2の両方でマウント可能な共有ディスクに移動しますが、任意の時点では片方のみがマウントされます。

- 引き続き、ノード1とノード2からアクセスできる元のMiddlewareホームが使用されます。

- 管理サーバーのリスニング・アドレスは、仮想IPになります。

図12-7 変換後の可能なトポロジ

「図12-7 変換後の可能なトポロジ」の説明

12.4.2 コールド・フェイルオーバー・クラスタ変換の手順

既存のドメインで管理サーバーを変換するには、次の手順を実行します。

1. コンポーネントの管理対象サーバーおよび管理サーバーのクラスタをシャットダウンします。

2. 各ノードでノード・マネージャ・プロセスが稼働していれば、それをシャットダウンします。

3. ドメイン全体をバックアップします。

4. ノード1で仮想IPをプロビジョニングします。例:
Linuxの場合:

/sbin/ifconfig eth0:1 IP_Address netmask netmask
/sbin/arping -q -U -c 3 -I eth0 IP_Address

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。

次の例では、Local Area ConnectionのインタフェースでIPアドレスが有効化されます。

/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0
/sbin/arping -q -U -c 3 -I eth0 130.35.46.17

Windowsの場合:

netsh interface ip add address interface IP_Address netmask

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。

次の例では、「Local Area Connection」のインタフェースでIPアドレスが有効化されます。

netsh interface ip add address "Local Area connection" 130.35.46.17 255.255.224.0

5. ローカルのドメイン・ホームから管理サーバーを起動します。

cd DOMAIN_HOME/bin
./startWeblogic.sh

6. 管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
管理コンソールにログインします。

仮想ホストに備えてノードを作成します。

1. 「環境」、「マシン」の順に選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。「新規」をクリックします。

3. 「名前」フィールドでは、cfcvip.mycompany.comと入力します。

注意:

「リスニング・アドレス」フィールドはlocalhostに設定したままにします(CFCソリューションはこの設定に依存します)。これを仮想IPアドレスまたはその他の値に変更しないでください。

管理サーバーには、ローカルだけでなく複数のノード・マネージャと対話できるように新しい仮想ホスト・マシンが必要です。各ホストの各ノード・マネージャは、実際のIPおよびローカル・ホスト(127.0.0.1)の両方のすべてのインタフェースでリスニングします。管理サーバーは、新しい仮想ホスト・マシン定義を排他的に使用します。

localhostはすべてのアクティブなマシンの相対内部アドレスであり、管理サーバーに固定されるため、仮想ホスト・マシンはlocalhostを指す必要があります。管理サーバーをあるホストから別のホストに変更しても、同じ仮想名およびVIPが保持されます。管理サーバーはlocalhost属性と1つ目のノードを組み合せて使用し、フェイルオーバー後は2つ目のノードも使用するため、管理サーバーと関連付けられているノード・マネージャも変更されます。図xを参照してください。

4. 適切なオペレーティング・システムを選択して、「OK」をクリックします。

5. 作成したマシンを選択します。

6. 「サーバー」タブをクリックしてから、「追加」をクリックします。

7. 既存のサーバーを選択して、このマシンに関連付けます。

8. 「サーバーの選択」ドロップダウン・リストで、「AdminServer」が選択されていることを確認します。

9. 「終了」→「変更のアクティブ化」をクリックします。

cfcvip.mycompany.com上でリスニングするように管理サーバーを構成します。

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 管理サーバー(AdminServer)をクリックします。

4. 「リスニング・アドレス」をcfcvip.mycompany.comに変更し、「保存」をクリックします。

管理コンソールから管理サーバーを停止します。

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」をクリックします。

3. その横にあるチェック・ボックスをクリックして、「Adminserver」を選択します。

4. 「停止」プルダウン・メニューで、「ただちに強制停止」を選択して、管理サーバーをシャットダウンします。

5. 「はい」をクリックします。

コマンドラインから、システムでVIPが有効で、管理サーバーが起動していることを確認します。

cd DOMAIN_HOME/bin
./startWeblogic.sh

7. 仮想IP上でコンソールにアクセスして、管理サーバーを検証します。

- http://cfcvip.mycompany.com:7001/console

- http://cfcvip.mycompany.com:7001/em

8. 管理コンソールを使用して、ノード1の管理サーバーシャットダウンします。

9. ノード1で共有ディスクがプロビジョニングおよびマウントされていることを確認します。

10. ノード1でドメイン全体をパックします。

cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=false -domain=/localdisk/user_projects/domains/domain_name
-template=cfcdomaintemplate_all.jar -template_name=cfc_domain_template_all

11. それを共有ディスク上に解凍します。

./unpack.sh -domain=/shareddisk/user_projects/domains/domain_name
-template=cfcdomaintemplate_all.jar
-app_dir=/shareddisk/user_projects/apps -server_start_mode=prod

12. 製品スイート固有の変更:
Oracle Identity Management製品スイート:

- config.xmlファイルをバックアップします。この例では、/shareddisk/user_projects/domains/domain_name/config/ディレクトリにあります。

- WCCソケット・ホスト・フィルタを次のファイル内のVIPに変更します。

- {domain}/ucm/ibr/config/config.cfg

- {domain}/ucm/urm/config/config.cfg

- {domain}/ucm/cs/config/config.cfg

- config.xmlファイルを編集してソースパスに次の変更を行います。この例では、/shareddisk/user_projects/domains/domain_name/configにあります。
dipappで、ソースパスをORACLE_HOME/ldap/odi/dipapp/dipapps.earに変更します。

例:

<app-deployment>
<name>DIP#11.1.1.2.0</name>
<target>cluster_ods</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/ldap/odi/dipapp/dipapps.ear</source_path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</app-deployment>

ODSMアプリケーションで、ソースパスをORACLE_HOME/ldap/odsm/odsm.earに変更します。

例:

<app-deployment>
<name>odsm#11.1.1.2.0</name>
<target>cluster_ods</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/ldap/odsm/odsm.ear</source-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</app-deployment>

- OIF:
次のようにして、OIF-APPのソースパスを ORACLE_HOME/fed/install/oif.earに変更します。

<app-deployment>
<name>OIF#11.1.1.2.0</name>
<target>cluster_oif</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/fed/install/oif.ear</source-path>
<security-dd-model>Advanced</security-dd-model>
<staging-mode>nostage</staging-mode>
</app-deployment>

oif-libsのソースパスをORACLE_HOME/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.earに変更します。

<library>
<name>oif-libs#11.1.1.2.0@11.1.1.2.0</name>
<target>cluster_oif</target>
<module-type>ear</module-type>
<source-path>ORACLE_HOME/lib/java/shared/oracle.idm.oif/11.1.1.0.0/oif-libs.ear</source-path>
<security-dd-model>DDOnly</security-dd-model>
</library>

13. 管理サーバーを起動します。

cd /shareddisk/user_projects/domains/domain_name/bin
./startWeblogic.sh

14. 仮想IP上でコンソールにアクセスして、管理サーバーを検証します。

- http://cfcvip.mycompany.com:7001/console

- http://cfcvip.mycompany.com:7001/em

15. 管理サーバーをシャットダウンします。

16. ノード1で次を実行します。

mv /localdisk/user_projects/domains/domain_name
/localdisk/user_projects/domains/domain_name_old
mv /localdisk/user_projects/applications/domain_name
/localdisk/user_projects/applications/domain_name_old
cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true -domain=/shareddisk/user_projects/domains/domain_name
-template=cfcdomaintemplate_mngd.jar -template_name=cfc_domain_template_mngd
./unpack.sh -domain=/localdisk/user_projects/domains/domain_name
-template=cfcdomaintemplate_mngd.jar

注意:

これらのコマンドでは、アプリケーション・ディレクトリがuser_projectsの下に存在すると想定しています。

17. テンプレートをノード2にコピーします。

scp ORACLE_COMMON_HOME/common/bin/cfcdomaintemplate_mngd.jar
Node2:ORACLE_COMMON_HOME/common/bin

18. ノード2にログインして、ノード2上で解凍します。

mv /localdisk/user_projects/domains/domain_name
/localdisk/user_projects/domains/domain_name_old
mv /localdisk/user_projects/applications/domain_name
/localdisk/user_projects/applications/domain_name_old
cd ORACLE_COMMON_HOME/common/bin
./unpack.sh -domain=/localdisk/user_projects/domains/domain_name
-template=cfcdomaintemplate_mngd.jar

注意:

これらのコマンドでは、アプリケーション・ディレクトリがuser_projectsの下に存在すると想定しています。

19. Oracle Identity Manager Suiteでは、次の追加手順が必要です。
DIPの場合:

1. ノード1で、Oracle WebLogic Serverドメイン・ディレクトリ内のアプリケーション・ディレクトリを探します。

MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applications

2. ノード1のアプリケーション・ディレクトリとその内容を、ノード2のドメイン・ディレクトリ内の同じ場所にコピーします。

scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers
/wls_ods1/applications
user@IDMHOST2:MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig
/servers/wls_ods2/applications

OIFの場合:

1. ノード1で、Oracle WebLogic Serverドメイン・ディレクトリ内のアプリケーション・ディレクトリを探します。

MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig/servers/wls_oif1/applications

2. ノード1のアプリケーション・ディレクトリとその内容を、ノード2のドメイン・ディレクトリ内の同じ場所にコピーします。

scp -rp MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig/servers
/wls_oif1/applications
user@IDMHOST2:MW_HOME/user_projects/domains/OIFDomain/config/fmwconfig
/servers/wls_oif2/applications

20. 管理サーバーを起動します。

cd /shareddisk/user_projects/domains/domain_name/bin
./startWeblogic.sh

21. ノード1およびノード2でノード・マネージャが使用されている場合、それを起動します。

cd WL_HOME/server/bin
./startNodeManager.sh

22. 管理サーバー・コンソール(ノード・マネージャが使用されている場合)またはコマンドラインからノード1およびノード2上のコンポーネントの管理対象サーバーを起動します。

23. コンポーネント固有の機能テストを使用してデプロイメントを検証します。

24. 管理サーバーのフェイルオーバーをテストします。
管理サーバーを2番目のノードに手動でフェイルオーバーさせます。

1. 管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。

2. Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。

3. 記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。

4. ノード1で仮想IPを無効化します。
Linuxの場合:

ifconfig interface:index down

次の例では、eth0インタフェースでIPアドレスが無効化されます。

ifconfig eth0:1 down

Windowsの場合:

netsh interface ip delete address interface addr=IP Address

この場合、IP Addressは仮想IPアドレスです。

次の例では、Local Area ConnectionのインタフェースでIPアドレスが有効化されます。

netsh interface ip delete address 'Local Area connection' addr=130.35.46.17

5. ノード2で仮想IPを有効化します。

6. 次のコマンドを使用して、管理サーバー・プロセスを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。

管理サーバーとOracle Enterprise Manager管理コンソールの両方へのアクセスを検証します。

コンポーネント固有のテストで検証します。

25. 検証後、管理サーバーが通常に稼働し、通常に処理を実行するノード(ノード1またはノード2)にフェイルバックします。

13 Oracle Cluster Ready Servicesの使用

この章では、Oracle Cluster Ready Servicesの概要および構成手順について説明します。次の項目が含まれます。

- 第13.1項「Oracle Clusterwareの概要」

- 第13.2項「Cluster Ready ServicesとOracle Fusion Middleware」

- 第13.3項「CRSでのOracle Clusterwareのインストールと構成」

- 第13.4項「ASCRSを使用したリソースの管理」

- 第13.5項「トポロジの例」

- 第13.6項「Oracle CRSのトラブルシューティング」

13.1 Oracle Clusterwareの概要

Oracle Clusterwareにより、クラスタ環境のユーザー・アプリケーションとOracle Databaseの可用性を管理します。Oracle Real Application Clusters(Oracle RAC)環境において、Oracle ClusterwareはすべてのOracle Databaseプロセスを自動的に管理します。Oracle Clusterwareの管理対象はクラスタ・リソースと呼ばれます。これは、データベース・インスタンス、リスナー、仮想IP(VIP)アドレスまたはアプリケーション・プロセスになる場合があります。

当初、Oracle ClusterwareはOracle RACのサポート用に作成されました。しかし、その利点はOracle RACに限定されず、アドオン・モジュール(またはアクション・スクリプト)により、他のアプリケーションの管理にもそれを使用できます。この柔軟性と拡張性から、Oracle ClusterwareはOracle Fusion Middlewareの高可用性ソリューションの基盤となっています。

Oracle Clusterwareの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

13.2 Cluster Ready ServicesとOracle Fusion Middleware

Oracle Clusterwareには、リソース固有のアドオン・モジュールを使用して任意のリソースに保護を提供する高可用性フレームワークが含まれます。Oracle Clusterwareの用語では、リソースとは、アプリケーション、仮想IP、共有ディスクなどの管理対象エンティティを識別するためにOracle Clusterwareによって作成されたオブジェクトのことです。Oracle Clusterwareでは、リソースの状態を頻繁にチェックして停止している場合には再起動を試行し、リソースの可用性を監視します。再起動に失敗すると、リソースは新しいノードで起動されます(このプロセスはフェイルオーバーと呼ばれています)。リソースのスイッチオーバーはリソースの運用環境の意図的な切替えのことですが、正規のユーザー・インタフェースを介してこれを使用することもできます。

この高可用性フレームワークによって、Oracle Clusterwareはユーザーが提供するアドオン・モジュールを介してリソースを管理します。たとえば、単一プロセスで実行されるアプリケーションを表すリソースを作成するには、プロセスを起動および停止し、その状態をチェックするモジュールをユーザーが提供する必要があります。このアプリケーションに障害が発生すると、Oracle Clusterwareではこのモジュールを使用してプロセスの再起動を試みます。このアプリケーションが現在実行されているノードで障害が発生したときに、アプリケーションおよびリソースが正しく構成されている場合、Oracle Clusterwareでは別のノードでアプリケーションの再起動を試みます。リソースの監視頻度を構成して、他のリソースとの関係を定義することができます。

Application Server Cluster Ready Services(ASCRS)を使用すると、重要で複雑なOracle Fusion Middlewareアプリケーション環境で独自のアドオン・モジュールを記述する労力が軽減され、Oracle Clusterwareの高可用性機能に容易にアクセスできます。

注意:

ASCRSは、すでにCFCが有効なOracle Fusion Middleware環境を管理するためのソリューションです。様々なFusion MiddlewareコンポーネントでのCFCの有効化の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。

ASCRSはフロントエンドとバックエンドで構成されます。フロントエンドはコマンドライン・インタフェースであるascrsctlであり、このインタフェースにより、リソースの作成、削除、更新、起動、停止、クラスタ・ノード間のスイッチオーバーなどの管理タスクを実行できます。バックエンドは、様々なFusion Middlewareリソースのライフサイクル管理のためのロジックです。フロントエンドとバックエンドにはそれぞれ固有のログ・ファイルがあります。

UnixプラットフォームおよびWindows Server 2008では、ASCRSは仮想IP、共有ディスク、データベース・リスナー、データベース・インスタンス、OPMN管理対象インスタンス、およびWebLogic Serverをサポートします。これらのミドルウェア・コンポーネントからOracle Clusterwareリソースを作成し、Oracle ClusterwareとASCRSでクラスタ内の高可用性を維持できます。

Oracle ClusterwareとASCRSには、ホスティング環境が破損したり消失した場合に様々なリソースの残存性を向上する手段が用意されています。ただし、ディスクの破損や、ディスクの破損によるアプリケーションの誤作動を回避するわけではありません。

ASCRSでは、Oracle Clusterwareバージョン10.2.0.4、11.1.0.7以上または11.2.0.2以上をサポートしています。次のコマンドを使用して、オンライン・ヘルプを開きます。

ascrsctl help -c command -t resource_type

たとえば、次のコマンドを実行すると、仮想IPリソースの作成に関するヘルプが表示されます。

ascrsctl help -c create -t vip

ascrsctlのオンライン・ヘルプの完全な内容については、付録E「ascrsctlのオンライン・ヘルプ」を参照してください。

13.3 CRSでのOracle Clusterwareのインストールと構成

ASCRSを使用するには、クラスタの各ノードにある各CRSホーム内で、CRSの拡張機能としてASCRSをインストールし、個別に構成する必要があります。

ASCRSコマンドライン・ツールのascrsctlにより、ASCRSで様々なミドルウェア・コンポーネントを制御できます。CRSの制御対象であるコンポーネントは、実行時の状態が詳細に監視され、障害発生時にCRSによって適切なアクションが実行されます。ascrsctlを使用して、CRSリソースを作成することができます。リソースを作成したら、そのリソースに対して、起動、停止、更新、切替え、ステータス監視および削除操作を実行できます。

13.3.1 古いバージョンから現在のバージョンへのASCRSのアップグレード

古いバージョンのASCRSを使用している場合、次の手順を実行して最新のASCRSバージョンにアップグレードします。

1. ASCRSのstopコマンドを使用して、すべてのASCRSリソースをオフラインにします。

2. ASCRSのstatusコマンドを使用してFusion Middlewareリソースのステータスを表示し、そのすべての設定をメモしておきます。

3. それらのリソースを削除します。

4. CRS_HOME/ascrsディレクトリを削除します。

5. 第13.3.2項「ASCRSのインストール」で説明されているように、ASCRSの新しいバージョンをインストールして、setupコマンドを使用して終了します。

6. ステップ2の情報を使用し、ASCRSのcreateコマンドを使用してFusion Middlewareリソースを再作成します。

13.3.2 ASCRSのインストール

クラスタの各ノードにASCRSをインストールします。個別ノードにASCRSを適切にインストールするには、次のことを確認してください。

- オペレーティング・システム: ASCRSは、UnixプラットフォームおよびWindows Server 2008でサポートされます。システム・バージョンとパッチ・レベルは、そのプラットフォームでサポートされているCRSのリリースと互換性がある必要があります。

- CRSおよびバージョン: CRSは、このシステムにインストールされ、起動され、適切に機能しています。CRSバージョンは、10.2.0.4以降であることが必要です。Oracle ClusterwareおよびCRSのインストールの詳細は、Oracle Clusterwareインストレーション・ガイドfor Linuxを参照してください。

- ユーザー・アカウント: ASCRSインストール・ユーザーは、CRSホームの所有者と同一ユーザーである必要があります。これは、管理対象のアプリケーション・リソースの所有者とも同一である必要があります。Windowsでは、ユーザーに管理者権限が必要です。

注意:

CRS 10.2.0.4に対してASCRSをインストールするには、ローカル・システムにSun JDK(またはJRE)1.5以上がインストールされている必要があります。これはコマンドライン・ツールのascrsctlで必要になります。

ASCRSをインストールする手順は次のとおりです。

1. CRSの所有者としてログインします。

2. Oracle Fusion Middleware Companion CDを挿入し、次のコマンドを実行してascrs.zipファイルを解凍およびインストールします。

cd CRS_HOME
unzip Disk1/ascrs/ascrs.zip
cd ascrs/bin
setup

JDK(JRE)1.5+以上がインストールされており、CRSのリリースが10.2.0.4である場合、次のコマンドを実行します。

setup -j JDK/JRE_HOME

インストールが完了すると、次のASCRSディレクトリ構造が表示されます。

CRS_HOME/ascrs/bin
CRS_HOME/ascrs/config
CRS_HOME/ascrs/lib
CRS_HOME/ascrs/log
CRS_HOME/ascrs/public
CRS_HOME/ascrs/perl
CRS_HOME/ascrs/sql
CRS_HOME/ascrs/wlst

13.3.3 Oracle Fusion MiddlewareでのASCRSの構成

ASCRSがインストールされると、デフォルト構成で使用できます。ロギングの場所、ロギング・レベルまたはデフォルトのCRSプロパティをカスタマイズするには、CRS_HOME/ascrs/configディレクトリにあるconfig.xmlを編集します。

注意:

ASCRSには、config.xmlファイル内の使用可能なリスニング・ポートが必要です。Weblogic Serverのリリースによっては、管理サーバーをコールド・フェイルオーバー・クラスタ構成に変換すると、管理サーバーのリスニング・ポートがデフォルト(7001)の場合、config.xmlファイルにリスニング・ポート・ディレクティブが明示的には含まれなくなります。ASCRSを構成する前に、ファイルDOMAIN_HOME/config/config.xmlにリスニング・ポート・ディレクティブが明示的に指定されていることを確認します。例:

<server>
<name>AdminServer</name>
....
<listen-port>7001</listen-port>
<listen-port-enabled>true</listen-port-enabled>
<listen-address>cfc.mycompany.com</listen-address>
....
</server>

config.xmlファイルには、ascrsctl ASCRSエージェント・ロギングの構成が格納されます。いずれかの場所を変更するには、既存のパス名を指定するか、ORACLE_HOME接頭辞を使用してこのCRSホーム内のパス名を指定します。利用可能なロギング・レベルは、冗長性の高い順に、ALL、FINEST、FINER、FINE、INFO、WARNINGおよびSEVEREです。それぞれのリソースには独自のエージェント・ログ・ファイルがあり、そのサイズがrollover_size バイトを超えるとロールオーバーします。

ポリシーのCRSプロパティが構成されます。ポリシー名は、そのポリシーにおけるCRSプロパティ値の特性を示しています。ポリシーはnormalまたはfastを指定できます。ポリシー「fast」はリソースのヘルス・チェックの頻度がより高くなり、フェイルオーバー時の遅延が低下します。

ASCRS付属のデフォルトconfig.xmlファイルを次に示します。

<?xml version="1.0" ?>
<config>
<ascrsctl>
<display level="normal"/>
<log path="${ORACLE_HOME}/ascrs/log/ascrsctl.log" level="FINER"/>
<resource-params target="vip" policy="normal">
<param name="AUTO_START" value="1"/>
<param name="CHECK_INTERVAL" value="7"/>
<param name="FAILOVER_DELAY" value="5"/>
<param name="FAILURE_INTERVAL" value="50"/>
<param name="FAILURE_THRESHOLD" value="5"/>
<param name="RESTART_ATTEMPTS" value="2"/>
<param name="SCRIPT_TIMEOUT" value="120"/>
<param name="START_TIMEOUT" value="120"/>
<param name="STOP_TIMEOUT" value="120"/>
</resource-params>

<resource-params target="vip" policy="fast">
<param name="AUTO_START" value="1"/>
<param name="CHECK_INTERVAL" value="5"/>
<param name="FAILOVER_DELAY" value="4"/>
<param name="FAILURE_INTERVAL" value="30"/>
<param name="FAILURE_THRESHOLD" value="5"/>
<param name="RESTART_ATTEMPTS" value="2"/>
<param name="SCRIPT_TIMEOUT" value="120"/>
<param name="START_TIMEOUT" value="120"/>
<param name="STOP_TIMEOUT" value="120"/>
</resource-params>

<resource-params target="disk" policy="normal">
<param name="AUTO_START" value="1"/>
<param name="CHECK_INTERVAL" value="7"/>
<param name="FAILOVER_DELAY" value="5"/>
<param name="FAILURE_INTERVAL" value="50"/>
<param name="FAILURE_THRESHOLD" value="5"/>
<param name="RESTART_ATTEMPTS" value="2"/>
<param name="SCRIPT_TIMEOUT" value="120"/>
<param name="START_TIMEOUT" value="120"/>
<param name="STOP_TIMEOUT" value="120"/>
</resource-params>

<resource-params target="disk" policy="fast">
<param name="AUTO_START" value="1"/>
<param name="CHECK_INTERVAL" value="5"/>
<param name="FAILOVER_DELAY" value="4"/>
<param name="FAILURE_INTERVAL" value="30"/>
<param name="FAILURE_THRESHOLD" value="5"/>
<param name="RESTART_ATTEMPTS" value="2"/>
<param name="SCRIPT_TIMEOUT" value="120"/>
<param name="START_TIMEOUT" value="120"/>
<param name="STOP_TIMEOUT" value="120"/>
</resource-params>

<resource-params target="dblsnr" policy="normal">
<param name="AUTO_START" value="1"/>
<param name="CHECK_INTERVAL" value="50"/>
<param name="FAILOVER_DELAY" value="20"/>
<param name="FAILURE_INTERVAL" value="300"/>
<param name="FAILURE_THRESHOLD" value="5"/>
<param name="RESTART_ATTEMPTS" value="4"/>
<param name="SCRIPT_TIMEOUT" value="120"/>
<param name="START_TIMEOUT" value="120"/>
<param name="STOP_TIMEOUT" value="120"/>
</resource-params>

<resource-params target="dblsnr" policy="fast">
<param name="AUTO_START" value="1"/>
<param name="CHECK_INTERVAL" value="40"/>
<param name="FAILOVER_DELAY" value="20"/>
<param name="FAILURE_INTERVAL" value="250"/>
<param name="FAILURE_THRESHOLD" value="5"/>
<param name="RESTART_ATTEMPTS" value="4"/>
<param name="SCRIPT_TIMEOUT" value="120"/>
<param name="START_TIMEOUT" value="120"/>
<param name="STOP_TIMEOUT" value="120"/>
</resource-params>

<resource-params target="db" policy="normal">
<param name="AUTO_START" value="1"/>
<param name="CHECK_INTERVAL" value="120"/>
<param name="FAILOVER_DELAY" value="30"/>
<param name="FAILURE_INTERVAL" value="700"/>
<param name="FAILURE_THRESHOLD" value="5"/>
<param name="RESTART_ATTEMPTS" value="4"/>
<param name="SCRIPT_TIMEOUT" value="300"/>
<param name="START_TIMEOUT" value="300"/>
<param name="STOP_TIMEOUT" value="300"/>
</resource-params>

<resource-params target="db" policy="fast">
<param name="AUTO_START" value="1"/>
<param name="CHECK_INTERVAL" value="60"/>
<param name="FAILOVER_DELAY" value="20"/>
<param name="FAILURE_INTERVAL" value="400"/>
<param name="FAILURE_THRESHOLD" value="5"/>
<param name="RESTART_ATTEMPTS" value="4"/>
<param name="SCRIPT_TIMEOUT" value="300"/>
<param name="START_TIMEOUT" value="300"/>
<param name="STOP_TIMEOUT" value="300"/>
</resource-params>

<resource-params target="as" policy="normal">
<param name="AUTO_START" value="1"/>
<param name="CHECK_INTERVAL" value="50"/>
<param name="FAILOVER_DELAY" value="20"/>
<param name="FAILURE_INTERVAL" value="350"/>
<param name="FAILURE_THRESHOLD" value="5"/>
<param name="RESTART_ATTEMPTS" value="4"/>
<param name="SCRIPT_TIMEOUT" value="600"/>
<param name="START_TIMEOUT" value="600"/>
<param name="STOP_TIMEOUT" value="600"/>
</resource-params>

<resource-params target="as" policy="fast">
<param name="AUTO_START" value="1"/>
<param name="CHECK_INTERVAL" value="40"/>
<param name="FAILOVER_DELAY" value="10"/>
<param name="FAILURE_INTERVAL" value="300"/>
<param name="FAILURE_THRESHOLD" value="5"/>
<param name="RESTART_ATTEMPTS" value="4"/>
<param name="SCRIPT_TIMEOUT" value="600"/>
<param name="START_TIMEOUT" value="600"/>
<param name="STOP_TIMEOUT" value="600"/>
</resource-params>
</ascrsctl>
<agent>
<log path="${ORACLE_HOME}/ascrs/log" level="FINER" rollover_size="5242880"/>
</agent>
</config>

注意:

リソースのプロパティ値は、それが作成されたときの正しい範囲の中に収まる必要があります。ポリシーにパラメータが構成されていない場合、内部のデフォルト値が使用されます。

表E-1に内部のデフォルトのパラメータ値を示します。

これらのプロパティの値を編集する場合は、事前にOracle Clusterwareのドキュメントで各パラメータの定義を確認してください。

コンピューティング環境によって処理速度が異なるため、スクリプト、起動および停止のタイムアウト値を設定する前に、アプリケーションの起動と停止における待機時間を測定することをお薦めします。これらの値を、測定された待機時間の約2倍に設定します。

13.4 ASCRSを使用したリソースの管理

ascrsctlコマンドラインにより、Fusion Middlewareコンポーネント用に作成したCRSリソースを管理します。このツールにより、リソースの作成、更新、起動、停止、スイッチおよび削除ができます。

前の項で述べたように、リソースとは、アプリケーション、仮想IP、共有ディスクなどの管理対象エンティティを識別するためにCRSによって作成されたオブジェクトのことです。各リソースの自動開始値を1に設定すると、CRSの起動時にそのリソースが確実に起動されます。Fusion Middlewareリソースは相互に依存するため、1つのリソースを起動または停止すると、別のリソースに影響する場合があります。ascrsctl構文を使用してリソースの作成時にリソースの依存性を施行します。実行時に、CRSはこの依存性の情報を使用して起動/停止を行います。

13.4.1 CRS管理対象リソースの作成

UnixおよびWindows 2008では、ASCRSは、WebLogic Server、OPMN管理対象インスタンス、Oracle Database、Oracle Databaseリスナー、仮想IPおよび共有ディスクをサポートします。これらの個別コンポーネントに対応するCRS管理対象リソースを作成し、そのリソースをCRSで管理できます。

ascrsctlコマンドラインでCRSリソースを作成する際、ネーミング規則が適用されます。リソースを適切に機能させるためには、このネーミング規則に従ってください。予期しないエラーを回避するために、CRSインストールはOracle Fusion Middleware専用にすることをお薦めします。それによって、すべてのCRS管理対象リソースがascrsctlで作成されます。

このネーミング規則では、正式なリソース名を次の形式にします。

ora.name.cfctype

nameは、リソースの短縮名(sharediskやmyvipなど)を表します。typeは、いずれかのリソース・タイプ(vip、disk、db、dblsnr、asなど)を表します。

たとえば、ネットマスクが255.255.255.0であるeth0ネットワーク・インタフェース上でIPアドレス192.168.1.10からora.myvip.cfcvipという仮想IPリソースを作成するには、次のコマンドを使用します。

ascrsctl create -name myvip -type vip -ipAddr 192.168.1.10 -netmask 255.255.255.0 -interface eth0

Windowsの場合:

ascrsctl create -name myvip -type vip -ipAddr 192.168.1.10 -netmask 255.255.255.0 -interface "Public network"

注意:

リソースが依存リソースを持つ場合、依存リソースのチェックの間隔を依存先のリソースのチェックの間隔以上に設定します。

13.4.1.1 仮想IPリソースの作成

仮想IPリソースを作成するには、次の情報が必要です。

- 有効な仮想ホスト名またはIPアドレスで、これらはネットワーク内の任意のホストで使用されていないものに限ります。

- このホスト名またはIPの有効なネットマスク番号

- 1つ以上の有効なネットワーク・インタフェース名で、このIPが使用されるすべてのクラスタ・ノードに存在します。Windowsでは、インタフェース名はネットワーク接続名と同じになります。

仮想IPリソースはシステム・リソースであるため、UNIXのcreateコマンドやupdateコマンドでスクリプトを生成して、これをrootユーザーが実行して操作を行う必要があります。

Linuxで仮想IPリソースora.myvip.cfcvipを作成するには、次の手順を実行します。

ascrsctl create -name myvip -type vip -ipAddr 192.168.1.10 -netmask 255.255.255.0 -interface eth0

13.4.1.2 共有ディスク・リソースの作成

Fusion Middleware環境において、共有ディスクは、Oracle Databaseソフトウェア、データベース・データファイル、WebLogic Server、OPMN管理対象サーバー、およびそれらのOracleホームを保持するディスク・ストレージです。共有ディスクにより、クラスタ内にある複数のノード間でアプリケーション・リソースが切り替えられても同じデータを使用できます。

共有ディスク・リソースを作成する際、次の考慮事項について入念に確認してください。

Unixの場合:

- 共有ディスク・リソースの作成前に、共有ディスクのルートに、.ascrssfという名前で空のシグネチャ・ファイルを作成します。CRSホームの所有者がこのファイルを所有する必要があります。このファイルは、リソースの作成後、CRSによって使用されます。

- マウント・コマンドとアンマウント・コマンドのどちらにも、nopを指定できます。共有ディスクが常時オンラインの場合は、マウント・コマンドでこれを使用できます。なんらかの理由でディスクがオフラインになると、CRSによって検出され、停止としてマーキングされます。CRSによってディスクをアンマウントする必要がない場合は、アンマウント・コマンドにnopコマンドを使用できます。この場合、ディスクがアンマウント不要であることを確認してください。共有ディスクが保護されずに2つのノードでマウントされると、ディスクが破損する場合があります。この場合も、共有ディスクには常にシグネチャ・ファイルが必要です。

- 共有ディスクを使用しているアクティブ・プロセスが存在する場合、マウント・コマンドが失敗することがあります。このコマンドの失敗を防止するには、このディスク・リソースがオンライン状態の間、他のアプリケーションでこのディスクにアクセスしないようにします。

- マウント・コマンドやアンマウント・コマンドが複雑な場合は、実行可能スクリプトにロジックをカプセル化し、マウント・コマンドやアンマウント・コマンドとして、スクリプトのフルパスを指定します。適切なアンマウント・スクリプトでは、このディスクを使用している他のプロセスを強制終了して、クリーンで正常なディスク・アンマウントを実行できます。アンマウント・コマンドをスクリプトに記述している場合、fsckコマンドを実行するなどして、基本的なファイル・システム・チェックを実行します。このようなスクリプトでは、成功すると0を返し、失敗すると1を返します。

- 共有ディスク・リソースはシステム・リソースです。create、updateまたはdeleteのコマンドでは、rootとして実行する必要があるスクリプトが生成され、作成操作を実行します。画面出力の指示に従ってください。

- シグネチャ・ファイルが共有ディスクのマウント・ポイントに存在すると、起動や停止の操作が失敗することがあります。シグネチャ・ファイルがマウント・ポイントに存在すると、実際にディスクがマウントされていなくても、マウントされているとASCRSでは認識されます。

- mcやumcのパラメータまたはスクリプト・ファイルでマウント・コマンドやアンマウント・コマンドを使用する前に、コマンドを検証してください。ASCRSではコマンドの検証は行われません。

- 共有ディスクがクラスタ・ファイル・システムで保護されていない場合、複数のノードでマウントされていると破損することがあります。これを回避するには、ASCRSリソースを作成する前に、リソースを作成したノード上でのみディスクをマウントします。

Windows Server 2008の場合:

- Microsoftディスク管理を開き、共有ディスク数を書き留めておきます。ディスク数は、0、2、5などの負でない整数です。

- 各クラスタ・ノードに、c:\oracle\asdiskなどの空のマウント・ディレクトリを作成します。

- このディスクがいずれのノードのいずれのアプリケーションでも使用されていないことを確認します。

- 1つのノードの「ディスク管理」で、ドライブを右クリックしそれをオンラインにして、このハード・ドライブに単一のパーティションを作成し、これをNTFSでフォーマットします。それに割り当てられている任意のドライブ文字を削除して、作成したばかりのディレクトリにそれをマウントします。再度ドライブを右クリックして、それをオフラインにします。

- それぞれのノードで、Microsoftディスク管理を開き、このドライブをオンラインにして、ドライブ文字があればそれを削除し、作成したばかりのディレクトリにそれをマウントします。ドライブを右クリックして、それをオフラインにします。

- ディスク・リソースを作成したノードに進み、ディスクをオンラインにします。

- ディスクのルートは、マウント・ディレクトリからアクセスできる必要があります。

- 共有ディスクのルートに、空のシグネチャ・ファイル.ascrssfを作成します。CRSホームの所有者がこのファイルを所有するようにします。このファイルは、リソースが作成された後で、CRSによって使用されます。

- マウント・コマンドは「diskmgr online disknumber」で、アンマウント・コマンドは「diskmgr offline disknumber」です。diskmgrはASCRSの組込みのコマンドです。diskmgrコマンドを使用するために、追加のソフトウェアをインストールする必要はありません。

共有ディスク・リソースを作成するには、Unix上で有効なマウント・ポイント、マウント・コマンドおよびアンマウント・コマンドを含む次のascrsctlコマンドを実行します。

ascrsctl create -n sharedisk -type disk -path /asdisk -mc "/bin/mount
/dev/sda /asdisk" -umc "/bin/umount /asdisk"

Windows Server 2008で共有ディスクを作成するには、次のようにascrsctlコマンドを実行します。

ascrsctl create -n sharedisk -type disk -path c:\oracle\asdisk -mc "diskmgr online 2" -umc
"diskmgr offline 2"

リソースを作成したら、createコマンドを実行するノード上でそれを明示的に起動し、すでにマウントされているディスクがASCRSの管理下にあることを確認します。

ascrsctl start -n ora.sharedisk.cfcdisk -node <disk resource creation node>

注意:

Windows Server 2008では、マップされたデバイスを共有ディスク・リソースとして使用することはできません。一般的なクラスタ・ファイル・システムでは、このような目的で動作することは保証されていません。

13.4.1.3 Oracle Databaseリスナー・リソースの作成

Oracleリスナー・リソースを作成するには、次の情報が必要です。

- 有効なOracle Databaseホーム

- リスナー名

- リスナー・アドレスの仮想IPリソース名

- Oracleホームのディスク・リソース名

データベース・リスナー・リソースを作成する前に、次の点を入念に確認してください:

- データベース・リスナー・ホームが共有ディスクにインストールされていること。ascrsctlコマンドで共有ディスクのCRSリソースが作成され、リソースが起動されていること。

- ascrsctlコマンドで仮想IPのCRSリソースが作成され、リソースが起動されていること。

- リスナーがコールド・フェイルオーバー・クラスタ(CFC)対応になっていること。詳細は、第12.2.5項「Oracle Databaseの変換」を参照してください。

- リスナー名およびOracleホームが有効なデータベースSIDおよびデータベース・ホームであることを確認します。このリリースでのこのタイプの情報を完全に検証する処理は、ASCRSでは実行されません。

- Windowsでは、リスナーWindowsサービスの開始方法が手動であることを確認します。

次に、リソースを作成する際の構文の例を示します。

ascrsctl create -n mydblsnr -type dblsnr -loh /cfcdb -ln LISTENER -disk ohdisk -vip myvip

Oracle Databaseリスナー・リソース作成に関するオンライン・ヘルプ情報を表示するには、次のコマンドを使用します。

ascrsctl help -c create -t dblsnr

13.4.1.4 Oracle Databaseリソースの作成

データベース・リソースは、次のいずれかのリソースになります。

- Oracle Databaseインスタンス

- Oracle Database Console(dbconsole)プロセス

- WindowsプラットフォームのOracleジョブ・スケジューラ・プロセス

- WindowsプラットフォームのOracle Volume Shadow Copy Service

Oracle Databaseインスタンス・リソースを作成するには、次のものが必要です。

- 有効なOracle Databaseホーム

- データベースSID名

- Oracleホームのディスク・リソース名

- ディスク・リソース名(データファイルが、異なる共有ディスクに存在する場合)

- リスナー・リソース名

Oracle Databaseインスタンス・リソースを作成する前に、次の考慮事項について入念に確認してください。

- Windowsでは、組込みのユーザー・システムはDBA_GROUPにあり、対応するWindowsサービスの開始方法が「手動」であることを確認してください。

- データベース・ホームが共有ディスクにインストールされています。同じ共有ディスクまたは異なる共有ディスクに、このデータベースのデータファイルが配置されています。ascrsctlでこれらすべての共有ディスクのCRSリソースが作成され、起動されています。

- ascrsctlコマンドでデータベース・リスナーのCRSリソースが作成され、リソースが起動されています。

- データベースはCFC対応です。詳細は、第12.2.5項「Oracle Databaseの変換」を参照してください。

- データベースSIDとOracleホームが有効であることを確認します。このリリースでこの情報を包括的に検証する処理は、ASCRSでは実行されません。

次に、データベース・インスタンス・リソースを作成する際の構文の例を示します。

ascrsctl create -n mydb -type db -oh /cfcdb -lsnr mydblsnr -oraSID sid -disk ohdisk datadisk

その他すべてのデータベース・リソースを作成するには、次のものが必要です。

- 有効なOracle Databaseホーム

- データベースSID名

- Oracleホームのディスク・リソース名

- 有効な仮想IPリソース名。これは、Oracle Database Console(dbconsole)データベース・リソースのみに必要です。

- データベースはCFC対応です。

Oracle Databaseリソース作成に関するオンライン・ヘルプ情報を表示するには、次のコマンドを使用します。

ascrsctl help -c create -t db

13.4.1.5 Middlewareリソースの作成

OPMNインスタンスおよびWebLogicサービスは、まとめてアプリケーション・サーバー(AS)コンポーネントと呼ばれており、個別のリソースで管理されます。特に、すべてのOPMN管理対象コンポーネントは1つのリソースで管理し、WebLogicドメイン配下のすべてのサーバーは別のリソースで管理する必要があります。

13.4.1.5.1 OPMN管理対象コンポーネントのリソースの作成

OPMN管理対象インスタンスのリソースを作成するには、次の情報が必要です。

- OPMN管理対象コンポーネントの有効なインスタンス・ホーム

- インスタンス・ホームのディスク・リソース名

- インスタンスのOracleホームのディスク・リソース名(異なる共有ディスクにある場合)

- リソースに含めるOPMN管理対象アプリケーションの名前。すべてのコンポーネントのサブセットのみを含める場合は、残りのコンポーネントはCRSで管理されないので外部のCRSで起動しないでください。デフォルトでは、すべてのコンポーネントが含まれます。

OPMNリソースを作成する前に、次の点を入念に確認してください:

- Oracleホームが共有ディスクにインストールされています。OPMNインスタンスが同一または異なる共有ディスクにあります。ascrsctlでこれらすべての共有ディスクのCRSリソースが作成され、起動されています。すべてのOPMN管理対象アプリケーションをシャットダウンします。

- OPMNサーバーとその管理対象のOracle Fusion Middlewareコンポーネントは、CFCに対応しています。Oracle Fusion MiddlewareコンポーネントでCFCを有効にする手順の詳細は、第12.2.3.8項「Oracle Process Management and Notification Serverの変換」から第12.2.3.11項「インスタンス固有の考慮事項」および第12.2.4項「Oracle Fusion Middlewareコンポーネントの変換」を参照してください。

- Windowsでは、このインスタンスに関するOPMN Windowsサービスの開始方法が「無効」であることを確認してください。

次に、リソースを作成する際の構文の例を示します(Oracleホームとインスタンス・ホームは、同じディスク上にあります。すべてのコンポーネントが含まれます。):

ascrsctl create -n myopmn -type as -ch /cfcas -disk ohdisk

OPMNインスタンス・リソース作成に関するオンライン・ヘルプ情報を表示するには、次のコマンドを使用します。

ascrsctl help -c create -t as

13.4.1.5.2 WebLogic Serverのリソースの作成

WebLogicドメインのCRSリソースを作成する場合、他のタイプのリソースを作成する場合よりも多くの準備が必要です。準備が複雑なため、その手順を次の項に分割します。

- 基本設定

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

- WebLogic Serverの設定

- リソースの作成

基本設定

基本設定の開始前に、WebLogicが共有ディスクにインストールされていることを確認してください。WebLogic Serverソフトウェアとドメイン・インスタンスは、同じ共有ディスクにでも別々の共有ディスクにでもインストールできます。

また、次のノード・マネージャおよびサーバーの設定処理を進める前に、WebLogic Server環境でCFCが有効であることを確認してください。Oracle WebLogic Server環境でのCFCの有効化の詳細については、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」から第12.2.3.7項「ノード・マネージャの変換」を参照してください。CFCが有効にされていると、サーバー、元のノードおよびフェイルオーバー・ノードを、顕著な相違なしに手動で起動や停止ができます。

依存リソースを作成する手順は次のとおりです。

1. 各共有ディスクのCRSリソースを作成し、作成場所のノードでリソースを起動します。

2. ascrsctlコマンドで仮想IPのCRSリソースを作成し、同じクラスタ・ノードでリソースを起動します。

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

ノード・マネージャを設定する手順は次のとおりです。

1. Windows Server 2008では、各ノードにノード・マネージャのWindowsサービスがない場合、WL_HOME/server/binディレクトリから次のコマンドを実行してそれを作成します。

installNodeMgrSvc.cmd

Windows Service Managerで、このサービスが手動の起動モードであることを確認します。

2. ノード・マネージャのユーザー名とパスワードが変更されていない場合は、それらを変更します。初期パスワードはランダムに生成されます。ノード・マネージャのパスワードを変更するには、管理コンソールで「ドメイン」、「セキュリティ」、「一般」、「詳細」の順に選択します。新しいパスワードを入力して「保存」をクリックします。

3. ステップ1またはステップ2でなんらかの変更を行った場合、ノード・マネージャを再起動します。
Unixでは、WL_HOME/server/binディレクトリから次のコマンドを使用します。

startNodemanager.sh

Windowsでは、サービス・マネージャからノード・マネージャを起動します。

4. WL_HOME/common/binディレクトリにあるWebLogic Scripting Toolを起動します。ascrscf.datファイルとascrskf.datファイルにノード・マネージャのユーザー・ログイン情報を永続保持するため、次のコマンドを使用します。

nmConnect('nmUser','nmPasswd','hostname','nmPort','domainName','domainDir')
storeUserConfig('WL_HOME/common/nodemanager/ascrscf.dat',
'WL_HOME/common/nodemanager/ascrskf.dat','true')
nmDisconnect()
exit()

5. Unixプラットフォームでは、CRS_HOME/ascrs/public/cfcStartNodeManager.shをWL_HOME/server/binディレクトリにコピーして、スクリプトを実行可能にします。

注意:

設定を常に同期するため、ノード・マネージャのパスワードやユーザー名を変更するたびにステップ4の操作を実行する必要があります。

ノード・マネージャを初めて起動した後で、nodemanager.propertiesファイルを編集してStartScriptEnabledプロパティを定義できます。nodemanager.propertiesファイルは、ノード・マネージャを初めて起動するまでは存在していません。

WL_HOME/common/nodemanagerディレクトリで、nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定します。

StartScriptEnabled=true

nodemanager.propertiesファイルをチェックして、ListenAddressに値が割り当てられていないことと、ListenPortに有効なポート番号が割り当てられていることを確認します。

このプロパティがnodemanager.propertiesファイルで設定されている場合には、同じプロパティをJAVA_OPTIONS環境変数で定義する必要はなくなります。

WebLogic Serverの設定

注意:

次の手順は、Oracle Clusterwareによって管理されるすべてのWebLogic Serverの設定に適用されます。

1. すべてのWebLogicサーバーは仮想IPでリスニングします。これが適切に構成されていることを確認するには、管理コンソールにログインし、「環境」→「サーバー」→server_name→「構成」→「一般」ページに移動し、仮想IPとポート番号の両方が適切に設定されていることを確認して、「保存」をクリックします。

2. 各サーバーはローカル・ホスト上でもリスニングする必要があります。これが正しく構成されていることを確認するには、管理コンソールにログインして次の操作を行います。

1. ドメイン・ツリーで、「環境」→「サーバー」→「server_name」→「プロトコル」→「チャネル」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「新規」をクリックしてチャネル名とt3プロトコルを選択し、次の画面に進みます。

4. 「リスニング・アドレス」と「外部リスニング・アドレス」の両方に対して、localhostと入力します。

5. 「リスニング・ポート」と「外部リスニング・ポート」にポート番号を入力します。このポート番号は、仮想IPのポート番号と正確に同じにする必要があります。

6. 次の画面に進んで、「有効」が選択されていることを確認します。

7. 「終了」をクリックします。

8. 「変更のアクティブ化」をクリックします。

3. これが管理サーバーの場合、DOMAIN_HOME/servers/serverName/securityディレクトリが存在することを確認します。このディレクトリにはboot.propertiesファイルが格納されている必要があります。このファイルが存在しない場合は作成して、次のプロパティを含めます。

username=<admin server user name>
password=<admin server user password>

4. ドメインに管理サーバーがない場合、DOMAIN_HOME/servers/serverName/securityディレクトリが存在することを確認します。このディレクトリにはboot.propertiesファイルが格納されている必要があります。このファイルが存在しない場合は作成して、次のプロパティを含めます。

username=<admin server user name>
password=<admin server user password>

5. DOMAIN_HOME/servers/serverName/data/nodemanager/startup.propertiesが存在する場合は、このファイルで定義されているAutoRestartプロパティがfalseに設定されていることを確認します。

6. すべてのサーバーについて前の手順を繰り返して、管理サーバー・コンソールですべてのサーバーを再起動します。

7. すべてのWebLogicプロセスを停止して、ノード・マネージャを強制終了します。

注意:

設定を常に同期するため、管理サーバーのパスワードを変更するたびにステップ3の操作を実行する必要があります。

リソースの作成

基本設定、ノード・マネージャの設定およびサーバーの設定を実行したら、次のコマンドを使用してCRSリソースを作成します。

ascrsctl create -n mywls -type as -ch /cfcas -disk sharedisk -vip myvip

注意:

WebLogicコンポーネントのホーム引数(-ch)は有効である必要があります。この情報を包括的に検証する処理は、ASCRSでは実行されません。

注意:

デフォルトでは、ASCRSエージェントはサーバーへのTCP接続を定期的に初期化してWebLogic Serverのヘルス・チェックを実行します。この動作を変更する場合は、第13.4.8項「ヘルス・モニターの構成および使用」を参照してください。

13.4.2 リソースの更新

ascrsctlで作成したリソースは、updateコマンドを使用して更新できます。リソースのタイプに応じて、updateコマンドラインで適切なパラメータを指定することでリソース・プロファイルを更新できます。更新は、リソースがオフラインの状態の場合にのみ実行できます。

たとえば、前述の項で作成した仮想IPリソースを新しいIPアドレスと別のインタフェースで更新するには、次のコマンドを使用します。

ascrsctl update -n myvip -type vip -ip 192.168.1.20 -if eth1

注意:

特定のリソースをホストするノードのセットを変更する場合、すべての依存リソースを停止してそれぞれのリソースが同じノード・セットと順序になるようにクラスタ・ノードを更新する必要があります。関連するリソースを検索するには、このリソースに対してascrsctlのstatusコマンドを実行します。

13.4.3 リソースの起動

リソースが起動されると、CRSに制御され、実行時の状態がCRSによって継続的に監視されます。リソースが他のリソースに依存する場合、そのリソースを起動すると、依存先のリソースが自動的に起動されます。リソース起動時のリソース配置ポリシーの役割の詳細は、Oracle Clusterwareのドキュメントを参照してください。ascrsctlのstartコマンドはCRSコマンドにマッピングされます。

たとえば、仮想IPリソースを起動するには、次のコマンドを使用します。

ascrsctl start -n ora.myvip.cfcvip

注意:

リソースが複数のリソースに依存する場合は、そのリソースの起動時に、それらのリソースがオンラインになった場合、同じノードにターゲット指定されることを確認します。

13.4.4 リソースの停止

リソースを停止すると、そのリソースはオフライン状態になり、CRSはその実行状態の監視を停止します。そのリソースがオンライン状態の他のリソースに依存している場合、プロンプトで確認するか(-np)オプションを指定しないと依存リソースは停止しません。リソース停止時におけるリソース依存性の影響の詳細は、Oracle Clusterwareのドキュメントを参照してください。ascrsctlのstopコマンドは、CRSコマンドのcrs_stopにマッピングされます。

たとえば、仮想IPリソースを停止するには、次のコマンドを実行します。

ascrsctl stop -n ora.myvip.cfcvip

13.4.5 リソースのスイッチオーバー

リソースのスイッチオーバーは、ノード上で実行しているリソースを停止してから別のノード上で再起動するプロセスです。新しいノードが指定されていない場合、配置ポリシーに基づいてCRSによって決定されます。スイッチ対象リソースが他のリソースに依存している場合や、オンライン状態のリソースがありそれらのリソースがスイッチ対象リソースに依存している場合、-npフラグでこのリソースのスイッチ操作を実行する必要があります。

クラスタ内で利用可能な別のノードにリソースをスイッチオーバーするには、次のコマンドを実行します。

ascrsctl switch -n ora.myvip.cfcvip

13.4.6 リソースの削除

リソースをCRSの制御から削除できます。リソースを削除すると、対応するアプリケーションやコンポーネントの機能はCRSの影響を受けなくなり、CRSはそれ以降そのリソースを監視しません。依存リソースを持つリソースは削除できません。

CRSの制御からリソースを削除するには、次のコマンドを実行します。

ascrsctl delete -n ora.myvip.cfcvip

注意:

CRSからリソースを削除すると、削除されたリソースのログ・ディレクトリおよびログ・ファイルは自動的には削除されません。今後これらを使用しない場合は、手動で削除する必要があります。ログ・ファイルは、デフォルトでは、ORA_CRS_HOME/ascrs/logディレクトリに格納されます。

13.4.7 リソース・ステータスのチェック

ascrsctlのstatusコマンドを使用して、リソースのステータスをチェックできます。このコマンドにより、すべてのリソースとその依存リソースの状態を表示できます。特定のリソースを指定してstatusコマンドを実行すると、そのCRSプロファイル、直接的な依存関係や間接的な依存関係、および現在の状態に関する情報が表示されます。

たとえば、リソースのステータスをチェックするには、次のコマンドを実行します。

ascrsctl status -n ora.myvip.cfcvip

この仮想IPリソースがデータベース・リスナー・リソースによって使用されているときに、このリスナー・リソースがデータベース・インスタンス・リソースによって必要とされている場合、次のようなステータス出力に、他のステータス情報とともにすべての依存性情報がツリー構造で表示されます。

Basic information
------------------------+------------------------
Name                  |  ora.myvip.cfcvip
Type                  |  Virtual IP
Target state          |  ONLINE
Resource state        |  ONLINE on stajz11
Restart count         |  0
Failure count         |  0
Hosting members       |  stajz11, stajz12
------------------------+------------------------

Common CRS parameters
------------------------+------------------------
Auto start            | Yes
Check interval        | 7 sec
Failover delay        | 5 sec
Failure interval      | 50 sec
Failure threshold     | 5
Restart attempts      | 2
Script timeout        | 30 sec
Start timeout         | 30 sec
Stop timeout          | 30 sec
------------------------+------------------------

Resource specific parameters
------------------------+------------------------
Interface(s)          | eth2
Netmask               | 255.255.252.0
Virtual IP address    | 140.87.27.48
------------------------+------------------------

Resource dependency tree(s)
-------------------------------------------------
ora.mydb.cfcdb
|
+->ora.mydisk.cfcdisk
|
+->ora.mylsnr.cfcdblsnr
|
+->ora.mydisk.cfcdisk
|
+->ora.myvip.cfcvip

ora.myopmn.cfcas
|
+->ora.mydisk.cfcdisk
|
+->ora.myvip.cfcvip

ora.dbc.cfcdb
|
+->ora.mydisk.cfcdisk
|
+->ora.myvip.cfcvip

ora.mywls.cfcas
|
+->ora.mydisk.cfcdisk
|
+->ora.myvip.cfcvip

13.4.8 ヘルス・モニターの構成および使用

リソースのヘルス状態は、CRSの再起動またはフェイルオーバーの決定において最も重要な情報です。ただし、サーバーの実際の状態を正確に特定することは容易な作業ではありません。たとえば、サーバー・プロセスが実行中でも実際にそのサービスが停止している状況があります。この場合、単にWebLogic ServerにTCP pingを実行しても、必ずしも正しい機能状態が通知されることにはなりません。かわりに、ASCRSではユーザー定義のモニターを介してWebLogic Serverの機能状態をチェックする限定的なサポートを提供します。

すべてのモニターはORA_CRS_HOME/ascrs/config/mconfig.xmlで定義されます。次にこのファイルの例を示します。

<monitors>

<!-- HTTP code monitor -->
<monitor name="http_cm">
<method type="ping" protocol="http" url="/index.html"/>
<result type="code" code="200"/>
</monitor>

<!-- HTTP response content monitor that checks the response of a particular
URL -->
<monitor name="http_rcm">
<method type="ping" protocol="http" url="/index.html"/>
<result type="exact_content" file="/crs/ascrs/public/index_content.txt"/>
</monitor>

<!-- HTTP response content monitor that checks the desired pattern in any line
of the returned content -->
<monitor name="http_regex">
<method type="ping" protocol="http" url="/cqi"/>
<result type="regex_content"><![CDATA[.+Welcome.+]]></result>
</monitor>

<!-- WebLogic callout script monitor -->
<monitor name="wls_sm">
<method type="script" command="/var/scripts/wlsrv3_checker.sh"/>
<result type="code" code="0"/>
</monitor>
</monitors>

各モニターで、methodとresultの両方を定義する必要があります。「method type」は、pingまたはscriptを指定できます。pingメソッドにはhttpプロトコルのみがサポートされ、有効なURLが必要です。「result type」は、code、exact_content、またはregex_contentのいずれかになります。httpプロトコルのpingの結果のコードで、想定されるHTTPリターン・コードを参照し、exact_contentおよびregex_contentで、正確な戻り値の内容と想定されるパターンを1行で指定します。

WebLogic Serverのモニターを使用するには、その作成または更新時に-mオプションを指定してモニター名をサーバー名に割り当てる必要があります。

たとえば、WebLogicリソースにAdminServerとwlsappという2つのサーバーがあるとすると、次のコマンドを使用してそのモニターをカスタマイズできます。

ascrsctl create -n mywls -type as -ch /cfcas -disk sharedisk -vip myvip -m
AdminServer=http_cm wlsapp=http_rcm

注意:

exact_contentメソッドを使用する場合、CRS_HOME/ascrs/bin/muユーティリティを使用して想定されるレスポンス・コンテンツのファイルを生成します。ブラウザで保存されるコンテンツは、サーバーから送信されたテキストと正確に一致しない場合がしばしばあるためです。

13.5 トポロジの例

次の2つの例では、ASCRSを使用してFusion Middlewareリソースを管理する方法を示します。

図13-1 CRSトポロジの例1

「図13-1 CRSトポロジの例1」の説明

図13-1に、CRSトポロジの例1を示します。この例では、2ノードのクラスタにOracle HTTP ServerとSOAがインストールされています。Oracle HTTP ServerはOPMNで管理されます。SOAインストールでは、4つのJava EEアプリケーションをホストするWebLogic Serverが稼働します。

前提事項:

- 動作環境: これは2ノードのLinuxクラスタで、そのメンバーはnode1.company.comとnode2.company.comです。ノード1は1次ノードとして指定され、ノード2はフェイルオーバー・ノードです。両方のノードの/crshomeディレクトリにCRSがインストールされ、起動されています。両方のノードでASCRSがインストールおよび構成されています。

- Oracle HTTP Server(Oracleホームおよびインスタンス・ホーム)とWebLogicインストール(SOAサーバーのサーバー・ソフトウェアおよびドメイン・ホーム)用に1台の共有ディスクが割り当てられています。これは/dev/sda1で識別されるSCSIドライブであり、ext2ファイル・システムが格納されています。これは/sharedisk1にマウントされます。この共有ディスクは、他の目的で使用されないことが前提になります。

- Oracle HTTP ServerおよびWebLogicは、パブリック・リスニング・アドレスとして仮想IPの192.168.1.10を使用します。各ノードで、仮想IPのバインドでは2つのネットワーク・インタフェース・コントローラのeth0とeth1が利用可能です。ネットマスクは255.255.255.0です。

- Oracle HTTP ServerのOracleホームは/sharedisk1/ohsohです。インスタンス・ホームは/sharedisk1/ohinstです。

- WebLogic Serverソフトウェアは/sharedisk1/fmwディレクトリにインストールされています。ドメイン・ディレクトリは/sharedisk1/fmw/user_projects/domains/asdomainです。

これらの前提の下で、コールド・フェイルオーバー・クラスタの自動設定について説明します。

1. 次の手順に従って、WebLogicソフトウェアをインストールし、コールド・フェイルオーバー・クラスタを有効にします。

1. ノード2に共有ディスク/dev/sda1がマウントされていれば、それをアンマウントします。ノード1の/shareddisk1に共有ディスクがマウントされていなければ、それをマウントします。

2. 空のシグネチャ・ファイル.ascrssfを/shareddisk1に作成します。このファイルを作成するのは、この共有ディスクのマウント後のみです。

3. /sbin/ifconfigを使用して仮想IPをeth0にバインドします。

4. SOAおよびOHSを共有ディスクにインストールします。仮想IPを使用して、SOAおよびOHSの両方に対してCFCを有効化する手順を実行します。CFCを有効にしたら、SOAサーバーおよびOHSインスタンスに属するすべてのプロセスをシャットダウンします。CFCの有効化の基本的なチェックを実行するには、ノード1上の共有ディスクをアンマウントしてそれをノード2にマウントし、ノード2でSOAとOHSの起動を試行します。起動に失敗したら、続行する前にそれを修正します。

5. ステップ3を実行したら、すべてのOHSおよびSOAプロセスをシャットダウンし、ノード2のディスクをアンマウントして、それをノード1にマウントします。

6. 第13.4.1.5.2項「WebLogic Serverのリソースの作成」の手順(リソースの作成手順を除く)に従って、SOAインストール内のWebLogicサーバーをASCRS用に構成します。

7. 任意のOHSおよびSOAプロセスをシャットダウンします。

8. 仮想IPをアンバインドします。

2. CRSリソースを作成します。

1. ノード1で、cdコマンドを使用して、/CRS_HOME/ascrs/binディレクトリに移動します。

2. 仮想IPリソースを作成します。

ascrsctl create -n asvip -t vip -if "eth0|eth1" -ip 192.168.1.10 -nm 255.255.255.0

3. 共有ディスク・リソースを作成します。

ascrsctl create -n asdisk -t disk -path /sharedisk1
-mc "/bin/mount /dev/sda1/sharedisk1"
-umc "/bin/umount /sharedisk1"

4. SOA WebLogic Serverリソースを作成します。

ascrsctl create -n soa -t as -vip asvip -disk asdisk
-ch /sharedisk1/fmw/user_projects/domains/asdomain

5. その依存性としてSOAを含むOracle HTTP Serverリソースを作成します。

ascrsctl create -n ohs -t as -vip asvip -disk asdisk -as soa -ch /sharedisk1/ohsinst

6. ノード1上のすべてのリソースを起動します。Oracle HTP Serverリソースはその他すべてのリソースに依存するため、このリソースを起動すると自動的に他のリソースも起動します。

ascrsctl start -n ora.ohs.cfcas -node node1

図13-2 CRSトポロジの例2

「図13-2 CRSトポロジの例2」の説明

図13-2に、CRSトポロジの例2を示します。このトポロジ例では、次の特性を持つ2ノード構成クラスタに、WebLogic ServerとOracle Databaseがインストールされています。

- このクラスタで実行されるWebLogic Serverは、WebLogic管理サーバーのみです。WebLogicソフトウェアとドメイン・ホームは同じ共有ディスク上に配置されています。

- 管理サーバーおよびOracle Enterprise Managerは、最初のノードを1次ノードとして、WebLogic Java EEコンテナで実行されます。

- データベース・ソフトウェアとそのデータファイルは、2番目のノードを1次ノードとして、他の2台の共有ディスクに配置されています。

このトポロジの目的は、WebLogic管理サーバーとデータベース・インスタンスの両方のフェイルオーバー・ソリューションを実現することです。

前提事項:

- 動作環境: これは2ノードのLinuxクラスタで、そのメンバーはnode1.company.comとnode2.company.comです。ノード1はWebLogic Serverの1次ノードとして指定され、ノード2はこのフェイルオーバー・ノードとなっています。ノード2はOracle Databaseの1次ノードとして指定され、ノード1はこのフェイルオーバー・ノードとなっています。両方のノードの/crshomeディレクトリに、CRSがインストールされ、起動されています。両方のノードでASCRSがインストールおよび構成されています。

- 3台の共有ディスクが割り当てられています。いずれもSCSIドライブで、それぞれ/dev/sda1、/dev/sda2、/dev/sda3として識別され、ext2ファイル・システムが格納されています。/dev/sda1はWebLogicソフトウェアで使用されます。

- ドメイン・ホーム: /dev/sda2はOracle Databaseソフトウェアで使用されます。/dev/sda3はデータベース・データファイルで使用されます。それらはそれぞれ、/sharedisk1、/sharedisk2、/sharedisk3にマウントされます。

- WebLogic Serverは、パブリック・リスニング・アドレスに仮想IPの192.168.1.10を使用し、リスニング・ポートに7001を使用しています。各ノードで、この仮想IPのバインドでは2つのネットワーク・インタフェース・コントローラのeth0とeth1が利用可能です。
データベース・リスナーは、リスニング・アドレスに仮想IPの192.168.1.20を使用し、リスニング・ポートに1521を使用しています。各ノードで、この仮想IPのバインドにネットワーク・インタフェース・コントローラのeth2を使用します。

両方の仮想IPのネットマスクは255.255.255.0です。

- WebLogic Serverは共有ディスクの/sharedisk1/fmwディレクトリにインストールされています。ドメイン・ディレクトリは/sharedisk1/fmw/user_projects/domains/asdomainです。

- データベースは共有ディスクの/sharedisk2/dbhomeディレクトリにインストールされており、データファイルは/sharedisk3/dbdataディレクトリに作成されます。ここでは、orclはOracle SID名、LISTENERはリスナー名であることが前提になります。

これらの前提の下で、コールド・フェイルオーバー・クラスタの自動設定について説明します。

1. WebLogicソフトウェアをインストールしてコールド・フェイルオーバー・クラスタを有効にします。

1. ノード2に共有ディスク/dev/sda1がマウントされていれば、それをアンマウントします。ノード1の/shareddisk1に共有ディスクがマウントされていなければ、それをマウントします。

2. 空のシグネチャ・ファイル.ascrssfを/shareddisk1に作成します。このファイルを作成するのは、この共有ディスクのマウント後のみです。

3. /sbin/ifconfigを使用して仮想IPの192.168.1.10をeth0にバインドします。

4. WebLogicを共有ディスクにインストールします。この仮想IPを使用して、このインストールにコールド・フェイルオーバー・クラスタの有効化手順を実行します。

5. ASCRSでのWebLogic Serverの構成の詳細は、第13.4.1.5.2項「WebLogic Serverのリソースの作成」を参照しください。

6. WebLogic Serverをシャットダウンします。

7. 仮想IPをアンバインドします。

2. WebLogic関連のリソースを作成します。

1. ノード1に移動し、cdコマンドを使用して、/CRS_HOME/ascrs/binディレクトリに移動します。

2. 仮想IPリソースを作成します。

ascrsctl create -n asvip -t vip -if "eth0|eth1" -ip 192.168.1.10 -nm 255.255.255.0

3. 共有ディスク・リソースを作成します。

ascrsctl create -n asdisk -t disk -path /sharedisk1
-mc "/bin/mount /dev/sda1 /sharedisk1" -umc "/bin/umount /sharedisk1"

4. WebLogic Serverリソースを作成します。

ascrsctl create -n adminserver -t as -vip asvip -disk asdisk        -ch /sharedisk1/fmw/user_projects/domains/asdomain

5. ノード1上のすべてのWebLogic関連のリソースを起動します。WebLogicリソースはディスクおよび仮想IPリソースに依存するため、WebLogicリソースを起動すると自動的に他の2つも起動します。

ascrsctl start -n ora.adminserver.cfcas -node node1

3. Oracle Databaseソフトウェアをインストールしてコールド・フェイルオーバー・クラスタを有効にします。

1. ノード1に共有ディスク/dev/sda2がマウントされていれば、それをアンマウントします。ノード2の/shareddisk2に共有ディスクがマウントされていなければ、それをマウントします。

2. 空のシグネチャ・ファイル.ascrssfを/shareddisk2に作成します。このファイルを作成するのは、この共有ディスクのマウント後のみです。

3. ノード1に共有ディスク/dev/sda3がマウントされていれば、それをアンマウントします。ノード2の/shareddisk3に共有ディスクがマウントされていなければ、それをマウントします。

4. 空のシグネチャ・ファイル.ascrssfを/shareddisk3に作成します。このファイルを作成するのは、この共有ディスクのマウント後のみです。

5. /sbin/ifconfigを使用して仮想IPの192.168.1.20をeth2にバインドします。

6. /sharedisk2/dbhomeディレクトリにOracle Databaseをインストールして、データファイルを/sharedisk3/dbdataに配置します。

7. この仮想IPで、このインストールにCFCの有効化手順を実行します。

8. データベースをシャットダウンします。

9. 仮想IPをアンバインドします。

4. Oracle Database関連のリソースを作成します。

1. ノード2で、cdコマンドを使用して、/CRS_HOME/ascrs/binディレクトリに移動します。

2. 仮想IPリソースを作成します。

ascrsctl create -n dbdisk -t disk -path /sharedisk2
-mc "/bin/mount /dev/sda2
/sharedisk2" -umc "/bin/umount /sharedisk2"

3. データベース・ソフトウェアの共有ディスク・リソースを作成します。

ascrsctl create -n dbdisk -t disk -path /sharedisk2
-mc "/bin/mount /dev/sda2
/sharedisk2" -umc "/bin/umount /sharedisk2"

4. データベース・データファイルの共有ディスク・リソースを作成します。

ascrsctl create -n dfdisk -t disk -path /sharedisk3
-mc "/bin/mount /dev/sda3
/sharedisk3" -umc "/bin/umount /sharedisk3"

5. データベース・インスタンス・リソースを作成します。

ascrsctl create -n asdblsnr -t lsnr -vip dbvip
-disk dbdisk -loh /sharedisk2/dbhome -ln LISTENER

6. データベース・リスナー・リソースを作成します。

ascrsctl create -n asdb -t db -lsnr asdblsnr -sid orcl
-oh /sharedisk2/dbhome -disk dbdisk dfdisk

7. ノード2上のすべてのデータベース関連リソースを起動します。データベース・リソースは直接的または間接的にその他すべてのリソースに依存するため、データベース・リソースを起動すると自動的に他のリソースも起動します。

ascrsctl start -n ora.asdb.cfcdb -node node2

13.6 Oracle CRSのトラブルシューティング

この項では、Oracle CRSのトラブルシューティング情報について説明します。

13.6.1 仮想IPリソースに依存するOPMNリソース

OPMNリソースは仮想IPリソースに依存しますが、作成または更新処理時にASCRSはOPMNインスタンスが依存している仮想IPリソースが実際に存在しているかどうかを検証していません。不正な仮想IPリソースが指定されていると、OPMNリソースは起動に失敗して、OPMNインスタンスは不整合な状態で残ることがあります。この問題を修正するには、次の手順に従ってください。

1. -fオプションを使用してOPMNリソースを停止します。

2. すべての関連リソースが停止していることを確認します。停止していなければ、残りの稼働中のプロセスをすべて手動で停止します。

3. リソースを正しい仮想IPリソースで更新します。

4. リソースを起動します。

13.6.2 ASCRSロギング

ASCRSでは、ロギングに基づいて、予期しない問題が診断されます。より多くの診断情報を取得するには、ASCRS構成ファイルconfig.xmlを変更してログ・レベルの冗長性を高くできます。ASCRSロギング・レベルを変更する方法の詳細は、第13.3.3項「Oracle Fusion MiddlewareでのASCRSの構成」を参照してください。

また、CRSの基本的な問題について、CRSデーモンのログもチェックできます。

14 Oracle Portal、Forms、ReportsおよびDiscovererの高可用性の構成

この章では、Oracle Portals、Forms、ReportsおよびDiscovererの高可用性の概要と構成手順について説明します。この章の項目は次のとおりです。

- 第14.1項「Oracle Portal、Forms、ReportsおよびDiscovererの概要」

- 第14.2項「Oracle Portalと高可用性の概要」

- 第14.3項「Oracle Reportsと高可用性の概要」

- 第14.4項「Oracle Formsと高可用性の概要」

- 第14.5項「Oracle Discovererと高可用性の概要」

- 第14.6項「高可用性のためのOracle Portal、Forms、ReportsおよびDiscovererの構成」

14.1 Oracle Portal、Forms、ReportsおよびDiscovererの概要

Oracle Portalにより、Oracle Fusion Middlewareと緊密に統合されたポータルを構築、デプロイおよび管理するための完全なポータル・フレームワークが実現されます。

Oracle Portalを使用すると、Oracle WebCenter Contentによるエンタープライズ・コンテンツ管理機能によりデプロイメントを拡張できます。さらに、Oracle WebCenterポータル・サービスを使用して既存のポータルにEnterprise 2.0機能を追加できます。Oracle Portalでは、これらの補完的なソリューションの両方との相互運用性と、Oracleエンタープライズ・アプリケーションおよび他のOracle Fusion Middlewareコンポーネントとの相互運用性が確認されています。

Oracle Portalを実装すると、多くの場合、それが組織のインターネットまたはイントラネットのエントリ・ポイントとなるため、できるかぎり高い可用性を持たせることが不可欠です。

Oracle Formsは、エンタープライズ・アプリケーションを迅速で効率的に設計し構築するために、オラクル社で長い歴史において確立されているテクノロジです。

Oracle Reportsサービスは、Oracle Fusion Middlewareのレポート・パブリッシング・コンポーネントです。これは、高品質の稼働レポートを生成するためのエンタープライズ・レポート作成サービスです。これによって、任意のデータを動的に取得し、任意の形式で書式設定し、任意の場所で配布します。Oracle Reportsサービスを使用して、Webベースと非Webベースの両方の環境で公開できます。

Oracle Discovererは、データ分析用のビジネス・インテリジェンス・ツールです。これは、Oracle Fusion Middlewareの重要なコンポーネントです。Discovererは、直感的な非定型問合せ、レポート作成、分析およびWebパブリッシングの各機能を備えた統合ビジネス・インテリジェンス・ソリューションです。これらのツールにより、技術的な知識のないユーザーが、データ・マート、データ・ウェアハウス、マルチディメンショナル(OLAP)データ・ソースおよびオンライン・トランザクション処理システムの情報に直接アクセスできるようになります。Discovererは、Oracle PortalおよびOracle WebCenterポータルとシームレスに統合されるため、Discovererのワークブックおよびワークシートを各Webポータルに迅速にデプロイできます。

Oracle Portal、Forms、ReportsおよびDiscovererは、個別にインストールすることも、まとめてインストールすることもできます。

14.1.1 Oracle Portal、Forms、ReportsおよびDiscovererのアーキテクチャ

図14-1は、単一インスタンスのOracle Portal、Forms、ReportsおよびDiscovererのデプロイメントを示しています。

図14-1 Oracle Portal、Forms、ReportsおよびDiscovererのアーキテクチャ

「図14-1 Oracle Portal、Forms、ReportsおよびDiscovererのアーキテクチャ」の説明

Oracle Portal、Forms、ReportsおよびDiscovererの一般的なコンポーネント

図14-1には、次の一般的なコンポーネントが含まれています。

- Oracle Web Cacheは2つの機能を実行します。そのプライマリ機能により、そのキャッシュから静的Webコンテンツが、Oracle HTTP Server単体の場合よりも高速に渡されます。Oracle Web Cacheのキャッシュにキャッシュ可能ページがない場合、つまりそのページが最新のページではない場合は、接続されたOracle HTTP Serverにそのページへのリクエストが実行されます。
Oracle Web Cacheの2番目の機能は、高可用性環境で使用されます。これはリクエストを受け取り、それ自体のキャッシュからそのリクエストに対応できない場合、複数のOracle HTTP Serverの間でロード・バランシングできます。

Oracle Web Cacheはオプションですが、Oracle Forms、ReportsおよびDiscovererとともに使用できます。

- Oracle HTTP Serverはリクエストされたページのアセンブルを行います。ページ・アセンブリは常に直接的に実行されるとはかぎりません。ページの構成方法に応じて、Oracle HTTP Serverでは次のいずれかが実行されます。

- ページが単純なHTMLドキュメントである場合、Web層によってドキュメントが検索されて返されます。

- Java EEアプリケーションを実行してアセンブルすることが必要なWebページである場合、Oracle Web TierによってリクエストがOracle WebLogic Serverにルーティングされ、リクエストはそこで処理された後、その結果がOracle Web Tierを経由してユーザーに返されます。

- PLSQLやCGIなど他のアプリケーションを実行してアセンブルすることが必要なWebページである場合は、リクエストはOracle Web Tierによって適切なアプリケーションにルーティングされ、そのアプリケーションによって処理された後、その結果がOracle Web Tier経由でユーザーに返されます。

- リクエストされたページがセキュリティで制御されている場合、Oracle Web ServerによってOracle Identity Managementが呼び出され、そのページを表示する権限がユーザーにあるかどうかが確認されます。

Oracle HTTP Serverは、スタンドアロンで使用することもOracle Web Cacheとともに使用することもできます。

Oracle Portal、Forms、ReportsおよびDiscovererのデプロイメントでは、Oracle HTTP Serverはmod_wl_ohsと呼ばれるApacheモジュールを使用して、リクエストをOracle WebLogic管理対象サーバーにルーティングします。WebLogic管理対象サーバーがまとめてクラスタ化されている場合、mod_wl_ohsではそのクラスタにあるすべての管理サーバー間でリクエストがロード・バランシングされます。

- Oracle WebLogic管理対象サーバーはOracle Portal、Forms、ReportsおよびDiscovererアプリケーション用のJava EEランタイム・コンテナです。

- Oracle Process Manager and Notification Server(OPMN)はOracle Web CacheやOracle HTTP Serverの起動、停止および監視を行うために使用されます。これによってOracle Web CacheおよびOracle HTTP Serverが定期的にポーリングされ、それらが機能していることが確認されます。それらが機能していない場合、OPMNによって適切なアクションが実行され、障害が発生したコンポーネントが再起動されます。これによって、サービスが確実に維持されます。

- Oracle Node ManagerはOracle WebLogic管理対象サーバー(管理サーバーを含む)を起動、停止および監視するために使用されます。これによってWebLogic管理対象サーバーが定期的にポーリングされ、それらが機能していることが確認されます。それらが機能していない場合、Oracle Node Managerによって適切なアクションが実行され、障害が発生したコンポーネントが再起動されます。これによって、サービスが確実に維持されます。

- Oracle WebLogic管理サーバーはWebLogic管理コンソールとOracle Fusion Middleware Enterprise Managerの両方が含まれます。これは、WebLogicドメイン内で1回のみアクティブになります。この管理サーバーをホストしているサーバーに障害が発生した場合は、これを他の場所で手動で再起動する必要があります。

- Oracle Single Sign-Onはオラクル社のエンタープライズ認証メカニズムです。Oracle Single Sign-Onは製品コンポーネントごとにOracle HTTP Serverに統合されます。認証が必要なリクエストがOracle HTTP Serverに着信すると、そのユーザーがOracle Single Sign-Onサーバーによって認証済かどうかが判別されます。ユーザーが認証済である場合、リクエストが処理されます。ユーザーが認証されていない場合は、Oracle Single Sign-Onサーバーと通信して認可を受けます。

14.1.2 共通ログ・ファイル

次の表に、Oracle Portal、Forms、ReportsおよびDiscovererによって使用される一般的ログ・ファイルのリストと説明、およびファイルの場所を示します。

ファイル

場所

説明

access_log

ORACLE_INSTANCE/diagnostics/logs/OHS/ohs1

Oracle HTTP Serverへの各アクセスとHTTPリターン・コードのリスト

ohs1.log

ORACLE_INSTANCE/diagnostics/logs/OHS/ohs1

HTTPサーバーのエラー・ログ

access_log

ORACLE_INSTANCE/diagnostics/logs/WebCache/web1

Oracle WebCacheへの各アクセスとHTTPリターン・コードのリスト

access_log

DOMAIN_HOME/servers/WLS_PORTAL/logs

WebLogic管理対象サーバーが受信するアクセス・リクエストのリスト

opmn.log

ORACLE_INSTANCE/diagnostics/logs/OPMN

OPMNログ・ファイル

14.1.3 一般的なコンポーネント障害および予想される動作

この項では、Oracle Portal、Forms、ReportsおよびDiscovererに適用される高可用性の概要について説明します。

14.1.3.1 Oracle Web CacheおよびOracle HTTP Serverのプロセス障害

Oracle HTTP Server、Oracle Web CacheおよびOracle Discovererのプリファレンス・サーバー・プロセスは、Oracle Process Manager and Notification(OPMN)システムによって保護されます。これらのプロセスのいずれかに障害が発生すると、OPMNによって自動的にそのプロセスが再起動されます。

Oracle WebLogic管理対象サーバーは、Oracle Node Managerによって起動され監視されます。Oracle WebLogic管理対象サーバーに障害が発生した場合、Oracle Node Managerによってそのプロセスが再起動されます。

14.1.3.2 一般的なコンポーネント・ノード障害

Oracle Web Cacheが前面に配置されていないノードに障害が発生した場合、正常に動作しているノードにリクエストがロード・バランサによって自動的に再ルーティングされます。

Oracle Web Cacheに障害が発生した場合、正常に動作しているWebキャッシュ・ノードにリクエストがロード・バランサによって自動的に再ルーティングされます。

Oracle Web Cacheが前面に配置されているOracle HTTP Serverのノードに障害が発生した場合、正常に動作しているOracle HTTP ServerにリクエストがOracle Web Cacheによって再ルーティングされます。

Oracle WebLogic Serverに障害が発生した場合、リクエストはOracle HTTP Serverによって別のWebLogicクラスタ・メンバーに再ルーティングされます。

Oracle Portal、Forms、ReportsおよびDiscovererリクエストが障害発生ノードで処理されていた場合、リクエストを再開する必要があります。

14.1.3.3 一般的なコンポーネントのWebLogic管理対象サーバーの障害

高可用性構成では、Oracle WebLogic管理対象サーバーはまとめてクラスタ化されます。管理対象サーバーのいずれかに障害が発生した場合、正常に動作しているクラスタ・メンバーのいずれかにリクエストがmod_wl_ohsによってリダイレクトされます。アプリケーションに状態が格納されている場合、状態のレプリケーションがクラスタ内で使用可能になり、これにより、リダイレクトされたリクエストが、同じ状態情報にアクセスできます。

14.1.3.4 一般的なコンポーネントのデータベースの障害

データベースは、Oracle Real Application Clustersなどの高可用性テクノロジを使用して実装することをお薦めします。データベース・ノードのいずれかに障害が発生した場合でも、そのデータベース全体は使用可能な状態に維持されます。場合によっては、リクエストの再送信が必要です。

マルチ・データベース・ノード環境では、障害が発生したデータベース・ノードにユーザー・セッションが接続されている場合、次のようになります。

- Oracle Portal: ユーザーは、リクエストを再送信する必要があります。

- Oracle Forms: ユーザーは、リクエストを再送信する必要があります。

- Oracle Reports: Oracle Transparent Application Failoverを使用してデータベース接続文字列が構成されている場合、アクションは必要ありません(レポートがその実行中にデータベースに書き込まれていない場合)。
レポート・キューを含むデータベースでノードが失われた場合、ユーザーはレポート・リクエストを再送信する必要があります。

- Oracle Discoverer: ユーザーは、リクエストを再送信する必要があります。

14.1.4 Oracle Portal、Forms、ReportsおよびDiscovererのクラスタワイドの構成変更

Oracle Web Cacheインスタンスはクラスタ化されます。Oracle Fusion MiddlewareコンソールやOracle Web Cache管理ユーティリティから構成変更が行われた場合、これらの変更は他のクラスタ・メンバーに伝播されます。伝播は、これらのツールを使用して手動で行います。

Oracle HTTP Serverはクラスタ化されません。Oracle HTTP Serverの構成はファイル・ベースです。その結果、いずれかのOracle HTTP Serverに対して行われた変更は、その構成において他のOracle HTTP Serverに手動でコピーする必要があります。これは、htdocsディレクトリに格納されている静的HTMLファイルにも適用されます。

一連の構成ファイルを使用して、Oracle Portal、Forms、ReportsおよびDiscovererを構成します。これらのファイルに対する変更はすべて、アーキテクチャにあるすべてのメンバーに手動で適用する必要があります。

WebLogic管理対象サーバーはクラスタ化され、クラスタ・レベルでリソースを共有します。これらのリソースに対する変更は一括して実行できるため、伝播する必要はありません。これらのリソースは、次のとおりです。

- データ・ソース

- アプリケーションの再デプロイメント

- 状態のレプリケーション

14.1.5 一般的なコンポーネント・ログ・ファイル情報

クラスタワイドでログを統合する機能は、Oracle Web Cache、Oracle HTTP Server、OPMNおよびWebLogic管理対象サーバーに対しては提供されていません。Oracle HTTP Serverアプリケーションの状態の詳細は、各Oracle HTTP Serverノードのログ・ファイルを参照してください。障害が発生したアプリケーションの状態の詳細は、各サーバー・ノードのログ・ファイルを参照してください。

14.2 Oracle Portalと高可用性の概要

この項では、Oracle Portalに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Portalデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。

14.2.1 Oracle Portalの単一インスタンスの特性

Oracle Portalの単一インスタンス・アーキテクチャの詳細は、『Oracle Fusion Middleware Oracle Portal管理者ガイド』の次に示す項を参照してください。

- Oracle Portalコンポーネントの理解に関する項: Oracle Fusion Middlewareのコンポーネントを紹介します。ここでは、これらのコンポーネントがOracle Portalとどのように連動するのかを説明します。

- Oracle Portalアーキテクチャの理解に関する項: Portalアーキテクチャについて説明します。この項の次に示すトピックをお読みください。

- Oracle Portalと他のコンポーネントとの連動方法に関する項

- Oracle Portalにおいてページがアセンブルされる方法に関する項

- Oracle Portalにおいて通信が行われる方法に関する項

- Oracle Portalにおけるキャッシュの理解に関する項: この項では、中規模から大規模のデプロイメントの可用性およびスケーラビリティを高めるために実装できるキャッシュ構成について説明します。

- WSRPおよびJPSの理解に関する項: Web Services for Remote Portlets (WSRP)規格およびJava Portlet Specification (JPS)の概要を示します。これらの2つの規格により、異なるポータル製品で相互運用するポートレットの開発が可能になり、組織内におけるポートレットの可用性が高まります。

14.2.1.1 Oracle Portalのリクエスト・フロー

Oracle Portalのリクエスト・フローの詳細は、『Oracle Fusion Middleware Administrator's Guide for Oracle Portal』で次に示す各項を参照してください。

- Oracle Portalにおいてページがアセンブルされる方法に関する項

- Oracle Portalにおいて通信が行われる方法に関する項

14.2.1.2 Oracle Portalコンポーネントの特性

Oracle Portalコンポーネントの特性は次のとおりです。

- Oracle Portalアプリケーションは、WebLogicコンテナ(WLS_PORTAL)の内部で実行されます。

- Oracle Portalのリポジトリには、メタデータ、ドキュメント、カスタマイズおよびパーソナライズが格納されます。

- Oracle Portalは、コンテンツを処理してキャッシュするためにOracle Web Cacheに強く依存しています。

- Oracle Portalは、Oracle HTTP Serverに依存して、トラフィックをWebLogic Serverにルーティングし、製品イメージのサービス処理を行い、URLをリライトします。

14.2.1.3 Oracle Portalのプロセスの起動と停止およびライフサイクル

Oracle Portalには、固有のプロセスはありません。標準のOracleツールおよびユーティリティに依存して、Oracle Web Cache、Oracle HTTP Server、WebLogic管理対象サーバーのWLS_PORTAL、およびデータベースを管理します。

Oracle Portalコンポーネントの構成と監視を行うインタフェースは次のとおりです。

- Enterprise Manager: Oracle Web Cache、Oracle HTTP Server、Oracle PortalおよびWLS_PORTALを管理するためにあります。

- Oracle WebLogic管理コンソール: WLS_PORTALを管理するためにあります。

- Oracle WebLogic Scripting Tool(WLST): Portal固有の構成パラメータの追加や編集を行うためにあります。

- opmnctlコマンド・ライン・インタフェース: Oracle Web CacheやOracle HTTP Serverを管理するためにあります。

14.2.1.4 Oracle Portalのデプロイメント・アーティファクト

Portalアプリケーションは、ステージング済アプリケーション(portal.ear)としてWebLogic Server(WLS_PORTAL)にデプロイされます。構成ファイルはDOMAIN_HOME/servers/WLS_PORTAL/stage/portal/portal/configurationにあります。

14.2.1.5 Oracle Portalの構成情報

Portal構成のいくつかは、Portalリポジトリに格納されます。この情報には、サイトの詳細(サイトのホストとポート)、Web Cacheの詳細(webcacheのホスト、無効化ポートおよび無効化パスワード)およびOracle Internet Directoryの詳細(Oracle Internet Directoryのホストおよびポート)が含まれています。このような情報は、Enterprise Managerにアクセスすることや、コンテナに対してWLSTコマンドを使用することにより変更できます。

残りのPortal構成は、Portalアプリケーションのステージング済場所内に配置される構成ファイルにあります。その構成ファイルはDOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/にあります。HA環境では、構成ファイルを変更した場合、各ノードに対してアクションを繰り返すか、あるノードから別のノードに構成ファイルをコピーすることで、同じ変更を各WLS_PORTALインスタンスで繰り返す必要があります。

表14-1 Portalの構成ファイル

構成ファイル

説明

appConfig.xml

Portal Page Engine構成

portal_dads.conf

ポータル・データベース・アクセス記述子(DAD)構成

このファイルには、高可用性(HA)に関するプロパティが含まれています。これには、データベースへの接続文字列情報が含まれています。Oracle RACノードが追加または削除された場合、ノードの最終的なセットを反映するようにこのファイルを更新する必要があります。このファイルには、構成プロパティが含まれています。これにより、プールされたデータベース接続を使用前にテストできます。このプロパティを有効にすると、データベース・ノードが停止した場合に、最小限のコストでより適切な結果を実現できます。

portal_cache.conf

ポータル・キャッシュ構成

portal_plsql.conf

ポータルのグローバル設定

14.2.1.6 Oracle Portalのロギングおよびログ構成

Portalのログ・ファイルは、DOMAIN_HOME/servers/WLS_PORTAL/logsディレクトリに生成されます。ログ・ファイルの名前は、WLS_PORTAL-diagnostic.logです。ログ・ローテーションにより、古いログは類似した名前でアーカイブされます。Portalのログ・ファイルの構成は、logging.xmlファイルによって制御されます。このファイルはDOMAIN_HOME/config/fmwconfig/servers/WLS_PORTALに配置されます。

14.2.1.6.1 Oracle Portalのログ・ファイル

次の表に、Oracle Portalによって使用されるログ・ファイルのリストと説明を示します。

ファイル

場所

説明

WLS_PORTAL.log

DOMAIN_HOME/servers/WLS_PORTAL/logs

WebLogic管理対象サーバーのログ・ファイル

WLS_PORTAL.out

DOMAIN_HOME/servers/WLS_PORTAL/logs

WebLogic管理対象サーバーのサプリメンタル・ログ・ファイル:これは、一般的にWebLogicの問題について最初に検索される場所です。

14.2.1.7 Oracle Portalの外部依存性

Oracle Portalでは、リクエストに対応するためにOracle HTTP Serverが必要になります。オプションで、これらのリクエストをOracle Web Cacheによってキャッシュできます。その場合、それはロード・バランサとしても機能します。

Oracle Portalには、情報を格納するためのデータベースが必要です。このデータベースは、Oracle Repository Creation Assistantを使用してスキーマで事前にシードされます。

14.2.2 Oracle Portalの障害からの保護および予想される動作

図14-2は、Oracle Portalの高可用性構成を示しています。

図14-2 Oracle Portalの高可用性デプロイメント

「図14-2 Oracle Portalの高可用性デプロイメント」の説明

Oracle Portalの高可用性設定には、複数のOracle Web Cacheインスタンスが含まれます。これらのOracle Web Cacheインスタンスはまとめてクラスタ化され、キャッシュの整合性とフェイルオーバーが実現されます。複数のOracle HTTP Serverにトラフィックをルーティングするように、各Oracle Web Cacheは構成され、これらのサーバーでは、着信リクエストがロード・バランシングされます。

Oracle Portalアプリケーションをホストする複数のOracle WebLogic管理対象サーバーにOracle Portalリクエストをルーティングするように各Oracle HTTP Serverは構成されます。Oracle HTTP Serverは、Oracle Fusion Middlewareによって用意されているWebサーバーです。これには、Secure Sockets Layer(SSL)およびHTTP Secure Sockets Layer(HTTPS)をサポートするためのOpenSSLモジュールが組み込まれています。JavaサーブレットおよびJ2EEアプリケーションを実行しているOracle WebLogic Serverにトラフィックをルーティングするためのモジュール・コネクタもOracle HTTP Serverに用意されています。Oracle PortalはOracle HTTP Serverに依存して、いくつかのシナリオで、製品イメージのサービス処理を行い、URLをリライトします。

WLS_PORTALは、Oracle Portalアプリケーションを実行するWebLogic Serverです。WebLogic Serverでは、JSPトランスレータ、JSPサーブレット・エンジン(OJSP)およびEnterprise JavaBeans(EJB)コンテナを含む完全なJava EE環境が実現されます。これにより、高速で軽量でありながら高度にスケーラブルで使いやすく完全なJava EE環境が実現されます。これは、すべてJavaで記述されており、標準のJava Development Kit(JDK)仮想マシン(JVM)上で実行されます。

WLS_PORTAL内で実行されているPortalアプリケーションでは、Oracle Web Cacheと緊密に連携し、そのEdge Side Include(ESI)処理を使用して、セキュアな形式で動的Portalページを提供します。Oracle PortalではESIを使用し、様々なメタデータやコンテンツをOracle Web Cacheにセキュアにキャッシュします。コンテンツが変更されると、Oracle Web CacheにキャッシュされたコピーはOracle Portalによって無効化されます。そのようなコンテンツは、後続のリクエストで再生成されます。ESIにより、コンテンツを詳細なレベルでキャッシュでき、これによって、キャッシュ・ヒット率が向上し、Portalコンテンツをより詳細に無効化できます。大部分のコンテンツやメタデータについては、Oracle Portalによって、Web Cacheのメモリー内コンテンツがファイル・システムに基づいたポータル・キャッシュにバックアップされます。

Oracle Portalでは、そのコンテンツおよびメタデータ情報はデータベースに格納されます。データベースがシングル・ポイント障害とならないようにするため、そのデータベースはOracle Real Application Clustersを使用して構築します。

最後に、Oracle Web Cacheインスタンスの前にロード・バランサをフロントエンドとして配置し、Oracle Portalへの単一仮想アクセス・ポイントとします。ロード・バランサは、ブラウザから着信する外部トラフィックをロード・バランシングする以外に、Oracle Portalによって生成される内部トラフィックもロード・バランシングします(ポータル・ループバック・リクエストと呼ばれる)。また、Portalメタデータ・リポジトリから生成される無効化メッセージのロード・バランシングも実現します。そのような無効化リクエストは、Oracle Web Cacheに送信され、Oracle Web Cacheにキャッシュされている失効コンテンツを無効化します。Oracle Web Cacheのクラスタリング機能により、Oracle Web Cacheインスタンス全体のキャッシュ整合性が確保されます。

注意:

独自のプロデューサをデプロイする場合、プロデューサに冗長性を持たせ、ロード・バランサをフロントエンドとして配置してください。この手順により、システム内のシングル・ポイント障害がなくなります。

14.2.2.1 Oracle Portalプロセスの障害

特定のプロセスが停止した場合でも、各コンポーネントの冗長性により、Oracle Portalは継続的に機能します。Oracle Portalによってリクエストが再試行されないことに注意してください。したがって、特定のリクエストの処理中に障害が発生した場合、そのリクエストは失敗します。

14.2.2.2 Oracle Portalノードの障害

Oracle Portalノードの障害の詳細は、第14.1.3.2項「一般的なコンポーネント・ノード障害」を参照してください。

14.2.2.3 Oracle Portal WebLogic管理対象サーバーの障害

Oracle Portal WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。

14.2.2.4 データベース障害からのOracle Portalの保護

Oracle Portalのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。

14.3 Oracle Reportsと高可用性の概要

この項では、Oracle Reportsに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Reportsデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。

注意:

Oracle Fusion Middleware 11g リリース1 (11.1.1)は、Reports管理対象サーバーのクローニングをサポートしません。

注意:

アクティブ/アクティブ構成では、Webクライアントのみがサポートされます。コマンドライン・クライアント(rwclient)はサポートされていません。rwclientは名前により特定のReports Serverに接続され、特定のReports Serverの指定可能なインスタンスは1つのみです。

14.3.1 Oracle Reportsの単一インスタンスの特性

Oracle Reportsサービスは、Oracle Fusion Middlewareのレポート公開コンポーネントです。それは、形式と場所を問わずどのようなデータでも動的に取得、書式設定および配布する高品質な本番レポートを作成するためのエンタープライズ・レポート・サービスです。Oracle Reportsサービスを使用して、Webベースと非Webベースの両方の環境で公開できます。

次の表は、Oracle Reports固有のコンポーネントを示しています。

表14-2 Oracle Reportsコンポーネント

" title="Oracle Reportsコンポーネント" width="100%">

コンポーネント

説明

Oracle Reports Server

Reports Server (rwserver)は、クライアント・リクエストを処理します。これには、認証と認可の確認、スケジューリング、キャッシング、配布(カスタムやプラガブルな出力宛先への配布を含む)などの様々なサービスにリクエストを送り出すことも含まれます。また、Reports Serverによって、リクエストされたレポートを生成するためのランタイム・エンジンが作成され、Reports Serverキャッシュから完成レポートがフェッチされ、ジョブの準備が完了したことがクライアントに通知されます。Reports Serverは、スタンドアロンでもインプロセスでも実行できます。

Oracle Reports Engine

SQLベースとプラガブル・データ・ソースベースのレポートを実行するためのコンポーネントが組み込まれています。これによって、データ・ソースにおけるリクエスト・データのフェッチ、レポートの書式設定、キャッシュへの出力の送信、およびReports Serverへのジョブ完了通知が行われます。

Oracle Reports Engine

Reports Engineは、SQLベースとプラガブル・データ・ソースベースのレポートを実行するためのコンポーネントが組み込まれています。これによって、データ・ソースにおけるリクエスト・データのフェッチ、レポートの書式設定、キャッシュへの出力の送信、およびReports Serverへのジョブ完了通知が行われます。

Oracle Reports Cache

正常に実行されたレポートの出力を格納するために、使用します。これを行うことによって、同じレポートを繰り返して実行する必要がありません。

Oracle Reports Queue

レポート・リクエストのリスト。処理能力が利用可能になったときに、キュー内の次のレポートが実行されます。

Oracle Reports Customer Databases

通常、様々なデータベース(カスタマ・データベースと呼ばれます)に格納された情報を使用してレポートはコンパイルされます。

Oracle Single Sign On

Oracle Single Sign-On (SSO)を使用して、Oracle Reportsへのアクセスを制限することをお薦めします。

14.3.1.1 Oracle Reportsの状態情報

Oracle Reportsの状態情報は、ジョブ・メタデータのみです。たとえば、実行対象レポートに関する情報や実行時のパラメータなどがあります。これは多くの場合、レポート・キューと呼ばれます。この情報は、オペレーティング・システム・ファイルのservername.datまたはデータベースに格納されます。

14.3.1.2 Oracle Reportsの外部依存性

Oracle Reportsでは、Oracle HTTP Serverによるリクエストの処理が必要です。オプションで、これらのリクエストをOracle Web Cacheによってキャッシュできます。その場合、それはロード・バランサとしても機能します。

14.3.1.3 Oracle Reports固有の構成ファイル

次の表に、Oracle Reportsによって使用される構成ファイルのリストと場所を示します。

ファイル

APPHOST1の場所

APPPHOST2の場所

rwserver.conf

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configuration/

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configuration/

reports_ohs.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

14.3.1.4 Oracle Reportsの接続の再試行

この項では、次に示す接続の再試行について説明します。

- Oracle Portalデータベース接続の再試行:
Reports ServerからOracle Portalデータベース・スキーマへの接続が切断された場合、Reports Serverは、エラー生成前に接続の再確立を試行します。再接続に成功した場合、Reports Serverを再起動する必要はありません。

- Oracle Internet Directory接続の再試行:
Oracle Internet Directory接続が失効した場合、ReportsサーブレットとReports Serverは、エラー生成前に接続の再確立を試行します。再接続に成功した場合、Reports Serverを再起動する必要はありません。

- Oracle Metadata RepositoryおよびOracle Identity Managementの停止:
Oracle Metadata Repository(セキュリティ・メタデータ格納場所)の停止によってReports Serverは停止しません。Oracle Metadata Repositoryが使用できない場合、Reports Serverでは、コンポーネントが使用できなくなるとその結果として新しいリクエストが拒否されます。Oracle Metadata Repositoryが復帰してオンラインになると、Reports Serverはリカバリし、新しいリクエストの受信と処理を開始します。

Oracle Identity Managementコンポーネントが使用できなくなった場合、Oracle Metadata Repositoryの停止の場合と同様に、Reports Serverでは新しいリクエストが拒否されます。

- Reports Serverのタイムアウト:
Reports Serverでは、リクエストがデータベースから返されるまでの待機時間のタイムアウトを構成できます。このタイムアウトは、有効なレポートを実行するために十分な長さの時間にする必要があるだけでなく、長すぎない値に設定する必要もあります。

14.3.1.5 Oracle Reportsのプロセス・フロー

レポートの実行プロセスには、次のようにOracle Reportsサービスのコンポーネントが関連しています。

1. クライアントは、URL(Web)を経由してサーバーと通信することでレポートをリクエストします。

2. Reports Serverは、リクエストを次のように処理します。
リクエストにTOLERANCEオプションが含まれている場合、Reports Serverではそのキャッシュにそのリクエストを処理するための出力が存在しているかどうかが確認されます。そのキャッシュに適切な出力がある場合、レポートは再実行されず、その出力が即座に返されます。

そのリクエストが現在実行中のジョブと同じ場合、レポートは再実行されず、現在のジョブの出力が再利用されます。

これらの条件のどちらも満たされない場合:

- Oracle Reportsサーブレット(rwservlet)でSSOが有効になっている場合、認証について確認されます。その後、セキュアなReports Serverによって、Oracle Internet Directoryが使用されてユーザーが認可されます。Oracle Reportsサーブレット(rwservlet)でSSOが無効になっている場合、セキュアなReports Serverによってユーザーの認証と認可が行われます。

- レポートがスケジュール済である場合、Reports Serverによって、スケジュール済ジョブ・キューにリクエストが格納され、レポートはスケジュールに従って実行されます。レポートがスケジュールされていない場合、それは現行ジョブ・キューに格納され、Reports Engineが使用可能になったときに実行されます。

3. 実行時に、Reports ServerによってReports Engineが作成され、そのエンジンにリクエストが送信され、実行されます。

4. Reports Engineによってデータが取り出され、書式設定されます。

5. Reports EngineによりReports Serverキャッシュに移入されます。

6. Reports Engineにより、レポートの準備完了がReports Serverに通知されます。

7. Reports Serverによって、キャッシュがアクセスされ、レポートが送信されます。そして、URL、コマンドライン、またはcgicmd.datファイルのキーワード・セクション(URLリクエストのみ)で指定されたランタイム・パラメータに従ってレポートが出力されます。

リクエストの実行中にレポート・サーバーが停止した場合、そのリクエストを再送信する必要があります。再送信すると、障害が発生していないレポート・サーバーのいずれかによってそのリクエストが処理されます。

14.3.1.6 Oracle Reportsのログ・ファイル

次の表に、Oracle Reportsによって使用されるログ・ファイルを示します。

ファイル

場所

説明

WLS_REPORTS.log

DOMAIN_HOME/servers/WLS_REPORTS/logs

WebLogic管理対象サーバーのログ・ファイル

WLS_REPORTS.out

DOMAIN_HOME/servers/WLS_REPORTS/logs

WebLogic管理対象サーバーのサプリメンタル・ログ・ファイル:これは、一般的にWebLogicの問題について最初に検索される場所です。

rwservlet_diagnostic.log

DOMAIN_HOME/servers/WLS_REPORTS/logs

Reportsサーブレットに関するログ情報

rwserver_diagnostic.log

DOMAIN_HOME/servers/WLS_REPORTS/logs

Reports Serverに関するログ情報

14.3.2 障害からのOracle Reportsの保護および必要な対応

図14-3は、Oracle Reportsの高可用性デプロイメントの例を示しています。

図14-3 Oracle Reportsの高可用性デプロイメント

「図14-3 Oracle Reportsの高可用性デプロイメント」の説明

図14-3に示すように、Oracle Real Application Clustersデータベースにより、レポート・キュー用の高可用性リポジトリが実現されます。高可用性構成では、各Reports Serverは同じレポート・キューにアクセスします。共有レポート・キューによって、リクエストはどれも1回のみ処理されますが、デプロイメント内のどのReports Serverでも処理できます。

通常、様々なデータベースに格納された情報を使用してレポートはコンパイルされ、前述の図では、これらのデータベースをカスタマ・データベースと記載しています。

Reportsキャッシュを十分に活用するには、実装内のどのReports Serverからでもキャッシュを使用できるようにする必要があります。このようにして、いずれかのReports Serverによって生成されたレポートは、どのReports Serverからでも再利用や処理ができます。図14-3では、共有ディレクトリを使用してReportsキャッシュを使用可能にしています。

Oracle Reportsへのアクセスを制限するためのシングル・サインオン(SSO)の使用は必須ではありませんが、多くの組織ではOracle Single Sign-onを使用してOracle Reportsへのアクセスを制限しています。この章では、Oracle Single Sign Onを使用してデプロイメントを保護するために必要な手順についても説明します。

Reportsの高可用性デプロイメントには、インプロセスReports Serverをお薦めします。インプロセスReports ServerはOracle WebLogic Server内部で実行され、Reports Server自体をクラスタ化して、高可用性を確実に保持できます。

高可用性分散構成でWeb Cacheを使用する場合、すべての分散キャッシュのコンテンツに整合性があることが重要です。たとえば、あるレポートについて、どのOracle Web Cacheインスタンスからでも同じキャッシュ・コピーが使用できます。キャッシュされたコンテンツが無効になった場合、Webキャッシュのすべてで無効になることが不可欠です。これを実現するために、Webキャッシュ・クラスタリングが使用されます。

前述の図には、Web Logic管理サーバーが含まれており、それをAPPHOST2に配置する方法を示しています。配置方法を決定するには、このマニュアルで該当する章を参照してください。

14.3.2.1 Oracle Reportsプロセスの障害

Reports Serverがハングしたり応答に失敗したが、WebLogic管理対象サーバーではハングや応答失敗が発生していない場合、WebLogic管理対象サーバーを手動で再起動する必要があります。

14.3.2.2 Oracle Reportsノードの障害

Oracle Reportsノードの障害の詳細は、第14.1.3.2項「一般的なコンポーネント・ノード障害」を参照してください。

14.3.2.3 Oracle Reports WebLogic管理対象サーバーの障害

Oracle Reports WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。

14.3.2.4 Oracle Reportsデータベースの障害

Oracle Reportsのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。

14.4 Oracle Formsと高可用性の概要

この項では、Oracle Formsに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Formsデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。

14.4.1 Oracle Formsの単一インスタンス・コンポーネントの特性

Oracle Fusion Middleware Forms Servicesアーキテクチャでは、Webベースのアプリケーションと同様にクライアントとHTTPリスナーとの間の接続は1つのみです。HTTPリスナーによって、リクエストがFormsリスナー・サーブレットにルーティングされ、そこでFormsクライアントからFormsランタイムへのリクエストのルーティングが制御されます。

FormsクライアントとFormsランタイムとの間の通信は、常にHTTPリスナーを経由し、ネットワークに開いているポートは1つのみになります。

クライアントはHTTPリクエストを送信し、HTTPリスナー・プロセスからHTTPレスポンスを受信します。HTTPリスナーがクライアントに対してネットワーク・エンドポイントとして機能し、他のサーバー・マシンおよびポートはファイアウォールで公開されません。

14.4.1.1 Oracle Formsの状態情報

Oracle Formsは、ステートフル・アーキテクチャを採用しています。各ランタイム・プロセスでは、サービスの提供先となるクライアントのために状態が作業メモリーに保持されます。状態は複数のランタイム・プロセス間でシリアライズや共有されませんし、そのようにできません。

14.4.1.2 Oracle Formsデータベースの要件

Oracle Formsでは、相互作用の対象となるデータベースとのアクセスのみを必要です。Oracle Forms自体には特別な要件はありません。

14.4.1.3 Oracle Formsのリクエスト・フロー

Oracle Formsのリクエスト・フローは次のようになります。

1. ユーザーがWebページからリンクを選択するか、ブラウザでURLを直接入力します。

2. 渡されたURLがHTTPリスナーによって解釈され、ブラウザにForms Javaクライアントを示す<EMBED>タグまたは<OBJECT>タグ(使用されているブラウザによって異なる)を含むHTMLページが表示されます。渡されたURLでは、Formsサーブレットをコールし、Webサーバー上にあるbase.htmlファイルに基づいてHTMLページを動的に作成します。

3. クライアントは、HTTPリスナーによって処理されたHTMLファイルを受信します。HTMLファイル内のタグには、Forms Javaクライアントを構成するJavaクラス・ファイルを探すために必要な情報があります。HTMLファイルのタグ内で、実行するFormに関する情報、およびログイン情報などFormsセッションに渡す他のすべてのパラメータに関する情報を指定します。タグ定義には、実行するForms Servicesに関する指示、およびJavaクライアントの外観(ルック・アンド・フィールや色のスキームなど)のカスタマイズに役立つパラメータも多数含まれています。
HTMLファイルには、他のHTML属性が含まれることもあります。クライアント上でJREの特定のバージョンを使用する特定アプレットを実行するようにブラウザに指示する属性などです。

4. その後、HTMLファイルに指定されている場所のJavaクラス・ファイルをブラウザはHTTPリスナーに対して要求します。これを定義するためにHTMLファイルのCODEBASEパラメータが使用されます。このファイルは個別にダウンロードできますし、アーカイブにもできます。このアーカイブには、.JAR拡張子が付きますが、アプレットに必要な個別クラス・ファイルすべてを含むZIPファイルと考えることもできます。JARファイルを使用すると、Javaクライアントのダウンロードが高速になり、後続のコールのためにクライアント上でキャッシングが可能になります。ARCHIVEパラメータにより、どの.JARファイルを使用するのかが定義されます(存在する場合)。JREプラグインにより、HTTPリスナー上で使用可能なFormsクライアント用Javaコードのバージョンを確認する追加手順が実行され、現在そのプラグインでキャッシュされているバージョンよりも新しいバージョンであることが判明した場合にのみダウンロードされます。

5. クラス・ファイルやJARファイルはブラウザにダウンロードされ(存在していない場合)、Javaアプレットが起動します。

6. Javaクライアント・アプレットからリクエストが送信され、HTTPリスナーを経由してFormsリスナー・サーブレットへのFormsセッションが開始します。Formsリスナー・サーブレットは、HTMLファイルのタグ内のserverURLパラメータによって定義されます。

7. Javaクライアントから接続リクエストを受信すると、Formsリスナー・サーブレットはこのクライアントのために新しいFormsランタイム・プロセスを開始します。formsweb.cfg構成ファイルのサーブレット初期化用envFileパラメータを特定の環境ファイルに設定することで、各ランタイム・プロセスに対してユーザー固有の環境を定義できます。

8. このクライアントに割り当てられたFormsランタイム・プロセスにより、HTMLファイルで指定されているモジュール、それらのフォームに必要なライブラリおよびメニューすべてがロードされます。FormsクライアントとFormsランタイム・プロセスとの間におけるすべての通信は、Formsリスナー・サーブレットを経由します。

9. ユーザーがデータベース・ログイン情報を入力していない場合は、その入力を求められ、データベース・サーバーへの接続が確立されます。

10. これでユーザーの作業の準備が完了しました。

14.4.1.4 Oracle Forms構成の永続性

Oracle Formsでは、起動構成のために次のいくつかのファイルを使用します。

- formsweb.cfgには、ランタイム・プロセスのForms固有起動パラメータ(以前はコマンドラインで指定)が保持されます。特定のセクションが利用されていない場合に使用されるデフォルト・セクションと、1つ以上のユーザー・セクション(ユーザー・セクション固有のパラメータを保持)で構成されます。これらのセクションは、アプリケーションと呼ばれるもの(同じ論理ユニットに属する一連のフォーム)に対応しています。
formsweb.cfgは、次のディレクトリにあります。

DOMAIN_HOME/config/fmwconfig/servers/<FORMS_MANAGED_SERVER>/applications/formsapp_11.1.1/config

- default.envには、以前は環境変数で指定されていた起動パラメータが保持されます。Windowsでは、これらの変数はシステム・レジストリでも指定できます。
このファイルは、formsweb.cfgと同じディレクトリにあります。

DOMAIN_HOME/config/fmwconfig/servers/<FORMS_MANAGED_SERVER>/applications/formsapp_11.1.1/config

別の名前でカスタマイズ済envファイルも作成できます。そのようなファイルが存在する場合は、formsweb.cfgで指定すると検出されます。

- base.htmlおよびbasejpi.htm、またはそれらのカスタマイズ・バージョンには、Formsクライアント・アプレットを起動するHTMLコードのテンプレート構造が保持されます。
これらのファイルは次のディレクトリにあります。

ORACLE_INSTANCE/config/FormsComponent/forms/server

- Registry.datには、フォント、アイコンおよびイメージのデフォルトの場所および検索パスが保持されます。このファイルは、次の場所にあります。

DOMAIN_HOME/config/fmwconfig/servers/<FORMS_MANAGED_SERVER>/applications/formsapp_11.1.1/config/forms/registry/oracle/forms/registry

- frmweb.resには、Formsクライアントのキー・バインド定義が保持されます。このバインドは、キーボード・キーと、それによってトリガーできる内部Forms関数との間の関係を定義します。UNIXの場合、このバインド・ファイルは次の場所にあります。

ORACLE_INSTANCE/config/FormsComponent/forms/admin/resource/<language>

ここで、<language>は、2文字の言語デノミネータですWindowsの場合、このファイルは次の場所にあります。

ORACLE_INSTANCE/config/FormsComponent/forms

Windowsの場合、言語はその略語をファイル名の最後に追加することで定義されます。たとえば、フランス語の場合はfrmwebf.resになります。

- jvmcontroller.cfgは、JVMコントローラを構成するためのファイルです。システムに対して構成されるコントローラは、すべてこのファイルで定義されます。このファイルは、次のディレクトリにあります。

ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/

14.4.1.5 Oracle Formsランタイムの考慮事項

Oracle Fusion Middleware Forms Servicesは、3つのコンポーネントで構成されています。それらは、エンド・ユーザーのクライアント・マシンに自動的にダウンロードされてキャッシュされるFormsクライアント、中間層のFormsリスナー・サーブレット、およびFormsランタイムです。

Oracle Formsクライアント(Javaアプレット)

ユーザーがFormsセッションを実行すると、Thin 100パーセントJavaアプレットであるFormsクライアントがOracle Fusion Middlewareアプリケーション・サーバーから動的にダウンロードされます。この汎用Javaアプレットは、中間層の関連付けられたFormsランタイム・プロセスに対してユーザー・インタフェースをレンダリングするためのクラスを提供し、ユーザーの相互作用や視覚的なフィードバックを処理します。それらの例には、複数のアイテム間のナビゲートやチェック・ボックスの選択によって生成されることなどがあります。すべてのFormsアプリケーションに同じJavaアプレットが使用されるため、それは1回のみダウンロードされてクライアントにキャッシュされ、後続のFormsアプリケーションに対して使用可能になります。

ブラウザでJavaアプレットを実行するためには、Java Runtime Engine(JRE)がインストールされている必要があります。JREはクライアントにインストールされ、プラットフォーム依存です。

Oracle Formsランタイム・プロセス

Formsランタイム・プロセスは、Formsクライアントのかわりにデータベースへの接続を維持するプロセスです。Formsアプリケーションを含むページにユーザーがアクセスしたときに、このプロセスは作成されます。ユーザーがFormsアプリケーションを閉じるかブラウザ・ウィンドウを終了すると即座に、このプロセスは自動的に停止します。

Oracle Formsリスナー・サーブレット

Formsリスナー・サーブレットによって管理される処理は、次のとおりです。

- ユーザーがFormsアプリケーションの実行をリクエストした際、クライアントごとにFormsランタイム・プロセスが作成される処理。

- ユーザーがFormsアプリケーションを閉じるかブラウザ・ウィンドウを終了したときに、Formsリスナー・サーブレットではランタイム・プロセスの停止も行います。

- クライアントとそれに関連付けられたFormsランタイム・プロセスとの間のネットワーク通信処理。

14.4.1.6 Oracle Formsのプロセス・フロー

Oracle Formsの実行プロセスには、次のようにOracle Forms Servicesの様々なコンポーネントが関連しています。

1. クライアントは、URLを経由してサーバーと通信することでフォームをリクエストします。

2. Oracle HTTP Serverは、リクエストをOracle WebLogic Serverにルーティングします。

3. Oracle WebLogic Serverは、フォームを実行するためのFormsランタイム・プロセスを作成します。

中間層のサーバーで障害が発生したりサーブレット・セッションが中断した場合、アプリケーションを再起動することで、どちらの障害からでもリカバリします。それにより、新しいFormsランタイムが作成され、保存されていないデータを再入力できます。保存されていないデータによってデータベースは破損しません。それは、Formsではアトミック・トランザクションが使用され、それにより定義済で整然とした方法でデータベースの保存が実行されるためです。

14.4.1.7 Oracle Forms構成ファイル

次の表に、Oracle Formsによって使用される構成ファイルを示します。

ファイル

APPHOST1の場所

APPHOST2の場所

formsweb.cfg

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config

default.env

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config

base(jpi).htm

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config

Registry.dat

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config/forms/registry/oracle/forms/registry

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config/forms/registry/oracle/forms/registry

frmweb.res

UNIX:

ORACLE_INSTANCE/config/FormsComponent/forms/admin/resource/<language>

Windows:

ORACLE_INSTANCE/config/FormsComponent/forms

UNIX:

ORACLE_INSTANCE/config/FormsComponent/forms/admin/resource/<language>

Windows:

ORACLE_INSTANCE/config/FormsComponent/forms

jvmcontroller.cfg

ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/

ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/

forms.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

14.4.1.8 Oracle Formsの外部依存性

Oracle Formsでは、リクエストに対応するためにOracle HTTP Serverが必要です。オプションで、これらのリクエストをOracle Web Cacheによってキャッシュできます。その場合、それはロード・バランサとしても機能します。

Oracle Formsは、クライアント上でSun社のJavaプラグイン(JRE)を使用し、Forms Javaクライアントを実行します。

14.4.1.9 Oracle Formsのログ・ファイル

次の表に、Oracle Formsによって使用されるログ・ファイルを示します。

ファイル

場所

説明

WLS_FORMS.log

DOMAIN_HOME/servers/WLS_FORMS/logs

WebLogic管理対象サーバーのログ・ファイル

WLS_FORMS.out

DOMAIN_HOME/servers/WLS_FORMS/logs

WebLogic管理対象サーバーのサプリメンタル・ログ・ファイル:これは、一般的にWebLogicの問題について最初に検索される場所です。

各種ファイル

ORACLE_INSTANCE/FormsComponent/forms/trace

Formsトレース・ファイル: Formsランタイム・プロセスが失敗すると生成されます。

このファイル名の形式は次のとおりです。

<forms_runtime_process>_dump_<process_id>

Formsランタイム・プロセスでは、正常な動作の場合はログ・ファイルに書込みを行いません。

各種ファイル

DOMAIN_HOME/servers/WLS_FORMS/logs

リスナー・サーブレットのログ

14.4.2 Oracle Formsのフェイルオーバーによる保護および予想される動作

Oracle Formsには、シリアライズ可能な状態がありません。これは、透過的フェイルオーバーが可能でないことを意味します。ランタイム・プロセスが失敗した場合、そのサーバー・プロセスによって処理されているクライアント・プロセスも失敗します。Oracle Formsは、アトミック・データベース・トランザクションを採用しています。アトミック・トランザクションでは、一連のデータ、レコードまたは一連のレコードは、完全に保存されるか、まったく保存されないかのいずれかです。その結果、障害が発生すると、保存されていないデータは、定義済の正確な方法により失われます。そのデータはアプリケーションが再起動したときに、ユーザーによって再入力する必要があります。実行マシンに障害が発生したためにプロセスが失敗すると、ユーザー・ベースにサービスを提供する既存の処理能力の大部分またはすべてが、使用できなくなる場合があります。このシナリオでは、アプリケーション全体が使用できなくなる可能性があります。継続的に使用できるようにするためのオプションとしては、アクティブ/アクティブ構成またはアクティブ/パッシブ構成のいずれかで処理能力に冗長性を持たせることがあります。

図14-4 Oracle Formsの高可用性デプロイメント

「図14-4 Oracle Formsの高可用性デプロイメント」の説明

14.4.2.1 Oracle Forms N+1の冗長性

N+1とは、処理能力に冗長性を持たせる手法のことです。その手法は、ハードウェアではグループ単位よりもユニット単位で破損する傾向があるという考えに基づいています。つまり、コンピュータ・ネットワークでは、複数のコンポーネントを同時に失う場合より、1つのコンポーネントを失う場合が多いことを意味します。N+1の原則では、ロードのピーク時にユーザー・ベース全体にサービスを処理するために必要なマシンの台数に加えて、そのセット内で最大の処理能力を有するマシンと同じ処理能力の追加ユニットを設置するようにします。これは、フェイルオーバーがマシン・レベルで行われるため、通常、アクティブ/パッシブ・フェイルオーバーと呼ばれます。

デプロイメント内にユーザー・ベース全体を処理可能なサーバーが6台ある場合に、それらが理想的に構成されていると、それらにはすべて、HTTP Server、JavaランタイムおよびFormsランタイムがインストールされています。どのサーバーも負荷が過剰にならないようにハードウェア(またはソフトウェア)型ロード・バランサがあります。ロード・バランサには、スタンバイというラベルが付いた1台のマシンが認識されます。そのマシンは、そのセット内の残りのマシンの中で最大の処理能力を有するマシンと同じ処理能力を持ち、残りのマシンすべてに対して理想的に構成されていますが、そのマシンにはルーティングされません。アクティブ/パッシブ・シナリオでは、スタンバイ・マシンは稼働している必要はありません。アクティブ/アクティブ・シナリオでは、それはセットのアクティブ部分の場合があり、継続的に余剰の処理能力が確保されます。

ここで、マシンのいずれかに障害が発生したと仮定します。

マシンのいずれかに障害が発生した場合、スタンバイ・マシンがオンラインになり、ロード・バランサでは新しいリクエストをそのマシンにもルーティングし、障害が発生したマシンを無視するように再構成されます(いくつかのハードウェア・ロード・バランサでは、これらの2つの手順が自動的に実行されます)。アクティブ/アクティブ・デプロイメントでスタンバイ・マシンがすでに実行中で、ユーザー・ベースにサービスを処理している場合、クライアント上のブラウザを再起動するために要する時間と同程度に停止時間が短くなる場合があります。アクティブ/パッシブ・デプロイメントでスタンバイ・マシンが実行中ではないときに、起動が必要であるだけでなく、ロード・バランサを手動で再構成する必要もある場合、停止時間はさらに長くなります。

14.4.2.2 Oracle Forms N+Mの冗長性

フェイルオーバー処理能力を強化するために、複数のスタンバイ・マシンを使用できます。これは通常、N+Mと呼ばれます。複数のマシンに同時に(またはほぼ同時に)障害が発生する確率はかなり低くなりますが、そのような状況に対処できる必要がある場合、N+M設定が可能でありますが、おそらくその設定が必要になります。

デプロイメント内のすべてのマシンに影響する状況(1箇所にあるマシンがすべて破壊される自然災害など)において冗長性を実現するには、このデプロイメントを地理的に別々の場所に複製できます。

14.4.2.3 Oracle Formsの仮想マシン

仮想マシンを使用するデータセンターでは、スペア・ハードウェアを使用してスタンバイ・マシンをオンラインにできるので、大変低いコストで実装できます。

14.4.2.4 Oracle Forms構成のクローニング

環境のクローニングの重要性は、前述の項で説明したシナリオから明白です。1台のマシンの環境に行われたすべての変更は、スタンバイ・マシンも含めて他のすべてのマシンにも適用する必要があります。これにより、特にスペア・マシンが仮想である場合、問題が発生します。仮想マシンのイメージは、他のマシンに行われた変更と同期している必要があります。

14.4.2.5 Oracle Formsプロセスの障害

Oracle Formsプロセスの障害の詳細は、第14.1.3.1項「Oracle Web CacheおよびOracle HTTP Serverのプロセス障害」を参照してください。

14.4.2.6 Oracle Formsノードの障害

Oracle Formsノードの障害の詳細は、第14.1.3.2項「一般的なコンポーネント・ノード障害」を参照してください。

14.4.2.7 Oracle Forms WebLogic管理対象サーバーの障害

Oracle Forms WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。

14.4.2.8 Oracle Formsデータベースの障害

Oracle Formsのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。

14.5 Oracle Discovererと高可用性の概要

この項では、Oracle Discovererに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Discovererデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。

14.5.1 Oracle Discovererの単一インスタンスの特性

Discovererをインストールする場合、図14-5に示すように、単一インスタンス内にDiscovererトポロジを作成します。インストール後、Discoverer用に他のタイプのトポロジを構成できます。

図14-5 単一インスタンスのDiscovererトポロジ

「図14-5 単一インスタンスのDiscovererトポロジ」の説明

14.5.1.1 Oracle Discovererランタイムの考慮事項

図14-6は、複数のDiscovererコンポーネント間において実行時に行われる相互作用を表しています。

図14-6 複数のDiscovererコンポーネント間において実行時に行われる相互作用

「図14-6 複数のDiscovererコンポーネント間において実行時に行われる相互作用」の説明

Discoverer Servletは、管理対象サーバー上にデプロイされるJava EEアプリケーションであり、管理コンソールやOracle Enterprise Manager Fusion Middleware Controlを使用して、起動と停止ができます。Discoverer Servletは、ステートレス・プロセスです。

Discoverer Session Serverは、OPMN管理CORBAコンポーネントであり、データベースへの接続やワークブックのオープンなどのDiscoverer操作を実行します。このセッション・サーバーは、Discoverer Servletとデータベースとの間のリンクを提供します。アクティブなユーザー・ログイン・セッションごとに1つのセッション・サーバー・コンポーネントがあります。Discoverer Session Serverはステートフル・プロセスであり、状態はメモリーにのみ格納されます。

Discoverer Preference Serverは、OPMN管理コンポーネントであり、すべてのDiscovererユーザーにプリファレンス設定(デフォルトとユーザー定義の両方)を提供します。これらのプリファレンスにより、Discovererの動作が制御されます。Preference Serverの起動および停止の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドを参照してください。

Discoverer Services Statusは、OPMNによって管理されるダミー・プロセスです。セッション・サーバーを作成するには、このプロセスが実行中である必要があります。

注意:

Discoverer Servletおよびセッション サーバーは、同じマシン上で実行する必要があります。

Oracle Discovererの外部依存性

Discovererには、Oracle HTTP ServerおよびEnterprise Manager Fusion Middleware Controlが必要です。

リポジトリ作成ユーティリティ(RCU)を使用して、Discovererのデータベース・スキーマおよびポートレット・スキーマを(Discovererをインストールする前に)ロードする必要があります。

Discovererは、DiscovererワークブックおよびDiscoverer End User Layerを含むカスタマ・データベースおよびその他のデータ・ソースと相互作用します。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererデータベース層に関する項を参照してください。

Oracle Web Cacheを使用して、Discoverer用にロード・バランシングを構成できます。

DiscovererのPortlet Providerコンポーネントは、Oracle PortalおよびOracle Web Centerにポートレットを提供できます。

DiscovererのWebサービス・コンポーネントは、外部クライアント(Oracle BI PublisherやOracle BI Enterprise Editionなど)がDiscoverer接続とワークブックを取得するために使用できます。

Oracle Single Sign-On(SSO)を使用してOracle Discovererへのアクセスを制限することをお薦めします(ただし、必須ではありません)。

Discovererのプロセス・フロー

Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererの動作に関する項参照してください。

接続プロトコル

クライアント・ブラウザは、HTTPリクエストをDiscoverer Java EEアプリケーションに送信します。

Discoverer Java EEアプリケーションは、WebLogic Serverデータ・ソースを使用してデータベース・スキーマにアクセスします。

Discoverer Session Server(非Java EEコンポーネント)は、OCIレイヤーを使用してデータ・ソースに接続します。

Discoverer Java EEアプリケーションおよびDiscoverer Session Serverプロセスは、CORBAを使用して通信します。

14.5.1.2 Oracle Discoverer ViewerおよびWeb Cache

Discoverer Viewerのパフォーマンスと可用性はOracle Web Cacheを使用して向上できます。Web Cacheをいつ、どのように使用するのかについては、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドの「Oracle Web CacheとのDiscoverer Viewerの使用方法」を参照してください。

14.5.1.3 Oracle Discoverer構成の考慮事項

Oracle Discovererの環境と動作は、Discovererプリファレンスおよび構成パラメータで制御します。

- プリファレンスの一覧とプリファレンス設定の変更手順の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererのプリファレンスの管理に関する項を参照してください。

- 構成パラメータは、configuration.xmlファイルに格納されています。構成パラメータおよびそれらのパラメータの設定の定義方法の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererの管理および構成に関する項を参照してください。

プリファレンスおよび構成パラメータが格納されているファイルの場所の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererの構成ファイルに関する項を参照してください。

14.5.1.4 Oracle Discovererデプロイメントの考慮事項

Discoverer Java EEアプリケーションは、基本的なデプロイメント・ディスクリプタを含んでいます。

- discoverer.earファイルは、application.xml、jazn-data.xmlおよびweblogic-application.xmlのファイルで構成されています。
これらのファイルは、DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/ディレクトリにあります。ここでDOMAIN_HOMEは、ドメイン・ディレクトリの名前です。

- discoverer.warファイルには、custom-laf.xml、plus_versions.properties、uix-config.xml、portlet.xml、weblogic.xml、struts-config.xmlおよびweb.xmlのファイルが含まれています。
これらのファイルは、DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/ディレクトリにあります。ここでDOMAIN_HOMEは、ドメイン・ディレクトリの名前です。

14.5.1.5 Oracle Discovererのログ・ファイルの場所

Discovererのログ・ファイルは、Enterprise Manager Fusion Middleware Controlで検索と表示ができます。

詳細は、Enterprise Manager Fusion Middleware Controlのオンライン・ヘルプを参照してください。

14.5.1.6 Discovererのログ・ファイル

次の表に、Oracle Discovererに使用されるログ・ファイルを示します。

ファイル

場所

説明

WLS_DISCO.log

DOMAIN_HOME/servers/WLS_DISCO/logs

WebLogic管理対象サーバーのログ・ファイル

WLS_DISCO.out

DOMAIN_HOME/servers/WLS_DISCO/logs

WebLogic管理対象サーバーのサプリメンタル・ログ・ファイル:これは、一般的にWebLogicの問題について最初に検索される場所です。

各種ファイル

ORACLE_INSTANCE/diagnostics/logs/Discoverer/Discoverer_Instance

プリファレンス・ストアを含むサプリメンタルDiscovererログ・ファイル

14.5.2 Oracle Discovererの障害からの保護および予想される動作

図14-7は、2つのDiscovererインスタンスで構成されるDiscovererトポロジを示しています。

各管理対象サーバーのDiscoverer Java EEアプリケーションは、1台のプリファレンス・サーバーと通信します。したがって、同じプリファレンスが両方のDiscovererインスタンスに適用されます。Discovererインスタンスは、同じマシン上にも異なるマシン上にも配置できます。

図14-7 複数インスタンスのDiscovererトポロジ

「図14-7 複数インスタンスのDiscovererトポロジ」の説明

次の各項では、Discovererに関連して特定の高可用性の考慮事項について説明します。高可用性を実現するために構成変更を行った後は、Oracle HTTP ServerおよびDiscoverer Java EEアプリケーションがデプロイされている管理対象サーバーを再起動する必要があります。

14.5.2.1 プリファレンス・サーバーのフェイルオーバー

クラスタ内のDiscoverer Java EEアプリケーションの障害検出および再起動は、WebLogic Serverによって管理されます。

プリファレンス・サーバーは、シングルトン・プロセスであり、クラスタ全体で1つのインスタンスのみが実行されます。

プリファレンス・サーバーのプロセスが停止した場合、OPMNによって自動的に再開されます。OPMNも停止した場合、管理者はプリファレンス・サーバーを手動で起動するか、プリファレンス・サーバーが構成されている別マシンにプリファレンスのあるファイル(reg_key.dcとpref.txt)を移動し、そのマシン上でプリファレンス・サーバーを起動する必要があります。

プリファレンス・サーバーをクラスタ内の別のノードで起動する場合、その新しいプリファレンス・サーバーを認識するようにDiscoverer Java EEアプリケーションを構成する必要があります。

14.5.2.2 セッション状態レプリケーションとフェイルオーバー

特定のDiscoverer HTTPセッションに関するリクエストを処理しているサーバーまたはマシンが停止した場合、後続のリクエストはクラスタ内の他の管理対象サーバーに転送されます。そのセッション状態は、新しいサーバーでレプリケートできます。このレプリケーションを実現するために必要な情報は、HTTPリクエスト(GET/POST)で入手できます。

注意:

リクエストを完了するためには、Discovererではセッション・サーバー(C++プロセス)が使用可能である必要があります。したがって、フェイルオーバーが発生すると、C++プロセスを作成してから必要な状態にする必要があるため、レスポンス時間がわずかに長くなります。

14.5.2.3 パフォーマンス上の推奨事項

Discoverer Java EE Servletは、受信したHTTPリクエストごとにセッション・サーバーのプロセスを作成します。複数のDiscovererインスタンス(管理対象サーバーおよび関連するoracleインスタンス)が1台のマシンに存在していると、すべてのDiscovererインスタンスでC++プロセスを同時に作成する場合があるためにCPUの負荷が非常に高くなることがあります。別のマシン上にDiscovererインスタンスを追加すると、同じマシン上に追加するよりもパフォーマンスが向上します。

14.5.2.4 クラスタ間の構成変更の伝播

どのような構成変更も、クラスタ内の各管理対象サーバーで個別に実装する必要があります。これは、configuration.xmlファイルをすべての管理対象サーバーにコピーすることにより実現できます。

構成ファイルの場所の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererの構成ファイルに関する項を参照してください。

14.5.2.5 クラスタワイドのアプリケーションのデプロイメント

各Discoverer Java EEアプリケーション・インスタンス(管理対象サーバー)は、Discovererコンポーネントを含むOracleインスタンスと関連付けられている必要があります。これらのコンポーネントは、インストール・プロセスの構成段階で作成されます。そのため、WebLogic Server管理コンソールから、管理対象サーバーをクラスタに追加したりDiscoverer Java EEアプリケーションをデプロイすることは、サポートされていません。

クラスタ内で定義されたすべての管理対象サーバーは、Discoverer Java EEアプリケーションのデプロイメントのターゲットとなります。

14.5.2.6 オンライン・アプリケーションのデプロイメント

Discoverer Java EEアプリケーション依存のjarファイルの大部分は、共有ライブラリを介して使用できます。これらの共有ライブラリにパッチを適用しても、Discoverer Java EEアプリケーションを再起動する必要はありません。

システム・クラスパスを介して実行できる次のjarファイルに対して変更を行った場合、Discoverer Java EEアプリケーションを再起動する必要があります。

WL_HOME/server/lib/weblogic.jar
ORACLE_HOME/modules/oracle.jrf_11.1.1/jrf.jar
ORACLE_HOME/opmn/lib/nonj2eembeans.jar
ORACLE_HOME/server/lib/ojdbc6.jar
ORACLE_HOME/opmn/lib/optic.jar
ORACLE_HOME/opmn/lib/iasprovision.jar
ORACLE_HOME/opmn/lib/ons.jar
ORACLE_HOME/modules/oracle.adf.share_11.1.1/oracle-el.jar
ORACLE_HOME/jlib/share.jar
ORACLE_HOME/jlib/jewt4.jar

14.5.2.7 Oracle Discovererプロセスの障害

Discoverer Java EEアプリケーションがデータベースにアクセスするためには、各データベースのエントリが、ORACLE_INSTANCE/config/tnsnames.oraファイル内に作成されている必要があります。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのtnsnames.oraファイルの構成に関する項を参照してください。

14.5.2.8 Oracle Discovererノードの障害

Oracle Discovererノードの障害の詳細は、第14.1.3.2項「一般的なコンポーネント・ノード障害」を参照してください。

14.5.2.9 Oracle Discoverer WebLogic管理対象サーバーの障害

Oracle Discoverer WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。

14.5.2.10 Oracle Discovererデータベースの障害

Oracle Discovererのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。

14.6 高可用性のためのOracle Portal、Forms、ReportsおよびDiscovererの構成

この項では、高可用性デプロイメントのためのOracle Portal、Forms、ReportsおよびDiscovererの構成手順について説明します。この項の項目は次のとおりです。

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

- 第14.6.1項「前提条件」

- 第14.6.2項「前提事項」

- 第14.6.3項「メタデータ・リポジトリの作成」

- 第14.6.4項「APPHOST1におけるアプリケーション層のインストールと構成」

- 第14.6.5項「APPHOST2におけるアプリケーション層のインストールと構成」

- 第14.6.6項「デプロイメントのスケール・アウト」

注意:

これらの項においてリストされるホスト名とポートは、このデプロイメント例を示すために使用しています。実際のデプロイメントを構成するときは、独自のホスト名とポートを指定できます。

14.6.1 前提条件

Oracle Portal、Forms、ReportsおよびDiscovererをインストールする前に、この項で説明する前提条件を確認してください。

14.6.1.1 依存関係

Oracle Single Sign-Onを使用している場合、高可用性アイデンティティ管理フレームワークが使用できることが前提になります。Oracle Portal、Forms、ReportsおよびDiscovererでは、シングル・サインオンを使用します。これはOracle Identity Management 10gで入手可能です。

14.6.1.2 ネットワークの要件

この項では、ネットワーク要件について説明します。

14.6.1.2.1 ロード・バランサ

複数のOracle Webサーバー間でリクエストを分散させるには、ロード・バランサが必要です。この外部ロード・バランサには、次の機能が必要です。

- 仮想サーバー名とポートを構成する機能

- プロセス障害を検出する機能

- Oracle HTTPおよびHTTPSのためにポート(HTTP、HTTPS)を監視する機能

- SSL変換機能(必要な場合)

14.6.1.2.2 ロード・バランサの構成: 仮想サーバー名とポート

ロード・バランシング・ルーターを使用する場合、次のものが使用可能になるように構成する必要があります。

ロード・バランサが終着点となるSSLトラフィックを使用している場合

ポート443(HTTPSリスニング・ポート)上でmysite.mycompany.comに対するリクエストをリスニングする仮想IPアドレス(VIP1): それらをアプリケーション層のOracle Web Cache(WEBHOST1およびWEBHOST2、ポート7777(HTTPリスニング・ポート)上で稼働)にバランシングします。プロトコル変換を実行するようにロード・バランシング・ルーターを構成する必要があります。

サイトSSLを使用している場合

ポート443(HTTPSリスニング・ポート)上でmysite.mycompany.comに対するリクエストをリスニングする仮想IPアドレス(VIP1): それらをアプリケーション層のOracle Web Cache(WEBHOST1およびWEBHOST2、ポート443(HTTPSリスニング・ポート)上で稼働)にバランシングします。

ロード・バランサが終着点となるHTTPトラフィックを使用している場合

ポート80(HTTPリスニング・ポート)上でmysite.mycompany.comに対するリクエストをリスニングする仮想IPアドレス(VIP1): それらをアプリケーション層のOracle Web Cache(WEBHOST1およびWEBHOST2、ポート7777(HTTPリスニング・ポート)上で稼働)にバランシングします。

Web Cache

- ポート9401(HTTPリスニング・ポート)上でmysite.mycompany.comに対するリクエストをリスニングする仮想IPアドレス(VIP1): WEBHOST1およびWEBHOST2、ポート9401(HTTPリスニング・ポート)上でそれらをアプリケーション層のOracle Web Cacheにバランシングします。

注意:

セキュリティ上の理由から、ロード・バランシング・ルーター上のポート9401、9402および9403は、外部ユーザーから参照できないようにする必要があります。

- Oracle Web CacheのHTTP/HTTPS監視: ロード・バランシング・ルーターでは、動作していないコンピュータを検出し、それが再度動作するまでそのコンピュータへのリクエストのルーティングを停止するように構成する必要があります。HTTPリクエスト・ポートと無効化ポートの2つのOracle Web Cacheポートを監視する必要があります。
ポート7777を監視するには、ロード・バランシング・ルーター構成で次のURLを使用します。

hostname:port/_oracle_http_server_webcache_static_.html

例:

http://webhost1.mycompany.com:7777/_oracle_http_server_webcache_static_.html

ロード・バランシング・ルーターがこのURLからのレスポンスを受信した場合、Oracle Web Cacheインスタンスが稼働しています。レスポンスを受信しない場合、プロセスまたはサーバーが停止しており、ロード・バランシング・ルーターはすべてのリクエストをアクティブなコンピュータに転送します。

ポート9401を監視するには、ロード・バランシング・ルーター構成で次のURLを使用します。

http://hostname.domain.com:9401/x-oracle-cache-invalidate-ping

例:

http://apphost1.mycompany.com:9401/x-oracle-cache-invalidate-ping

ロード・バランシング・ルーターは、このURLにHTTPリクエストを送信し、レスポンス・ヘッダーは次にようなヘッダーになります。

HTTP/1.0

ロード・バランシング・ルーターは、レスポンス・ヘッダーの最初の行にあるHTTP文字列を検出するように構成する必要があります。したがって、ロード・バランシング・ルーターがレスポンス・ヘッダーの最初の行でHTTPを検出した場合、無効化ポートが使用可能になります。検出しない場合、すべての無効化リクエストはアクティブなコンピュータにルーティングされます。

注意:

sqlnet.oraファイルは、ロード・バランシング・ルーターおよびファイアウォールに関連する接続タイムアウトを防止するように更新する必要があります。

要約すると、ロード・バランサには次の構成が必要です。

仮想ホスト

仮想ポート

サーバー・プール

サーバー

ポート

コメント

mysite.mycompany.com

443/80

UserRequest

WEBHOST1

7777

SSLの終着点がロード・バランサの場合、プロトコル変換が必要です。

mysite.mycompany.com

443/80

UserRequest

WEBHOST2

7777

SSLの終着点がロード・バランサの場合、プロトコル変換が必要です。

mysite.mycompany.com

キャッシュの無効化

WEBHOST1

9401

外部クライアントからは参照できません。

mysite.mycompany.com

キャッシュの無効化

WEBHOST2

9401

外部クライアントからは参照できません。

14.6.1.3 データベース

製品が異なると、データベースの使用方法が異なります。次に、Oracle Portal、Forms、ReportsおよびDiscovererのデータベース要件の要約を示します。

Oracle Portal

Oracle Portalは、それ自体のメタデータとユーザー・コンテンツの両方をデータベースに格納します。Portalアプリケーション・ロジックの大部分もPLSQLの形式でこのデータベースに配置されます。メタデータ、ユーザー・コンテンツおよびPLSQLの組合せを使用することで、Portalにより、Webページが生成されます。

Oracle Portalには、高可用性データベースが必要です。これはPortalアプリケーションによって必要とされるデータベース・オブジェクトで事前にシードされます。メタデータ・リポジトリの作成の詳細は、第14.6.3項「メタデータ・リポジトリの作成」を参照してください。

Oracle Forms

Oracle Formsは、データベースと相互作用するため、データベースへのアクセスが必要です。Oracle Forms自体には特別なデータベース要件はありません。

Oracle Reports

Oracle Reportsには、レポート・キューを備えた高可用性データベースが必要です。また、様々なカスタマ・データベースへのアクセスも必要であり、それを使用してレポート・コンテンツをコンパイルします。

Oracle Discoverer

Oracle Discovererには、ポートレット用のデータベースが必要です。これは、高可用性データベースにする必要があり、Oracleリポジトリ作成ユーティリティ(RCU)を使用してシードされている必要があります。

また、Oracle Discovererは、いくつかのカスタマ・データベースと相互作用します。これらのデータベースは、レポートするデータに加えて、Discoverer End User Layerおよびワークブックも格納します。

14.6.1.4 共有ディレクトリ

共有ディレクトリの要件は、製品ごとに異なります。次の表に、これらの要件を示します。

製品

共有ディレクトリ要件

Oracle Portal

なし

Oracle Forms

必須ではありませんが、Oracle Forms実行可能ファイル用に共有ディレクトリがあると便利です。

Oracle Reports

レポート・キャッシュ

Oracle Discoverer

ポートレットのプリファレンス・ストア

14.6.1.5 管理対象ポートの番号

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

ポート番号は、インストール時に自動的に割り当てることも手動で割り当てることもできます。

14.6.1.6 サイト名

Webサイトを構成するには、サイト名が必要です。このサイト名(たとえばmysite.mycompany.com)はDNSで定義し、ロード・バランサに割り当てられた仮想IPアドレスと関連付ける必要があります。

サイト名は、シングル・サインオン・サーバーにも必要です。これは、高可用性シングル・サインオン・インストールの一部として設定します。

14.6.2 前提

この章で説明する高可用性構成の例のために、次の前提事項について説明します。

14.6.2.1 ポート

次の表に、Oracle Portal、Forms、ReportsおよびDiscovererの実装に必要な一般的ポートを示します。

用途

ホスト

ポート

コメント

mysite.mycompany.com

ロード・バランサ

80

ロード・バランサ上のHTTPポート

Web CacheのHTTP

APPHOST1

APPHOST2

7777

Web CacheのHTTPポート

Web CacheのHTTPS

APPHOST1

APPHOST2

4443

Web CacheのHTTPSポート

Web Cacheの無効化

APPHOST1

APPHOST2

9401

Web Cacheの無効化ポート

Web Cacheの管理

APPHOST1

APPHOST2

9400

Web Cacheの管理ポート

HTTPサーバー(OHS)のHTTP

APPHOST1

APPHOST2

7778

OHSのHTTPリスニング・ポート

HTTPサーバー(OHS)のHTTPS

APPHOST1

APPHOST2

4444

OHSのHTTPSリスニング・ポート

WebLogicの管理ポート

APPHOST1

7001

WebLogic管理サーバー・ポート

WLS_PORTAL

APPHOST1

7050

WebLogic管理対象サーバー・ポート

WLS_PORTAL1

APPHOST2

7050

WebLogic管理対象サーバー・ポート

WLS_REPORTS

APPHOST1

7051

WebLogic管理対象サーバー・ポート

WLS_REPORTS1

APPHOST2

7051

WebLogic管理対象サーバー・ポート

WLS_DISCO

APPHOST1

7052

WebLogic管理対象サーバー・ポート

WLS_DISCO1

APPHOST2

7052

WebLogic管理対象サーバー・ポート

WLS_FORMS1

APPHOST1

7053

WebLogic管理対象サーバー・ポート

WLS_FORMS2

APPHOST2

7053

WebLogic管理対象サーバー・ポート

インターネット・ディレクトリ

SSOHOST

389

Oracle Internet DirectoryのHTTPポート

シングル・サインオン

SSOHOST

7777

シングル・サインオンのリスニング・ポート

14.6.3 メタデータ・リポジトリの作成

Oracle PortalおよびOracle Discovererをインストールする前に、リポジトリ作成ユーティリティ(RCU)を実行して、これらのアプリケーションが機能するために必要なメタデータを含むリポジトリを作成してからシードします。

注意:

Oracle FormsおよびReportsには、メタデータ・リポジトリは必要ありません。

14.6.3.1 リポジトリ作成ユーティリティ(RCU)のインストール

リポジトリ作成ユーティリティの最新バージョンを、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』の説明に従ってインストールします。

14.6.3.2 リポジトリ作成ユーティリティの実行

RCUをインストールしたら、それを使用してデータベースに移入します。次のコマンドを使用してリポジトリ作成ユーティリティを起動します。

UNIXの場合:

rcu

Windowsの場合:

rcu.exe

これらのコマンドは、RCUのORACLE_HOME/binディレクトリにあります。

1. 「リポジトリの作成」画面で、「作成」を選択し、「次へ」をクリックします。

2. 「データベース接続の詳細」画面で、次の値を指定します。

- データベース・タイプ: Oracle Database

- ホスト名: Oracle RACを使用している場合、Oracle RACノードの1つ(VIP名を使用)を入力します。

- ポート: リスナー・ポートを入力します。

- サービス名: Oracle Real Application Clustersデータベースのサービス名を入力します。

- ユーザー名: sysと入力します。

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

- ロール: SYSDBAを選択します。

3. 「前提条件の確認」画面で、前提条件を検証したら「OK」をクリックします。

4. 「コンポーネントの選択」画面で、次の値を指定します。

- 接頭辞の新規作成: データベース・スキーマに追加する接頭辞を入力します(例: MYS)。

- コンポーネント: Portal and BI > Portal and Discoverer

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

5. 「前提条件の確認」画面で、前提条件を検証したら「OK」をクリックします。

6. 「スキーマ・パスワード」画面で、各ポータル・スキーマのパスワードを入力するか、すべてのスキーマに同じパスワードを使用します。
「次へ」をクリックします。

7. 「表領域のマップ」画面で「次へ」をクリックし、デフォルトを受け入れます。

8. 「表領域の作成」画面で、「はい」をクリックし、欠落している表領域をRCUで作成できるようにします。

9. 「表領域の作成」画面で、「OK」をクリックし、表領域の作成を承認します。

10. 「サマリー」画面で、「作成」をクリックし、作成プロセスを開始します。

14.6.4 APPHOST1におけるアプリケーション層のインストールと構成

次の手順は、Oracle Portal、Forms、ReportsおよびDiscovererのインストールに適用されます。

- 第14.6.4.1項「Oracle WebLogic Serverのインストール」

- 第14.6.4.2項「Oracle Portal、Forms、ReportsおよびDiscovererのインストール」

- 第14.6.4.3項「Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成」

- 第14.6.4.4項「検証」

- 第14.6.4.5項「汎用構成」

- 第14.6.4.6項「高可用性のためのOracle Portalの構成」

- 第14.6.4.7項「高可用性のためのOracle Formsの構成」

- 第14.6.4.8項「高可用性のためのOracle Reportsの構成」

- 第14.6.4.9項「高可用性のためのOracle Discovererの構成」

14.6.4.1 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverのバイナリをインストールするには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

14.6.4.2 Oracle Portal、Forms、ReportsおよびDiscovererのインストール

Oracle Portal、Forms、Reports、およびDiscovererのバイナリをインストールするには、Oracle Fusion Middleware Oracle Portal, Forms, ReportsおよびDiscovererのインストレーション・ガイドを参照してください。

注意:

第14.6.4.3項「Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareが最新バージョンになるように、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチがMiddlewareホームに適用されていることを確認してください。

最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

14.6.4.3 Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成

Oracle Fusion Middleware構成ウィザードを起動するには、次のコマンドを実行します。

ORACLE_HOME/bin/config.sh

注意:

構成を開始する前に、次の環境変数(UNIX)が設定されていないことを確認してください。

- LD_ASSUME_KERNEL

- ORACLE_BASE

- LD_LIBRARY_PATH

次の手順を続行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「前提条件のチェック」画面で、すべての前提条件を検証したら、「次へ」をクリックします。

3. ドメインの作成画面で新しいドメインの作成を選択し、次の値を入力します。

- ユーザー名: WebLogicドメインにログインするユーザーの名前です。

- ユーザー・パスワード: ドメインのパスワードです。

- パスワードの確認: 同じパスワードを再度入力します。

- ドメイン名: ドメインの名前です(例: MyDomain)。

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

4. セキュリティ・アップデートの指定画面で、必要に応じて、OracleサポートのOracleセキュリティ・アップデートを受け取るためのユーザー名およびパスワードを入力します。

5. 「インストール場所の指定」画面で、次の値を入力します。

- WebLogicサーバーの場所: Oracle WebLogic Serverのインストール・ディレクトリを入力します。このディレクトリはMW_HOME/wlserver_10.3です。例:

/u01/app/oracle/product/FMW/wlserver_10.3

- Oracleインスタンスの場所: Oracle構成ファイルを配置するディレクトリを入力します。これは、Oracleホーム・ディレクトリの外部にする必要があります。このディレクトリは、ORACLE_INSTANCEとも呼ばれます。例:

/u01/app/oracle/admin/fmw1

- Oracleインスタンス名: fmw1

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

6. 「コンポーネントの構成」画面で、インストールと構成を行う製品を選択します。
管理コンポーネント - Enterprise Managerも選択されていることを確認します。

クラスタを選択します。

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

7. 高可用性の実装では、様々なコンポーネントで使用されるポートのすべてを複数のホスト間で同期することは必須ではありませんが、強くお薦めします。使用するポートをファイルに指定することで、自動ポート構成をバイパスできます。
ファイル名を選択してから表示/編集をクリックして、割り当てるポートを含むファイルを作成します。

サンプルのstaticports.iniファイルは、インストールのDisk1のstage/Responseディレクトリにあります。

このファイルには、次のエントリがあります。

[Domain Port No = 7001
Oracle HTTP Server Port No = 7778
WebCache Port No = 7777
WebCache Administration Port No = 9400
WebCache Statistics Port No = 9402
Web Cache Invalidation Port = 9401
Portal Managed Server Port = 7050
Reports Managed Server Port = 7051
Discoverer Managed Server Port = 7052
Forms Managed Server Port = 7053]

ファイルを保存し、「次へ」をクリックします。

8. プロキシ詳細の指定画面(Reportsのみ)で、プロキシ・サーバーを使用している場合は、この画面に詳細を入力します。
それ以外の場合は、「次へ」をクリックします。

9. スキーマの指定画面(PortalとDiscovererのみ)で、次の値を指定します。

- データベース接続文字列: 次の形式で入力します。
Oracle RACデータベースの場合:

racnode1-vip:ListenerPort:racnode2-vip:ListenerPort@mydb.mycompany.com

その他のデータベースの場合:

host:port:mydb.mycompany.com

- Portalスキーマ名: MYS_PORTAL

- Portalスキーマ・パスワード: RCUで入力したパスワードを入力します。

- Discovererスキーマ名: MYS_DISCOVERER

- Discovererスキーマ・パスワード: RCUで入力したパスワードを入力します。

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

10. ポートレット・スキーマの指定画面(PortalとDiscovererのみ)で、次の値を指定します。

- ポートレット・スキーマ名: MYS_PORTLET

- ポートレット・スキーマ・パスワード: RCUで入力したパスワードを入力します。

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

11. アプリケーション・アイデンティティ・ストアの指定画面で、次の値を指定します。

- ホスト名: Oracle Internet Directoryサーバーの名前です(例: myoid.mycompany.com)。

- ポート: Oracle Internet Directoryポートです(例: 389)。

- ユーザー名: cn=orcladmin

- パスワード: Oracle Internet Directoryのorcladminアカウントのパスワードです。

12. 「サマリー」画面で、「インストール」をクリックし、作成プロセスを開始します。

14.6.4.4 検証

次のテストを実行して、初期インストールを検証します。

テスト

URL

結果

Portal

http://apphost1.mycompany.com:7777/portal/pls/portal

Portalのホーム・ページが開きます。

Forms

http://apphost1.mycompany.com:7777/forms/frmservlet

Formsサーブレットのホーム・ページが開きます。

レポート

http://apphost1.mycompany.com:7777/reports/rwservlet/showjobs

「ジョブ・キュー」が開きます。

Discoverer

http://apphost1.mycompany.com:7777/discoverer/viewer

Discoverer Viewerのホーム・ページが開きます。

14.6.4.5 汎用構成

次の手順は、構成する製品に関係なく必要です。

14.6.4.5.1 管理サーバーのリスニング・アドレスの設定

複数のネットワーク・カードが存在するサーバーでは、使用するネットワーク・カードに管理サーバーをバインドすることが重要になります。

そのための手順は次のとおりです。

1. 次のURLを使用して、WebLogicコンソールにログインします。
http://apphost1.mycompany.com:7001/console

2. 「ドメイン構造」メニューで、「環境」、「サーバー」の順に選択します。

3. 「AdminServer (admin)」をクリックします。

4. 「チェンジ・センター」で、「ロックして編集」をクリックします。

5. 使用するネットワーク・カードを参照するDNS名にリスニング・アドレスを設定します。これは一般的にパブリック・サーバー名を指定します。

6. 「保存」をクリックします。

7. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

8. DOMAIN_HOME/binディレクトリにあるstopWebLogic.shスクリプトを使用して、管理サーバーを停止します。同じDOMAIN_HOME/binディレクトリにあるstartWebLogic.shスクリプトを使用して、管理サーバーを起動します。

14.6.4.5.2 仮想ホストの構成

サイトをロード・バランサで適切に機能させるには、2つの仮想ホストを追加する必要があります。Oracle Enterprise Manager Fusion Middleware Controlを使用して仮想ホストを構成するか、ORACLE_INSTANCE/config/OHS/ohs1/httpd.confファイルを編集するか、ORACLE_INSTANCE/config/OHS/ohs1/moduleconfディレクトリにvirtual_hosts.confというファイルを作成できます。

2つの仮想ホストをvirtual_hosts.confファイルに追加するには、テキスト・エディタで次のエントリをファイルに追加します。

NameVirtualHost *:7778
<VirtualHost *:7778>
ServerName http://mysite.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:7778>
ServerName apphost1.mycompany.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

注意:

説明:

7778は、Oracle HTTP Serverのリスニング・ポートです。

80は、ロード・バランサのリスニング・ポートです。

7777は、Web Cacheのリスニング・ポートです。

Oracle HTTP Serverが存在するサーバーの名前: apphost1

サイトがhttpプロトコルでのみ動作する場合は、ServerName HTTPを使用します。

次のコマンドを使用してWeb層を再起動します。

opmnctl stopall
opmnctl startall

14.6.4.5.3 boot.propertiesファイルの作成

APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。boot.propertiesファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。

テキスト・エディタで、DOM_HOME/servers/AdminServer/securityディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminuser
password=password

管理サーバーを再起動すると、このファイルの値が暗号化されます。このため、管理サーバーはそれをホストできる各ノードで再起動することをお薦めします。

DOMAIN_HOME/binにあるstopWebLogic.shスクリプトを使用して、管理サーバーを停止します。または、同じDOMAIN_HOME/binにあるstartWebLogic.shスクリプトを使用します。

14.6.4.5.4 sqlnet.oraの構成

ORACLE_INSTANCE/config/ディレクトリにsqlnet.oraというファイルを作成し、そのファイルに次のエントリを追加します。

TCP.CONNECT_TIMEOUT=10

これにより、妥当な長さの時間が経過すると、データベース接続がタイムアウトします。

14.6.4.5.5 Web Cacheの構成

Web Cacheは、Oracle Forms、ReportsおよびDiscovererの場合はオプションですが、Oracle Portalの場合は必須です。構成する環境でWeb Cacheを使用しない場合、次のWeb Cache構成手順は無視してください。

Enterprise Managerコンソールへのログイン

次のURLを使用して、Oracle Fusion MiddlewareのEnterprise Managerコンソールにログインします。

http://apphost1.mycompany.com:7001/em

デフォルトの「ユーザー名」および「パスワード」は、インストール中に入力されたWebLogicドメイン・ユーザー名およびパスワードと同じです。

サイトの作成

1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

2. wc1コンポーネントをクリックします。

3. ページの最上部にあるリストから「管理 - サイト」を選択します。

4. 「サイトの作成」を選択します。

5. 次の情報を入力し、サイトを追加します。

フィールド

値

ホスト名

mysite.mycompany.com

ポート

リクエストを受信するロード・バランサ上のポート番号を指定します。たとえば、HTTPリクエストの場合は80、HTTPSリクエストの場合は443です。

ロード・バランサを使用している場合、これはロード・バランサ上のリスニング・ポートです。

デフォルト・サイト

はい

サイト全体の圧縮

はい

サイト別名 - ホスト名

mysite.mycompany.com

サイト別名 - ポート

7777

サイト別名 - ホスト名

mysite.mycompany.com

サイト別名 - ポート

80 脚注 1

脚注 1 ロード・バランサがリクエストをポート80およびポート443に送信可能な場合に必要です。

6. その他のデフォルトは変更しないでください。

7. 「発行」を選択します。

8. 「OK」を選択し、各エントリを保存します。

サイトとサーバーとの間におけるマッピングの作成

1. 同じページで、「サイト・サーバー間マッピング」セクションの「作成」を選択します。

2. 次の情報を入力し、サイトを追加します。

フィールド

値

ホスト・パターン

mysite.mycompany.com

ポート・パターン

80

選択したオリジナル・サーバー

apphost1.mycompany.com:7778

3. 「OK」をクリックしてサイトを保存します。

4. mysite.mycompany.com:443/80のサイトが、サイトとサーバーとの間におけるマッピングのリストにあることを確認します。

5. 「適用」をクリックして変更を保存します。

セッション・バインディングの有効化

Oracle Web Cacheのセッション・バインディング機能は、ユーザー・セッションを特定のオリジナル・サーバーにバインドし、一定の期間、状態を維持するために使用します。デフォルトのOracle Fusion Middleware中間層で実行されているコンポーネントはほとんどすべてステートレスですが、Oracle Portalにはセッション・バインディングが必要です。

セッション・バインディングを有効化すると、すべてのユーザー・リクエストが特定のOracle Portal中間層に送信されます。その結果、ポータル・キャッシュのキャッシュ・ヒット率が高くなります。

次の手順に従って、セッション・バインディングを有効化します。

1. ページの上部にある「管理 - セッション構成」を選択します。

2. ドロップダウン・リストからmysite.mycompany.com:443/80のサイトを選択します。

3. 「セッション・バインディング」セクションで、「Set-Cookieを使用したCookieに基づくセッション・バインディング」を選択します。

4. 「適用」をクリックして変更を保存します。

14.6.4.5.6 Web Cacheパスワードの変更

Web Cacheパスワードはランダムに生成されますが、後の段階で必要になります。したがって、Web Cacheパスワードをデフォルト値から新しい既知の値に変更することをお薦めします。

デフォルトのパスワードを変更する手順は、次のとおりです。

1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

2. wc1コンポーネントをクリックします。

3. ページの最上部にあるドロップダウン・リストから「管理 - パスワード」を選択します。

4. 新しい無効化パスワードと管理パスワードを入力してからそれらを確認し、「適用」をクリックします。

14.6.4.5.7 Web層(Oracle HTTP ServerおよびWeb Cache)の再起動

前述の変更を行った後、次のコマンドを使用してWeb層コンポーネントを再起動します。

opmnctl stopall
opmnctl startall

14.6.4.5.8 シングル・サインオン・サーバーでの登録

シングル・サインオン・サーバーから次の手順を実行します。

1. ORACLE_HOME変数をシングル・サインオン・サーバーのORACLE_HOMEの場所に設定します。

2. 次のパラメータを指定して、ORACLE_HOME/sso/bin/ssoreg.sh(Windowsの場合はssoreg.bat)を実行します。

-site_name mysite.mycompany.com
-mod_osso_url http://mysite.mycompany.com
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier

3. /tmp/osso.confを中間層のホームの場所にコピーします。それは次の場所です。

ORACLE_INSTANCE/config/OHS/ohs1

4. 次のコマンドを使用してAPPHOST1上のOracle HTTP Serverを再起動します。

opmnctl restartproc process-type=OHS

5. 次のURLを使用してシングル・サインオン・サーバーにログインします。

http://login.mycompany.com/pls/orasso

6. 「管理」ページに移動してから、「パートナ・アプリケーション管理」ページに移動します。apphost1.mycompany.comのエントリを削除します。

14.6.4.5.9 WebLogicプラグインの有効化

セキュリティのために、ドメインに対してWebLogicプラグイン有効化フラグをオンにします。そのためには、次の手順に従ってください。

Oracle Web TierはOracle WebLogic Serverの前面に配置され、Oracle HTTP ServerからOracle WebLogic管理対象サーバーにリクエストをルーティングします。このシナリオでは、Oracle WebLogicプラグインが使用されていることをWebLogicが認識する必要があります。そのための手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、ドメイン名をクリックします。

3. 「Webアプリケーション」タブをクリックします。

4. 「ロックして編集」をクリックします。

5. 「WebLogicプラグインの有効化」ボックスを選択します。

6. 変更を保存およびアクティブ化します。

7. 管理サーバーを再起動します。

14.6.4.5.10 WebLogicにおけるホスト・アサーションの変更

Oracle HTTP Serverは、WebLogicのプロキシとして機能するため、デフォルトでは、特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。

1. 次のURLを使用して、管理コンソールにログインします。

http://apphost1.mycompany.com:7001/console

2. ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. クラスタ名(cluster_portal、cluster_forms、cluster_reports、cluster_disco)をクリックします。

5. 「HTTP」を選択し、次の値を入力します。

パラメータ

値

フロントエンド・ホスト

mysite.mycompany.com

フロントエンドHTTPポート

80

フロントエンドHTTPSポート

443

これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート443または80に送られます。

6. 「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックし、変更を保存します。

7. 次の手順を使用して、WLS_PORTAL、WLS_FORMS、WLS_REPORTS、WLS_DISCOの管理対象サーバーを再起動します。

1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」タブを選択します。

3. 各管理対象サーバーの横にあるボックスを選択します。

4. 「停止」→「ただちに強制停止」を選択します。

5. 「はい」をクリックし、管理対象サーバーを停止します。

6. 管理対象サーバーが停止したら、その管理対象サーバーの横にあるボックスを選択します。

7. 「起動」をクリックします。

8. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.6 高可用性のためのOracle Portalの構成

次の手順は、Oracle Portalの構成にのみ必要です。

14.6.4.6.1 Portalリポジトリのリワイヤ

次の手順に従って、Oracle Portalリポジトリをリワイヤします。

1. Oracle Fusion Middleware Enterprise Managerで次のURLを使用してドメインにログインします。

http://apphost1.example.com:7001/em

2. 左側にある「Fusion Middleware」メニューを開きます。

3. 「Portal」メニューを開きます(「Fusion Middleware」メニューの下にあります)。

4. 「Portal」をクリックします。

5. 「Portal」を右クリックして、「設定」、「ワイヤ構成」を選択します。

6. Portal中間層に次の情報を入力します。

パラメータ

値

ホスト

ロード・バランサのDNS名を入力します。たとえば、mysite.mycompany.comとします。

ポート

ロード・バランサがリスニングするポートを入力します。たとえば、SSLターミネーションまたはSSL有効化サイトの場合は443、HTTPの場合は80です。

SSLプロトコル

SSLターミネーションまたはSSL有効化サイトを使用している場合、これを選択します。

7. Web Cacheについて次の情報を入力します。

パラメータ

値

ホスト

ロード・バランサのDNS名を入力します。たとえば、mysite.mycompany.comとします。

無効化ポート

ロード・バランサで構成されているとおりにPortal無効化ポートを入力します(例: 9401)。

無効化ユーザー名

Portal無効化に使用されるユーザー名を入力します(例: invalidator)。

無効化パスワード

前述のアカウントのパスワードです。

このパスワードの値が不明な場合、前述のようにEnterprise Managerで変更できます。

8. 「適用」をクリックし、リワイヤを開始します。

9. リワイヤが完了したら、「Portal」メニューのオプションを再度クリックします。

10. 次のようにPortalのURLが表示されていることを確認します。

http://mysite.mycompany.com:80/portal/pls/portal

14.6.4.6.2 ロード・バランサでのParallel Page Engineループバックの構成

Parallel Page Engine(PPE Servlet)の目的は、ユーザーによってリクエストされたページを構成することです。これは、ユーザーからページ・リクエストを受信し、ページの各部分すべてを並行してフェッチするように独自の新しいリクエストを実行し、これらの部分を1つのページ・ファイルにアセンブルし、ページ・コンテンツをエンド・ユーザーに送り返す(またはクライアント・ブラウザに送り返す)ことにより行います。

これらの内部リクエストは、組織内部に保持され、HTTPプロトコルを使用してサービスが処理されます。

次の手順は、ロード・バランサを使用している場合にのみ必要です。

1. 次のURLを使用してOracle Fusion Middleware Enterprise Managerにログインします。

http://apphost1.example.com:7001/em

2. 左側にあるオブジェクト・ブラウザから「Fusion Middleware」→「Classic」→「Portal」を選択します。

3. 「Portal」を右クリックして、「設定」→「ページ・エンジン」を選択します。

4. 「拡張プロパティ」セクションで、次の情報を追加します。

パラメータ

値

ポートの使用

内部ループバックのポート番号を選択します(例: 7777)このポートは、内部リクエスト用にロード・バランサで構成されます。

スキームの使用

HTTPの値に変更します。

5. 「適用」をクリックして設定を保存します。

6. 次のようにOracle WebLogic管理コンソールからWebLogic管理対象サーバーを再起動します。

1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」タブを選択します。

3. WLS_PORTAL管理対象サーバーの横にあるボックスを選択します。

4. 「停止」→「ただちに強制停止」を選択します。

5. 「はい」をクリックし、管理対象サーバーを停止します。

6. 管理対象サーバーが停止したら、その管理対象サーバーの横にあるボックスを選択します。

7. 「起動」をクリックします。

8. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.6.3 データベース・ウォレットとポータル

SSLを使用している場合、Oracle Portalでは、ポータル・スキーマが配置されているデータベースにウォレットが存在している必要があります。このウォレットには、ロード・バランサまたはサイトの証明書が格納されます。ウォレットを作成したら、Oracle Portalにその場所を認識させる必要があります。

注意:

この手順は、SSLターミネーションまたはサイトSSLを使用している場合にのみ必要です。

データベース・ウォレットの作成

このプロセスを開始する前に、証明書をデータベース・サーバーにコピーします。

この方法は、ブラウザによってわずかに異なります。Firefoxブラウザの場合は次のようになります。

1. ブラウザを使用してhttps://mysite.mycompany.comのURLにアクセスします。

2. Firefox→「プリファレンス」→「拡張」→「暗号化」→「証明書の表示」に移動します。

3. mysite.mycompany.comの証明書を選択してから、エクスポートを選択してファイルの名前を指定します。

4. このファイルをデータベース・サーバーにコピーします。

5. 必要に応じて証明書を保存します。

6. 証明書のコピーを取得したら、各データベース・サーバーでウォレットを作成し、この証明書をデータベース・サーバーからOracle Wallet Managerを使用してインポートします。これは、すべてのOracle RACノードに対して次の手順に従って実行する必要があります。

1. owmと入力し、Oracle Wallet Managerを起動します。

2. 「ウォレット」→「新規」を選択します。

3. デフォルトの場所にウォレットを作成しないので、「いいえ」を選択します。

4. ウォレットのパスワードを入力します(このパスワードは後で必要になるので覚えておいてください)。

5. ウォレットのタイプを「標準」に設定します。

6. この時点で証明書を作成するかどうかという質問に対して「いいえ」を選択します。

7. Oracle Wallet Managerで、「操作」→「信頼できる証明書のインポート」を選択します。

8. 「証明書を含むファイルを選択」を選択し、「OK」をクリックします。

9. 前の手順で選択した証明書ファイルを選択し、「インポート」をクリックします。

10. 「ウォレット」および「別名保存」を選択します。

11. ウォレットの場所を選択します。例:

ORACLE_BASE/admin/DB_NAME/wallet

12. 他のOracle RACデータベース・ノードに対してもこの手順を繰り返します。
すべてのデータベース・ノードで同じディレクトリ・パスを使用する必要があります。

ポータルに対するウォレットの識別

データベース・ウォレット内に証明書を格納したら、次の手順に従ってポータル・リポジトリ内にウォレットの場所を格納します。

1. SQL*Plusスクリプトのsecwc.sqlを実行します。これは次のディレクトリにあります。

ORACLE_HOME/portal/admin/plsql/wwc

ORACLE_HOME/network/adminにあるtnsnames.oraファイルにデータベース・エントリを作成することが必要な場合もあります。

SQL> @secwc 'file:$ORACLE_BASE/admin/DB_NAME/wallet' 'walletpassword'

前述のコマンドでは、次のようにします。

- ウォレットへの絶対パスを使用します。環境変数は使用しません。

- walletpasswordは、ウォレットのパスワードです。

- ウォレット・ファイル自体ではなくウォレット・ディレクトリへのパスを使用します。キーワード・ファイルが必要です。

14.6.4.6.4 すべてのコンポーネントの再起動

前の項の変更を行った後、Web層コンポーネントを再起動する必要があります。この項では、コンポーネントを再起動する手順について説明します。

Webコンポーネントの再起動

次のコマンドを使用してOracle HTTP Serverを再起動します。

opmnctl stopall
opmnctl startall

WLS_Portalの再起動

WebLogic管理コンソールにログインし、次の手順に従って管理対象サーバーのWLS_PORTALを再起動します。

1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」タブを選択します。

3. WLS_PORTAL管理対象サーバーの横にあるボックスを選択します。

4. 「停止」→「ただちに強制停止」を選択します。

5. 「はい」をクリックし、管理対象サーバーを停止します。

6. 管理対象サーバーが停止したら、そのWLS_PORTAL管理対象サーバーの横にあるボックスを選択します。

7. 「起動」をクリックします。

8. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.6.5 Oracle RACでのポータルのインストールに対するインストール後の手順

ポータルおよびポートレット・コンポーネントに対して作成される個々のデータ・ソースの初期容量を0に設定することをお薦めします。管理コンソールを使用してこれらのデータ・ソースの初期容量を0に設定してください。

14.6.4.6.6 構成の検証

構成を検証するには、次のテストを実行します。

テスト

URL

結果

ロード・バランサを使用したPortalのテスト

http://mysite.mycompany.com/portal/pls/portal

Portalのホーム・ページが開きます。

シングル・サインオンのエラーのトラブルシューティング

構成のこの段階でシングル・サインオンのエラー・メッセージがPortalフロント画面に表示された場合、データベースのウォレットが適切に作成されていないか、その正しい場所がOracle Portalに認識されていない可能性があります。

このエラーが表示された場合、データベースのウォレットを作成する手順とその後にポータルで識別する手順を繰り返します。

14.6.4.7 高可用性のためのOracle Formsの構成

次の手順は、Oracle Formsの構成にのみ使用します。

14.6.4.7.1 カスタマ・データベースのTNSNAMESエントリの作成

アプリケーションで1つ以上のデータベースにアクセスする場合、アクセスされる各データベースのエントリをtnsnames.oraファイルに配置する必要があります。

各データベースのエントリをファイルに配置する手順は次のとおりです。

1. ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

mydb.mycompany.com =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = mydb.mycompany.com)
)
)

注意:

これは、Oracle RACデータベース接続文字列です。

2. ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。

tnsping mydb.mycompany.com

注意:

前述のtnspingコマンドを発行する前に、TNS_ADMIN環境変数を設定してください。

14.6.4.7.2 WLS_FORMSの再起動

WebLogic管理コンソールにログインし、次の手順に従って管理対象サーバーのWLS_FORMSを再起動します。

1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」タブを選択します。

3. WLS_FORMS管理対象サーバーの横にあるボックスを選択します。

4. 「停止」→「ただちに強制停止」を選択します。

5. 「はい」をクリックし、管理対象サーバーを停止します。

6. 管理対象サーバーの停止後に、WLS_FORMS管理対象サーバーの横のボックスを選択します。「起動」をクリックします。

7. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.7.3 構成の検証

構成を検証するには、次のテストを実行します。

テスト

URL

結果

ロード・バランサのテスト

http://mysite.mycompany.com/

ホーム・ページが開きます。

Forms

http://mysite.mycompany.com/forms/frmservlet

Formsサーブレットのホーム・ページが開きます。

14.6.4.8 高可用性のためのOracle Reportsの構成

次の手順は、Oracle Reportsの構成にのみ必要です。

14.6.4.8.1 データベースにおけるレポート・キューの作成

複数のReports Serverインスタンス間で整合性のあるレポート・キューを保持し、レポート・サーバーの障害に対するリジリエンスを持たせるには、高可用性のReal Application Clustersデータベースにレポート・キューを作成します。

レポート・キューを作成するには、SQL*Plusスクリプトのrw_server.sqlをデータベースに対して実行します。

このスクリプトは、次のディレクトリにあります。

ORACLE_HOME/reports/admin/sql

次の手順を実行します。

1. 次のコマンドを使用して、データベース内にレポート・キューを保持するユーザーを作成します。

sql> create user report_queue identified by MYSpassword;
sql> grant connect, resource,create view to report_queue;

2. そのレポート・ユーザーに接続し、次のスクリプトを実行します。

cd ORACLE_HOME/reports/admin/sql
sqlplus reports_queue/MYpasswd@rw_server.sql

14.6.4.8.2 レポート・キューのTNSNAMESエントリの作成

Oracle Reportsでは、tnsnames.oraファイルのエントリを使用して、データベース接続情報を判別します。次の手順に従って、レポート・キュー・データベースのエントリをこのファイルに配置します。

1. ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

myrepq.mycompany.com =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = myrepq.mycompany.com)
)
)

注意:

これは、Oracle RACデータベース接続文字列です。

2. ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。

tnsping myrepq.mycompany.com

注意:

tnspingコマンドを使用する前に、TNS_ADMIN環境変数を設定してください。

14.6.4.8.3 レポート・キューのセキュリティ・キーの作成

Oracle Reportsのセキュリティは、間接的モデルを使用して実行されます。データベース・レポート・キューを使用するようにレポート・サーバーを構成する前に、次の手順に従ってレポート・キューのパスワードを保持するエントリをWebLogicに作成します。

1. 次のURLを使用してOracle Fusion Middleware Enterprise Managerにログインし、求められたらWebLogic管理者ユーザーおよびパスワードを入力します。

http://apphost1.mycompany.com:7001/em

2. 左側にあるナビゲーション・ツリーで、WebLogicDomainを開き、ドメインの名前(たとえばReportsDomain)をクリックします。
ReportsDomain概要ページが表示されます。

3. ページの最上部にあるドロップダウン・メニューから「セキュリティ」→「資格証明」を選択します。

4. 「キーの作成」をクリックします。

5. 次の情報を入力します。

パラメータ

値

マップの選択

reports

キー

queuePassword

タイプ

パスワード

ユーザー名

report_queue

パスワード

レポート・キュー・アカウントのパスワード

説明

レポート・キュー・アカウントの説明

6. 終了したら、「OK」をクリックします。

14.6.4.8.4 インプロセスReports Serverのデータベース・ジョブ・リポジトリの構成

レポート・キューをデータベースに配置したら、それにアクセスする方法をレポート・サーバーに認識させる必要があります。

そのためには、rwserver.confファイルを編集します。

このファイルは、次のディレクトリにあります。

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configuration/

サーバー構成ファイルではエントリの順序は固定しています。rwserver.confファイルの<jobStatusRepository>要素の直後に次の要素を追加します。

<jobRepository>
<property name="dbuser" value="dbuser"/>
<property name="dbpassword" value="csf:reports:dbpasswdKey"/>
<property name="dbconn" value="dbconn"/>
</jobRepository>

説明:

- dbuserは、レポート・キューが配置するスキーマの名前です。

- dbconnは、ORACLE_INSTANCE/configディレクトリにあるtnsnames.oraファイルのデータベース・エントリを参照します。

例:

<jobRepository>
<property name="dbuser" value="report_queue"/>
<property name="dbpassword" value="csf:reports:queuePassword"/>
<property name="dbconn" value="myrepq.mycompany.com"/>
</jobRepository>

14.6.4.8.5 共有出力ディレクトリにアクセスするためのReports Serverの構成

次のディレクトリにあるrwserver.confファイルの<cache>要素にCacheDirプロパティまたはJOCCacheDirプロパティを追加します。

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configuration/

例:

<property name="JOCCacheDir" value="folder_name"/>
<property name="CacheDir" value="folder_name"/>

UNIXの場合:

<cache class="oracle.reports.cache.RWCache">
<property name="cacheSize" value="50"/>
<!--property name="cacheDir" value="your cache directory"/-->
<!--property name="maxCacheFileNumber" value="max number of cache files"/-->
<property name="JOCCacheDir" value="/share/reports"/>
<property name="CacheDir" value="/share/reports"/>
</cache>

14.6.4.8.6 WLS_REPORTSの再起動

管理対象サーバーのWLS_REPORTSを再起動するには、WebLogic管理コンソールにログインし、次の手順に従います。

1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」タブを選択します。

3. WLS_REPORTS管理対象サーバーの横にあるボックスを選択します。

4. 「停止」→「ただちに強制停止」を選択します。

5. 「はい」をクリックし、管理対象サーバーを停止します。

6. 管理対象サーバーが停止したら、そのWLS_REPORTS管理対象サーバーの横にあるボックスを選択します。

7. 「起動」をクリックします。

8. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.8.7 構成の検証

次のテストを実行して、初期Reports構成を検証します。

テスト

URL

結果

レポート・キュー

http://mysite.mycompany.com/reports/rwservlet/showjobs

「シングル・サインオン」画面と、その後にレポート・キューが開きます。

代替テストのために、Oracle Technology Networkからサンプル・レポートをダウンロードし、それを実行します。Oracle Technology NetworkのURLは、次のとおりです。

http://www.oracle.com/technology/index.html

14.6.4.9 高可用性のためのOracle Discovererの構成

Oracle Discovererの高可用性を構成する場合にのみ、次の手順に従います。

14.6.4.9.1 カスタマ・データベースのTNSNAMESエントリの作成

アプリケーションで1つ以上のデータベースにアクセスする場合、次の手順に従って、アクセスされる各データベースのエントリをtnsnames.oraファイルに配置します。

1. ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

mydb.mycompany.com =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = mydb.mycompany.com)
)
)

注意:

これは、Oracle RACデータベース接続文字列です。

2. ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。

tnsping mydb.mycompany.com

注意:

tnspingコマンドを発行する前に、TNS_ADMIN環境変数を設定してください。

14.6.4.9.2 configuration.xmlの更新

configuration.xmlには、Discovererの構成の情報が格納されています。このファイルは、次のディレクトリにあります。

DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/

applicationURL=で始まる行を更新し、そのURLを次のように変更します。

http://mysite.mycompany.com/discoverer

例:

applicationURL="http://mysite.mycompany.com/discoverer">

14.6.4.9.3 Discoverer ViewerおよびWeb Cache

デフォルトでは、Discoverer Viewerは、Oracle Web Cacheを十分に活用するように構成されていません。これを有効にすると、パフォーマンスを大幅に向上させることができます。ただし、この機能を有効にすることが適切でない場合もあります。

Discoverer ViewerをOracle Web Cacheとともに使用可能にする場合とその方法の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscoverer ViewerをOracle Web Cacheとともに使用する方法に関する項を参照してください。

14.6.4.9.4 シングル・サインオンの有効化

デフォルトでは、Discovererはシングル・サインオンで保護されていません。Discoverer PlusおよびViewerを保護するには、次の手順を実行します。

1. mod_osso.confファイルを編集します。これは、次のディレクトリにあります。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

2. ファイルにおいて</IfModule>で始まる行の前に次の行を追加します。

<Location /discoverer/plus>
require valid-user
AuthType Osso
</Location>

<Location /discoverer/viewer>
require valid-user
AuthType Osso
</Location>

<Location /discoverer/app>
require valid-user
AuthType Osso
</Location>

14.6.4.9.5 すべてのコンポーネントの再起動

前の項の変更を行った後、この項で説明する手順を使用してWeb層コンポーネントを再起動します。

Webコンポーネントの再起動

次のコマンドを使用して、Oracle HTTP Serverを再起動します。

opmnctl stopall
opmnctl startall

WLS_DISCOの再起動

WebLogic管理コンソールにログインし、次の手順に従って管理対象サーバーのWLS_DISCOを再起動します。

1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」タブを選択します。

3. WLS_DISCO管理対象サーバーの横にあるボックスを選択します。

4. 「停止」→「ただちに強制停止」を選択します。

5. 「はい」をクリックし、管理対象サーバーを停止します。

6. 管理対象サーバーが停止したら、そのWLS_DISCO管理対象サーバーの横にあるボックスを選択します。

7. 「起動」をクリックします。

8. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.9.6 構成の検証

次のテストを実行して、初期Discoverer構成を検証します。

テスト

URL

結果

ロード・バランサのテスト

http://mysite.mycompany.com/

ホーム・ページが開きます。

Discoverer

http://mysite.mycompany.com/discoverer/viewer

「シングル・サインオン」画面と、その後にDiscoverer Viewerが開きます。

14.6.5 APPHOST2におけるアプリケーション層のインストールと構成

次の項では、APPHOST2にアプリケーション層をインストールおよび構成する方法について説明します。

- 第14.6.5.1項「Oracle WebLogic Serverのインストール」

- 第14.6.5.2項「Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアのインストール」

- 第14.6.5.3項「Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成」

- 第14.6.5.4項「汎用構成」

- 第14.6.5.5項「高可用性のためのOracle Portalの構成」

- 第14.6.5.6項「高可用性のためのOracle Formsの構成」

- 第14.6.5.7項「高可用性のためのOracle Reportsの構成」

- 第14.6.5.8項「高可用性のためのOracle Discovererの構成」

14.6.5.1 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverのバイナリをインストールするには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

14.6.5.2 Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアのインストール

Oracle Portal、Forms、Reports、およびDiscovererのバイナリをインストールするには、Oracle Fusion Middleware Oracle Portal, Forms, ReportsおよびDiscovererのインストレーション・ガイドを参照してください。

注意:

第14.6.5.3項「Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成」の説明に従って構成ウィザードを実行する前に、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチがMiddlewareホームに適用されていることを確認してください。

最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

14.6.5.3 Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成

次のコマンドを実行してOracle Fusion Middleware構成ウィザードを起動します。

ORACLE_HOME/bin/config.sh

注意:

構成を開始する前に、次の環境変数(UNIX)が設定されていないことを確認してください。

- LD_ASSUME_KERNEL

- ORACLE_BASE

- LD_LIBRARY_PATH

次の手順を続行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「前提条件のチェック」画面で、すべての前提条件を検証したら、「次へ」をクリックします。

3. ドメインの作成画面で「クラスタを開く」を選択し、次の値を入力します。

- ホスト名: WebLogic管理サーバーを実行しているホストの名前です(例: APPHOST1.mycompany.com)。

- ポート: 管理サーバーのポートです。たとえば、7001とします。

- ユーザー名: 管理サーバーの管理者アカウント名です。

- User Password: 管理サーバーの管理者アカウント用パスワードです。

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

4. セキュリティ・アップデートの指定画面で、必要に応じて、OracleサポートのOracleセキュリティ・アップデートを受け取るためのユーザー名およびパスワードを入力します。

5. 「インストール場所の指定」画面で、次の値を入力します。

- WebLogicサーバーの場所: Oracle WebLogic Serverのインストール・ディレクトリを入力します。これはMW_HOME/wlserver_10.3です。例:

/u01/app/oracle/product/FMW/wlserver_10.3

- Oracleインスタンスの場所: Oracle構成ファイルを配置するディレクトリを入力します。これは、Oracleホーム・ディレクトリの外部にする必要があります。このディレクトリは、ORACLE_INSTANCEとも呼ばれます。例:

/u01/app/oracle/admin/fmw2

- Oracleインスタンス名: fmw2

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

6. 「コンポーネントの構成」画面で、インストールと構成を行う製品を選択します。Oracle Web CacheやOracle HTTP Serverをこのノードに配置する場合、選択されていることを確認します。

注意:

これは、APPHOST1で選択したものと同じリストにする必要があります。

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

7. APPHOST1に使用されたものと同じstaticports.iniファイルを選択します。

8. アプリケーション・アイデンティティ・ストアの指定画面で、次の値を指定します。

- ホスト名: Oracle Internet Directoryサーバーの名前です(例: login.myoid.com)。

- ポート: Oracle Internet Directoryポートです(例: 389)。

- ユーザー名: cn=orcladmin

- パスワード: Oracle Internet Directoryのorcladminアカウントのパスワードです。

9. 「サマリー」画面で、「インストール」をクリックし、作成プロセスを開始します。

14.6.5.4 汎用構成

次の手順は、構成するコンポーネントに関係なく必要です。

14.6.5.4.1 APPHOST1からの構成情報のコピー

クラスタを開く操作により新しいWebLogic管理対象サーバーおよび関連付けられたマシンが作成されたら、APPHOST1からAPPHOST2にいくつかの構成情報をコピーする必要があります。

APPHOST1上にある次のファイルを、次の表に示すAPPHOST2の場所にコピーします。

ファイル

APPHOST1の場所

APPHOST2の場所

mod_oradav.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

mod_osso.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

plsql.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

portal.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

forms.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

reports_ohs.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

module_disco.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

virtual_hosts.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

osso.conf

ORACLE_INSTANCE/config/OHS/ohs1/

ORACLE_INSTANCE/config/OHS/ohs1/

sqlnet.ora

ORACLE_INSTANCE/config

ORACLE_INSTANCE/config

tnsnames.ora

ORACLE_INSTANCE/config

ORACLE_INSTANCE/config

14.6.5.4.2 仮想ホストの構成

サイトをロード・バランサで適切に機能させるには、2つの仮想ホストを追加する必要があります。Oracle Enterprise Manager Fusion Middleware Controlを使用して仮想ホストを構成するか、ORACLE_INSTANCE/config/OHS/ohs1/httpd.confファイルを編集するか、ORACLE_INSTANCE/config/OHS/ohs1/moduleconfディレクトリにあるvirtual_hosts.confファイル(APPHOST1からコピー)を編集できます。

テキスト・エディタでファイルを更新し、APPHOST1をAPPHOST2に変更します。

NameVirtualHost *:7778
<VirtualHost *:7778>
ServerName http://mysite.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:7778>
ServerName apphost2.mycompany.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

14.6.5.4.3 クラスタ対応にするためのOracle HTTP Server構成の更新

インストールが最初に作成されると、APPHOST1に配置されるように最初に作成された管理対象サーバーにすべてのWeb Logicリクエストが転送されるように構成されていました。ここではAPPHOST2が存在するので、APPHOST1とAPPHOST2の両方のOracle HTTP Serverを、すべてのOracle WebLogic管理対象サーバーで認識させる必要があります。

Oracle HTTP ServerにAPPHOST2を認識させるには、次のディレクトリにあるファイルを編集します。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

次の表に示すように、Portal、Forms、ReportsおよびDiscovererのそれぞれに対して異なるファイルを編集します。

製品

ファイル

Portal

portal.conf

Forms

forms.conf

レポート

reports_ohs.conf

Discoverer

module_disco.conf

次のようにファイルを編集します。

1. WebLogicHostやWebLogicPortで始まる行を削除し、次の行を追加します。

WebLogicCluster apphost1:9001,apphost2:9001

2. WebLogicClusterで始まる行をすべて、次のような行に変更します。

WebLogicCluster apphost1:9001,apphost2:9001

たとえば、次のような行を探して変更します。

<Location /portal>
SetHandler weblogic-handler
WebLogicHost apphost1.mycompany.com
WebLogicPort PORT
</Location>

前述の行を次のように変更します。

<Location /portal>
SetHandler weblogic-handler
WebLogicCluster apphost1.mycompany.com:PORT,apphost2.mycompany.com:PORT
</Location>

次のような行を探して変更します。

<Location /Forms>
SetHandler weblogic-handler
WebLogicCluster apphost1.mycompany.com:PORT
</Location>

前述の行を次のように変更します。

<Location /Forms>
SetHandler weblogic-handler
WebLogicCluster apphost1.mycompany.com:PORT,apphost2.mycompany.com:PORT
</Location>

これらの手順をAPPHOST2上で繰り返します。

14.6.5.4.4 Web Cacheパスワードの変更

Web Cacheパスワードはランダムに生成されますが、後の段階で必要になります。したがって、Web Cacheパスワードをデフォルト値から新しい既知の値に変更することをお薦めします。

デフォルトのパスワードを変更する手順は、次のとおりです。

1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

2. wc1コンポーネントをクリックします。

3. ページの最上部にあるドロップダウン・リストから「管理 - パスワード」を選択します。

4. 新しい無効化パスワードと管理パスワードを入力してからそれらを確認し、「適用」をクリックします。

注意:

この手順で使用するパスワードは、APPHOST1で使用するパスワードと同一である必要があります。これは、後の手順でWebキャッシュをまとめてクラスタ化するために必要です。

14.6.5.4.5 Web Cacheの構成

Web Cacheは、Oracle Forms、ReportsおよびDiscovererの場合はオプションですが、Oracle Portalの場合は必須です。APPHOST1でWeb Cacheを構成しなかった場合、次のWeb Cache構成手順は無視してください。

Enterprise Managerコンソールへのログイン

次のURLを使用して、Enterprise Managerコンソールにログインします。

http://apphost1.mycompany.com:7001/em

デフォルトの「ユーザー名」および「パスワード」は、インストール中に入力されたWebLogicドメイン・ユーザー名およびパスワードと同じです。

オリジナル・サーバーの作成

オリジナル・サーバーを作成する手順は次のとおりです。

1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

2. wc1コンポーネントをクリックします(これがAPPHOST1と関連付けられているものであることを確認します)。

3. ページの最上部にあるドロップダウン・リストから「管理 - オリジナル・サーバー」を選択します。

4. 「作成」をクリックします。

5. 次の情報を入力し、オリジナル・サーバーを追加します。

フィールド

値

ホスト

APPHOST2.mycompany.com

ポート

7778

許容量

100

プロトコル

HTTP

フェイルオーバーのしきい値

5

pingのURL

/

pingの間隔

10

6. 「OK」をクリックして変更を保存します。

7. 「適用」をクリックして変更を保存します。

既存のサイトからサーバーへのマッピングへのオリジナル・サーバーの追加

サイトからサーバーへのマッピングにオリジナル・サーバーを追加する手順は次のとおりです。

1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

2. wc1コンポーネントをクリックします(これがAPPHOST1と関連付けられているものであることを確認します)。

3. ページの最上部にあるドロップダウン・リストから「管理 - サイト」を選択します。

4. 「サイトからサーバーへのマッピング」セクションで<ホスト:ポート>をクリックします。例:

mysite.mycompany.com:80

5. 「編集」をクリックします。

6. オリジナル・サーバーのAPPHOST2.mycompany.com:7778を選択してから、選択したオリジナル・サーバー・リストに移動します。

7. 「OK」をクリックして変更を保存します。

8. 「適用」をクリックして変更を保存します。

APPHOST1およびAPPHOST2におけるWeb Cacheのクラスタ化

APPHOST1およびAPPHOST2上でOracle Web Cacheをクラスタ化する手順は次のとおりです。

注意:

Oracle Web Cacheのクラスタリングを適切に機能させるには、まとめてクラスタ化されたWeb Cacheそれぞれの管理パスワードが同一である必要があります。

1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

2. wc1コンポーネントをクリックします(これがAPPHOST1と関連付けられているものであることを確認します)。

3. ページの最上部にあるドロップダウン・リストから「管理 - クラスタ」を選択します。

4. 「追加」をクリックします。
APPHOST2のWeb Cacheが自動的に追加されます。

5. 「適用」をクリックして変更を適用します。

6. 新しく作成されたWeb Cacheエントリをクリックします(エントリのURL部分をクリックしないようにしてください)。

7. 「同期化」をクリックし、構成をAPPHOST2上のWeb Cacheにコピーします。

8. 操作を実行することの確認を求められたら「はい」をクリックします。

9. 「適用」をクリックして新しい構成を適用します。

14.6.5.4.6 APPHOST1およびAPPHOST2上のWebプロセスの再開

前述の変更を行った後、各サーバー上で次のコマンドを使用して、APPHOST1およびAPPHOST2上のWeb層コンポーネントを再起動します。

opmnctl stopall
opmnctl startall

14.6.5.5 高可用性のためのOracle Portalの構成

この項で説明する手順は、高可用性のためのOracle Portalの構成にのみ使用します。

14.6.5.5.1 APPHOST1からの構成情報のコピー

クラスタを開く操作により、新しいWebLogic管理対象サーバーおよび関連付けられたマシンが作成されますが、APPHOST1からAPPHOST2にいくつかの構成情報をコピーする必要があります。

APPHOST1上にある次のファイルを、次の表に示すAPPHOST2の場所にコピーします。

ファイルまたはディレクトリ

APPHOST1の場所

APPHOST2の場所

ORACLE_HOME/portal

ORACLE_HOME/portal

ORACLE_HOME/portal

appConfig.xml

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/

portal_cache.conf

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/

portal_dads.conf

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/

portal_plsql.conf

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/

14.6.5.5.2 Portalディレクトリの作成

APPHOST2上に次のディレクトリを作成するとOracle Portal Cacheの記憶域にできます。

ORACLE_INSTANCE/portal/cache
ORACLE_INSTANCE/diagnostics/logs/portal

14.6.5.5.3 インスタンス・パスの更新

次の2つのコピー・ファイルにおいて、ハードコードされたエントリを編集し、前述のパスを反映するようにします。

- portal_cache.confファイルで、PlsqlCacheDirectoryを変更します。

- portal_plsql.confファイルで、PlsqlLogDirectoryを変更します。

これらのファイルは、DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configurationディレクトリにあります。

14.6.5.5.4 Webプロセスの再開

各サーバー上で次のコマンドを使用し、APPHOST2上のWeb層コンポーネントを再起動します。

opmnctl stopall
opmnctl startall

14.6.5.5.5 WLS_PORTAL1の起動

これで、アプリケーション・ファイルが全体にコピーされました。次の手順で、管理対象サーバーのWLS_PORTAL1を起動します。

1. 次のURLを使用してAPPHOST1上の管理サーバーにログインします。

http://APPHOST1.mycompany.com:7001/console

2. WebLogic管理コンソールのログイン資格証明を入力します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブを選択します。

5. 管理対象サーバーWLS_PORTAL1の横にあるボックスを選択し、「停止 - ただちに強制停止」をクリックします。

6. 「はい」をクリックして操作を確認します。
これにより、サーバーの状態がリセットされます。

14.6.5.5.6 構成の検証

構成を検証する手順は次のとおりです。

テスト

URL

結果

ロード・バランサを経由したPortalのテスト

http://mysite.mycompany.com/portal/pls/portal

Portalのホーム・ページが開きます。

ロード・バランサを経由したPortalログインのテスト

http://mysite.mycompany.com/portal/pls/portal

orcladminアカウントを使用してログインできる必要があります。

14.6.5.5.7 ベスト・プラクティス

デフォルトでは、構成情報はすべてのサーバー・インスタンスに自動的に伝播されません。1台のポータル・サーバー上で構成ファイルが変更された場合、その構成をすべてのサーバーに伝播するようにしてください。

14.6.5.6 高可用性のためのOracle Formsの構成

この項で説明する手順は、高可用性のためのOracle Formsの構成にのみ使用します。

14.6.5.6.1 カスタマ・データベースのTNSNAMESエントリの作成

アプリケーションで1つ以上のデータベースにアクセスする場合、アクセスされる各データベースのエントリをtnsnames.oraファイルに配置します。

ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

mydb.mycompany.com =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = mydb.mycompany.com)
)
)

これは、Oracle RACデータベース接続文字列です。

14.6.5.6.2 Forms構成ファイルのコピー

クラスタを開く操作により、新しいWebLogic管理対象サーバーおよび関連付けられたマシンが作成されますが、APPHOST1からAPPHOST2にいくつかの構成情報をコピーする必要があります。

APPHOST1上の次のファイルをコピーします。

ファイル

APPHOST1の場所

APPHOST2の場所

すべて

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config

すべて

ORACLE_INSTANCE/config/FormsComponent/forms

ORACLE_INSTANCE/config/FormsComponent/forms

すべて

ORACLE_INSTANCE/config/FRComponent/frcommon

ORACLE_INSTANCE/config/FRComponent/frcommon

14.6.5.6.3 default.envの更新

前述のファイルをコピーしたら、DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/configディレクトリのdefault.envファイルを、APPHOST2に適した値に更新します。特に、次のエントリを変更する必要があります。

- ORACLE_INSTANCE

- TNS_ADMIN

- FORMS_PATH

- WEBUTIL_CONFIG

通常、これらのエントリは次の値になっています。

ORACLE_INSTANCE=/u01/app/oracle/admin/Forms1
TNS_ADMIN=/u01/app/oracle/admin/Forms1/config
FORMS_PATH=/u01/app/oracle/product/FMW/Forms/forms:/u01/app/oracle/admin/Forms1/FormsComponent/forms
WEBUTIL_CONFIG=/u01/app/oracle/admin/Forms1/config/FormsComponent/forms/server/webutil.cfg

前述の値を、次のように変更する必要があります。

ORACLE_INSTANCE=/u01/app/oracle/admin/Forms2
TNS_ADMIN=/u01/app/oracle/admin/Forms2/config
FORMS_PATH=/u01/app/oracle/product/FMW/Forms/forms:/u01/app/oracle/admin/Forms2/FormsComponent/forms
WEBUTIL_CONFIG=/u01/app/oracle/admin/Forms2/config/FormsComponent/forms/server/webutil.cfg

14.6.5.6.4 WLS_FORMS1の再起動

前の項で述べた変更を行った後、次のURLを使用してOracle WebLogic管理コンソールにログインし、WebLogic管理対象サーバーのWLS_FORMSとWLS_FORMS1を再起動します。

http://apphost1.mycompany.com:7001/console

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」タブを選択します。

3. WLS_FORMS1サーバーの横にあるボックスを選択します。

4. 「停止」→「ただちに強制停止」を選択します。

5. 確認ダイアログが開いたら、「はい」を選択します。

6. サーバーを停止したら、WLS_FORMS1サーバーの横にあるボックスを選択して再起動します。

7. 「起動」をクリックします。

14.6.5.6.5 構成の検証

構成を検証するには、次のテストを実行します。

テスト

URL

結果

ロード・バランサのテスト

http://mysite.mycompany.com/

ASのホーム・ページが開きます。

Forms

http://mysite.mycompany.com/forms/frmservlet

Formsサーブレットのホーム・ページが開きます。

14.6.5.6.6 ベスト・プラクティス

WebLogicアプリケーション・サーバーでは、構成情報は複数のノード間で自動的にレプリケートされません。次のいずれに行われた変更もすべて、デプロイメント内の他のサーバーに手動で伝播することが重要です。

- ORACLE_INSTANCE

- DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config

14.6.5.7 高可用性のためのOracle Reportsの構成

この項で説明する手順は、高可用性のためのOracle Reportsの構成にのみ使用します。

14.6.5.7.1 カスタマ・データベースのTNSNAMESエントリの作成

Oracle Reportsでは、tnsnames.oraファイルのエントリを使用して、データベース接続情報を判別します。Oracle Reportsキュー・データベースのエントリをこのファイルに配置します。

ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

mydb.mycompany.com =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = mydb.mycompany.com)
)
)

ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。

tnsping myreportq.mycompany.com

14.6.5.7.2 共有出力ディレクトリにアクセスするためのReports Serverの構成

CacheDirプロパティまたはJOCCacheDirプロパティを各rwserver.confファイルの<cache>要素に追加します。このファイルはDOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configuration/ディレクトリにあります。

例:

<property name="JOCCacheDir" value="folder_name"/>
<property name="CacheDir" value="folder_name"/>

UNIXの場合:

<cache class="oracle.reports.cache.RWCache">
<property name="cacheSize" value="50"/>
<!--property name="cacheDir" value="your cache directory"/-->
<!--property name="maxCacheFileNumber" value="max number of cache files"/-->
<property name="JOCCacheDir" value="/share/reports"/>
<property name="CacheDir" value="/share/reports"/>
</cache>

14.6.5.7.3 インプロセスReports Serverのデータベース・ジョブ・リポジトリの構成

レポート・キューがデータベースに配置されたら、rwserver.confファイルを編集して、それにアクセスする方法をReports Serverに認識させます。そのファイルは、DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configurationディレクトリにあります。

ファイルを編集する場合、サーバー構成ファイル内の様々なエントリの順序は固定されています。したがって、次の要素は、サーバー構成ファイルの<jobStatusRepository>要素の直後に追加する必要があります。

<jobRepository>
<property name="dbuser" value="dbuser"/>
<property name="dbpassword" value="csf:reports:dbpasswdKey"/>
<property name="dbconn" value="dbconn"/>
</jobRepository>

ここで、dbuserはレポート・キューが配置されているスキーマの名前です。

また、dbconnは、ORACLE_INSTANCE/configディレクトリにあるtnsnames.oraファイルのデータベース・エントリを参照します。dbpasswdKeyは、作成されたエントリの名前です。

例:

<jobRepository>
<property name="dbuser" value="reports_queue"/>
<property name="dbpassword" value="csf:reports:queuePassword"/>
<property name="dbconn" value="myrepq.mycompany.com"/>
</jobRepository>

クラスタ・ノードの値は、APPHOST1上のrwservlet.propertiesファイルの<server>タグに記述されている値です。

クラスタ・ノードのパラメータでは、ローカル・レポート・サーバーを除いてクラスタ内のすべてのレポート・サーバーを(カンマ区切りで)リストする必要があります。

14.6.5.7.4 Oracle Reports Serverクラスタの作成

データベース・レポート・キューでReportsクラスタを作成すると、すべてのReports Serverを同じキューにリンクすることができます。この処理の利点は、サーバーの処理能力に余裕があるときに、このキューで次のレポートを実行し、負荷を分散させることができるということです。また、クラスタ・メンバーが使用できなくなったときに、別のReports Serverがこれを検出して、障害が発生したサーバーが処理していたレポートを実行するするようにすることもできます。

Reportsクラスタを作成するには、APPHOST1およびAPPHOST2の両方のrwservlet.propertiesファイルにクラスタ・エントリを追加します。

クラスタAPPHOST1

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configurationディレクトリにあるrwservlet.propertiesファイルを編集します。

次の行を追加します。

<cluster clustername="cluster_reports" clusternodes="rep_wls_reports1_APPHOST2_reports2"/>

注意:

clusternodesの値は、APPHOST2にあるrwservlet.propertiesファイルの<server>タグの中の値です。

注意:

clusternodesパラメータでは、ローカルReports Serverを除いてクラスタ内のすべてのReports Serverを(カンマ区切りで)リストする必要があります。

クラスタAPPHOST2

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configurationディレクトリにあるrwservlet.propertiesファイルを編集します。

次の行を追加します。

<cluster clustername="cluster_reports" clusternodes="rep_wls_reports_APPHOST1_reports1"/>

注意:

clusternodesの値は、APPHOST1にあるrwservlet.propertiesファイルの<server>タグの中の値です。

注意:

clusternodesパラメータでは、ローカルReports Serverを除いてクラスタ内のすべてのReports Serverを(カンマ区切りで)リストする必要があります。

14.6.5.7.5 WLS_REPORTSとWLS_REPORTS1の再起動

次のURLを使用してWebLogic管理コンソールにログインし、Web Logic管理対象サーバーのWLS_REPORTSとWLS_REPORTS1を再起動します。

http://apphost1.mycompany.com:7001/console

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」タブを選択します。

3. WLS_REPORTSサーバーとWLS_REPORTS1サーバーの横にあるボックスを選択します。

4. 「停止」→「ただちに強制停止」を選択します。

5. 確認ダイアログが開いたら、「はい」を選択します。

6. サーバーを停止したら、WLS_REPORTSサーバーとWLS_REPORTS1サーバーの横にあるボックスを選択して再起動します。

7. 「起動」をクリックします。

14.6.5.7.6 構成の検証

構成を検証するには、次のテストを実行します。

テスト

URL

結果

ロード・バランサのテスト

http://mysite.mycompany.com/

ASのホーム・ページが開きます。

レポート・キューのテスト

http://mysite.mycompany.com/reports/rwservlet/showjobs

「シングル・サインオン」ページおよびレポート・キュー・ページが開きます。

14.6.5.7.7 Oracle Reportsサービスの接続可用性の管理

ロード・バランシング・ルーター、ファイアウォール、Oracle HTTP ServerおよびWebLogic Serverに対するアイドル接続を管理するタイムアウト設定を、それらのOracle Reportsサービス・アプリケーション要件に従って調整する必要があります。たとえば、ロード・バランシング・ルーターおよびファイアウォール接続タイムアウトが10分に設定されている場合に、レポートの実行時間が10分を超えると、ブラウザ接続は、ロード・バランシング・ルーターによってタイムアウトになり、Oracle Reportsサービスの出力はブラウザに出力されなくなります。Oracle Reportsサービス・クライアントとOracle Reports Serverとの間における接続のタイムアウト値は、Oracle Reportsサービス・サーバー構成ファイルのrwserver.confにある接続要素のidleTimeout属性によって制御されます。

14.6.5.8 高可用性のためのOracle Discovererの構成

この項で説明する手順は、高可用性のためのOracle Discovererの構成にのみ使用します。

14.6.5.8.1 カスタマ・データベースのTNSNAMESエントリの作成

アプリケーションで1つ以上のデータベースにアクセスする場合、アクセスされる各データベースのエントリをtnsnames.oraファイルに配置します。

ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

mydb.mycompany.com =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = mydb.mycompany.com)
)
)

これは、Oracle RACデータベース接続文字列です。

ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。

tnsping myreportq.mycompany.com

14.6.5.8.2 Discoverer構成ファイルのコピー

クラスタを開く操作により、新しいWebLogic管理対象サーバーおよび関連付けられたマシンが作成されました。ただし、APPHOST1からAPPHOST2にいくつかの構成情報をコピーする必要があります。

この手順を実行する前に、DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/ディレクトリのconfiguration.xmlファイルをコピーします。

このファイルをAPPHOST1から、APPHOST2の同じディレクトリにコピーします。

14.6.5.8.3 configuration.xmlの更新

コピーしたconfiguration.xmlファイルを更新し、次の値をconfiguration.xml.origファイルの値で置換します。

<oracleInstance>
<discovererComponentName>

14.6.5.8.4 プリファレンス・ストアの変更

エンタープライズ・デプロイメントでは、一度にアクティブになるDiscovererプリファレンス・ストアは1つのみです。プリファレンス・ストアを変更するには、APPHOST2上のOracle DiscovererがAPPHOST1上のプリファレンス・ストアを指すように変更します。

プリファレンス・ストアのホスト名とポートの識別

この例で指定するプリファレンス・サーバーは、APPHOST1上で実行するように構成されています。サーバーにインストールすると、プリファレンス・サーバーはポートを割り当てられます。次の手順に進む前にこの値を探します。

1. APPHOST1上で、ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるopmn.xmlファイルを開きます。

2. ファイルにおいてPREFERENCE_PORTエントリを探します。「value=」は、プリファレンス・サーバーに割り当てられたポートを示します。

他のマシン上のDiscovererプリファレンス・サーバーの指定

プリファレンス・コンポーネント(Discovererプリファレンス・サーバー・マシン)を実行するマシンのホスト名とポート番号を特定したら、他のマシンがDiscovererプリファレンス・サーバー・マシン上のプリファレンス・コンポーネントを使用するように確認する必要があります。

他のマシンのopmn.xmlファイルを変更してDiscovererプリファレンス・サーバー・マシンを使用するには、インストールの他のすべてのマシンで次の手順を実行します。

1. プリファレンス・サーバー・マシン以外のすべての各マシンで、テキスト・エディタ(またはXMLエディタ)でopmn.xmlファイルを開きます。

2. PREFERENCE_HOST変数を探してから、その値を次のようにDiscovererプリファレンス・サーバー・マシンのホスト名に変更します。

<variable id="PREFERENCE_HOST" value="hostname">

3. PREFERENCE_PORT変数を探してから、その値を次のようにDiscovererプリファレンス・サーバー・マシンのポート番号に変更します。

<variable id="PREFERENCE_PORT" value="port">

4. PreferenceServerプロセス・タイプを探してから、次のようにその状態をdisabledに変更します。

<process-type id="PreferenceServer" module-id="Disco_PreferenceServer"
working-dir="$DC_LOG_DIR" status="disabled">

5. opmn.xmlファイルを保存します。

14.6.5.8.5 WLS_DISCOおよびWLS_DISCO1の再起動

次のURLを使用してWebLogic管理コンソールにログインし、Web Logic管理対象サーバーのWLS_DISCOおよびWLS_DISCO1を再起動します。

http://apphost1.mycompany.com:7001/console

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」タブを選択します。

3. WLS_DISCOサーバーとWLS_DISCO1サーバーの横にあるボックスを選択します。

4. 「停止」→「ただちに強制停止」を選択します。

5. 確認ダイアログが開いたら、「はい」を選択します。

6. サーバーを停止したら、WLS_DISCOサーバーとWLS_DISCO1サーバーの横にあるボックスを選択して再起動します。

7. 「起動」をクリックします。

14.6.5.8.6 構成の検証

構成を検証するには、次のテストを使用します。

テスト

URL

結果

ロード・バランサのテスト

http://mysite.mycompany.com/

ASのホーム・ページが開きます。

Discoverer

http://mysite.mycompany.com /discoverer/viewer

Discoverer Servletのホーム・ページが開きます。

14.6.5.8.7 プリファレンス・サーバーのフェイルオーバー

プリファレンス・サーバーをホストしているサーバーに障害が発生した場合、障害が発生していないノードのいずれかで次の手順を使用してプリファレンス・サーバーを起動する必要があります。

プリファレンス・ストアのホスト名とポートの識別

この例で指定するプリファレンス・サーバーは、APPHOST1上で実行するように構成されています。サーバーにインストールすると、プリファレンス・サーバーはポートを割り当てられます。次の手順を使用してこの値を探します。

1. APPHOST1上で、ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるopmn.xmlファイルを開きます。

2. ファイルにおいてPREFERENCE_PORTエントリを探します。「value=」は、プリファレンス・サーバーに割り当てられたポートを示します。

APPHOST2上でのプリファレンス・ストアの有効化

APPHOST2がAPPHOST1上のプリファレンス・ストアを使用するようになったら、ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるopmn.xmlファイルを編集して、APPHOST2上のプリファレンス・ストアを無効化します。

次の行を探します。

<process-type id="PreferenceServer" module-id="Disco_PreferenceServer" working-dir="$DC_LOG_DIR" status="disabled">

status=disabledをstatus=enabledに変更します。

例:

<process-type id="PreferenceServer" module-id="Disco_PreferenceServer" working-dir="$DC_LOG_DIR" status="enabled">

APPHOST2上のプリファレンス・サーバーの起動

次のコマンドを使用してAPPHOST2上のプリファレンス・サーバーを起動します。

opmnctl startproc process-type=PreferenceServer

障害の発生していないサーバーがAPPHOST2上のプリファレンス・ストアを使用するための変更

プリファレンス・サーバーがAPPHOST2上で起動したら、APPHOST2を含めてすべてのDiscovererインスタンスがこのプリファレンス・サーバーを使用するように修正します。

使用されるプリファレンス・ストアは、WebLogic管理対象サーバーであるWLS_DISCO1の起動時に決まります。WLS_DISCO1が別のプリファレンス・ストアを使用するようにするには、次のURLを使用してWebLogic管理コンソールにログインして、起動パラメータを変更する必要があります。

http://apphost1.mycompany.com:7001/console

次の手順を続行します。

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. WLS_DISCO1サーバーをクリックします。

4. 「構成」タブ、「サーバーの起動」サブタブの順にクリックします。

5. 引数フィールドで、次の行を追加します。

-Doracle.disco.activation.preferencePort=<portno>
-Doracle.disco.activation.preferenceHost=<hostname>

ポート番号は、前に定義したPREFERENCE_PORTの値です。

ホスト名は、プリファレンス・サーバーが起動されたホストの名前です(例: APPHOST2)。

14.6.5.8.8 クラスタ環境でのDiscoverer WSRPポートレット・プロデューサの設定

ポートレット・プリファレンス・ストアは、コンシューマ登録ハンドルおよびポートレット・プリファレンス・データを永続的に保持するために使用されます。

Discoverer WSRPポートレット・プロデューサでは、ファイルベースのプリファレンス・ストアを使用します。プリファレンス・ストアの場所は、Discovererデプロイメント・プラン(XMLファイル)のdiscoWsrpPrefStoreSharedPath変数の値で定義されます。discoWsrpPrefStoreSharedPath変数のデフォルト値は、portletDataです。

デプロイメント・プランおよびその内容の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・プランの内容の理解に関する項を参照してください。

クラスタ環境では、ファイルベースのプリファレンス・ストアに対して、同じOracle WebLogic Server内で稼働するすべてのDiscoverer WSRPポートレット・プロデューサはデプロイメント・プランのdiscoWsrpPrefStoreSharedPath変数に同じパスを使用する必要があります。そのため、「プリファレンス・ストアの設定」の項で説明されているように、discoWsrpPrefStoreSharedPath変数の値はデプロイメント・プランの共有パスに変更する必要があります。

discoWsrpPrefStoreSharedPath変数を変更してプリファレンス・ストアのコンテンツを既存のプリファレンス・ストアから共有パスに移行する場合、「移行ユーティリティを使用したプリファレンス・ストア・コンテンツの転送」の項で説明されているように、移行ユーティリティを実行してプリファレンス・データを移行元パスから移行先パスに転送する必要があります。

プリファレンス・ストアの設定

Discovererのデプロイメント・プランを表示および編集するには、次の手順に従います。

1. 管理コンソールにログインします。

2. 左側のペインで、「デプロイメント」をクリックします。

3. 右側のペインで、デプロイメント・プランを更新するDiscovererアプリケーションを選択します。「Discoverer: 概要」ページが表示されます。

「概要」ページの「デプロイメント・プラン」フィールドには、Discovererアプリケーション・デプロイメント・プラン(XMLファイル)のパスが表示されます。次の手順に示すように、デプロイメント・プランを変更します。

1. XMLエディタで、「Discoverer: 概要」ページに表示されている場所からデプロイメント・プランを開きます。

2. variable-definitionセクションへ移動します。

...
<variable-definition>
<variable>
<name>discoWsrpPrefStoreSharedPath</name>
<value>portletData</value>
</variable>
<variable-definition>
...

注意:

discoWsrpPrefStoreSharedPath変数は、デプロイメント・プランのvariable-definitionおよびvariable-assignmentセクションで定義されます。variable-definitionセクションで定義されているdiscoWsrpPrefStoreSharedPath変数のみを変更してください。

3. discoWsrpPrefStoreSharedPath変数のvalueを、すべての管理対象サーバーがアクセスできるSharedPathに変更します。

...
<variable-definition>
<variable>
<name>discoWsrpPrefStoreSharedPath</name>
<value>SharedPath</value>
</variable>
<variable-definition>
...

注意:

valueの絶対パスを指定する必要があります。valueの相対パスは、ORACLE_HOME/portalディレクトリを基準に解釈されます。

4. 変更を保存してXMLファイルを閉じます。

デプロイメント・プランをdiscoWsrpPrefStoreSharedPath変数の新しい値で更新したら、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプのエンタープライズ・アプリケーションの更新(再デプロイ)に関する項で説明されているように、Discovererアプリケーションを更新する必要があります。

移行ユーティリティを使用したプリファレンス・ストア・コンテンツの転送

WSRPコンテナ・プリファレンス・ストア移行ユーティリティPersistenceMigrationToolを使用すると、異なるプリファレンス・ストア間で既存のデータを移行できます。

PersistenceMigrationToolの構文は次のとおりです。

java oracle.portlet.server.containerimpl.PersistenceMigrationTool
-sourceType file -destType file -sourcePath dir -destPath dir

sourceTypeは、移行元ストアがファイル内にあることを示します。

destTypeは、移行先ストアがファイル内にあることを示します。

注意:

Discoverer WSRPプロデューサでは、ファイルベースのプリファレンス・ストアを使用します。そのため、sourceTypeおよびdestType引数にfileを指定する必要があります。

sourcePathおよびdestPathは、ファイルベースのプリファレンス・ストアの場所です。

注意:

このツールを実行して、wsrp-container.jar、oracle.portlet-api.jar、およびojdbc6.jarを組み込む場合は、クラスパスを設定する必要があります。例:

java -classpath $ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/oracle-portlet-api.jar:$ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wsrp-container.jar:$WL_HOME/server/lib/ojdbc6.jar

14.6.5.8.9 ベスト・プラクティス

Oracle WebLogic Serverでは、構成情報は複数のノード間で自動的にレプリケートされません。したがって、次のいずれに行われた変更もすべて、デプロイメント内の他のサーバーに手動で伝播することが重要です。

- ORACLE_INSTANCE

- DOMAIN_HOME/servers/WLS_DISCO1/applications/discoverer_version/configuration/configuration.xml

プリファレンス・サーバー

プリファレンス・サーバーには、ユーザー・プリファレンスに関する詳細が含まれています。これは頻繁に更新される場合があります。Oracle Discovererプリファレンス・サーバーに障害が発生した場合は、そのプリファレンス・サーバーを別のサーバー上で起動する必要がありますプリファレンス情報を、これらの代替として使用される場合があるホストに定期的にコピーする必要があります。

プリファレンス・サーバーをホストする場合がある他のサーバーに定期的に次のファイルを伝播する必要があります。

ORACLE_INSTANCE/config/PreferenceServer/Discoverer_Instance/.reg_key.dc

14.6.6 デプロイメントのスケール・アウト

デプロイメントを追加のノードにスケール・アウトするには、第14.6.5項「APPHOST2でのアプリケーション層のインストールと構成」の手順に従います。以前のノードに使用したディレクトリ構造と同じものを使用します。

15 Oracle Business IntelligenceおよびEPMの高可用性の構成

Oracle Business Intelligenceは、ビジネス・ユーザーに組織の全体像を提供する統合ビジネス・インテリジェンス(BI)ソリューションです。Oracle Business Intelligenceは、迅速かつ簡単に様々なデータ・ソースを統合し、データベースの情報を検索し、データベース情報を共有して、企業およびその顧客に関する情報を得るためにデータを有効に利用することを目的として設計されています。

OracleのEnterprise Performance Management(EPM)システムは、モジュール方式のパフォーマンス管理アプリケーションのスイートと、包括的なビジネス・インテリジェンス機能をレポート作成および分析のために統合します。これにより、ユーザーの生産性は向上し、所有にかかる経費は抑えられ、ビジネス・リスクは低減します。

この章では、次の項目に関する高可用性について説明します。

- 第15.1項「Oracle Business Intelligence Enterprise EditionおよびEnterprise Performance Managementの高可用性」

- 第15.2項「Oracle Business Intelligence Publisherの高可用性」

- 第15.3項「Oracle Real-Time Decisionsの高可用性」

この章は、Oracle Business IntelligenceおよびEPMを理解している読者を対象にしています。そうでない場合は、Oracle Business IntelligenceおよびEPMのドキュメントを参照してください。

15.1 Oracle Business Intelligence Enterprise EditionおよびEnterprise Performance Managementの高可用性

この項では、Oracle Business Intelligence Enterprise Edition(Oracle BI EE)およびEnterprise Performance Management(EPM)の概要について説明します。また、この項では、Oracle BI EEおよびEPMのための高可用性環境の設計方法とデプロイ方法についても説明します。

Oracle BI EEは、包括的なエンタープライズBI機能の集合体であるOracle Business Intelligenceの一部です。Oracle Business Intelligenceは、インタラクティブ・ダッシュボード、完全にアドホックな事前対応インテリジェンスとアラート、エンタープライズおよび財務のレポート作成機能、リアルタイムの予測インテリジェンスなど、あらゆるBI機能を提供します。Oracle BI EEプラットフォームは、本当の次世代BI機能を提供する、実証済の最新型Webサービス指向アーキテクチャを基盤にしています。Oracle BI EEは、各種データを収集および編成してから編成データをユーザーに表示できる堅牢なアプリケーションで、ユーザーは、これらのデータを分析および解釈して、その結果に基づいて対処できます。Oracle BI EEに関するその他の概要は、『Oracle Fusion Middlewareユーザーズ・ガイドfor Oracle Business Intelligence Enterprise Edition』を参照してください。

Enterprise Performance Managementアプリケーションは、戦略、計画および実行をシームレスなプロセスに統合します。OracleのEPMアプリケーションは、Oracleのトランザクション・システムとOracle以外のトランザクション・システムの両方を統合する、モジュール方式の統合化アプリケーションのスイートです。各アプリケーションは高度な有用性を実現するために個別にデプロイすることもできますが、それらのアプリケーションを合わせて使用すると、デプロイメントと所有に掛かる費用を抑えながら、戦略、財務および運用管理のプロセスを統合できるようになります。

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

- 第15.1.1項「Oracle BI EEのコンポーネント・アーキテクチャ」

- 第15.1.2項「Oracle BI EEの高可用性の概要」

- 第15.1.3項「Oracle Essbaseのコンポーネント・アーキテクチャ」

- 第15.1.4項「Oracle Essbaseの高可用性の概要」

- 第15.1.5項「Oracle Essbaseのクラスタリングの構成」

- 第15.1.6項「Oracle Hyperion Provider Servicesのコンポーネント・アーキテクチャ」

- 第15.1.7項「Oracle Hyperion Provider Servicesの高可用性の概要」

- 第15.1.8項「Oracle EPM Workspaceのコンポーネント・アーキテクチャ」

- 第15.1.9項「Oracle EPM Workspaceの高可用性の概要」

- 第15.1.10項「Oracle Hyperion Financial Reportingのコンポーネント・アーキテクチャ」

- 第15.1.11項「Oracle Hyperion Financial Reportingの高可用性の概要」

- 第15.1.12項「Allocation Managerのコンポーネント・アーキテクチャと特性」

- 第15.1.13項「Oracle BI EEの高可用性の構成手順」

15.1.1 Oracle BI EEのコンポーネント・アーキテクチャ

図15-1では、単一インスタンス・アーキテクチャでのOracle BI EEコンポーネントを示しています。Javaコンポーネントとシステム・コンポーネント間のすべての通信は、HTTP経由のSOAPメッセージを介して行われます。

図15-1 Oracle BI EEの単一インスタンス・アーキテクチャ

「図15-1 Oracle BI EEの単一インスタンス・アーキテクチャ」の説明

図15-1に示しているポート番号は、単一マシン上に各コンポーネント・タイプのコンポーネントが1つだけ配置された単純なインストール環境用のデフォルト・ポート番号です。Oracle Enterprise Manager Fusion Middleware Controlを使用してスケール・アウトするときには、ボート番号の範囲を選択できます。「システム・コンポーネントをスケーリングするためのFusion Middleware Controlの使用」を参照してください。

15.1.1.1 Oracle BI EEコンポーネントの特性

次のセクションでは、Oracle BI EEコンポーネントの特性について詳しく説明します。ここで説明する情報は、Oracle BI EEの高可用性の要件について詳しく理解するために役立ちます。

次に、Oracle BI EEシステム・コンポーネントの機能について概要を説明します。

- Oracle BIプレゼンテーション・サービス(プレゼンテーション・サービス): これは、ユーザー・インタフェース・ページを生成し、Oracle BIスケジューラにかわって結果セットをレンダリングするC++プロセスです。複数のプレゼンテーション・サービス・プロセスを構成でき、それらで負荷を共有できます。プレゼンテーション・サービス・プロセス間でセッション・レプリケーションは行われません。
プレゼンテーション・サービスはほぼステートレスです。唯一の重要な状態はクライアント認証です。シングル・サインオンを使用して認証するようにOracle Business Intelligenceが構成されている場合、ユーザーはフェイルオーバー後に再認証する必要はありません。他のすべての認証方式では、フェイルオーバーが発生すると、クライアントは再認証する必要があります。クライアントに対するサービスは中断され、クライアントはログイン・ページにリダイレクトされます。

- Oracle Business Intelligence Server(BI Server): これは、データ操作を実行したりデータ・ソースからデータを収集するC++プロセスです。負荷を共有する複数のBI Serverプロセスを構成できます。BI Serverプロセス間では、セッション・レプリケーションは行われません。
BI Serverでは、ユーザー・セッション状態は保持されません。高可用性デプロイメントの場合は、問合せ結果はグローバル・キャッシュに格納されます。

- JavaHost: これは、大量のリソースを消費するグラフやPDFのレンダリングを含むJavaプロセスです。負荷を共有する複数のJavaHostプロセスを構成できます。JavaHostプロセス間では、セッション・レプリケーションは行われません。
JavaHostはステートレス・プロセスです。

- Cluster Controller: これは、BI ServerとOracle BIスケジューラの集合を管理するC++プロセスです。

- Oracle Business Intelligence Scheduler(Oracle BIスケジューラ): これは、時刻が指定されたスケジュールに従ってジョブを実行するC++プロセスです。ジョブは、Oracle BIプレゼンテーション・カタログで作成されたエージェントの場合や、ジョブ・マネージャによって作成されたジョブの場合があります。

次に、Oracle BI EE Javaコンポーネントの機能について概要を説明します。

- Oracle BIプレゼンテーション・サービスのプラグイン・サーブレット: プレゼンテーション・サービスは、Webサーバーとしてではなくプロセスとして実行するため、Webサーバー・プラグインAPIを使用して通信することはありません。Oracle BIプレゼンテーション・サービスのプラグインは、HTTPリクエストをPresentation Servicesに転送します。HTTPリクエストは、ブラウザ・ベースのユーザー・インタフェースからのリクエストまたはSOAPリクエストです。

- Webサービス:

- アクション実行サービス:プレゼンテーション・サービスとOracle BIスケジューラのかわりにアクションを実行します。アクションは、サード・パーティWebサービスのコールである場合や、EJBとして実行されるユーザー提供Javaコードのコールである場合があります。

- アクション・レジストリWebサービス: アクションのリストを提供します。

- アクション場所サービス: 間接レベルを提供することで、アクションを顧客のテスト環境で開発してから、すべてのアクション定義を本番ソースを指すように変更することなく、開発したアクションを本番環境にデプロイできます。

- SOA用Webサービス:Oracle BIプレゼンテーション・カタログのコンテンツに対するWebサービス・インタフェースを提供します。Oracle BIプレゼンテーション・カタログ内のオブジェクトのツリーは、WSDLリーフを持つWSILツリーによって定義されたWebサービスのツリーとして公開されます。

- セキュリティWebサービス: 標準に基づいた認証サービスと移入サービスを提供します。

15.1.1.1.1 プロセスのライフサイクル

OPMNは、各Oracle BI EEシステム・コンポーネントを制御します。開始および停止するには、Oracle Enterprise Manager Fusion Middleware ControlのOracle BI EE管理用ページを使用します。

各Oracle BI EEのJavaコンポーネントは、管理対象Oracle WebLogic Serverによってホストされ、管理コンソールを使用して制御されます。それぞれの管理対象Oracle WebLogic Serverは、ローカルのWebLogicノード・マネージャによって監視および(必要に応じて)再起動されます。

注意:

名前付きユーザーを使用してOPMNプロセスを実行する場合は、Windows環境で共有ネットワーク・ファイルにアクセスできることを確認する方法に関する項を参照してください。

15.1.1.1.2 外部依存性

Oracle BI EEを使用するには次が必要です。

- SMTPメール・サーバー

- LDAPプロバイダ(Oracle Internet Directoryなど)

- アクションをサポートするための外部Webサービス(ユーザーによって構成)

次のクライアントはOracle BI EEに依存します。

- ADFデスクトップ統合: ADFでは、プレゼンテーション・サービスのWebサービスと、ODBC/JDBCポートを介したBI Serverの直接起動の両方が使用されます。これは、プレゼンテーション・サービスを経由することなくOracle BI Serverが直接起動される唯一のケースです。

- BI Publisher: プレゼンテーション・サービスのWebサービスを使用します。

- BPEL: WSILブラウジング・サーブレットおよびSOA WebサービスのWebサービスを使用します。

15.1.1.1.3 構成アーティファクト

Oracle BI EEでは、次の3種類の構成方法が用意されています。

- 中央構成: Oracle Enterprise Manager Fusion Middleware ControlのBI EEページで行います。これらのページを使用して、追加のインスタンスをプロビジョニングして、高い可用性とスケーラビリティを提供できます。主要な構成値も中央で管理できるため、すべてのインスタンスに一貫した構成値を割り当てることができます。

- ローカル・システム・コンポーネントの構成:ローカル構成が必要となるのは、詳細構成に変更を加える場合のみです。

- ローカルJavaコンポーネントの構成:システム・コンポーネントの構成と同様に、ローカル構成は詳細オプションについてのみ必要です。

中央構成

Oracle BI EEでは、Enterprise Manager Fusion Middleware Controlで公開されている中央構成メカニズムが用意されています。

中央で管理される構成の対象は次のとおりです。

- コンポーネント数の変更

- リスニング・ポートの範囲。各コンポーネントによって使用されるポートは、この範囲から自動的に割り当てられます。

- 基本SSL構成: システムMBeanブラウザを使用して、BI EEコンポーネントに対してSSLを有効にできます。

- メール・サーバー構成

- プリンシパル・チューニング・オプション

- 共有ファイルの場所

詳細構成はローカルでできますが、そのためにはローカル構成ファイルを直接編集します。中央構成がコミットされると、中央構成によって設定された構成オプションのみがローカル・マシンに配信されます。

ローカル・システム・コンポーネントの構成

実行中の各システム・コンポーネントは、共有構成ファイルとコンポーネント固有構成ファイルの両方を参照します。共有構成ファイル(ClusterConfig.xmlなど)は次のディレクトリに配置されます。

ORACLE_INSTANCE/config/OracleBIApplication/coreapplication

コンポーネント固有構成ファイルは次の場所に配置されます。

ORACLE_INSTANCE/config/ComponentType/ComponentInstanceName

例:

ORACLE_INSTANCE/config/OracleBIPresentationServicesComponent/
coreapplication_obips1

各コンポーネントはローカル・ファイルを参照するため、中央の管理サーバー上に保持されているファイルにアクセスする必要はありません。中央構成がコミットされると、中央で管理されている構成値はこれらのローカル構成ファイルに配信されます。ローカル・ファイル内では、これらの中央で管理されている構成値をローカルで編集しないようにユーザーに警告するコメントが、これらの構成値に付加されます。残りの値はローカルで編集できます。

rpdファイルにはデータ・ソースへの参照が含まれています。一般に開発環境では、本番環境とは異なるデータベースがファクト表用に使用されます。rpdファイルが開発環境から本番環境に移動された場合は、BI管理ツールを使用してrpdファイルを編集し、データ・ソース参照を変更する必要があります。

ローカルJavaコンポーネントの構成

Javaコンポーネントは、次の場所のWebLogicディレクトリ・ツリーで構成されます。

DOMAIN_HOME/config/fmwconfig/biinstances/coreapplication

15.1.1.1.4 デプロイメント・アーティファクト

一般に、Oracle BI EEはJavaアプリケーションをnostageモードでデプロイします。WebLogic Serverは.earファイルを展開して、それをプライベート一時ディレクトリに配置します。これに対する例外であるMapViewerには、事前に展開されたデプロイメント・ディレクトリでのみ実行できる構成要件があります。

すべての管理対象サーバー・アプリケーションは(Enterprise Manager Fusion Middleware Controlや中央構成アプリケーションなどの管理アプリケーションは除く)、個別に指定されたシステムにデプロイするのではなく、Oracle BI EEクラスタ全体にデプロイします。

Oracle BI EEシステム・コンポーネントがデプロイされるときのログ・ファイルの場所については、第15.1.1.1.5項「ログ・ファイルの場所」を参照してください。

15.1.1.1.5 ログ・ファイルの場所

表15-1には、Oracle BI EEシステム・コンポーネントのログ・ファイルを示しています。これらすべてのログ・ファイルは、Enterprise Manager Fusion Middleware Controlからアクセスできます。

表15-1 Oracle BI EEシステム・コンポーネントのログ・ファイル

BIコンポーネント

ログ・ファイル

ログ・ファイルのディレクトリ

OPMN

debug.log

ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn

OPMN

opmn.log

ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn

BI Server

nqserver.log

ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication_obis1

BI Cluster Controller

nqcluster.log

ORACLE_INSTANCE/diagnostics/logs/OracleBIClusterControllerComponent/coreapplication_obiccs1

Oracle BIスケジューラ

nqscheduler.log

ORACLE_INSTANCE/diagnostics/logs/OracleBISchedulerComponent/coreapplication_obisch1

プレゼンテーション・サービス

sawlog*.log(例: sawlog0.log)

ORACLE_INSTANCE/diagnostics/logs/OracleBIPresentationServicesComponent/coreapplication_obips1

BI JavaHost

jh.log

ORACLE_INSTANCE/diagnostics/logs/OracleBIJavaHostComponent/coreapplication_objh1

15.1.2 Oracle BI EEの高可用性の概要

この項では、Oracle BI EEを高可用性デプロイメントで使用する場合の概要について説明します。

Oracle BI EEの高可用性を確保するための要件

Oracle BI EEは、プロセス・レプリケーションと高可用性ストレージ(データベースと共有ファイル・システム)の組合せを通じて高可用性を実現します。

高可用性システムを実現するには、Oracle BI EEは次の外部サービスを必要とします。

- フォルト・トレラントのHTTPロード・バランサ

- 高可用性の共有ファイル・システム

- Oracle BIスケジューラおよびファクト表用の高可用性データベース

次のシステム・コンポーネントをレプリケートする必要があります(2つ以上のインスタンスを確保)。

- プレゼンテーション・サービス

- Cluster Controller

- Oracle BIスケジューラ

- BI Server

- JavaHost

これらのシステム・コンポーネントのインスタンスが2つ以上ない場合は、高可用性要件が満たされず、Enterprise Manager Fusion Middleware Controlの構成UIでは管理者に対して警告が表示されます。

次の永続データ・ソースは、高可用性の共有ファイル・システムに配置される必要があります。

- RPD公開ディレクトリ: サーバー・メタデータは、各BI Serverに対してローカルであるリポジトリ・ファイル(.rpdファイル)に含まれています。1台のBI Serverがマスターとして指定されます。rpdファイルへのオンライン変更はマスターBI Server上で行われ、これらの変更内容はクラスタの他のメンバーにレプリケートされます。

- Oracle BIプレゼンテーション・カタログ

- グローバル・キャッシュ(必須ではありませんが、高いパフォーマンスを得るためにお薦めします):グローバル・キャッシュ機能により、キャッシュのシード・イベントとパージ・イベントを格納する共通問合せキャッシュがサポートされます。このグローバル・キャッシュは、クラスタ内のすべてのBI Serverから参照できます。

- スケジューラ・スクリプト

また、Oracle BIプレゼンテーション・サービス・プラグインや認証サービスなどのOracle BI EE Javaコンポーネントをホストするために、2つ以上のメンバーで構成されるWebLogicクラスタも必要です。

15.1.2.1 Oracle BI EEおよびEPMの高可用性アーキテクチャ

図15-2は、Oracle BI EEおよびEPMの高可用性デプロイメントを示しています。

図15-2 Oracle BI EEおよびEPMの高可用性デプロイメント

「図15-2 Oracle BI EEおよびEPMの高可用性デプロイメント」の説明

図15-2では、ハードウェアのロード・バランサがハードウェアのリクエストを受信し、それらをWeb層のWEBHOST1またはWEBHOST2にルーティングしています。これらのホストにはOracle HTTP Serverがインストールされています。

Oracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。第3章「WebLogic Serverの高可用性」で説明されているように、APPHOST1が使用できなくなった場合、APPHOST2で管理サーバーをアクティブにできます。Oracle BI EE、Oracle EPMおよびOracle BI Publisher Javaコンポーネントは、これらのホストのBI_SERVER1およびBI_SERVER2管理対象サーバーにデプロイされます(Financial Reporting、Provider ServicesおよびWorkspaceはOracle EPMコンポーネントです)。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。サーバー移行全体は、管理対象サーバー用に構成されます。

BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシンに対するこれらのホスト名それぞれに、APPHOST1はVIP1、APPHOST2はVIP2というVIPマッピングを有効にして、このトポロジが使用するネットワーク・システム内の仮想ホスト名を(DNSサーバーまたはhosts解決で)正しく解決する必要があります。BIサーバーのサーバー移行を構成する方法の詳細は、第15.1.13.22項「BI_SERVERnサーバーのサーバー移行の構成」を参照してください。

Oracle BIプレゼンテーション・サービス、JavaHost、Oracle BI Cluster Controller、Oracle BIスケジューラおよびOracle BI Serverは、APPHOST1およびAPPHOST2にインストールされてクラスタとして構成されたシステム・コンポーネントです。APPHOST2上のCluster ControllerとSchedulerはパッシブであり(これらは起動されますがリクエストを処理しません)、APPHOST1のコンポーネントで障害が発生した場合にのみアクティブ化されます。

データ層では、カタログ、問合せキャッシュ、RPDおよびSchedulerのスクリプト・データを格納するために、共有外部記憶域が設定されます。Oracle RACデータベースは、BI EEスキーマ・メタデータとBI Publisherリポジトリ・データを格納するために使用され、エンタープライズ・データベース用としてもお薦めします。

次の各項では、いくつかのOracle BI EEコンポーネントの高可用性情報について説明します。

15.1.2.1.1 Webサーバーの高可用性の考慮事項

Oracle BIプレゼンテーション・サービス・プラグインは、ブラウザ・ユーザー・インタフェースなどのすべてのHTTPクライアントにとっての最初の通信先です。この前方には、Oracle HTTP Serverまたは他のサポートされているWebサーバーが配置されることがあります。シングル・ポイント障害を回避するために、このHTTPスタックをレプリケートする必要があります。ユーザーに複数のHTTP URLが表示されることを防ぐには、外部ロード・バランサをセットアップします。これにより、ユーザー・リクエストは、レプリケートされたOracle BI EE URLのいずれかにルーティングされます。

内部HTTPリクエストをローカルWebLogic管理対象サーバーに直接ルーティングすると、高可用性は低下します。WebLogicインスタンスで障害が発生した場合は、ノード・マネージャによってそのインスタンスが再起動されます。WebLogicの再起動には数分間かかることがあります。この間は、ローカル・セキュリティ・サービスは使用不能になり、ログインできなくなります。これとは対照的に推奨の構成では、内部HTTPリクエストはロード・バランサを介してルーティングされます。代替のセキュリティ・サービスはすぐに使用可能になります。

15.1.2.1.2 Oracle BIプレゼンテーション・サービスプラグインの高可用性の考慮事項

Oracle BIプレゼンテーション・サービス・プラグインは、分析.earアプリケーションとしてデプロイされます。それは、TCP経由のネイティブRPCプロトコルを使用して、セッション・リクエストをプレゼンテーション・サービス・インスタンスにルーティングします。また、セッションCookieまたはURL引数を通じて全般的にセッション・アフィニティを維持しながら、複数のプレゼンテーション・サービス・インスタンス間のロード・バランシングも実行します。プレゼンテーション・サービスとプラグインは個別のプロセスとして実行されます。

それぞれのOracle BIプレゼンテーション・サービス・プラグイン・インスタンスは完全に独立しており、Oracle BIプレゼンテーション・サービス・プラグイン・インスタンス間の通信は行われません。それぞれは、過去におけるレスポンス時間と未処理リクエスト数に基づいて、ロード・バランシングについて独自に判断します。

ロード・バランサ上でセッション・アフィニティを構成することをお薦めします。

Oracle BIプレゼンテーション・サービス・プラグインは、Oracle Business Intelligence Javaコンポーネントの1つであり、追加の管理対象サーバーをデプロイメントに追加する場合、高可用性のためのスケーラビリティを持っています。

15.1.2.1.3 プレゼンテーション・サービスの高可用性の考慮事項

プレゼンテーション・サービスは、Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブで定義されたポート範囲から割り当てられたポート上のOracle BIプレゼンテーション・サービス・プラグインからリクエストを受信します。初期ユーザー・セッション・リクエストは、クラスタ内の任意のプレゼンテーション・サービス・インスタンスに送信できますが、その後は各ユーザーは特定のプレゼンテーション・サービス・インスタンスにバインドされます。

ユーザー・リクエストの処理のために、プレゼンテーション・サービスはBI Serverと通信する必要があります。クラスタ環境では、BI Serverとの通信のためにはまずCluster Controllerと通信します。プレゼンテーション・サービスは、クラスタ環境用に構成されたOracle BI ODBCデータ・ソースを使用してプライマリCluster ControllerとセカンダリCluster Controllerを識別するとともに、これらがリスニングするポートを識別します。中央管理の構成が変更されたときには、中央に配置されたBIドメイン構成ファイルによって、ODBCデータ・ソース名(DSN)内の接続パラメータが自動的に構成されます。Oracle BI ODBC DSNの接続パラメータは、ローカルに変更しないでください。

Cluster Controllerは、プレゼンテーション・サービスが接続するOracle BI Serverインスタンスを割り当てます。Oracle BI Serverへの接続はODBCを介して確立され、同じセッション内の後続のリクエストは、プレゼンテーション・サービスから、割り当てられたOracle BI Serverに直接送信されます。プレゼンテーション・サービスとOracle BI Serverとの間のODBCセッションは、ステートフルであり、セッション存続時間の間、アフィニティを保持する必要があります。

Oracle BIスケジューラと通信するために、プレゼンテーション・サービスはまずCluster Controllerと通信し、それからアクティブなOracle BIスケジューラ・インスタンスにリレーします。その後、Presentation Servicesは該当するOracle BIスケジューラ・インスタンスとのセッションを確立します。Fusion Middleware Controlの「容量管理」ページの「可用性」タブで、ホストおよびOracleインスタンスの名前をCluster ControllerおよびOracle BIスケジューラに指定します。

15.1.2.1.4 BI Cluster Controllerの高可用性の考慮事項

Cluster Controllerは、プレゼンテーション・サービスなどのクライアントからの新しいBI ServerセッションやOracle BIスケジューラ・セッションにとって最初の通信先です。Cluster Controllerは、次のようにアクティブ/パッシブ構成でデプロイします。

- プライマリCluster Controller: アクティブCluster Controllerです。

- セカンダリCluster Controller: プライマリCluster Controllerが使用不能になった場合にアクティブCluster Controllerの役割を担います。

デフォルトでは、Oracle Business Intelligenceインストールで最初に構成したCluster ControllerがプライマリCluster Controllerになります。

Cluster Controllerは、Oracle BI Serverの可用性と負荷に基づいて、クラスタ内のどのOracle BI Serverが着信リクエストを受信するのかを決定します。また、Oracle BIスケジューラ・インスタンスなどのクラスタ内のサーバー処理の監視もします。

Cluster Controllerでサポートされているものは、次のとおりです。

- サーバーおよびOracle BIスケジューラの障害の検出。

- サーバーに障害が発生した場合のODBCクライアントに対するフェイルオーバー。

Cluster Controllerは、実行時にアクティブOracle BIスケジューラ・インスタンスも判別します。Cluster Controllerはプレゼンテーション・サービス・インスタンスを制御しないことに注意してください。

両方のCluster Controllerのどちらもがアクティブであると認識するスプリット・ブレイン構成を回避することが重要です。スプリット・ブレイン構成を回避するために、潜在的に信頼性が低いWANを介して接続された別々のLAN上でCluster Controllerを構成しないでください。サイト障害に対するフォルト・トレランスでは、クラスタ化メカニズムではなく障害時リカバリ・メカニズムを使用する必要があります。

15.1.2.1.5 BI Serverの高可用性の考慮事項

複数のBI Serverをインストールして構成することで、BI Serverクラスタを作成できます。Cluster Controllerは、プレゼンテーション・サービスなどのクライアントからのリクエストをこのクラスタのアクティブ・メンバーにディスパッチします。BI Serverは、Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブで定義されたポート範囲から割り当てられたポート上でクライアント・リクエストをリスニングします。

注意:

クラスタに参加している各サーバーのクロックを同期する必要があります。クロックが同期していないと、レポートで時間のずれが生じることがあります。

マスターBI Serverは、Oracle BI管理ツールがRPDファイル内でオンライン・メタデータ変更を加えるために接続するサーバーです。このメタデータ変更内容は、他のサーバーの再起動時にそれぞれのサーバーに伝播されます。管理ツールのクラスタ・マネージャを使用して、どのOracle BI Serverがマスターであるかを表示できます。

BI Serverからデータベースへの通信

BI Serverは、Oracle Databaseを含む多くのデータベース・タイプとの通信をサポートしています。BI Serverのデータ・リポジトリは、未加工のファクト表を保持します。Oracle BI EEはBI Serverデータ・リポジトリにメタデータを保管しません。すべてのメタデータは、RPDファイルまたは(プレゼンテーション・サービスの場合は)Oracle BIプレゼンテーション・カタログに保管されます。

Oracle BIスケジューラは、Oracle BIスケジューラ・スキーマにデータを保管します。Oracle BIスケジューラのデータベース接続構成では、BI Serverと同じライブラリが使用されるため、フォルト・トレランス特性は同じです。唯一の違いは、Oracle BIスケジューラの操作の方がはるかに書込みが多いことです。BI Serverのデータ・ソースは主に読取り専用です。

BI Serverのデータベース操作の主なポイントは次のとおりです。

- ソース・データベース: ソース・データベースはOracle BI EEのレポート用に使用されます。これらは主に読取り専用です。ソース・データベースについては多くのオプションがサポートされています。

- イベント・ポーリング: ファイル・システムからのキャッシュの削除や作成を常時チェックします。

- 使用状況トラッキング

- ライト・バック機能: ユーザー主導型の機能です。

実装では次の特性が実現されます。

- すべてのデータベース読取り/書込み操作はC++コードによって実行されます。

- Oracle Databaseの場合は、OCIが使用されます。他のデータベースやデータ・ソースの場合は、ネイティブ・データベース機能が使用されます。

- Oracle Databaseと非Oracle Databaseのサポートは、ソース・データベースについてだけでなく、Oracle BIスケジューラについても可能です。

15.1.2.1.6 管理ツールの高可用性の考慮事項

管理ツールでは、Presentation Servicesが使用するのと同じOracle BI ODBC DSNを使用します。それは、Cluster ControllerによってマスターBI Serverに接続されます。マスターBI Serverが使用できない場合、管理ツールはRPDファイルへの書込みを実行できません。

15.1.2.1.7 Oracle BIスケジューラの高可用性の考慮事項

Oracle BIスケジューラ・インスタンスは、アクティブ/パッシブ・モデルに基づいて動作します。どの時点でも、1つのOracle BIスケジューラのみがアクティブになってリクエストを処理することで、新しいジョブに一意のジョブIDが割り当てられることを保証します。非アクティブなOracle BIスケジューラ・インスタンスはアイドル状態を維持し、アクティブなOracle BIスケジューラで障害が発生した場合に引継ぎを要請されるまで、ジョブを処理しません。

インストールされた複数のOracle BIが同じスケジューラ表を使用するように構成しないでください。そのようにすると、アクティブなOracle BIスケジューラが複数存在することになり、一意のジョブIDという制約が破綻します。

Oracle BIスケジューラは、BI Serverと同じデータベース・テクノロジを使用します。

Oracle BIスケジューラは稼働しているが、データベースが停止している場合、失敗したトランザクションはOracle BIスケジューラによってそのメモリー内のキューに格納され、正常に処理されるまで再試行されます。したがって、バックエンド・データベース・ソースをメンテナンスのために停止した場合、そのデータベースの再起動時にOracle BI EEのプロセスを再起動する必要はありません。このプロセスは、Oracle BIスケジューラでの定期的パージと同じカウントで再試行されるため、同じ構成値を使用します。Oracle BI EEは、Oracle BI EEのメタデータに含まれている必要のある文のみを再試行します。Oracle BI EEは、問合せを再試行せずに、挿入と削除のみを再試行します(再実行される削除は除く)。構成値は、Oracle BIスケジューラのinstanceconfig.xmlファイルにあります(PurgeIntervalMinutes)。

Oracle BIスケジューラは、Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブで定義されたポート範囲から割り当てられたポート上で、Cluster Controller通信およびクライアント・リクエストをリスニングします。

15.1.2.1.8 BI JavaHostの高可用性の考慮事項

Oracle BI JavaHostコンポーネントは、Oracle BIプレゼンテーション・サービスが、Oracle BIスケジューラ、Oracle BI Publisherおよびグラフ生成のためのJavaタスクなど様々なコンポーネントをサポートできるようにするサービスを提供します。他のすべてのコンポーネントと同様に、管理者はFusion Middleware Controlを使用して、デプロイされるインスタンス数と場所を制御できます。JavaHostクライアントのデフォルト構成では、すべての使用可能なJavaHostが使用されます。これは、ローカルJavaHostのみを使用する以前の10gのデフォルト構成とは異なります。

JavaHostサービスは、Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブで定義されたポート範囲から割り当てられたポート上のプレゼンテーション・サービスおよびOracle BIスケジューラからリクエストを受信します。

15.1.2.2 共有ファイルと共有ディレクトリ

Oracle BI EEでは、プロセスの状態は、分散通信プロトコルを介してではなく、共有ファイル・システムとデータベースを介して共有されます。特に、Oracle BI EEは、プロセス内やJavaコンポーネント内の状態を保管しません。したがってOracle BI EEは、コンポーネントの状態をシリアライズして、Javaクラスタ内で配信できるようにする必要はありません。

ファクト表とOracle BIスケジューラの表は、それぞれBI Serverインスタンス間とOracle BIスケジューラ・インスタンス間で共有されます。ファイル・システムの共有はあまり標準的ではないため、これについてはこの項の後半で説明します。NASやSANなどの共有ストレージ・デバイスを使用できます。

15.1.2.2.1 Oracle BIプレゼンテーション・カタログの共有ファイル

クラスタ内のプレゼンテーション・サービス・インスタンスは、共通のOracle BIプレゼンテーション・カタログを共有します。Oracle BIプレゼンテーション・カタログは、共有されたNASデバイスまたはSANデバイスに配置されている必要があります。プレゼンテーション・サービスのすべてのインスタンスは、この共有デバイスに対する読取りと書込みのアクセス権を持っている必要があります。同時アクセスは、ファイル・システムのロック・セマンティックによって管理されます。

Oracle BIプレゼンテーション・カタログは、頻繁にアクセスされる多数の小さいファイルで構成されているため、場合によっては、ファイル数が共有ファイル・システムのファイル制限を超えることに注意してください。システムのファイル制限の設定については、お使いの共有ファイル・システムのドキュメントを参照してください。

15.1.2.2.2 リポジトリ公開ディレクトリの共有ファイル

クラスタに参加しているすべてのBI Serverが、リポジトリ公開ディレクトリを共有し、それによってオンライン・モードで編集されるリポジトリのマスター・コピーが保持されます。マスターBI Serverには、このディレクトリに対する読取り権限および書込み権限が付与されている必要があります。その他のすべてのBI Serverには、読取り権限が付与されている必要があります。

クラスタ化されたBI Serverは、起動時にこのディレクトリを調べて、リポジトリの変更の有無を確認します。起動時に、BI Serverインスタンスは、公開ディレクトリ内のリポジトリをたとえば次のようなローカル・リポジトリ・ディレクトリにコピーします。

ORACLE_INSTANCE/bifoundation/OracleBIServerComponent/coreapplication_obis1/repository

このコピーは再起動時にしか実行されないため、すべてのBI Serverインスタンスが再起動されるまでは、書込み可能なrpdファイルを含むクラスタでは一貫性のない動作が発生することがあります(メタデータが分析からのリクエストに一致しないなど)。メタデータの変更は、本番環境の読取り専用rpdファイルを使用して、通常は開発環境でオフラインで行われます。

Fusion Middleware Controlでは「デプロイメント」ページにある「リポジトリ」タブの「共有場所」パラメータで、リポジトリ公開ディレクトリの場所を指定します。

15.1.2.2.3 グローバル・キャッシュの共有ファイル

グローバル・キャッシュは、クラスタに参加しているすべてのBI Serverによって共有されます。これは共有ファイル・システムのストレージ・デバイスに配置されており、パージ・イベント、シード・イベント(多くの場合はエージェントによって生成されます)、およびシード・イベントと関連付けられた結果セットを格納します。各Oracle BI Serverは、通常の問合せ用に固有のローカル問合せキャッシュを保持します。

グローバル・キャッシュの共有ファイル要件は次のとおりです。

- すべてのBI Serverは、グローバル・キャッシュ・ディレクトリに対する読取りと書込みのアクセス権を持っている必要があります。

- グローバル・キャッシュのパラメータは、クラスタに参加している各BI ServerノードのNQSConfig.INIファイルで構成します。グローバル・キャッシュは、Fusion Middleware Controlを使用して中央で管理されます。

- BI Serverは、問合せキャッシュを保持します。これは、ローカルなディスクベースの問合せ結果セットのキャッシュです。この問合せキャッシュによって、BI Serverはバックエンド・データベースにアクセスすることなく、潜在的に多くの問合せ要求を満たすことができるため、問合せ応答時間が大幅に短縮されます。問合せキャッシュのエントリは、バックエンド・データベースで更新が発生すると不要になるため、定期的に消去する必要があります。問合せキャッシュの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。

15.1.2.2.4 Oracle BIスケジューラ・スクリプトの共有ファイル

Oracle BIスケジューラ・スクリプトのネットワーク共有を作成する必要があります。ネットワーク共有を作成するには、Oracle BIスケジューラのinstanceconfig.xmlファイルのSchedulerScriptPath要素およびDefaultScriptPath要素を更新します(このファイルは、ORACLE_INSTANCE/config/OracleBISchedulerComponent/coreapplication_obischnにあります)。Oracle BIスケジューラ・サーバーは、この共有に対する読取りと書込みのアクセス権を持っている必要があります。

15.1.2.3 クラスタの起動と停止

プロセス間には依存関係が存在するため、特定の順序でクラスタを起動する必要があります。起動手順は次のとおりです。

1. すべてのWebLogic管理対象サーバーを起動します。システム・コンポーネントは、それぞれのローカル管理対象サーバーから認証サービスを受けます。

2. Fusion Middleware Controlの「すべて起動」ボタンを使用して他のプロセスを起動します。「すべて起動」ボタンを使用すると、Javaアプリケーションおよびシステム・コンポーネントが確実に適切な起動順序で起動されます。

15.1.2.4 クラスタワイドの構成変更

構成の変更は高可用性にとって非常に重要であり、その中でもクラスタのメンバーに対する変更は特に重要です。クラスタに新しいメンバーを追加できないと、障害を修復できず、クラスタはその後の障害に対して脆弱になります(このため、高可用性システムでは平均修復時間は平均故障間隔と同じくらい重要です)。

Javaとシステムという2つのテクノロジ・スタックは別々に管理されます。

WebLogicの構成変更は、WebLogic管理コンソールで行います。標準のWebLogicメカニズムを使用して、変更中の構成をロックして、変更内容をすべての管理対象サーバーに伝播します。

システム・コンポーネントの構成変更は、Fusion Middleware Controlを使用して中央で行います。構成の変更を入力したら、「保存」をクリックして、構成の変更内容をすべてのローカルの構成ファイルに伝播します。この伝播は重要です。構成が破損していたり伝播に失敗した場合は、次の伝播によってローカル・ファイルが修正されます。Oracle JMX拡張機能によって、WebLogic構成ファイルの配布と同じようにファイル配布が実行されます。リモート・サイトでの配信は、JMX MBeanコールによって通知されます。MBeanはMBeanサーバーでホストされる必要があるため、これは、Oracle BI EEシステム・コンポーネントをホストしているすべてのマシンは、どのようなOracle BI EE Javaコンポーネントもホストしていない場合でも、WebLogic管理対象サーバーも備えている必要があることを意味します。

すべてのコンポーネントは、そのコンポーネントが次回に再起動されたときに初めて構成変更にアクセスします。コンポーネントの稼働中に構成変更は適用されません。

構成変更は次の場合にトリガーされます。

- Fusion Middleware Controlで加えられた変更を管理者がコミットした場合。

- MBean API(このAPIにはFusion Middleware Controlのユーザー・インタフェースが直接反映されます)によって加えられた変更を管理者がコミットした場合。

新しいインストールを登録するエンタープライズ・インストールによって構成の配信はトリガーされません。これによって、管理者がFusion Middleware Controlから選択できるマシンの集合が変更されます。新しいコンポーネント・インスタンスは構成に自動的に追加されません。

15.1.2.5 障害からの保護および予想される動作

この項では、発生する可能性のある様々な種類の障害と、各種類の障害が発生したときに予想される動作について説明します。

15.1.2.5.1 マシンの障害

マシンで一時的な障害が発生した場合、クラスタは再起動されたコンポーネントを検知して、それらのコンポーネントを再び使用し始めます。マシンの障害が永続的ならば、そのマシンは交換する必要があります。既存のクラスタを拡張するには、エンタープライズ・インストールを使用して、新しいマシンにOracle BI EEをインストールします。

Oracle BI EEマシンの障害からのリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の別のホストへのOracle BI EEのリカバリに関する項を参照してください。

15.1.2.5.2 WebLogic管理サーバー障害

WebLogic管理サーバーはシングルトンであるため、同時に複数のインスタンスを稼働させることはできません。WebLogic管理サーバーの保護の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。Oracle BI EEでは、WebLogic管理サーバーは管理タスクにのみ使用されます。

WebLogic管理サーバーが停止していると、Oracle BI EEを再構成することも、Fusion Middleware Controlを使用してログ・ファイルを参照することもできません。

15.1.2.5.3 WebLogic管理対象サーバーの障害

WebLogicノード・マネージャは、管理対象サーバーの障害を検知します。すべてのJavaコンポーネントはステートレスであるため、Oracle BI EEは、Javaクラスタの状態のメンテナンスについては考慮に入れていません。

システム・コンポーネントから管理対象サーバーへのすべての通信(Presentation Servicesからアクション・サービスへの通信など)では、ローカル管理対象サーバーへのHTTPを使用します。ローカル管理対象サーバーで障害が発生した場合は、ノード・マネージャによってそれが再起動されます。

管理対象サーバーが再起動できないときに、マシンに障害がない場合、同一のマシン上で実行しているシステム・コンポーネントには、次のような影響があります。

- BI Server: ローカル管理対象サーバーが正常に稼働するまでサービスを停止し、これにより、BI Serverを介したログインが影響を受けることが防止されます。ローカル管理対象サーバーが稼働していないことをBI Serverが検知すると、ログイン・リクエストを他のBI Serverに送信するようにCluster Controllerに指示します。

- プレゼンテーション・サービス: アクションを実行できません。

- Oracle BIスケジューラ: アクティブ・スケジューラがこのマシン上で実行されている場合、スケジュール済アクションを実行できません。
新しいScheduler接続(ジョブ・マネージャなどから)を確立できません。ローカルの管理対象サーバーを実行していないホスト上のOracle BIスケジューラは、新しいユーザーを認証できません。

管理対象サーバーをオフラインにする必要がある場合は、最初に、そのマシン上で実行しているすべてのシステム・コンポーネントを停止します。特定のマシン上の管理対象サーバーが使用できなくなる場合は、そのマシン上で実行しているすべてのシステム・コンポーネントを停止します。

15.1.2.5.4 Oracle BIスケジューラの障害

Cluster Controllerは、Oracle BIスケジューラを監視および管理します。Oracle BIスケジューラが使用不能な場合は、Cluster Controllerは、次にアクティブ化するOracle BIスケジューラ・インスタンスを決定します。元のプライマリOracle BIスケジューラが再び使用可能になった場合でも、そのOracle BIスケジューラにプライマリ・ロールが戻されることはありません。

アクティブなOracle BIスケジューラで障害が発生したときに、確立済のクライアント接続がエラーを受信することはありません。これは、Oracle BIスケジューラ・プロトコルがステートレスであり、シームレスにフェイルオーバーするからです。

- エージェント: エージェントの実行ではOracle BIスケジューラの表に状態が保持されます。次のOracle BIスケジューラ・インスタンスがアクティブになると、このインスタンスは、実行途中であったすべてのジョブ・インスタンスの状態を読み取って、これらのインスタンスを実行します。スケジュール済エージェントは、アクティブなインスタンスの障害発生前に配信されなかった受信者に対してのみ配信します。
正常に行われた配信は、配信の完了後にOracle BIスケジューラ表に記録されます。配信は完了したがその事実が記録される前にOracle BIスケジューラがフェイルオーバーした場合、配信が繰り返されます。このため、繰返しの配信が数回実行されることがあります。

エージェントのフェイルオーバーは、スケジュール済のエージェントについてのみサポートされます。たとえば、Answersのツールバーで「エージェントを今すぐ実行」をクリックした後に、プライマリOracle BIスケジューラで障害が発生した場合は、そのエージェントはセカンダリScheduler上で引き続き実行されることはなく、エラー・メッセージが「今すぐ実行」結果ダイアログ・ボックスに表示されます。

- Java、コマンドラインまたはスクリプトのジョブ: これらのジョブは、新しいジョブ・インスタンスを使用して最初から再実行されます。

注意:

すべてのジョブ・インスタンスは、ジョブ・マネージャから手動で再実行できます。エージェントについては、正常に配信されなかったユーザーに対してのみ配信されます。たとえば、エージェントの実行途中でメール・サーバーが停止した場合、そのインスタンスの再実行では、メール・サーバーの障害が原因で電子メールを受信できなかった受信者に対してのみ配信されます。

15.1.2.5.5 Cluster Controllerの障害

Cluster Controllerは、BI ServerまたはOracle BIスケジューラの障害の検知と、障害が発生したサーバーのクライアントのフェイルオーバーをサポートします。

Cluster Controllerは、アクティブ/パッシブのモデルに基づいて動作します。すべてのクライアントは、まずプライマリCluster Controllerへの接続を試行します。プライマリCluster Controllerが使用不能な場合は、クライアントはセカンダリCluster Controllerに接続します。セカンダリCluster Controllerは、負荷と可用性に基づいてリクエストをBI Serverに転送するとともに、アクティブなOracle BIスケジューラ・インスタンスにも転送します。プライマリが後で使用可能になった場合は、すべてのリクエストはプライマリに再び転送されます。

セカンダリCluster Controllerは、各BI Server上のセッション・カウントを監視しますが(プライマリと同様に)、プライマリCluster Controllerが停止している場合を除いて、どのOracle BIスケジューラがアクティブ・スケジューラであるかを決定しません。

プライマリとセカンダリのCluster Controllerは相互のライフ・サイクルを監視します。Cluster Controllerインスタンス間では通信不能になっているが、各インスタンスは稼働しており他のクライアントと通信できる場合は、スプリット・ブレイン障害が発生する可能性があります。このような場合は、BI Serverは影響を受けませんが、Oracle BIスケジューラの2つのインスタンスが同時にアクティブになる可能性があります。まれに、この状況が原因となって、ジョブが二重に実行される場合があります。通信が回復すると、プライマリCluster Controllerは、1つのOracle BIスケジューラのみがアクティブになる必要があることをクラスタに指示します。クラスタ・コンポーネントは同一のLAN上に配置して、スプリット・ブレイン障害の可能性を最小限に抑える必要があります。

両方のCluster Controllerが使用不能な場合は、プレゼンテーション・サービスは、ログインしようとするすべての新しいユーザーにエラーを返します。既存のセッションは影響を受けません。

Cluster Controllerは、各BI Serverインスタンス上のアクティブ・セッションの数を常時監視しています。新しいODBC接続が確立されると、Cluster Controllerは新しいセッションを割り当てることで、BI Server当たりのセッション数の均衡を保ちます。BI Serverインスタンスが一時的に停止してから回復した場合は、このインスタンスのセッション・カウントがクラスタ内の他のインスタンスのセッション・カウントと等しくなるまでは、すべての新しいODBCセッションはこのノードにルーティングされます。

Cluster Controllerで障害が発生すると、新しいセッションを最初に作成しようとしたユーザーに対しては、セカンダリCluster Controllerがそのセッションを開始するために約6秒間の遅延が生じます。それ以降は、他のすべての接続はセカンダリCluster Controllerにルーティングされます。

15.1.2.5.6 プレゼンテーション・サービスの障害

プレゼンテーション・サービスの障害は次に影響を与えます。

- Webクライアント: 初期ユーザー・セッション・リクエストは、任意のプレゼンテーション・サービス・インスタンスに送信できますが、その後は各ユーザーは特定のプレゼンテーション・サービス・インスタンスにバインドされます。そのプレゼンテーション・サービス・インスタンスが失われると、セッションが切断されて、ブラウザにエラーが返されます。サーバーが使用不能になったときに進行途中であった作業のうち、ディスクに保存されていなかったものの内容はすべて失われます。ユーザーは再びログインして、使用可能なプレゼンテーション・サービス・インスタンスに対する新しい接続を確立する必要があります。ユーザーのログインがOracle Single Sign-Onなどのシングル・サインオン・システムを使用して行われている場合は、この再ログインは自動的に実行されます。新しいプレゼンテーション・サービス・セッションによって新しいBI Serverセッションが作成されます。

注意:

プレゼンテーション・サービス・インスタンスで障害が発生すると、少し間隔を置いてから、システムによってそのインスタンスで障害が発生したことが検知されて、ユーザーが新しいプレゼンテーション・サービス・インスタンスに移行されます。シングル・サインオン・ソリューションが使用されている場合は、ユーザーは再認証する必要はありません。シングル・サインオンが使用されていない場合は、ユーザーは再認証する必要があります。

- エージェント: Oracle BIスケジューラにエラーが転送されます。Oracle BIスケジューラは障害をログに記録してから、ジョブを再試行します。この再試行によって、使用可能なプレゼンテーション・サービスに対する新しい接続が確立されます。

15.1.2.5.7 BI Serverの障害

BI Serverで障害が発生すると、ODBCエラーが適切なクライアントに送信されます。

- Presentation Services: 各Webユーザーのリクエストは、単一のBI Serverによって処理されます。BI Serverが使用不可能な場合、ユーザーにはエラーが表示されます。ただし、ブラウザを更新することで、使用可能なBI Serverとの新しいセッションが確立されます。この調停は、そのユーザーのかわりプレゼンテーション・サービス・コンポーネントが実行することに注意してください。

- 管理ツール: 管理ツールは、その接続先であるBI Serverが使用不能になると、ODBCエラーを転送してから接続を切断します。管理者は、管理ツールを使用して再接続する必要があります。

- エージェント: BI Serverで障害が発生すると、Oracle BIスケジューラにエラーが転送されます。Oracle BIスケジューラは障害をログに記録してから、ジョブを再試行します。その後で、使用可能なBI Serverとの接続が確立されます。

- サード・パーティ・クライアント: サード・パーティ・クライアントはODBCを使用してBI Serverに接続します。BI Serverで障害が発生すると、ODBCによってエラーが転送され、ODBC標準に従ってセッションが切断されてから再確立されます。

- マスターBI Serverの障害: マスターBI Serverが使用不能である場合、オンライン・メタデータの変更は実行できません。これは管理操作であり、ランタイムの可用性には影響がありません。
マスターBI Serverが永続的に使用不能になった場合は、他のサーバーのいずれかを新しいマスターとして指定する必要があります。

- Fusion Middleware Controlの「容量管理」ページの「スケーラビリティ」タブを使用して、マスターBI Serverをスケール・インします。

- Oracle BI EEシステム・コンポーネントを再起動します。
システムによって、新しいマスターBI Serverが割り当てられます。

15.1.2.5.8 Oracle BI EEのトラブルシューティング

一般にリカバリの問題は、プロセスの起動失敗に関係しています。推奨されるトラブルシューティング手順は次のとおりです。

1. Fusion Middleware Controlをチェックして、どのプロセスが実行されているか確認します。これにはOPMNによって報告される状態が反映されます。

2. OPMNログ・ファイルをチェックします。これらは、Fusion Middleware Controlからアクセスできます。これらは、表15-1で明示している場所でもアクセスできます。

3. 正常に実行されなかったプロセスを特定したら、そのログ・ファイルをチェックしてください。このログ・ファイルには、Fusion Middleware Controlから、または表15-1で明示している場所でアクセスできます。

特定のプロセスは、そのピアと通信できない場合に停止されます。この問題を診断する手順は次のとおりです。

1. 正常に実行されなかったプロセスを特定します。ログ・ファイルで低レベル・ソケット・エラーを探します。これによりポートとサーバー・アドレスが特定されます。ローカル構成ファイルを調べて、そのポートをリスニングするように構成されたプロセスを確認します。単純なデプロイメントでは、第15.1.2.1項「Oracle BI EEの高可用性アーキテクチャ」のコンポーネントに関する説明で示されているように、デフォルトのポート割当てが使用されます。現在構成されているポートは、Fusion Middleware Controlの「容量管理」ページの「可用性」タブで確認できます。

2. ピアが動作しているかどうか確認します。ピアが動作している場合は、そのログ・ファイルをチェックして、通信を拒否するエントリがないか確認します。通信が拒否される可能性があるのは、SSL構成が矛盾している場合やプロトコル障害が発生している場合です。

Cluster Controllerの管理対象プロセスの構成がCluster Controllerと一致していない場合は、これらのプロセスは正常に実行されません。一部のフェイルオーバー・イベントはログに記録されませんが、Cluster Controllerのログ・ファイルには、すべてのOracle BIスケジューラ・インスタンスまたはBI Serverインスタンスの障害が記録されます。

初回の起動後にログ・ファイルを確認してください。BI ServerまたはOracle BIスケジューラのインスタンスが、Cluster Controllerによる仕様どおりに正しく構成されていない場合は、そのインスタンスは、停止されない可能性がありますが、クラスタには追加されません。ログ・ファイルにはこのようなエラーが記録されます。

15.1.3 Oracle Essbaseのコンポーネント・アーキテクチャ

図15-3は、Oracle Essbaseの単一インスタンス・アーキテクチャを示しています。

図15-3 Oracle Essbaseの単一インスタンス・アーキテクチャ

「図15-3 Oracle Essbaseの単一インスタンス・アーキテクチャ」の説明

15.1.3.1 Oracle Essbaseコンポーネントの特性

Essbaseコンポーネントのアーキテクチャは、次の4つの層で構成されています。

- Web: Oracle HTTP Server。

- アプリケーション: Oracle Hyperion Provider Services。これは、WebLogicアプリケーション・サーバーにデプロイされた中間層エンタープライズ・アプリケーションです。
Provider Servicesは、TCP/IPを使用してEssbaseエージェントおよびEssbaseサーバーと通信します。

- Essbaseサービス: Essbase Analytical Services。これは、OPMN、EssbaseエージェントおよびEssbaseアプリケーション・サーバーで構成されます。
OPMNは、Oracle Net Servicesを使用してEssbaseエージェントと通信します。Essbaseエージェントは、クライアントとEssbaseアプリケーション・サーバー間のコーディネータとして機能します。Essbaseエージェントには、そのサーバーとのパイプ通信チャネルがあります。また、TCP/IPを使用した通信も行います。

- 記憶域: Hyperion Registry。これは、構成情報を格納するリレーショナル・データベース内のリポジトリです。EssbaseエージェントとEssbaseアプリケーション・サーバーは、バックエンド・データベースとの通信にJDBCまたはODBCを使用します。

15.1.3.1.1 状態情報

Oracle Essbaseセッションの状態は、メモリー内に保持され、セッション・フェイルオーバーはありません。クライアント・セッションが失われたときには、そのクライアントは再度ログオンする必要があります。

15.1.3.1.2 ランタイム・プロセス

Essbase Analytical Servicesは、ランタイムに次のプロセスで構成されます。

- Oracle Process Manager and Notification Server(OPMN): Oracle Fusion Middlewareコンポーネント(Essbaseなど)を監視するデーモン。
OPMN管理コンポーネントは、opmn.xmlで指定されます。

Essbaseエージェントの起動、停止、再起動および監視には、OPMNのコマンドライン・インタフェースを使用します。第15.1.1.1.1項「プロセスのライフサイクル」を参照してください。Essbaseアプリケーション・サーバー・プロセスを直接開始または停止することはありません。OPMNは、Oracle Net Servicesを使用してEssbaseエージェントと通信します。

- Essbaseエージェント(ESSBASE): アプリケーションに対するユーザーのリクエストをコーディネイトする役割を果たすプロセス。
Essbaseエージェントは、OPMNによって直接管理されます。Essbaseエージェントは、アプリケーション・サーバーを管理します。

- Essbase Application Server(ESSSVR): すべてのデータ記憶域、キャッシュ操作、計算およびデータ・セキュリティを処理するEssbase Application Serverプロセス。

15.1.3.1.3 プロセスのライフサイクル

OPMNコマンドのopmnctlを使用して、Essbaseエージェントの起動、停止および監視を実行します。

起動

OPMNと、そのOPMNの管理対象コンポーネントをすべて起動するには、$ORACLE_INSTANCE/bin/opmnctl startallを使用します。

OPMNを実行している状態でEssbaseエージェントのみを起動するには、$ORACLE_INSTANCE/bin/opmnctl startproc ias-component=essbaseserver1を使用します。essbaseserver1は、opmn.xmlで指定された管理対象Essbaseインスタンスの名前になります。

停止

OPMNと、そのOPMNの管理対象コンポーネントをすべて停止するには、$ORACLE_INSTANCE/bin/opmnctl stopallを使用します。

Essbaseがフェイルオーバー・クラスタ・モードで構成されていて、OPMNを実行している状態で、Essbaseエージェントのみを停止するには、$ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=essbaseserver1 process-type=Essbaseを使用します。essbaseserver1は、opmn.xmlで指定された管理対象Oracle Essbaseインスタンスの名前になります。

監視

管理対象プロセスのステータス情報を取得するには、$ORACLE_INSTANCE/bin/opmnctl statusを使用します。

15.1.3.1.4 リクエスト・フロー

Essbaseとの通信には、クラスタ名(Provider Servicesによって解決されます)、URL(アプリケーションによって解決されます)、または物理的なホストおよびポートを使用できます。

15.1.3.1.5 外部依存性

Essbaseは、データベース・リポジトリであるHyperion Registryを使用して、構成情報を格納および取得します。

Essbaseは、Oracle Internet Directory(OID)などの外部ディレクトリ・サービスと連動するように構成できます。Essbaseは、LDAPプロトコルを使用してOIDと通信します。

15.1.3.1.6 構成アーティファクト

次の表では、Essbaseの構成アーティファクトについて説明しています。

表15-2 Essbaseの構成アーティファクト

ファイル

場所

説明

Essbase構成ファイルessbase.cfg

$ARBORPATH/bin

Essbaseの構成可能パラメータの値を格納します。

Essbaseセキュリティ・ファイルessbase.sec

$ARBORPATH/bin

セキュリティおよびアプリケーションについての情報を格納します。

OPMN構成ファイルopmn.xml

$ORACLE_INSTANCE/config/OPMN/opmn

すべての管理対象コンポーネントと、各管理対象コンポーネントに渡される環境変数をリストします。

15.1.3.1.7 デプロイメント・アーティファクト

デプロイメント・アーティファクトは、JDBCおよびODBC、reg.properties、セキュリティ・アーティファクトなどを含むEssbaseを適切に設定するために必要になります。デプロイメント・アーティファクトは、EssbaseをプロビジョニングするOPMNに渡す必要があります。

15.1.3.1.8 ログ・ファイル

診断ログ・ファイルは、デフォルトでは、$ORACLE_INSTANCE/diagnostics内に配置されます。

Essbaseエージェントは、メッセージをEssbase.logに書き込みます。

- デフォルトの場所: $ORACLE_INSTANCE/diagnostics/logs/Essbase/<Essbaseインスタンスの名前>/essbase

- 構成される場所: $HYPERION_LOGHOME/essbase

Essbaseアプリケーション・サーバーは、メッセージをアプリケーション・サーバーのログ・ファイルに書き込みます。

- デフォルトの場所: $ORACLE_INSTANCE/diagnostics/logs/Essbase/<Essbaseインスタンスの名前>

- 構成される場所: $HYPERION_LOGHOME/essbase/app

OPMNは、Essbaseコンソール・ログを作成します。このログは、デフォルトでは、$ORACLE_INSTANCE/diagnostics/logs/Essbase/<Essbaseインスタンスの名前>内にあります。

Essbase転送PingログEssbasePing.logは、デフォルトでは、$ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn内にあります。

リース管理ログは、フェイルオーバー構成でのみ作成されます(第15.1.4.2項「障害からの保護および予想される動作」を参照してください)。EssbaseエージェントとEssbaseサーバー内のリース管理モジュールは、それぞれに固有のログにメッセージを書き込みます。

- デフォルトの場所: $ORACLE_INSTANCE/diagnostics/logs/Essbase/<iasコンポーネント名>/essbase

- 構成される場所: $HYPERION_LOGHOME/essbase

15.1.4 Oracle Essbaseの高可用性の概要

この項では、Essbaseを高可用性環境で使用する場合の概要について説明します。

15.1.4.1 Oracle Essbaseの高可用性アーキテクチャ

図15-2は、Oracle BI EEの高可用性デプロイメントにおけるEssbaseを示しています。

15.1.4.1.1 共有ファイルと共有ディレクトリ

ARBORPATH(構成ファイル、セキュリティ・ファイル、およびすべてのアプリケーションとそれに対応するデータベースを含む)は、共有ディスクに配置されています。インスタンス固有のファイル、バイナリおよびログ・ファイルは、デフォルトではローカル・ディスクに配置されますが、共有することもできます。たとえば、opmn.xmlの構成設定を変更して、ログ・ファイルを共有ディスクに配置できます。

15.1.4.1.2 クラスタワイドの構成変更

共有される構成情報は、共有ディスク上のessbase.cfgにあります。たとえば、リースの取得または更新のタイムアウト設定についての変更は、共有ディスク上のessbase.cfgで行います。

15.1.4.2 障害からの保護および予想される動作

フェイルオーバーに向けて、2ノード・クラスタでEssbaseを構成できます。

フェイルオーバー・クラスタの設定に含まれる項目は、次のとおりです。

- 2つのノード
常に一方のノードがアクティブであり、もう一方はパッシブになります。

- ノード間の共有ディスク
共有ディスクには、アプリケーション、データベース、製品構成、および$ARBORPATH以下に配置されるすべてのものを格納します。

- $ESSBASEPATH内の製品のバイナリなど
各ノードは直接接続されたストレージ・ディスクにバイナリを保持できます。

- レジストリ・データベースおよびリース・データベース
これらの必須データベースは、冗長ストレージ・デバイスに配置する必要があります。

リース・メカニズムは、唯一のEssbaseエージェントと、そのエージェントのアプリケーション・サーバーのセットのみがアクティブになることを保証します。常に、1つのリソースに対して必ず唯一のリースがアクティブになります。アクティブなリースの所有者は、そのリソースに対する所有権を持ちます。このリース・スキームは、データベース内のリース表を使用することで実装されます。リース表は、Repository Configuration Utility(RCU)によってシードされます。

フェイルオーバーの機能を利用するには、Java APIクライアントはAPSサーブレットのエンドポイントURLを使用してログオンする必要があります。このURLはフェイルオーバー・クラスタのクラスタ名を指定することになります(例: http://WEBHOST1:7777/aps/Essbase?clusterName=cludemo)。

Provider Servicesは、クラスタ名をクラスタ内でアクティブなノードのホスト名とポートに解決します。

セッションのフェイルオーバーはサポートされません。サービスのフェイルオーバーが発生すると、クライアントはエラーメッセージを受信します。そのクライアントは、再度ログオンする必要があります。

15.1.4.3 トラブルシューティング

Essbaseのフェイルオーバーをトラブルシューティングするには、OPMNログとEssbaseログを調べてイベントの発生順序を確認します。たとえば、OPMNはEssbaseを起動したが、データベース認証に失敗したためにEssbaseはリースを取得しなかったということがログに示されていることがあります。

15.1.5 Oracle Essbaseのクラスタリングの構成

この項では、高可用性環境でのEssbaseのクラスタリングの設定方法について説明します。

15.1.5.1 前提条件

単一EssbaseエージェントのローカルARBORPATHの内容を共有ARBORPATHにコピーします。

プロビジョニング・フレームワークにより、単一Essbaseエージェント(essbaseserver1)が自動的に作成され、ARBORPATHが/u02/local/oracle/config/BIInstance/Essbase/essbaseserver1を指すよう設定されます。ローカルARBORPATHの下には3つのディレクトリがあり、これらのディレクトリを共有ARBORPATHの場所にコピーする必要があります。

$ ls /u02/local/oracle/config/BIInstance/Essbase/essbaseserver1 app   bin   java

15.1.5.2 共有ARBORPATHの構成

共有ARBORPATHを構成する手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「Farm_BIDomain」ウィンドウで、「Business Intelligence」ノードを開きます。

3. 「coreapplication」をクリックしてから、「可用性」の次に「フェイルオーバー」をクリックします。

4. 「構成をロックして編集」をクリックして、「可用性」タブの「Essbaseエージェント」セクションをアクティブ化します。

5. Essbaseエージェントの「共有フォルダ・パス」を指定します。
指定しておかない場合は、ローカルのOracleインスタンス・ホームの下にある構成フォルダを共有場所にアップロードします。

6. 「適用」をクリックしてから、「変更のアクティブ化」をクリックします。

15.1.5.3 Essbaseエージェントのセカンダリ・インスタンスの構成

高可用性を実現するために、Essbaseエージェントのセカンダリ・インスタンスを構成して分散させる手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「Farm_BIDomain」ウィンドウで、「Business Intelligence」ノードを開きます。

3. 「coreapplication」をクリックしてから、「可用性」の次に「フェイルオーバー」をクリックします。

4. 「構成をロックして編集」をクリックして、「可用性」タブの「Essbaseエージェント」セクションをアクティブ化します。

5. Essbaseエージェントの「セカンダリ・ホスト / インスタンス」を指定します。「適用」をクリックします。
「潜在的単一点障害」で、Essbaseエージェントに対して「問題はありません」と報告されている必要があります。

6. 「変更のアクティブ化」をクリックします。

7. 「システムの管理」の下の「再起動」をクリックしてから、「はい」をクリックします。

15.1.6 Oracle Hyperion Provider Servicesのコンポーネント・アーキテクチャ

Oracle Hyperion Provider Services(Provider Services)は、中間層データ・ソース・プロバイダです。これは、Oracle Essbase for Java API、Oracle Hyperion Smart View for Office、Fusion EditionおよびXMLAの各クライアントと、Oracle Business Intelligence Enterprise Editionを対象にしています。Provider Servicesは、高度同時並列分析シナリオをサポートし、Web対応のエンタープライズ分散環境にスケーラビリティと信頼性を提供します。

図15-4は、Provider Servicesの単一インスタンス・アーキテクチャを示しています。

図15-4 Provider Servicesの単一インスタンス・アーキテクチャ

「図15-4 Provider Servicesの単一インスタンス・アーキテクチャ」の説明

Provider Servicesには、Essbase Java API、SmartViewプロバイダ、およびXMLA(XML for Analysis)プロバイダという3つのサブコンポーネントが含まれています。これらのサブコンポーネントは、それぞれJava APIクライアント、SmartViewクライアントおよびXMLAクライアントにサービスを提供します。Provider Servicesは、サブコンポーネントごとに異なる3つのサーブレットに合わせて設計されています。

これらのクライアントとProvider Services間の通信には、HTTP(S)プロトコルを使用します。JAPIクライアントとXMLAクライアントは、Essbase通信用に設計されています。Smart Viewクライアントを使用すると、ユーザーはEssbase、Oracle Hyperion Planning、Fusion EditionやOracle BI EEサーバーなどのデータ・ソースに接続できます。

15.1.6.1 Oracle Hyperion Provider Servicesコンポーネントの特性

次の項では、Prover Servicesコンポーネントの特性について説明します。

15.1.6.1.1 状態情報

Provider Servicesのセッション情報は、ユーザーが切断するか、セッション・タイムアウトになるまでメモリー内に格納されます。

15.1.6.1.2 ランタイム・プロセス

Provider Servicesは、WebLogicサーバーのアプリケーション・コンテナにデプロイされたJavaベースのエンタープライズ・アプリケーションです。実行時には、単一のJavaプロセスが存在し、これがコンテナになります。Provider Servicesは、その他の外部プロセスを実行しません。

15.1.6.1.3 プロセスのライフサイクル

Provider Servicesプロセスのライフサイクルは、WebLogicサーバーにデプロイされた標準のJavaベースのエンタープライズ・アプリケーションのライフサイクルと同じです。

15.1.6.1.4 リクエスト・フロー

Oracle HTTP Web Serverなどのディスパッチャは、ゲートウェイとして機能し、リクエストをクラスタの一部であるProvider Servicesインスタンスに配信します。Provider Servicesは、スティッキー・セッションをサポートしています。そのため、Provider Servicesインスタンスとのユーザー・セッションを確立すると、ユーザーが切断するまで、同一のインスタンスがクライアントからの後続のリクエストをすべて処理します。Provider Servicesインスタンスに障害が発生したときには、ユーザーは既存の無効なセッションを切断してから、失敗したセッションと同じURL(ディスパッチャURL)を使用して再度ログオンする必要があります。

15.1.6.1.5 外部依存性

Provider Servicesは、Hyperion Registryに依存します。SmartViewプロバイダ・コンポーネントは、Registry Java APIを使用して、データ・ソース(datasources.xml)とSmart Slicesをレジストリ・データベースに格納します。また、Essbase Java APIコンポーネントは、ドメイン関連(domain.dbファイル)情報を保持するためにHyperion Registryを使用します。この情報のすべては、Provider ServicesのRegistryのLOGICAL_WEB_APPコンポーネントに格納されます。

15.1.6.1.6 構成アーティファクト

Provider Servicesは、構成ファイルessbase.propertiesを保持します。このファイルは、$ORACLE_HOME/products/Essbase/aps/binに配置されています。Provider Servicesの起動スクリプトには、次のESS_ES_HOMEのJVM設定が必要です。この設定によって、起動スクリプトは実行時に構成ファイルを識別できるようになります。この設定では、PROVIDER_SERVICES_HOMEフォルダを指定します。このフォルダにbin/essbase.propertiesファイルが配置されています。

15.1.6.1.7 デプロイメント・アーティファクト

Provider Servicesのデプロイメント・アーティファクトに含まれるファイルは、次のとおりです。

- logging.xml: Provider Servicesのログを管理するための構成ファイル

- essbase.properties: Provider Services構成ファイル

- aps.ear: Provider Servicesエンタープライズ・アプリケーション・アーカイブ

15.1.6.1.8 ログ・ファイル

Provider Servicesのロギングは、ODLログ出力に基づいています。Provider Services起動スクリプトには、次のロギングに関連するJVM設定が必要です。

- oracle.core.ojdl.logging.config.file: Provider ServicesのODL logging.xmlファイル・パスを指定します。

- logging.folder: Provider Servicesサーバー・ログ・ファイルを格納する場所です。

注意:

クラスタ内に複数のProvider Servicesインスタンスがある場合は、それぞれのインスタンスに対して固有のログの場所が定義されています。インスタンスの場所がProvider Servicesのホーム内にある場合、管理者はすべてのProvider Servicesインスタンスに対して、そのフォルダへの読取り権限と書込み権限を付与する必要があります。

15.1.7 Oracle Hyperion Provider Servicesの高可用性の概要

Provider Servicesは、Oracle WebLogic Serverなどのアプリケーション・サーバー環境にデプロイし、この環境で実行します。Provider Servicesの高可用性をサポートするには、WebLogic Serverのクラスタ化機能とロード・バランシング機能を使用して、複数のProvider Servicesインスタンスをデプロイします。Provider Servicesなどのエンタープライズ・アプリケーションのクラスタ化の詳細は、WebLogic Serverのドキュメントを参照してください。

15.1.7.1 Oracle Hyperion Provider Servicesの高可用性アーキテクチャ

図15-2は、Oracle BI EE高可用性デプロイメントにおけるOracle Hyperion Provider Servicesを示しています。

15.1.7.1.1 Provider ServicesクラスタのHyperion Registry構造

前述の図のLOGICAL_WEB_APPは、Provider Servicesのインスタンスで構成されているクラスタを表します。各PROVIDER_SERVICES_WEB_APPコンポーネントには、実際のサーバーと、そのサーバーのProvider Servicesインスタンスのポートを格納します。次に、その例を示します。

LOGICAL_WEB_APPCluster_URL

|

----- PROVIDER_SERVICES_WEB_APP 1 server1:port

|

----- PROVIDER_SERVICES_WEB_APP 2

|

----- PROVIDER_SERVICES_WEB_APP 2 server2:port_y

LOGICAL_WEB_APPコンポーネント情報では、Provider Servicesクラスタの一意のURLを指定します。

15.1.7.1.2 クラスタワイドの構成変更

Provider Servicesは、起動時にのみessbase.propertiesファイルを読み取ります。このファイルをProvider Servicesの管理者が変更するときには、その管理者はProvider Servicesクラスタを再起動する必要があります。そうすることで、クラスタ内のすべてのProvider Servicesインスタンスは、構成の設定値で同期されます。

15.1.7.1.3 OPMN Essbaseのクラスタ・サポート

Essbaseのクラスタをサポートする場合、クライアントはProvider Servicesと通信することで、クラスタ内でアクティブなEssbaseノードをフェッチします。APIクライアント(CAPI/JAPI)は、アクティブなEssbaseホスト・インスタンスの詳細を取得するために、Provider ServicesのURL(OPMN Essbaseクラスタの名前を含む)を指定する必要があります。それにより、Provider Servicesは、アクティブなEssbaseノードの詳細をHyperion Registryから取得します。この項の残りの部分では、Provider ServicesとC/JAPIクライアントを使用した場合の動作について説明します。

15.1.7.1.4 Provider ServicesによるEssbaseデータベースのクラスタ化

Provider Servicesは、アクティブ/アクティブのクラスタ化によってEssbaseデータベースの高可用性をサポートします。Essbaseキューブ(データベース)をクラスタ化することで、ロード・バランシングとフェイルオーバーのサポートが可能になります。Provider Servicesは、一連のアクティブな複製データベースを管理し、このデータベースがユーザーのリクエストに応答します。ユーザーは、Essbaseクラスタを指定することでデータベースに接続します。ユーザーはアクセス対象のデータベースを意識する必要はありません。Provider Servicesによって、クラスタ内のデータベース間での可用性と優先順位のルールに基づいたルーティングが容易になります(これには、ラウンドロビン技法を使用します)。Essbaseクラスタは、Essbaseデータベースに対する読取り専用操作をサポートしています。データのロードやアウトラインの編集などのライトバック操作はサポートされていません。

15.1.7.2 障害からの保護および予想される動作

Provider Servicesは、スティッキー・セッションをサポートしています。Provider Servicesインスタンスとのユーザー・セッションが確立されると、ユーザーが切断するまで、同一のProvider Servicesインスタンスがクライアントからの後続のリクエストをすべて処理します。Provider Servicesインスタンスに障害が発生したときには(無効なセッション・エラーによって示されます)、ユーザーは既存の(無効な)セッションを切断してから再度ログオンする必要があります。新しいProvider Servicesインスタンスへのフェイルオーバーは透過的であるため、ユーザーは前に使用したAPS URL(ディスパッチャのURL)と同じURLに接続できます。ディスパッチャは、ゲートウェイとして機能するOracle HTTP Serverなどになります。このゲートウェイによって、リクエストはクラスタに属するProvider Servicesインスタンスに配信されます。

15.1.8 Oracle EPM Workspaceのコンポーネント・アーキテクチャ

Oracle Enterprise Performance Management(EPM)Workspace、Fusion Edition(Workspace)は、すべてのOracle HyperionコンテンツとOracle Hyperion以外のコンテンツにアクセスするために使用するWebユーザー・インタフェースです。Oracle Hyperionコンテンツには、レポート作成および分析フレームワークと、OracleのHyperion財務管理アプリケーションが含まれます。

15.1.8.1 Workspaceコンポーネントの特性

図15-5は、Workspaceの単一インスタンス・アーキテクチャを示しています。

図15-5 Workspaceの単一インスタンス・アーキテクチャ

「図15-5 Workspaceの単一インスタンス・アーキテクチャ」の説明

EPM Workspaceは、単一のJ2EE Webアプリケーションで構成されます。通常、このアプリケーションの前面にはOracle HTTP ServerなどのHTTPプロキシが配置されています。HTTPプロキシは、静的コンテンツを提供します。また、EPM Workspaceに統合された他の製品のプロキシになります。通常、コンテンツの集約はクライアント側で行われます。EPM Workspaceは、それ自体のプロセスでコンテンツを集約することはありません。つまり、EPM Workspaceは、ポータルとしては機能しないということです。

15.1.8.1.1 状態情報

EPM Workspaceのセッションは、通常のJ2EEセッションであり、メモリーにのみ保持されます。EPM Workspaceは、それが使用するセッションにおいてステートフルであり、そのセッションはどのDBに対してもシリアライズできません。

15.1.8.1.2 ランタイム・プロセス

EPM Workspaceは、通常のJ2EEランタイムを保持します。通常、ユーザーはEPM Workspaceに接続してからシステムにログオンし、Oracle Hyperion Financial Reportingなどの別の製品にアクセスします。バックグラウンド・スレッドや、その他の形式のサーバー側のサービスまたはジョブは存在しません。すべてのプロセスは、HTTPリクエストとして処理されます。

EPM Workspaceは、直接またはJSPとして実装された一連のサーブレットと、サーブレット・フィルタを使用します。EJBやJMSを使用することはありません。データベース・アクセスは、JDBCデータ・ソースについての標準のJNDIルックアップによって行われます。

15.1.8.1.3 プロセスのライフサイクル

EPM Workspaceは、WebLogicアプリケーション・サーバーにデプロイされた標準のJ2EE Webアプリケーションとして管理されます。そのアプリケーション・サーバーによって、これが管理、開始および終了されます。

15.1.8.1.4 リクエスト・フロー

EPM Workspaceに対するリクエストは、HTTPプロキシを通じて行われます。エンドユーザーがEPM Workspaceにアクセスするには、このHTTPプロキシを使用する以外に手段はありません。EPM Workspaceが、その他のWebアプリケーションやデータベースに対してリクエストを行うことはありません(ただし、そのEPM Workspaceのリポジトリ・データベースとEPM Registryデータベースを除きます)。

15.1.8.1.5 外部依存性

EPM Workspaceは、そのEPM Workspaceのリポジトリ・データベースと、Hyperion Registryに依存します。これらは、どちらも同一のスキーマになります。

多くのEPM製品は、初期認証とそれに含まれるユーザー・インタフェースを提供するためにEPM Workspaceに依存します。

15.1.8.1.6 構成アーティファクト

EPM Workspace全体の構成は、Hyperion Registryに格納されます。個別のユーザー・プリファレンスは、EPM Workspaceリポジトリに格納されます。

15.1.8.1.7 デプロイメント・アーティファクト

EPM Workspaceには、JDBCデータ・ソース以外のデプロイメント・アーティファクトはありません。

15.1.8.1.8 ログ・ファイル

管理対象サーバーのドメイン・ホーム内のlogs/workspaceサブディレクトリに移動して、workspace.logとFramework.logを確認してください。

15.1.9 Oracle EPM Workspaceの高可用性の概要

この項では、高可用性環境でEPM Workspaceを使用する場合の概要について説明します。

15.1.9.1 Workspaceの高可用性アーキテクチャ

EPM WorkspaceのHTTPプロキシとJ2EEデプロイメントの両方を、WebLogic Serverのクラスタ化メカニズムと、アプリケーション・サーバー・デプロイメントおよびデータ・ソースの標準的な使用によってクラスタ化できます。EPM Workspaceの高可用性には、スティッキー・セッションが必要になります。セッションのレプリケーションとフェイルオーバーはサポートされていません。

クラスタ化されたバージョンはすべて、同一にする必要があります。クラスタのメンバーに対するすべての更新は、同時に行う必要があります。

ロード・バランサ・ハードウェアまたはHTTPプロキシは、ラウンドロビン・ローテーションでリクエストを割り当てます。リポジトリ・データベースまたはHyperion Registryが失われると、リクエストは失敗します。リクエストが失敗すると、後続のリクエストによってEPM Workspaceの初期化と、そのEPM Workspaceのデータベース接続のリストアが試行されます。

EPM Workspaceインスタンスが開始および初期化されるときには、データベースの使用が大幅に増加します。多数のデプロイメントがある場合は、インスタンスの起動を重ならないようにすることで、クラスタの起動時間を短縮できることがあります。

15.1.9.1.1 共有ファイルと共有ディレクトリ

EPM Workspaceには、共有ファイルまたは共有ディレクトリがありません。ただし、Oracle JRFおよびEPMの共通ファイルを除きます。

15.1.9.1.2 クラスタワイドの構成変更

製品のバイナリとWebLogic Serverによって生成されたデプロイメント情報は、ファイル・システムに格納されます。構成はHyperion Registryに格納されます。Workspaceのすべてのインスタンスは、Hyperion Registryを介して同一の構成を共有します。構成は、EPM Workspace管理ユーザー・インタフェースから変更できます。また、EPM Workspace外のレジストリに明示的な更新を行うことでも変更できます。

通常、ファイル・システム・アーティファクトは、Oracle WebLogic Serverのファイル変更が必要になるような、パッチまたはデプロイメントやクラスタ化の再構成に際してのみ変更します。構成の変更に、ファイル・システムの更新は必要ありません。クラスタのメンバーは、更新された構成を次回の再初期化時に認識します。各クラスタ・メンバーに対して、そのメンバーの再初期化を指示する必要があります。Hyperion Registryはポーリングされません。

15.1.9.2 障害からの保護および予想される動作

障害が発生したノード上で未完了のリクエストおよびセッションは失われます。別のノードにルーティングされるブラウザからの後続のリクエストはインターセプトされるため、Workspaceへの再認証が必要になります。単一ノード障害に対してセッションを移行するプロビジョニングはありません。管理者がWorkspaceユーザーに対して停止時間などの情報をログオン時に通知できる機能があります。

注意:

データベースの停止は、BI Workspaceのセッションに影響を与えます。RACデータベース・バックエンドでは、データベース・インスタンスが停止すると、そのデータベースに接続したBI workspaceのセッションはエラーを生成し、再起動が必要になることがあります。

15.1.9.3 トラブルシューティング

管理対象サーバーのドメイン・ホーム内のlogs/workspaceサブディレクトリに移動して、Workspace.logとFramework.logを確認してください。

15.1.10 Oracle Hyperion Financial Reportingのコンポーネント・アーキテクチャ

Oracle Hyperion Financial Reporting(Financial Reporting)は、分析データをグラフィカルにデザインして表現するための強力なツールです。資金管理レポートや損益計算書、貸借対照表などの従来型の財務レポート形式をデザインできます。さらに、従来型の形式ではないテキストやグラフを含む財務データや分析データを設計することもできます。

Financial Reportingを使用すると、財務レポートを作成して、それをGeneral Ledgerシステムに配信できます。Reporting管理者は、財務レポートにEPM Workspaceを使用して、レポート、ブックおよびバッチ定義の作成や変更を実行します。また、EPM Workspaceにあるレポート作成スケジューラのユーザー・インタフェースからバッチ・ジョブをスケジュールします。Reportingユーザーは、General Ledgerユーザー・インタフェースを使用してレポートの実行や表示を行います。このユーザーは、General Ledgerブラウザ・ウィンドウのIFrame内でレポートを起動できます。

図15-6は、Financial Reportingの単一インスタンス・アーキテクチャを示しています。

図15-6 Financial Reportingの単一インスタンス・アーキテクチャ

「図15-6 Financial Reportingの単一インスタンス・アーキテクチャ」の説明

15.1.10.1 Oracle Hyperion Financial Reportingコンポーネントの特性

Financial Reportingには、サーブレットと、UIおよびXML生成用のJSPが含まれています。また、FR用のESSスケジューラ実装(FREssClient.ear)から使用するためのWebサービスAPI(JRFベース)も提供しています。FRWebAppには、HTTPコールを通じて検出および配信されるRMIオブジェクトも含まれています。このオブジェクトは、通常のRMIレジストリを置換することで、マシンごとに複数のインスタンスをプロキシ・リクエストでルックアップしてインスタンス全体に負荷を分散できるようになります。

PrintServerは、Webアプリケーションに登録されるスタンドアロンのRMIサーバー(デフォルト・ポートは8297)であるため、PDFについてのWebリクエストでプリント・サーバーの検出と、結果としてのPDFの生成が可能になります。

15.1.10.1.1 状態情報

EPM Workspaceブラウザは、ステートレスまたはセッション単位のどちらかになります。Oracle BIプレゼンテーション・サービスへの接続はキャッシュされ、タイムアウトが発生した場合にはリストアされます。WebLogicのポーリングはRDBMSを処理して、SQLコールが行われたときに障害が発生した場合には再接続を試行します。デフォルトでは、Essbaseの接続は5分間キャッシュされます(構成可能)。

プロトコル:

- RDBMS – WebLogicで構成されたJNDI接続によって管理されます。

- Oracle BIプレゼンテーション・サービスのWebサービスURL – Hyperion Registry内で構成されます。

- EPM Workspace – Financial Reporting用のWebユーザー・インタフェース・コンテナです(Financial Reportingとのすべての相互作用は、JavaScriptを使用したブラウザ内で行われます)。

- Essbase/Provider Services – Financial Reportingは、ソケットによってEssbaseに直接接続します。ルックアップは、直接またはProvider ServicesのHTTPコールによって実行します。

15.1.10.1.2 ランタイム・プロセス

- この項では、実行時のFinancial Reportingプロセスについて説明します。

- ユーザーは、利用可能なレポートのリストからレポートまたはブックを起動します。ユーザーは、HTMLやPDF、Microsoft Officeドキュメントなどの形式を選択できます。

- Financial Reportingは、使用されるレポート・インスタンスを識別するトラッキング・フレームをロードし、サーバー・インスタンスをクリーンアップするためにIFrameのアンロード・イベントを捕捉します。このフレームは、レポートまたはブックを実行および表示するための別のフレームがロードします。

- Financial Reporting Webアプリケーションは、レポートまたはブックのデザインをロードし、それをEssbaseに向けて実行して必要な形式での出力を生成します。

- Financial Reportingは、Oracle BIプレゼンテーション・サービスコールを通じてカタログからデザインをロードします。

- Financial Reportingは、Essbaseに直接またはProvider ServicesのURLを通じて接続します。

- Financial Reportingは、レポートまたはブックのデザインに基づいてEssbaseに問合せを行い、必要な形式での出力を生成します。
HTMLおよびMicrosoft Office形式の場合、Financial ReportingはHTMLを生成してから関連付けられたMIMEタイプをクライアントに配信し、必要に応じてMicrosoft Officeを起動できるようにします。

PDF形式の場合、Financial Reportingアプリケーション・サーバーは利用可能なプリント・サーバーに向けたRMIコールを実行し、PDFコンテンツを生成してからブラウザ・クライアントにPDFファイルを戻します。

注意:

複数のプリント・サーバーを構成して登録してください。プリント・サーバーに障害が発生した場合やオフラインになった場合、Financial Reportingは別のプリント・サーバーに移ります。

- EPM Workspaceで起動されるレポートまたはブックの実行および表示(HTML、PDF、Microsoft Office)

- ブラウザから開始します。

- XML、HTML、JavaScriptおよびBindows – EPM Workspace、Financial ReportingおよびOracle BI EEによって表示されるユーザー・インタフェース・コンポーネントです。

- フェイルオーバーはサポートされません。ユーザーはブラウザを再起動する必要があります。

- Smart Viewによるレポートのインポート

- Microsoft Officeから起動します。

- XML、HTML、JavaScript。

- フェイルオーバーがサポートされています。

レポートのプレビューがInternet Explorerベースのコントロールに表示されます。このコントロールには、Microsoft Office形式のHTMLによる結果が返される前に、HTML形式でレポートが表示されます。

- ブックおよびバッチのデザインと変更(EPM Workspaceからのみ利用可能)

- ブラウザから開始します。

- XML、HTML、JavaScriptおよびBindows。

- フェイルオーバーはサポートされません。ユーザーはブラウザを再起動する必要があります。

ブックおよびバッチのデザインの編集にはBindowsコンポーネントの複合ユーザー・インタフェースを使用します。これは、ブックおよびバッチのコンテンツを表示および操作するためのものです。

- Financial Reportingは、WebサービスAPIを通じてOracle BIプレゼンテーション・サービスリポジトリからデザイン・オブジェクトを開き、このリポジトリにデザイン・オブジェクトを保存します。

- Financial Reportingは、Essbaseへの直接接続またはProvider ServicesのURL(フェイルオーバー可能)を通じてデザイン固有のEssbaseキューブに接続します。

- Financial Reportingは、Bindowsユーザー・インタフェース・コンポーネントとJavaScriptを使用して、Reports Designerにデザインを提出し、これによって、ブックまたはバッチのデザインを変更できます。

- レポートのデザインと変更(Financial Reporting Studioから実行可能)

- Financial Reporting Studio(Windows 32ビット実行可能ファイル)から開始します。

- Visual Basic/Visual C++/Javaアプリケーション。

- フェイルオーバーはサポートされていません。ユーザーはFinancial Reporting Studioを再起動する必要があります。

- 接続およびユーザー認証: Report DesignerによってFinancial Reportingサーバーの資格証明とURL(通常は、Oracle HTTP Serverプロキシのアドレス)が入力されます。Financial Reporting Studioは、Webアプリケーションに向けたHTTPコールを実行して、RMIスタブ・オブジェクトを取得します。その後の通信はすべてRMIを通じて行われます。

- リポジトリおよびデータ・ソースに対するすべてのアクセスは、Financial Reporting WebアプリケーションRMIオブジェクトに向けたリモートRMIコールを通じて行われます。このオブジェクトは、リポジトリとデータ・ソースに向けたコールを実行します。Financial Reporting Studioから、リポジトリまたはEssbaseへの直接接続が確立されることはありません。

- RDBMSに対するすべてのアクセスは、Financial Reporting WebアプリケーションRMIオブジェクトに向けたリモート・コールを通じて行われます。このオブジェクトは、JDBCコールを実行します。FRStudioからJDBCデータ・ソースへの直接接続が確立されることはありません。

- バッチ・スケジュール(EPM Workspaceから使用可能。スケジュールは、ESS EMからアクセスおよび変更可能)

- ブラウザから開始します。

- HTML、JavaScriptおよびBindows。

- フェイルオーバーはサポートされません。ユーザーはブラウザを再起動する必要があります。

ユーザーはウィザードを起動して、スケジュールするバッチを選択します。また、観点や実行時間/実行頻度、出力形式などのジョブ属性も選択します。

Financial Reporting Webアプリケーションは、ESS EJB APIを使用して、ユーザーの指示に応じたジョブの作成とスケジュールを実行します。ESS RDBMSの表には、ジョブとリクエストが格納されます。

- バッチ実行(ESSおよびFinancial Reportingバックエンド・コード)

- ESSによって開始されます。

- Financial Reportingに向けたWebserviceコールを呼び出します。

- フェイルオーバーがサポートされています(コール時にWebserviceに障害が発生するとバッチ結果の状態はエラーになります)。

- ESSはFinancial Reportingのスケジュール済ジョブを取得して、Financial Reporting EssClientをコールします。このEssClientは、FSCMドメインにESS専用サーバーとともにデプロイされます。

- FREssClientは、ターゲットのFinancial Reportingアプリケーション・サーバーのURLを抽出し、Financial Reportingアプリケーション・サーバーに向けたWebserviceコールを実行して、ジョブ定義として定義されたXMLを渡すことでジョブを実行します。

- Financial Reporting Webアプリケーションは、ユーザーがジョブをスケジュールしたときに定義したパラメータに応じてジョブを実行し、FREssClientにステータス・コードを返します。

- FREssClientは、成功または失敗のステータスをESSのコール元に返します。

注意:

Financial Reportingは、ジョブの結果をRDBMSの表に保持します。ただし、ジョブの実行時期はESSが決定し、FREssClientが接続するFinancial Reporting Webアプリケーションは1つに限定されています。これにより、複数のFinancial Reportingサーバーが同一のジョブを処理するという問題を防止します。ESSは、複数のESSサーバーによる同一ジョブの処理を防止する方法を管理します。

- バッチ結果のビューア(EPM Workspaceから使用可能)

- ブラウザから開始します。

- HTML、JavaScriptおよびBindows。

- フェイルオーバーはサポートされません。ユーザーはブラウザを再起動する必要があります。

- ユーザーは実行済のジョブと保留中のジョブのリストを取得します。Financial Reporting Webアプリケーションは、このリストをESSのインプロセスEJBから取得します。

- ユーザーは、ジョブのリストから結果コンテンツを取得できます。Financial Reporting Webアプリケーションは、Financial Reporting Scheduler RDBMSの表から結果を取得します。

- ユーザーは、ジョブの作成やスケジュールのプロセスと同じ手順を実行することで、ジョブを削除またはレプリケートできます。

15.1.10.1.3 外部依存性

- RDBMS: Hyperion Registry、注釈の表(Financial Reporting)、Financial Reportingスケジューラの表(Financial Reporting)、ESSジョブの表(ESS)。

- Oracle BIプレゼンテーション・サービスリポジトリ(Web ServicesおよびEPM Workspaceからアクセスされます)

- EPM Workspace (Reporting管理者用)

- Essbase/Provider Services

- Essbaseによって生成されたキューブ

- インストールと構成が完了しているESS

15.1.10.1.4 構成アーティファクト

Hyperion Registryには、システム全体の構成に含まれない部分の構成情報を格納します。Webアプリケーションのすべてのインスタンスは、Hyperion Registryを共有します。MBean(Fusion Middleware Controlで表示や変更が可能)は、構成情報を公開します。Fusion Middleware Controlで、com.hyperion.FinancialReportingと、com.hyperion.Annotationsを参照してください。

15.1.10.1.5 デプロイメント・アーティファクト

Financial Reportingのデプロイメント・アーティファクトは、次のとおりです。

- FREssClient.ear – Financial Reportingのジョブ用のEnterprise Scheduler Serviceサーバーの実装が含まれています。これは、FinDomain Enterprise Scheduler Serviceにデプロイされます。

- HReports.ear – BIDomainにデプロイされるプライマリFinancial Reporting Webアプリケーションです。

Financial Reporting Webアプリケーションに必要なBIDomainにデプロイされる共有ライブラリには、epm-shared-libraries、epm-fr-libraries、epm-annotation-libraries、epm-frweb-libraries、epm-misc-librariesがあります。

15.1.10.1.6 ログ・ファイル

Financial Reportingログは、$domain home/servers/${weblogic.Name}/logs/financialreportingにあります。${weblogic.Name}は、管理対象サーバーの名前になります。たとえば、bi_server1やbi_server2になります。

15.1.11 Oracle Hyperion Financial Reportingの高可用性の概要

Oracle Hyperion Financial Reportingは、次の機能についての高可用性をサポートしています。

- レポートの実行と、HTMLまたはPDF形式での表示:

- プロンプト

- POVの変更

- ページ・ディメンションのドロップダウン(HTMLのみ)

- 注釈の作成と表示

- 拡張

- ドリルスルー(PDFでは使用不可)

- ブックの実行と、HTMLまたはPDF形式での表示

- Microsoft Office形式へのエクスポート

15.1.11.1 Oracle Hyperion Financial Reportingの高可用性アーキテクチャ

図15-2は、Oracle BI EEの高可用性デプロイメントにおけるEssbaseを示しています。

15.1.11.1.1 共有ファイルと共有ディレクトリ

共有されるファイルまたはディレクトリはありません。共通のすべてのプロパティとドキュメントは、リレーショナル・データベースまたはOracle BIプレゼンテーション・サービスリポジトリのどちらかに格納されます。

15.1.11.1.2 クラスタワイドの構成変更

PrintServer以外の構成は、キャッシュされます。変更は、その変更を行ったサーバーでのみ、他のサーバーが次回再起動するまで有効です。プリント・サーバーはキャッシュされないため、いつでも追加または削除が可能です。

15.1.11.2 障害からの保護および予想される動作

Financial Reportingは、次のコンポーネントも併せてデプロイされている場合に、フェイルオーバーとセッションのシリアライズをサポートします。

- Oracle Business Intelligence Enterprise Edition/Oracle BIプレゼンテーション・サービス: Financial Reportingは、Oracle BIプレゼンテーション・サービスへのWebサービス接続を使用します。この接続は、現在のOracle BIプレゼンテーション・サービス接続に障害が発生すると他のカタログ・ノードに移行するフェイルオーバーを備えています。このフェイルオーバーは、次の条件を想定しています:

- カタログ・アプリケーション・サーバー、Presentation Servicesおよびファイル記憶域が、クラスタ化またはレプリケートされている。

- アプリケーションのプロビジョニング時に構成されたカタログの場所は、カタログWebアプリケーション・サーバーを直接参照するのではなく、プロキシ・サーバーを参照する。

- Essbase: Financial Reportingのレポートは、Provider ServicesのURLを使用してEssbaseをターゲットにする必要があります。また、Provider Servicesは、アクティブおよびパッシブのEssbaseサーバーで構成されている必要があります。Essbaseに障害が発生すると、Financial ReportingはOracle Hyperion Provider ServicesのURLを通じてバックアップ・サーバーに接続します。Essbaseの問合せは再発行されますが、このときユーザーのリクエストが中断されることはありません。

- RDBMS: このデータベースはフェイルオーバーをサポートしている必要があります。接続は、WebLogic JDBC構成と接続プールによって処理されます。

- Oracle Internet Directory/OAM。

- Oracle HTTP Serverは、フェイルオーバーを提供することに加え、すべてのコンポーネントの統合ポイントを提供することが期待されます。Financial Reporting構成は、Oracle HTTP Serverまたはロード・バランシングされたURLを通じてOracle BIプレゼンテーション・サービスをターゲットにする必要があります。カタログ・サーバーを直接ターゲットにはしません。

- Oracle Hyperion Financial Reporting、Fusion Edition PrintServer – 少なくとも2つのPrintServerホストをWindowsマシン上にデプロイして、そのシステムによって構成する必要があります。

15.1.12 Allocation Managerのコンポーネント・アーキテクチャと特性

Allocation Managerを使用すると、Oracle Hyperion Financial Management、Fusion Edition、Oracle Hyperion Planning、Fusion EditionおよびOracle Essbaseのビジネス問題を解決する洗練された計算を作成、検証、デプロイおよび管理できます。Oracle Enterprise Performance Management Workspace, Fusion Edition内のAllocation Managerにアクセスします。

Allocation Managerは、アクティブ/アクティブ・モードで実行する複数のインスタンスとともにWebLogicにデプロイされるJava Webアプリケーションです。Allocation Managerのインスタンスは、すべて同等であり、あらゆるリクエストを処理できます。Allocation Managerはステートフルなアプリケーションであり、スティッキーなルーティングが必要です。セッションのフェイルオーバーはサポートされません。編集は単一インスタンス内でのみ行われ、そのインスタンスに障害が発生すると保存されません。

Allocation Managerによる外部コンポーネントの管理と検出は、Hyperion Registryを通じて行われます。

15.1.13 Oracle BI EEの高可用性の構成手順

この項では、Oracle BI EEおよびBI Publisherにおいて2ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図15-2に示しています。

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

15.1.13.1 Oracle BI Enterprise EditionおよびBI Publisherの高可用性構成の設定前に必要な手順

次の項では、Oracle BI EEおよびOracle BI Publisherの高可用性構成を設定する前に必要となる手順を説明します。

15.1.13.1.1 データベースに関する前提条件

Oracle BI EEでサポートしているデータベースのバージョンは次のとおりです。

- Oracle Database 10g(非XEデータベースについては10.2.0.4以上)

- Oracle Database 11g(非XEデータベースについて11.1.0.7以上)

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.1.13.1.2 VIPとIPの前提条件

図15-7で示すように、異なる仮想IPをリスニングするようにBI管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。インストールを実行する前に、各VIPが使用可能であり、アクセスできることを確認します。

表15-3 BI EEの仮想ホスト

仮想IP

仮想IPのマップ先

説明

VIP1

APPHOST1VHN1

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

VIP2

APPHOST2VHN1

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

15.1.13.1.3 共有記憶域に関する前提条件

障害発生時に適切にリカバリできるようにするには、すべてのノードからアクセスできる場所にJMSとトランザクションの両方のログを格納して、管理対象サーバーで障害が発生した後にすべてのノードが操作を再開できるようにします。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表15-4は、共有記憶域の内容を示しています。

表15-4 BI EEの共有記憶域の内容

サーバー

データの型

共有記憶域のボリューム

ディレクトリ

ファイル

BI_SERVER1とBI_SERVER2

トランザクション・ログ

VOL2

ORACLE_BASE/admin/domain_name/cluster_name/tlogs

共通の場所(WebLogicサーバーにより決められたストア)

BI_SERVER1とBI_SERVER2

JMSストア

VOL2

ORACLE_BASE/admin/domain_name/cluster_name/jms

共通場所ですが、サーバーごとに個別のストアになります。例: BI_SERVER1にはBipJmsStore、BI_SERVER2にはBipJmsStore2。

BI_SERVER1とBI_SERVER2

BI Serverリポジトリ

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/ClusterRPD

共通の場所

BI_SERVER1とBI_SERVER2

BIグローバル・キャッシュ

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/GlobalCache

共通の場所

BI_SERVER1とBI_SERVER2

BIプレゼンテーション・サービス・リポジトリ

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/catalog

共通の場所

BI_SERVER1とBI_SERVER2

BI Publisher構成フォルダ

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/config

共通の場所

BI_SERVER1とBI_SERVER2

BI Publisherカタログ・リポジトリ

VOL1

ORACLE_BASE/domain_name/config/bipublisher/catalog

これが必要なのは、「BI Publisherカタログ」タイプで「Oracle BI Publisher - ファイル・システム」が選択されている場合のみです。

共通の場所

BI_SERVER1とBI_SERVER2

BI Publisher Scheduler一時ディレクトリ

VOL1

ORACLE_BASE/admin/domain_name/cluster_name/bipublisher/temp

共通の場所

共有記憶域にはNASやSANなどのデバイスを使用できます。NAS over NFSデバイスに基づいたコマンド例を次に示します。この項で指定しているオプションは、実際のオプションと異なる場合があります。

APPHOST1> mount nasfiler:/vol/volX/FMWshared MW_HOME-t nfs -o
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

15.1.13.1.4 クロックの同期

クラスタに参加しているすべてのサーバーのクロックを、1秒以内の差異に収まるように同期する必要があります。クロックを同期するには、単一のネットワーク・タイム・サーバーを使用して各サーバーがそのネットワーク・タイム・サーバーを指すようにします。ネットワーク・タイム・サーバーを指すように設定する手順は、WindowsとLinuxでは異なります。使用するオペレーティング・システムのドキュメントを参照してください。

15.1.13.1.5 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

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

自動ストレージ管理

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをOracle Real Application Clusters(Oracle RAC)データベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g (11.1.1.)Oracle Fusion Middleware RepositoryをOracle RACデータベースにインストールしてください。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

15.1.13.1.6 RCUを使用したデータベースへのBusiness Intelligenceスキーマのロード

Oracle Business Intelligenceをインストールする前に、11g (11.1.1) Oracle Fusion Middlewareのメタデータ・ストアおよびOracle BIスキーマをOracle RACデータベースにインストールします。次の手順を実行します。

1. リポジトリ作成ユーティリティ(RCU)のDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。

prompt> cd RCU_HOME/bin
prompt> ./rcu

2. 「ようこそ」画面で「次へ」をクリックします。

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

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

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

- ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを次のように指定します:
BIDBHOST1-VIP

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

- サービス名: データベースのサービス名を指定します。
biha.mycompany.com

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

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

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

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

5. 「コンポーネントの選択」画面で、次を行います。

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

ヒント:

このスキーマの名前をメモに記録してください。後述する手順でこの情報が必要になります。

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

o  AS Common Schemas: Metadata Services (automatically selected)
o  Oracle Business Intelligence: Business Intelligence Platform

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

6. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択します。

「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。

ヒント:

スキーマ・パスワードの名前をメモに記録してください。後述する手順でこの情報が必要になります。

7. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

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

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

15.1.13.1.7 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle BI EEの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

Oracle BI EEは、2つのOracle HTTP ServerがWeb層コンポーネントとして使用された高可用性構成でデプロイされた場合は、ハードウェア・ロード・バランサを使用します。

仮想サーバー名

bi.mycompany.comは、Oracle BI PublisherなどのランタイムBIコンポーネント宛てのすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、bi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

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

この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。

1. サーバーが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。

- ポート7777がWEBHOST1上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに対して次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep "7777"

Windowsの場合:

netstat -an | findstr :7777

ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。

UNIXの場合:

ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

- staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

- 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle HTTP Serverのポート番号を指定する行は非コメント化)を割り当てます。

# The port for Oracle HTTP server
Oracle HTTP Server port = 7777

2. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXの場合:

./runinstallerコマンドを発行します。

Windowsの場合:

setup.exeをダブルクリックします。

「インベントリ・ディレクトリの指定」画面が表示されます。

3. 「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /u01/app/oraInventory

オペレーティング・システムのグループ名: oinstall

次のメッセージのダイアログ・ボックスが表示されます。

「インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください」

rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。

これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。

注意:

すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールで「Oracleインベントリ」画面が表示されない場合は、次の内容を確認してください。

- /etc/oraInst.locファイルが存在しているか。

- このファイルが存在する場合は、一覧表示されているインベントリ・ディレクトリが有効か。

- インストールを実行するユーザーに、インベントリ・ディレクトリへの書込み権限が付与されているか。

4. 「ようこそ」画面で「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

6. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。

7. 「インストール場所の指定」画面で、次を指定します。

- Oracle Middlewareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)

- Oracleホーム・ディレクトリ: Oracle_WT1

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

8. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

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

9. 「コンポーネントの詳細の指定」画面で、WEBHOST1用に次の値を入力します。

- インスタンス・ホームの場所: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1

- インスタンス名: web1

- OHSコンポーネント名: ohs1

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

10. 「ポートの構成」画面で、次の操作を行います。

- カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

- Oracle HTTP Serverポートを入力します(例: 7777)。

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

11. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。

12. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「インストール」をクリックします。

13. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

14. 「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。「次へ」をクリックします。

15. 「インストール完了」画面で「終了」をクリックして終了します。

WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランサを構成します。

15.1.13.1.9 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、ブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

http://WEBHOST1:7777/
http://WEBHOST2:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザにOracle FMWの「ようこそ」画面が表示されます。

15.1.13.2 高可用性のためのOracle Business Intelligence Enterprise Editionのインストール

この項では、Oracle WebLogic ServerとOracle BI EEを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする方法について説明します。WebLogic ServerとOracle BI EEをAPPHOST2にインストールするために、これと同じ手順を繰り返します(次ではAPPHOST1を対象にして説明しています)。新しいノードをインストールするときにバイナリ・ファイルとドメインに使用するディレクトリ・パスは、最初のノードに使用したものと同一にする必要があります。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

- Oracle WebLogic Server

- Oracle Business Intelligence

この項では、ソフトウェアのみのインストールを実行してから、config.sh構成スクリプトを使用してOracle BIシステムを作成およびスケール・アウトします。

15.1.13.2.1 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールする手順は次のとおりです。

1. Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します。

注意:

ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracleの値をお薦めします。

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

4. 「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。

6. 「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.6ディレクトリを受け入れます。そして「次へ」をクリックします。

7. 「インストールの概要」画面で「次へ」をクリックします。
Oracle WebLogic Serverソフトウェアがインストールされます。

8. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

15.1.13.2.2 Business Intelligence Enterprise EditionおよびOracle BI Publisher用のOracle Fusion Middlewareのインストール

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

1. Oracle Fusion Middleware Business Intelligence 11gのインストーラを次のインストール・メディアから起動します。
UNIXの場合:

APPHOST1>./runInstaller

Windowsの場合:

APPHOST1> setup.exe

2. 「インベントリ・ディレクトリの指定」画面で、次の操作を行います。

- HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

- インストールを実行するユーザーのOSグループを入力します。
「次へ」をクリックします。

- 画面の手順に従って、/createCentralnventory.shをrootとして実行します。
「OK」をクリックします。

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「インストール・タイプの選択」画面で、「ソフトウェアのみインストール」を選択して「次へ」をクリックします。

5. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

6. 「インストール場所の指定」画面で、前にインストールしたMiddlewareホームをドロップダウン・リストで選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(Oracle_BI1)を入力します。
「次へ」をクリックします。

7. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。

8. 「サマリー」画面で「インストール」をクリックします。
Oracle Fusion Middleware Business Intelligence 11gソフトウェアがインストールされます。

9. 「インストールの進行状況」画面で「次へ」をクリックします。

10. 完了画面で「終了」をクリックします。

15.1.13.3 APPHOST1のVIP1およびAPPHOST2のVIP2の有効化

BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してマッピングされているVIPを有効にして(APPHOST1ではVIP1、APPHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。

15.1.13.4 管理サーバーと1つ目のBI_SERVER1管理対象サーバーが含まれたドメインの作成

この項では、Oracle Business Intelligence構成アシスタント、管理コンソールおよびOracle Enterprise Managerを使用して、ドメインと最初のWebLogic Server BI管理対象サーバーを作成する方法について説明します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

Oracleホーム・ディレクトリから構成アシスタントを実行して、BI Publisherが配置された管理対象サーバーおよび管理サーバーが含まれたドメインを作成します。

1. 構成アシスタントの場所にディレクトリを移動します。

APPHOST1> cd ORACLE_HOME/bin

2. 構成アシスタントを起動します。
UNIXの場合:

APPHOST1> ./config.sh

Windowsの場合:

APPHOST1> config.cmd

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

5. BIシステムの作成またはスケールアウト画面で、「新規BIシステムの作成」を選択し、次を指定します。

- ユーザー名: weblogic

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

- ドメイン名: bifoundation_domain

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

6. 「インストール場所の指定」画面で、次を入力します。

- MiddleWareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)

- Oracleホーム: ORACLE_BASE/product/fmw/Oracle_BI1(グレーアウトされています)

- WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3(グレーアウトされています)

- ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain

注意:

「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

- インスタンス・ホーム: ORACLE_BASE/product/fmw/instance1

- インスタンス名: instance1

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

7. 「コンポーネントの構成」画面で、次を選択します。

- Oracle Business Intelligence
- Business Intelligence Enterprise Edition
- Business Intelligence Publisher

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

8. BIPLATFORMスキーマ画面で、次のように入力します。

- データベース・タイプ: Oracle Database

- 接続文字列: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM

- BIPLATFORMスキーマ・ユーザー名: BIHA_BIPLATFORM

- BIPLATFORMスキーマ・パスワード: BIPLATFORMスキーマ・ユーザーのパスワードを入力します。

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

9. MDSスキーマ画面で情報を確認し、「次へ」をクリックします。

10. 「ポートの構成」画面で、次のいずれかを選択します。

- 自動でポートを構成

- 構成ファイルを使用してポートを指定

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

11. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

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

13. 「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。

14. 完了画面で「終了」をクリックします。

15.1.13.5 APPHOST1での管理サーバーのboot.propertiesの作成

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。

APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成する手順は、次のとおりです。

1. 次のディレクトリに移動します。

ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/
AdminServer/security

2. 次の行をファイルに入力し、ファイルを保存してからエディタを閉じます。

username=Admin_username
password=Admin_password

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

15.1.13.6 APPHOST1での管理サーバーの起動と検証

この項では、APPHOST1で管理サーバーを起動および検証する手順について説明します。

15.1.13.6.1 APPHOST1での管理サーバーの起動

APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin
APPHOST1> ./startWebLogic.sh

15.1.13.6.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. ブラウザで、http://APPHOST1:7001/consoleにアクセスして、管理者としてログインします。

2. BI_SERVER1管理対象サーバーが表示されていることを確認します。

3. bi_clusterクラスタが表示されていることを確認します。

4. Enterprise Manager(http://APPHOST1:7001/em)にアクセスできることを確認します。

15.1.13.7 BI_SERVER1管理対象サーバーのリスニング・アドレスの設定

管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で「bi_server1」を選択します。

6. リスニング・アドレスをAPPHOST1VHN1に設定します。「保存」をクリックします。

7. 「変更のアクティブ化」をクリックします。

8. BI_SERVER1管理対象サーバーを再起動して変更を有効にします。

1. 「サーバーのサマリー」画面で、「制御」タブを選択します。

2. 表で「bi_server1」を選択してから、「停止」をクリックします。

9. BIシステムのコンポーネントを再起動します。例:

cd ORACLE_BASE/admin/instance1/bin
./opmnctl restartproc

15.1.13.7.1 Oracle BI Publisher Schedulerの構成の更新

この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLを更新します。

注意:

Oracle BI Publisher Schedulerのクロックの同期を維持する方法については、「Oracle BI Publisherの「スケジューラ診断」ページでJMSインスタンスが欠落している」を参照してください。

Oracle BI Publisher Schedulerの構成を更新する手順は次のとおりです。

1. 次のURLにアクセスしてOracle BI Publisherにログインします。

http://APPHOST1VHN1:9704/xmlpserver

2. 「管理」リンクをクリックします。

3. 「スケジューラ構成」を「システム・メンテナンス」で選択します。

4. 次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。

t3://APPHOST1VHN1:9704

5. 「適用」をクリックします。

6. スケジューラのステータスを「スケジューラ診断」タブでチェックします。

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

管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合、ホスト名の検証を無効化する必要があります。サーバー証明書を構成しないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。

ホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。「サーバー」をクリックします。

4. 表の「名前」列で「bi_server1」を選択します。

5. 「SSL」タブを開きます。ページの「詳細」セクションを開きます。

6. 「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。

7. 「変更のアクティブ化」をクリックします。

8. この変更は、BI_SERVER1管理対象サーバーを再起動するまで有効になりません。

1. 「サーバーのサマリー」画面で、「制御」タブを選択します。

2. 表で「bi_server1」を選択してから、「停止」をクリックします。

9. BIシステムのコンポーネントを再起動します。例:

cd ORACLE_BASE/admin/instance1/bin
./opmnctl restartproc

15.1.13.9 APPHOST1でのシステムの起動

この項では、APPHOST1でノード・マネージャを起動する方法、およびAPPHOST1でBI_SERVER1管理対象サーバーを起動して検証する方法について説明します。

15.1.13.9.1 APPHOST1でのノード・マネージャの起動

通常、ノード・マネージャはconfig.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合、次のコマンドを使用してAPPHOST1で起動します。

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

15.1.13.9.2 BI_SERVER1管理対象サーバーの起動と検証

BI_SERVER1管理対象サーバーを起動して、このサーバーが適切に構成されていることを確認する手順は次のとおりです。

1. 管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「制御」タブをクリックします。

4. 「bi_server1」を選択してから、「起動」をクリックします。

2. 管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。

3. BI_SERVER1が起動すると、次のURLが使用できるようになります。

- http://APPHOST1VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。

注意:

ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

- http://APPHOST1VHN1:9704/xmlpserverにアクセスして、BI Publisherアプリケーションのステータスを確認します。

15.1.13.9.3 APPHOST1でのBI EEシステム・コンポーネントの起動と検証

opmnctlコマンドを使用して、Oracle Business Intelligenceのシステム・コンポーネントを制御できます。

OPMNCTLコマンドラインを使用してBI EEシステム・コンポーネントを起動する手順は次のとおりです。

1. OPMNコマンドライン・ツールが格納されたディレクトリに移動します。

注意:

OPMNコマンドライン・ツールは、ORACLE_INSTANCE/binディレクトリにあります。

2. opmnctlコマンドを実行して、BI EEシステム・コンポーネントを起動します。

- opmnctl startall
このコマンドは、OPMNとすべてのBI EEシステム・コンポーネントを起動します。

- opmnctl start
このコマンドはOPMNのみを起動します。

- opmnctl startproc ias-component=componentName
このコマンドは、指定されたシステム・コンポーネントを起動します。たとえば、coreapplication_obips1がBIプレゼンテーション・サービスである場合、コマンドは次のようになります。

opmnctl startproc ias-component=coreapplication_obips1

3. BI EEシステム・コンポーネントのステータスをチェックします。

opmnctl status

15.1.13.10 Oracle BI EEの構成

この項では、Oracle BI EEを構成する方法を説明します。

15.1.13.10.1 共有Oracle BIリポジトリの場所の設定

Fusion Middleware Controlで次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

3. 「coreapplication」をクリックします。

4. 「デプロイメント」をクリックしてから、「リポジトリ」をクリックします。

5. 「構成をロックして編集」をクリックします。

6. 「リポジトリの共有」を選択して、Oracle BIリポジトリの「共有場所」を指定します。Windows環境では、Enterprise Manager Fusion Middleware Controlの要件として、UNCパスを使用してリポジトリの共有場所を定義する必要があります。

7. 「適用」をクリックします。

8. 「変更のアクティブ化」をクリックします。

15.1.13.10.2 BI Serverの共有グローバル・キャッシュの設定

Fusion Middleware Controlで次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

3. 「coreapplication」をクリックします。

4. 「容量管理」をクリックしてから、「パフォーマンス」をクリックします。

5. 「構成をロックして編集」をクリックします。

6. 「グローバル・キャッシュ」セクションで、Oracle BI Serverグローバル・キャッシュの共有場所を指定して、グローバル・キャッシュ・サイズとして250MBを指定します。Windows環境では、Enterprise Manager Fusion Middleware Controlの要件として、UNCパスを使用してOracle BI Serverグローバル・キャッシュの共有場所を定義する必要があります。

7. 「適用」をクリックします。

8. 「変更のアクティブ化」をクリックします。

15.1.13.10.3 Schedulerスクリプト・パスとデフォルト・スクリプト・パスの設定

Oracle BIスケジューラでサーバー側スクリプトを使用する場合は、クラスタ内のすべてのOracle BIスケジューラ・コンポーネントで共有できるように、これらのスクリプトの共有ディレクトリを構成することをお薦めします。

次の手順は、サーバー側スクリプトを使用している場合にのみ実行してください。

Oracle BIスケジューラのスクリプトを共有する手順は次のとおりです。

1. デフォルトのOracle BIスケジューラ・スクリプト(例: ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/common)とカスタムのOracle BIスケジューラ・スクリプト(例: ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/scheduler)をBIスケジューラ・スクリプトの共有場所にコピーします。

2. Oracle BIスケジューラのinstanceconfig.xmlファイルのSchedulerScriptPath要素とDefaultScriptPath要素を更新します。

- SchedulerScriptPath: Oracle BIスケジューラによって作成されたジョブ・スクリプトが格納されているパスを指します。共有BIスケジューラ・スクリプトの場所を指すパスにこれを変更します。

- DefaultScriptPath: ユーザーによって作成されたジョブ・スクリプト(エージェントではなく)が格納されているパスを指定します。共有BIスケジューラ・スクリプトの場所を指すパスにこれを変更します。

デプロイメント環境内の各Oracle BIスケジューラ・コンポーネントについて、このファイルを更新する必要があります。

15.1.13.10.4 共有Oracle BIプレゼンテーション・カタログの場所の設定

各プレゼンテーション・サービス・インスタンスは、Fusion Middleware Controlで指定されたカタログの場所からOracle BIプレゼンテーション・カタログをロードします。

次の手順を実行します。

1. 既存の(ローカルに公開された)Oracle BIプレゼンテーション・カタログを共有場所にコピーします。次にローカルに公開されたカタログの例を示します。

ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/
coreapplication_obipsn/catalog/SampleAppLite

この手順は、Fusion Middleware Controlで「カタログの場所」を指定する前に実行する必要があります。

この項の例で述べたSampleAppLiteカタログを共有カタログとして使用する予定である場合は、それをAPPHOST1からコピーしてください。

2. Fusion Middleware Controlにログインします。

3. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

4. 「coreapplication」をクリックします。

5. 「デプロイメント」をクリックしてから、「リポジトリ」をクリックします。

6. 「構成をロックして編集」をクリックします。

7. 共有Oracle BIプレゼンテーション・カタログの「カタログの場所」を指定します。
Windows環境では、UNCパス名を指定します。

注意:

Windows環境では、共有記憶域の指定に汎用命名規則(UNC)を使用する必要があります。UNCは、ローカル・エリア・ネットワーク上のリソースの場所を指定するためのPCの書式です。UNCでは、\\server-name\shared-resource-path-nameという書式を使用します。

8. 「適用」をクリックします。

9. 「変更のアクティブ化」をクリックします。

15.1.13.11 サーバー構成オプションの設定

Oracle BI Publisherのサーバー構成オプションを設定するには、次の手順を実行します。

1. DOMAIN_HOME/config/bipublisher/repositoryの内容を構成フォルダの共有場所にコピーします。

2. 管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。

3. 「システム・メンテナンス」で「サーバー構成」を選択します。

4. 「パス」で、構成フォルダの共有場所のパスを入力します。

5. 変更を適用してから、BI Publisherアプリケーションを再起動します。

15.1.13.12 APPHOST2でのBIシステムのスケール・アウト

第15.1.13.2項「高可用性のためのOracle Business Intelligence Enterprise Editionのインストール」の手順に従って、APPHOST2でOracle WebLogic ServerとOracle Business Intelligenceのソフトウェアのみをインストールします。

次に、ORACLE_HOMEディレクトリから構成アシスタントを実行して、BIシステムをスケール・アウトします。

1. 構成アシスタントの場所にディレクトリを移動します。

APPHOST2> cd ORACLE_HOME/bin

2. 構成アシスタントを起動します。

APPHOST2> ./config.sh

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。

5. BIシステムの作成またはスケールアウト画面が表示されます。BIシステムのスケールアウトを選択して、次の値を入力します。

- ホスト名: ADMINHOST

- ポート: 7001

- ユーザー名: weblogic

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

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

6. BIシステム詳細のスケールアウト画面で、次の値を入力します。

- MiddleWareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)

- Oracleホーム: Oracle_BI1(グレーアウトされています)

- WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3(グレーアウトされています)

- ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain

- アプリケーション・ホーム: ORACLE_BASE/admin/domain_name/mserver/applications

- インスタンス・ホーム: ORACLE_BASE/product/fmw/instance2

- インスタンス名: instance2(グレーアウトされています)

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

7. 「ポートの構成」画面で、次のいずれかを選択します。

- 自動でポートを構成

- 構成ファイルを使用してポートを指定

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

8. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

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

10. 「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。

11. 完了画面で「終了」をクリックします。

通常、ノード・マネージャはconfig.shの完了時に自動的に起動されます。ノード・マネージャが実行されていない場合は、APPHOST2で次のコマンドを実行してノード・マネージャを起動します。

APPHOST2> cd WL_HOME/server/bin
APPHOST2> ./startNodeManager.sh

15.1.13.13 BIシステム・コンポーネントのスケール・アウト

BIシステム・コンポーネントをスケール・アウトする手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

3. 「coreapplication」をクリックします。

4. 「容量管理」をクリックしてから、「スケーラビリティ」をクリックします。

5. 「構成をロックして編集」をクリックします。

6. APPHOST2の「instance2」Oracleインスタンスについて、次のOracle Business Intelligenceコンポーネントを1だけ増分します。

- BI Server

- プレゼンテーション・サービス

- JavaHost

7. 「ポート範囲(開始)」と「ポート範囲(終了)」を、APPHOST1の「instance1」Oracleインスタンスと同じになるように変更します。

8. 「適用」をクリックします。次のメッセージが表示されます。
警告: 複数のプレゼンテーション・サービスが構成されています。共有の場所が指し示されるようにカタログの場所を調整してください。

9. 「OK」をクリックします。共有場所は後で構成します。

10. 「変更のアクティブ化」をクリックします。「再起動」をクリックして最近の変更を適用します。

15.1.13.14 シングルトン・コンポーネントのアクティブ/パッシブ化

Fusion Middleware Controlで次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

3. 「coreapplication」をクリックします。

4. 「容量管理」をクリックしてから、「可用性」をクリックします。

5. 「構成をロックして編集」をクリックして、「可用性」タブの「アクティブ/パッシブ構成」セクションをアクティブ化します。

6. BIスケジューラとBI Cluster Controllerの「パッシブ・ホスト/インスタンス」を指定します。

7. 「適用」をクリックします。
「潜在的単一点障害」で、「問題はありません。すべてのコンポーネントにバックアップがあります。」と報告されていることを確認します。

8. 「変更のアクティブ化」をクリックします。

9. 「再起動して最近の変更を適用」をクリックします。

15.1.13.15 BI_SERVER2管理対象サーバーのリスニング・アドレスの設定

BI_SERVER2管理対象サーバー・リスニング・アドレスを設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で「bi_server2」を選択します。
bi_server2の「設定」ページが表示されます。

6. リスニング・アドレスをAPPHOST2VHN1に設定します。

7. 「保存」をクリックします。

8. 「変更のアクティブ化」をクリックします。

9. この変更は、BI_SERVER2管理対象サーバーを再起動するまで有効になりません。

1. 「サーバーのサマリー」画面で、「制御」タブを選択します。

2. 表で「bi_server2」を選択してから、「停止」をクリックします。

10. BIシステムのコンポーネントを再起動します。例:

cd ORACLE_BASE/admin/instance2/bin
./opmnctl restartproc

15.1.13.15.1 APPHOST1およびAPPHOST2でのOracle BI Publisher Schedulerの構成の更新

この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLを更新します。

Oracle BI Publisher Schedulerの構成を更新する手順は次のとおりです。

1. 次のURLにアクセスしてOracle BI Publisherにログインします。

http://APPHOST1VHN1:9704/xmlpserver
http://APPHOST2VHN1:9704/xmlpserver

2. 「管理」リンクをクリックします。

3. 「スケジューラ構成」を「システム・メンテナンス」で選択します。

4. 次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。

t3://bi_cluster

5. 「適用」をクリックします。

6. スケジューラのステータスを「スケジューラ診断」タブでチェックします。

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

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。

ホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で「bi_server2」を選択します。

6. 「SSL」タブを開きます。

7. ページの「詳細」セクションを開きます。

8. 「ホスト名の検証」を「なし」に設定します。

9. 「保存」をクリックします。

10. 「変更のアクティブ化」をクリックします。

この変更は、BI_SERVER2管理対象サーバーを再起動するまで有効になりません。

15.1.13.17 Oracle BI for Microsoft OfficeのSSOプロパティの構成

Oracle BI for Microsoft Officeのシングル・サインオン(SSO)プロパティを構成する手順は次のとおりです。

1. 次のURLにアクセスして、Oracle BI EE Officeサーバーのセットアップを検証します。

- http://APPHOST1VHN1:9704/bioffice/about.jsp

- http://APPHOST2VHN1:9704/bioffice/about.jsp

図15-7に示すように、「Oracle BI EE Officeサーバーについて」ページが開きます。

図15-7 「Oracle BI EE Officeサーバーについて」ページ

「図15-7 「Oracle BI EE Officeサーバーについて」ページ」の説明

2. Oracle BI EE Officeサーバー・ディレクトリに移動します。例:
DOMAIN_HOME/servers/managed_server/tmp/_WL_user/bioffice_11.1.1/cvsibb/war/WEB-INF

Oracle BI EE Officeサーバーのディレクトリの場所がわからない場合は、「Oracle BI EE Officeサーバーについて」ページで「LogDir」パラメータを確認してください。Oracle BI Enterprise Edition Officeサーバーのディレクトリは、logディレクトリの親ディレクトリです。

3. APPHOST1およびAPPHOST2の両方で、bioffice.xmlを編集のために開いて、表15-5のとおりにBI Officeのプロパティを変更します。

表15-5 bioffice.xmlに含まれるOracle BI for Microsoft Officeのプロパティ

プロパティ名

有効な値

説明

SawBaseURL

https://bi.mydomain.com:443/analytics/saw.dll

または

https://bi.mydomain.com:443/analytics-ws/saw.dll

Oracle BIプレゼンテーション・サービスのロード・バランサ仮想サーバー名URLです。

重要: SSOが有効になっている場合は、Oracle BI for Microsoft OfficeをSSO対応のOracle BI Serverと統合するように構成する際にデプロイした保護された分析サーブレットのURLを入力してください。Oracle BI for Microsoft OfficeサーバーとPresentation Services間のWebサービスのリクエストは、ここで指定したURLを使用します。

SawUseSSO

0: いいえ(デフォルト)

1: はい

実装されたOracle Business IntelligenceがSSOに対応している場合は、このプロパティを1に設定します。

SawWebURLforSSO

https://bi.mydomain.com:443/analytics/saw.dll

SSOが有効になっている場合は、このプロパティを使用してパブリックURLを入力し、外部ユーザーはこのURLを使用して、Oracle BI for Microsoft OfficeからSSOを使用してOracle Business Intelligenceにアクセスできます。

4. 次の手順に従ってOracle BI for Microsoft Officeアプリケーションを再起動します。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「デプロイメント」をクリックします。

3. 「bioffice(11.1.1)」を選択します。

4. 「停止」をクリックします。

5. アプリケーションの停止後に、「開始」をクリックします。

5. 「Oracle BI EE Officeサーバーについて」ページで、「SawBaseURL」パラメータが更新されていることを確認します。

15.1.13.17.1 Oracle BI for Microsoft Officeの構成の検証

Oracle BI for Microsoft Officeの構成を検証するには、次の手順を実行します。

1. 次の場所でOracle BIプレゼンテーション・サービスにログインします:
https://bi.mydomain.com:443/analytics

2. 左下ペインの「はじめに」見出しの下で、「BIデスクトップ・ツールのダウンロード」を選択してから、「Oracle BI for MS Office」を選択します。

3. Oracle BI for Microsoft OfficeのInstallShieldウィザードを実行して、Oracle BI for Microsoft Officeをインストールします。

4. Microsoft ExcelまたはMicrosoft PowerPointを開きます。

5. 「Oracle BI」メニューから「設定」を選択します。

6. 「接続」タブで「新規」を選択します。

7. 次のフィールドに値を入力します。

- サーバー名: 接続名を入力します。

- BI Officeサーバー: Oracle BI for Microsoft OfficeサーバーのURLを入力します。

- アプリケーション名: Oracle BI for Microsoft Officeサーバー・アプリケーションをWLSにデプロイしたときにOracle BI for Microsoft Officeに対して定義したアプリケーション名を入力します。デフォルト名は、biofficeです。

- ポート: Oracle BI for Microsoft Officeサーバーのポート番号を入力します。

図15-8は、「新規接続」ダイアログを示しています。

図15-8 Oracle BI for Microsoft Officeの「新規接続」ダイアログ

「図15-8 Oracle BI for Microsoft Officeの「新規接続」ダイアログ」の説明

8. 「接続のテスト」をクリックし、アドインとOracle BI for Microsoft Officeサーバーとの間の接続をテストします。

9. 管理者(例: weblogic)としてログインして、図15-9に示す「Oracle BIタスク・ペイン」にアクセスできることを確認します。

図15-9 Microsoft Excel内の「Oracle BIタスク・ペイン」

「図15-9 Microsoft Excel内の「Oracle BIタスク・ペイン」」の説明

15.1.13.18 Oracle BI Publisherの構成

この項では、Oracle BI Publisherを構成する方法を説明します。

15.1.13.18.1 Oracle BIプレゼンテーション・サービスのオプションの設定

Oracle BIプレゼンテーション・サービスの統合のオプションを構成するには、次の手順を実行します。

1. 管理者の資格証明を使用してOracle BI Publisherにログインして、「管理」タブを選択します。

2. 「統合」で、「Oracle BIプレゼンテーション・サービス」を選択します。

3. 次の項目を検証して更新します。

- サーバー・プロトコル: http

- サーバー: bi.mycompany.com

- ポートのURL接尾辞: analytics-ws/saw.dl: 80

4. 「適用」をクリックします。

5. Oracle BI Publisherアプリケーションを再起動します。

15.1.13.18.2スケジューラ構成オプションの設定

スケジューラ構成オプションを構成するには、次の手順を実行します。

1. 管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。

2. 「システム・メンテナンス」で「スケジューラ構成」を選択します。

3. 「クォーツ・クラスタリング」を「スケジューラ選択」で選択します。

4. 変更を適用してから、BI Publisherアプリケーションを再起動します。

15.1.13.18.3 Oracle BI EEデータ・ソースの設定

Oracle BI EEのデータ・ソースは、Cluster Controllerを介してクラスタ化されたBI Serverを指している必要があります。

BI PublisherでOracle BI EEのデータ・ソースを設定する手順は次のとおりです。

1. 管理者の資格証明でBI Publisherにログインします。「管理」タブを選択します。

2. 「データ・ソース」で、「JDBC接続」を選択します。

3. 「接続文字列」パラメータを次のように変更して、Oracle BI EEのデータ・ソース設定を更新します。

<Primary Cluster Controller Port>/PrimaryCCS=<Primary Cluster Controller Host>;PrimaryCCSPort=<Primary Cluster Controller Port>;SecondaryCCS=<Secondary Cluster Controller Host>;SecondaryCCSPort=<Secondary Cluster Controller Port>;

例:

jdbc:oraclebi://APPHOST1:9706/PrimaryCCS=APPHOST1;PrimaryCCSPort=9706;SecondaryCCS=APPHOST2;SecondaryCCSPort=9706;

4. 「システム・ユーザーの使用」を選択します。
接続にシステム・ユーザーを使用しない場合は、「システム・ユーザーの使用」を選択解除して、「ユーザー名」と「パスワード」に対してBIImpersonateUserの資格証明を指定します。このコンテキストでのBIImpersonateUserユーザーの詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Edition開発者ガイドのOracle BI EE プレゼンテーション・カタログへの接続の資格証明に関する説明を参照してください。

5. 「接続のテスト」をクリックします。「接続は正常に確立されました。」というメッセージが表示されることを確認します。「適用」をクリックします。

15.1.13.18.4 Oracle BI Publisher用のJMSの構成

両方のノードから参照できるディレクトリに、すべての永続ストアの場所を構成する必要があります。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 「BipJmsStore」をクリックして、共有記憶域にあるディレクトリを入力します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。

ORACLE_BASE/admin/domain_name/bi_cluster/jms

5. 「保存」→「変更のアクティブ化」をクリックします。

6. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。

7. 「チェンジ・センター」で、「ロックして編集」をクリックします。

8. 「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。

9. 名前(例: BipJmsStore2)を入力し、BI_SERVER2をターゲットにします。APPHOST1とAPPHOST2の両方からアクセスできるように、共有記憶域にあるディレクトリを入力します。

ORACLE_BASE/admin/domain_name/bi_cluster/jms

10. 「OK」をクリックして、変更をアクティブ化します。

11. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSサーバー」ノードをクリックします。

12. 「チェンジ・センター」で、「ロックして編集」をクリックします。

13. 新規をクリックします。

14. 名前(例: BipJmsServer2)を入力してから「永続ストア」ドロップダウン・リストで「BipJmsStore2」を選択し、「次へ」をクリックします。

15. 「BI_SERVER2」をターゲットとして選択します。

16. 「終了」→「変更のアクティブ化」をクリックします。

17. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。

18. 「チェンジ・センター」で、「ロックして編集」をクリックします。

19. 「BIPJmsResource」→「サブデプロイメント」タブをクリックします。

20. 「サブデプロイメント」の「BipJmsSubDeployment」のターゲットを、BipJmsServer1とBipJmsServer2の両方にします。

21. 「終了」→「変更のアクティブ化」をクリックします。

Oracle BI Publisherに対して実行したJMS構成を検証するには、第15.1.13.7.1項「Oracle BI Publisher Schedulerの構成の更新」の手順を実行してください。

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

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。

BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

4. 「BI_SERVER1」(ハイパーリンクとして表示されています)を表の「名前」列でクリックします。
BI_SERVER1の設定ページが開き、「構成」タブがアクティブに表示されます。

5. 「サービス」タブをクリックします。

6. 「デフォルト・ストア」セクションで、デフォルトの永続ストアでデータ・ファイルを格納するフォルダのパスを入力します。そのパス・ディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/bi_cluster/tlogs

7. 「保存」→「変更のアクティブ化」をクリックします。

8. BI_SERVER2サーバーに対してこれらの手順を繰り返します。

注意:

トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方からこのディレクトリにアクセスできる必要があり、サーバーの再起動前に、このディレクトが存在している必要があります。

15.1.13.19 APPHOST2でのシステムの起動

この項では、APPHOST2でシステムを起動する手順について説明します。

15.1.13.19.1 APPHOST2でのノード・マネージャの起動

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、第15.1.13.9.1項「APPHOST1でのノード・マネージャの起動」の手順に従って、APPHOST2でノード・マネージャを起動してください。

15.1.13.19.2 BI_SERVER2管理対象サーバーの起動と検証

BI_SERVER2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は、次のとおりです。

1. 管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「制御」タブをクリックします。

4. 「bi_server2」を選択してから、「起動」をクリックします。

2. 管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。

3. BI_SERVER2が起動すると、次のURLが使用できるようになります。

- http://APPHOST2VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。

注意:

ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

- http://APPHOST2VHN1:9704/xmlpserverにアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。

15.1.13.19.3 Business Intelligence Enterprise Editionシステム・コンポーネントの起動と検証

APPHOST2でBI Enterprise Editionシステム・コンポーネントを起動するには、第15.1.13.9.3項「APPHOST1でのBI EEシステム・コンポーネントの起動と検証」の手順をAPPHOST2で繰り返します。

15.1.13.20 BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成

BI_SERVERn管理対象サーバーを含むbi_clusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

1. WEBHOST1およびWEBHOST2で、ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。

# BI Office
<Location /bioffice>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /biofficeclient>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BIEE Analytics
<Location /analytics>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /mapviewer>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /analytics-ws>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /bimiddleware>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BI Publisher
<Location /xmlpserver>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

2. WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。

3. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

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

管理コンソールで、BI ServerのステータスがRunningであることを確認します。ステータスがStartingまたはResumingである場合は、サーバー・ステータスがStartedに変更されるまで待機します。コンソールに別のステータス(Adminなど)が表示された場合は、サーバー出力のログ・ファイルでエラーを調べてください。

次のURLにアクセスできることを確認します。

- http://WEBHOST1:7777/wsm-pm

- http://WEBHOST2:7777/wsm-pm

- http://WEBHOST1:7777/analytics

- http://WEBHOST2:7777/analytics

- http://WEBHOST1:7777/xmlpserver

- http://WEBHOST2:7777/xmlpserver

- http://WEBHOST1:7777/bioffice/about.jsp

- http://WEBHOST2:7777/bioffice/about.jsp

- http://WEBHOST1:7777/mapviewer

- http://WEBHOST2:7777/mapviewer

ロード・バランシング・ルーター・アドレスを使用して、次のURLにアクセスできることを確認します。

- http://bi.mycompany.com:80/analytics

- http://bi.mycompany.com:80/xmlpserver

- http://bi.mycompany.com:80/wsm-pm

- http://bi.mycompany.com:80/bioffice/about.jsp

- http://bi.mycompany.com:80/mapviewer

次の手順に従って、HTTP Serverからbi_clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

1. BI_SERVER2の実行中に、管理コンソールからBI_SERVER1を停止します。

2. 次のURLにアクセスして、適切な機能を検証します。

- WEBHOST1:7777/wsm-pm

- WEBHOST1:7777/analytics

- WEBHOST1:7777/xmlpserver

- WEBHOST1:7777/bioffice/about.jsp

3. 管理コンソールから、BI_SERVER1を開始します。

4. BI_SERVER2を停止します。

5. 前述のステップ2のURLにアクセスして、適切な機能を検証します。

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

Oracle WebLogic Serverクラスタに対して、フロントエンドHTTPのホストとポートを設定する必要があります。そのためには、次の手順に従ってください。

1. 管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

2. 左側のペインで、「ドメイン構造」ウィンドウの「環境」を選択し、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。

3. 「bi_cluster」クラスタを選択します。

4. 「HTTP」を選択します。

5. 次の値を設定します。

- フロントエンド・ホスト: bi.mycompany.com

- フロントエンドHTTPポート: 80

- フロントエンドHTTPSポート: このフィールドは空白のままにします。

注意:

このアドレスが正しくて使用可能である(ロード・バランサが稼働している)ことを確認してください。アドレスの「http://」やホスト名末尾の「/」など、値が間違っていると、仮想IPを使用してアクセスする場合でも、BIシステムにアクセスできない可能性があります。

6. 「保存」をクリックします。

7. 変更内容をアクティブ化するには、「変更のアクティブ化」をクリックします。

8. サーバーを再起動して、クラスタ内のフロントエンド・ホスト・ディレクティブを有効化します。

15.1.13.22 BI_SERVERnサーバーのサーバー移行の構成

この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を次のように構成する必要があります。

- 障害発生時に、bi_server1管理対象サーバーがAPPHOST2で再起動するよう構成します。

- 障害発生時に、bi_server2管理対象サーバーがAPPHOST1で再起動するよう構成します。

このような構成では、bi_server1サーバーおよびbi_server2サーバーは、WLSサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。

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

- ステップ1: サーバー移行leasing表のユーザーと表領域を設定する

- ステップ2: 管理コンソールを使用してマルチ・データ・ソースを作成する/GridLinkデータ・ソースを作成する

- ステップ3: ノード・マネージャのプロパティ・ファイルを編集する

- ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する

- ステップ5: サーバー移行ターゲットを構成する

- ステップ6: サーバー移行をテストする

15.1.13.22.1 サーバー移行leasing表のユーザーと表領域の設定

サーバー移行leasing表のユーザーと表領域を設定する手順は次のとおりです。

1. leasingという名前の表領域を作成します。たとえば、ユーザーsysdbaでSQL*Plusにログインし、次のコマンドを実行します。

SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;

2. leasingという名前のユーザーを作成し、leasing表領域に割り当てます。

SQL> create user leasing identified by welcome1;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

3. leasing.ddlスクリプトを使用してleasing表を作成します。

1. WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。

2. データベースにleasingユーザーとして接続します。

3. SQL*Plusでleasing.ddlスクリプトを実行します。

SQL> @Copy_Location/leasing.ddl;

15.1.13.22.2 管理コンソールによるマルチ・データ・ソースの作成/GridLinkデータ・ソースの作成

この項では、マルチ・データ・ソースの作成方法およびGridLinkデータ・ソースの作成手順について説明します。

GridLinkデータソースの作成

GridLinkデータ・ソースには、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」で説明されているように、汎用データ・ソースの機能に加え、Oracle RACに対する追加サポートが含まれています。

GridLinkデータ・ソースを作成する手順は次のとおりです。

1. 既存のマルチ・データ・ソースをすべて削除します。JDBCマルチ・データ・ソースの削除に関する説明を参照してください。

2. 対応するデータ・ソースを削除します。

3. GridLinkデータ・ソースを作成します。管理コンソール・オンライン・ヘルプのJDBC汎用データ・ソースの作成に関する説明を参照してください。

GridLinkデータ・ソースの構成方法の包括的な概要は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのGridLinkデータ・ソースの作成に関する説明を参照してください。

マルチ・データ・ソースの作成

マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データソースを作成する際は、次の点に注意してください。

- このデータ・ソースが非XAデータ・ソースであることを確認します。

- マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。

- Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。

- データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。

- これらのデータ・ソースをOracle WebCenter Content: Imagingクラスタのターゲットに設定します。

- データ・ソースの初期接続プール容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データ・ソース名」→「接続プール」タブをクリックし、「初期容量」フィールドに0を入力します。

マルチ・データ・ソースを作成する手順は、次のとおりです。

1. 管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「データ・ソース」をクリックします。「JDBCデータ・ソースのサマリー」ページが表示されます。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「新規」→「マルチ・データ・ソース」をクリックします。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。

4. 名前として、leasingと入力します。

5. JNDI名として、jdbc/leasingと入力します。

6. アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。

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

8. 「bi_cluster」をターゲットとして選択します。

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

10. 「非XAドライバ」(デフォルト)を選択します。

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

12. 「新しいデータ・ソースの作成」をクリックします。

13. 名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。

注意:

leasing表のマルチ・データ・ソースを作成するときに、名前を<MultiDS>-rac0、<MultiDS>-rac1などの形式で入力します。

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

15. 「グローバル・トランザクションのサポート」の選択を解除します。

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

17. leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。

18. 「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。

19. データ・ソースのターゲットをbi_clusterに設定します。

20. データ・ソースを選択して、右の画面に追加します。

21. Oracle RACデータベースの2つ目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをbi_clusterに設定してから、Oracle RACデータベースの2つ目のインスタンスについても同じ手順を繰り返します。

22. 2つ目のデータ・ソースをマルチ・データ・ソースに追加します。

23. 「変更のアクティブ化」をクリックします。

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

この項では、ノード・マネージャのプロパティ・ファイルnodemanager.propertiesの編集方法について説明します。これは、サーバーの移行を構成する両方のノードのノード・マネージャに対して実行する必要があります。

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

- Interface: このプロパティは、浮動IPのインタフェース名(たとえば、Linuxではeth0)を指定します。

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

注意:

Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: Interface="Local Area Connection"

- NetMask: このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります。このドキュメントの例では、255.255.255.0が使用されています。

- UseMACBroadcast: このプロパティでは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、すなわち、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力は、次のように表示されます。

...
StateCheckInterval=500
Interface=eth0 (Linux) or Interface="Local Area Connection" (Windows)
NetMask=255.255.255.0
...

注意:

次の手順は、サーバー・プロパティ(起動プロパティ)が適切に設定されていて、ノード・マネージャがリモートでサーバーを起動できる場合には不要です。

1. nodemanager.propertiesファイルで次のプロパティを設定します。

- StartScriptEnabled: このプロパティをtrueに設定します。これは、ノード・マネージャが起動スクリプトを使用して管理対象サーバーを起動するために必要です。

2. WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、APPHOST1とAPPHOST2でノード・マネージャを起動します。

注意:

共有記憶域インストールからノード・マネージャを実行する場合、同じnodemanager.propertiesファイルを使用して複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個々のパラメータを指定します。たとえば、APPHOSTnで異なるインタフェース(eth3)を使用するには、インタフェース環境変数を「APPHOSTn> export JAVA_OPTIONS=-DInterface=eth3」のように使用して、この変数がシェル内で設定された後にノード・マネージャを起動します。

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

この項では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する方法について説明します。

注意:

Windowsでは、このスクリプトの名前はwlsifconfig.cmdであり、管理者権限を持つユーザーがこれを実行できます。

1. PATH環境変数に次のファイルが含まれていることを確認します。

表15-6 PATH環境変数に必要なファイル

ファイル

格納されているディレクトリ

wlsifconfig.sh

ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

WL_HOME/common

2. wlsifconfig.shスクリプトに対するsudo構成権限を付与します。

- パスワード・プロンプトを使用しないで機能するsudoを構成します。

- セキュリティ上の理由から、sudoをwlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。

1. WebLogicユーザー(oracle)に、パスワードなしのsudo権限を付与し、/sbin/ifconfigと/sbin/arpingのバイナリの実行権限を付与します。

2. WebLogicユーザー(oracle)がスクリプトを実行できることを確認します。/etc/sudoers内の次のエントリ例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

注意:

この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。

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

この項では、サーバー移行ターゲットを構成する方法について説明します。まず、すべての使用可能なノードをクラスタのメンバーに割り当て、次に、サーバー移行用に構成された各サーバーに候補となるマシン(適切な順序で)を指定します。クラスタ内の移行でクラスタ移行を構成するには、次の手順を実行します。

1. 管理コンソール(http://Host:Admin_Port/console)にログインします。通常、Admin_Portは7001(デフォルト)です。

2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。

3. 移行を構成する対象となるクラスタ(bi_cluster)を、表の「名前」列でクリックします。

4. 「移行」タブをクリックします。

5. 「チェンジ・センター」で、「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「APPHOST1」と「APPHOST2」を選択します。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。

8. 「保存」をクリックします。「変更のアクティブ化」をクリックします。

9. サーバー移行の候補マシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。

1. 管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。

ヒント:

サーバーが実行されているマシンを表示するには、「サーバーのサマリー」ページで「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウに移動します。サーバーが自動的に移行される場合、これはこの構成とは異なります。

2. 移行を構成するサーバーを選択します。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。bi_server1については、「APPHOST2」を選択します。bi_server2については、「APPHOST1」を選択します。

5. 「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

6. 「保存」をクリックします。「変更のアクティブ化」をクリックします。

7. 管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。

15.1.13.22.6 サーバー移行のテスト

最後の手順は、サーバー移行をテストすることです。サーバー移行が適切に機能していることを確認する手順は次のとおりです。

APPHOST1から:

1. bi_server1管理対象サーバーを強制停止します。次のコマンドを実行します。

APPHOST1> kill -9 pid

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

APPHOST1> ps -ef | grep bi_server1

注意:

Windowsの場合は、taskkillコマンドを使用して管理対象サーバーを終了できます。例:

taskkill /f /pid <pid>

<pid>は、管理対象サーバーのプロセスIDを表します。

管理対象サーバーのプロセスIDを調べるには、次のコマンドを実行して、bi_servern管理対象サーバーのpidを確認します。

MW_HOME\jrockit_160_<version>\bin\jps -l -v

2. ノード・マネージャのコンソールを確認します。bi_server1の浮動IPが無効になっていることを示すメッセージが表示されます。

3. ノード・マネージャがbi_server1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

APPHOST2から:

1. ローカルのノード・マネージャのコンソールを確認します。APPHOST1でbi_server1の再起動が最後に試行されてから30秒経過した後、APPHOST2のノード・マネージャによって、bi_server1の浮動IPが有効化されようとしていること、およびこのノードでサーバーが再起動されようとしていることが示されます。

2. 同じIPを使用していずれかのアプリケーション(BI Publisherなど)にアクセスします。

管理コンソールからの検証

管理コンソールで移行を検証することもできます。

1. 管理コンソールにログインします。

2. 左側のコンソールで、「ドメイン」をクリックします。

3. 「監視」タブ→「移行」サブタイプをクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

15.1.13.23 Oracle BI EEトポロジのスケール・アップ

Oracle BI EEトポロジをスケール・アップする際は、Oracle BI EE高可用性トポロジ内のいずれかの既存ノードに新たなシステム・コンポーネントを追加します。

この項では、ノードが2つ以上あり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがある高可用性トポロジを前提にします。トポロジをスケール・アップするには、いずれかの既存ノードで実行されているシステム・コンポーネントの数を増やします。

特定のノードで複数の管理対象サーバーを実行する必要はありません。

Oracle BI EEトポロジをスケール・アップする手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

3. 「coreapplication」をクリックします。

4. 「容量管理」をクリックしてから、「スケーラビリティ」をクリックします。

5. 「構成をロックして編集」をクリックします。

6. 矢印キーを使用して、「BIサーバー」、プレゼンテーション・サービスまたは「JavaHost」の数を変更します。

7. 「適用」をクリックしてから、「変更のアクティブ化」をクリックします。

8. 「概要」をクリックしてから、「再起動」をクリックします。

15.1.13.24 新しいノード(APPHOST3)へのOracle BI EEトポロジのスケール・アウト

Oracle BI EEトポロジをスケール・アウトする際は、トポロジ内の新しいノード(APPHOST3)に、新しい管理対象サーバーとシステム・コンポーネント・セットを追加します。この項では、ノードが2つ以上あり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがある高可用性トポロジを前提にします。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

- Oracle Business Intelligenceの管理対象サーバーが稼働している既存ノードがトポロジ内に存在していること。

- 新しいノード(APPHOST3)が、Oracle WebLogic ServerとOracle Business Intelligence用の既存のホーム・ディレクトリにアクセスできます。

- ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。新しいノードをインストールするときにバイナリ・ファイルとドメインに使用するディレクトリ・パスは、最初のノードに使用したものと同一にする必要があります。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、MW_HOME/.homeファイルを編集します。次の手順を参照してください。

- 新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。

APPHOST3でOracle Business Intelligenceをスケール・アウトする手順は次のとおりです。

1. APPHOST3で、Oracle Business Intelligenceのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>

Middlewareホーム・リストを更新するには、MW_HOME/.homeファイルを作成して(別のWebLogicインストールがノード内に存在する場合はそれを編集して)、それにORACLE_BASE/product/fmwを追加します。

3. VIP3をAPPHOST3で有効にします。第15.1.13.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。

4. 第15.1.13.12項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームから構成アシスタントを実行します。

5. 第15.1.13.13項「BIシステム・コンポーネントのスケール・アウト」の手順に従って、APPHOST3でシステム・コンポーネントをスケール・アウトします。

6. 第15.1.13.15項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第15.1.13.16項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名検証を無効にすることで、bi_server3管理対象サーバーを構成します。

7. 第15.1.13.18.4項「Oracle BI Publisher用のJMSの構成」の説明に従って、Oracle BI Publisher用のJMSを構成します。

8. 第15.1.13.17項「Oracle BI for Microsoft OfficeのSSOプロパティの構成」の説明に従って、APPHOST3上のOracle BI for Microsoft Officeを構成します。

9. 第15.1.13.18.5項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。

10. 第15.1.13.20項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。

11. APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第15.1.13.9.2項「BI_SERVER1管理対象サーバーの起動と検証」および第15.1.13.9.3項「APPHOST1でのBI EEシステム・コンポーネントの起動と検証」を参照してください。

12. 第15.1.13.22項「BI_SERVERnサーバーのサーバー移行の構成」の説明に従って、サーバー移行を構成します。

13. 構成を検証するには、次のURLにアクセスします。

- http://APPHOST3VHN1:9704/analyticsにアクセスして、bi_server3のステータスを確認します。

- http://APPHOST3VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

- http://APPHOST3VHN1:9704/xmlpserverにアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。

14. ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信には、それぞれのアドレス用の証明書を使用する必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のノード・マネージャの設定に関する章を参照してください。

15.2 Oracle Business Intelligence Publisherの高可用性

Oracle Business Intelligence Publisher(Oracle BI Publisher)は、複雑な分散環境に適用できる最も効率的でスケーラブルなレポート・ソリューションを提供します。セキュリティが高く適切なフォーマットで情報を生成して、従業員、顧客およびサプライヤに配信するための中央アーキテクチャを提供します。Oracle BI Publisherを使用すれば、ビジネス文書の開発、カスタマイズおよびメンテナンスにかかる高額なコストを削減しながら、レポート管理の効率性を向上させることができます。

この項では、Oracle BI Publisherの高可用性環境を設計およびデプロイする方法を説明します。

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

- 第15.2.1項「Oracle BI Publisherのコンポーネント・アーキテクチャ」

- 第15.2.2項「Oracle BI Publisherの高可用性の概要」

- 第15.2.3項「Oracle BI Publisherの高可用性の構成手順」

15.2.1 Oracle BI Publisherのコンポーネント・アーキテクチャ

図15-10では、単一インスタンス・アーキテクチャでのOracle BI Publisherコンポーネントを示しています。

図15-10 Oracle BI Publisherの単一インスタンス・アーキテクチャ

「図15-10 Oracle BI Publisherの単一インスタンス・アーキテクチャ」の説明

15.2.1.1 Oracle BI Publisherコンポーネントの特性

Oracle BI Publisherは、サーブレットベースのアーキテクチャを使用するJava EEアプリケーションです。JMSは、スケジュール済のジョブを実行するために使用されます。Fusion ESSは、Webサービスを通じてBI Publisherと統合します。

15.2.1.1.1 状態情報

Oracle BI Publisherレポートの実行中は、セッション情報がメモリーに保管されます。

複数のサーバーにまたがってレポートの実行を移行する複雑性があるため、BI Publisherはステートレス・アプリケーションではありません。

15.2.1.1.2 ランタイム・プロセス

Oracle BI Publisherは、Oracle WebLogic ServerにデプロイされるJava EEコンポーネントです。

- Oracle BI Publisherのアーティファクトの処理(次のアーティファクトの作成、削除および編集を含む)

- レポート

- データ・モデル

- レイアウト・テンプレート

- スケジューラ・ジョブ

- 構成

- スケジューラ・レポートの実行

- オンライン・レポートの実行

15.2.1.1.3 プロセスのライフサイクル

Oracle BI Publisherは、Oracleインフラストラクチャに全面的に依存しています。Oracle BI Publisherをデプロイ、起動、停止および監視するには、管理コンソールを使用します。

15.2.1.1.4 リクエスト・フロー

JMSは、Oracle BI Publisherのバッチ・レポート処理システムのバックボーンとして使用されます。JMSは、トランザクション方式でメッセージング・ボードとして使用されます。すべてのレポートは次の実行段階に分けられます。

1. データの取得

2. データのフォーマット設定

3. レポートの配信

これらの各段階は、JMSキュー内のジョブ・リクエストとして表現されます。1つのノードが停止した場合、他のノードがそのキューへのサービス提供を続行します。ただし、レポート・ジョブが、これらの実行の段階(データ取得、データの書式設定またはレポートの配信)の1つにある場合、そのジョブは失敗としてマークされ、それを手動で再送信する必要があります。

15.2.1.1.5 外部依存性

Oracle BI Publisherは次に依存しています。

- データベース・リポジトリ: スケジュール済ジョブの情報用に使用されます。

- Oracle BI Publisherアーティファクトの保管: これらのアーティファクトには、レポート、定義およびレイアウトが含まれます。この保管は次の2種類の方法で行われます。

- Oracle Business Intelligence Enterprise Editionモード: Oracle BI Publisherは、Webサービス経由の短時間接続を介してOracle BIプレゼンテーション・カタログを使用します。

- スタンドアロン・モード: Oracle BI Publisherは、共有ファイル・システムを使用します(SANやNASなど)。

- レポート・データ用のDBMS: Oracle BI Publisherは、DBMSに問い合せて、処理する必要のあるレポート・データを取得します。

- Webサービス: データを取得するために使用されます。

15.2.1.1.6 構成アーティファクト

Oracle BI Publisherは、標準のJava EEアプリケーションです。

15.2.1.1.7 デプロイメント・アーティファクト

Oracle BI Publisherには、特別なデプロイメント・アーティファクトはありません。

15.2.1.1.8 ログ・ファイル

Oracle BI Publisherは、Oracle WebLogic ServerにデプロイされるJava EEアプリケーションです。ログ・メッセージはすべて、アプリケーションがデプロイされるOracle WebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

15.2.2 Oracle BI Publisherの高可用性の概要

この項では、Oracle BI Publisherを高可用性環境で使用する場合の概要について説明します。

15.2.2.1 Oracle BI Publisherの高可用性アーキテクチャ

図15-11は、Oracle BI Publisherの高可用性アーキテクチャを示しています。

図15-11 Oracle BI Publisherの高可用性アーキテクチャ

「図15-11 Oracle BI Publisherの高可用性アーキテクチャ」の説明

図15-11では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。

Oracle BI Publisherが実行されるOracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。APPHOST2上の管理サーバーはパッシブです。第3章「WebLogic Serverの高可用性」で説明されているように、APPHOST1が使用できなくなった場合、APPHOST2で管理サーバーをアクティブにできます。Oracle BI Publisherは、これらのホストのBI_SERVER1およびBI_SERVER2管理サーバーでデプロイされます。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。サーバー移行全体は、管理対象サーバー用に構成されます。

BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してVIPマッピングを有効にして(APPHOST1ではVIP1、APPHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。BIサーバーのサーバー移行を構成する方法の詳細は、第15.1.13.22項「BI_SERVERnサーバーのサーバー移行の構成」を参照してください。

データ層では、レコード定義、レポート・レイアウト、データ・モデルなどのOracle BI Publisherリポジトリ・メタデータと、Oracle BI Publisher JMS永続ストアを格納するための共有外部記憶域が設定されます。

Oracle RACデータベースは、レポート・データ用に使用されますが、エンタープライズ・データベース用としてもお薦めします。

Oracle BI Publisherは、アクティブ/アクティブ形式の高可用性構成をサポートしています。各ノードは、他のOracle BI Publisherノードと共通のリポジトリおよびスケジューラ・データベースを共有する独立サーバーとして動作します。

Oracle BI Publisherリポジトリ(レポートやデータ・モデルなどのすべてのコンテンツを格納)は、BI PublisherがOracle BI EEと組み合せて構成されている場合はOracle BIプレゼンテーション・カタログに保管され、Oracle BI Publisherが単独でインストールされている場合は共有ファイル・システムに保管されます。

Oracle BI Publisherの構成フォルダは共有ファイル・システムに配置されている必要があります。

共有リポジトリには、次のOracle BI Publisherアーティファクトが保管されます。

- レポート定義

- レポート・テンプレート

- データ・モデル

- Oracle BI Publisherの構成

Schedulerデータベースは、次の情報が保管される共有データベースです。

- レポートの詳細(パラメータ)

- 実行ステータス

- 実行履歴

- 過去のレポート実行のスナップショット

ハードウェアまたはソフトウェアのロード・バランサを、高可用性環境内のOracle BI Publisherノードに対するフロントエンドとして使用できます。

Oracle BI Publisherの高可用性デプロイメントでは次のことが当てはまります。

- スティッキー・セッションをロード・バランサに対して有効にする必要があります。

- Oracle BI Publisherは、WebLogic ServerのJMSフェイルオーバー・メカニズムに依存しています。

- クラスタ内のすべてのOracle BI Publisherインスタンスは独立しています。

- アーティファクトと構成は共有リポジトリに保管されており、各インスタンスは個別にこのリポジトリを読み取ります。

15.2.2.1.1 共有ファイルと共有ディレクトリ

Oracle BI Publisherの共有ファイルは、前の項で説明した共有リポジトリとSchedulerデータベースです。

15.2.2.1.2 クラスタワイドの構成変更

構成フォルダには、BI Publisherを使用して設定したすべての構成、セキュリティおよびデータ・ソースが格納されています。構成フォルダが共有記憶域にある場合は、加えられたすべての変更はクラスタ内のすべてのノードに適用されます。

15.2.2.2 障害からの保護および予想される動作

ノード・マネージャは、障害が発生したOracle BI Publisherインスタンスを再起動するように設定できます。

Oracle BI Publisherインスタンスが再起動されても、他の実行中インスタンスは影響を受けません。

ノードで障害が発生したときに生じる動作は次のとおりです。

- シングル・サインオンが実装されていないデプロイメント環境では、ユーザーは再びログインするように求められます。

- 編集内容が含まれていたトランザクションはすべて保存されます。

15.2.2.3 トラブルシューティング

Oracle BI Publisherのログは、次のデフォルト場所にあるWebLogic Serverのログに含まれています。

DOMAIN_HOME/servers/serverName/logs/serverName-diagnostic.log

また、次のファイルにはBI Publisher関連のメッセージが含まれています。

DOMAIN_HOME/servers/serverName/logs/bipublisher/bipublisher.log

構成情報は共有リポジトリに保管されています。構成ファイルは、共有リポジトリ内のAdminディレクトリに保管されています。

15.2.3 Oracle BI Publisherの高可用性の構成手順

この項では、Oracle BI Publisherの2ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図15-11に示しています。

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

15.2.3.1 環境の準備: Oracle BI Publisherの高可用性構成の設定前に必要な手順

この項では、BI Publisherの高可用性構成を設定するための前提条件について説明します。

15.2.3.1.1 データベースに関する前提条件

Oracle BI Publisherでサポートしているデータベースのバージョンは次のとおりです。

- Oracle Database 10g(非XEデータベースについては10.2.0.4以上)

- Oracle Database 11g(非XEデータベースについて11.1.0.7以上)

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.2.3.1.2 VIPとIPの前提条件

図15-7で示すように、異なる仮想IPをリスニングするようにBI管理対象サーバーを構成します。そのためには、ノード内の対応するVIPのプロビジョニングと、ネットワーク上のDNSシステムで関連付けられているホスト名が必要です。インストールを実行する前に、各VIPが使用可能であり、アクセスできることを確認します。

表15-7 BI Publisherの仮想ホスト

仮想IP

仮想IPのマップ先

説明

VIP1

APPHOST1VHN1

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

VIP2

APPHOST2VHN1

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

15.2.3.1.3 共有記憶域に関する前提条件

障害発生時に適切にリカバリできるようにするには、すべてのノードからアクセスできる場所にJMSとトランザクションの両方のログを格納して、管理対象サーバーで障害が発生した後にすべてのノードが操作を再開できるようにします。そのためには、複数ノードで参照可能な共有記憶域の場所が必要です。表15-8は、共有記憶域の内容を示しています。

表15-8 BI Publisherの共有記憶域の内容

サーバー

データの型

共有記憶域のボリューム

ディレクトリ

ファイル

BI_SERVER1とBI_SERVER2

トランザクション・ログ

VOL2

ORACLE_BASE/admin/domain_name/bi_cluster_name/tlogs

共通の場所(WebLogicサーバーにより決められたストア)

BI_SERVER1とBI_SERVER2

JMSストア

VOL2

ORACLE_BASE/admin/domain_name/bi_cluster_name/jms

共通場所ですが、サーバーごとに個別のストアになります。例: BI_SERVER1にはBipJmsStore、BI_SERVER2にはBipJmsStore2。

BI_SERVER1とBI_SERVER2

BI Publisher構成フォルダ

VOL1

ORACLE_BASE/domain_name/config/bipublisher/repository

共通の場所

BI_SERVER1とBI_SERVER2

BI Publisherカタログ・リポジトリ

VOL1

ORACLE_BASE/domain_name/config/bipublisher/catalog

共通の場所

BI_SERVER1とBI_SERVER2

BI Publisher Scheduler一時ディレクトリ

VOL1

ORACLE_BASE/domain_name/config/bipublisher/temp

共通の場所

共有記憶域にはNASやSANなどのデバイスを使用できます。NASデバイス別のコマンド例を次に示します。この項で指定しているオプションは、実際のオプションと異なる場合があります。

APPHOST1> mount nasfiler:/vol/volX/FMWshared MW_HOME-t nfs -o
rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

15.2.3.1.4 クロックの同期

クラスタに参加しているすべてのサーバーのクロックを、1秒以内の差異に収まるように同期する必要があります。クロックを同期するには、単一のネットワーク・タイム・サーバーを使用して各サーバーがそのネットワーク・タイム・サーバーを指すようにします。ネットワーク・タイム・サーバーを指すように設定する手順は、WindowsとLinuxでは異なります。使用するオペレーティング・システムのドキュメントを参照してください。

15.2.3.1.5 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

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

自動ストレージ管理

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをOracle Real Application Clusters(Oracle RAC)データベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g (11.1.1.)Oracle Fusion Middleware RepositoryをOracle RACデータベースにインストールしてください。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

15.2.3.1.6 RCUを使用したデータベースへのBusiness Intelligenceスキーマのロード

Oracle BI Publisherをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとOracle BIスキーマをOracle RACデータベースにインストールします。次の手順を実行します。

1. リポジトリ作成ユーティリティ(RCU)のDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。

prompt> cd RCU_HOME/bin
prompt> ./rcu

2. 「ようこそ」画面で「次へ」をクリックします。

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

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

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

- ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを次のように指定します:
BIDBHOST1-VIP

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

- サービス名: データベースのサービス名を指定します。
biha.mycompany.com

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

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

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

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

5. 「コンポーネントの選択」画面で、次を行います。

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

ヒント:

このスキーマの名前をメモに記録してください。後述する手順でこの情報が必要になります。

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

o  AS Common Schemas: Metadata Services (automatically selected)
o  Oracle Business Intelligence: Business Intelligence Platform

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

6. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択できます。

「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。

ヒント:

スキーマ・パスワードの名前をメモに記録してください。後述する手順でこの情報が必要になります。

7. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

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

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

15.2.3.1.7 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle BI Publisherの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

BI Publisherは、2つのOracle HTTP ServerがWeb層コンポーネントとして使用された高可用性構成でデプロイされた場合は、ハードウェア・ロード・バランサを使用します。

仮想サーバー名

bi.mycompany.comは、Oracle BI PublisherなどのランタイムBIコンポーネント宛てのすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、bi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

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

この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。

1. サーバーが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。

- ポート7777がWEBHOST1上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに対して次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep "7777"

Windowsの場合:

netstat -an | findstr :7777

ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。

UNIXの場合:

ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

- staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

- 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle HTTP Serverのポート番号を指定する行は非コメント化)を割り当てます。

# The port for Oracle HTTP server
Oracle HTTP Server port = 7777

2. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXの場合:

./runinstallerコマンドを発行します。

Windowsの場合:

setup.exeをダブルクリックします。

「インベントリ・ディレクトリの指定」画面が表示されます。

3. 「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /u01/app/oraInventory

オペレーティング・システムのグループ名: oinstall

次のメッセージのダイアログ・ボックスが表示されます。

「インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください」

rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。

これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。

注意:

すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。このインストールで「Oracleインベントリ」画面が表示されない場合は、次の内容を確認してください。

- /etc/oraInst.locファイルが存在しているか。

- このファイルが存在する場合は、表示されているインベントリ・ディレクトリが有効か。

- インストールを実行するユーザーに、インベントリ・ディレクトリへの書込み権限が付与されているか。

4. 「ようこそ」画面で「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

6. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。

7. 「インストール場所の指定」画面で、次を指定します。

- Oracle Middlewareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)

- Oracleホーム・ディレクトリ: Oracle_WT1

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

8. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

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

9. 「コンポーネントの詳細の指定」画面で、WEBHOST1用に次の値を入力します。

- インスタンス・ホームの場所: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1

- インスタンス名: web1

- OHSコンポーネント名: ohs1

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

10. 「ポートの構成」画面で、次の操作を行います。

- カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

- Oracle HTTP Serverポートを入力します(例: 7777)。

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

11. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。

12. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「インストール」をクリックします。

13. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

14. 「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。「次へ」をクリックします。

15. 「インストール完了」画面で「終了」をクリックして終了します。

WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランサを構成します。

15.2.3.1.9 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、ブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

http://WEBHOST1:7777/
http://WEBHOST2:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザにOracle FMWの「ようこそ」画面が表示されます。

15.2.3.2 Oracle Fusion Middlewareホームのインストール

この項では、Oracle WebLogic ServerとOracle Fusion Middleware BI EEを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする手順について説明します。WebLogic ServerとBI PublisherをAPPHOST2にインストールするために、これと同じ手順を繰り返します(次ではAPPHOST1を対象にして説明しています)。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

- Oracle WebLogic Server

- Oracle Fusion Middleware BI EE

15.2.3.2.1 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールする手順は次のとおりです。

1. Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します。

注意:

ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracleの値をお薦めします。

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

4. 「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。

6. 「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.6ディレクトリを受け入れます。そして「次へ」をクリックします。

7. 「インストールの概要」画面で「次へ」をクリックします。
Oracle WebLogic Serverソフトウェアがインストールされます。

8. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

15.2.3.2.2 BI Publisher用のOracle Fusion Middlewareのインストール

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

1. Oracle Fusion Middleware Business Intelligence 11gのインストーラを次のインストール・メディアから起動します。
UNIXの場合:

APPHOST1>./runInstaller

Windowsの場合:

APPHOST1> setup.exe

2. 「インベントリ・ディレクトリの指定」画面で、次の操作を行います。

- HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

- インストールを実行するユーザーのOSグループを入力します。
「次へ」をクリックします。

- 画面の手順に従って、/createCentralnventory.shをrootとして実行します。
「OK」をクリックします。

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「インストール・タイプの選択」画面で、「ソフトウェアのみインストール」を選択して「次へ」をクリックします。

5. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

6. 「インストール場所の指定」画面で、前にインストールしたMiddlewareホームをドロップダウン・リストで選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(Oracle_BI1)を入力します。
「次へ」をクリックします。

7. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。

8. 「サマリー」画面で「インストール」をクリックします。

9. 「インストールの進行状況」画面で「次へ」をクリックします。

10. 完了画面で「終了」をクリックします。

15.2.3.3 APPHOST1のVIP1およびAPPHOST2のVIP2の有効化

BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してマッピングされているVIPを有効にして(APPHOST1ではVIP1、APPHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。

15.2.3.4 管理サーバーと1つ目のBI_SERVER1管理対象サーバーが含まれたドメインの作成

この項では、Oracle Business Intelligence構成アシスタント、管理コンソールおよびOracle Enterprise Managerを使用して、ドメインと1つ目のWebLogic Server BI管理対象サーバーを作成する方法について説明します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

Oracleホーム・ディレクトリから構成アシスタントを実行して、BI Publisherが配置された管理対象サーバーおよび管理サーバーが含まれたドメインを作成します。

1. 構成アシスタントの場所にディレクトリを移動します。

APPHOST1> cd ORACLE_HOME/bin

2. 構成アシスタントを起動します。
UNIXの場合:

APPHOST1> ./config.sh

Windowsの場合:

APPHOST1> config.cmd

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

5. BIシステムの作成またはスケールアウト画面が表示されます。新規BIシステムの作成を選択して、次の値を指定します。

- ユーザー名: weblogic

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

- ドメイン名: bifoundation_domain

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

6. 「インストール場所の指定」画面で、次を入力します。

- MiddleWareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)

- Oracleホーム: ORACLE_BASE/product/fmw/Oracle_BI1(グレーアウトされています)

- WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3(グレーアウトされています)

- ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain

注意:

「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

- インスタンス・ホーム: ORACLE_BASE/product/fmw/instance1

- インスタンス名: instance1

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

7. 「コンポーネントの構成」画面で、Business Intelligence Publisherを選択します。
「次へ」をクリックします。

8. BIPLATFORMスキーマ画面で、次のように入力します。

- データベース・タイプ: Oracle Database

- 接続文字列: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM

- BIPLATFORMスキーマ・ユーザー名: BIHA_BIPLATFORM

- BIPLATFORMスキーマ・パスワード: BIPLATFORMスキーマ・ユーザーのパスワードを入力します。

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

9. 「ポートの構成」画面で、次のいずれかを選択します。

- 自動でポートを構成

- 構成ファイルを使用してポートを指定

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

10. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

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

12. 「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。

13. 完了画面で「終了」をクリックします。

15.2.3.5 APPHOST1での管理サーバーのboot.propertiesの作成

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。

1. 次のディレクトリに移動します。

ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/
AdminServer/security

2. 次の行をファイルに入力し、ファイルを保存してからエディタを閉じます。

username=Admin_username
password=Admin_password

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

15.2.3.6 APPHOST1での管理サーバーの起動と検証

この項では、APPHOST1で管理サーバーを起動および検証する手順について説明します。

15.2.3.6.1 APPHOST1での管理サーバーの起動

APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin
APPHOST1> ./startWebLogic.sh

15.2.3.6.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. ブラウザでhttp://APPHOST1:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. BI_SERVER1管理対象サーバーが表示されていることを確認します。

4. bi_clusterクラスタが表示されていることを確認します。

5. Enterprise Manager(http://APPHOST1:7001/em)にアクセスできることを確認します。

15.2.3.7 BI_SERVER1管理対象サーバーのリスニング・アドレスの設定

管理対象サーバーのリスニング・アドレスを設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で「bi_server1」を選択します。

6. リスニング・アドレスをAPPHOST1VHN1に設定します。

7. 「保存」をクリックします。

8. 変更を保存およびアクティブ化します。

変更内容は、BI_SERVER1管理対象サーバーが再起動されるまでは有効になりません。

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

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。

ホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で「bi_server1」を選択します。設定ページが開きます。

6. 「SSL」タブを開きます。

7. ページの「詳細」セクションを開きます。

8. 「ホスト名の検証」を「なし」に設定します。

9. 「保存」をクリックします。

10. 変更を保存およびアクティブ化します。

11. 変更内容は、BI_SERVER1管理対象サーバーが再起動されるまでは有効になりません。

15.2.3.9 APPHOST1でのシステムの起動

この項では、APPHOST1でノード・マネージャを起動する方法、およびAPPHOST1でBI_SERVER1管理対象サーバーを起動して検証する方法について説明します。

15.2.3.9.1 APPHOST1でのノード・マネージャの起動

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合、次のコマンドを使用してAPPHOST1で起動します。

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

15.2.3.9.2 BI_SERVER1管理対象サーバーの起動と検証

BI_SERVER1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は、次のとおりです。

1. 管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「制御」タブをクリックします。

4. 「bi_server1」を選択してから、「起動」をクリックします。

2. 管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。

3. BI_SERVER1が起動すると、次のURLが使用できるようになります。

- http://APPHOST1VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。

注意:

ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

- http://APPHOST1VHN1:9704/xmlpserverにアクセスして、BI Publisherアプリケーションのステータスを確認します。

15.2.3.10 APPHOST2でのBIシステムのスケール・アウトの前提条件

この項では、APPHOST2でBIシステムをスケール・アウトする前に、前提条件として実行するタスクについて説明します。

15.2.3.10.1 サーバー構成オプションの設定

サーバー構成オプションを構成するには、次の手順を実行します。

1. DOMAIN_HOME/config/bipublisher/repositoryの内容を構成フォルダの共有場所にコピーします。

2. 管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。

3. 「システム・メンテナンス」で「サーバー構成」を選択します。

4. 構成フォルダ用に次のフィールドを入力します。

- パス: 構成フォルダの共有場所のパスを入力します。

5. 変更を適用してから、BI Publisherアプリケーションを再起動します。

15.2.3.10.2スケジューラ構成オプションの設定

スケジューラ構成オプションを構成するには、次の手順を実行します。

1. 管理者の資格証明を使用してBI Publisherにログインして、「管理」タブを選択します。

2. 「システム・メンテナンス」で「スケジューラ構成」を選択します。

3. 「クォーツ・クラスタリング」を「スケジューラ選択」で選択します。

4. 変更を適用してから、BI Publisherアプリケーションを再起動します。

15.2.3.10.3 Oracle BI Publisher Schedulerの構成の更新

この項の手順に従って、Oracle BI Publisher SchedulerのWebLogic JNDI URLとJMS共有一時ディレクトリを更新します。

Oracle BI Publisher Schedulerの構成を更新する手順は次のとおりです。

1. 次のURLにアクセスして、いずれかのOracle BI Publisherインスタンスにログインします。

http://APPHOST1VHN1:9704/xmlpserver
http://APPHOST2VHN1:9704/xmlpserver

2. 「管理」リンクをクリックします。

3. 「スケジューラ構成」を「システム・メンテナンス」で選択します。

4. 次のようにして「WebLogic JNDI URL」を「JMS構成」で更新します。

t3://bi_cluster

5. 共有記憶域のあるディレクトリを入力して、「共有ディレクトリ」を更新します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。残りの手順を引き続き実行します。「適用」をクリックします。

6. スケジューラのステータスを「スケジューラ診断」タブでチェックします。

15.2.3.11 APPHOST2でのBIシステムのスケール・アウト

BIシステムをスケールアウトするには

1. 構成アシスタントの場所にディレクトリを移動します。

APPHOST2> cd ORACLE_HOME/bin

2. 構成アシスタントを起動します。

APPHOST2> ./config.sh

3. 「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。

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

5. BIシステムのスケールアウトを選択して、次の値を入力します。

- ホスト名: ADMINHOST

- ポート: 7001

- ユーザー名: weblogic

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

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

6. BIシステム詳細のスケールアウト画面で、次の値を入力します。

- MiddleWareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)

- Oracleホーム: Oracle_BI1(グレーアウトされています)

- WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3(グレーアウトされています)

- ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain

注意:

「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

- インスタンス・ホーム: ORACLE_BASE/product/fmw/instance2

- インスタンス名: instance2(グレーアウトされています)

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

7. 「ポートの構成」画面で、次のいずれかを選択します。

- 自動でポートを構成

- 構成ファイルを使用してポートを指定

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

8. 「セキュリティ更新の指定」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。「次へ」をクリックします。

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

10. すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。

11. 完了画面で「終了」をクリックします。

15.2.3.12 BI_SERVER2管理対象サーバーのリスニング・アドレスの設定

BI_SERVER2管理対象サーバー・リスニング・アドレスを設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で「bi_server2」を選択します。

6. リスニング・アドレスをAPPHOST2VHN1に設定します。「保存」をクリックします。

7. 変更を保存およびアクティブ化します。

この変更は、BI_SERVER2管理対象サーバーを再起動したときに有効になります。

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

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。

ホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。「サーバー」をクリックします。

4. 表の「名前」列で「bi_server2」を選択します。「SSL」タブを開きます。

5. ページの「詳細」セクションを開きます。

6. 「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。

7. 変更を保存およびアクティブ化します。

この変更は、BI_SERVER2管理対象サーバーを再起動すると有効になります。

15.2.3.14 Oracle BI Publisherの構成

この項では、Oracle BI Publisherを構成する方法を説明します。

15.2.3.14.1 BI Publisher用のJMS永続ストアの構成

両方のノードから参照できるディレクトリに、すべての永続ストアの場所を構成する必要があります。そして、この共有のベース・ディレクトリを使用するように、すべての永続ストアを変更します。

注意:

JMSメッセージ、トランザクション・ログおよびファイル・ストアでのロックの解放に関する重要な情報は、「NFSでのファイル・ストアの使用に関する考慮事項」を参照してください。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。

3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

4. 「BipJmsStore」をクリックして、共有記憶域にあるディレクトリを入力します。この共有記憶域には、APPHOST1およびAPPHOST2の両方からアクセスできます。

ORACLE_BASE/admin/domain_name/bi_cluster/jms

5. 「保存」→「変更のアクティブ化」をクリックします。

6. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。

7. 「チェンジ・センター」で、「ロックして編集」をクリックします。

8. 「新規」をクリックしてから、「ファイル・ストアの作成」をクリックします。

9. 名前(例: BipJmsStore2)を入力し、BI_SERVER2をターゲットにします。APPHOST1とAPPHOST2の両方からアクセスできるように、共有記憶域にあるディレクトリを入力します。

ORACLE_BASE/admin/domain_name/bi_cluster/jms

10. 「OK」をクリックして、変更をアクティブ化します。

11. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSサーバー」ノードをクリックします。「JMSサーバーのサマリー」ページが表示されます。

12. 「チェンジ・センター」で、「ロックして編集」をクリックします。

13. 新規をクリックします。

14. 名前(例: BipJmsServer2)を入力してから「永続ストア」ドロップダウン・リストで「BipJmsStore2」を選択し、「次へ」をクリックします。

15. 「BI_SERVER2」をターゲットとして選択します。

16. 「終了」→「変更のアクティブ化」をクリックします。

17. 「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「メッセージング」→「JMSモジュール」ノードをクリックします。

18. 「チェンジ・センター」で、「ロックして編集」をクリックします。

19. 「BIPJmsResource」→「サブデプロイメント」タブをクリックします。

20. 「サブデプロイメント」の「BipJmsSubDeployment」のターゲットを、BipJmsServer1とBipJmsServer2の両方にします。

21. 「終了」→「変更のアクティブ化」をクリックします。

Oracle BI Publisherに対して実行したJMS構成を検証するには、第15.2.3.10.3項「Oracle BI Publisher Schedulerの構成の更新」の手順を実行してください。

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

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。

BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

3. 表の「名前」列で、BI_SERVER1をクリックします。

4. 「サービス」タブをクリックします。「チェンジ・センター」で、「ロックして編集」をクリックします。

5. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。そのパス・ディレクトリ構造は次のとおりです。

ORACLE_BASE/admin/domain_name/bi_cluster/tlogs

6. 「保存」→「変更のアクティブ化」をクリックします。

7. BI_SERVER2サーバーに対してこれらの手順を繰り返します。

注意:

トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。

15.2.3.15 APPHOST2でのシステムの起動

この項では、APPHOST2でシステムを起動する手順について説明します。

15.2.3.15.1 APPHOST2でのノード・マネージャの起動

通常、ノード・マネージャはconfig.shの完了時に自動的に起動されます。ノード・マネージャが実行されていない場合、これをAPPHOST2で起動します。第15.2.3.9.1項「APPHOST1でのノード・マネージャの起動」にある手順を参照してください。

15.2.3.15.2 BI_SERVER2管理対象サーバーの起動と検証

BI_SERVER2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は、次のとおりです。

1. 管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

2. 「サーバー」を選択します。「制御」タブをクリックします。

3. 「bi_server2」を選択してから、「起動」をクリックします。

2. サーバーのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。その他のもの(AdminやFailedなど)が表示されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。

3. BI_SERVER2が起動すると、次のURLが使用できるようになります。

- http://APPHOST2VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。

注意:

ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

- http://APPHOST2VHN1:9704/xmlpserverにアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。

15.2.3.16 BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成

BI_SERVERn管理対象サーバーを含むbi_clusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

1. WEBHOST1およびWEBHOST2で、ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# BI Publisher
<Location /xmlpserver>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

2. WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。

3. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

15.2.3.17 Oracle HTTP Serverを使用したアクセスの検証

BI Serverのステータスが「実行中」であることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。その他のもの(AdminやFailedなど)が表示されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。

次のURLにアクセスできることを確認します。

- http://WEBHOST1:7777/wsm-pm

- http://WEBHOST2:7777/wsm-pm

- http://WEBHOST1:7777/xmlpserver

- http://WEBHOST2:7777/xmlpserver

ロード・バランシング・ルーター・アドレスを使用して、次のURLにアクセスできることを確認します。

- http://bi.mycompany.com:80/xmlpserver

- http://bi.mycompany.com:80/wsm-pm

HTTP Serverからbi_clusterへのルーティングとフェイルオーバーが適切に機能していることを確認する手順は、次のとおりです。

1. BI_SERVER2の実行中に、管理コンソールからBI_SERVER1を停止します。

2. 次のURLにアクセスして、適切な機能を検証します。

- WEBHOST1:7777/wsm-pm

- WEBHOST1:7777/xmlpserver

3. 管理コンソールから、BI_SERVER1を開始します。

4. BI_SERVER2を停止します。

5. 前述のステップ2のURLにアクセスして、適切な機能を検証します。

15.2.3.18 BI_SERVERnサーバーのサーバー移行の構成

この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を構成する必要があります。これを行うには、第15.1.13.22項「BI_SERVERnサーバーのサーバー移行の構成」の指示に従ってください。

15.2.3.19 新しいノード(APPHOST3)へのOracle BI Publisherトポロジのスケール・アウト

Oracle BI Publisherトポロジをスケール・アウトする際は、トポロジ内の新しいノード(APPHOST3)に、新しい管理対象サーバーとシステム・コンポーネント・セットを追加します。この項では、ノードが2つ以上あり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがある高可用性トポロジを前提にします。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

- Oracle BI Publisherの管理対象サーバーが稼働している既存ノードがトポロジ内に存在する必要があります。

- 新しいノード(APPHOST3)が、Oracle WebLogic ServerとOracle Business Intelligence用の既存のホーム・ディレクトリにアクセスできます。

- ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、MW_HOME/.homeファイルを編集します。次の手順を参照してください。

- 新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。

APPHOST3でBI Publisherをスケール・アウトする手順は次のとおりです。

1. APPHOST3で、Oracle Business Intelligenceのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>

Middlewareホーム・リストを更新するには、MW_HOME/.homeファイルを作成して(別のWebLogicインストールがノード内に存在する場合はそれを編集して)、それにORACLE_BASE/product/fmwを追加します。

3. VIP3をAPPHOST3で有効にします。第15.2.3.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。

4. 第15.2.3.11項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームから構成アシスタントを実行します。

5. 第15.2.3.12項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第15.2.3.13項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名検証を無効にすることで、bi_server3管理対象サーバーを構成します。

6. 第15.2.3.14.1項「BI Publisher用のJMS永続ストアの構成」の説明に従って、Oracle BI Publisher用のJMSを構成します。

7. 第15.2.3.14.2項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。

8. 第15.2.3.16項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。

9. APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第15.2.3.9.2項「BI_SERVER1管理対象サーバーの起動と検証」を参照してください。

10. 第8.9.3.11.5項「サーバー移行ターゲットの構成」および第15.1.13.22.6項「サーバー移行のテスト」の説明に従って、サーバー移行を構成します。

11. 構成を検証するには、http://APPHOST3VHN1:9704/xmlpserverというURLにアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。

12. ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信には、それぞれのアドレス用の証明書が必要です。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の「ノード・マネージャの設定」を参照してください。

15.3 Oracle Real-Time Decisionsの高可用性

Oracle Real-Time Decisions(Oracle RTD)を使用すると、選択元となる最善の選択肢について意思決定するための十分なコンテキストに基づいて、リクエストのオファーまたは選択肢のランク付きリストを提供できます。Oracle RTDでは常にフロントエンド・アプリケーションが使用されます。このアプリケーションの役割は、プロセス・フローを定義し、ユーザー操作を取得し、この操作をOracle RTDによる意思決定のための入力情報として解釈することです。したがってOracle RTDは、従来のWebアプリケーションというよりはむしろ意思決定サービスと見なすことができます。

この項では、Oracle RTDの高可用性環境を設計およびデプロイする方法を説明します。

この項の項目は次のとおりです。

- 第15.3.1項「Oracle RTDのコンポーネント・アーキテクチャ」

- 第15.3.2項「Oracle RTDの高可用性の概要」

- 第15.3.3項「Oracle RTDの高可用性の構成手順」

15.3.1 Oracle RTDのコンポーネント・アーキテクチャ

図15-12では、Oracle RTDの単一インスタンス・アーキテクチャでの主要なコンポーネントを示しています。

図15-12 Oracle RTDの単一インスタンス・アーキテクチャ

「図15-12 Oracle RTDの単一インスタンス・アーキテクチャ」の説明

図15-12には、次のコンポーネントが示されています。

- Decision Server: インライン・サービスと呼ばれるOracle RTDアプリケーションを実行するためのランタイム・サービスを提供します。
Decision Serverとインライン・サービスの詳細は、「Decision Server」を参照してください。

- バッチ・サービス: バッチ・マネージャとバッチ・エージェントが含まれます。バッチ・サービスの役割は、バッチ・ジョブを実行するためのリクエストを処理することです。
バッチ・サービスの詳細は、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドの「Oracle RTDバッチ・フレームワーク」を参照してください。

- Decision Center: このWebベースのUIを使用して、ビジネス・ユーザーは、自身の分析モデルの有効性に関するレポートを表示したり、自身のホストしているインライン・サービスをチューニングします。
Decision Centerの詳細は、「Decision Center」を参照してください。

- 学習サービス: Oracle RTDデータベースから学習レコードを読み取り、新しい予測モデルを定期的に生成します。
学習サービスの詳細は、「学習サービス」を参照してください。

Decision Server

Decision Serverは、インライン・サービスと呼ばれるOracle RTDアプリケーションを実行するために必要なランタイム・サービスを提供します。インライン・サービスは、Decision Studio開発環境を使用して開発され、Oracle RTD Decision Serverにデプロイされて実行されます。Decision Studioの詳細は、「Decision Studio、RTDクライアントおよびツール」を参照してください。

インライン・サービスは、リアルタイムかつ継続的に、エンタープライズ・ビジネス・プロセスのデータを収集して、これらのプロセスの特性を分析できます。また、これらのデータと分析結果を利用して、意思決定機能と、主要なビジネス・プロセスに対するフィードバックも提供できます。

Decision Serverのすべてのメタデータは、Oracle RTDデータベースに保管されます。

インライン・サービスの次の要素は、高可用性トポロジで特定の役割を果たすとともに、高可用性トポロジによる影響を受けます(主にOracle RTDの外部のリソースにアクセスすることで)。

1. 選択肢: 選択肢は、インライン・サービスを通じて提示されるオファー、またはOracle RTDの自己学習モデルによって追跡される調査ターゲットを表します。選択肢には、静的と動的という2つの形式があります。静的選択肢は、Decision Studioを使用してハードコーディングされます。動的選択肢は、外部データ・ソースで定義されて、インライン・サービスの実行時にロードされます。

2. ルール: ルールを使用して、移入のセグメントのターゲットを設定したり、選択肢が適格であるかどうか判断したり、特定の選択肢を評価したりします。ルールは、グラフィカルなルール・エディタを使用して作成されます。ルールは、インライン・サービスの実行時にDecision Serverによってロードされます。Oracle RTDには、外部ルールと呼ばれるルールのタイプがあります。これらのルールは、Oracle RTDの外部のデータ・ソースに保管されます。

3. エンティティ: エンティティは、Oracle RTDのモデリングと意思決定に使用されるデータの論理表現です。エンティティの属性は、統合点からの受信パラメータとしてデータ・ソースを介して入力することも、カスタム・ロジックを通じてリアルタイムに導出することもできます。

4. データ・ソース: データ・ソースは、表やストアード・プロシージャからデータを取得します。

5. 統合点: 統合点は、Oracle RTDと連携動作する外部システムとの接点の役割を果たします。統合点には、インフォーマントとアドバイザという2種類があります。インフォーマントは外部システムからデータを受信するのに対して、アドバイザはデータを受信して外部システムに推奨情報を送信します。

6. モデル: 予測と報告という2つの主な役割を果たします。モデルは、次を目的として定義されます。

- 選択肢に付随する特定のイベントが発生する可能性を予測します。

- これらのイベントと相関付けられたデータを分析します。

統計コレクタは、エンティティに関する統計を追跡する特別なモデルです。

モデルは、設計時に選択肢グループと関連付けられます。これにより、予測とレポートが適用される選択肢のリストが定義されます。

Decision Center

ワークベンチ・サービスは、Decision Serverによるインライン・サービスのデプロイメントをサポートするとともに、Decision CenterのWebインタフェースを提供します。Decision Centerでは、インライン・サービスの構造と意思決定履歴が表示されます。ビジネス・ユーザーはDecision Centerを使用して、自身の分析モデルの有効性に関するレポートを表示したり、自身のホストしているインライン・サービスをチューニングできます。

Decision CenterはLearning Serverと連携して、学習モデルのコンテンツについて問い合せます。

学習サービス

インライン・サービス・セッションの終了時に、学習レコードが作成されます。学習レコードは、メモリー(構成可能)内でバッチ処理されて、Oracle RTDデータベースに保管されるためにキューに格納されます。これはパフォーマンス上の理由のために実行されます。これにより、学習レコードをOracle RTDデータベースに保管するために必要なデータベース・トランザクションの数が最小限に抑えられます。デフォルトでは、Oracle RTDは、50個のバッファ用の1つのキューを使用して、100件のレコードをバッファに格納します。ワーカー・スレッドによって、学習レコードがOracle RTDデータベースに書き込まれます。

学習サービスは休止状態から定期的に復帰して、次の操作を実行します。

- 学習レコードをデータベースから読み取ります。

- 新しい予測モデルを生成します。

各予測モデルは、特定のインライン・サービスと関連付けられています。したがって、インライン・サービスが影響を受けるのは、そのインライン・サービスが新しい予測モデルを持つときのみです。すべてのインライン・サービスは、別のインライン・サービスのモデルに対する更新から分離されています。

予測モデルは、Decision Serverに伝播されます。各Decision Serverは、Oracle RTDデータベースを頻繁にポーリングして、新しい予測モデルの有無を確認します。新しい予測モデルが見つかると、その予測モデルはメモリーにロードされます。

Decision Studio、RTDクライアントおよびツール

Decision Studioは、Oracle RTDのインライン・サービスを開発するためのEclipseベースの開発環境です。

Decision Studioを使用すると、Oracle RTDワークベンチ・サービスのWebサービスを介して、Oracle RTD Serverからインライン・サービスをダウンロードしてデプロイすることもできます。

Oracle RTDは、Oracle RTD Decision Serverとの簡単な統合を可能にするいくつかのクライアント・コンポーネントを提供します。たとえば、Oracle RTDが提供するJavaクライアントは、Oracle RTDのWebサービス・コールのラッパーを提供したり、デフォルトの結果セットをクライアント側のキャッシュに格納したり、Oracle RTD Serverが応答しないときにデフォルトのレスポンスを提供したりします。

Oracle RTDクライアント・ツールの詳細は、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドを参照してください。

Oracle RTDの管理

Oracle Enterprise Manager Fusion Middleware Controlは、Oracle RTDの単一インスタンスとクラスタ全体の属性を構成するために使用されます。

15.3.1.1 Oracle RTDコンポーネントの特性

この項では、Oracle RTDのコンポーネントの特性を説明します。

Oracle RTD Serverとそのコンポーネントは、JavaまたはWebベースのコンポーネントです。これらは、JavaコンテナまたはWebコンテナ内で実行されます。Oracle RTD Serverに接続されたOracle RTDクライアントとDecision Studioの間の通信は、いくつかのWebサービスを介して行われます。

Oracle RTDはセッション情報をローカルで管理するため、Webサーバーにセッション管理に依存しません。その理由は、Oracle RTDは、Webアプリケーションに関連付けられた一般的なセッションではなく、ビジネス・プロセスを完了するために長時間のセッションを必要とするからです。単一のDecision Serverセッションは、それぞれ異なるクライアント・サーバーを起点とする複数のHTTPセッションからリクエストを受信することがあります。Oracle RTDのセッションは短時間で終了する場合も、数時間、数日または数週間にわたって継続する場合もあります。

サーバーで障害が発生した場合は、リクエストは別のサーバーに転送されて、新しいセッションが作成されます。ほとんどの場合、セッション情報は外部データ・ソースから読み取られるか計算されます。これらの値は、新しいセッションで再び読み取られるか再び計算されます。Oracle RTDは可能性を計算するためにセッション情報を使用するのであり、ビジネス・トランザクションの状態を保管するためではありません(後者はトランザクション/運用システムに委ねられています)。したがって、セッション情報が失われてもビジネス・プロセスに悪影響は及ぼされません。

15.3.1.1.1 コンポーネントのライフサイクル

Oracle RTDは、Oracle Enterprise Manager Fusion Middleware Controlを介して管理されます。Fusion Middleware Controlを使用して、Oracle RTDのサービスを起動、停止、アンデプロイ、デプロイおよび監視します。

15.3.1.1.2 プロセス・フロー

Oracle RTDのプロセス・フローは次のとおりです。

1. 外部アプリケーションからOracle RTDの統合点に対してコールが発行されます。

2. このリクエストは、Oracle RTDの意思決定サービスのWebサービスに送信されます。このサービスはOracle Web Services Managerによって認証されてから、このリクエストを処理します。

3. このリクエストは、ターゲットとして設定されたインライン・サービスと、そのインライン・サービス内のターゲット・インフォーマントまたはターゲット・アドバイザに転送されます。

4. インフォーマントの処理に含まれるのは、ルールの実行、関数の実行、エンティティへのアクセスおよび学習レコードの作成です。

5. アドバイザの処理に含まれるのは、意思決定の実行、ルールの実行、適格性に関する関数の実行(フィルタリング)、エンティティへのアクセスおよび適格な選択肢のリストの返送です。

15.3.1.1.3 外部依存性

Oracle RTDの構成情報は自己完結型で、固有のデータベース・スキーマに格納されます。ただしインライン・サービスは、そのエンティティや外部ルールを外部データ・ソースからロードできます。

15.3.1.1.4 構成アーティファクト

構成情報はOracle RTDデータベースに保管され、Fusion Middleware Controlを使用して更新されます。

データ・ソースの構成情報は、管理コンソールを使用して設定されます。

15.3.1.1.5 デプロイメント・アーティファクト

Oracle RTDのインライン・サービス は、Decision Studioで作成されます。開発者は、Decision Studioのデプロイメント機能を使用してインライン・サービスをデプロイします。インライン・サービスはOracle RTD Studioによってパッケージ化されて、Decision Serverのインスタンスにアップロードされます。Decision Serverは、すべてのアップロードされたインライン・サービスをOracle RTDの運用表に保管します。

15.3.1.1.6 ログ・ファイルの場所

Oracle RTDログ・ファイルは、Oracle Enterprise Manager Fusion Middleware Controlを使用して表示できます。Oracle RTDホーム・ページからログ・ファイルを表示するには、ナビゲータ・ペインでデプロイ済Oracle RTDアプリケーションを右クリックし、「ログ」→「ログ・ファイルの表示」を選択します。これにより、「ログ・メッセージ」画面が表示され、そこでログ・ファイルを表示できます。Oracle RTDログ・ファイルの表示の詳細は、Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイドを参照してください。

15.3.2 Oracle RTDの高可用性の概要

この項では、Oracle RTDを高可用性デプロイメントで使用する場合の概要について説明します。

15.3.2.1 Oracle RTDの高可用性アーキテクチャ

図15-13は、Oracle RTDの高可用性アクティブ/アクティブ・アーキテクチャを示しています。

図15-13 Oracle RTDの高可用性アーキテクチャ

「図15-13 Oracle RTDの高可用性アーキテクチャ」の説明

図15-13では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。

Oracle WebLogic Serverは、アプリケーション層のAPPHOST1およびAPPHOST2にインストールされます。第3章「WebLogic Serverの高可用性」で説明されているように、APPHOST1が使用できなくなった場合、APPHOST2で管理サーバーをアクティブにできます。Oracle RTDは、これらのホストのBI_SERVER1およびBI_SERVER2管理対象サーバーでデプロイされます。これらの管理対象サーバーはアクティブ/アクティブ的に動作できるように、Oracle WebLogicクラスタにおいて構成されます。

データ層では、Oracle RACデータベースはOracle RTDリポジトリ用に使用されますが、エンタープライズ・データベース用としてもお薦めします。Oracle RTDリポジトリには、学習モデル、学習レコード、予測モデルおよびインライン・サービスのメタデータが保管されます。

注意:

Web層のかわりにロード・バランサを直接のフロントエンドとして使用したOracle RTDインスタンスのクラスタもサポートされています。このタイプのデプロイメントでは、ロード・バランサは、HTTPヘッダーを使用したスティッキー・セッションのルーティングを実現できるように構成される必要があります。HTTPヘッダーを使用したスティッキー・セッションのルーティングを実現できるようにするための構成については、お使いのロード・バランサのドキュメントを参照してください。

このタイプのデプロイメントのOracle RTDクラスタにアクセスするクライアントは、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドのJavaスマートクライアントに関する項に指定された要件を満たす必要があります。クライアントのセット・アップ例は、Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイドの「Javaスマート・クライアントの使用方法」を参照してください。

Oracle RTDクラスタの考慮事項

クラスタ化インストールでは、RTDコンポーネントのインスタンスは、同じホスト上またはリモート・ホスト上にある他のRTDコンポーネントと通信する必要があります。それらのコンポーネントが同じホスト上にない場合は、内部リモート・プロシージャ・コール(RPC)メカニズムを使用してクラスタ・ホスト間で通信し、レスポンスを伝達します。

クラスタ内では、Decision Centerは、学習サービスと通信する必要があるため、通常は学習サービスと同じOracle RTDインスタンスにデプロイされます。ただし、Decision Centerはシングルトンではないため、アクティブな学習サービスとは異なる場所に配置されたインスタンスは、RPCを使用してアクティブな学習サービスと通信します。

クラスタ内では、Decision Centerは通常は意思決定サービスとは異なるOracle RTDインスタンスにデプロイされることで、Decision Centerがパフォーマンスとメモリーの面で意思決定サービスに与える影響が最小限に抑えられます。

クラスタ内では、非クラスタ化インストールで使用されるのと同じ内部WorkBench Webサービスを使用して、インライン・サービスがDecision Studioによって任意のクラスタ・メンバーにデプロイされます。Decision Studioが接続されているインスタンスは、インライン・サービスをメモリーにロードして、データベースに保存します。他のクラスタ・メンバーは、データベース内の新しいインライン・サービスを検知して、このインライン・サービスを各自のメモリーにロードします。

パフォーマンス上の理由から、HTTPセッション・アフィニティが有効になっているクラスタにOracle RTDをデプロイすることが最適です。その理由は、正確な学習レコードの作成と予測のためには、Oracle RTDセッションのコンテキストが必要だからです。セッション内には、学習に寄与できる動的状態が存在しますが(このDecision Serverセッションでアクセスされる一連のWebページの順序など)、この動的状態はデータベースからは取得されません。この状態は学習に寄与しますが、それは集約された形のみになります。個人の状態や、複数のサーバーにまたがって複製されるほど重要な状態は存在しません(その状態がシリアライズ可能であった場合でも同様です)。サーバーの障害が原因でいくつかのセッションが失われた場合でも、集約された情報に基づいているOracle RTDの学習モデルの整合性は目立った影響を受けません。

クラスタ内の各Decision Serverインスタンスは、Oracle RTDの運用表をポーリングして、新しいインライン・サービスや更新されたインライン・サービスの有無を確認します。新しいインライン・サービスや更新されたインライン・サービスが見つかった場合は、そのインライン・サービスはクラスタのすべてのメンバーによってメモリーにロードされます。

Oracle RTDでは、ハードウェアまたはソフトウェアのロード・バランサが使用されます。

Webサービス・リクエストにセッション鍵を挿入できます。セッション鍵はユーザーによって定義され、パラメータとしてOracle RTD Javaクライアント(Oracle RTD Webサービスに対するラッパー)に渡されます。ロード・バランサは、セッション・アフィニティを有効にするように構成される必要があるとともに、セッション鍵をHTTPヘッダーから取得するように構成される必要があります。

Oracle RTDインスタンス間のクラスタ・メンバー内通信は、その内部のクラスタ内RPCテクノロジを通じて行われます。JMSの公開/サブスクライブ・モデルは、Oracle RTDデプロイメントで作成される「RTDTopic」という単一トピックとともに使用されます(Oracle RTDのWebLogicテンプレートで定義されます)。各Oracle RTDインスタンスは、この単一トピックにサブスクライブして、各インスタンスに該当するメッセージを読み取ります(フィルタリングを介して)。

Oracle RTD Serverは、セッション状態が不明なリクエストを受信することがあります。この場合は、リクエストを受信したDecision Serverは検索を実行して、このリクエストの本来の宛先であるDecision Serverを探します。その後、このリクエストは正しいDecision Serverに転送されます。転送側のDecision Serverは、このリクエストが受信側のDecision Serverによって完了されるのを待ちます。

転送されるリクエストは、RPCを介して送信されます。各Oracle RTD Serverは、各自に該当するすべてのメッセージをOracle RTD JMSトピックから取得します。

受信側のDecision Serverがリクエストを完了したら、コールはアンワインドされ、リクエストの転送元は、受信側のDecision Serverからレスポンスを受け取ります。このレスポンスはコール元に返送されます。

シングルトン・サービス

図15-13では、Oracle RTDの学習サービスとバッチ・マネージャはシングルトンです。学習サービスの役割は、1つ以上のOracle RTD意思決定サービス・インスタンスによって書き込まれたデータ・レコードから分析モデルを構築することです。分析モデルは、一連の入力値に基づいて、特定の結果が生じる可能性を提示します。たとえば分析モデルは、過去に購入された製品の履歴に基づいて、顧客が特定の製品を購入する可能性がどれだけあるのかを算定できます。学習モデルはメモリー内で構築されます。モデルの構築中にアクティブな学習サービスで障害が発生した場合は、新しい学習サービスがアクティブ化されて、データが失われることなくモデルを最初から構築します。バッチ・マネージャの役割は、バッチ管理クライアントのかわりにバッチ・ジョブを開始および管理することです。これは、他のOracle RTDインスタンス上のバッチ・エージェント・インスタンスと通信して、作業をクラスタ全体にわたって分散します。学習サービスとバッチ・マネージャはどちらも、アクティブ/スペア・シングルトンと見なされます。

クラスタ・コーディネータ

Oracle RTDには、次のタスクを実行する独自のクラスタ・コーディネータがあります。

- 学習サービス・シングルトンとバッチ・マネージャ・シングルトンという各タイプについて、ちょうど1つのシングルトンがアクティブになるようにします。クラスタ・シングルトンを起動または停止するのは、クラスタ・コーディネータだけです。

- クラスタ・コーディネータは、クラスタを離れるメンバーによって開いた状態のまま放置されたリソースをクリーンアップします(このクリーンアップ・ロジックは、制御された手順に従ってノードが停止されるときに、そのノードが自身に対して通常実行するものと同じです)。コーディネータがこのクリーンアップを実行するのは、クラスタを離れようとしているノードが突然動作しなくなったために、そのノード自体のリソースを閉じることができなかった場合です。たとえば、クラスタ・メンバーによってホストされているすべてのDecision Centerセッションは、そのクラスタ・メンバーがクラスタを離れるときにコーディネータによって閉じられます。

各Oracle RTDクラスタ・メンバーは、その起動時に、クラスタ・コーディネータになろうとして競合します。そのために、データベースをトランザクション方式でテストして、別のインスタンスがすでにコーディネータになっているかどうかを確認し、他のコーディネータが存在しない場合は自身をコーディネータとしてデータベースに挿入します。コーディネータになるための権限は、そのコーディネータ自身によって定期的に更新されないと失効するため、コーディネータが動作不能になると、他のいずれかのクラスタ・メンバーがコーディネータになります。

15.3.2.1.1 クラスタの起動と停止

管理コンソールを使用して、Oracle RTDクラスタ内の単一インスタンスを起動および停止できます。

15.3.2.1.2 クラスタワイドの構成変更

Oracle RTDの構成情報は自己完結型で、固有のデータベース・スキーマに格納されます。これは、Oracle Enterprise Manager Fusion Middleware Controlを使用して更新できます。

Oracle RTDクラスタ内の1つのインスタンスの構成を変更した場合は、Oracle Enterprise Manager Fusion Middleware Controlで「適用」ボタンをクリックした後に、他のインスタンスがそれらの構成変更内容を取得します。

15.3.2.2 障害からの保護および予想される動作

各クラスタ・メンバーで動作しているOracle RTDトポロジ管理レイヤーは、データベース内の自身のハートビート・レコードを更新しなくなったクラスタ・メンバーを検知します。管理対象サーバー内の個別サービスの障害が発生しているかどうかは確認しません。このため、この項で説明する障害シナリオは、個別サービスの障害ではなく管理対象サーバーの障害を対象にしています。

15.3.2.2.1 Decision Serverの障害

Decision Serverで障害が発生した場合は、次のようになります。

- Decision Serverと関連付けられたOracle RTDセッションは、それらのステートフル情報とともに失われます。

- ロード・バランサは、障害が発生したサーバーを本来の宛先としていたリクエストを別のサーバーに転送します。

- これらのリクエストを受信したサーバーは、新しいOracle RTDセッションを作成して、セッション・レベル・エンティティを適切なデータ・ソースからハイドレートして、そのリクエストに対応します。

学習レコードは、データベースに頻繁に書き込まれます。学習レコードは統計目的に使用されます。Decision Serverで障害が発生した場合は、次のようになります。

- 永続化されていない学習レコードはすべて失われます。

- Oracle RTDは、特定の顧客の情報やアカウント情報などのトランザクション・データを一切保管しません。したがって、多数の学習レコードがすでに学習元として使用済であり、予測モデルが収束済の場合は、一部のデータが失われても重大な問題にはならず、可能性の計算は大きな影響を受けないため、Oracle RTDインフォーマントによって返されるオファーも大きな影響を受けません。

15.3.2.2.2 クラスタ・コーディネータの障害

障害が発生したサーバーがクラスタ・コーディネータである場合は、次のようになります。

- Oracle RTDデータベース内のタイムスタンプを更新しなくなります。

- データベース表をポーリングしている他のサーバーは、タイムスタンプが無効になったこと、およびクラスタ・コーディネータで問題が発生している可能性があることを検知します。

- すべてのアクティブなOracle RTDインスタンスは、新しいクラスタ・コーディネータになろうとして競合します。

15.3.2.2.3 学習サービスの障害

学習モデルはメモリー内で構築されます。

モデルの構築中にアクティブな学習サービスで障害が発生した場合は、新しい学習サービスがアクティブ化されて、データが失われることなくモデルを最初から構築します。

アクティブな学習サービスが配置されたノードで障害が発生した場合は、クラスタ・コーディネータは、残りのクラスタ・ノード(学習サービスがデプロイおよび有効化されているノード)のいずれかで学習サービスをアクティブ化します。そのために、クラスタ・コーディネータは、クラスタ内RPCを介してOracle RTDインスタンスにコマンドを送信します。

15.3.2.2.4 Decision Centerの障害

Decision Centerで障害が発生した場合は、進行途中のユーザー作業のうち、保存されていなかった作業の内容はすべて失われます。たとえば、保存されていなかったルールの更新内容やパフォーマンス目標の変更内容が失われます。

1つのクラスタ内で複数のDecision Centerが実行されているため、ユーザーはアクティブなDecision Centerに接続されます。

15.3.2.2.5 バッチ・マネージャの障害

アクティブなバッチ・マネージャが配置されたノードで障害が発生した場合は、クラスタ・コーディネータは、残りのノード(バッチ・マネージャがデプロイおよび有効化されているノード)のいずれかでバッチ・マネージャをアクティブ化します。

クラスタのバッチ・マネージャ・シングルトンで障害が発生した場合は、クラスタ・コーディネータはその障害を検知して、異なるホストで別のバッチ・マネージャを起動します。すべてのバッチ・エージェントには新しいバッチ・マネージャの存在が通知され、これらのバッチ・エージェントは自身をその新しいバッチ・マネージャに登録します。

バッチ・ジョブを実行しているノードで障害が発生した場合は、次のようになります。

- 障害が発生したサーバー上のバッチ・ジョブのみが処理を停止します。

- 障害が発生したノード上で実行されていたバッチ・ジョブはすべて中断状態になります。これらのバッチ・ジョブを手動で再開するには、バッチ・コンソールまたは他のバッチ管理クライアントを使用してバッチ・マネージャに対して再開コマンドを発行します。

- 中断されたジョブが再開されるときは、その状態がバッチ・マネージャと最後に同期された箇所から再開されます。バッチ・マネージャがジョブの再開を要求されると、バッチ・マネージャによって選択された使用可能なバッチ・エージェント上で、そのジョブが再開されます。

15.3.3 Oracle RTDの高可用性の構成手順

この項では、Oracle Real-Time Decisionsの2ノードの高可用性構成を設定する方法を説明します。この構成手順を対象としたアーキテクチャを図15-13に示しています。

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

15.3.3.1 Oracle RTDの高可用性構成の設定前に必要な手順

この項では、Oracle RTDの高可用性構成を設定するための前提条件について説明します。

15.3.3.1.1 データベースに関する前提条件

Oracle RTDでサポートしているデータベースのバージョンは次のとおりです。

- Oracle Database 10g(非XEデータベースについては10.2.0.4以上)

- Oracle Database 11g(非XEデータベースについて11.1.0.7以上)

データベースのバージョンを調べるには、次の問合せを実行します。

SQL>select version from sys.product_component_version where product like 'Oracle%';

15.3.3.1.2 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Clusterwareインストレーション・ガイドを参照してください。

自動ストレージ管理

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

- 10g リリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

- 11g リリース1(11.1)以降については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをOracle Real Application Clusters(Oracle RAC)データベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g (11.1.1.)Oracle Fusion Middleware RepositoryをOracle RACデータベースにインストールしてください。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

15.3.3.1.3 RCUを使用したデータベースへのBusiness Intelligenceスキーマのロード

Oracle RTDをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとOracle BIスキーマをOracle RACデータベースにインストールします。次の手順を実行します。

1. リポジトリ作成ユーティリティ(RCU)のDVDを挿入してから、RCUホーム・ディレクトリのbinディレクトリでRCUを起動します。

prompt> cd RCU_HOME/bin
prompt> ./rcu

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。

4. 「データベース接続の詳細」画面で、データベースの接続情報を入力します。

- データベース・タイプ: Oracle Databaseを選択します。

- ホスト名: データベースが存在しているノードの名前を指定します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを次のように指定します:
BIDBHOST1-VIP

- ポート: データベースのリスニング・ポート番号である1521を指定します。

- サービス名: データベースのサービス名を指定します。
biha.mycompany.com

- ユーザー名: DBA権限またはSYSDBA権限のあるユーザーの名前(SYS)を指定します。

- パスワード: SYSユーザーのパスワードを入力します。

- ロール: データベース・ユーザーのロール(SYSDBA)をリストで選択します(SYSユーザーに必要)。

「次へ」をクリックします。

5. 「コンポーネントの選択」画面で、次を行います。

- 「接頭辞の新規作成」を選択し、BIHAのように、データベース・スキーマに使用する接頭辞を入力します。6文字まで接頭辞として指定できます。接頭辞を使用して、複数リポジトリの論理グルーピングをデータベースにおいて作成します。詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

ヒント:

このスキーマの名前をメモに記録してください。後述する手順でこの情報が必要になります。

- 次のコンポーネントを選択します。

o  AS Common Schemas: Metadata Services (automatically selected)
o  Oracle Business Intelligence: Business Intelligence Platform

「次へ」をクリックします。

6. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
要件に応じて、「すべてのスキーマに同じパスワードを使用」または「すべてのスキーマに異なるパスワードを指定」を選択できます。

「補助スキーマにメイン・スキーマのパスワードを使用」は選択しないでください。補助パスワードは、主要なスキーマ・ユーザーのパスワードから導出します。

ヒント:

スキーマ・パスワードの名前をメモに記録してください。後述する手順でこの情報が必要になります。

7. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

8. 「サマリー」画面で「作成」をクリックします。

9. 「完了サマリー」画面で「閉じる」をクリックします。

15.3.3.1.4 ロード・バランサの仮想サーバー名とポートの構成

この項では、Oracle RTDの高可用性環境をデプロイするためのロード・バランサの前提条件について説明します。

ロード・バランサ

Oracle RTDは、2つのOracle HTTP ServerがWeb層コンポーネントとして使用された高可用性構成でデプロイされた場合は、ハードウェア・ロード・バランサを使用します。

仮想サーバー名

bi.mycompany.comは、Oracle RTDなどのランタイムBIコンポーネント宛てのすべてのHTTPトラフィックのアクセス・ポイントとして機能する仮想サーバー名です。SSLと非SSLの両方のポートへのトラフィックが構成され、通常、非SSLはSSLにリダイレクトされます。クライアントは、bi.mycompany.com:443のアドレスを使用してこのサービスにアクセスします。この仮想サーバーは、ロード・バランサ上に定義されます。

15.3.3.1.5 WEBHOST1およびWEBHOST2へのOracle HTTP Serverのインストール

この項では、WEBHOST1にOracle HTTP Serverをインストールする方法について説明します。

1. サーバーが次の要件を満たしていることを確認します。

- システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にあります。

- ポート7777がWEBHOST1上のサービスによって使用されていないことを確認するために、使用しているオペレーティング・システムに対して次のコマンドを実行します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。
UNIXの場合:

netstat -an | grep "7777"

Windowsの場合:

netstat -an | findstr :7777

ポートが使用されている(コマンドを実行するとポートを識別する戻り値が表示される)場合は、そのポートを解放する必要があります。

UNIXの場合:

ポート7777のエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

Windowsの場合:

ポートを使用しているコンポーネントを停止します。

- staticports.iniファイルをDisk1/stage/Responseディレクトリから一時ディレクトリにコピーします。

- 一時ディレクトリにコピーしたstaticports.iniファイルを編集して、次のカスタム・ポート(Oracle HTTP Serverのポート番号を指定する行は非コメント化)を割り当てます。

# The port for Oracle HTTP server
Oracle HTTP Server port = 7777

2. Oracle Fusion Middleware 11g Web Tier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXの場合:

./runinstallerコマンドを発行します。

Windowsの場合:

setup.exeをダブルクリックします。

「インベントリ・ディレクトリの指定」画面が表示されます。

3. 「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:
インベントリ・ディレクトリの指定: /u01/app/oraInventory

オペレーティング・システムのグループ名: oinstall

次のメッセージのダイアログ・ボックスが表示されます。

「インストールを続行する前に、root権限で特定の処理を実行する必要があります。別のウィンドウで/u01/app/oraInventory/createCentralInventory.shスクリプトを実行してから、「OK」をクリックしてインストールを続行してください。root権限を持たずにインストールを続行する場合は「ローカル・インベントリでインストールを続行」オプションを選択してください」

rootユーザーとしてログインして、/u01/app/oraInventory/createCentralInventory.shを実行します。

これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。

注意:

Oracle製品がすでにホスト上でインストールされている場合、「Oracleインベントリ」画面は表示されません。「Oracleインベントリ」画面が開かない場合は、次のことを確認してください:

- /etc/oraInst.locファイルが存在している。

- このファイルが存在し、表示されているインベントリ・ディレクトリが有効か。

- インストールを実行しているユーザーがインベントリ・ディレクトリに対する書込み権限を持っているか。

4. 「ようこそ」画面で「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

6. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。

7. 「インストール場所の指定」画面で、次を指定します。

- Oracle Middlewareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)

- Oracleホーム・ディレクトリ: Oracle_WT1

「次へ」をクリックします。

8. 「コンポーネントの構成」画面で、次の操作を行います。

- 「Oracle HTTP Server」を選択します。

- 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

「次へ」をクリックします。

9. 「コンポーネントの詳細の指定」画面で、WEBHOST1用に次の値を入力します。

- インスタンス・ホームの場所: ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1

- インスタンス名: web1

- OHSコンポーネント名: ohs1

「次へ」をクリックします。

10. 「ポートの構成」画面で、次の操作を行います。

- カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

- Oracle HTTP Serverポートを入力します(例: 7777)。

「次へ」をクリックします。

11. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。

12. 「インストール・サマリー」画面で、選択した内容が正しいことを確認します。正しくない場合は、「戻る」をクリックして必要に応じて修正します。選択が適切であれば、「インストール」をクリックします。

13. UNIXシステムでは、「インストールの進行状況」画面にoracleRoot.shスクリプトの実行を指示するダイアログが表示されます。ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。

14. 「構成の進行状況」画面で、複数の構成アシスタントが連続して起動します。このプロセスには時間がかかる可能性があります。「次へ」をクリックします。

15. 「インストール完了」画面で「終了」をクリックして終了します。

WEBHOST2に対して手順を繰り返し、WEBHOST1アドレスとWEBHOST2アドレスの両方を含むプールを使用してロード・バランサを構成します。

15.3.3.1.6 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、ブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

http://WEBHOST1:7777/
http://WEBHOST2:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザにOracle FMWの「ようこそ」画面が表示されます。

15.3.3.2 Oracle Fusion Middlewareホームのインストール

この項では、Oracle WebLogic ServerとOracle Fusion Middleware BI EEを実行するアプリケーション層のすべてのノードにOracle Fusion Middlewareをインストールする方法について説明します。WebLogic ServerとOracle RTDをAPPHOST2にインストールするために、これと同じ手順を繰り返します(次ではAPPHOST1を対象にして説明しています)。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。

Oracle Fusion Middlewareの、次のコンポーネントをインストールします。

- Oracle WebLogic Server

- Oracle Fusion Middleware BI EE

15.3.3.2.1 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールする手順は次のとおりです。

1. Oracle WebLogic Serverのインストーラを次のインストール・メディアから起動します。

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

- 「新しいミドルウェア・ホームを作成する」を選択します。

- 「ミドルウェア・ホーム・ディレクトリ」で、ORACLE_BASE/product/fmwと入力します。

注意:

ORACLE_BASEは、Oracle製品がインストールされているベース・ディレクトリです。/u01/app/oracleの値をお薦めします。

「次へ」をクリックします。

4. 「セキュリティ更新のための登録」画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

5. 「インストール・タイプの選択」画面で、「標準」を選択して「次へ」をクリックします。

6. 「製品インストール・ディレクトリの選択」画面で、WebLogic Serverの場合はORACLE_BASE/product/fmw/wlserver_10.3ディレクトリを受け入れます。Oracle Coherenceの場合はORACLE_BASE/product/fmw/coherence_3.6ディレクトリを受け入れます。そして「次へ」をクリックします。

7. 「インストールの概要」画面で「次へ」をクリックします。
Oracle WebLogic Serverソフトウェアがインストールされます。

8. 「インストール完了」画面で、「Quickstartの実行」チェック・ボックスの選択を解除して「完了」をクリックします。

15.3.3.2.2 Oracle RTDのインストール

Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在していない場合には、この手順をスキップできます。

1. Oracle Fusion Middleware Business Intelligence 11gのインストーラを次のインストール・メディアから起動します。
UNIXの場合:

APPHOST1>./runInstaller

Windowsの場合:

APPHOST1> setup.exe

2. 「インベントリ・ディレクトリの指定」画面で、次の操作を行います。

- HOME/oraInventoryと入力します。HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(この場所をお薦めします)。

- インストールを実行するユーザーのOSグループを入力します。
「次へ」をクリックします。

- 画面の手順に従って、/createCentralnventory.shをrootとして実行します。
「OK」をクリックします。

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「インストール・タイプの選択」画面で、「ソフトウェアのみインストール」を選択して「次へ」をクリックします。

5. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

6. 「インストール場所の指定」画面で、前にインストールしたMiddlewareホームをドロップダウン・リストで選択します。「Oracleホーム」ディレクトリには、ディレクトリ名(Oracle_BI1)を入力します。
「次へ」をクリックします。

7. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力し、「次へ」をクリックします。

8. 「サマリー」画面で「インストール」をクリックします。
Oracle Fusion Middleware Business Intelligence 11gソフトウェアがインストールされます。

9. 「インストールの進行状況」画面で「次へ」をクリックします。

10. 完了画面で「終了」をクリックします。

15.3.3.3 APPHOST1のVIP1およびAPPHOST2のVIP2の有効化

BIドメインは、BI管理対象サーバーのリスニング・アドレスとして仮想ホスト名を使用します。2つのBIマシン上でこれらのホスト名それぞれに対してマッピングされているVIPを有効にして(APPHOST1ではVIP1、APPHOST2ではVIP2)、トポロジで使用されるネットワーク・システムで仮想ホスト名を(DNSサーバーとhosts解決のいずれかで)正しく解決する必要があります。

15.3.3.4 管理サーバーと1つ目のBI_SERVER1管理対象サーバーが含まれたドメインの作成

この項では、Oracle Business Intelligence構成アシスタント、管理コンソールおよびOracle Enterprise Managerを使用して、ドメインと1つ目のWebLogic Server BI管理対象サーバーを作成する方法について説明します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、すべてのインスタンスが実行されている必要があります。

注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

Oracleホーム・ディレクトリから構成アシスタントを実行して、Oracle RTDが配置された管理対象サーバーおよび管理サーバーが含まれたドメインを作成します。

1. 構成アシスタントの場所にディレクトリを移動します。

APPHOST1> cd ORACLE_HOME/bin

2. 構成アシスタントを起動します。
UNIXの場合:

APPHOST1> ./config.sh

Windowsの場合:

APPHOST1> config.bat

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「前提条件のチェック」画面で、すべてのチェックが正常に完了したことを確認して「次へ」をクリックします。

5. BIシステムの作成またはスケールアウト画面が表示されます。新規BIシステムの作成を選択して、次の値を指定します。

- ユーザー名: weblogic

- ユーザー・パスワード: weblogicユーザーのパスワードを入力します。

- ドメイン名: bifoundation_domain

「次へ」をクリックします。

6. 「インストール場所の指定」画面で、次を入力します。

- MiddleWareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)

- Oracleホーム: ORACLE_BASE/product/fmw/Oracle_BI1(グレーアウトされています)

- WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3(グレーアウトされています)

- ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain

注意:

「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

- インスタンス・ホーム: ORACLE_BASE/product/fmw/instance1

- インスタンス名: instance1

「次へ」をクリックします。

7. 「コンポーネントの構成」画面で、Oracle Real-Time Decisionsを選択します。
「次へ」をクリックします。

8. BIPLATFORMスキーマ画面で、次のように入力します。

- データベース・タイプ: Oracle Database

- 接続文字列: BIDBHOST1:1521:BIDB1^BIDBHOST2:1521:BIDB2@BIHA.MYCOMPANY.COM

- BIPLATFORMスキーマ・ユーザー名: BIHA_BIPLATFORM

- BIPLATFORMスキーマ・パスワード: BIPLATFORMスキーマ・ユーザーのパスワードを入力します。

「次へ」をクリックします。

9. 「ポートの構成」画面で、次のいずれかを選択します。

- 自動でポートを構成

- 構成ファイルを使用してポートを指定

「次へ」をクリックします。

10. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

11. 「サマリー」画面で「構成」をクリックします。

12. 「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。

13. 完了画面で「終了」をクリックします。

15.3.3.5 APPHOST1での管理サーバーのboot.propertiesの作成

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーに対してboot.propertiesファイルを作成します。

1. 次のディレクトリに移動します。

ORACLE_BASE/product/fmw/user_projects/domains/bifoundation_domain/servers/
AdminServer/security

2. 次の行をファイルに入力し、ファイルを保存してからエディタを閉じます。

username=Admin_username
password=Admin_password

注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

15.3.3.6 APPHOST1での管理サーバーの起動と検証

この項では、APPHOST1で管理サーバーを起動および検証する手順について説明します。

15.3.3.6.1 APPHOST1での管理サーバーの起動

APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

APPHOST1> cd MW_HOME/user_projects/domains/bifoundation_domain/bin
APPHOST1> ./startWebLogic.sh

15.3.3.6.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

1. ブラウザでhttp://APPHOST1:7001/consoleにアクセスします。

2. 管理者としてログインします。

3. BI_SERVER1管理対象サーバーが表示されていることを確認します。

4. bi_clusterクラスタが表示されていることを確認します。

5. Enterprise Manager(http://APPHOST1:7001/em)にアクセスできることを確認します。

15.3.3.7 BI_SERVER1管理対象サーバーのリスニング・アドレスの設定

次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で「bi_server1」を選択します。

6. リスニング・アドレスをAPPHOST1VHN1に設定します。

7. 「保存」をクリックします。

8. 変更を保存およびアクティブ化します。

変更内容は、BI_SERVER1管理対象サーバーが再起動されるまでは有効になりません。

15.3.3.8 BI_SERVER1管理対象サーバーに対するホスト名検証の無効化

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。

ホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で「bi_server1」を選択します。

6. 「SSL」タブを開きます。

7. ページの「詳細」セクションを開きます。

8. 「ホスト名の検証」を「なし」に設定します。

9. 「保存」をクリックします。

10. 変更を保存およびアクティブ化します。

11. 変更内容は、BI_SERVER1管理対象サーバーが再起動されるまでは有効になりません。

15.3.3.9 APPHOST1でのシステムの起動

この項では、APPHOST1でノード・マネージャを起動する方法、およびAPPHOST1でBI_SERVER1管理対象サーバーを起動して検証する方法について説明します。

15.3.3.9.1 APPHOST1でのノード・マネージャの起動

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合、次のコマンドを使用してAPPHOST1で起動します。

APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

15.3.3.9.2 BI_SERVER1管理対象サーバーの起動と検証

BI_SERVER1管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は、次のとおりです。

1. 管理コンソールを使用して、次のようにbi_server1管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「制御」タブをクリックします。

4. 「bi_server1」を選択してから、「起動」をクリックします。

2. 管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。

3. BI_SERVER1が起動してから、次の操作を実行します。

- http://APPHOST1:9704/wsm-pmに移動して、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックして、データで使用できるポリシーとアサーション・テンプレートのリストを表示します。

注意:

ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

- http://APPHOST1:9704/uiに移動して、Oracle RTD Decision Centerアプリケーションのステータスを確認します。

15.3.3.10 APPHOST2でのBIシステムのスケール・アウト

構成アシスタントをORACLE_HOMEディレクトリから実行して、BIシステムをスケール・アウトします。

1. 構成アシスタントの場所にディレクトリを移動します。

APPHOST2> cd ORACLE_HOME/bin

2. 構成アシスタントを起動します。

APPHOST2> ./config.sh

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「前提条件のチェック」画面で、インストーラによって前提条件のチェックが完了します。チェックに失敗した項目がある場合は、修正してインストールを再開します。
「次へ」をクリックします。

5. BIシステムの作成またはスケールアウト画面が表示されます。BIシステムのスケールアウトを選択して、次の値を入力します。

- ホスト名: ADMINHOST

- ポート: 7001

- ユーザー名: weblogic

- ユーザー・パスワード: weblogicユーザーのパスワードを入力します。

「次へ」をクリックします。

6. BIシステム詳細のスケールアウト画面で、次の値を入力します。

- MiddleWareホーム: ORACLE_BASE/product/fmw(グレーアウトされています)

- Oracleホーム: Oracle_BI1(グレーアウトされています)

- WebLogic Serverホーム: ORACLE_BASE/product/fmw/wlserver_10.3(グレーアウトされています)

- ドメイン・ホーム: ORACLE_BASE/product/fmw/user_projects/domain/bifoundation_domain

注意:

「ドメイン・ホーム」では末尾はドメイン名にする必要があります。

- インスタンス・ホーム: ORACLE_BASE/product/fmw/instance2

- インスタンス名: instance2(グレーアウトされています)

「次へ」をクリックします。

7. 「ポートの構成」画面で、次のいずれかを選択します。

- 自動でポートを構成

- 構成ファイルを使用してポートを指定

「次へ」をクリックします。

8. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。「次へ」をクリックします。

9. 「サマリー」画面で「構成」をクリックします。

10. 「構成の進行状況」画面で、すべての構成ツールが正常に完了したことを確認して「次へ」をクリックします。

11. 完了画面で「終了」をクリックします。

15.3.3.11 BI_SERVER2管理対象サーバーのリスニング・アドレスの設定

BI_SERVER2管理対象サーバー・リスニング・アドレスを設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で「bi_server2」を選択します。

6. リスニング・アドレスをAPPHOST2VHN1に設定します。

7. 「保存」をクリックします。

8. 変更を保存およびアクティブ化します。

この変更は、BI_SERVER2管理対象サーバーを再起動するまで有効になりません。

15.3.3.12 BI_SERVER2管理対象サーバーに対するホスト名検証の無効化

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。サーバー証明書を構成していないと、別のWebLogic Serverを管理するときにエラーになります。このようなエラーが発生しないようにするには、トポロジを設定および検証するときにホスト名の検証を無効化し、高可用性トポロジの構成を完了した後で再度有効化します。

ホスト名の検証を無効化するには、次の手順を実行します。

1. 管理コンソールにログインします。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

4. 「サーバー」をクリックします。

5. 表の「名前」列で「bi_server2」を選択します。

6. 「SSL」タブを開きます。

7. ページの「詳細」セクションを開きます。

8. 「ホスト名の検証」を「なし」に設定します。

9. 「保存」をクリックします。

10. 変更を保存およびアクティブ化します。

11. この変更内容は、管理サーバーが再起動されるまでは有効になりません(ノード・マネージャが実行中であることを確認してください)。

1. 「サーバーのサマリー」画面で、「制御」タブを選択します。

2. 表で「AdminServer(管理サーバー)」(ハイパーリンクとして表示)を選択してから、「停止」をクリックします。

3. コマンドラインから次のコマンドを実行して管理サーバーを再び起動します。

APPHOST1> cd ORACLE_COMMON_HOME/bin
APPHOST1> ./wlst.sh

WLSTシェル内で、次のコマンドを実行します(ノード・マネージャが稼働していることを確認します)。

wls:/offline> nmConnect ('Admin_User','Admin_Password', 'APPHOST1', '9556',
'domain_name', 'ORACLE_BASE/product/fmw/user_projects/domain/
bifoundation_domain')

wls:/nm/domain_name> nmStart ('AdminServer')

15.3.3.13 Oracle RTDの構成

この項では、Oracle RTDの構成について説明します。

15.3.3.13.1 RTDクラスタ固有プロパティの構成

Oracle Enterprise Manager Fusion Middleware Controlで次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 「Farm_domain_name」ウィンドウで、「アプリケーション・デプロイメント」ノードを開きます。

3. 「OracleRTD(11.1.1)(bi_cluster)」をクリックします。

4. その下の任意のノードをクリックします。たとえば、「 OracleRTD(11.1.1)(bi_server1) 」をクリックします。

5. 右側のペインで、「アプリケーション・デプロイメント」をクリックして、「システムMBeanブラウザ」を選択します。

6. 「システムMBeanブラウザ」ペインで、「アプリケーション定義のMBean」を開きます。

7. Oracle RTDにあるサーバーごとに、MBeanに移動して、表15-9に示した属性を設定します。

表15-9 Oracle RTDのMBeanに設定する属性値

MBean

属性

BI_SERVER1の値

「SDClusterPropertyManager」→「その他」

DecisionServiceAddress

http://bi.mycompany.com

8. 「適用」をクリックします。

15.3.3.14 APPHOST2でのシステムの起動

この項では、APPHOST2でシステムを起動する手順について説明します。

15.3.3.14.1 トランザクション・リカバリのためのデフォルトの永続ストアの構成

各サーバーにはトランザクション・ログがあり、サーバーによって調整およびコミットされた、未完了の可能性のあるトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。

BI_SERVER1のデフォルト永続ストアの場所を設定する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。

3. 「BI_SERVER1」(ハイパーリンクとして表示されています)を表の「名前」列でクリックします。
BI_SERVER1サーバーの設定ページが開き、「構成」タブがアクティブに表示されます。

4. 「サービス」タブをクリックします。

5. 「チェンジ・センター」で、「ロックして編集」をクリックします。

6. ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようになります。

ORACLE_BASE/admin/domain_name/bi_cluster/tlogs

7. 「保存」→「変更のアクティブ化」をクリックします。

8. BI_SERVER2サーバーに対してこれらの手順を繰り返します。

注意:

トランザクション回復サービスの移行機能を有効化するには、クラスタ内の他のサーバーで利用可能な永続記憶域ソリューション上の場所を指定します。APPHOST1とAPPHOST2の両方が、このディレクトリにアクセスできる必要があります。このディレクトリは、サーバーを再起動する前にも存在している必要があります。

15.3.3.14.2 APPHOST2でのノード・マネージャの起動

通常はノード・マネージャは、config.shの完了時に自動的に起動されます。ノード・マネージャがなんらかの理由によって実行されていない場合は、第15.3.3.9.1項「APPHOST1でのノード・マネージャの起動」の手順を繰り返して、APPHOST2でノード・マネージャを起動してください。

15.3.3.14.3 BI_SERVER2管理対象サーバーの起動と検証

BI_SERVER2管理対象サーバーを起動して、このサーバーが正しく構成されていることを確認する手順は、次のとおりです。

1. 管理コンソールを使用して、次のようにbi_server2管理対象サーバーを起動します。

1. 「ドメイン構造」ウィンドウで、「環境」ノードを開きます。

2. 「サーバー」を選択します。

3. 「制御」タブをクリックします。

4. 「bi_server2」を選択してから、「起動」をクリックします。

2. 管理コンソールでサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中です。」と表示される場合は、サーバーのステータスが「起動済み」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。

3. BI_SERVER2が起動すると、次のURLが使用できるようになります。

- http://APPHOST2:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックして、データで使用できるポリシーとアサーション・テンプレートのリストを表示します。

注意:

ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

- http://APPHOST2:9704/uiにアクセスして、Oracle RTD Decision Centerアプリケーションのステータスを確認します。

15.3.3.15 BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成

BI_SERVERn管理対象サーバーを含むbi_clusterにOracle HTTP Serverをルーティングできるようにするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定する必要があります。

1. WEBHOST1およびWEBHOST2で、ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。

<Location /rtis>
SetHandler weblogic-handler
WebLogicCluster APPHOST1:9704, APPHOST2:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /schema>
SetHandler weblogic-handler
WebLogicCluster APPHOST1:9704, APPHOST2:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /ws>
SetHandler weblogic-handler
WebLogicCluster APPHOST1VHN1:9704, APPHOST2VHN1:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster APPHOST1:9704, APPHOST2:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

# RTD
<Location /ui>
SetHandler weblogic-handler
WebLogicCluster APPHOST1:9704, APPHOST2:9704
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

2. WEBHOST2のOracle HTTP Serverについて同じ手順を実行します。

3. WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

WEBHOST2> ORACLE_BASE/product/fmw/Oracle_WT1/instances/web1/bin/
opmnctlrestartproc ias-component=ohs1

15.3.3.16 Oracle HTTP Serverを使用したアクセスの検証

管理コンソールでBIサーバーのステータスが「実行中」として報告されていることを確認します。サーバーに「起動中」または「再開中」と表示される場合は、サーバーの状態が「起動済」に変更されるまで待機します。別のステータス(「管理」や「失敗」など)が報告されている場合は、サーバーの出力ログ・ファイルを調べてエラーがないか確認します。

次のURLにアクセスできることを確認します。

- http://WEBHOST1:7777/wsm-pm

- http://WEBHOST2:7777/wsm-pm

- http://WEBHOST1:7777/ui

- http://WEBHOST2:7777/ui

ロード・バランシング・ルーター・アドレスを使用して、次のURLにアクセスできることを確認します。

- http://bi.mycompany.com:80/ui

- http://bi.mycompany.com:80/wsm-pm

次の手順に従って、HTTP Serverからbi_clusterへのルーティングとフェイルオーバーが適切に機能していることを確認します。

1. BI_SERVER2の実行中に、管理コンソールからBI_SERVER1を停止します。

2. 次のURLにアクセスして、適切な機能を検証します。

- WEBHOST1:7777/wsm-pm

- WEBHOST1:7777/ui

3. 管理コンソールからBI_SERVER1を起動します。

4. BI_SERVER2を停止します。

5. 前述のステップ2のURLにアクセスして、適切な機能を検証します。

15.3.3.17 BI_SERVERnサーバーのサーバー移行の構成

この高可用性トポロジでは、bi_server1とbi_server2の管理対象サーバーに対してサーバー移行を構成する必要があります。これを行うには、第15.1.13.22項「BI_SERVERnサーバーのサーバー移行の構成」の指示に従ってください。

15.3.3.18 新しいノード(APPHOST3)へのOracle RTDトポロジのスケール・アウト

Oracle RTDトポロジをスケール・アウトする際は、トポロジ内の新しいノード(APPHOST3)に、新しい管理対象サーバーとシステム・コンポーネント・セットを追加します。この項では、ノードが2つ以上あり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがある高可用性トポロジを前提にします。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

- Oracle RTDの管理対象サーバーが稼働している既存ノードがトポロジ内に存在していること。

- 新しいノード(APPHOST3)が、Oracle WebLogic ServerとOracle Business Intelligence用の既存のホーム・ディレクトリにアクセスできます。

- ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、MW_HOME/.homeファイルを編集します。次の手順を参照してください。

- 新しいサーバーは新しい個別のドメイン・ディレクトリを使用できます。また、他の管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合、それらのサーバーのドメイン・ディレクトリを再利用できます。

APPHOST3でOracle RTDをスケール・アウトする手順は次のとおりです。

1. APPHOST3で、Oracle Business Intelligenceのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>

Middlewareホーム・リストを更新するには、MW_HOME/.homeファイルを作成して(別のWebLogicインストールがノード内に存在する場合はそれを編集して)、それにORACLE_BASE/product/fmwを追加します。

3. VIP3をAPPHOST3で有効にします。第15.2.3.3項「APPHOST1のVIP1およびAPPHOST2のVIP2の有効化」を参照してください。

4. 第15.3.3.10項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームから構成アシスタントを実行します。

5. 第15.3.3.11項「BI_SERVER2管理対象サーバーのリスニング・アドレスの設定」および第15.3.3.12項「BI_SERVER2管理対象サーバーに対するホスト名検証の無効化」の手順に従って、リスニング・アドレスを設定してホスト名検証を無効にすることで、bi_server3管理対象サーバーを構成します。

6. 追加のOracle Real-Time Decisions構成手順を、第15.3.3.13項「Oracle RTDの構成」に記載されている手順をガイドとして使用してAPPHOST3上のbi_server3管理対象サーバーに対して実行します。

7. 第15.3.3.14.1項「トランザクション・リカバリのためのデフォルトの永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。

8. 第15.3.3.15項「BI_SERVERn管理対象サーバーに対するOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。

9. APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第15.3.3.9.2項「BI_SERVER1管理対象サーバーの起動と検証」を参照してください。

10. 構成を検証するには、http://APPHOST3VHN1:9704/uiというURLにアクセスして、Oracle RTDアプリケーションのステータスを確認します。

11. ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の「ノード・マネージャの設定」を参照してください。

16 HAパワー・ツールの使用

管理コンソールの「HAパワー・ツール」タブを使用して、Javaオブジェクト・キャッシュを構成します。

この項の内容は次のとおりです。

- 第16.1項「Oracle WebLogic管理コンソールでのHAパワー・ツールの有効化」

- 第16.2項「HAパワー・ツールを使用したクラスタのJavaオブジェクト・キャッシュの構成」

- 第16.3項「HAパワー・ツールを使用した管理対象サーバーのJavaオブジェクト・キャッシュの構成」

16.1 Oracle WebLogic管理コンソールでのHAパワー・ツールの有効化

HAパワー・ツールを使用するには、次の手順に従ってこれらのツールを有効にする必要があります。

1. MW_HOME/oracle_common/hapowertoolsディレクトリに配置されている次の2つの.warファイルをDOMAIN_HOME/console-extディレクトリにコピーします。

- powertools-core.war

- powertools-configurejoc.war

2. 管理サーバーを再起動します。

3. 左側のナビゲーション・ツリーで「ドメイン」をクリックして、「HAパワー・ツール」タブを表示します。

16.2 HAパワー・ツールを使用したクラスタのJavaオブジェクト・キャッシュの構成

HAパワー・ツールを使用してクラスタのJavaオブジェクト・キャッシュを構成する手順は次のとおりです。

1. 管理コンソールにログインして、「ドメイン」を選択します。

2. 「HAパワー・ツール」タブをクリックします。「クラスタのJOC構成」を選択します。

3. ドロップダウン・リストからクラスタ名を選択します。「検出ポート」を入力します。

4. ホスト名をカンマで区切って入力します。

5. 「JOCの構成」をクリックします。

6. クラスタを再起動します。

7. CacheWatcherユーティリティを使用してJOC構成を検証します。付録F「分散Javaオブジェクト・キャッシュの構成」を参照してください。

16.3 HAパワー・ツールを使用した管理対象サーバーのJavaオブジェクト・キャッシュの構成

HAパワー・ツールを使用して管理対象サーバーのJavaオブジェクト・キャッシュを構成する手順は次のとおりです。

1. 管理コンソールにログインして、「ドメイン」をクリックします。

2. 「HAパワー・ツール」タブをクリックします。

3. 「管理対象サーバーのJOC構成」を選択します。

4. 管理対象サーバー名と検出ポートを入力します。

5. ホスト名をカンマで区切って入力します。

6. 「JOCの構成」をクリックします。

7. クラスタを再起動します。

8. CacheWatcherユーティリティを使用してJOC構成を検証します。付録F「分散Javaオブジェクト・キャッシュの構成」を参照してください。

一部の管理対象サーバーをJOC構成の対象から除外するには、「除外するサーバー」セクションでサーバー名を(カンマで区切って)指定します。すべての指定されたサーバーの分散モードはfalseに設定されます。

すべての影響を受ける管理対象サーバーの分散モードを無効にするには、「分散モードの無効化」オプションを使用します。このオプションを適用できるのは、クラスタのJOCを構成する場合と、管理対象サーバーのJOCを構成する場合です。

A Oracle RACデータベース・ストアを使用した監査の設定

Oracle Fusion Middleware 11gでは、Oracle Fusion Middlewareの監査フレームワーク・サービスを設定することもできます。監査によって、アカウンタビリティの手段が提供されるとともに、誰がいつ何を行ったか、というタイプの疑問が解決されます。

Oracle Fusion Middlewareの監査フレームワークは、ミドルウェア製品の集中監査フレームワークとして機能するように設計されています。このフレームワークで提供されている監査サービスの対象は次のとおりです。

- ミドルウェア・プラットフォーム: これには、Oracle Platform Security Services(OPSS)やOracle Web ServicesなどのJavaコンポーネントが含まれます。これらは、ミドルウェアにデプロイされたアプリケーションによって活用されるコンポーネントです。間接的には、これらのJavaコンポーネントを活用するデプロイ済アプリケーションはすべて、プラットフォーム・レベルで発生する監査フレームワークの監査イベントから利点を得られます。

- Java EEアプリケーション: 目的は、Oracle自体のJavaコンポーネントをはじめとするJava EEアプリケーションにフレームワークを提供することです。Java EEアプリケーションは、そのアプリケーション固有の監査イベントを作成できるようになります。現在のリリースでは、Oracle Fusion Middlewareの監査フレームワークを使用するJava EEコンポーネントはOracleの内部コンポーネントです。

- システム・コンポーネント: 監査フレームワークは、Oracle Process Manager and Notification Server(OPMN)で管理されるミドルウェア内のシステム・コンポーネントにも、Javaコンポーネントに対するサービスと同様のエンドツーエンドのサービスを提供します。

Oracle Fusion Middleware監査フレームワークの概要情報は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle Fusion Middleware監査フレームワークの概要」の章を参照してください。

出荷時の設定では、監査フレームワークでの監査レコードの格納にはファイル・システムが使用されます。ただし本番環境では、データベース監査ストアを使用して、監査フレームワークのスケーラビリティと高可用性を確保することをお薦めします。この章で説明する構成のような高可用性構成を採用する場合は、データベース監査ストアとしてOracle Real Application Clusters(Oracle RAC)データベースを使用することをお薦めします。

『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査の構成と管理」の章には、監査を構成する手順が記載されています。その章の監査ストアの管理に関する項にデータベースを監査データ・ストアとしてセットアップする手順が記載されています。

Oracle RACデータベース監査ストアを使用してOracle Fusion Middlewareの監査フレームワークを設定する場合は、手動により次の構成を行います。

- WebLogic Serverを使用した、監査データ・ソースのデータ・ソースおよびマルチ・データ・ソースの構成

- opmn.xmlファイルでの、OPMNローダーのJDBC文字列の構成

次の各項では、監査データ・ストアとしてOracle RACデータベースを使用する場合の監査構成固有の追加情報を提供します。

A.1 WebLogic Serverを使用した監査データ・ソースおよびマルチ・データ・ソースの構成

Oracle RACデータベースの監査データ・ソースおよびマルチ・データ・ソースを設定する場合は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の監査ストアの管理に関する項の指示に従ってください。監査データ・ソースのセットアップに関する項の情報に従って監査データ・ソースをセットアップし、複数のデータ・ソースに関する項の説明に従って監査データ・ストアとしてOracle RACデータベースを構成します。

監査データ・ソースのセットアップに関する項の情報に従って監査データ・ソースをセットアップします。監査データ・ストアとしてOracle RACデータベースを使用するには、2つのデータ・ソースを個別に作成する必要があります。この2つのデータ・ソースは、監査スキーマがインストールされている個々のOracle RACインスタンスをそれぞれ指すようにします。必要な設定は次のとおりです。

- 接続URLは次の形式にします。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=PROTOCOL=TCP)(HOST=host-vip)
(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1))

ホストとポート以外にも、サービス名とインスタンス名が必要です。

- 使用するドライバはoracle.jdbc.OracleDriverです。

- 次のプロパティを設定します。

<property>
<name>oracle.net.CONNECT_TIMEOUT</name>
<value>10000</value>
</property>

- データ・ソースごとに必要な設定は次のとおりです。

- initial-capacity: 0

- connection-creation-retry-frequency-seconds: 10

- test-frequency-seconds: 300

- test-connections-on-reserve: true

- test-table-name: SQL SELECT 1 FROM DUAL

- seconds-to-trust-an-idle-pool-connection: 0

- global-transactions-protocol: なし

複数のデータ・ソースに関する項の情報に従って、Oracle RACデータベースを監査データ・ストアとして構成します。JNDI名jdbc/AuditDBを持つマルチ・データ・ソースを作成します。このマルチ・データ・ソースは、作成した個々のデータ・ソースを指す必要があります。

マルチ・データ・ソースに必要な設定は次のとおりです。

- test-frequency-seconds: 5

- algorithm-type: ロード・バランシング

- data-source-list: カンマで区切った子データ・ソースのリスト("JDBC Data Source-0,JDBC Data Source-1")を指します。このリストは、Oracle RACデータベースの個別ノードごとに作成したデータ・ソースのセットと同じものです。

A.2 監査ローダーのJDBC文字列の構成

監査ストアを構成してある場合、Oracle Process Manager and Notification Server(OPMN)によって、Oracle WebLogic Serverで実行されている複数のシステム・コンポーネントが管理されます。これらのコンポーネント用に、OPMNはデータベース監査ストアに監査イベントをプッシュします。

『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のシステム・コンポーネント用のデータベース監査ストアの構成に関する項では、OPMN起動監査ローダーの設定方法について説明しています。

OPMN起動監査ローダーの設定時には、opmn.xmlファイルのrmd-definitions要素を変更する必要があります。デフォルトでは、rmd-definitions要素には、次の形式によるのJDBC文字列が含まれています。

jdbc:oracle:thin:@host:port:sid

監査データ・ストアとしてOracle RACデータベースを使用する場合は、rmd-definitions要素で、Oracle RACデータベースのJDBC文字列を次の形式で使用する必要があります。

jdbc:oracle:thin@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=
tcp)(HOST=node1-vip)(PORT=1521))(ADDRESS=(PROTOCOL=tcp)(HOST=node2-vip)(PORT=1521)
))(CONNECT_DATA=SERVICE_NAME=service-name.mycompany.com)))

また、Javaコンポーネント用にOracle RACデータベース監査ストアを構成する必要がある場合は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のJavaコンポーネント用のデータベース監査ストアの構成に関する項に記載された指示を参照してください。

B 推奨されるマルチ・データ・ソース

マルチ・データ・ソース構成ファイルの例を次に示します。マルチ・プールDS JDBC Multi Data Source-0は、JDBC Data Source-0とJDBC Data Source-1の2つのデータ・ソースで構成されています。太字テキストのプロパティ設定は推奨設定です。

B.1 JDBC Multi Data Source-0

<?xml version='1.0' encoding='UTF-8'?>
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/jdbc-data-source"
xmlns:sec="http://www.bea.com/ns/weblogic/90/security"
xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/jdbc-data-source
http://www.bea.com/ns/weblogic/jdbc-data-source/1.0/jdbc-data-source.xsd">
<name>JDBC Multi Data Source-0</name>
<jdbc-connection-pool-params>
<test-frequency-seconds>5</test-frequency-seconds>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>jdbc/OracleDS</jndi-name>
<algorithm-type>Load-Balancing</algorithm-type>
<data-source-list>JDBC Data Source-0,JDBC Data Source-1</data-source-list>
<failover-request-if-busy>false</failover-request-if-busy>
</jdbc-data-source-params>
</jdbc-data-source>

B.2 JDBC Data Source-0(非XA)

<?xml version='1.0' encoding='UTF-8'?>
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/jdbc-data-source"
xmlns:sec="http://www.bea.com/ns/weblogic/90/security"
xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/jdbc-data-source
http://www.bea.com/ns/weblogic/jdbc-data-source/1.0/jdbc-data-source.xsd">
<name>JDBC Data Source-0</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)
(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))</url>
<driver-name>oracle.jdbc.OracleDriver</driver-name>
<properties>
<property>
<name>user</name>
<value>username</value>
</property>
<property>
<name>oracle.net.CONNECT_TIMEOUT</name>
<value>10000</value>
</property>
</properties>
<password-encrypted>{3DES}LMWCj6TOOuI=</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<initial-capacity>0</initial-capacity>
<max-capacity>20</max-capacity>
<capacity-increment>1</capacity-increment>
<shrink-frequency-seconds>900</shrink-frequency-seconds>
<highest-num-waiters>2147483647</highest-num-waiters>
<connection-creation-retry-frequency-seconds>10</connection-creation-retry-frequency-seconds>
<connection-reserve-timeout-seconds>10</connection-reserve-timeout-seconds>
<test-frequency-seconds>300</test-frequency-seconds>
<test-connections-on-reserve>true</test-connections-on-reserve>
<ignore-in-use-connections-enabled>true</ignore-in-use-connections-enabled>
<inactive-connection-timeout-seconds>0</inactive-connection-timeout-seconds>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
<login-delay-seconds>0</login-delay-seconds>
<statement-cache-size>10</statement-cache-size>
<statement-cache-type>LRU</statement-cache-type>
<remove-infected-connections>true</remove-infected-connections>

<seconds-to-trust-an-idle-pool-connection>0</seconds-to-trust-an-idle-pool-connection>
<statement-timeout>-1</statement-timeout>
<pinned-to-thread>false</pinned-to-thread>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>jdbc/OracleDS0</jndi-name>
<global-transactions-protocol>None</global-transactions-protocol>
</jdbc-data-source-params>
</jdbc-data-source>

B.3 JDBC Data Source-0(XA)

<?xml version='1.0' encoding='UTF-8'?>
<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/jdbc-data-source"
xmlns:sec="http://www.bea.com/ns/weblogic/90/security"
xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/jdbc-data-source
http://www.bea.com/ns/weblogic/jdbc-data-source/1.0/jdbc-data-source.xsd">
<name>JDBC Data Source-0</name>
<jdbc-driver-params>
<url>
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
<properties>
<property>
<name>user</name>
<value>username</value>
</property>
<property>
<name>oracle.net.CONNECT_TIMEOUT</name>
<value>10000</value>
</property>
</properties>
<password-encrypted>{3DES}LMWCj6TOOuI=</password-encrypted>
<use-xa-data-source-interface>true</use-xa-data-source-interface>
</jdbc-driver-params>
<jdbc-connection-pool-params>
<initial-capacity>0</initial-capacity>
<connection-creation-retry-frequency-seconds>10</connection-creation-retry-frequency-seconds>
<max-capacity>15</max-capacity>
<capacity-increment>1</capacity-increment>
<shrink-frequency-seconds>900</shrink-frequency-seconds>
<highest-num-waiters>2147483647</highest-num-waiters>
<connection-reserve-timeout-seconds>10</connection-reserve-timeout-seconds>
<test-frequency-seconds>300</test-frequency-seconds>
<test-connections-on-reserve>true</test-connections-on-reserve>
<ignore-in-use-connections-enabled>true</ignore-in-use-connections-enabled>
<inactive-connection-timeout-seconds>0</inactive-connection-timeout-seconds>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
<login-delay-seconds>0</login-delay-seconds>
<statement-cache-size>10</statement-cache-size>
<statement-cache-type>LRU</statement-cache-type>
<remove-infected-connections>true</remove-infected-connections>
<seconds-to-trust-an-idle-pool-connection>0</seconds-to-trust-an-idle-pool-connection>
<statement-timeout>-1</statement-timeout>
<jdbc-xa-debug-level>10</jdbc-xa-debug-level>
<pinned-to-thread>false</pinned-to-thread>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
<jndi-name>jdbc/OracleDS1</jndi-name>
<global-transactions-protocol>TwoPhaseCommit</global-transactions-protocol>
</jdbc-data-source-params>
<jdbc-xa-params>
<keep-xa-conn-till-tx-complete>true</keep-xa-conn-till-tx-complete>
<need-tx-ctx-on-close>false</need-tx-ctx-on-close>
<xa-end-only-once>false</xa-end-only-once>
<keep-logical-conn-open-on-release>false</keep-logical-conn-open-on-release>
<resource-health-monitoring>true</resource-health-monitoring>
<recover-only-once>false</recover-only-once>
<xa-set-transaction-timeout>false</xa-set-transaction-timeout>
<xa-transaction-timeout>0</xa-transaction-timeout>
<rollback-local-tx-upon-conn-close>false</rollback-local-tx-upon-conn-close>
<xa-retry-duration-seconds>300</xa-retry-duration-seconds>
<xa-retry-interval-seconds>60</xa-retry-interval-seconds>
</jdbc-xa-params>
</jdbc-data-source>

XA用および非XA用のJDBC Data Source-1では、別のOracle RACインスタンス(host:port)を指すことのみがJDBC Data Source-0と異なります。

C Windowsでのサーバー全体の移行

この付録では、Windows XPシステムで仮想IPアドレスを有効化する手順について説明します。

C.1 Windowsコントロール・パネルの使用

この手順では、静的IPアドレスを使用するように構成されたWindows XPシステムを想定しています。

1. 「コントロール パネル」を開きます。

2. 「ネットワークとインターネット接続」を選択します。

3. 「ネットワーク接続」を選択した後、「ローカルエリア接続」を選択します。

4. 「インターネット プロトコル (TCP/IP)」を選択して「プロパティ」ボタンをクリックします。

5. 次のウィンドウで、ダイアログの下部にある「詳細設定」をクリックします。

6. IPアドレスの横にある「追加」をクリックして、対応するサブネット・マスクとともにIPアドレスを追加します。(システムが静的IP用に構成されている場合のみ可能。)

C.2 netshコマンドラインの使用

コマンドラインによる方法では、netshを使用します。例:

netsh interface ip show address <interface>
netsh interface ip add address <interface> <address> <netmask>
netsh interface ip delete address <interface> addr=<address>

次のコマンドを使用できます。

表C-1 アプリケーションのURL

アプリケーション

URL

?

コマンドのリストを表示します。

add

表に構成エントリを追加します。

delete

表から構成エントリを削除します。

dump

構成スクリプトを表示します。

help

コマンドのリストを表示します。

ip

netsh interface ip」コンテキストに変更します。

ipv6

netsh interface ipv6」のコンテキストに変更します。

portproxy

netsh interface portproxy」のコンテキストに変更します。

reset

情報をリセットします。

set

構成情報を設定します。

show

情報を表示します。

次のサブコンテキストを使用できます。

ip ipv6 portproxy

各コマンドのヘルプを表示するには、コマンドに続けてスペース1つと?を入力します。

D コンポーネントのワークブック

この付録では、このドキュメントに記述されているコンポーネントの高可用性構成を実行する際に使用できるワークブックを掲載しています。

次の項目が含まれます。

- 第D.1項「Oracle SOA Suiteのワークブック」

- 第D.2項「Oracle Identity Managementのワークブック」

- 第D.3項「Oracle WebCenterポータルのワークブック」

- 第D.4項「Oracle Portal、Forms、ReportsおよびDiscovererのワークブック」

- 第D.5項「Oracle WebCenter Contentのワークブック」

- 第D.6項「Oracle Data Integratorのワークブック」

- 第D.7項「Oracle Business Intelligence Platformのワークブック」

D.1 Oracle SOA Suiteのワークブック

この項は、Oracle SOA Suiteのワークブックです。

第5.13項「Oracle SOAサービス・インフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」および第5.15項「Oracle BAMの高可用性の構成」の情報を参考にして、Oracle SOA Suiteの高可用性の構成時に、環境内での使用を予定している構成内容を入力できます。

D.1.1 Oracle SOA Suiteのワークブック表

表D-1を使用して、アプリケーションのURLを記録します。

表D-1 アプリケーションのURL

アプリケーション

URL

SOAインフラ・アプリケーション

Oracle Business Process WebアプリケーションのURL

SOAワークリスト・アプリケーション

WSM-PM検証アプリケーション

UMSプリファレンス・アプリケーション

BPM Composer

BPM Workspace

B2B UIアプリケーション

BAMアプリケーション

管理コンソール

WebLogicコンソール

FMWコントロール

表D-2を使用して、仮想IPアドレスを記録します。

表D-2 仮想IPアドレス

用途

IPアドレス

DNS名

管理サーバー

WLS_SOA1

WLS_SOA2

WLS_BAM1

WLS_BAM2

表D-3を使用して、アプリケーション層のファイルの場所を記録します。

表D-3 ファイルの場所: アプリケーション層

環境変数またはアーティファクト

場所

共有

ORACLE_BASE

いいえ

MW_HOME

はい

ORACLE_HOME

はい

WL_HOME

はい

DOMAIN_HOME

いいえ

TLOGディレクトリ

はい

JMS永続ストア

はい

表D-4を使用して、Web層のファイルの場所を記録します。

表D-4 ファイルの場所: Web層

環境変数またはアーティファクト

場所

共有

ORACLE_BASE

いいえ

MW_HOME

はい

ORACLE_HOME

はい

ORACLE_INSTANCE

いいえ

表D-5を使用して、Identity Managementの詳細を記録します。

表D-5 Identity Managementの詳細

Identity Managementのアーティファクト

値

LDAPホスト名

LDAPホスト

LDAP SSLポート

LDAPユーザーDN

LDAPパスワード

Access Managerホスト

Access Managerポート

アプリケーション・プロファイル・パスワード

表D-6を使用して、データベース情報を記録します。

表D-6 データベース情報: メタデータ・リポジトリ

SOAデータベースのアーティファクト

値

データベース・ホスト(Oracle RACを使用する場合はVIP)

リスナー・ポート

データベース・サービス名

RCU接頭辞

メイン・スキーマのユーザー/パスワード

補助スキーマのユーザー/パスワード

MDSのユーザー/パスワード

ユーザー・メッセージングのユーザー/パスワード

BAMのユーザー/パスワード

SOAインフラストラクチャのユーザー/パスワード

SYSのパスワード

表D-7を使用して、ロード・バランシング構成を記録します。

表D-7 ロード・バランサの構成

用途

仮想名

ポート

外部から参照可能

SSL

接続先ホスト

接続先ポート

SSL

外部サイト

内部サイト

管理サイト

表D-8を使用して、ポート情報を記録します。

表D-8 ポート情報

コンポーネント

ホスト

ポート

ロード・バランサ上のSSLポート

ロード・バランサ

ロード・バランサ上のHTTPポート

ロード・バランサ

OHS HTTPのリスニング

OHSの管理

OPMN

WebLogic管理サーバー

シングル・サインオンのリスニング

WLS_SOA1のリスニング・アドレス

WLS_SOA2のリスニング・アドレス

WLS_BAM1のリスニング・アドレス

WLS_BAM2のリスニング・アドレス

SOAHOST1上のノード・マネージャ

SOAHOST2上のノード・マネージャ

BAMHOST1上のノード・マネージャ

BAMHOST2上のノード・マネージャ

D.2 Oracle Identity Managementのワークブック

この項は、Oracle Identity Managementのワークブックです。

第8章「Identity Managementコンポーネントの高可用性の構成」内の情報を参考にして、Oracle Identity Managementコンポーネントの高可用性の構成時に、環境内での使用を予定している構成内容を入力できます。

D.2.1 Oracle Identity Managementのワークブック表

次の各表を使用して、Oracle Identity Managementの高可用性構成で使用することを予定している構成内容を記録します。

表D-9には、構成に使用するアプリケーションのURLを入力します。

表D-9 アプリケーションのURL

アプリケーション

URL

Oracle WebLogic管理コンソール

Oracle Enterprise Manager Fusion Middleware Control

Oracle Access Managerコンソール

表D-10には、構成に使用する仮想IPアドレスを入力します。

表D-10 仮想IPアドレス

用途

IPアドレス

DNS名

Oracle WebLogic管理サーバー

表D-11には、構成に使用する次の汎用ファイルの場所を入力します。

表D-11 汎用ファイルの場所

タイプ

場所

共有

ORACLE_BASE

いいえ

MW_HOME

いいえ

表D-12には、構成に使用するIDMHOSTnのファイルの場所を入力します。

表D-12 IDMHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

ORACLE_HOME

いいえ

管理サーバーのORACLE_INSTANCE

いいえ

WLS_ODS1のORACLE_INSTANCE

いいえ

WLS_ODS2のORACLE_INSTANCE

いいえ

WL_HOME

いいえ

DOMAIN_HOME

いいえ

表D-13には、構成に使用するOIDHOSTnのファイルの場所を入力します。

表D-13 OIDHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表D-14には、構成に使用するOVDHOSTnのファイルの場所を入力します。

表D-14 OVDHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表D-15には、構成に使用するOAMHOSTnのファイルの場所を入力します。

表D-15 OAMHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

IDM_ORACLE_HOME

いいえ

IAM_ORACLE_HOME

いいえ

SOA_ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表D-16には、構成に使用するOIMHOSTnのファイルの場所を入力します。

表D-16 OIMHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

IAM_ORACLE_HOME

いいえ

ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表D-17には、構成に使用するOAAMHOSTnのファイルの場所を入力します。

表D-17 OAAMHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

IDM_ORACLE_HOME

いいえ

IAM_ORACLE_HOME

いいえ

SOA_ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表D-18には、構成に使用するOIFHOSTnのファイルの場所を入力します。

表D-18 OIFHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

ORACLE_HOME

いいえ

管理サーバーのORACLE_INSTANCE

いいえ

WLS_OIF1のORACLE_INSTANCE

いいえ

WLS_OIF2のORACLE_INSTANCE

いいえ

WL_HOME

いいえ

DOMAIN_HOME

いいえ

表D-19には、構成に使用するWeb層のファイルの場所を入力します。

表D-19 Web層のファイルの場所

環境アーティファクト

ディレクトリの場所

共有

ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表D-20には、構成に使用するOracle Identity Managementの詳細を入力します。

表D-20 Identity Managementのアーティファクト

Identity Managementのアーティファクト

値

シングル・サインオンURL

Oracle Internet Directoryホスト名

Oracle Internet Directoryの非SSLポート

Oracle Internet DirectoryのSSL有効

Oracle Internet DirectoryのSSLポート

Oracle Internet Directoryのセキュリティ・レルム

Oracle Virtual Directoryのホスト名

Oracle Virtual Directoryのポート

Oracle Virtual DirectoryのSSL有効

Oracle Virtual DirectoryのSSLポート

表D-21には、Oracle Identity Federation構成に使用する認証LDAPのアーティファクトの詳細を入力します。

表D-21 Oracle Identity Federation用の認証LDAPのアーティファクト

認証LDAPのアーティファクト

値

LDAPタイプ

LDAP URL

LDAPバインドDN

LDAPバインドDNのパスワード

ユーザー資格証明ID属性

ユーザーの一意ID属性

個人オブジェクト・クラス

ベースDN

表D-22には、構成でLDAPユーザー・データ・ストアを使用する場合のOracle Identity Federationのアーティファクトを入力します。

表D-22 Oracle Identity Federation用のLDAPユーザー・データ・ストアのアーティファクト

LDAPユーザー・データ・ストアのアーティファクト

値

LDAPタイプ

LDAP URL

LDAPバインドDN

LDAPバインドDNのパスワード

ユーザー説明属性

ユーザーID属性

個人オブジェクト・クラス

ベースDN

表D-23には、構成でLDAPフェデレーション・データ・ストアを使用する場合のOracle Identity Federationのアーティファクトを入力します。

表D-23 Oracle Identity Federation用のLDAPフェデレーション・データ・ストアのアーティファクト

フェデレーション・データ・ストアのアーティファクト

値

LDAPタイプ

LDAP URL

LDAPバインドDN

LDAPバインドDNのパスワード

ユーザー・フェデレーション・レコード・コンテキスト

LDAPコンテナ・オブジェクト・クラス

表D-24には、構成でRDBMSユーザー・データ・ストアを使用する場合のOracle Identity Federationのアーティファクトを入力します。

表D-24 Oracle Identity Federation用のRDBMSユーザー・データ・ストアのアーティファクト

RDBMSユーザー・データ・ストアのアーティファクト

値

ホスト名

ユーザー名

パスワード

ログイン表

ユーザーID属性

ユーザー説明属性

表D-25には、構成でRDBMSフェデレーション・データ・ストアを使用する場合のOracle Identity Federationのアーティファクトを入力します。

表D-25 Oracle Identity Federation用のRDBMSフェデレーション・データ・ストアのアーティファクト

RDBMSフェデレーション・データ・ストアのアーティファクト

値

ホスト名

ユーザー名

パスワード

表D-26には、Oracle Identity Federation構成に使用するRDBMS一時データ・ストアのアーティファクトを入力します。

表D-26 Oracle Identity Federation用のRDBMS一時データ・ストアのアーティファクト

一時データ・ストアのアーティファクト

値

ホスト名

ユーザー名

パスワード

表D-27には、構成に使用するメタデータ・リポジトリのデータベース情報を入力します。

表D-27 メタデータ・リポジトリのデータベース情報

データベースの詳細

値

データベース・ホスト(Oracle RACを使用する場合はVIP)

リスナー・ポート

データベース・サービス名

RCU接頭辞

メイン・スキーマの名前/パスワード

補助スキーマの名前/パスワード

SYSのパスワード

表D-28には、構成に使用するロード・バランサの構成情報を入力します。

表D-28 ロード・バランサの構成

用途

仮想名

ポート

外部から参照可能

SSL

接続先ホスト

接続先ポート

SSL

Oracle Internet Directory

Oracle Virtual Directory

管理サーバー

Oracle Identity Manager

シングル・サインオン

表D-29には、構成に使用するポート情報を入力します。

表D-29 ポート情報

コンポーネント

ホスト

ポート

Oracle Internet Directory

Oracle Internet Directory(SSL)

Oracle Virtual Directory

Oracle Virtual Directory(SSL)

WebLogic Serverコンソール

Oracle Enterprise Manager Fusion Middleware Control

Oracle Directory Services Manager

Oracle Access Manager Server

Oracle Identity Manager Server

Oracle Identity Manager

Oracle SOA

Oracle Adaptive Access Manager Server

Oracle Adaptive Access Manager管理サーバー

Oracle HTTP Server

Oracle HTTP Server(SSL)

Oracle HTTP Serverの管理

OPMN

ノード・マネージャ

D.3 Oracle WebCenter Portalのワークブック

この項は、第6.3.2.1項「WebCenterポータルの管理対象サーバーとアプリケーション」のワークブックです。

第6.4項「WebCenterポータルの高可用性の構成」内の情報を参考にして、Oracle WebCenterポータル・コンポーネントの高可用性の構成時に、環境内での使用を予定している構成内容を入力できます。

D.3.1 Oracle WebCenterポータルのワークブック表

次の各表を使用して、Oracle WebCenterポータルの高可用性構成で使用することを予定している構成内容を記録します。

表D-30を使用して、アプリケーションのURLを記録します。

表D-30 アプリケーションのURL

アプリケーション

URL

WebCenter Spacesアプリケーション

Portal Toolsアプリケーション

WSM Policy Managerアプリケーション

WebCenterディスカッション・フォーラム

WebCenter Analytics

WebCenterアクティビティ・グラフ

WebCenterパーソナライズ

管理コンソール

WebLogicコンソール

FMWコントロール

表D-31を使用して、仮想IPアドレスを記録します。

表D-31 仮想IPアドレス

用途

IPアドレス

DNS名

管理サーバー

表D-32を使用して、アプリケーション層のファイルの場所を記録します。

表D-32 ファイルの場所: アプリケーション層

タイプ

場所

共有

ORACLE_BASE

いいえ

MW_HOME

はい

ORACLE_HOME

はい

WL_HOME

はい

DOMAIN_HOME

いいえ

ADMIN_DOMAIN_HOME

はい

表D-33を使用して、Web層のファイルの場所を記録します。

表D-33 ファイルの場所: Web層

アプリケーション

URL

共有

ORACLE_BASE

いいえ

MW_HOME

はい

ORACLE_HOME

はい

WL_HOME

はい

DOMAIN_HOME

いいえ

ADMIN_DOMAIN_HOME

はい

表D-34を使用して、Identity Managementの詳細を記録します。

表D-34 Identity Managementの詳細

LDAPホスト名

LDAPポート

LDAP SSL有効

LDAPユーザーDN

LDAPパスワード

Access Managerホスト

Access Managerポート

アプリケーション・プロファイル・パスワード

表D-35を使用して、メタデータ・リポジトリのデータベース情報を記録します。

表D-35 データベース情報: メタデータ・リポジトリ

データベース・ホスト(Oracle RACを使用する場合はVIP)

リスナー・ポート

データベース・サービス名

RCU接頭辞

メイン・スキーマのユーザー/パスワード

補助スキーマのユーザー/パスワード

MDSのユーザー/パスワード

WebCenter Spacesのユーザー/パスワード

ポートレットのユーザー/パスワード

ディスカッション・フォーラムのユーザー/パスワード

コンテンツ・サーバーのユーザー/パスワード

SYSのパスワード

表D-36を使用して、ロード・バランサの構成を記録します。

表D-36 ロード・バランサの構成

用途

仮想名

ポート

外部から参照可能

SSL

接続先ホスト

接続先ポート

WCアプリケーション

管理

WC内部アプリケーション

表D-37を使用して、ポート情報を記録します。

表D-37 ポート情報

コメント

ホスト

ポート

ロード・バランサ上のSSLポート

ロード・バランサ

ロード・バランサ上のHTTPポート

ロード・バランサ

OHS HTTPのリスニング

OHSの管理

WebLogic管理サーバー

OPMN

シングル・サインオンのリスニング

WLS_WSM1

WLS_WSM2

WC_SPACES1

WC_SPACES2

WC_PORTLETS1

WC_PORTLETS2

WC_COLLABORATION1

WC_COLLABORATION2

WC_UTILITIES1

WC_UTILITIES2

ノード・マネージャ

D.4 Oracle Portal、Forms、ReportsおよびDiscovererのワークブック

この項は、第14.6項「高可用性のためのOracle Portal、Forms、ReportsおよびDiscovererの構成」のワークブックです。

第14.6項「高可用性のためのOracle Portal、Forms、ReportsおよびDiscovererの構成」内の情報を参考にして、Oracle Portal、Forms、ReportsおよびDiscovererの高可用性の構成時に、環境内での使用を予定している構成内容を入力できます。

D.4.1 Oracle Portal、Forms、ReportsおよびDiscovererのワークブック表

表D-38を使用して、アプリケーションのURLを記録します。

表D-38 アプリケーションのURL

アプリケーション

URL

Portal

Forms

レポート

Discoverer

WebLogicコンソール

FMWコントロール

表D-39を使用して、仮想IPアドレスを記録します。

表D-39 仮想IPアドレス

用途

IPアドレス

DNS名

管理サーバー

表D-40を使用して、ファイルの場所を記録します。

表D-40 ファイルの場所

タイプ

場所

共有

ORACLE_BASE

いいえ

MW_HOME

いいえ

ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

WL_HOME

いいえ

DOMAIN_HOME

いいえ

レポート・キャッシュ

はい

表D-41を使用して、Identity Managementの詳細を記録します。

表D-41 データベース情報: メタデータ・リポジトリ

シングル・サインオンURL

OIDホスト名

OIDポート

OID SSL有効

表D-42を使用して、データベース情報を記録します。

表D-42 データベース情報: メタデータ・リポジトリ

データベース・ホスト(Oracle RACを使用する場合はVIP)

リスナー・ポート

データベース・サービス名

RCU接頭辞

ポータルのユーザー名/パスワード

ポートレットのユーザー名/パスワード

Discovererのユーザー名/パスワード

SYSのパスワード

表D-43を使用して、ロード・バランシング構成を記録します。

表D-43 ロード・バランサの構成

用途

仮想名

ポート

外部から参照可能

SSL

接続先ホスト

接続先ポート

メイン・サイト

内部サイト

Web Cacheの無効化

表D-44を使用して、ポート情報を記録します。

表D-44 ポート情報

コメント

ホスト

ポート

ロード・バランサ上のSSLポート

ロード・バランサ

ロード・バランサ上のHTTPポート

ロード・バランサ

Web CacheのHTTP

Web Cacheの無効化

Web Cache管理

Web Cache統計

OHS HTTPのリスニング

OHS HTTPSのリスニング

OHSの管理

WebLogic管理サーバー

OPMN

シングル・サインオンのリスニング

WebLogic管理対象サーバー

WebLogic管理対象サーバー

OID HTTP

WLS_PORTAL

WLS_PORTAL1

WLS_FORMS

WLS_FORMS1

WLS_REPORTS

WLS_REPORTS1

WLS_DISCO

WLS_DISCO1

ノード・マネージャ

D.5 Oracle WebCenter Contentのワークブック

この項は、第11.3項「Oracle WebCenter Contentの高可用性の構成手順」のワークブックです。

第11.3項「Oracle WebCenter Contentの高可用性の構成手順」内の情報を参考にして、Oracle WebCenter Contentの高可用性の構成時に、環境内での使用を予定している構成内容を入力できます。

D.5.1 Oracle WebCenter Contentのワークブック表

表D-45を使用して、アプリケーションのURLを記録します。

表D-45 アプリケーションのURL

アプリケーション

URL

UCMアプリケーション

I/PMアプリケーション

URMアプリケーション

IBRの場所

WebLogicコンソール

Fusion Middleware Control

表D-46を使用して、仮想IPアドレスを記録します。

表D-46 仮想IPアドレス

用途

IPアドレス

DNS名

管理サーバー

WLS_IPM1

WLS_IPM2

表D-47を使用して、アプリケーション層のファイルの場所を記録します。

表D-47 ファイルの場所: アプリケーション層

環境変数またはアーティファクト

場所

共有

ORACLE_BASE

いいえ

MW_HOME

はい

ORACLE_HOME

はい

WL_HOME

はい

DOMAIN_HOME

いいえ

UCM構成ディレクトリ

はい

URM構成ディレクトリ

はい

I/PM構成ディレクトリ

はい

IBR構成ディレクトリ

いいえ

表D-48を使用して、Web層のファイルの場所を記録します。

表D-48 ファイルの場所: Web層

環境変数またはアーティファクト

場所

共有

ORACLE_BASE

いいえ

MW_HOME

はい

ORACLE_HOME

はい

表D-49を使用して、データベース情報を記録します。

表D-49 データベース情報: メタデータ・リポジトリ

WCCデータベースのアーティファクト

値

データベース・ホスト(Oracle RACを使用する場合はVIP)

リスナー・ポート

データベース・サービス名

RCU接頭辞

UCMスキーマのユーザー/パスワード

IPMスキーマのユーザー/パスワード

URMのユーザー/パスワード

表D-50を使用して、ロード・バランシング構成を記録します。

表D-50 ロード・バランサの構成

用途

仮想名

ポート

外部から参照可能

SSL

接続先ホスト

接続先ポート

SSL

外部サイト

内部サイト

管理サイト

表D-51を使用して、ポート情報を記録します。

表D-51 ポート情報

コンポーネント

ホスト

ポート

ロード・バランサ上のSSLポート

ロード・バランサ

ロード・バランサ上のHTTPポート

ロード・バランサ

Oracle HTTP ServerのHTTPリスニング

Oracle HTTP Serverの管理

WebLogic管理サーバー

WLS_IPM1のリスニング・アドレス

WLS_IPM2のリスニング・アドレス

WCCHOST1のノード・マネージャ

WCCHOST2のノード・マネージャ

IBRHOST1のノード・マネージャ

IBRHOST2のノード・マネージャ

D.6 Oracle Data Integratorのワークブック

この項は、第7.4項「Oracle Data Integratorの高可用性の構成」のワークブックです。

第7.4項「Oracle Data Integratorの高可用性の構成」内の情報を参考にして、Oracle Data Integratorの高可用性の構成時に、環境内での使用を予定している構成内容を入力できます。

D.6.1 Oracle Data Integratorのワークブック表

表D-52を使用して、アプリケーションのURLを記録します。

表D-52 アプリケーションのURL

アプリケーション

URL

Oracle Data Integratorエージェント

Oracle Data Integratorエクスプローラ

Oracle Data Integrator Webサービス

WebLogicコンソール

Oracle Enterprise Manager Fusion Middleware Control

表D-53を使用して、仮想IPアドレスを記録します。

表D-53 仮想IPアドレス

用途

IPアドレス

DNS名

管理サーバー

表D-54を使用して、アプリケーション層のファイルの場所を記録します。

表D-54 ファイルの場所: アプリケーション層

環境変数またはアーティファクト

場所

共有

ORACLE_BASE

いいえ

MW_HOME

はい

ORACLE_HOME

はい

WL_HOME

はい

DOMAIN_HOME

いいえ

表D-55を使用して、Web層のファイルの場所を記録します。

表D-55 ファイルの場所: Web層

環境変数またはアーティファクト

場所

共有

ORACLE_BASE

いいえ

MW_HOME

はい

ORACLE_HOME

はい

表D-56を使用して、データベース情報を記録します。

表D-56 データベース情報: メタデータ・リポジトリ

Oracle Data Integratorデータベースのアーティファクト

値

データベース・ホスト(Oracle RACを使用する場合はVIP)

リスナー・ポート

データベース・サービス名

RCU接頭辞

ODIマスター・スキーマのユーザー/パスワード

ODI作業スキーマのユーザー/パスワード

表D-57を使用して、ロード・バランシング構成を記録します。

表D-57 ロード・バランサの構成

用途

仮想名

ポート

外部から参照可能

SSL

接続先ホスト

接続先ポート

SSL

外部サイト

内部サイト

管理サイト

表D-58を使用して、ポート情報を記録します。

表D-58 ポート情報

コンポーネント

ホスト

ポート

ロード・バランサ上のSSLポート

ロード・バランサ

ロード・バランサ上のHTTPポート

ロード・バランサ

Oracle HTTP ServerのHTTPリスニング

Oracle HTTP Serverの管理

WebLogic管理サーバー

odi_server1のリスニング・アドレス

odi_server2のリスニング・アドレス

APPHOST2のノード・マネージャ

APPHOST2のノード・マネージャ

D.7 Oracle Business Intelligence Platformのワークブック

この項は、Oracle BI Platformのワークブックです。

第15.1.13項「Oracle BI EEの高可用性の構成手順」内の情報を参考にして、Oracle BI EEコンポーネントの高可用性の構成時に、環境内での使用を予定している構成内容を入力できます。

D.7.1 Oracle Business Intelligence Platformのワークブック表

次の各表を使用して、BI Platformの高可用性構成で使用することを予定している構成内容を記録します。

表D-59を使用して、アプリケーションのURLを記録します。

表D-59 アプリケーションのURL

アプリケーション

URL

BI EEアプリケーション

BI Publisherアプリケーション

Real-Time Decisionsアプリケーション

WMS-PM検証アプリケーション

管理コンソール

WebLogicコンソール

Fusion Middleware Control

表D-60を使用して、仮想IPアドレスを記録します。

表D-60 仮想IPアドレス

用途

IPアドレス

DNS名

管理サーバー

BI_SERVER1

BI_SERVER2

表D-61を使用して、アプリケーション層のファイルの場所を記録します。

表D-61 ファイルの場所: アプリケーション層

環境変数またはアーティファクト

場所

共有

ORACLE_BASE

いいえ

MW_HOME

はい

ORACLE_HOME

はい

WL_HOME

はい

WLS管理サーバーのDOMAIN_HOME

はい

BI_SERVER1のDOMAIN_HOME

いいえ

BI_SERVER2のDOMAIN_HOME

いいえ

TLOGディレクトリ

はい

JMS永続ストア

はい

WLS管理サーバーのORACLE_INSTANCE

いいえ

BI_SERVER1のORACLE_INSTANCE

いいえ

BI_SERVER2のORACLE_INSTANCE

いいえ

グローバル・キャッシュ

はい

BIプレゼンテーション・カタログ

はい

BIリポジトリの公開ディレクトリ

はい

BI Publisherカタログ

はい

BI Publisherの構成

はい

BI Publisherの一時ディレクトリ

はい

表D-62を使用して、Web層のファイルの場所を記録します。

表D-62 ファイルの場所: Web層

環境変数またはアーティファクト

場所

共有

ORACLE_BASE

いいえ

MW_HOME

はい

ORACLE_HOME

はい

ORACLE_INSTANCE

いいえ

表D-63を使用して、データベース情報を記録します。

表D-63 データベース情報

BIデータベースのアーティファクト

値

データベース・ホスト(Oracle RACを使用する場合はVIP)

リスナー・ポート

データベース・サービス名

RCU接頭辞

BIPLATFORMスキーマのユーザー/パスワード

MDSのユーザー/パスワード

SYSのパスワード

表D-64を使用して、ロード・バランシング構成を記録します。

表D-64 ロード・バランシングの構成

用途

仮想名ポート

外部から参照可能なSSL

接続先ホスト

接続先ポート

SSL

外部サイト

内部サイト

管理サイト

表D-65を使用して、ポート情報を記録します。

表D-65 ポート情報

コンポーネント

ホスト

ポート

ロード・バランサ上のSSLポート

ロード・バランサ

ロード・バランサ上のHTTPポート

ロード・バランサ

Oracle HTTP ServerのHTTPリスニング

Oracle HTTP Serverの管理

OPMN

WebLogic管理サーバー

BI_SERVER1のリスニング・アドレス

BI_SERVER2のリスニング・アドレス

APPHOST2のノード・マネージャ

APPHOST2のノード・マネージャ

E ascrsctlのオンライン・ヘルプ

ascrsctl helpコマンドで生成される手順に従うことで、ascrsctlの詳細な使用方法がわかります。この付録には、オフラインでの詳細な参照用に、ヘルプ・ページのすべての内容が収録されています。

E.1 start

トピック

start - start an ASCRS resource

コマンド

ascrsctl start -name <string> [-type <string>] [-node <string>]

説明

このASCRSコマンドは、ASCRSですでに作成されているリソースを起動するときに使用します。

必須の引数は次のとおりです。

-name、-n

この引数では、リソース名を指定します。

オプションの引数は次のとおりです。

-type、-t

この引数では、リソース名を短い形式で指定した場合にリソース・タイプを指定します。これは、名前を正規の形式で指定した場合には不要です。

-node

この引数では、リソースの起動に使用するクラスタ・ノードを指定します。指定しないと、このリソースの配置ポリシーに基づき、CRSによってノードが選択されます。

例

ascrsctl start -n mydisk -t disk
ascrsctl start -n ora.myvip.cfcvip -node hostA.mycompany.com

E.2 stop

トピック

stop - stop an ASCRS resource

コマンド

ascrsctl stop -name <string> [-type <string>] [-force] [-noprompt]

説明

このASCRSコマンドは、ASCRSで作成されたリソースを停止するときに使用します。

必須の引数は次のとおりです。

-name、-n

この引数では、リソース名を指定します。

必須でない引数は次のとおりです。

-type、-t

この引数では、リソース名を短い形式で指定した場合にリソース・タイプを指定します。これは、名前を正規の形式で指定した場合には不要です。

-force、-f

この引数では、指定されたリソースを停止して、このリソースをCRS管理からオフラインにします。このオプションを指定すると、CRSによるリソース監視は必ずオフラインになりますが、そのリソースが管理不能な状態になっている場合は、そのリソースが停止されることは保証されません。

-noprompt、-np

この引数を指定すると、ユーザーは確認を求められることなく、リソースとその従属要素がオフラインになります。

例

ascrsctl stop -n mydisk -t disk
ascrsctl stop -n ora.myvip.cfcvip -f -np

E.3 status

トピック

status - check the status of ASCRS resources

コマンド

ascrsctl status [-name <string>] [-type <string>] [-long]

説明

このASCRSコマンドは、ASCRSで作成されたリソースのいずれかまたはすべてのステータスをチェックするときに使用します。リソースのステータスには、現在の実行状態、CRSの基本的なプロファイル情報および他のASCRSリソースとの関係が含まれます。

-name、-n

この引数では、リソース名を指定します。指定しないと、すべてのリソースがチェックされます。

-type、-t

この引数では、チェックするリソースのタイプを指定します。これは、名前を正規の形式で指定した場合には不要です。

-long、-l

この引数を指定すると、ステータス情報が詳細形式で表示されます。

例

ascrsctl status
ascrsctl status -name ora.mydisk.cfcdisk
ascrsctl status -l

E.4 switch

トピック

switch - switchover an ASCRS resource to another cluster node

コマンド

ascrsctl switch -name <string> [-type <string>]
[-node <string>] [-noprompt]

説明

ASCRSコマンドは、現在オンライン状態のASCRSリソースをクラスタ内の別のノードにスイッチオーバーします。このリソースが依存しているすべてのリソースもスイッチオーバーされます。

必須の引数は次のとおりです。

-name、-n

この引数では、リソース名を指定します。

必須でない引数は次のとおりです。

-type、-t

この引数では、リソース名を短い形式で指定した場合にリソース・タイプを指定します。これは、名前を正規の形式で指定した場合には不要です。

-node

この引数では、このリソースのターゲット・クラスタ・ノードを指定します。この引数を指定しないと、このリソースの配置ポリシーに基づき、CRSによってターゲット・ノードが選択されます。

-noprompt、-np

この引数を指定すると、ユーザーは確認を求められなくなります。

例

ascrsctl switch -n mydisk -t disk hostB.mycompany.com
ascrsctl switch -n ora.myvip.cfcvip -np

E.5 delete

トピック

delete - delete an ASCRS resource

コマンド

ascrsctl delete -name <string> [-type <string>] [-noprompt]

説明

このASCRSコマンドは、ASCRSで作成されたリソースを削除するときに使用します。正常に削除されたリソースは、CRSによる管理の対象外になります。

1つ以上の他のリソースが依存しているASCRSリソースやオフライン状態ではないASCRSリソースは、削除できません。

必須の引数は次のとおりです。

-name、-n

この引数では、リソース名を指定します。

必須でない引数は次のとおりです。

-type、-t

この引数では、リソース名を短い形式で指定した場合にリソース・タイプを指定します。これは、名前を正規の形式で指定した場合には不要です。

-noprompt、-np

指定すると、確認するように求められなくなります。

例

ascrsctl delete -n mydisk -np
ascrsctl delete -n ora.myvip.cfcvip

E.6 create/disk

トピック

create/disk - create disk ASCRS resource

コマンド

ascrsctl create -name <string> -type disk -path <string>
-mountCommand <string> -umountCommand <string>
[options]

説明

このASCRSコマンドは、CRSで共有ディスク・リソースを作成(または登録)するときに使用します。ディスク・リソースを正常に作成するには、共有ディスクのルートにシグネチャ・ファイルを作成する必要があります。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

必須の引数は次のとおりです。

-name、-n

この引数では、作成するリソース名を指定します。

-type、-t

この引数では、リソースのタイプを指定します。その値はdiskにする必要があります。

-path

この引数では、共有ディスクのマウント・ポイントを指定します。

-mountCommand、-mc

この引数では、共有ディスクのマウント時に実行するプラットフォーム固有コマンドを指定します。"nop"というコマンドを指定した場合、アクションは何も実行されません。Windowsでは、共有ディスクがNTFSの場合、「diskmgr online <disk number>」コマンドを使用します。<disk number>は「Microsoft Disk Manager」ウィンドウで識別できます。

-umountCommand、-umc

この引数では、共有ディスクのアンマウント時に実行するプラットフォーム固有コマンドを指定します。"nop"というコマンドを指定した場合、アクションは何も実行されません。Windowsでは、共有ディスクがNTFSの場合、「diskmgr offline <disk number>」コマンドを使用します。<disk number>は「Microsoft Disk Manager」ウィンドウで識別できます。

必須でないオプションは次のとおりです。

-clusterNodes、-nodes、-cn

この引数では、このリソースをホストできるクラスタの有効ノードを指定します。この値は、空白またはカンマで区切ったクラスタ・ノード名のリストです。指定しないと、すべてのノードが含まれます。

-resourceParams、-params、-p

この引数では、このリソースのCRSプロパティを設定するための「名前=値」ペアを空白またはカンマで区切って指定します(例: as=1,rt=400)。

プロパティの名前と値の範囲を表E-1に示します。この表では、as、stおよびraを除くすべての数値は秒単位です。これらのプロパティは、ASCRSの構成ファイルで構成できます。プロパティが構成されていない場合やこのオプションで指定されていない場合、デフォルト値が使用されます。

表E-1 createコマンドのリソース値

パラメータ

最小

最大

デフォルト

用途

as

0

1

1

自動開始

ci

5

6000

600

チェックの間隔

fd

5

600

50

フェイルオーバー遅延

fi

5

6000

50

障害の間隔

ft

0

20

5

障害のしきい値

ra

0

20

3

再起動の試行

st

20

3600

30

スクリプトのタイムアウト

rt

20

3600

30

起動のタイムアウト

pt

20

3600

30

停止のタイムアウト

-policy

この引数では、どのリソース・パラメータ値を使用するかを指定します。これらのポリシーと値は、ASCRSの構成で使用できます。

有効な値はnormalまたはfastです。指定しないと、normalを指定したことになります。ただし、-resourceParamsの値が、ポリシーより常に優先されます。

例

UNIX:
ascrsctl create -n dbhome -t disk -path /cfcdb1
-mc "/bin/mount /dev/sda1 /cfcdb1" -p fd=30
ascrsctl create -n dbhome -t disk -path /cfcdb1
-mc "/bin/mount /dev/sda1 /cfcdb1"
-umc "/bin/umount /dev/sda1"

Windows:
ascrsctl create -n asdisk -t disk -path c:\oracle\asdisk
-mc "diskmgr online 2" -mc "diskmgr offline 2"
-p fd=30

E.7 update/disk

トピック

update/disk - update disk ASCRS resource

コマンド

ascrsctl update -name <string> [-type disk] [-path <string>]
[-mountCommand <string>] [-umountCommand <string>]
[options]

説明

このASCRSコマンドは、ASCRSで作成されたdiskリソースを更新するときに使用します。

必須の引数は次のとおりです。

-name、-n

この引数では、更新するリソース名を指定します。-typeオプションは、完全修飾名を指定した場合には省略できます。

必須でないオプションは次のとおりです。

-type、-t

この引数では、リソースのタイプを指定します。その値はdiskにする必要があります。

-path

この引数では、共有ディスクのマウント・ポイントを指定します。

-mountCommand、-mc

この引数では、共有ディスクをマウントするために実行する、プラットフォーム固有のコマンドまたはスクリプトの完全修飾名を指定します。Windowsでは、共有ディスクがNTFSの場合、「diskmgr online <disk number>」コマンドを使用します。<disk number>は「Microsoft Disk Manager」ウィンドウで識別できます。

-umountCommand、-umc

この引数では、共有ディスクをアンマウントするために実行する、プラットフォーム固有のコマンドまたはスクリプトの完全修飾名を指定します。Windowsでは、共有ディスクがNTFSの場合、「diskmgr offline <disk number>」コマンドを使用します。<disk number>は「Microsoft Disk Manager」ウィンドウで識別できます。

-clusterNodes、-nodes、-cn

この引数では、このリソースをホストできるクラスタの有効ノードを指定します。この値は、空白またはカンマで区切ったクラスタ・ノード名のリストです。特別な値であるdefaultを指定すると、すべてのノードが対象に含まれます。

-resourceParams、-params、-p

この引数では、このリソースのCRSプロパティを設定するための「名前=値」ペアを空白またはカンマで区切って指定します(例: as=1, rt=400)。

プロパティの名前と値の範囲は表E-2に示しています。この表では、as、stおよびraを除くすべての数値は秒単位です。

表E-2 updateコマンドのリソース値

パラメータ

最小

最大

用途

as

0

1

自動開始

ci

5

6000

チェックの間隔

fd

5

600

フェイルオーバー遅延

fi

5

6000

障害の間隔

ft

0

20

障害のしきい値

ra

0

20

再起動の試行

st

20

3600

スクリプトのタイムアウト

rt

20

3600

起動のタイムアウト

pt

20

3600

停止のタイムアウト

例

UNIX:
ascrsctl update -n mydisk -t disk -umfc "/bin/umount -l /sharedisk"

Windows:
ascrsctl update -n mydisk -t disk -mc "diskmgr online 1"
-umc "diskmgr offline 1"

E.8 create/vip

トピック

create/vip - create vip ASCRS resource

コマンド

ascrsctl create -name <string> -type vip -ipAddr <ip> -netmask <string>
-interface <string> [options]

説明

このASCRSコマンドは、CRSで仮想IPリソースを作成(または登録)するときに使用します。

必須の引数は次のとおりです。

-name、-n

この引数では、作成するリソース名を指定します。

-type、-t

この引数では、リソースのタイプを指定します。その値はvipにする必要があります。

-ipAddr、-ip

この引数では、仮想IPのIPアドレスまたはホスト名を指定します。

-netmask、-nm

この引数では、前述の仮想IPのネットワーク・マスクを指定します。

-interface、-if

この引数では、IPを有効化するネットワーク・インタフェースを指定します。

UNIXの場合、値には、eth0や"eth0|eth1"のように、1つ以上のインタフェース名を指定できます。Windowsの場合、値には、"Public network1|Public network2"のように、1つ以上のネットワーク接続名を指定できます。

必須でないオプションは次のとおりです。

-clusterNodes、-nodes、-cn

この引数では、このリソースをホストできるクラスタの有効ノードを指定します。この値は、空白またはカンマで区切ったクラスタ・ノード名のリストです。指定しないと、すべてのノードが含まれます。

-resourceParams、-params、-p

この引数では、このリソースのCRSプロパティを設定するための「名前=値」ペアを空白またはカンマで区切って指定します(例: as=1, rt=400)。

プロパティの名前と値の範囲を表E-1に示します。この表では、as、stおよびraを除くすべての数値は秒単位です。これらのプロパティは、ASCRSの構成ファイルで構成できます。プロパティが構成されていない場合やこのオプションで指定されていない場合、デフォルト値が使用されます。

-policy

この引数では、どのリソース・パラメータ値を使用するかを指定します。これらのポリシーと値は、ASCRSの構成ファイルで使用できます。

有効な値はnormalまたはfastです。指定しないと、normalを指定したことになります。ただし、-resourceParamsの値が、ポリシーより常に優先されます。

例

UNIX:
ascrsctl create -n myvip -t vip -ip 192.168.1.10 -nm 255.255.255.0
-if eth1 -p ci=5

Windows:
ascrsctl create -n myvip -t vip -ip 192.168.1.10 -nm 255.255.255.0
-if "Public network" -p ci=5

E.9 update/vip

トピック

update/vip - update vip ASCRS resource

コマンド

ascrsctl update -name <string> [-type vip] [-ipAddr <string>
[-netmask <string>] [-interface <string>] [options]

説明

このASCRSコマンドは、ASCRSで作成されたvipリソースを更新するときに使用します。

必須の引数は次のとおりです。

-name、-n

この引数では、更新するリソース名を指定します。-typeオプションは、完全修飾名を指定した場合には省略できます。

必須でないオプションは次のとおりです。

-type、-t

この引数では、リソースのタイプを指定します。その値はvipにする必要があります。

-ipAddr、-ip

この引数では、仮想IPのIPアドレスまたはホスト名を指定します。

-netmask、-nm

この引数では、前述の仮想IPのネットワーク・マスクを指定します。

-interface、-if

この引数では、IPを有効化するネットワーク・インタフェースを指定します。

UNIXの場合、値には、eth0や"eth0|eth1"のように、1つ以上のインタフェース名を指定できます。Windowsの場合、値には、"Public network1|Public network2"のように、1つ以上のネットワーク接続名を指定できます。

-clusterNodes、-nodes、-cn

この引数では、このリソースをホストできるクラスタの有効ノードを指定します。この値は、空白またはカンマで区切ったクラスタ・ノード名のリストです。特別な値であるdefaultを指定すると、すべてのノードが対象に含まれます。

-resourceParams、-params、-p

この引数では、このリソースのCRSプロパティを設定するための「名前=値」ペアを空白またはカンマで区切って指定します(例: as=1, rt=400)。

プロパティの名前と値の範囲を表E-2に示します。この表では、as、stおよびraを除くすべての数値は秒単位です。

例

UNIX:
ascrsctl update -n ora.myvip.cfcvip -ip 192.168.1.10
ascrsctl update -n ora.myvip.cfcvip -if eth1 -p ci=3

Windows:
ascrsctl update -n ora.myvip.cfcvip -if Public -p ci=3

E.10 create/dblsnr

トピック

create/dblsnr - create dblsnr ASCRS resource

コマンド

ascrsctl create -name <string> -type dblsnr -listenerName <string>
-listenerOracleHome <string>
-vip <string> -disk <string>
[-tnsAdmin <string>] [options]

説明

このASCRSコマンドは、CRSでOracle Databaseのリスナー・リソースを作成(または登録)するときに使用します。

必須の引数は次のとおりです。

-name、-n

この引数では、作成するリソース名を指定します。

-type、-t

この引数では、リソースのタイプを指定します。その値はdblsnrにする必要があります。

-listenerName、-ln

この引数では、データベースのリスナー名を指定します。

-listenerOracleHome、-lsnroh、-loh

この引数では、このリスナーを保有するデータベースのOracleホームを指定します。

-vip

この引数では、このリスナーの実行場所の仮想IPリソースを指定します。

-disk

この引数では、Oracleホームの配置場所のディスク・リソースを指定します。

そのほか、必須でないオプションは次のとおりです。

-clusterNodes、-nodes、-cn

この引数では、このリソースをホストできるクラスタの有効ノードを指定します。この値は、空白またはカンマで区切ったクラスタ・ノード名のリストです。特別な値であるdefaultを指定すると、すべてのノードが対象に含まれます。指定しないと、すべてのノードが含まれます。

-resourceParams、-params、-p

この引数では、このリソースのCRSプロパティを設定するための「名前=値」ペアを空白またはカンマで区切って指定します(例: as=1, rt=400)。

プロパティの名前と値の範囲を表E-1に示します。この表では、as、stおよびraを除くすべての数値は秒単位です。これらのプロパティは、ASCRSの構成ファイルで構成できます。プロパティが構成されていない場合やこのオプションで指定されていない場合、デフォルト値が使用されます。

-policy

この引数では、どのリソース・パラメータ値を使用するかを指定します。これらのポリシーと値は、ASCRSの構成ファイルで使用できます。

有効な値はnormalまたはfastです。指定しないと、normalを指定したことになります。ただし、-resourceParamsの値が、ポリシーより常に優先されます。

-tnsAdmin、-ta

この引数では、リスナー構成がOracleホーム内のデフォルトの場所にない場合に、この構成のある場所を指定します。

例

UNIX:
ascrsctl create -name mydblsnr -type dblsnr -listenerName orcl
-listenerOracleHome /cfcdb1
-vip 192.168.1.10 -disk ohdisk

Windows:
ascrsctl create -name mydblsnr -type dblsnr -listenerName orcl
-listenerOracleHome c:\oraasshare\cfcdb1
-vip myvip -disk ohdisk

E.11 update/dblsnr

トピック

update/dblsnr - update dblsnr ASCRS resource

コマンド

ascrsctl update -name <string> [-type dblsnr]
[-listenerName <string>]
[-listenerOracleHome <string>]
[-vip <string>] [-disk <string>]
[-tnsAdmin <string>] [options]

説明

このASCRSコマンドは、ASCRSで作成されたdblsnrリソースを更新するときに使用します。

必須の引数は次のとおりです。

-name、-n

この引数では、更新するリソース名を指定します。-typeオプションは、完全修飾名を指定した場合には省略できます。

必須でないオプションは次のとおりです。

-type、-t

この引数では、リソースのタイプを指定します。その値はdblsnrにする必要があります。

-listenerName、-ln

この引数では、データベースのリスナー名を指定します。

-listenerOracleHome、-lsnroh、-loh

この引数では、このリスナーを保有するデータベースのOracleホームを指定します。

-vip

この引数では、このリスナーの実行場所の仮想IPリソースを指定します。

-clusterNodes、-nodes、-cn

この引数では、このリソースをホストできるクラスタの有効ノードを指定します。この値は、空白またはカンマで区切ったクラスタ・ノード名のリストです。特別な値であるdefaultを指定すると、すべてのノードが対象に含まれます。

-resourceParams、-params、-p

この引数では、このリソースのCRSプロパティを設定するための「名前=値」ペアを空白またはカンマで区切って指定します(例: as=1, rt=400)。

プロパティの名前と値の範囲を表E-2に示します。この表では、as、stおよびraを除くすべての数値は秒単位です。

-tnsAdmin、-ta

この引数では、リスナー構成ファイルの新しい場所を指定します。特別な値である「nil」を指定すると、デフォルトの場所が使用されます。

-disk

この引数では、Oracleホームの配置場所のディスク・リソースを指定します。

例

ascrsctl update -n mydblsnr -t dblsnr -vip newvip
ascrsctl update -n mydblsnr -t dblsnr -disk newdisk -p st=30,pt=40,rt=40

E.12 create/db

トピック

create/db - create db ASCRS resource

コマンド

For database instance:
ascrsctl create -name <string> -type db -oraHome <string>
-oraSID <string> -disk <string> [<string> ...]
-lsnr <string> [-pfile <string>]
[-componentID dbinstance] [options]

For database console:
ascrsctl create -name <string> -type db -oraHome <string>
-oraSID <string> -disk <string> -vip <string>
[-componentID dbconsole] [options]

For job scheduler (Windows only):
ascrsctl create -name <string> -type db -oraHome <string>
-oraSID <string> -disk <string>
[-componentID jobscheduler] [options]

For VSS writer (Windows only):
ascrsctl create -name <string> -type db -oraHome <string>
-oraSID <string> -disk <string>
[-componentID vsswriter] [options]

説明

このASCRSコマンドは、CRSでOracle Databaseのリソースを作成(または登録)するときに使用します。指定されたコンポーネントIDに応じて、データベース・リソースは、コア・データベース・インスタンス、dbconsoleサービス、Oracleジョブ・スケジューラ・サービスまたはOracle Volume Shadow Service(VSS)のいずれかを表します(後者の2つはプラットフォームがWindowsの場合)。

次は、すべてのデータベース・リソースに必須の引数です。

-name、-n

この引数では、作成するリソース名を指定します。

-type、-t

この引数では、リソースのタイプを指定します。その値はdbにする必要があります。

-oraHome、-oh

この引数では、データベースのOracleホームの場所を指定します。

-oraSID、-sid

この引数では、Oracle SID名を指定します。

-disk

この引数では、Oracleホームおよびデータファイルをホストする共有ディスクを指定します。データベース・インスタンス・コンポーネントの場合は、このパラメータの値は、ASCRSディスク・リソース名を空白またはカンマで区切って列記したものです。他のコンポーネントの場合は、この値はOracleホームをホストしているディスク・リソースです。

そのほか、必須でないオプションは次のとおりです。

-componentID、-c

この引数では、管理するデータベース・コンポーネントを指定します。これは、dbinstance、dbconsole、jobscheduler(Windowsのみ)またはvsswriter(Windowsのみ)です。この引数を指定しないと、dbinstanceを指定したことになります。

-clusterNodes、-nodes、-cn

この引数では、このリソースをホストできるクラスタの有効ノードを指定します。この値は、空白またはカンマで区切ったクラスタ・ノード名のリストです。指定しないと、すべてのノードが含まれます。

-resourceParams、-params、-p

この引数では、このリソースのCRSプロパティを設定するための「名前=値」ペアを空白またはカンマで区切って指定します(例: as=1, rt=400)。

プロパティの名前と値の範囲を表E-1に示します。この表では、as、stおよびraを除くすべての数値は秒単位です。これらのプロパティは、ASCRSの構成ファイルで構成できます。プロパティが構成されていない場合やこのオプションで指定されていない場合、デフォルト値が使用されます。

-policy

この引数では、どのリソース・パラメータ値を使用するかを指定します。これらのポリシーと値は、ASCRSの構成ファイルで使用できます。

有効な値はnormalまたはfastです。指定しないと、normalを指定したことになります。ただし、-resourceParamsの値が、ポリシーより常に優先されます。

コンポーネント固有のオプション:

データベース・インスタンス・コンポーネントの場合:

-lsnr

この引数では、このデータベースで使用するリスナー・リソースを指定します。これは必須です。

-pfile、-pf

この引数では、データベースの起動に使用するデータベース・パラメータ・ファイルを指定します。dbinstanceコンポーネントにのみ有効です。

データベース・コンソール・コンポーネントの場合:

-vip

この引数では、このデータベース・コンソール・リソースで使用される仮想IPリソースを指定します。これは必須です。

例

UNIX:
ascrsctl create -n mydb -t db -oh /cfcdb1 -sid orcl
-disk ohdisk datafiledisk -lsnr mydblsnr

Windows:
ascrsctl create -n mydb -t db -oh c:\oraasshare\cfcdb1 -sid orcl
-disk ohdisk datafiledisk -lsnr mydblsnr

E.13 update/db

トピック

update/db - update db ASCRS resource

コマンド

ascrsctl update -name <string> -type db [-oraHome <string>]
[-oraSID <string>] [-disk <string> [<string> ...]]
[-lsnr <string>] [-pfile <string>]
[-vip <string>] [options]

説明

このASCRSコマンドは、CRSに登録されているASCRS dbリソースを更新するときに使用します。

必須の引数は次のとおりです。

-name、-n

この引数では、更新するリソース名を指定します。

必須でない引数は次のとおりです。

-type、-t

この引数では、リソースのタイプを指定します。その値はdbにする必要があります。-typeオプションは、リソース名を正規の形式で指定した場合には省略できます。

-oraHome、-oh

この引数では、データベースのOracleホームの場所を指定します。

-oraSID、-sid

この引数では、Oracle SID名を指定します。

-disk

データベース・インスタンス・コンポーネントの場合は、このパラメータの値は、ASCRSディスク・リソース名を空白またはカンマで区切って列記したものです。他のコンポーネントの場合は、この値はOracleホームをホストしているディスク・リソースです。

-lsnr

この引数では、リスナー・リソースを指定します。dbinstanceコンポーネントにのみ適用されます。

-vip

この引数は、データベース・コンソールで使用される仮想IPリソースを指定するため、データベース・コンソール・リソースにのみ適用されます。

そのほか、必須でないオプションは次のとおりです。

-clusterNodes、-nodes、-cn

この引数では、このリソースをホストできるクラスタの有効ノードを指定します。この値は、空白またはカンマで区切ったクラスタ・ノード名のリストです。特別な値であるdefaultを指定すると、すべてのノードが対象に含まれます。

-resourceParams、-params、-p

この引数では、このリソースのCRSプロパティを設定するための「名前=値」ペアを空白またはカンマで区切って指定します(例: as=1, rt=400)。

プロパティの名前と値の範囲を表E-2に示します。この表では、as、stおよびraを除くすべての数値は秒単位です。

-pfile、-pf

この引数では、データベースの起動に使用するデータベース・パラメータ・ファイルを指定します。特別な値である「nil」を指定すると、デフォルトのファイルが使用されます。dbinstanceコンポーネントにのみ有効です。

例

ascrsctl update -n ora.mydb.cfcdb -disk ohdisk -lsnr newlsnr
-p st=60,rt=60,pt=60

E.14 create/as

トピック

create/as - create as ASCRS resource

コマンド

ascrsctl create -name <string> -type as -componentHome <string>
[-componentIDs <string> [<string> ...]]
-vip <string> -disk <string> [<string> ...]
[-db <string> [<string> ...]]
[-as <string> [<string> ...]]
[options]

説明

このASCRSコマンドは、CRSでミドルウェア・リソースを作成(または登録)するときに使用します。

必須の引数は次のとおりです。

-name、-n

この引数では、作成するリソース名を指定します。

-type、-t

この引数では、リソースのタイプを指定します。その値はasにする必要があります。

-componentHome、-ch

この引数では、ターゲット設定された管理サーバー、管理対象サーバーまたはOPMN管理対象サーバーが含まれているWebLogicドメインの場所を指定します。

-vip

この引数では、ミドルウェア・サーバーが依存する仮想IPリソースを指定します。

-disk

この引数では、WebLogicソフトウェアをホストしている共有ディスク、WebLogicサーバーのドメイン・ディレクトリ、インスタンス・ホーム(OPMN管理対象コンポーネントが対象の場合)、およびこのリソースが直接依存している他の共有ディスクを指定します。1つの共有ディスクを複数の目的に使用する場合でも、指定するのは一度だけです。このパラメータの値は、空白またはカンマで区切ったASCRSディスク・リソース名のリストです。

必須でないオプション:

-componentIDs、-ci

この引数では、WebLogicドメインまたはOPMNインスタンスで管理されるサーバーの名前を指定します。この引数を指定しない場合やdefaultの値を指定した場合は、すべてのサーバーが対象に含まれます。

db

この引数では、このasリソースが直接依存するデータベース・リソースを指定します。

as

この引数では、このリソースが直接依存するasリソースを指定します。

-m

この引数では、WebLogicサーバーが使用する必要のある状態モニターを指定します。このオプションを指定しない場合やdefaultの値を指定した場合は、TCP pingモニターがすべての管理対象サーバー用に使用されます。ユーザー定義のモニターを使用するには、このオプションの後ろにモニター割当てのリストを記述します。たとえば、「-m AdminServer=mon1 wlsapp=mon2」という指定例では、AdminServerとwlsappは有効なサーバー名です。mon1とmon2は、CRS_HOME/ascrs/config/mconfig.xmlで定義された有効なモニター名です。

-clusterNodes、-nodes、-cn

この引数では、このリソースをホストできるクラスタの有効ノードを指定します。この値は、空白またはカンマで区切ったクラスタ・ノード名のリストです。指定しないと、すべてのノードが含まれます。

-resourceParams、-params、-p

この引数では、このリソースのCRSプロパティを設定するための「名前=値」ペアを空白またはカンマで区切って指定します(例: as=1, rt=400)。

プロパティの名前と値の範囲を表E-1に示します。この表では、as、stおよびraを除くすべての数値は秒単位です。これらのプロパティは、ASCRSの構成ファイルで構成できます。プロパティが構成されていない場合やこのオプションで指定されていない場合、デフォルト値が使用されます。

-policy

この引数では、どのリソース・パラメータ値を使用するかを指定します。これらのポリシーと値は、ASCRSの構成ファイルで使用できます。

有効な値はnormalまたはfastです。指定しないと、normalを指定したことになります。ただし、-resourceParamsの値が、ポリシーより常に優先されます。

例

UNIX:
ascrsctl create -n idm.weblogic -t as
-ch /sharedisk/fmw/user_projects/domains/IDMDomain
-vip idmvip -disk idmdisk

ascrsctl create -n idm.weblogic -t as
-ch /sharedisk/fmw/user_projects/domains/IDMDomain
-vip idmvip -disk idmdisk -p st=800,rt=800,pt=800

ascrsctl create -n idm.opmn -t as
-ch /sharedisk/fmw/asinst_1
-vip idmvip -disk idmdisk -p st=800,rt=800,pt=800

Windows:
ascrsctl create -n adminserver -t as
-ch c:\oracle\asdisk\fmw\user_projects\domains\adminserverDomain
-vip adminservervip -disk adminserverdisk

E.15 update/as

トピック

update/as - update as ASCRS resource

コマンド

ascrsctl update -name <string> [-type as] [-componentHome <string>]
[-componentIDs <string> [<string> ...]]
[-vip <string>] [-disk <string> [<string> ...]]
[-db <string> [<string> ...]]
[-as <string> [<string> ...]]
[options]

説明

このASCRSコマンドは、ASCRSで作成されたasリソースを更新するときに使用します。Windowsでは、OPMNリソースはサポートされていません。

必須の引数は次のとおりです。

-name、-n

この引数では、更新するリソース名を指定します。

必須でない引数は次のとおりです。

-type、-t

この引数では、リソースのタイプを指定します。その値はasにする必要があります。-typeオプションは、リソース名を正規の形式で指定した場合には省略できます。

-componentHome、-ch

この引数では、WebLogicドメインまたはOPMNインスタンス・ホームの場所を指定します。

-componentIDs、-ci

この引数では、WebLogicドメインまたはOPMNインスタンスで管理されるサーバーの名前を指定します。「default」の値を指定すると、すべてのサーバー名が対象に含まれます。

-vip

この引数では、このコンポーネントが依存する仮想IPリソースを指定します。

-disk

この引数では、このasリソースが直接依存している共有ディスク・リソースを指定します。この値は、空白またはカンマで区切ったディスク・リソース名のリストです。

-db

この引数では、このasリソースが直接依存するデータベース・リソースを指定します。「nil」の値を指定すると、これらの依存要素がすべて削除されます。

-as

この引数では、このリソースが直接依存するasリソースを指定します。「nil」の値を指定すると、これらの依存要素がすべて削除されます。

-m

この引数では、WebLogicサーバーが使用する必要のある状態モニターを指定します。defaultの値を指定した場合は、TCP pingモニターがすべての管理対象サーバー用に使用されます。モニター割当てを微調整するには、このオプションの後ろにモニター割当てのリストを記述し、たとえば、-m AdminServer=mon1 wlsapp=mon2では、AdminServerとwlsappは有効なサーバー名で、mon1とmon2は、CRS_HOME/ascrs/config/mconfig.xmlで定義された有効なモニター名です(mon1とmon2のかわりにdefaultも指定できます)。

-clusterNodes、-nodes、-cn

この引数では、このリソースをホストできるクラスタの有効ノードを指定します。この値は、空白またはカンマで区切ったクラスタ・ノード名のリストです。特別な値であるdefaultを指定すると、すべてのノードが対象に含まれます。

-resourceParams、-params、-p

この引数では、このリソースのCRSプロパティを設定するための「名前=値」ペアを空白またはカンマで区切って指定します(例: as=1, rt=400)。

プロパティの名前と値の範囲を表E-2に示します。この表では、as、stおよびraを除くすべての数値は秒単位です。

例

ascrsctl update -n myas -t as -vip newvip -disk instdisk wldisk
ascrsctl update -n ora.myas.cfcas -p st=800,rt=800,pt=800

F 分散Javaオブジェクト・キャッシュの構成

Javaオブジェクト・キャッシュ(JOC)を、Oracle Web Services Manager (WSM)を実行しているすべてのサーバー間、およびOracle WebCenterポータルのスペース・アプリケーションを実行しているすべてのサーバー間で構成します。この手順はオプションですが、ローカル・キャッシュを保持することでキャッシュを検索する必要がなくなるため、Oracle WSMのパフォーマンスが向上します。

F.1 Javaオブジェクト・キャッシュの構成

分散Javaオブジェクト・キャッシュを構成するには、MW_HOME/oracle_common/bin/configure-joc.pyスクリプト(管理対象サーバーでJOCを構成する場合に使用できるPythonスクリプト)を使用します。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが稼働中であることが求められます。

Oracle製品にJOCポートを構成する場合は、9988から9998のポートを使用することをお薦めします。

注意:

WLSTコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成した後で、構成を有効にするために、影響を受ける管理対象サーバーをすべて再起動します。

Oracle Web Services ManagerまたはSpacesアプリケーション用に分散Javaオブジェクト・キャッシュを構成する手順は、次のとおりです。その他のアプリケーションの場合は、必要に応じて関連するホスト、ポートおよびクラスタ名を置き換えてください。

1. コマンドラインのOracle WebLogic Scripting Tool(WLST)を使用して管理サーバーに接続します。

ORACLE_HOME/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構成に対して共通です。

Oracle Web Services Managerの場合:

Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : WSM_Cluster
Enter Discover Port : 9991

スペース・アプリケーションの場合:

Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : Spaces_Cluster
Enter Discover Port : 9988

次に示すのは、高可用性環境でconfigure-joc.pyを使用する際の手順です。

Oracle Web Services Managerの場合:

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_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

スペース・アプリケーションの場合:

execfile('MW_HOME/oracle_common/bin/configure-joc.py')
.
Enter Hostnames (eg host1,host2) : APPHOST1, APPHOST2
.
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を入力し、プロンプトが表示されたら管理対象サーバーと検出ポートを指定します。

Oracle Web Services Managerの場合:

Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WLS_WSM1:9991, WLS_WSM1:9991) : WLS_WSM1:9991,WLS_WSM2:9991

スペース・アプリケーションの場合:

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を入力し、プロンプトが表示されたら除外する管理対象サーバーの名前を入力します。

Oracle Web Services Managerの場合:

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

スペース・アプリケーションの場合:

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_SPACES3

- すべての管理対象サーバーに対して、分散モードを無効にします。
このスクリプトにより、指定されたクラスタのすべての管理対象サーバーへの配布が無効になります。分散モードを指定するように求められたら、falseを指定します。デフォルトでは、分散モードはtrueに設定されています。

Oracle WebLogic管理コンソールの「HAパワー・ツール」タブを使用して、Javaオブジェクト・キャッシュを構成することもできます(第16章「HAパワー・ツールの使用」を参照)。

CacheWatcherユーティリティを使用してJavaオブジェクト・キャッシュ構成を検証します。第F.2項「CacheWatcherの実行」を参照してください。

F.2 CacheWatcherの実行

CacheWatcherユーティリティを使用して、Javaオブジェクト・キャッシュの分散構成を検証できます。CacheWatcher自体が、キャッシュ・クラスタのメンバーになります。

この例では、クラスタ内の管理対象サーバーはWLS_Server1とWLS_Server2です。

- WLS_Server1はAPPHOST1上で稼働しています。

- APPHOST2上でCacheWatcherを起動します。

CacheWatcherを実行する手順は次のとおりです。

1. APPHOST2では次のスクリプトを実行します。

"java -classpath ORACLE_HOME/modules/oracle.javacache_
11.1.1/cache.jar:ORACLE_HOME/modules/oracle.odl_11.1.1/ojdl.jar oracle.ias.cache.CacheUtil
watch -config=DOMAIN_HOME/config/fmwconfig/servers/<Server_Name>/javacache.xml

説明:

- ORACLE_HOMEには、Oracle WebCenterポータルのインストール場所を使用します。たとえば、MW_HOME/Oracle_WC1を使用します。

- DOMAIN_HOMEには、MW_HOME/user_projects/domainsの下にあるドメインの場所のフルパスを使用します。

- Server_Nameは、管理対象サーバー名を指します。たとえば、WLS_Server2です。CacheWatcherは、この管理対象サーバーが使用するのと同じjavacache.xmlファイルを使用できます。

2. CacheWatcherのプロンプトで、lcと入力して[Enter]を押します。
グループ・ビューが表示されます。キャッシュ・メンバーの数を示します。CacheWatcherの実行例を次に示します。

java -classpath MW_HOME/modules/oracle.javacache_11.1.1/
cache.jar:MW_HOME/modules/oracle.odl_11.1.1/ojdl.jar
oracle.ias.cache.CacheUtil watch -config=DOMAIN_HOME
/config/fmwconfig/servers/WLS_Server_Server/javacache.xml"
cache> lc
VID:    2
Size:   2
Column: 0123456789
CL:     JJ
GRP0:   11
...
Member Table:
#1. J57161:145.87.9.15:86AAC2E:11B28D57BE4:-7FFE, 0
#2. J35578:145.87.9.14:-9E92850:11B28D5F7E0:-7FFF, 1

CacheWatcherを各ホストで起動した後、ビューから2つのメンバーを検索します。

注意:

CacheWatcher自体は分散キャッシュ・インスタンスと見なされます。CacheWatcherシェルを終了するには、exitと入力して[Enter]を押します。

G MDSに対する分散通知の構成

MDSデータベース・リポジトリには、MetadataObjectとそれらのコンテンツをキャッシュするためにJavaオブジェクト・キャッシュを使用する機能があります。MDSを使用する各ノードには独自のJavaオブジェクト・キャッシュ・インスタンスがあり、そのノードによってリポジトリからMetadataObjectが読み取られるとそれらがキャッシュされ、そのMetadataObjectを構成するドキュメントに対するローカルな更新が行われるとそのローカル・キャッシュでそれらが無効化されます。

MDSでは、 MetadataObjectをレプリケートするために分散Javaオブジェクト・キャッシュが使用されることはありません。MDSは、そのリポジトリにローカルな変更がフラッシュされるたびに、他のノードによって行われたリポジトリに対する変更を検出し、それに従って関連するローカル・キャッシュ・エントリを無効化するようになります。さらに、各クラスタ・メンバーによって30秒ごとに(これはデフォルトの間隔であり、構成可能です)リポジトリへのポーリングが行われ、ドキュメントが変更されたかどうかが検知され、同様の方法でローカル・キャッシュ・エントリが無効化されます。

ただし、MDSデータベース・リポジトリには、そのリポジトリ内のドキュメントがクラスタ・メンバーによって変更されたときにクラスタワイドの通知を送信する機能があります。この機能が有効化されている場合は、すべてのクラスタ・メンバーは、ローカル・コミットやリポジトリのポーリングが実行されるまで待つことなく、変更が行われた時点でドキュメントに対する変更を通知されます。したがって、高可用性環境では、パフォーマンス上の理由により、分散通知を有効化することをお薦めします。各クラスタ・メンバー上で分散Javaオブジェクト・キャッシュを構成すると、分散通知が使用可能になります。クラスタ・メンバーがドキュメントに対する変更の通知を受信すると、そのドキュメントの現在のローカル・バージョンは無効化され、更新されたドキュメントがかわりに使用されます。

この機能が動作するためには、各ノードでJavaオブジェクト・キャッシュを構成し、各ノードがそのリポジトリを指すために使用するJNDI名をすべてのノードで同一にして、ポーリングを有効化する必要があります(これはデフォルトで有効化されていますが、無効化しないでください)。

クラスタ内のノード上での分散Javaオブジェクト・キャッシュの構成の説明は、第F.1項「Javaオブジェクト・キャッシュの構成」を参照してください。

Copyright © 2012, Oracle and/or its affiliates. All rights reserved.