Oracle® Fusion Middleware

Oracle Identity and Access Management高可用性ガイド

11gリリース2 (11.1.2.2)

B69538-05(原本部品番号:E28391-08)

2014年5月

管理者や開発者など、高可用性を扱う方を対象としており、高可用性の概要について説明し、また高可用性を目的としてOracle Fusion Middlewareをデプロイおよび管理するための管理手順と構成手順についても説明します。

Oracle Fusion Middleware Oracle Identity and Access Management高可用性ガイド11gリリース2 (11.1.2.2)

B69538-05

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

原本著者: Christine Ford

原本協力者: Fermin Castro、Michael Blevins、Pradeep Bhat、Michael Rhys、Samrat Ray、Jeni Ferns、Richard Delval、Bharath K.Reddy、Susan Kornberg、Joe Paul、Ajay Keni、Amit Sharma、Vasuki Ashok、Olaf Stullich、Jingjing Wei、Olfat Aly、Eileen He、Ramaprakash Sathyanarayan、Apurv Chandra、Atika Jain、Buddhika Kottahachchi、Arun Theebaprakasam、Rajiv Jaisankar、Vinay Kalra、Daniel Shih、Pratima Gogineni、Russ Hodgson、Christopher Johnson、Pramodini Gattu、Gururaj BS、Ben Gelernter、Peter Jacobsen

協力者: Van Sioung Ng Yan Tun、Eric Cloney、Fiona Zheng、Ruchica Behl、David J.Jones、Ellen Desmond、Don Biasotti、Vinaye Misra、Dhaval Shah、Herbert Stiel、Albert Tam、Pushkar Kapasi、Shail Goel、Rahul Menezes、Satheesh Amilineni、Ratheesh Pai、Jan Carlin

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

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

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次の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およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

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

目次

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

1 高可用性の概要

- 1.1 高可用性とは

- 1.1.1 高可用性の問題

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

- 1.2 このガイドの使用方法

- 1.2.1 このガイドでの最新情報

- 1.2.2 Oracle Fusion Middlewareドキュメント・ライブラリ

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

第I部 高可用性の特徴と機能

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.2 ファイアウォールのタイムアウトからのアイドル接続の保護

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

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

第II部 Oracle Identity and Access Managementコンポーネントの高可用性の構成

5 Oracle Identity Managerコンポーネントの高可用性の構成

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

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

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

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

- 5.1.4 Oracle Identity Managerの起動と停止

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

- 5.1.6 外部依存性

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

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

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

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

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

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

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

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

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

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

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

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

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

- 5.3.3 Oracle Platform Security Servicesスキーマのアップグレード

- 5.3.4 ドメイン用のデータベース・セキュリティ・ストアの構成

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

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

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

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

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

- 5.3.6 OIMHOST1でのOracle Identity Managerの構成

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

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

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

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

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

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

- 5.3.9 OIMHOST2へのOracle Identity Managerの伝播

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

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

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

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

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

- 5.3.12 SOAサーバーのデフォルト・コンポジットの更新

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

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

- 5.3.14.1 サーバー移行リース表のユーザーと表領域の設定

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

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

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

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

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

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

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

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

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

- 5.3.18.1 前提条件

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

- 5.3.19 Oracle HTTP Serverの構成の検証

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

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

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

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

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

6 Oracle Access Management Access Managerコンポーネントの高可用性の構成

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

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

- 6.1.1.1 Access Managerの状態情報

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

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

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

- 6.1.1.2.3 Access Managerの外部依存性

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

- 6.2 Access Managerの高可用性の概要

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

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

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

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

- 6.2.2.1 WebLogic Serverのクラッシュ

- 6.2.2.2 ノード障害

- 6.2.2.3 データベース障害

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

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

- 6.3.2 リポジトリ作成ユーティリティの実行によるデータベース・スキーマの作成

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

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

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

- 6.3.4.2 OAMHOST1におけるOracle Access Managerの構成

- 6.3.5 データベース・セキュリティ・ストアの構成

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

- 6.3.7 OAMHOST1の起動

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

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

- 6.3.7.3 OAMHOST1上のAccess Managerの起動

- 6.3.8 OAMHOST1の検証

- 6.3.9 OAMHOST2でのOAMの構成

- 6.3.10 OAMHOST2の起動

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

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

- 6.3.10.3 OAMHOST2上のAccess Managerの起動

- 6.3.11 OAMHOST2の検証

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

- 6.3.12.1 Oracle HTTP Server構成の更新

- 6.3.12.2 Oracle HTTP Serverの再起動

- 6.3.12.3 OAM Serverにロード・バランサを認識させる

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

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

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

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

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

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

- 6.3.14 Access Managerの構成の検証

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

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

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

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

7 Oracle Adaptive Access Managerコンポーネントの高可用性の構成

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

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

- 7.1.1.1 Oracle Adaptive Access Managerの状態情報

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 7.3.4.1.1 OAAMHOST1におけるOracle Access Managerの構成

- 7.3.5 ドメイン用のデータベース・セキュリティ・ストアの構成

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

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

- 7.3.8 OAAMHOST1の起動

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

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

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

- 7.3.9 OAAMHOST1の検証

- 7.3.10 OAAMHOST2におけるOracle Adaptive Access Managerの構成

- 7.3.11 OAAMHOST2の起動

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

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

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

- 7.3.12 OAAMHOST2の検証

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

- 7.3.13.1 Oracle HTTP Server構成の更新

- 7.3.13.2 Oracle HTTP Serverの再起動

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

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

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

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

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

8 Oracle Access Management Security Token Serviceの高可用性の構成

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

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

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

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

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

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

- 8.2.2.1 Security Token Serviceの起動と停止

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

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

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

- 8.2.4 外部依存性

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

- 8.4 Security Token Serviceの高可用性の検証

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

- 8.5.1 障害検出と再起動

- 8.5.2 ノード障害

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

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

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

- 8.9 その他の考慮事項

9 Identity Federationコンポーネントの高可用性の構成

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

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

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

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

- 9.1.1.3 リクエスト・フロー

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

- 9.1.1.5 外部依存性

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

- 9.2 Identity Federationの高可用性の概要

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

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

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

- 9.2.2 Identity Federationの前提条件

- 9.3 Identity Federationの高可用性の構成

- 9.3.1 ホスト名およびポートの設定

- 9.3.2 プロバイダID値の変更

- 9.3.3 Identity Federationのパラメータのチューニング

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

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

10 Oracle Entitlements Serverの高可用性の構成

- 10.1 Oracle Entitlements Serverの高可用性の概要

- 10.1.1 Oracle Entitlements Serverの高可用性アーキテクチャ

- 10.1.1.1 Oracle Entitlements Serverの管理サーバーの高可用性

- 10.1.1.2 セキュリティ・モジュール(OESクライアント)/ポリシー情報ポイントの高可用性

- 10.1.1.3 Webサービスに対するプロキシ・モードでのセキュリティ・モジュール/制御プッシュ・モードの高可用性でのRMIセキュリティ・モジュール

- 10.1.1.4 Webサービスに対するプロキシ・モードでのセキュリティ・モジュール/制御プル・モードの高可用性でのRMIセキュリティ・モジュール

- 10.1.1.5 Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの高可用性

- 10.1.2 Oracle Entitlements Serverのセキュリティ・モジュールの高可用性

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

- 10.1.4 フェイルオーバーに関する考慮事項

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

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

- 10.1.5.2 ノード障害

- 10.1.5.3 データベース障害

- 10.1.6 Oracle Entitlements Serverクラスタの起動と停止

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

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

- 10.2 Oracle Entitlements Serverの高可用性の構成

- 10.2.1 Oracle Entitlements Serverの構成の前提条件

- 10.2.2 OESHOST1でのOES管理サーバー用WebLogicドメインの構成

- 10.2.3 構成後および検証

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

- 10.2.3.2 WebLogic管理サーバーの検証

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

- 10.2.3.3.1 リモート・サーバーへの変更内容の伝播

- 10.2.3.4 リモート・ホストでのノード・マネージャの起動

- 10.2.3.5 WebLogic管理サーバーの停止と起動およびoes_server1とoes_server2の起動

- 10.2.4 制御プッシュ・モードのOESのセキュリティ・モジュールをOracle Entitlements Server管理サーバーを使用して高可用性に構成

- 10.2.5 プロキシ・モードのOracle Entitlements Serverのセキュリティ・モジュールをPDPを使用して高可用性に構成

- 10.2.6 Oracle Entitlements Serverのポリシー情報ポイントの高可用性の構成

- 10.2.7 WebLogicでのOracle Entitlements Server Webサービスのセキュリティ・モジュールの高可用性の構成

- 10.2.8 Oracle Entitlements Server WebLogicセキュリティ・モジュールの高可用性の構成

- 10.2.9 制御プル・モードおよび非制御モードのセキュリティ・モジュールでのRACデータ・ソースの使用

- 10.2.10 Web Tierと連携するためのOracle Entitlements Serverの構成

- 10.2.10.1 前提条件

- 10.2.10.2 OESの管理対象サーバーをフロントエンドするためのOracle HTTP Serverの構成

- 10.2.10.3 Oracle HTTP Serverの構成の検証

11 Mobile and Socialの高可用性の構成

- 11.1 Oracle Access Management Mobile and Socialコンポーネント・アーキテクチャ

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

- 11.1.2 コンポーネントのライフサイクル

- 11.1.3 コンポーネントの構成アーティファクト

- 11.1.4 Mobile and Socialデプロイメント・アーティファクト

- 11.2 Mobile and Socialコンポーネントの特性

- 11.3 Mobile and Socialの高可用性の概要

- 11.3.1 Mobile and Socialの高可用性アーキテクチャ

- 11.3.2 Mobile and Socialの高可用性とノードのフェイルオーバー

- 11.3.2.1 ロード・バランシングの要件および特性

- 11.3.2.2 セッション状態レプリケーションとフェイルオーバー

- 11.3.2.3 クライアント・アプリケーションの起動

- 11.3.2.3.1 障害検出と再起動

- 11.4 Mobile and Socialの高可用性の構成

12 Oracle Privileged Account Managerコンポーネントの高可用性の構成

- 12.1 Oracle Privileged Account Managerコンポーネント・アーキテクチャ

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

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

- 12.1.3 セッションの状態

- 12.1.4 外部依存性

- 12.1.5 デプロイメント・アーティファクト

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

- 12.2 Oracle Privileged Account Managerの高可用性の概要

- 12.3 Oracle Privileged Account Managerの高可用性アーキテクチャ

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

- 12.4 Oracle Privileged Account Managerの高可用性およびノード障害

- 12.5 Oracle Privileged Account Managerの高可用性の構成

- 12.5.1 適切なデプロイメント環境

- 12.5.2 デプロイされるコンポーネント

- 12.5.3 依存性

- 12.5.4 高可用性の構成手順

- 12.5.4.1 OPAMHOST1でのOracle Identity and Access Managementの構成

- 12.5.4.1.1 データベース・セキュリティ・ストアの構成

- 12.5.4.1.2 OPAMHOST1上での管理サーバーの起動

- 12.5.4.2 OPAMHOST1の起動

- 12.5.4.2.1 OPAMHOST1でのOracle Privileged Account Managerの起動

- 12.5.4.3 OPAMHOST2でのOPAMの構成

- 12.5.4.4 OPAMHOST2の起動

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

- 12.5.5.1 SSLの構成

- 12.5.5.2 Oracle HTTP Server構成の更新

- 12.5.5.3 Oracle HTTP Serverの再起動

13 Oracle Identity Navigatorの高可用性の構成

- 13.1 Oracle HTTP Server構成の更新

- 13.2 Oracle HTTP Serverの再起動

14 Oracle Unified Directory

15 Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ

- 15.1 Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジの概要

- 15.2 アクティブ/パッシブ・デプロイメントのためのOracle Fusion Middlewareの構成

- 15.2.1 コールド・フェイルオーバー・クラスタの要件

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

- 15.2.3 Oracle Fusion Middlewareインフラストラクチャ・コンポーネントの変換

- 15.2.3.1 管理サーバーのトポロジ1

- 15.2.3.2 トポロジ1のインストール手順

- 15.2.3.3 管理サーバーのトポロジ2

- 15.2.3.4 トポロジ2のインストール手順

- 15.2.3.5 コールド・フェイルオーバー・クラスタ用の管理サーバーの変換

- 15.2.3.6 Oracle WebLogic管理対象サーバーの変換

- 15.2.3.6.1 Fusion Middleware管理コンソールによるOracle WebLogic管理対象サーバーの変換

- 15.2.3.6.2 WLSTコマンド行によるOracle WebLogic管理対象サーバーの変換

- 15.2.3.7 ノード・マネージャの変換

- 15.2.3.8 Oracle Process Management and Notification Serverの変換

- 15.2.3.9 OracleインスタンスのOracle Enterprise Managerの変換

- 15.2.3.10 Web層のコンポーネントとクライアントの変換

- 15.2.3.10.1 Oracle HTTP Serverの変換

- 15.2.3.10.2 Oracle Web Cacheの変換

- 15.2.4 Oracle Fusion Middlewareコンポーネントの変換

- 15.2.4.1 Oracle Virtual Directoryおよびそのクライアントの変換

- 15.2.4.1.1 Oracle Virtual Directoryの変換

- 15.2.4.1.2 キーストアの新しい鍵の生成

- 15.2.4.1.3 Oracle Virtual Directoryクライアントの変換

- 15.2.4.2 Oracle Directory Integration PlatformおよびOracle Directory Services Managerとそれぞれのクライアントの変換

- 15.2.4.2.1 Oracle Directory Integration PlatformとOracle Directory Services Managerの変換

- 15.2.4.2.2 Oracle Directory Integration PlatformとOracle Directory Services Managerのクライアントの変換

- 15.2.4.3 Oracle Identity Federationおよびそのクライアントの変換

- 15.2.4.3.1 Oracle Identity Federationの変換

- 15.2.4.3.2 Oracle Identity Federationクライアントの変換

- 15.2.4.4 Oracle Access Managerおよびそのクライアントの変換

- 15.2.4.4.1 Oracle Access Managerの変換

- 15.2.4.4.2 Oracle Access Managerクライアントの変換

- 15.2.4.5 Oracle Adaptive Access Managerおよびそのクライアントの変換

- 15.2.4.5.1 Oracle Adaptive Access Managerの変換

- 15.2.4.5.2 Oracle Adaptive Access Managerクライアントの変換

- 15.2.4.6 Oracle Identity Managerおよびそのクライアントの変換

- 15.2.4.6.1 Oracle Identity Managerの変換

- 15.2.4.6.2 Oracle Identity Managerクライアントの変換

- 15.2.4.7 シングル・サインオンの再登録(必要な場合)

- 15.2.5 Fusion Middlewareフェイルオーバーの追加のアクション

- 15.2.6 Oracle Databaseの変換

- 15.2.6.1 データベース・インスタンスの考慮事項

- 15.3 Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジ例

- 15.3.1 トポロジ例1

- 15.3.2 トポロジ例2

- 15.3.3 トポロジ例3

- 15.4 コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換

- 15.4.1 変換後トポロジ

- 15.4.2 コールド・フェイルオーバー・クラスタ変換の手順

第III部 付録

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 Oracle Identity Managementのワークブック

- C.1 Oracle Identity Managementのワークブック表

D ascrsctlのオンライン・ヘルプ

- D.1 start

- D.2 stop

- D.3 status

- D.4 switch

- D.5 delete

- D.6 create/disk

- D.7 update/disk

- D.8 create/vip

- D.9 update/vip

- D.10 create/dblsnr

- D.11 update/dblsnr

- D.12 create/db

- D.13 update/db

- D.14 create/as

- D.15 update/as

E MDSに対する分散通知の構成

図一覧

- 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 Identity Managerコンポーネント・アーキテクチャ

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

- 6-1 Access Managerの単一インスタンス・アーキテクチャ

- 6-2 Access Managerの高可用性アーキテクチャ

- 7-1 Oracle Adaptive Access Managerの単一インスタンス・アーキテクチャ

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

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

- 8-2 Security Token Serviceのランタイム・プロセス

- 9-1 Identity Federationアーキテクチャ

- 9-2 高可用性アーキテクチャのIdentity Federation

- 10-1 Oracle Entitlements Serverの管理サーバーの高可用性アーキテクチャ

- 10-2 セキュリティ・モジュール/ポリシー情報ポイントの高可用性

- 10-3 RACおよびロード・バランサを使用するOracle Entitlements Server PIP

- 10-4 WebLogic Serverデプロイメント上のWebサービスのセキュリティ・モジュール

- 10-5 スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメント

- 10-6 RMIのセキュリティ・モジュールのデプロイメント

- 10-7 WebLogic Server上のWebサービスのセキュリティ・モジュール

- 10-8 スタンドアロンのWebサービスのセキュリティ・モジュール

- 10-9 RMIのセキュリティ・モジュール

- 10-10 Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュール、制御プッシュ・モード

- 10-11 Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの制御プル・モード/非制御モード

- 11-1 Mobile and Socialコンポーネント・アーキテクチャ

- 11-2 Mobile and Socialの高可用性アーキテクチャ

- 12-1 Oracle Privileged Account Managerコンポーネント・アーキテクチャ

- 12-2 高可用性アーキテクチャのOracle Privileged Account Manager

- 15-1 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ1

- 15-2 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ2

- 15-3 コールド・フェイルオーバー・クラスタのトポロジ例1

- 15-4 コールド・フェイルオーバー・クラスタのトポロジ例2

- 15-5 コールド・フェイルオーバー・クラスタのトポロジ例3

- 15-6 コールド・フェイルオーバー・クラスタの開始トポロジ例

- 15-7 変換後の可能なトポロジ

表一覧

- 1-1 可用性の割合と対応する停止時間の値

- 1-2 11g R2高可用性ガイドに記載されている11g R2コンポーネント

- 1-3 11g R2高可用性ガイドに記載されていない11g R2コンポーネント

- 1-4 11gリリース1高可用性ガイドに記載されているコンポーネント

- 1-5 Oracle Fusion Middlewareドキュメント・ライブラリ

- 1-6 Oracle Fusion Middlewareドキュメントで提供される高可用性情報

- 2-1 計画停止のソリューション

- 2-2 計画外停止のソリューション

- 4-1 推奨されるマルチ・データ・ソース構成

- 4-2 XAデータ・ソース構成

- 4-3 XA以外のデータ・ソース構成

- 4-4 SCANの実行時の内容と制限

- 5-1 各マルチ・データ・ソース・スキーマのスキーマ所有者とパスワードの入力

- 5-2 JMSシステム・リソースに対して選択する値

- 5-3 PATH環境変数に必要なファイル

- 5-4 WLS_OIM1、WLS_OIM2、WLS_SOA1、WLS_SOA2サーバー移行

- 9-1 RDBMS一時ストアの非同期設定

- 9-2 RDBMSアーティファクトのメモリー・キャッシュ設定

- 9-3 RDBMSのメモリー・キャッシュ設定

- 10-1 Oracle Entitlements Serverのフェイルオーバーのシナリオと動作

- 11-1 Mobile and Socialコンポーネントの構成ファイル

- 11-2 Mobile and Social製品のデプロイメントの場所

- 12-1 OPAMデプロイメント・アーティファクト

- C-1 アプリケーションのURL

- C-2 仮想IPアドレス

- C-3 汎用ファイルの場所

- C-4 IDMHOSTnのファイルの場所

- C-5 OIDHOSTnのファイルの場所

- C-6 OVDHOSTnのファイルの場所

- C-7 OAMHOSTnのファイルの場所

- C-8 OIMHOSTnのファイルの場所

- C-9 OAAMHOSTnのファイルの場所

- C-10 OIFHOSTnのファイルの場所

- C-11 Web層のファイルの場所

- C-12 Identity Managementのアーティファクト

- C-13 Oracle Identity Federation用の認証LDAPのアーティファクト

- C-14 Oracle Identity Federation用のLDAPユーザー・データ・ストアのアーティファクト

- C-15 Oracle Identity Federation用のLDAPフェデレーション・データ・ストアのアーティファクト

- C-16 Oracle Identity Federation用のRDBMSユーザー・データ・ストアのアーティファクト

- C-17 Oracle Identity Federation用のRDBMSフェデレーション・データ・ストアのアーティファクト

- C-18 Oracle Identity Federation用のRDBMS一時データ・ストアのアーティファクト

- C-19 メタデータ・リポジトリのデータベース情報

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

- C-21 ポート情報

- D-1 createコマンドのリソース値

- D-2 updateコマンドのリソース値

はじめに

「はじめに」には次の項が含まれます:

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Fusion Middleware Oracle Identity and Access Management高可用性ガイド』は、管理者や開発者など、高可用性要件を使用して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/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

- Oracle Fusion Middlewareコンセプト

- Oracle Fusion Middleware管理者ガイド

表記規則

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

規則

意味

太字

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

イタリック

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

固定幅

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

1 高可用性の概要

高可用性アーキテクチャは、エンタープライズ・デプロイメントの主要な要件の1つです。Oracle Fusion Middlewareは、計画外停止からそのコンポーネントとアプリケーションを保護し、計画停止を最小限に抑える広範な高可用性機能を備えています。

このドキュメントで説明するソリューションと手順は、Oracle Fusion Middlewareコンポーネントのシングル・ポイント障害をなくし、停止時間をなくすか、または最小限に抑えるように設計されています。これらのソリューションを使用すると、Oracle Fusion Middlewareにデプロイされているアプリケーションがビジネス目標の達成に必要な可用性を実現できるようになります。

Oracle Identity and Access Managementは、エンタープライズ・リソース間でユーザー・アイデンティティのエンドツーエンド・ライフサイクルを企業が管理できるようにします。アプリケーションをより高速にデプロイでき、エンタープライズ・リソースに対してもっとも詳細な保護を適用できるなど、その他にもいろいろできます。このガイドでは、アクティブ/アクティブ構成における高可用性のためのIdentity and Access Management (IAM)製品の構成方法について説明します。

この章では、高可用性とその重要性についてOracle Fusion Middlewareの観点から説明します。この章の項目は次のとおりです。

- 第1.1項「高可用性とは」

- 第1.2項「このガイドの使用方法」

- 第1.3項「他のドキュメントで提供される高可用性情報」

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.2 このガイドの使用方法

このガイドでは、11gリリース2 (11.1.2.2)におけるOracle Fusion Middlewareコンポーネントのアーキテクチャ、相互作用および依存関係、またこれらを高可用性アーキテクチャにデプロイする方法について説明します。

この項では、このガイドでの変更内容および11gリリース1と2のコンポーネントに関する情報が記載されている場所について説明します。

- 第1.2.1項「このガイドでの最新情報」

- 第1.2.2項「Oracle Fusion Middlewareドキュメント・ライブラリ」

1.2.1 このガイドでの最新情報

高可用性ガイドの以前のバージョンでは、Oracle SOA SuiteなどのIdentity and Access Management (IAM)コンポーネントではないコンポーネントについて説明していました。ガイドのこのバージョンでは、Oracle Identity and Access Management 11gリリース2のコンポーネントについてのみ説明します。詳細は、次の表を参照してください。

注意:

Oracle Forms and Reports 11gリリース2の高可用性ガイドはありません。11gリリース1の高可用性ガイドの「Oracle Portal、Forms、ReportsおよびDiscovererの高可用性の構成」の章を参照することをお薦めします。

- 表1-2では、このガイドに記載されている11g R2コンポーネントを示します。

- 表1-3では、このガイドに記載されていない11g R2コンポーネントを示します。

- 表1-4では、リリース1の『Oracle Fusion Middleware Oracle Identity and Access Management高可用性ガイド』に記載されているコンポーネントを示します。

表1-2 11g R2高可用性ガイドに記載されている11g R2コンポーネント

11gリリース2 (11.1.2.2)コンポーネント

参照先

Oracle Identity Manager (OIM)

第5章「Oracle Identity Managerコンポーネントの高可用性の構成」

Oracle Access Management Access Manager (OAM)

第6章「Oracle Access Management Access Managerコンポーネントの高可用性の構成」

Oracle Adaptive Access Manager (OAAM)

第7章「Oracle Adaptive Access Managerコンポーネントの高可用性の構成」

Oracle Access Management Security Token Service (STS)

第8章「Oracle Access Management Security Token Serviceの高可用性の構成」

Oracle Access Management Identity Federation (IF)

第9章「Identity Federationコンポーネントの高可用性の構成」

Oracle Entitlements Server (OES)

第10章「Oracle Entitlements Serverの高可用性の構成」

Oracle Access Management Mobile and Social

第11章「Mobile and Socialの高可用性の構成」

Oracle Privileged Account Manager (OPAM)

第12章「Oracle Privileged Account Managerコンポーネントの高可用性の構成」

Oracle Identity Navigator (OIN)

第13章「Oracle Identity Navigatorの高可用性の構成」

Oracle Unified Directory (OUD)

第14章「Oracle Unified Directory」

表1-3 11g R2高可用性ガイドに記載されていない11g R2コンポーネント

11gリリース2 (11.1.2.2)コンポーネント

『Oracle Fusion Middleware高可用性ガイド11gリリース1』で参照する章

Oracle Forms and Reports

Oracle Portal、Forms、ReportsおよびDiscoverer

11gリリース2 (11.1.2.2)でリリースされていない残りのすべてのOracle Fusion Middleware製品については、最新の『Oracle Fusion Middleware高可用性ガイド11gリリース1』を参照してください。表1-4では、11gリリース1で説明しているコンポーネントを示します。

表1-4 11gリリース1高可用性ガイドに記載されているコンポーネント

コンポーネント

『Oracle Fusion Middleware高可用性ガイド11gリリース1』で参照する章

Oracle SOA Suite (Oracle SOAサービス・インフラストラクチャ、Oracle BPEL Process Manager、Oracle BPM Suite、Oracle Mediator、Oracle JCA Adapter、Oracle B2B、Oracle Web Services Manager (WSM)、Oracle User Messaging Service (UMS)を含む)

Oracle SOA Suiteの高可用性の構成

Oracle ADFおよびOracle WebCenter Portal

Oracle ADFおよびOracle WebCenter Portalの高可用性の構成

Oracle Data Integrator (ODI)

Oracle Data Integrator (ODI)の高可用性の構成

Oracle Business Intelligence (BI)およびEPM

Oracle Business IntelligenceおよびEPMの高可用性の構成

Oracle Web Tier

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

Oracle WebCenter Content

WebCenter Contentの高可用性の構成

Oracle PortalおよびDiscoverer

Oracle Portal、Forms、ReportsおよびDiscovererの高可用性の構成

1.2.2 Oracle Fusion Middlewareドキュメント・ライブラリ

この項では、実行中のOracle Fusion Middlewareリリースのドキュメント・ライブラリへのリンクを示します。

表1-5 Oracle Fusion Middlewareドキュメント・ライブラリ

実行中のリリース

ドキュメント・ライブラリの参照先

Oracle Fusion Middleware 11gリリース1

リリース1 (11.1.1.8)

Oracle Fusion Middleware 11gリリース2 (11.1.2.2)

リリース2 (11.1.2.2)

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

表1-6に、高可用性情報について記述しているOracle Fusion Middlewareのガイド(このガイド以外)を示します。この情報は、Oracle Fusion Middlewareの各種コンポーネントの高可用性に関連するものです。

表1-6 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 Portal

Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイド

Oracle Fusion Middleware Oracle WebCenterインストレーション・ガイド

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

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管理者ガイド

第I部

高可用性の特徴と機能

第I部では、Oracle Fusion Middlewareの高可用性の特徴、機能およびデータベース・アクセスについて説明します。

この部は次の章で構成されています。

- 第2章「Oracle Fusion Middlewareの高可用性フレームワーク」

- 第3章「WebLogic Serverの高可用性」

- 第4章「可用性の高いOracle Databaseアクセスの考慮事項」

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コンポーネントは、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環境には、次が含まれます。

- WebLogic Serverドメイン: 1つの管理サーバーと1つ以上の管理対象サーバーが含まれます。

- 1つ以上のシステム・コンポーネント・ドメイン(環境にシステム・コンポーネントが含まれている場合)。

- Oracle Metadata Repository(インストールしたコンポーネントで必要な場合)。

図2-1に、Oracle Fusion Middlewareの環境(1つの管理サーバーと2つの管理対象サーバーを含むOracle WebLogic Serverドメイン、システム・コンポーネント・ドメイン、およびOracle Metadata Repositoryで構成されています)を示します。

図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コンポーネントやその他のリソースをデプロイして、管理サーバーは構成および管理の目的にのみ使用します。

ドメイン内の管理対象サーバーは、クラスタにグループ化できます。

WebLogic Serverドメインは、システム・コンポーネント・ドメインと同格です。どちらにも、Oracleホームの外部に固有の構成があります。

WebLogic Serverドメインのディレクトリ構造とWebLogic Serverホームのディレクトリ構造は別です。場所はどこでもよく、Middlewareホーム・ディレクトリ内にある必要はありません。

図2-2に、1つの管理サーバー、3つのスタンドアロンの管理対象サーバー、およびクラスタ化された3つの管理対象サーバーで構成される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 Portalなどのコンポーネント、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 Portalなど、他のコンポーネントを追加する場合には、ドメイン内に追加の管理対象サーバーを作成し、追加するコンポーネント用のドメイン・テンプレートを使用して、ドメインを拡張できます。

アプリケーションのパフォーマンス、スループットまたは高可用性の向上が要求される本番環境では、クラスタとして動作するように複数の管理対象サーバーを構成できます。クラスタとは、同時に稼働し、協調動作によってスケーラビリティと信頼性の向上を実現する、WebLogic Serverの複数のサーバー・インスタンスの集合です。クラスタでは、(単一の管理対象サーバーでなく)管理対象サーバーごとに、ほとんどのリソースおよびサービスがまったく同じようにデプロイされるため、フェイルオーバーとロード・バランシングが可能になります。1つのドメインには、複数のWebLogic Serverクラスタが存在していても、クラスタとして構成されていない複数の管理対象サーバーが存在していてもかまいません。管理対象サーバーがクラスタ化されている場合とされていない場合の重要な違いは、フェイルオーバーとロード・バランシングに対するサポートです。これらの機能は、管理対象サーバーがクラスタ化されている場合にのみ利用できます。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のWebLogic Serverのクラスタリングの理解に関する項

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

ノード・マネージャは、WebLogic Serverとは別のプロセスとして稼働するJavaユーティリティであり、これを使用すると、管理サーバーを基準とした場所に関係なく、管理対象サーバーに対して共通操作を実行できます。ノード・マネージャを使用するかどうかはオプションですが、高可用性を要求するアプリケーションがWebLogic Server環境でホストされている場合には、ノード・マネージャを使用すると貴重な利点が得られます。

管理対象サーバーをホストするシステムでノード・マネージャを実行する場合、管理コンソールまたはコマンド行を使用して、管理対象サーバーをリモートで起動または停止できます。ノード・マネージャを使用して、予期しない障害が発生した後に、管理対象サーバーを自動的に再起動することもできます。

関連項目:

Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド

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

システム・コンポーネント・ドメインには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどのシステム・コンポーネントが1つ以上含まれています。システム・コンポーネント・ドメイン内のシステム・コンポーネントは、同じシステム上にある必要があります。システム・コンポーネント・ドメイン・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルが格納されています。

システム・コンポーネント・ドメインは、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ファイルや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に示すように、このトポロジは複数層アーキテクチャを表しています。ユーザーはクライアント層からシステムにアクセスします。リクエストはハードウェア・ロード・バランサを通過し、そこで、Web層のOracle HTTP ServerおよびOracle Web Cacheが稼働しているWebサーバー・クラスタにルーティングされます。Webサーバーでは、プロキシ・プラグイン(mod_wl_ohs.conf)を使用して、リクエストをアプリケーション層のWebLogicクラスタにルーティングします。次に、アプリケーション層のWebLogicクラスタで稼働しているアプリケーションが、データ層のデータベース・クラスタと対話して、リクエストに応じます。

アーキテクチャ全体で、シングル・ポイント障害はありません。第15.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.conf)は、様々な管理対象サーバーの実行時の可用性、および状態のレプリカが保持される管理対象サーバーの場所を認識しています。プライマリ管理対象サーバーが使用できなくなると、プラグインによって、アプリケーションが使用可能なサーバーにリクエストがルーティングされます。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インスタンスが使用できなくなったことが原因で発生した、サービス、データまたはトランザクションの消失に対する組込みの保護が用意されています。これを実現するには、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を配置するアーキテクチャをお薦めします。

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では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。Middlewareホームとドメイン・ディレクトリは、ある時点でノード1またはノード2にマウントされている共有ディスク上にあります。Middlewareホームとドメイン・ディレクトリは両方とも、同じ共有ディスク上、またはいっしょにフェイルオーバーできる複数の共有ディスク上にあります。複数のアプリケーションまたは環境用に複数のFusion Middlewareドメインがある企業では、管理サーバーの高可用性にはこのトポロジが最適です。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。それぞれの管理サーバーでは、その仮想IPおよび一連の共有ディスクを使用して、ドメイン・サービスの高可用性を実現できます。

アクティブ/パッシブの概要およびOracle Cold Failover Clustersの構成手順の詳細は、第15章「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.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の高可用性」

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に示されているクラスタの起動時に発生する主要な手順は、次のとおりです。

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 障害が発生したサーバーの自動移行

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 サーバー全体の手動移行

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を手動で再起動できます。

予期しないマシン障害後に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. 「[server_name]の設定」ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。

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インスタンスの正常な停止を提供します。また、アフィニティ機能もあります。

Oracle RACデータベースの使用時には、GridLinkデータ・ソースを使用することをお薦めします。その他のデータベースの場合は、高可用性を確保するためにマルチ・データ・ソースを使用してください。

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.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のノードまたはインスタンスに障害が発生すると、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ウォレットを使用したセキュアな通信

データベース接続の高可用性、ロード・バランシング、フェイルオーバーをサポートするために、GridLinkデータ・ソースとマルチ・データ・ソースが用意されています。ご使用のOracle RAC Databaseバージョンに応じて、次のデータ・ソース・タイプをお薦めします。

- Oracle RACデータベースのバージョンが11gリリース2以降の場合は、GridLinkデータ・ソースを使用します。

- Oracle RACデータベースのバージョンが11gリリース2より前の場合や、Oracle Database以外のデータベースを使用している場合は、マルチ・データ・ソースを使用します。

注意:

Oracle RACデータベースの可用性を最大限に高めるために、GridLinkデータ・ソースの使用をお薦めします。GridLinkデータ・ソースがサポートされていないOracle RACデータベースのバージョンの場合は、マルチ・データ・ソースを使用して可用性を高めることをお薦めします。

次のトピックの詳細は、『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.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コンポーネントおよび作成するドメインによって異なります。手順の詳細は、使用しているコンポーネントについて説明している項を参照してください。

注意:

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、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.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を使用して構成されている場合は、Oracle RACインスタンスの詳細をSCANアドレスで指定します。Oracle RACインスタンスへのFusion Middlewareの接続では、各Oracle RACインスタンスは、サービス名、インスタンス名、ホストおよびポートを使用して一意に識別されます。そのようなすべてのインスタンスのhost:portアドレスはSCAN host:portであるため、この同じ共通アドレスをすべてのインスタンスに使用することをお薦めします。

インストール・タイプに基づいて、次のガイドラインに従います。

- 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

- マルチ・データ・ソースを使用する構成ウィザードのインストールでは、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-4に、RACに対して構成する際にサポートされるシナリオを示します。

表4-4 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ステータス・メッセージを受信します。

第II部

Oracle Identity and Access Managementコンポーネントの高可用性の構成

第II部では、特定のコンポーネント製品に固有の手順について説明します。

この部は次の章で構成されています。

- 第5章「Oracle Identity Managerコンポーネントの高可用性の構成」

- 第6章「Oracle Access Management Access Managerコンポーネントの高可用性の構成」

- 第7章「Oracle Adaptive Access Managerコンポーネントの高可用性の構成」

- 第8章「Oracle Access Management Security Token Serviceの高可用性の構成」

- 第9章「Identity Federationコンポーネントの高可用性の構成」

- 第10章「Oracle Entitlements Serverの高可用性の構成」

- 第11章「Mobile and Socialの高可用性の構成」

- 第12章「Oracle Privileged Account Managerコンポーネントの高可用性の構成」

- 第13章「Oracle Identity Navigatorの高可用性の構成」

- 第14章「Oracle Unified Directory」

- 第15章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」

5 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管理者ガイドを参照してください。

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

- 第5.1項「Oracle Identity Managerコンポーネント・アーキテクチャ」

- 第5.2項「Oracle Identity Managerの高可用性の概要」

- 第5.3項「Oracle Identity Managerの高可用性の構成手順」

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

図5-1は、Oracle Identity Managerのアーキテクチャを示しています。

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

5.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用のフロントエンドURLであるSOAサーバーのT3 URLを使用してSOAに接続します。クラスタ化された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コマンドのリストを参照してください。

5.1.2 ランタイム・プロセス

Oracle Identity Managerは、Oracle WebLogic ServerにnostageアプリケーションとしてデプロイされるJava EEアプリケーションです。Oracle Identity Managerサーバーは、それがデプロイされたWebLogic Serverの起動時に初期化されます。アプリケーションの初期化の一部として、クォーツ・ベースのスケジューラも起動されます。初期化が完了すると、システムはクライアントからリクエストを受信できるようになります。

Remote ManagerおよびDesign Consoleは別にスタンドアロンのユーティリティとして起動する必要があります。

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

Oracle Identity Managerは、外部的に管理されるアプリケーションとしてOracle WebLogic Serverにデプロイされます。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は、アプリケーションの監視および構成の変更に使用します。

5.1.4 Oracle Identity Managerの起動と停止

Oracle Identity Managerのライフサイクル・イベントは、次に示すコマンド行ツールおよびコンソールを1つ以上使用して管理できます。

- Oracle WebLogic Scripting Tool (WLST)

- WebLogic Server管理コンソール

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle WebLogicノード・マネージャ

5.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に格納されます。

5.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サーバーの機能に必要な外部コンポーネントは次のとおりです。

- 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ファイルがそのクラスパスに含まれている必要があります。

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

Oracle Identity Managerは、Oracle WebLogic ServerにデプロイされるJava EEアプリケーションです。サーバーに関連するログ・メッセージはすべて、サーバーのログ・ファイルに記録され、Oracle Identity Managerに固有のメッセージはすべて、アプリケーションがデプロイされたWebLogic Serverの診断ログ・ファイルに記録されます。

WebLogic Serverのログ・ファイルは、次のディレクトリに配置されます。

DOMAIN_HOME/servers/serverName/logs

主なログ・ファイルは、serverName.log、serverName.outおよびserverName-diagnostic.logの3つですが、ここでserverNameはWebLogic Serverの名前です。たとえば、WebLogic Server名がwls_OIM1の場合、診断ログ・ファイル名はwls_OIM1-diagnostic.logになります。

このログ・ファイルは、Oracle Enterprise Manager Fusion Middleware Controlを使用して表示できます。

5.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呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。

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

図5-2は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたOracle Identity Managerを示しています。

図5-2 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の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。

図5-2の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アドレスを指します。

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

高可用性アーキテクチャでは、Oracle Identity Managerは、Oracle WebLogicクラスタにデプロイされます。このクラスタには、クラスタのメンバーとして少なくとも2つのサーバーが存在します。

デフォルトでは、WebLogic Serverによって、このアプリケーションに対する様々なライフサイクル・イベントの起動、停止、監視および管理が行われます。Oracle Identity Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

Oracle Identity Managerのライフサイクル・イベントは、次に示すコマンド行ツールおよびコンソールを1つ以上使用して管理できます。

- WebLogic Server管理コンソール

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle WebLogic Scripting Tool (WLST)

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

高可用性環境では、1つのOracle Identity Managerインスタンスの構成変更により、他のすべてのインスタンスの構成が変更されます。これは、すべてのOracle Identity Managerインスタンスが同じ構成リポジトリを共有しているためです。

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

LDAPとOracle Identity Managerデータベースとの間の同期情報は、調整と呼ばれるプロセスによって処理されます。このプロセスは、主にバックグラウンドで実行されるスケジュール済プロセスです。このプロセスは手動で実行することもできます。

同期プロセス中にLDAPが停止した場合、Oracle Identity Managerによって取得されていないデータは、調整タスクの次回の実行時に取得されます。

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

この項では、Oracle Identity Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。

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

- 第5.3.1項「Oracle Identity Managerの構成のための前提条件」

- 第5.3.2項「OIMHOST1でのOIMとSOAのためのWebLogicドメインの作成と構成」

- 第5.3.3項「Oracle Platform Security Servicesスキーマのアップグレード」

- 第5.3.4項「ドメイン用のデータベース・セキュリティ・ストアの構成」

- 第5.3.5項「OIMHOST1におけるインストール後の手順」

- 第5.3.6項「OIMHOST1でのOracle Identity Managerの構成」

- 第5.3.7項「管理対象サーバーに対する構成後の手順」

- 第5.3.8項「OIMHOST1でのOracle Identity Managerインスタンスの検証」

- 第5.3.9項「OIMHOST2へのOracle Identity Managerの伝播」

- 第5.3.10項「OIMHOST2におけるインストール後の手順」

- 第5.3.11項「OIMHOST2でのOracle Identity Managerインスタンスの検証」

- 第5.3.12項「SOAサーバーのデフォルト・コンポジットの更新」

- 第5.3.13項「LDAP構成ポストセットアップ・スクリプトを使用したOracle Internet Directoryの構成」

- 第5.3.14項「OIMおよびSOA管理対象サーバーに対するサーバーの移行の構成」

- 第5.3.15項「共有JMS永続ストアの構成」

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

- 第5.3.17項「WEBHOST1およびWEBHOST2へのOracle HTTP Serverのインストール」

- 第5.3.18項「Web Tierと連携するためのOracle Identity Managerの構成」

- 第5.3.19項「Oracle HTTP Serverの構成の検証」

- 第5.3.20項「Oracle Identity Managerのフェイルオーバーおよび予想される動作」

- 第5.3.21項「Oracle Identity Managerの高可用性のトラブルシューティング」

- 第5.3.22項「Oracle Identity Managerトポロジのスケール・アップとスケール・アウト」

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

Oracle Identity Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。

- データベースに OIMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。手順は、第5.3.1.1項「データベースにOIMスキーマを作成するためのRCUの実行」を参照してください。

- OIMHOST1およびOIMHOST2にWebLogicサーバーをインストールします。手順は、第5.3.1.1.1項「Oracle WebLogic Serverのインストール」を参照してください。

- OIMHOST1およびOIMHOST2にOracle SOA Suiteをインストールします。手順は、第5.3.1.2項「OIMHOST1およびOIMHOST2へのOracle SOA Suiteのインストール」を参照してください。

- OIMHOST1およびOIMHOST2にOracle Identity Managementソフトウェアをインストールします。手順は、第5.3.1.3項「OIMHOST1およびOIMHOST2へのOracle Identity Managerのインストール」を参照してください。

- 高可用性LDAP実装が使用可能であることを確認します。

注意:

この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managementと統合されているOracle Identity Managerインストールでのみ必要です。

LDAPSyncオプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップできます。

Oracle Identity Managerは、Oracle Internet Directoryと直接通信しません。それは、Oracle Virtual Directoryと通信し、Oracle Virtual DirectoryがOracle Internet Directoryと通信します。

- wlfullclient.jarファイルを、OIMHOST1およびOIMHOST2で作成します。
Oracle Identity Managerでは、特定の操作にwlfullclient.jarライブラリが必要です。たとえば、Design Consoleでは、サーバー接続にこのライブラリを使用します。このライブラリは出荷されていないため、手動で作成する必要があります。このライブラリは、環境のアプリケーション層にあるすべてのマシンのMW_HOME/wlserver_10.3/server/libディレクトリの下に作成することをお薦めします。このライブラリは、OIDHOST1、OIDHOST2、OVDHOST1、OVDHOST2などのディレクトリ層マシンに作成する必要はありません。詳細は、Oracle Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントのプログラミングのWebLogicフル・クライアントの開発に関する説明を参照してください。

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

5.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.example.com

- ユーザー名: SYS

- パスワード: SYSユーザーのパスワード

- ロール: SYSDBA

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

5. グローバルな前提条件が完了したら、「前提条件チェック」画面で「OK」をクリックします。

6. 「コンポーネントの選択」画面で、新しい接頭辞を作成して、このデプロイメントに関連するコンポーネントを選択します。
接頭辞の新規作成: ha

コンポーネント:

- 「アイデンティティ管理」の下では、次のように指定します。

- Oracle Identity Manager - OIM

- Oracle Platform Security Services - OPSS

- デフォルトで、「Metadata Services - MDS」が選択されていることに注意してください。

- 「SOAおよびBAMインフラストラクチャ」の下で:

- SOAインフラストラクチャ: デフォルトで、SOAINFRAが選択済です。

- ユーザー・メッセージング・サービス: デフォルトで、ORASDPMが選択済です。

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

7. コンポーネントの前提条件が完了したら、「前提条件チェック」画面で「OK」をクリックします。

8. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。
「次へ」をクリックします。

9. 「表領域のマップ」画面で、コンポーネントの表領域を選択します。

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

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

5.3.1.1.1 Oracle WebLogic Serverのインストール

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の実行」の選択を解除します。
「完了」をクリックします。

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

次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOIMHOST1およびOIMHOST2にインストールします。

/etc/oraInst.locファイルが存在している場合は、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合、この手順をスキップできます。

次のようにOracle Fusion Middlewareコンポーネントのインストーラを起動します。

HOST1> runInstaller

インストーラで、JRE/JDKの場所を入力するよう求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_14_<バージョン>のように入力します。

次のように実行します。

1. 「ようこそ」画面で、「次へ」をクリックします。

2. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

3. 「インストール場所の指定」画面で、次の値を入力します。

- Oracle Middlewareホーム: MW_HOMEのリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ:

- ORACLE_HOMEにOracle SOA Suiteをインストールするときに、Oracleホーム・ディレクトリ名としてsoaを入力します。

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

4. 「インストール・サマリー」画面で「インストール」をクリックします。

5. 「インストール完了」画面で「終了」をクリックします。

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

次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOIMHOST1およびOIMHOST2にインストールします。

/etc/oraInst.locファイルが存在している場合は、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合、この手順をスキップできます。

次のようにOracle Fusion Middlewareコンポーネントのインストーラを起動します。

HOST1> runInstaller

インストーラで、JRE/JDKの場所を入力するよう求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_<バージョン>のように入力します。

次のように実行します。

1. 「ようこそ」画面で、「次へ」をクリックします。

2. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

3. 「インストール場所の指定」画面で、次の値を入力します。

- Oracle Middlewareホーム: MW_HOMEのリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。
/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ:

- ORACLE_HOMEにOracle Identity and Access Management Suiteをインストールするときは、Oracleホーム・ディレクトリ名としてiamを入力します。

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

4. 「インストール・サマリー」画面で「インストール」をクリックします。

5. 「インストール完了」画面で「終了」をクリックします。

5.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 Enterprise Manager、Oracle Platform Security Service、Oracle JRF、Oracle JRF WebServices AsynchronousサービスおよびOracle WSM Policy Managerが自動的に選択されます。

- Oracle Enterprise Manager
Oracle JRFが自動的に選択されます。

4. 「ドメイン名と場所の指定」画面で、ドメインおよびそのすべてのアプリケーションの名前と場所を入力します。
次の項目を入力します。

- ドメイン名: IDMDomain

- ドメインの場所: デフォルトを受け入れます。

- アプリケーションの場所: デフォルトを受け入れます。

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

5. 管理サーバーのユーザー名とパスワードの構成画面で、次のように入力します。

- 名前: weblogic

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

- ユーザー・パスワードの確認: weblogicユーザーのパスワードを入力します。

- 説明: ユーザーの説明を入力します。

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

6. 「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JRockit SDK 1.6.n」を選択します。
「次へ」をクリックします。

7. 「JDBCコンポーネント・スキーマの構成」画面で、次に示すコンポーネント・スキーマを選択します。

- SOAインフラストラクチャ

- ユーザー・メッセージング・サービス

- OIM MDSスキーマ

- OWSM MDSスキーマ

- SOA MDSスキーマ

- OIMインフラストラクチャ

- OPSSスキーマ

「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」の横のチェック・ボックスを選択します。

注意:

GridLinkデータ・ソースを使用することもできます。詳細は、第3.13項「GridLinkデータ・ソース」を参照してください。

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

8. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、マルチ・データ・ソース・スキーマをすべて選択し、次の項目を入力します。

- サービス名: oim.example.com

- 最初のRACノードの場合は、次のように入力します。

- ホスト名: OIMDBHOST1-VIP.example.com

- インスタンス名: oimdb1

- ポート: 1521

- 2つ目のRACノードの場合は、次のように入力します。

- ホスト名: OIMDBHOST2-VIP.example.com

- インスタンス名: oimdb2

- ポート: 1521

各スキーマを個別に選択し、スキーマのユーザー名とパスワードを表5-1に示すように入力します。

表5-1 各マルチ・データ・ソース・スキーマのスキーマ所有者とパスワードの入力

スキーマ名

スキーマ所有者

パスワード

SOAインフラストラクチャ

HA_SOAINFRA

<パスワードを入力>

ユーザー・メッセージング・サービス

HA_ORASDPM

<パスワードを入力>

OIM MDSスキーマ

HA_MDS

<パスワードを入力>

OWSM MDSスキーマ

HA_MDS

<パスワードを入力>

SOA MDSスキーマ

HA_MDS

<パスワードを入力>

OIMスキーマ

HA_OIM

<パスワード>

OPSSスキーマ

HA_OPSS

<パスワード>

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

9. 「コンポーネント・スキーマのテスト」画面で、すべてのスキーマを選択して「接続のテスト」をクリックします。すべてのスキーマに対するテストが正常に完了したことを確認します。
「次へ」をクリックします。

10. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- JMS分散宛先 (OIMのインストールされたドメインでのみ必要)

- 管理対象サーバー、クラスタ、およびマシン

- JMSファイル・ストア (OIMのインストールされたドメインでのみ必要)

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

11. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: oimhost1.example.com

- リスニング・ポート: 7001

- SSLリスニング・ポート: 適用なし

- SSL有効: 選択を解除

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

12. 「JMS分散宛先タイプの選択」画面で、リストされているすべてのJMSシステム・リソースが共通分散宛先であることを確認します。そのようになっていない場合は、ドロップダウン・ボックスから「UDD」を選択します。エントリが表5-2に示すように設定されていることを確認します。

表5-2 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エントリについては、そのエントリを次の値に変更します。

- 名前: WLS_OIM1

- リスニング・アドレス: OIMVHN1

- リスニング・ポート: 14000

soa_server1エントリについては、そのエントリを次の値に変更します。

- 名前: WLS_SOA1

- リスニング・アドレス: SOAVHN1

- リスニング・ポート: 8001

2つ目のOIMサーバーに対して、「追加」をクリックし、次の情報を入力します。

- 名前: WLS_OIM2

- リスニング・アドレス: OIMVHN2

- リスニング・ポート: 14000

2つ目のSOAサーバーに対して、「追加」をクリックし、次の情報を入力します。

- 名前: WLS_SOA2

- リスニング・アドレス: SOAVHN2

- リスニング・ポート: 8001

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

注意:

さらに管理対象サーバーを追加するには、2つ目の管理対象サーバーを追加するための手順に従ってください。

14. 「クラスタの構成」画面で、「追加」をクリックして2つのクラスタを作成します。
OIMクラスタに関して次の情報を入力します。

- 名前: oim_cluster

- クラスタのメッセージング・モード: unicast

- クラスタ・アドレス: oimhost1:14000,oimhost2:14000

SOAクラスタに関して次の情報を入力します。

- 名前: soa_cluster

- クラスタのメッセージング・モード: unicast

- クラスタ・アドレス: oimhost1:8001,oimhost2:8001

他のフィールドはすべてデフォルト設定のままにして、「次へ」をクリックします。

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. 「JMSファイル・ストアの構成」画面で、JMSファイル・ストアのディレクトリの場所を更新します。次の値を入力します。

名前

ディレクトリ

UMSJMSFileStore_auto_1

/u01/app/oracle/admin/domain_name/soa_cluster/jms/UMSJMSFileStore_auto_1

UMSJMSFileStore_auto_2

/u01/app/oracle/admin/domain_name/soa_cluster/jms/UMSJMSFileStore_auto_2

BPMJMSFileStore_auto_1

/u01/app/oracle/admin/domain_name/soa_cluster/jms/BPMJMSFileStore_auto_1

BPMJMSFileStore_auto_2

/u01/app/oracle/admin/domain_name/soa_cluster/jms/BPMJMSFileStore_auto_2

JRFWSAsyncFileStore_auto_1

/u01/app/oracle/admin/domain_name/oim_cluster/jms/JRFWSAsyncFileStore_auto_1

JRFWSAsyncFileStore_auto_2

/u01/app/oracle/admin/domain_name/oim_cluster/jms/JRFWSAsyncFileStore_auto_2

SOAJMSFileStore_auto_1

/u01/app/oracle/admin/domain_name/soa_cluster/jms/SOAJMSFileStore_auto_1

SOAJMSFileStore_auto_2

/u01/app/oracle/admin/domain_name/soa_cluster/jms/SOAJMSFileStore_auto_2

OIMJMSFileStore_auto_1

/u01/app/oracle/admin/domain_name/oim_cluster/jms/OIMJMSFileStore_auto_1

OIMJMSFileStore_auto_2

/u01/app/oracle/admin/domain_name/oim_cluster/jms/OIMJMSFileStore_auto_2

PS6SOAJMSFileStore_auto_1

/u01/app/oracle/admin/domain_name/soa_cluster/jms/PS6SOAJMSFileStore_auto_1

PS6SOAJMSFileStore_auto_2

/u01/app/oracle/admin/domain_name/soa_cluster/jms/PS6SOAJMSFileStore_auto_2

19. 「構成のサマリー」画面で、「作成」をクリックしてドメインを作成します。

5.3.3 Oracle Platform Security Servicesスキーマのアップグレード

パッチ・セット・アシスタントを使用して、Oracle Platform Security Servicesスキーマをアップグレードする必要があります。これを行うには、次の手順を実行します。

1. 次のコマンドを使用して、MW_HOME/oracle_common/binからパッチ・セット・アシスタントを起動します。
./psa

2. opssを選択します。

3. データベース接続の詳細を指定し、アップグレード対象のスキーマを選択します。

4. Oracle Platform Security Servicesスキーマのアップグレード後、MW_HOME/oracle_common/upgrade/logs/psa<timestamp>.logにあるログ・ファイルをチェックしてアップグレードを確認してください。
timestampは、パッチ・セット・アシスタントが実行された実際の日時を示します。アップグレードが失敗した場合は、ログ・ファイルをチェックしてエラーを修正し、パッチ・セット・アシスタントを再実行してください。

5.3.4 ドメイン用のデータベース・セキュリティ・ストアの構成

データベース・セキュリティ・ストアには、セキュリティ・ポリシー、監査メタデータ、資格証明、キー、およびOPSSによって管理されるその他のセキュリティ・アーティファクトが格納されます。トポロジ内のポリシーが重複しないように動作することで、ドメイン構成(単一、複数または拡張)に関係なく高可用性を円滑化します。

ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Managementドメインに対するデータベース・セキュリティ・ストアの構成に関する項を参照してください。

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

この項では、OIMHOST1で実行するインストール後の手順について説明します。次のトピックが含まれます:

- 第5.3.5.2項「OIMHOST1でのノード・マネージャの更新」

- 第5.3.5.3項「OIMHOST1でのノード・マネージャの起動」

- 第5.3.5.4項「OIMHOST1での管理サーバーの起動」

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

この項では、OIMHOST1上の管理サーバー用boot.propertiesファイルを作成する方法を説明します。boot.propertiesファイルによって、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できます。

boot.propertiesファイルを作成する手順は次のとおりです。

1. OIMHOST1で、次のディレクトリを作成します。

MW_HOME/wlserver_10.3/server/bin

例:

$ mkdir -p
MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

2. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリの下に作成します。次の行をファイルに入力します。

username=adminUser
password=adminUserPassword

注意:

管理サーバーを起動すると、ファイル内のユーザー名とパスワードのエントリは暗号化されます。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化する必要があります。

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

管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャではStartScriptEnabledプロパティをtrueに設定する必要があります。

これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。

MW_HOME/oracle_common/common/bin

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

次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST1上のノード・マネージャを起動します。

MW_HOME/wlserver_10.3/server/bin

5.3.5.4 OIMHOST1での管理サーバーの起動

次の手順に従い、管理サーバーを起動し、その起動を確認します。

1. 次のコマンドを実行し、OIMHOST1上の管理サーバーを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

2. Webブラウザを開いて次のページにアクセスし、管理サーバーの起動が正常に行われたことを確認します。

- 次の場所にある管理コンソール:

http://oimhost1.example.com:7001/console

- Oracle Enterprise Manager Fusion Middleware Control:

http://oimhost1.example.com:7001/em

weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

5.3.6 OIMHOST1でのOracle Identity Managerの構成

この項では、Oracle Identity ManagerとSOA管理対象サーバーの起動前の構成方法について説明します。

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

- 第5.3.6.1項「Oracle Identity Managerの構成のための前提条件」

- 第5.3.6.2項「CoherenceクラスタのためのCoherenceの構成の更新」

- 第5.3.6.3項「Oracle Identity Management構成ウィザードの実行」

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

Oracle Identity Managerを構成する前に、次のタスクが実行済であることを確認します。

注意:

この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managementと統合されているOracle Identity Managerインストールでのみ必要です。

LDAPSyncオプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップできます。

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.example.com

IDSTORE_PORT : 389

IDSTORE_BINDDN: cn=orcladmin

IDSTORE_USERNAMEATTRIBUTE: cn

IDSTORE_LOGINATTRIBUTE: uid

IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com

IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com

IDSTORE_SEARCHBASE: dc=example,dc=com

IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com

説明:

- IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。非OIDディレクトリを使用している場合は、Oracle Virtual Directoryのホスト(IDSTORE.example.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にあります。
コマンド構文は次のとおりです。

idmConfigTool.sh -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.example.com

IDSTORE_PORT : 389

IDSTORE_BINDDN : cn=orcladmin

IDSTORE_USERNAMEATTRIBUTE: cn

IDSTORE_LOGINATTRIBUTE: uid

IDSTORE_USERSEARCHBASE:cn=Users,dc=example,dc=com

IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com

IDSTORE_SEARCHBASE: dc=example,dc=com

POLICYSTORE_SHARES_IDSTORE: true

IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com

IDSTORE_OIMADMINUSER: oimadmin

IDSTORE_OIMADMINGROUP:OIMAdministrators

説明:

- IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。OVDではなく、バックエンド・ディレクトリを指定します。

- 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. IAM_ORACLE_HOME/idmtools/binにあるidmConfigToolコマンドを使用して、アイデンティティ・ストアを構成します。
idmConfigTool.sh -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.example.com/odsm)を表示します。

注意:

Oracle Directory Services Managerは、図5-2には記載されていませんが、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.example.com

ポート

389

サーバー・プロキシ・バインドDN

cn=oimadmin,cn=systemids,dc=example,dc=com

プロキシ・パスワード

oimadminのパスワード。これは、「Oracle Identity Manager用のディレクトリ・スキーマの拡張」のパスワードと同じにします。

接続テスト

テストが正常に行われたことを確認します。

ネームスペース

リモート・ベース

dc=example,dc=com

マップされたネームスペース

dc=example,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.example.com/odsm)を表示します。

2. OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれへの接続がまだ存在していない場合は、作成します。

3. 適切な接続エントリを使用して、Oracle Virtual Directoryインスタンスに接続します。

4. ホームページで、「アダプタ」タブをクリックします。

5. アダプタ・ウィンドウの上部にある「アダプタの作成」をクリックして、「新規アダプタ・ウィザード」を起動します。

6. 「新規アダプタ・ウィザード」および次のパラメータを使用して、新規アダプタを作成します。

画面

フィールド

値/手順

タイプ

アダプタ・タイプ

LDAP

アダプタ名

OIM変更ログ・アダプタ

アダプタ・テンプレート

Changelog_OID

接続

DNS設定を使用

いいえ

ホスト

oid.example.com

ポート

389

サーバー・プロキシ・バインドDN

cn=oimadmin,cn=systemids,dc=example,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=systemids,dc=example,dc=com

sizeLimit

1000

targetDNFilter

dc=example,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インスタンス。

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

次の手順に従い、SOA管理対象サーバーのCoherence構成を更新します。

1. 管理コンソールにログインします。

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. 「保存」をクリックして、変更をアクティブ化します。
この変更を有効にするには、SOAサーバーの再起動が必要です。

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

Oracle Identity Manager管理対象サーバーを起動する前に、Oracle Identity Managerサーバー・インスタンスを構成しておく必要があります。これらの構成手順を実行するのは、一度のみ(たとえば、ドメインを最初に作成するとき)です。Oracle Identity Management構成ウィザードによって、OIMメタデータがデータベースにロードされ、インスタンスが構成されます。

構成ウィザードを実行する前に、次を検証する必要があります。

- 管理サーバーが起動されて、実行中であること。

- wls_soa1のコヒーレンスを設定していること。

- wls_soa1が実行中であること。

- 環境変数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.example.com:1521:oimdb1^oimdbhost2-vip.example.com:1521:oimdb2@oim.example.com

- OIMスキーマ・ユーザー名: HA_OIM

- OIMスキーマのパスワード: password

- MDSスキーマ・ユーザー名: HA_MDS

- MDSスキーマのパスワード: password

「次へ」を選択します。

4. WebLogic管理サーバー画面で、WebLogic管理サーバーについて次の詳細を入力します。

- URL: WebLogic管理サーバーに接続するためのURLです。例: t3://oimhost1.example.com:7001。

- ユーザー名: weblogic

- パスワード: weblogicユーザーのパスワードです。

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

5. 「OIMサーバー」画面で、次の値を入力します。

- OIM管理者パスワード: OIM管理者のパスワード。これは、xelsysadmユーザーのパスワードです。このパスワードは、事前にidmconfigtoolで入力したパスワードと同じにします。

- パスワードの確認: パスワードを確認するためのものです。

- OIM HTTP URL: OIMサーバーのプロキシURL。これは、OIM用のOHSサーバーのフロントエンドに配置されているハードウェア・ロード・バランサのURLです。例: http://oiminternal.example.com:80。

- キー・ストア・パスワード: キー・ストア・パスワードです。パスワードには大文字と数字をそれぞれ1文字含める必要があります。例: MyPassword1

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

6. 環境に必要な場合は、LDAP同期とOAM画面で、BI Publisherの構成を選択し、BI Publisher URLに値を指定します。環境においてBI Publisherに接続するためのURLを入力します。
LDAP同期の有効化を選択します。

注意:

- OAMとのアイデンティティ管理の統合の有効化は選択しないでください。

- BI PublisherはIDMDomainの一部ではありません。

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

7. 「LDAPサーバー」画面で、次のLDAPサーバーの詳細を指定します。

- ディレクトリ・サーバー・タイプ: ディレクトリ・サーバーのタイプです。OID、ACTIVE_DIRECTORY、IPLANETまたはOVDを選択します。デフォルトはOIDです。

- ディレクトリ・サーバーID: ディレクトリ・サーバーのIDです。

- サーバーURL: LDAPサーバーにアクセスするためのURLです。例: Oracle Virtual Directory Serverを使用する場合はldap://ovd.example.com:389、Oracle Internet Directoryを使用する場合はldap://oid.example.com:389。

- サーバーのユーザー: サーバーに接続するためのユーザー名前。例: cn=orcladmin·

- サーバー・パスワード: LDAPサーバーに接続するためのパスワード。

- サーバー検索DN: 検索DN。例: dc=example,dc=com

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

8. LDAPサーバー(続き)画面で、次のLDAPサーバー詳細を入力します。

- LDAPロールコンテナ: ロール・コンテナのDNです。これは、OIMロールが格納されているコンテナです。例: cn=Groups,dc=example,dc=com

- LDAPユーザーコンテナ: ユーザー・コンテナのDNです。これは、OIMユーザーが格納されているコンテナです。例: cn=Users,dc=example,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インスタンスの詳細を確認します。
「終了」をクリックし、Configuration Assistantを終了します。

13. WebLogic管理サーバーを停止します。

14. WebLogic管理サーバーを起動します。

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

この項では、管理対象サーバーの構成後の手順について説明します。

5.3.7.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管理対象サーバーを起動します。

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

Webブラウザを使用してOracle Identity Managerコンソールを起動することによって、OIMHOST1上のOracle Identity Managerサーバー・インスタンスを検証します。

Oracle Identity ManagerコンソールのURLは、次のとおりです。

http://identityvhn1.example.com:14000/identity

xelsysadmパスワードを使用してログインします。

5.3.9 OIMHOST2へのOracle Identity Managerの伝播

OIMHOST1で構成を完了したら、その構成をOIMHOST2に伝播できます。これを行うには、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。

次の手順に従い、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。

1. OIMHOST1上で、ORACLE_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

5.3.10 OIMHOST2におけるインストール後の手順

この項では、OIMHOST2で実行するインストール後の手順について説明します。これらの項目が含まれます。

- 第5.3.10.1項「OIMHOST2でのノード・マネージャの更新」

- 第5.3.10.2項「OIMHOST2でのノード・マネージャの起動」

- 第5.3.10.3項「OIMHOST2でのWLS_SOA2およびWLS_OIM2管理対象サーバーの起動」

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

WebLogic管理コンソールを使用して管理対象サーバーを起動する前に、ノード・マネージャでStartScriptEnabledプロパティがtrueに設定されていることが必要です。

これを行うには、次のディレクトリの下にあるsetNMProps.shスクリプトを実行します。

MW_HOME/oracle_common/common/bin

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

次のディレクトリの下にあるstartNodeManager.shスクリプトを使用してOIMHOST2上のノード・マネージャを起動します。

MW_HOME/wlserver_10.3/server/bin

5.3.10.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管理対象サーバーを起動してください。

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

Webブラウザを使用してOracle Identity Managerコンソールを起動することによって、OIMHOST2上のOracle Identity Managerサーバー・インスタンスを検証します。

Oracle Identity ManagerコンソールのURLは、次のとおりです。

http://identityvhn2.example.com:14000/oim

xelsysadmパスワードを使用してログインします。

5.3.12 SOAサーバーのデフォルト・コンポジットの更新

統合環境では、Oracle Identity ManagerはOHSによってフロントエンド処理されます。すべてのSOAサーバーのデフォルト・コンポジットを更新する必要があります。SOAサーバーのデフォルト・コンポジットの更新手順は、Oracle Fusion Middleware Oracle Identity Management統合ガイドのSOAサーバーのデフォルト・コンポジットの更新に関する説明を参照してください。

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

注意:

この項は、LDAPSyncが有効なOracle Identity Managerインストール、およびOracle Access Managementと統合されているOracle Identity Managerインストールでのみ必要です。

LDAP同期オプションの有効化や、Oracle Access Managementとの統合を計画していない場合は、この項をスキップできます。

現在のリリースでは、LDAPConfigPostSetupスクリプトを使用すると、LDAPSync関連の増分リコンシリエーション・スケジューラ・ジョブがすべて有効になります。これらのジョブはデフォルトでは無効です。LDAP構成ポストセットアップ・スクリプトは、IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあります。スクリプトを実行する手順は、次のとおりです。

1. IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあるldapconfig.propsファイルを編集して、次の値を指定します。

パラメータ

値

説明

OIMProviderURL

t3://OIMHOST1VHN.example.com:14000,OIMHOST2VHN.example.com:14000

Oracle Identity Manager管理対象サーバーのリスト。

LDAPURL

次の例のようにして、Oracle Virtual DirectoryインスタンスのURLを指定します。ldap://idstore.example.com:389

アイデンティティ・ストアのURL。Oracle Virtual Directoryを使用してIDストアにアクセスする場合のみ必要です。

LDAPAdminUserName

cn=oimadmin,cn=systemids,dc=example,dc=com

アイデンティティ・ストアに接続するユーザーの名前。アイデンティティ・ストアがOracle Virtual Directoryに存在する場合のみ必要です。このユーザーは、cn=Users,dc=example,dc=comに配置しないでください。

LIBOVD_PATH_PARAM

MSERVER_HOME/config/fmwconfig/ovd/oim

Oracle Virtual Directoryを使用してアイデンティティ・ストアにアクセスしない場合は必要です。

注意:

usercontainerName、rolecontainernameおよびreservationcontainernameは、この手順で使用しません。

2. ファイルを保存します。

3. 次のように、JAVA_HOME、WL_HOME、APP_SERVER、OIM_ORACLE_HOMEおよびDOMAIN_HOME環境変数を設定します。

- JAVA_HOMEをMW_HOME/jrockit_versionに設定

- WL_HOMEをMW_HOME/wlserver_10.3に設定

- APP_SERVERをweblogicに設定

- OIM_ORACLE_HOMEをIAM_ORACLE_HOMEに設定

- DOMAIN_HOMEをMSERVER_HOMEに設定

4. LDAPConfigPostSetup.shを実行します。このスクリプトでは、LDAPの管理者パスワードとOracle Identity Managerの管理者パスワードが要求されます。例:

IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh path_to_property_file

例:

IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh IAM_ORACLE_HOME/server/ldap_config_util

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

この高可用性トポロジでは、管理対象サーバーWLS_OIM1、WLS_SOA1、WLS_OIM2、WLS_SOA2に対してサーバー移行を構成することをお薦めします。サーバー全体の移行を使用する利点と推奨する理由については、第3.9項「サーバー全体の移行」を参照してください。

- 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: サーバー移行リース表のユーザーと表領域を設定する

- ステップ2: Oracle WebLogic管理コンソールを使用してマルチ・データ・ソースを作成する

- ステップ3: ノード・マネージャのプロパティ・ファイルを編集する

- ステップ4: wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する

- ステップ5: サーバー移行ターゲットを構成する

- ステップ6: サーバー移行をテストする

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

最初の手順では、サーバー移行リース表のユーザーと表領域を設定します。

注意:

同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。この場合、データベース・リース用にデータ・ソースおよびマルチ・データ・ソースを再作成する必要はありませんが、これらをサーバー移行用に構成しているクラスタにターゲット指定しなおす必要があります。

1. leasingという名前の表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。

SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;

2. leasingという名前のユーザーを作成し、リース表領域に割り当てます。

SQL> create user leasing identified by welcome1;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

3. leasing.ddlスクリプトを使用してリース表を作成します。

1. 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.3.14.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. 管理者の資格証明を使用して、管理コンソールにログインします。

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」を選択します。

注意:

リース表のマルチ・データ・ソースを作成する場合は、名前を<MultiDS>-rac0や<MultiDS>-rac1などの形式で入力します。

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

13. 「グローバル・トランザクションのサポート」の選択を解除します。「次へ」をクリックします。

14. leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。

15. 「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。

注意:

作成するデータ・ソースすべての作成を完了するまで、「終了」をクリックしないでください。作成したデータ・ソースが表示されない場合は、「終了」をクリックするのが早すぎたことを示しています。「終了」をクリックすると、データ・ソースをターゲット指定する画面が管理コンソールに表示されなくなります。

16. データ・ソースをクラスタにターゲット指定します。

17. データ・ソースを選択して、右の画面に追加します。

18. Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。

19. 2つ目のデータ・ソースをマルチ・データ・ソースに追加します。

20. 保存して、「変更のアクティブ化」をクリックします。

5.3.14.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となります。

- 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.3.14.4 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

サーバー移行を構成するノードごとにwlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は、次のとおりです。

1. PATH環境変数に次のファイルが含まれていることを確認します。

表5-3 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とシステム権限はシステム管理者にお問い合せください。

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

まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。

3. 「名前」列で、移行を構成するクラスタをクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。

8. 「保存」をクリックします。

9. 「変更のアクティブ化」をクリックします。

10. サーバー移行の候補となるマシンを設定します。このタスクは、次の手順に従って、すべての管理対象サーバーについて実行する必要があります。

1. 管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。

ヒント:

「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックして、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動し、サーバーが実行されているマシンを表示します。サーバーが自動的に移行される場合、これは実際の構成とは異なります。

2. 移行を構成するサーバーを選択します。

3. 「移行」タブをクリックします。

4. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。

5. 「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

6. 「保存」をクリックしてから、「変更のアクティブ化」をクリックします。

7. 追加の管理対象サーバーに対して、前述の手順を繰り返します。

8. 管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。

5.3.14.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秒間経過した後に、WLS_OIM1の浮動IPが表示されサーバーをこのノードで再起動することを示すメッセージがOIMHOST2のノード・マネージャにより表示されます。

2. 同じIPでsoa-infraコンソールにアクセスします。

前述の手順に従い、WLS_OIM2、WLS_SOA1、およびWLS_SOA2管理対象サーバーのサーバー移行をテストします。

表5-4は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。

表5-4 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. 管理者の資格証明を使用して、管理コンソール(http://oimhost1.example.com:7001/console)にログインします。

2. 左側のコンソールで、「ドメイン」をクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

5.3.15 共有JMS永続ストアの構成

OIMHOST1とOIMHOST2の両方から参照できる共有ディレクトリに、すべての永続ストアの場所を構成します。JMSメッセージは、各サーバーのローカル・ファイル・システムのファイル・システムで永続化されているため、WebLogicサーバー移行のためにはJMS永続ストア用の共有記憶域が必要です。共有記憶域がない場合、移行先サーバーからは保留中のJMSメッセージにアクセスできなくなります。

注意:

JMSメッセージ、トランザクション・ログおよびファイル・ストアでのロックの解放の詳細は、「NFSでのファイル・ストアの使用に関する考慮事項」を参照してください。

共有のベース・ディレクトリを使用するように、すべての永続ストアを変更する手順は、次のとおりです。

1. 管理者の資格証明を使用して、管理コンソール(http://oimhost1.example.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. サーバーを再起動して、永続ストア内の変更を有効化します。

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

各Oracle WebLogic管理対象サーバーにはトランザクション・ログがあり、サーバーによって調整された、未完了の可能性のある、進行中のトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、クラスタ内のすべてのサーバーからアクセス可能な場所にトランザクション・ログを格納します。共有記憶域がないと、サーバーに障害が発生したときにクラスタ内の他のサーバーがトランザクション・リカバリを実行できず、操作の再試行が必要になることがあります。

注意:

可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。

Oracle Identity ManagerおよびSOAサーバーのデフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. 管理者の資格証明を使用して、管理コンソール(http://oimhost1.example.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は、このディレクトリにアクセスできる必要があります。

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

WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールします。

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

この項では、Oracle Identity Managerを構成してOracle Web Tierと連携する方法について説明します。

5.3.18.1 前提条件

次のタスクが実行済であることを確認します。

1. Oracle Web TierをWEBHOST1とWEBHOST2にインストールしました。

2. Oracle Identity ManagerがOIMHOST1およびOIMHOST2にインストールされ、構成済であること。

3. ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(sso.example.com)で構成済であること。

4. ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(oiminternal.example.com)で構成済であること。

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

1. WEBHOST1とWEBHOST2上の各Webサーバーで、oim.confと呼ばれるファイルをORACLE_INSTANCE/config/OHS/component/moduleconfディレクトリに作成します。このファイルには次の情報が記載されている必要があります。

# oim admin console(idmshell based)
<Location /admin>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.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.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /identity>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /sysadmin>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.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.example.com:8001,oimvhn2.example.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.example.com:14000,oimvhn2.example.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.example.com:14000,oimvhn2.example.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.example.com:14000,oimvhn2.example.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.example.com:14000,oimvhn2.example.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.example.com:14000,oimvhn2.example.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.example.com:14000,oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /reqsvc>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:8001,oimvhn2.example.com:8001
oimvh1.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /integration>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:8001,oimvhn2.example.com:8001
oimvhn2.example.com:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /provisioning-callback>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.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.example.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

<VirtualHost *:7777>
ServerName http://oiminternal.example.com:80
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On
</VirtualHost>

3. WEBHOST1とWEBHOST2の両方でファイルを保存します。

4. WEBHOST1およびWEBHOST2の両方で、Oracle HTTP Serverインスタンスを停止および起動します。

5.3.19 Oracle HTTP Serverの構成の検証

Oracle HTTP Serverが適切に構成されていることを検証する手順は次のとおりです。

1. Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。

http://sso.example.com:7777/identity

Oracle Identity Managerコンソール・ログイン・ページが表示されます。

2. xelsysadmユーザーの資格証明を使用してOracle Identity Managerコンソールにログインします。

5.3.20 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呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。

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

この例外を受け取った場合でも、ユーザーは正常に作成されます。

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

Oracle Identity Manager高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。

5.3.22.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、JRFWSAsyncおよびPS6SOAのJMSサーバーを作成します。

1. 管理コンソールを使用して、新しい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. 新しいJRFWSAsyncJMSServerの新しい永続ストアを作成します(たとえば、JRFWSAsyncJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n

8. JRFWSAsync用の新しいJMSサーバーを作成します(たとえば、JRFWSAsyncJMSServer_n)。このJMSServerに対して、JRFWSAsyncJMSFileStore_nを使用します。JRFWSAsyncJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいJRFWSAsync JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

9. 新しいPS6JMSServerの新しい永続ストアを作成します(たとえば、PS6JMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/PS6JMSFileStore_n

10. PS6用の新しいJMSサーバーを作成します(たとえば、PS6JMSServer_n)。このJMSServerに対して、PS6JMSFileStore_nを使用します。PS6JMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいPS6 JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

11. 新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。

12. サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。

13. 新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUMSJMSServerXXXXXXという形式のランダム名です。

14. サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

15. 新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。

16. サブデプロイメント「OIMJMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。

17. 新たに作成されたJRFWSAsync JMSサーバーが含まれるように、JRFWSAsyncJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「JRFWSAsyncJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。JRFWSAsyncJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。JRFWSAsyncJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたJRFWSAsyncJMSServerXXXXXXという形式のランダム名です。

18. サブデプロイメント「JRFWSAsyncJMSServerXXXXXX」をクリックします。このサブデプロイメントに、JRFWSAsyncJMSServer_nと呼ばれる、JRFWSAsyncの新しいJMSサーバーを追加します。「保存」をクリックします。

19. 新たに作成されたPS6SOA JMSサーバーが含まれるように、PS6SOAJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「PS6SOAJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。PS6SOAJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。PS6SOAJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたPS6SOAJMSServerXXXXXXという形式のランダム名です。

20. サブデプロイメント「PS6SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、PS6SOAJMSServer_nと呼ばれる、PS6SOAの新しいJMSサーバーを追加します。「保存」をクリックします。

4. デプロイするコンポジットのOracle Coherenceを構成します。

注意:

サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例:

Dtangosol.coherence.localhost=SOAHOST1VHNn

5. 新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。

6. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。管理サーバーと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. 管理コンソールにログインします。「サービス」→「外部JNDIプロバイダ」リンクを選択します。「ForeignJNDIProvider-SOA」を選択し、新しいサーバーを既存の値に追加します。

9. 新しい管理対象サーバーに対してサーバー移行を構成します。

注意:

これはスケール・アップ操作であるため、ノード・マネージャ、サーバー移行に対して構成された環境および新しいSOA管理対象サーバーの浮動IPがあらかじめノードに用意されている必要があります。

サーバー移行を構成する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 左側のペインで、「環境」を開き、「サーバー」を選択します。

3. 移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。
たとえば、すでにWLS_SOA1が実行されているSOAHOST1上の新しい管理対象サーバーには、SOAHOST2を選択します。すでにWLS_SOA2が実行されているSOAHOST2上の新しい管理対象サーバーには、SOAHOST1を選択します。

移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

9. 新しく作成したWLS_OIMn管理対象サーバーに対してサーバー移行を構成するために、このリストの手順を繰り返します。

10. この新規サーバーのサーバー移行をテストするには、新規サーバーの追加先となったノードで、次の手順を実行します。

1. 管理対象サーバーWLS_SOAnを停止します。
そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを入力します。

2. ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

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

トポロジのスケール・アウトでは、SOAで構成された新しい管理対象サーバーを新しいノードに追加します。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

- SOAで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。

- 新しいノードがWebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること。(新しい管理対象サーバーWLS_SOAまたはWLS_OIMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやSOAバイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります。)

注意:

共有記憶域に既存のインストールが存在しない場合は、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. 管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。このサーバーにWLS_SOAnという名前を付けます。nは番号です。

注意:

これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。

7. 新しい管理対象サーバーでその管理対象サーバーのリスニング・アドレスに使用するホスト名またはIPを割り当てます。
このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーのVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、既存の管理対象サーバーとは別のものを使用してください。

8. 新しい管理対象サーバーにSOA、OIM (該当する場合)、UMS、BPM、JRFWSAsyncおよびPS6SOAのJMSサーバーを作成します。

1. 管理コンソールを使用して、新しい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. 新しいBPMJMSServerの新しい永続ストアを作成します(たとえば、BPMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_n

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいBPM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

8. BPMの新しいJMSサーバーを作成します(たとえば、BPMJMSServer_n)。このJMSServerに対して、BPMJMSFileStore_nを使用します。BPMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

9. 新しいJRFWSAsyncJMSServerの新しい永続ストアを作成します(たとえば、JRFWSAsyncJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいJRFWSAsync JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

10. JRFWSAsync用の新しいJMSサーバーを作成します(たとえば、JRFWSAsyncJMSServer_n)。このJMSServerに対して、JRFWSAsyncJMSFileStore_nを使用します。JRFWSAsyncJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

11. 新しいPS6SOAJMSServerの新しい永続ストアを作成します(たとえば、PS6SOAJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。

ORACLE_BASE/admin/domain_name/cluster_name/jms/PS6SOAJMSFileStore_n

注意:

このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。

新しいPS6SOA JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。

12. PS6SOA用の新しいJMSサーバーを作成します(たとえば、PS6SOAJMSServer_n)。このJMSServerに対して、PS6SOAJMSFileStore_nを使用します。PS6SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。

13. 新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。

14. サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。

15. 新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUMSJMSServerXXXXXXという形式のランダム名です。

16. サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。

17. 新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。

注意:

このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。

18. サブデプロイメント「OIMJMSServerXXXXXX」をクリックします。このサブデプロイメントに、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. デプロイするコンポジットの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. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

6 Oracle Access Management Access Managerコンポーネントの高可用性の構成

この章では、Oracle Access Management Access Manager (Access Manager)の概要、およびAccess Managerの高可用性環境の設計およびデプロイ方法について説明します。

Access Managerによって、すべての認証および認可サービスの一元的な提供が可能になります。提供されるコア・サービスは、有効なセッション・トークンのチェック、セッション・トークンが無効であるか見つからない場合の資格証明の要求、セッション・トークンの発行、リソース・リクエストのインターセプト、およびリソースへのアクセスを制御するためのアクセス制御ポリシーの評価です。Access Managerは、Pure Javaサーバーの機能を備えていますが、Oracle Single Sign-On 10gおよびOracle Access Manager 10gエージェント・コンポーネントも引き続き使用します。Access Managerの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Access Managerの概要に関する説明を参照してください。

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

- 第6.1項「Access Managerコンポーネント・アーキテクチャ」

- 第6.2項「Access Managerの高可用性の概要」

- 第6.3項「Access Managerの高可用性の構成手順」

6.1 Access Managerコンポーネント・アーキテクチャ

図6-1は、Access Managerコンポーネントのアーキテクチャを示しています。

図6-1 Access Managerの単一インスタンス・アーキテクチャ

図6-1は、次のコンポーネントを示しています。

- ユーザー・エージェント: これらには、Webブラウザ、Javaアプリケーション、およびWebサービス・アプリケーションが含まれます。ユーザー・エージェントは、HTTPを使用してアクセス・サーバーと管理および構成ツールにアクセスします。

- 保護されたリソース: 保護されたリソースとは、それへのアクセスが制限されたアプリケーションまたはWebページのことです。保護されたリソースへのアクセスは、WebGateまたはカスタム・エージェントによって制御されます。

- 管理および構成ツール: Access Managerは、Oracle Access Managementコンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Enterprise Manager Grid ControlおよびWebLogic Scripting Tool (WLST)を使用して管理および構成します。

- アクセス・サーバー: アクセス・サーバーには、資格証明コレクタ、OSSOプロキシおよびOAMプロキシ・コンポーネントが含まれます。Coherence分散オブジェクト・キャッシュは、アクセス・サーバー間で構成ファイルの変更を伝播するために使用されます。

6.1.1 Access Managerコンポーネントの特性

Access Managerデプロイメントは、次のシステム・エンティティで構成されます。

- Access Managerエージェント: Access Managerエージェントは、アクセス・サーバーの拡張機能であり、アクセス・サーバーで管理されているポリシーに従ってアクセスが制御されるようにする役割を担います。
エージェントがその機能を実行するには、アクセス・サーバー・コンポーネントが必要です。アクセス・サーバーが使用できない場合、保護されるサーバーへのアクセスは許可されないため、ユーザーはシステムからロックアウトされます。

- 保護されたリソース(パートナ・アプリケーション): Access Managerによって保護されたアプリケーションです。これらのリソースへのアクセスは、Access Managerのアクセス制御ポリシーに従って行われ、保護されたリソースのアクセス・パスにデプロイされたAccess Managerエージェント(WebサーバーにデプロイされたAccess Managerエージェントなど)によって制御されます。

- アクセス・サーバー: コア・ランタイム・アクセス管理サービスを提供するサーバー・サイド・コンポーネントです。

- JMX Mbean: ランタイムMBeanは、アクセス・サーバー・パッケージの一部としてパッケージ化されています。構成Mbeanは、スタンドアロンWARファイルとしてパッケージ化されています。

- WebLogic 11g SSPIプロバイダは、Access Java Access JDKとともにSSPIインタフェースを実現するJavaクラスで構成されています。AccessGateは、Pure Java Access JDKを使用して構築されています。

- Oracle Access Managementコンソール: 管理コンソールをホストするJ2EEアプリケーションであり、Access Managerデプロイメントを管理するための管理や構成などのサービスを提供します。

- WebLogic Scripting Tool (WLST)は、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。Access Managerデプロイメントの管理の一部は、コマンド行からサポートされます。

- Fusion Middleware ControlおよびEnterprise Manager Grid Control: Access Managerは、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。

- Coherence分散オブジェクト・キャッシュ: Access Managerコンポーネントは、このインフラストラクチャに依存して、変更をリアルタイムに伝播します。

- Access Manager Proxyは、Apache MINAサーバーのカスタマイズ・バージョン(JCAアーキテクチャに基づく)であり、Javaサーバー・クラスに加えてMessageDrivenBeanおよびResourceAdapterが含まれています。

- Oracle Single Sign-On (OSSO)プロキシは、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。

- データ・リポジトリ: Access Managerは、アイデンティティ、ポリシー、パートナ、セッション、一時データを含む様々なタイプの情報を処理します。

- アイデンティティ・データ用LDAP

- 構成およびパートナ・データ用ファイル

- セッションおよび一時データ用Coherenceインメモリー

- ポリシー・データはファイルまたはRDBMSに格納されます

- Oracle Access Manager 10g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。

- Oracle Single Sign-On Apacheモジュールは、Oracle HTTP Server Webサーバーにデプロイすることを意図したCベースのエージェントです。

- Access Manager 11g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。

6.1.1.1 Access Managerの状態情報

認証ユーザー・セッション情報は、Coherence分散オブジェクト・キャッシュを介して永続化されます。Access Managerに対しては、Coherence分散オブジェクト・キャッシュ・インメモリー・モードを使用します。

Access Managerによって、ログイン処理中に、認証されていないユーザーに対して一時状態が作成されることがあります。この状態は、通常、Access Managerノード間でレプリケートされません。ログイン処理中のノードの障害の影響を防止するために、オプションでその状態を暗号化されたクライアントCookieに格納することができます。

認証されていないユーザーの一時状態をログイン処理中に格納するには、次の手順に従ってOAMサーバー・パラメータ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.example.com:7001

5. 次のコマンドを発行します。

wls:/IDM_Domain/serverConfig> configRequestCacheType(type="COOKIE")

6. 次のコマンドを発行して、コマンドが動作したことを確認します。

wls:/IDM_Domain/serverConfig> displayRequestCacheType()

7. Access Manager管理対象サーバーを再起動します。

6.1.1.2 Access Managerのリクエスト・フロー

Access Managerのリクエスト・フローの手順を次に説明します。

1. ユーザーが、Access Managerによって保護されたWebリソースに、Webブラウザを使用してアクセスを試みます。

2. Access Managerエージェント脚注1 によって、そのリクエストはインターセプトされ、ユーザーが認証済セッションを持っているかどうかの確認が試みられます。

3. これは、ユーザーの最初のアクセスであるため、ユーザーは認証のためにAccess Manager 11gアクセス・サーバーにリダイレクトされます。

4. アクセス・サーバーの資格証明コレクタ脚注3 ユーザーは、自身の資格証明をアクセス・サーバーに送信します。

5. アクセス・サーバーによって、ユーザーの資格証明が検証され、セキュリティ・トークン(Cookie)が生成されます。ユーザーは、ステップ1でアクセスを試みたリソースにリダイレクトされます。

6. Access Managerエージェントによってリクエストがインターセプトされ、セキュリティ・トークン(Cookie)が抽出されます。

7. Access Managerエージェントによってアクセス・サーバーにバック・チャネル呼出し脚注4 (TCPを介したOAP)が行われ、セッションが検証され、リクエストが認可されます。

8. アクセス・サーバーによって、そのWebリソースの構成済ポリシーに対してユーザーの権限が検証されます。

9. アクセス・サーバーは、WebGateリクエストに応答し、そのアクセスが許可されることを示します。

10. Access Managerエージェントによって、リクエストの通過が許可されます。脚注5

11. ユーザーは、手順1でアクセスを試みたWebリソースにアクセスできるようになります。

6.1.1.2.1 Access Managerプロセスのライフサイクル

アクセス・サーバーと管理コンソールは、WebLogic Serverの提供するユーザー・インタフェースおよびコマンド行ツールから起動できます。

アクセス・サーバーは、障害の検出のためにロード・バランサで使用できるヘルス・チェック・リクエスト(HTTPを介したpingリクエスト)をサポートしています。

Access Managerエージェントは、保護されたアプリケーション環境に常駐するネイティブ・アプリケーションです。OAMの一部として提供されているツールはありませんが、環境固有のツールが使用可能な場合は、それが前述の目的で使用されます。

Access Managerは、サーバー・サイド・メトリック用(DMSを使用)にインスツルメント処理されており、この情報はWebLogic管理コンソールに公開されます。コンポーネントの監視のかわりとして、DMSメトリック収集を使用してエージェントおよびサーバー・コンポーネント・メトリックを監視できます。さらに、Access Managerは、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。

アクセス・サーバーは、起動時にバックエンド・リポジトリへの接続を初期化します。リポジトリに到達不能な場合、アクセス・サーバーはリポジトリへの接続を再試行します。この接続の再試行には指数関数的に増加するタイムアウトが使用されます。タイムアウトの上限は構成可能です。

アクセス・サーバーは、バックエンド接続が停止した場合はローカルにキャッシュしたデータに基づいてサービスの継続性を提供します。これは、キャッシュが失効するか、バックエンド接続が復活するまで継続されます。

6.1.1.2.2 Access Managerの構成アーティファクト

Access Managerの構成アーティファクトには、次のファイルが含まれています。

- DOMAIN_HOME/config/fmwconfig/oam-config.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
OAMがアイデンティティ・ストア、データベースおよびその他のエンティティへの接続に使用するストア・パスワードに使用されます。これは、エンド・ユーザー用のパスワードではありません。

6.1.1.2.3 Access Managerの外部依存性

Access Managerは、次の項目に対して外部ランタイム依存性があります。

- LDAPベースのアイデンティティ・ストア

- ユーザー・アイデンティティ・リポジトリ

- ユーザー/ロールAPIによって抽象化されるLDAPアクセス

注意:

Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、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の拡張認証スキームが選択されている場合)

- Identity Federation (Identity Federationの認証スキームが選択されている場合)

6.1.1.2.4 Access Managerのログ・ファイルの場所

Access ManagerはWebLogic Server上にデプロイされます。すべてのログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。デフォルトのサーバー・ログの場所は次のとおりです。

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

6.2 Access Managerの高可用性の概要

この項では、Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。

6.2.1 Access Managerの高可用性アーキテクチャ

図6-2は、Access Managerの高可用性アーキテクチャを示しています。

図6-2 Access Managerの高可用性アーキテクチャ

図6-2では、着信認証リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohs.confが使用されてWebLogic管理対象サーバーにリクエストが転送されます。分散型資格証明コレクタにより、Webゲートが資格証明を収集し、OAPプロトコルによりAccess Managerサーバーに送信することが可能になります。

ロード・バランシング・ルーターは、HTTPトラフィックに対してのみセッション・スティックネスを使用する必要があります。OAPトラフィックは、ロード・バランシング・ルーターを使用しません。そのため、OAPトラフィックに対してはセッション・スティックネスは必要ありません。

他のOracle HTTP Serverからアクセスされ、さらにはアクセスが制限されているリソースを持つアプリケーションには、WebGate、Oracle Single Sign-On Serverエージェント(mod_ossoエージェント)、OpenSSOポリシー・エージェントまたはカスタム・エージェントを構成する必要があります。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 Managementコンソールをデプロイします。管理サーバーは、OAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAMHOST1が使用不可になった場合に、管理サーバーをOAMHOST2上で手動で起動できます。

ディレクトリ層で、仮想IP ovd.example.comは、Oracle Virtual DirectoryリクエストをOVDHOST1とOVDHOST2にルーティングするように設定されます。OVDHOST1とOVDHOST2は、アクティブ/アクティブのOracle Virtual Directoryクラスタを構成します。仮想IP oid.example.comは、Oracle Internet DirectoryリクエストをOIDHOST1とOIDHOST2にルーティングするように設定されます。OIDHOST1とOIDHOST2は、アクティブ/アクティブのOracle Internet Directoryクラスタを構成します。

Oracle RACデータベースは、データ層における高可用性を提供します。

Access Manager 11gでは、WebLogic ServerドメインごとにサポートされるAccess Managerクラスタは1つのみです。Access Managerクラスタは、複数のWebLogic Serverドメインにわたることはできません。

単一インスタンスのAccess Managerデプロイメントは、次の高可用性要件を満たします。

- ロード処理

- 外部接続管理と監視

- リカバリ

- フォルト包含

- フォルト診断

- 管理サーバーのオフライン

複数インスタンスのAccess Managerデプロイメントは、さらに次の高可用性要件を満たします。

- 冗長性

- クライアント接続のフェイルオーバー/継続性

- クライアントのロード・バランシング

- 状態管理

インバウンドHTTP接続の場合は、外部ロード・バランシング・ルーターの使用をお薦めします。LDAPサーバー(またはOAMポリシー・エンジンPDP/PIP)へのアウトバウンド外部接続はロード・バランシングされ、接続フェイルオーバーに対してもサポートされます。このため、ロード・バランサは必要ありません。Access Managerエージェント、通常Webゲートは、複数のアクセス・サーバーにわたる接続をロード・バランシングできます。

Access Managerエージェントは、アクセス・サーバーへの永続TCP接続を開きます。これには、TCP接続の早すぎる終了を回避するためにファイアウォール接続タイムアウトを十分大きい値にする必要があります。

アクセス・サーバーとAccess Manager管理コンソールは、ポリシー評価および管理のために、OAMポリシー・エンジンと連動します。OAMポリシー・エンジンは、ポリシー・リポジトリとしてのデータベースに内部依存します。データベースの相互作用はOAMポリシー・エンジン内にカプセル化され、Access Managerからは、その接続構成情報のみを管理できます。Access ManagerとOAMポリシー・エンジン間の相互作用の高可用性の特性は、次のとおりです。

- データベース接続情報は、Access Managerインスタンス間で同期されるAccess Manager構成ファイルで構成されます。

- データベース通信はOAMポリシー・エンジン内で管理され、通常、Access ManagerとOAMポリシー・エンジンの相互作用からは分離されます。ただし、OAMサーバー・インスタンスの最初の起動は、データベースに到達不能な場合、失敗します。OAMポリシー・エンジンのブートストラップの障害はAccess Managerによって致命的として処理され、起動操作は中断されます。

- 一時的なデータベースの使用不能は、OAMポリシー・エンジン・ポリシー評価サービスによって透過的に許容され、Access Managerサーバー・ランタイムは中断されることなく継続的に機能します。最初のOAMポリシー・エンジンのブートストラップの後、データベースが到達不能でも、Access Managerインスタンスは再起動でき、OAMポリシー・エンジンはそのローカルにキャッシュされたポリシーに対して処理を継続します。

- Access Managerポリシー管理インタフェース(Oracle Access ManagementコンソールおよびCLIツール内)は、OAMポリシー・エンジン管理サービス・インタフェースからみてデータベースが到達不能である場合に失敗します。操作は後で再試行できますが、管理操作に対して自動化された再試行は提供されていません。

- データベース・リポジトリでポリシーが変更されると、OAMサーバー・ランタイムのOAMポリシー・エンジン・レイヤーが、(Access Managerの構成で構成される)構成可能なOAMポリシー・エンジン・データベース・ポーリング間隔内でその変更を取得し、アクティブ化します。ポリシー変更の肯定応答を、各OAMサーバー・ランタイムから受信する必要がありますが、それ以外の場合は、そのポリシー変更はアクティブ化に成功したとみなされません。管理者は、Oracle Access Managementコンソールを使用して、サービスから、ポリシー・アクティブ化が失敗したAccess Managerインスタンスを削除できます。

6.2.1.1 クラスタの起動と停止

高可用性アーキテクチャでは、OAMサーバーは、Oracle WebLogicクラスタにデプロイされますが、このクラスタには、その一部として少なくとも2つのサーバーが存在します。

デフォルトでは、WebLogic Serverによって、このアプリケーションに対する様々なライフサイクル・イベントの起動、停止、監視および管理が行われます。Access Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。

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

Access Managerが使用する標準Java EEアーティファクトは、Access ManagerがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Access Managerコンポーネントで使用されるライブラリを同期します。

さらに、Access Managerのアプリケーション・レベルの構成は、Access Managerリポジトリに格納されます。すべてのクラスタ・メンバーへのAccess Managerの構成変更の伝播は、Coherence分散オブジェクト・キャッシュを活用する配布メカニズムに基づきます。すべてのAccess Managerコンポーネントは、変更イベントをCoherenceレイヤーから通知されて取得します。変更の原子性を確保するために、Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。

Access Managerの構成は、クラスタ内のすべてのインスタンスに適用されます。Access Managerでサポートされる前述の構成(インスタンス固有の構成)の例外は、Access Managerプロキシ・ホスト、Access Managerプロキシ・ポートおよびインスタンス固有のCoherence構成(Well Knownアドレス(WKA)が使用されている場合)のみです。プロキシ・ホストのIPアドレスおよびプロキシ・ポートは、構成ファイルに格納されます。Access Managerプロキシ・ポートは、エージェントからのOAPリクエストのエンドポイントです。Coherence WKAのIPアドレスも、構成ファイルに格納されます。Coherence WKAは、Access Manager固有のトラフィックを受信する権限を付与されたCoherenceノードを判別するために使用されます。oam-config.xmlファイルは、この構成情報を格納する構成ファイルです。

アクセス・サーバー・インスタンスの追加および削除は、クラスタ内の他のAccess Manager Access Serverインスタンスに対して透過的です。ただし、特定のアクセス・サーバーの削除が、エージェントのロード・バランシングとフェイルオーバーの特性に影響を与えないように注意してください。

Access Manager Access Serverを再起動しても、クラスタ内の他の実行中のコンポーネントやメンバーには影響ありません。

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

この項では、Oracle Identity Managementの高可用性クラスタ・デプロイメントによって、コンポーネントを障害から保護する仕組みと、コンポーネントの障害が発生したときに予想される動作について説明します。

WebLogic Serverインフラストラクチャにより、Identity Managementサービス・インフラストラクチャ・システムは、あらゆるプロセス障害から保護されます。

また、次の機能もAccess Managerの高可用性構成を障害から保護します。

- バック・チャネルOAPバインディングでは、フェイルオーバーのためにプライマリ/セカンダリ・モデルが使用されます。フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。

- セッションの状態は、Coherence分散オブジェクト・キャッシュで保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。Coherenceキャッシュに格納されたデータは、データベースに非同期的に書き込まれます。このデータは、すべてのアクセス・サーバーが再起動されても保持されます。ただし、書込みの非同期的な性質により少量のデータが失われる可能性があります。

- アクセス・サーバーで障害が発生した場合、そのサーバーへの永続接続を持つWebGateは、接続がタイムアウトするまで待機し、その後にセカンダリ(バックアップ)アクセス・サーバーに切り替えます。未処理のリクエストは、セカンダリ・サーバーにフェイルオーバーされます。

- Access Manager Access Serverは、ハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視して、そのアプリケーションを再起動できます。

- WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。

- ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、そのセッション状態を取得して処理を継続します。

- 接続の存続時間が期限切れした場合、保留中のリクエストは接続が終了する前に完了します。接続オブジェクトはプールに戻されます。

- 別のサービスから例外を受信した場合、Access Managerは、外部接続リクエストを再試行します。再試行回数は設定が可能です。

6.2.2.1 WebLogic Serverのクラッシュ

WLS_OAMxサーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。

HTTP Serverからの処理中のリクエストはタイムアウトして、新しいリクエストは他のWLS_OAMxサーバーに送られます。障害が発生したノードでサーバーが正常に再起動されると、Oracle HTTP Serverは、受信したリクエストのサーバーへのルーティングを再開します。

注意:

Access Managerサーバーは、アクセス・サーバーがそのリクエストにサービスを提供できるかどうかを判別するため、ハートビート・チェックをサポートします。次のチェックを行います。

- LDAPストアにアクセスできるかどうか。

- ポリシー・ストアにアクセスできるかどうか。

ハートビート・チェックに成功した場合、アクセス・サーバーはリクエストの処理が可能であり、リクエストがそれに送信されます。ハートビート・チェックで問題がある場合、リクエストはアクセス・サーバーにルーティングされません。

6.2.2.2 ノード障害

ノード障害は、WebLogic Serverの障害と同じ方法で処理されます。

6.2.2.3 データベース障害

Access Managerサービス・インフラストラクチャは、マルチ・データ・ソースの使用によりデータベースの障害から保護されます。通常、これらのマルチ・データ・ソースは、システムの初期設定時に構成されます(Oracle Fusion Middleware構成ウィザードで、インストール時にこれらのマルチプールを直接定義できます)。これらのソースによって、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。

Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

6.3 Access Managerの高可用性の構成手順

この項では、Access Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAMサーバーに配布します。これらのOAMサーバーは、Oracle Real Application Clusters (Oracle RAC)データベースおよび、(オプションで)外部LDAPストアと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。

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

- 第6.3.1項「Access Managerの構成のための前提条件」

- 第6.3.2項「リポジトリ作成ユーティリティの実行によるデータベース・スキーマの作成」

- 6.3.3項「Oracle WebLogic Serverのインストール」

- 第6.3.4項「Access Manager Application Tierのインストールと構成」

- 第6.3.5項「データベース・セキュリティ・ストアの構成」

- 第6.3.6項「OAMHOST1での管理サーバー用boot.propertiesの作成」

- 第6.3.7項「OAMHOST1の起動」

- 第6.3.8項「OAMHOST1の検証」

- 第6.3.9項「OAMHOST2でのOAMの構成」

- 第6.3.10項「OAMHOST2の起動」

- 第6.3.11項「OAMHOST2の検証」

- 第6.3.12項「Oracle HTTP Serverと連携するためのAccess Managerの構成」

- 第6.3.13項「外部LDAPストアを使用するためのAccess Managerの構成」

- 第6.3.14項「Access Managerの構成の検証」

- 第6.3.15項「構成ファイルの同期を保つためのOracle Coherenceの構成」

- 第6.3.16項「Access Managerトポロジのスケール・アップとスケール・アウト」

6.3.1 Access Managerの構成のための前提条件

Access Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。

- リポジトリ作成ユーティリティを実行して、データベースにAccess Managerのスキーマを作成します。第6.3.2項「リポジトリ作成ユーティリティの実行によるデータベース・スキーマの作成」を参照してください。

- OAMHOST1およびOAMHOST2にOracle WebLogic Serverをインストールします。第6.3.3項「Oracle WebLogic Serverのインストール」を参照してください。

- OAMHOST1およびOAMHOST2にOracle Identity Management実行可能ファイルをインストールします。第6.3.4項「Access Manager Application Tierのインストールと構成」を参照してください。

- 高可用性LDAP実装が使用可能であることを確認します。

6.3.2 リポジトリ作成ユーティリティの実行によるデータベース・スキーマの作成

作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。RCU実行の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』および『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

6.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の実行」の選択を解除します。
「完了」をクリックします。

6.3.4 Access Manager Application Tierのインストールと構成

この項では、Oracle Fusion MiddlewareコンポーネントをOAMHOST1およびOAMHOST2にインストールして構成する方法について説明します。

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

この項では、Oracle Identity Managementソフトウェアを、前に作成したMiddlewareホーム・ディレクトリにインストールする手順について説明します。OAMHOST1およびOAMHOST2上で手順を実行します。

/etc/oraInst.locファイルが存在している場合は、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。

次のようにOracle Fusion Middlewareのインストーラを起動します。

OAMHOST1> runInstaller

インストーラで、JRE/JDKの場所を入力するように求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_<バージョン>のように入力します。

次の手順を実行します。

1. 「ようこそ」画面で、「次へ」をクリックします。

2. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

3. 「インストール場所の指定」画面で、次の値を入力します。

- Oracle Middlewareホーム: MW_HOMEのリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。

/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ: idmを入力します。

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

4. 「インストール・サマリー」画面で「インストール」をクリックします。

5. 「インストール完了」画面で「終了」をクリックします。

6.3.4.2 OAMHOST1におけるOracle Access Managerの構成

この項では、OAMHOST1にドメインを作成します。

次のコマンドを実行して、構成ウィザードを起動します。

MW_HOME/oracle_common/common/bin/config.sh

次の手順を実行します。

1. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

2. 「ドメイン・ソースの選択」画面で、次を選択します。
「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

次の製品を選択します。

- Oracle Enterprise Manager

- Oracle JRF(デフォルトで選択)

- Oracle Access Management

- Oracle Platform Security Service

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

3. 「ドメイン名と場所の指定」画面で、次を入力します。

- ドメイン名: IDM_Domain

- ドメインの場所: デフォルトを受け入れます。

- アプリケーション・ディレクトリ: デフォルトを受け入れます。

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

4. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。

5. 「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。

- WebLogicドメインの起動モード: 「本番モード」を選択します。

- JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。

6. 「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
「次へ」をクリックします。

7. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAMインフラストラクチャを選択し、次の項目を入力します。

- データ・ソース: OAM

- サービス名: oam.example.com

- ユーザー名: OAM_OAM (OAMがRCU接頭辞として使用されていたと想定)

- パスワード: 前述のアカウント用のパスワード

右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。

- ホスト名: OAMDBHOST1

- インスタンス名: oamdb1

- ポート: 1521

再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。

- ホスト名: OAMDBHOST2

- インスタンス名: oamdb2

- ポート: 1521

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

8. 「コンポーネント・スキーマのテスト」画面で、データ・ソースの検証が試行されます。
データ・ソースの検証が成功したら、「次へ」をクリックします。

失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。

9. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

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

10. 「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。

11. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: OAMHOST1.example.com

- リスニング・ポート: 7001

- SSLリスニング・ポート: 適用なし

- SSL有効: 選択を解除

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

12. 「管理対象サーバーの構成」画面で、トポロジのOAMHOSTごとにエントリを作成します。つまり、OAMHOST1上で実行されているOAMサーバーに対して1つと、OAMHOST2上で実行されているOAMサーバーに対して1つ作成します。
OAM_SERVERエントリを選択し、そのエントリを次の値に変更します。

- 名前: WLS_OAM1

- リスニング・アドレス: OAMHOST1.example.com

- リスニング・ポート: 14100

2つ目のOAM_SERVERに対して、「追加」をクリックし、次の情報を入力します。

- 名前: WLS_OAM2

- リスニング・アドレス: OAMHOST2.example.com

- リスニング・ポート: 14100

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

13. 「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前としてOAM_Clusterを入力します。

その他すべてのフィールドはデフォルトの設定のままにします。

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

14. 「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。

- 右のウィンドウでクラスタ名OAM_Clusterをクリックします。

- 管理対象サーバーWLS_OAM1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。

- 管理対象サーバーWLS_OAM2に対しても同様に繰り返します。

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

15. 「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を指定します。

- 名前: ホスト名です。ベスト・プラクティスは、DNS名(OAMHOST1)を使用することです。

- ノード・マネージャ・リスニング・アドレス: マシン(OAMHOST1.example.com)のDNS名。

- ノード・マネージャ・ポート: ノード・マネージャが使用するポート。

OAMHOST2に対しても次のように手順を繰り返します。

- 名前: ホスト名です。ベスト・プラクティスは、DNS名(OAMHOST2)を使用することです。

- ノード・マネージャ・リスニング・アドレス: マシン(OAMHOST2.example.com)のDNS名。

- ノード・マネージャ・ポート: ノード・マネージャが使用するポート。

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

16. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。

- 右のウィンドウでマシンOAMHOST1をクリックします。

- 左のウィンドウで管理対象サーバーWLS_OAM1をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAMHOST1に割り当てます。

- 右のウィンドウでマシンOAMHOST2をクリックします。

- 左のウィンドウで管理対象サーバーWLS_OAM2をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAMHOST2に割り当てます。

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

17. 「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。

注意:

構成を変更するためにconfig.shスクリプトを2回実行することはできないため、構成に追加の変更を行う場合は、Fusion Middleware ControlのMBeansブラウザの使用などの別のツールを使用する必要があります。

6.3.5 データベース・セキュリティ・ストアの構成

ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、第5.3.4項「ドメイン用のデータベース・セキュリティ・ストアの構成」を参照してください。

6.3.6 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.example.com:7001/console

- Oracle Enterprise Manager Fusion Middleware Control:

http://oamhost1.example.com:7001/em

weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

6.3.7 OAMHOST1の起動

この項では、OAMHOST1の起動手順について説明します。

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

コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:

OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

6.3.7.2 ノード・マネージャの起動

次のコマンドを発行してノード・マネージャを起動します。

OAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

6.3.7.3 OAMHOST1上のAccess Managerの起動

OAMHOST1上のAccess Managerを起動する手順は、次のとおりです。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oamhost1.example.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを指定します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバーWLS_OAM1をクリックします。

6. 「起動」をクリックします。

7. 「OK」をクリックし、サーバーを起動することを確認します。

6.3.8 OAMHOST1の検証

実装を検証するには、次のURLにあるOracle Access Managementコンソールに接続します。

http://OAMHOST1.example.com:7001/oamconsole

OAM管理コンソールのログイン・ページが開き、WebLogic administratorアカウントを使用してログインできる場合、実装は有効です。

6.3.9 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

6.3.10 OAMHOST2の起動

この項では、OAMHOST2を起動する手順について説明します。

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

コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:

OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

6.3.10.2 ノード・マネージャの起動

次のコマンドを発行してノード・マネージャを起動します。

OAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

6.3.10.3 OAMHOST2上のAccess Managerの起動

OAMHOST2上のAccess Managerを起動する手順は、次のとおりです。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oamhost2.example.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを指定します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバーWLS_OAM2をクリックします。

6. 「起動」をクリックします。

7. 「OK」をクリックし、サーバーを起動することを確認します。

6.3.11 OAMHOST2の検証

次のURLを使用してOAMサーバーに接続することによって実装を検証します。

http://OAMHOST2.example.com:14100/oam/server/logout

OAMから正常にログアウトしたことを示すページが表示されると、実装は有効です。

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

この項では、Oracle HTTP Serverと連携するためのAccess Managerの構成手順について説明します。

6.3.12.1 Oracle HTTP Server構成の更新

WEBHOST1およびWEBHOST2で、次のディレクトリにoam.confというファイルを作成します。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

次の行を指定してファイルを作成します。

NameVirtualHost *:7777
<VirtualHost *:7777>

ServerName sso.example.com:7777
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /oam>
SetHandler weblogic-handler
Debug ON
WLLogFile /tmp/weblogic.log
WLProxySSL ON
WLProxySSLPassThrough ON
WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
</Location>

<Location /oamfed>
SetHandler weblogic-handler
Debug ON
WLLogFile /tmp/weblogic.log
WLProxySSL ON
WLProxySSLPassThrough ON
WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100

</Location>

</VirtualHost>

6.3.12.2 Oracle HTTP Serverの再起動

WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1>opmnctl stopall
WEBHOST1>opmnctl startall

WEBHOST2>opmnctl stopall
WEBHOST2>opmnctl startall

6.3.12.3 OAM Serverにロード・バランサを認識させる

デフォルトでは、Access Managerではローカル・サーバーにあるログイン・ページにリクエストに送信します。高可用性デプロイメントでは、この設定を変更してログイン・ページ・リクエストがローカル・バランサに送信されるようにする必要があります。

Access Managerにロード・バランサを認識させる手順は、次のとおりです。

1. 次のURLで、Oracle Access Managementコンソールにweblogicユーザーとしてログインします。

http://OAMHOST1.example.com:7001/oamconsole

2. 「構成」タブをクリックします。

3. 「Access Managerの設定」リンクをクリックします。

4. 次の情報を入力します。

- OAMサーバー・ホスト: sso.example.com

- OAMサーバー・ポート: 7777

- OAMサーバー・プロトコル: http

5. 「適用」をクリックします。

6. 管理対象サーバーWLS_OAM1およびWLS_OAM2を再起動します。

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

デフォルトでは、Access Managerでは、組込みLDAPサーバーにある独自コンポーネントを使用します。高可用性構成では、ディレクトリ・ストアとして外部LDAPディレクトリを使用することをお薦めします。この項では、外部LDAPストアの設定方法について説明します。

注意:

この項で説明する手順を実行する前に、環境およびLDAPストアをバックアップしておくことをお薦めします。

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

アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。

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.example.com

IDSTORE_PORT : 389

IDSTORE_BINDDN : cn=orcladmin

IDSTORE_USERNAMEATTRIBUTE: cn

IDSTORE_LOGINATTRIBUTE: uid

IDSTORE_USERSEARCHBASE:cn=Users,dc=example,dc=com

IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com

IDSTORE_SEARCHBASE: dc=example,dc=com

IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com

説明:

- IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。(OVDではなく、バックエンド・ディレクトリを指定します。)

- 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にあります。
コマンド構文は次のとおりです。

idmConfigTool.sh -preConfigIDStore input_file=configfile

例:

idmConfigTool.sh -preConfigIDStore input_file=extend.props

このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。

次に、コマンドの出力例を示します。

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. ログ・ファイルを確認して、エラーや警告を修正します。

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

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.example.com

IDSTORE_PORT : 389

IDSTORE_BINDDN : cn=orcladmin

IDSTORE_USERNAMEATTRIBUTE: cn

IDSTORE_LOGINATTRIBUTE: uid

IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com

IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com

IDSTORE_SEARCHBASE: dc=example,dc=com

POLICYSTORE_SHARES_IDSTORE: true

OAM11G_IDSTORE_ROLE_SECURITY_ADMIN:OAMAdministrators

IDSTORE_OAMSOFTWAREUSER:oamLDAP

IDSTORE_OAMADMINUSER:oamadmin
IDSTORE_SYSTEMIDBASE:cn=systemids,dc=example,dc=com

説明:

- IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。

- IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。

- IDSTORE_USERSEARCHBASEは、ユーザーが格納されるディレクトリの場所です。

- IDSTORE_GROUPSEARCHBASEは、グループが格納されるディレクトリの場所です。

- IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。

- POLICYSTORE_SHARES_IDSTOREは、ポリシー・ストアとアイデンティティ・ストアが同じディレクトリに存在する場合にはtrueを設定します。そうでない場合は、falseを設定します。

- IDSTORE_OAMADMINUSERは、Access Manager管理者として作成するユーザーの名前です。

- IDSTORE_OAMSOFTWAREUSERは、LDAPに作成されるユーザーで、Access Managerが実行中にLDAPサーバーに接続するために使用されます。

3. idmConfigToolコマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
コマンド構文は次のとおりです。

idmConfigTool.sh -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統合概要を参照してください。

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

ユーザー・アイデンティティ・ストアを作成する手順は、次のとおりです。

1. 次のURLのOracle Access Managementコンソールに移動します。

http://adminvhn.example.com:7001/oamconsole

2. WebLogic管理ユーザーを使用してログインします。

3. 「システム構成」→「データソース」を選択します。

4. 「ユーザー・アイデンティティ・ストア」を選択して、「追加」をクリックします。次の情報を入力します。

- ストア名: LDAP_DIR

- ストア・タイプ: OVD

- 説明: ディレクトリ・ストアの説明を入力します

- SSLの有効化: これは、SSLを使用してディレクトリと通信する場合に選択します

- 場所: 場所を入力します(例: ovd.example.com:389)

- バインドDN: LDAPストアを検索する権限を与えるユーザーを入力します。例: cn=orcladmin

- パスワード: oracleadminパスワードを入力します

- ユーザー名属性: たとえば、uidとします。

- ユーザー検索ベース: LDAPストアのユーザーの場所を入力します。例: cn=Users,dc=example,dc=com

- グループ名属性: 例: orclguid

- グループ検索ベース: LDAPストアのグループの場所を入力します。例: cn=Groups,dc=example,dc=com

- OAM管理者ロール: OAMAdministrators

5. 「適用」をクリックします。

6. 「接続テスト」をクリックし、LDAPサーバーへの接続を検証します。

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

LDAPアイデンティティ・ストアを定義したので、プライマリ認証ストアとして設定する必要があります。これを行うには、Oracle Access Managementコンソールで次の手順を実行します。

1. 「システム構成」タブをクリックします。

2. ナビゲーション・ペインから「データ・ソース - ユーザー・アイデンティティ・ストア」を選択します。

3. 「LDAP_DIR」をクリックします。

4. 「オープン」を「アクション」メニューで選択します。

5. 「デフォルト・ストアとして設定」をクリックします。

6. 「システム・ストアとして設定」をクリックします。

7. 「アクセス・システム管理者」の追加[+]アイコンをクリックします。

8. 検索名フィールドにOAM*を入力して、「検索」をクリックします。

9. 検索結果から「OAMAdministrators」を選択して、「選択済の追加」をクリックします。

10. 「適用」をクリックします。

11. 「システム管理者の検証」ウィンドウで、OAM管理者のユーザー名とパスワード(例: oamadmin)を入力します。

12. 「検証」をクリックします。

13. 「接続テスト」をクリックして接続をテストします。

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

デフォルトでは、Access Managerは、ユーザーの検証に統合LDAPストアを使用します。LDAP認証モジュールを更新して、そのモジュールが新しい外部LDAPストアに対してユーザーを認証できるようにします。

LDAP認証モジュールが外部LDAPを使用するように更新する手順は、次のとおりです。

1. 「システム構成」タブをクリックします。

2. 「Access Managerの設定」→「認証モジュール」→「LDAP認証モジュール」を選択します。

3. 「LDAP」をクリックします。

4. 「オープン」を「アクション」メニューで選択します。

5. 「ユーザー・アイデンティティ・ストア」をLDAP_DIRに設定します。

6. 「適用」をクリックします。

7. 管理対象サーバーの管理サーバー、WLS_OAM1およびWLS_OAM2を再起動します。

注意:

oamadminを使用してOIFを管理する場合は、OAM管理者ロールを追加する必要があります。詳細は、第6.3.13.3項「ユーザー・アイデンティティ・ストアの作成」を参照してください。

6.3.14 Access Managerの構成の検証

Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminとしてログインすることにより、構成を検証します。

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

高可用性環境では、OracleはOracle Coherenceを使用して構成ファイルの同期を保ちます。Oracle Coherenceは、デフォルトではポート9095を使用しますが、これはOracle Access Managementコンソールを使用して変更できます。

URL (http://admin.example.com/oamconsole)を使用して、コンソールにログインし、次の手順を実行します。

1. 「システム構成」タブをクリックします。

2. ナビゲータでサーバーを展開します。

3. ポートを変更する管理対象サーバーをダブルクリックします。

4. 「コヒーレンス」タブをクリックします。

5. 「ローカル・ポート」の値を目的の値に変更します。

6. 「適用」をクリックします。

7. 管理サーバーと、更新された管理対象サーバーと同じクラスタに配置されている管理対象サーバーすべてを再起動します。

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

この項では、Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいAccess Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいAccess Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。

6.3.16.1 Access Managerのスケール・アップ

OAMをスケール・アップする手順は、次のとおりです。

Oracle WebLogic Server管理コンソール(http://oamhost1.example.com:7001/console)にログインします。

1. 管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 拡張するホスト上のサーバーを選択します(例: WLS_OAM1)。

4. 「クローンの作成」をクリックします。

5. 次の情報を入力します。

- サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。

- サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。

6. 「OK」をクリックします。

7. 新しく作成したサーバーWLS_OAM3をクリックします。

8. SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。

9. 「保存」をクリックします。

10. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。表の「名前」列で「WLS_OAM3」を選択します。

4. 「SSL」タブをクリックします。「詳細」をクリックします。

5. 「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。

11. 構成のアクティブ化を「チェンジ・センター」メニューでクリックします。

新しい管理対象サーバーをOAMに登録します。この時点で、Oracle Access Managementコンソールで、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。

1. Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。

2. 「システム構成」タブをクリックします。「サーバー・インスタンス」をクリックします。

3. 「アクション」メニューから「作成」を選択します。

4. 次の情報を入力します。

- サーバー名: WLS_OAM3

- ホスト: サーバーを実行するホスト。

- ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート

- OAMプロキシ・ポート: OAMプロキシを実行するポート。これは当該ホストについて一意のポートです。

- プロキシ・サーバーID: AccessServerConfigProxy

- モード: オープン

5. 「コヒーレンス」タブをクリックします。
「ローカル・ポート」をそのホストで一意の値に設定します。

「適用」をクリックします。

6. 「適用」をクリックします。

これでアクセス・サーバーを起動できます。このアクセス・サーバーを使用するには、その存在をWebgateに通知する必要があります。この手順は次のとおりです。

1. Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。

2. 「システム構成」タブをクリックします。

3. 「アプリケーション管理」の下の「起動パッド」から、「SSOエージェント」をクリックして開きます。「SSOエージェント」ページで、「検索」をクリックします。

4. 変更するWebゲートをダブルクリックします。

5. 「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。

6. サーバー名をリストから選択します。

7. 「適用」をクリックします。

6.3.16.2 Access Managerのスケール・アウト

スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。

1. 第6.3.3項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。

2. 新しいホストにIdentity Managementコンポーネントをインストールします。第6.3.4項「Access Manager Application Tierのインストールと構成」を参照してください。

3. Oracle WebLogic Server管理コンソール(http://oamhost1.example.com:7001/oamconsole)にログインします。

4. 管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。

5. 「チェンジ・センター」で、「ロックして編集」をクリックします。

6. 拡張するホスト上のサーバーを選択します(例: WLS_OAM1)。

7. 「クローンの作成」をクリックします。

8. 次の情報を入力します。

- サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。

- サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。

9. 「OK」をクリックします。

10. 新規作成したサーバーである「WLS_OAM3」をクリックします。

11. SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。

12. 「保存」をクリックします。

13. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。「詳細」をクリックします。

6. 「ホスト名の検証」を「なし」に設定します。

7. 「保存」をクリックします。

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に登録します。この時点で、Oracle Access Managementコンソールで、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。

1. Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。

2. 「システム構成」タブをクリックします。「サーバー・インスタンス」をクリックします。

3. 「アクション」メニューから「作成」を選択します。

4. 次の情報を入力します。

- サーバー名: WLS_OAM3

- ホスト: サーバーを実行するホスト、OAMHOST3。

- ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート。

- OAMプロキシ・ポート: OAMプロキシを実行するポート。これは当該ホストについて一意のポートです。

- プロキシ・サーバーID: AccessServerConfigProxy

- モード: オープン

5. 「適用」をクリックします。

Access Serverを起動します。このサーバーを使用するには、その存在をWebgateに通知する必要があります。

1. Oracle Access Managementコンソール(http://oamhost1.example.com:7001/oamconsole)にoamadminユーザーとしてログインします。

2. 「システム構成」タブをクリックします。

3. 「エージェント」→「OAMエージェント」→「10gエージェント」を展開します。

4. 変更するWebゲートをダブルクリックします。

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.example.com:14200,OAMhost2.example.com:14200
</Location>

変更後は次のようになります。

<Location /OAM_admin>
SetHandler weblogic-handler
WebLogicCluster
OAMhost1.example.com:14200,OAMhost2.example.com:14200,OAMhsot3.example.com:14300
</Location>

脚注

脚注 1: 使用されるエージェントはデプロイメント固有であり、デプロイメントによって(異なる機能を持つ)様々なタイプのエージェントを使用できます。
脚注 2: Access Managerは、組込み資格証明コレクタだけでなく、外部資格証明コレクタもサポートできます。
脚注 3: 資格証明収集は、非ユーザー名およびパスワード認証スキームでは異なります。
脚注 4: WebGateのみが、バック・チャネル通信をサポートします。
脚注 5: エージェントは、Webリソースへのリクエストの転送を許可する前に、セッション・リフレッシュなどのいくつかのハウスキーピング・タスクを実行することがあります。

7 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は、このアーキテクチャによって、スケーラブルでフォルト・トレラントなソリューションとなっています。

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

- 7.1項「Oracle Adaptive Access Managerコンポーネント・アーキテクチャ」

- 第7.2項「Oracle Adaptive Access Managerの高可用性の概要」

- 第7.3項「Oracle Adaptive Access Managerの高可用性の構成手順」

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

図7-1は、Oracle Adaptive Access Managerの単一インスタンスのアーキテクチャを示しています。

図7-1 Oracle Adaptive Access Managerの単一インスタンス・アーキテクチャ

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データベースにはポリシーと構成情報が格納されます。

7.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を使用します。

- OAAM_OFFLINE: このコンポーネントはスタンドアロン・アプリケーションです。OAAMオフラインには、独自のデータベースがあります。このデータベースには、OAAMオンライン・バージョンのものと同じスキーマがあります。これは、カスタマ・データをロードしてリスク分析やルールのチューニングを行うために使用されます。OAAMオフラインでは、ログイン・データとトランザクション・データの両方をサポートできます。

次に示すコンポーネントも、Oracle Adaptive Access Manager 11gデプロイメントで使用できます。

- 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がサポートし、機能するデータベース・トポロジは、次のとおりです。

- Real Application Clusters

- Oracle Data Guard

- レプリケーション・ストリーム

- データベース・パーティション化

Oracle Adaptive Access Managerは、RCUを使用してデータベースにそのスキーマを作成します。

7.1.1.1 Oracle Adaptive Access Managerの状態情報

OAAM_Serverコンポーネントには、OAAM ServerサブコンポーネントとOAAM Adminサブコンポーネントが含まれています。

- OAAM Serverは、HTTPセッションに状態を格納するステートフル・アプリケーションです。

- OAAM Adminは、データベースにそのセッション情報を格納するステートフル・アプリケーションです。

OAAM_Adminコンポーネントは、ADFおよびアイデンティティ管理UIシェルベース・アプリケーションです。それは、ステートレス・アプリケーションであり、そのアプリケーションの状態は、ADFフレームワークによって保持されます。

OAAM_OFFLINEコンポーネントは、HTTPセッションに状態を格納するステートフル・アプリケーションです。

7.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を使用してランタイム処理も実行できます。

7.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は、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。

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

Oracle Adaptive Access Managerは、その構成情報をデータベースに格納します。これらの構成プロパティを変更するには、Oracle Adaptive Access Manager管理コンソールを使用します。

Oracle Adaptive Access Managerは、構成情報をファイル・システムや展開したEARファイルに格納することはありません。

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

Oracle Adaptive Access Managerは、デプロイメント・ステージングのnostageモードをサポートします。つまり、すべてのデプロイメント・ファイルはローカルです。

7.1.1.6 Oracle Adaptive Access Managerの外部依存性

Oracle Adaptive Access Managerは、RDBMSデータベースに外部依存し、それに構成情報を格納します。

Oracle Adaptive Access Managerは、Oracle RACデータベースに対してWebLogic Serverマルチ・データ・ソースおよびGridlinkデータ・ソースを使用します。

Oracle Adaptive Access Managerは、標準Oracle TopLinkオブジェクト・キャッシュ・メカニズムを使用します。

Oracle Adaptive Access Managerは、標準セッション・オブジェクト・シリアライズを使用して、オブジェクトの永続状態を保持します。

Oracle Adaptive Access Managerは、どのようなホスト名、IPアドレス、またはポートにも依存しません。コンテナ固有のポートまたはホスト名で機能します。

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

7.2 Oracle Adaptive Access Managerの高可用性の概要

この項では、Oracle Adaptive Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。

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

図7-2は、Oracle Adaptive Access Managerの高可用性アーキテクチャを示しています。

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

図7-2では、ロード・バランサが受信リクエストを受信し、そのリクエストをWeb層のWEBHOST1またはWEBHOST2にルーティングしています。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverは、WebLogicプラグインmod_wl_ohs.confを使用して、OAAMHOST1およびOAAMHOST2上のWebLogic管理対象サーバーにリクエストを転送します。

OAAMHOST1およびOAAMHOST2には、Oracle Adaptive Access Managerサーバーをホストする管理対象サーバー、Oracle Adaptive Access Manager AdminおよびOracle Adaptive Access Manager Offlineアプリケーションが含まれています。管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。

WebLogic管理サーバーは、OAAMHOST1上で実行され、WebLogic管理コンソールとOracle Enterprise Manager Fusion Middleware Controlを含んでいます。管理サーバーは、OAAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAAMHOST1が使用不可になった場合に、管理サーバーをOAAMHOST2上で手動で起動できます。

Oracle RACデータベースは、データ層における高可用性を提供します。

1つのWebLogic ServerドメインでサポートされるOAAM Serverクラスタ、OAAM OfflineクラスタおよびOAAM 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接続の早すぎる終了を回避するために、ロード・バランシング・ルーターとファイアウォール接続タイムアウトを十分大きい値にする必要があります。

7.2.1.1 クラスタの起動と停止

各Oracle Adaptive Access Manager管理コンソールおよびサーバー・インスタンスは、他のインスタンスのピアです。すべての初期化はサーバーがリクエストを受信できるようになる前に行われ、さらに組込みのスロットル機能が存在するため、サージ状態はOracle Adaptive Access Manager 11gR2アクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく正常に処理されます。

クラスタが停止した場合、新しいリクエストは拒否され、既存のリクエストはOracle Adaptive Access Manager管理コンソールおよびサーバー・アプリケーションが停止する前に完了できます。強制シャットダウンが行われた場合、Oracle Adaptive Access Manager 11gR1は、その強制シャットダウンによって破損または無効になったデータをリカバリします。

Oracle Adaptive Access Managerコンポーネントは、Pure J2EEアプリケーションであり、それ自体に起動および停止の機能はありません。かわりに、それらは、コンテナ固有の起動および停止機能に依存します。

Oracle Adaptive Access Managerコンポーネントは、WebLogic Server管理対象サーバー・ノードにデプロイされます。ノード・マネージャを使用してコンポーネントを再起動します。

7.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つのクラスタ当たりのインスタンス数に制限はありません。

オンライン・アプリケーション・デプロイメントによって問題が発生することはありません。

7.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がそのデータベース接続の状態を保持しているためです。

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

この項では、Oracle Adaptive Access Managerで最大限の高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAAMサーバーに配布します。これらのOAAMサーバーは、Oracle Real Application Clusters (Oracle RAC)データベースと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。

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

- 第7.3.1項「Oracle Adaptive Access Managerの構成のための前提条件」

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

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

- 第7.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」

- 第7.3.5項「ドメイン用のデータベース・セキュリティ・ストアの構成」

- 第7.3.6項「OAAMHOST1での管理サーバー用boot.propertiesの作成」

- 第7.3.7項「Oracle Adaptive Access Manager管理ユーザーの作成」

- 第7.3.8項「OAAMHOST1の起動」

- 第7.3.9項「OAAMHOST1の検証」

- 第7.3.10項「OAAMHOST2におけるOracle Adaptive Access Managerの構成」

- 第7.3.11項「OAAMHOST2の起動」

- 第7.3.12項「OAAMHOST2の検証」

- 第7.3.13項「Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成」

- 第7.3.14項「Oracle Adaptive Access Managerの構成の検証」

- 第7.3.15項「Oracle Adaptive Access Managerトポロジのスケール・アップとスケール・アウト」

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

Oracle Adaptive Access Managerを高可用性のために構成する前に、次の操作を実行しておく必要があります。

- データベースにOAAMスキーマを作成するためにリポジトリ作成ユーティリティを実行します。第7.3.2項「データベースにOAAMスキーマを作成するためのリポジトリ作成ユーティリティの実行」を参照してください。

- OAAMHOST1およびOAAMHOST2にOracle WebLogic Serverをインストールします。第7.3.3項「Oracle WebLogic Serverのインストール」を参照してください。

- OAAMHOST1およびOAAMHOST2にOracle Identity Management実行可能ファイルをインストールし、構成します。第7.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」を参照して手順に従います。

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

作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。RCU実行の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・プランニング・ガイド』および『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

7.3.3 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverをインストールする前に、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』で指定されているように、ご使用のマシンのシステム、パッチ、カーネルの要件、およびその他の要件が満たされていることを確認します。

Oracle WebLogic ServerをOAAMHOST1およびOAAMHOST2にインストールするには、インストーラを起動後、次の手順を実行します。

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の実行」の選択を解除します。
「完了」をクリックします。

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

この項では、Oracle Fusion MiddlewareコンポーネントをOAAMHOST1およびOAAMHOST2にインストールする方法について説明します。

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

次の手順を実行して、Oracle Fusion MiddlewareコンポーネントをOAAMHOST1およびOAAMHOST2にインストールします。

/etc/oraInst.locファイルが存在している場合は、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。/etc/oraInst.locファイルが存在しない場合は、この手順をスキップできます。

次のようにOracle Fusion Middlewareのインストーラを起動します。

OAAMHOST1> runInstaller

インストーラでJRE/JDKの場所を入力するように求められたら、WebLogic Serverのインストールで作成したOracle SDKの場所(例: ORACLE_BASE/product/fmw/jrockit_160_<バージョン>)を入力して、次の手順を実行します。

1. 「ようこそ」画面で、「次へ」をクリックします。

2. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

3. 「インストール場所の指定」画面で、次の値を入力します。

- Oracle Middlewareホーム: MW_HOMEのリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。

/u01/app/oracle/product/fmw

- Oracleホーム・ディレクトリ:

- IAM_ORACLE_HOMEにOracle Identity and Access Management Suiteをインストールする際には、Oracleホーム・ディレクトリ名としてiamを入力します。

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

4. 「インストール・サマリー」画面で「インストール」をクリックします。

5. 「インストール完了」画面で「終了」をクリックします。

7.3.4.1.1 OAAMHOST1におけるOracle Access Managerの構成

この項では、OAAMHOST1にドメインを作成します。

次のコマンドを実行して、構成ウィザードを起動します。

ORACLE_HOME/oracle_common/common/bin/config.sh

次の手順を続行します。

1. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

2. 「ドメイン・ソースの選択」画面で、次を選択します。
「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

次の製品を選択します。

- Oracle Enterprise Manager

- Oracle JRF(デフォルトで選択)

- Oracle Adaptive Access Manager - サーバー

- Oracle Adaptive Access Manager管理サーバー

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

3. 「ドメイン名と場所の指定」画面で、次を入力します。

- ドメイン名: IDM_Domain

- ドメイン・ディレクトリ: デフォルトを受け入れます。

- アプリケーション・ディレクトリ: デフォルトを受け入れます。

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

4. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。

5. 「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。

- WebLogicドメインの起動モード: 「本番モード」を選択します。

- JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。

6. 「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
「次へ」をクリックします。

7. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAAM Admin Serverを選択し、次の項目を入力します。

- データ・ソース: OAAM Admin Server

- サービス名: oaam.example.com

- ユーザー名: OAAM_OAAM (OAAMがRCU接頭辞として使用されていたと想定)

- パスワード: 前述のアカウント用のパスワード

右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。

- ホスト名: OAAMDBHOST1

- インスタンス名: oaamdb1

- ポート: 1521

再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。

- ホスト名: OAAMDBHOST2

- インスタンス名: oaamdb2

- ポート: 1521

このデータ・ソースの選択を解除します。次のデータ・ソースであるOAAM Admin MDSスキーマを選択し、次の情報を入力します。

- データ・ソース: OAAM Admin MDSスキーマ

- サービス名: oaam.example.com

- ユーザー名: OAAM_MDS (OAAMがRCU接頭辞として使用されていたと想定)

- パスワード: OAAM_MDSアカウント用パスワードです。

右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。

- ホスト名: OAAMDBHOST1

- インスタンス名: oaamdb1

- ポート: 1521

再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。

- ホスト名: OAAMDBHOST2

- インスタンス名: oaamdb2

- ポート: 1521

このデータ・ソースの選択を解除します。次のデータ・ソースであるOAAM Serverを選択し、次の情報を入力します。

- データ・ソース: OAAM Server

- サービス名: oaam.example.com

- ユーザー名: OAAM_OAAM (OAAMがRCU接頭辞として使用されていたと想定)

- パスワード: OAAM_OAAMアカウント用パスワードです。

右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。

- ホスト名: OAAMDBHOST1

- インスタンス名: oaamdb1

- ポート: 1521

再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。

- ホスト名: OAAMDBHOST2

- インスタンス名: oaamdb2

- ポート: 1521

このデータ・ソースの選択を解除します。次のデータ・ソースであるOWSM MDSスキーマを選択し、次の情報を入力します。

- データ・ソース: OWSM MDSスキーマ

- サービス名: oaam.example.com

- ユーザー名: OAAM_MDS (OAAMがRCU接頭辞として使用されていたと想定)

- パスワード: OAAM_MDSアカウント用パスワードです。

右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。

- ホスト名: INFRADBHOST1

- インスタンス名: oaamdb1

- ポート: 1521

再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。

- ホスト名: INFRADBHOST2

- インスタンス名: oaamdb2

- ポート: 1521

このデータ・ソースの選択を解除します。

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

8. 「コンポーネント・スキーマのテスト」画面で、データ・ソースの検証が試行されます。
データ・ソースの検証が成功したら、「次へ」をクリックします。

失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。

9. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

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

10. 「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。

11. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: 管理サーバーの仮想ホスト名を入力します(例: OAAMHOST1.example.com)。

- リスニング・ポート: 7001

- SSLリスニング・ポート: 適用なし

- SSL有効: 選択を解除

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

12. 「管理対象サーバーの構成」画面で、トポロジのOAAMHOSTごとに3つのエントリを作成します(OAAM Server、OAAM Admin ServerおよびOAAM Offline Serverに対して1つずつ)。
OAAM_SERVERエントリを選択し、そのエントリを次の値に変更します。

- 名前: WLS_OAAM1_SERVER1

- リスニング・アドレス: OAAMHOST1.example.com

- リスニング・ポート: 14300

- SSLリスニング・ポート: 14301

- SSL有効: 選択します。

2つ目のOAAM_SERVERに対して、「追加」をクリックし、次の情報を入力します。

- 名前: WLS_OAAM2_SERVER2

- リスニング・アドレス: OAAMHOST2.example.com

- リスニング・ポート: 14300

- SSLリスニング・ポート: 14301

- SSL有効: 選択します。

OAAM Offlineエントリを選択し、そのエントリを次の値に変更します。

- 名前: WLS_OAAM_OFFLINE1

- リスニング・アドレス: OAAMHOST1.example.com

- リスニング・ポート: 14400

- SSLリスニング・ポート: 14401

- SSL有効: 選択します。

2番目のOAAM Offlineに対して、「追加」をクリックし、次の情報を入力します。

- 名前: WLS_OAAM_OFFLINE2

- リスニング・アドレス: OAAMHOST2.example.com

- リスニング・ポート: 14400

- SSLリスニング・ポート: 14401

- SSL有効: 選択します。

OAAM_ADMIN_SERVERエントリを選択し、そのエントリを次の値に変更します。

- 名前: WLS_OAAM_ADMIN1

- リスニング・アドレス: OAAMHOST1.example.com

- リスニング・ポート: 14200

- SSLリスニング・ポート: 14201

- SSL有効: 選択します。

2つ目のOAAM_ADMIN_SERVERに対して、「追加」をクリックし、次の情報を入力します。

- 名前: WLS_OAAM_ADMIN2

- リスニング・アドレス: OAAMHOST2.example.com

- リスニング・ポート: 14200

- SSLリスニング・ポート: 14201

- SSL有効: 選択します。

その他すべてのフィールドはデフォルトの設定のままにします。

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

13. 「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前としてOAAM_SERVER_CLUSTERを入力します。

「追加」をクリックして2番目のクラスタを作成します。

名前としてOAAM_Offline_Clusterを入力します。

「追加」をクリックして3番目のクラスタを作成します。

名前としてOAAM_Admin_Clusterを入力します。

その他すべてのフィールドはデフォルトの設定のままにします。

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

14. 「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。

- 右のウィンドウでクラスタ名OAAM_SERVER_CLUSTERをクリックします。

- 管理対象サーバーWLS_OAAM1_SERVER1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。

- 管理対象サーバーWLS_OAAM2_SERVER2に対しても同様に繰り返します。

その後、次の操作を実行します。

- 右のウィンドウでクラスタ名OAAM_OFFLINE_Clusterをクリックします。

- 管理対象サーバーWLS_OAAM_OFFLINE1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。

- 管理対象サーバーWLS_OAAM_OFFLINE2に対しても同様に繰り返します。

その後、次の操作を実行します。

- 右のウィンドウでクラスタ名OAAM_Admin_Clusterをクリックします。

- 管理対象サーバーWLS_OAAM_ADMIN1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。

- 管理対象サーバーWLS_OAAM_ADMIN2に対しても同様に繰り返します。

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

15. 「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を指定します。

- 名前: ホスト名です。ベスト・プラクティスは、DNS名(OAAMHOST1)を使用することです。

- ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAAMHOST1.example.com)

- ノード・マネージャ・ポート: ノード・マネージャが使用するポート。

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

16. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。
OAAMHOST1について、次のように操作します。

- 右のウィンドウでマシンOAAMHOST1をクリックします。

- 左のウィンドウで管理対象サーバーWLS_OAAM1_SERVER1をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。

- 左のウィンドウで管理対象サーバーWLS_OAAM_OFFLINE1をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。

- 左のウィンドウで管理対象サーバーWLS_OAAM_ADMIN1をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。

OAAMHOST2について、次のように操作します。

- 右のウィンドウでマシンOAAMHOST2をクリックします。

- 左のウィンドウで管理対象サーバーWLS_OAAM2_SERVER2をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。

- 左のウィンドウで管理対象サーバーWLS_OAAM_OFFLINE2をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。

- 左のウィンドウで管理対象サーバーWLS_OAAM_ADMIN2をクリックします。

- 矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。

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

17. 「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。

7.3.5 ドメイン用のデータベース・セキュリティ・ストアの構成

ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、第7.3.5項「ドメイン用のデータベース・セキュリティ・ストアの構成」を参照してください。

7.3.6 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.example.com:7001/console

- Oracle Enterprise Manager Fusion Middleware Control:

http://oaamhost1.example.com:7001/em

weblogicユーザーの資格証明を使用して、これらのコンソールにログインします。

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

OAAMコンソールへのアクセスに使用する管理ユーザーを作成するには、次の手順を実行します。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oaamhost1.example.com:7001/console

2. 「ドメイン構造」メニューで、「セキュリティ・レルム」→「myrealm」を選択します。

3. 「ユーザーとグループ」タブをクリックします。

4. 「ユーザー」サブタブをクリックします。

5. 「新規」をクリックします。

6. 次の値を入力します。

- 名前: ユーザーの名前(例: oaamadmin)

- プロバイダ: デフォルト・オーセンティケータ

- パスワード/確認: ユーザーのパスワード

「OK」をクリックします。

7. ユーザーを作成したら、ユーザー名をクリックします。

8. 「グループ」サブタブをクリックします。

9. ユーザーを次のグループに割り当てます。

- OAAMCSRGroup

- OAAMCSRManagerGroup

- OAAMInvestigatorGroup

- OAAMInvestigationManagerGroup

- OAAMRuleAdministratorGroup

- OAAMEnvAdminGroup

- OAAMSOAPServicesGroup

「保存」をクリックします。

7.3.8 OAAMHOST1の起動

この項では、OAAMHOST1の起動手順について説明します。

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

コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:

OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

7.3.8.2 ノード・マネージャの起動

次のコマンドを発行してノード・マネージャを起動します。

OAAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

7.3.8.3 OAAMHOST1でのOracle Adaptive Access Managerの起動

OAAMHOST1上のOracle Adaptive Access Managerを起動する手順は、次のとおりです。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oaamhost1.example.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを指定します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバーWLS_OAAM1_SERVER1、WLS_OAAM_OFFLINE1およびWLS_OAAM_ADMIN1をクリックします。

6. 「起動」をクリックします。

7. 「OK」をクリックし、サーバーを起動することを確認します。

7.3.9 OAAMHOST1の検証

次のURLにあるOAAM管理サーバーに接続することによって実装を検証します。

http://OAAMHOST1.example.com:14200/oaam_admin

OAAM管理コンソールのログイン・ページが表示され、第7.3.7項「Oracle Adaptive Access Manager管理ユーザーの作成」で作成したoaamadminアカウントを使用してログインできる場合、実装は有効です。

次の場所にあるOAAMサーバーに接続することによって実装を検証します:

http://OAAMHOST1.example.com:14300/oaam_server

OAAMサーバーのログイン・ページが表示されると、実装は有効です。

7.3.10 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

7.3.11 OAAMHOST2の起動

OAAMHOST2を起動します。

この項では、OAAMHOST2の起動手順について説明します。

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

コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:

OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

7.3.11.2 ノード・マネージャの起動

次のコマンドを発行してノード・マネージャを起動します。

OAAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

7.3.11.3 OAAMHOST2でのOracle Adaptive Access Managerの起動

OAAMHOST2上のOracle Adaptive Access Managerを起動する手順は、次のとおりです。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oaamhost2.example.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを指定します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバーWLS_OAAM2_SERVER2、WLS_OAAM_OFFLINE2およびWLS_OAAM_ADMIN2をクリックします。

6. 「起動」をクリックします。

7. 「OK」をクリックし、サーバーを起動することを確認します。

7.3.12 OAAMHOST2の検証

次のURLにあるOAAM管理サーバーに接続することによって実装を検証します。

http://OAAMHOST2.example.com:14200/oaam_admin

OAAM管理コンソールのログイン・ページが表示され、第7.3.7項「Oracle Adaptive Access Manager管理ユーザーの作成」で作成したoaamadminアカウントを使用してログインできる場合、実装は有効です。

次の場所にあるOAAMサーバーに接続することによって実装を検証します:

http://OAAMHOST2.example.com:14400/oaam_server

OAAMサーバーのログイン・ページが表示されると、実装は有効です。

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

この項では、Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成手順について説明します。

7.3.13.1 Oracle HTTP Server構成の更新

WEBHOST1およびWEBHOST2で、次のディレクトリにoaam.confというファイルを作成します。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

次の行を指定してファイルを作成します。

NameVirtualHost *:7777
<VirtualHost *:7777>

ServerName oaam.example.com:7777
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit

<Location /oaam_server>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.example.com:14300,oaamhost2.example.com:14300
</Location>

<Location /oaam_offline>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.example.com:14400,oaamhost2.example.com:14400
WebLogicPort 7001
</Location>

<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster oaamhost1.example.com:14200,oaamhost2.example.com:14200
WebLogicPort 7001
</Location>

</VirtualHost>

7.3.13.2 Oracle HTTP Serverの再起動

WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。

WEBHOST1>opmnctl stopall
WEBHOST1>opmnctl startall

WEBHOST2>opmnctl stopall
WEBHOST2>opmnctl startall

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

Oracle HTTP Serverは、WebLogicのプロキシとして機能するため、デフォルトでは、特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。

そのためには、次のWebLogic管理コンソールにログインします。

http://oaamhost1.example.com:7001/console

次の手順を実行します。

1. ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。

2. 「チェンジ・センター」ウィンドウで「ロックして編集」をクリックし、編集可能にします。

3. クラスタ名(OAAM_SERVER_CLUSTER)をクリックします。

4. 「一般」タブで、「拡張プロパティ」セクションのボックスを選択して、WebLogicプラグインを「有効」に設定します。

5. 「保存」をクリックします。

6. 「HTTP」を選択して、次の値を入力します。

- フロントエンド・ホスト: oaam.example.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.example.com

- フロントエンドHTTPポート: 7777

- フロントエンドHTTPSポート: SSL通信を使用している場合は、ロード・バランサ上のSSLポートまたはOracle HTTP Server SSLポートに設定します。

13. 「保存」をクリックします。

14. 「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックし、変更を保存します。

15. 管理対象サーバーWLS_OAAM1_SERVER1、WLS_OAAM2_SERVER2、WLS_OAAM_OFFLINE1、WLS_OAAM_OFFLINE2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2を次のようにして再起動します。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://oaamhost1.example.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを指定します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバーWLS_OAAM1_SERVER1、WLS_OAAM2_SERVER2、WLS_OAAM_OFFLINE1、WLS_OAAM_OFFLINE2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2をクリックします。

6. 「停止 - ただちに強制停止」を選択します。

7. 「はい」をクリックし、サーバーを停止することを確認します。

8. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

9. 「制御」タブをクリックします。

10. サーバーWLS_OAAM1_SERVER1、WLS_OAAM2_SERVER2、WLS_OAAM_OFFLINE1、WLS_OAAM_OFFLINE2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2をクリックします。

11. 「起動」をクリックします。

12. 「はい」をクリックし、サーバーを起動することを確認します。

16. 管理サーバーを再起動します。

7.3.14 Oracle Adaptive Access Managerの構成の検証

Oracle Adaptive Access Manager管理コンソール(http://oaam.example.com:7777/oaam_admin)に、作成したoaamadminアカウントを使用してログインします。

Oracle Adaptive Access Managerサーバー(http://oaam.example.com:7777/oaam_offline)に、oaamadminアカウントおよびパスワード・テストを使用してログインします。

Oracle Adaptive Access Managerサーバー(http://oaam.example.com:7777/oaam_server)に、作成したoaamadminアカウントおよびパスワード・テストを使用してログインします。

『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の「7.7 インストール後の手順」の項で説明されている手順を完了します。

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

この項では、Oracle Adaptive Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいOracle Adaptive Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいOracle Adaptive Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。

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

OAAMをスケール・アップするには、OAAMサーバーとOAAM管理サーバーの両方について同じ手順を実行します。

Oracle WebLogic Serverコンソール(http://oaamhost1.example.com:7001/console)にログインします。次の手順を実行します。

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーのサマリー」ページが表示されます。

2. 「チェンジ・センター」メニューで「ロックして編集」をクリックします。

3. 拡張するホストで既存のサーバーを選択します(例: WLS_OAAM1_SERVER1またはWLS_OAAM_ADMIN1)。

4. 「クローンの作成」をクリックします。

5. 次の情報を入力します。

- サーバー名: サーバーの新しい名前です(例: WLS_OAAM3)。

- サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。

6. 「OK」をクリックします。

7. 新規作成サーバーの「WLS_OAAM3」をクリックします。

8. SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。

9. 「保存」をクリックします。

10. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAAMHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。

1. Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ペインで、「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

11. 構成のアクティブ化を「チェンジ・センター」メニューでクリックします。

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

スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。次の手順を実行します。

1. 第5.3.1.1.1項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。

2. 新しいホストにOracle Fusion Middleware Identity Managementコンポーネントをインストールします。第7.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」を参照してください。

3. WebLogicコンソール(http://oaamhost1.example.com:7001/console)にログインします。

4. 管理コンソールの「ドメイン構造」ペインで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。

5. 「チェンジ・センター」メニューで「ロックして編集」をクリックします。

6. 拡張するホストで既存のサーバーを選択します(例: WLS_OAAM1_SERVER1またはWLS_OAAM_ADMIN1)。

7. 「クローンの作成」をクリックします。

8. 次の情報を入力します。

- サーバー名: サーバーの新しい名前です(例: WLS_OAAM3)。

- サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。

9. 「OK」をクリックします。

10. 新規作成サーバーの「WLS_OAAM3」をクリックします。

11. SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。

12. 「保存」をクリックします。

13. 新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAAMHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。

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.example.com:14200,oaamhost2.example.com:14200
</Location>

変更後は次のようになります。

<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster
oaamhost1.example.com:14200,oaamhost2.example.com:14200,oaamhost3.example.com:14300
</Location>

8 Oracle Access Management Security Token Serviceの高可用性の構成

この章では、Oracle Access Management Security Token Serviceの高可用性について説明します。

Security Token Serviceは、共有Webサービス(JAX-WS)であり、様々なIdentityドメインとインフラストラクチャ層との間での信頼を仲介する機能が統合された標準ベースのメカニズムを提供します。Security Token Serviceブローカは、Webサービス利用者(WSC)とWebサービス・プロバイダ(WSP)との間において信頼関係があり、セキュリティ・トークンのライフサイクル管理サービスを利用者とプロバイダに提供します。Security Token Serviceでは、標準化されたインタフェースのセットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。

Security Token Serviceの高可用性デプロイメントは、Oracle Access Management Access Managerに依存します。Access Managerアプリケーションには、Oracle Security Token Serviceのサーバー・ランタイムが含まれています。Security Token Serviceの高可用性デプロイメントは、Access Managerがなければ成り立ちません。Access ManagerとSecurity Token Serviceは、どちらもOAM J2EEアプリケーションEARファイルに同梱されていて、WebLogicドメイン内の同じ管理対象サーバーにまとめてインストールされ、デプロイされます。さらに、Security Token Serviceは、Oracle Access Managementコンソールに統合されます。

Security Token Serviceの管理と構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の次のいずれかの項目を参照してください。

Security Token Serviceの管理と構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の次のいずれかの項目を参照してください。

- Security Token Serviceの主な用語と概要

- Security Token Serviceについて

- Security Token Serviceのデプロイメントについて

- Security Token Serviceの管理について

- Security Token Serviceの実装シナリオ

- Security Token Serviceの設定値と設定の管理

- Security Token Serviceの証明書と鍵の管理

- テンプレート、エンドポイントおよびポリシーの管理

- Token Serviceパートナとパートナ・プロファイルの管理

パッチの適用については、Oracle Access Managerの管理の第11.1.1.3.0項から第11.1.1.6.0項を参照してください。

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

- 第8.1項「Security Token Serviceの高可用性アーキテクチャ」

- 第8.2項「Security Token Serviceコンポーネントの特性」

- 第8.3項「Security Token Serviceの高可用性の構成手順」

- 第8.4項「Security Token Serviceの高可用性の検証」

- 第8.5項「Security Token Serviceの障害と予想される動作」

- 第8.6項「Security Token Serviceの無効化および有効化」

- 第8.7項「Security Token Serviceのトラブルシューティング」

- 第8.8項「ログ・ファイルの場所」

- 第8.9項「その他の考慮事項」

8.1 Security Token Serviceの高可用性アーキテクチャ

次の図は、高可用性アーキテクチャのSecurity Token Serviceを示しています。

図8-1 Security Token Serviceの高可用性アーキテクチャ

この図は、Access ManagerとSecurity Token Serviceコンポーネントの2ノード・デプロイメントを示しています。この項では、Security Token Serviceの高可用性デプロイメントについて詳しく説明します。Access Managerの全体的な高可用性アーキテクチャの詳細は、第6.2.1項「Access Managerの高可用性アーキテクチャ」を参照してください。

Security Token Serviceは、WS-Trustプロトコルのサポートを実装するサーバー側コンポーネントです。

ロード・バランサはトークン・リクエストを受信すると、そのリクエストをSecurity Token Service (STS)にルーティングします。

RACデータベースは、Access ManagerによってCoherenceバックエンド・ストアとして使用されるデータベースと同じです。

Oracle Access Managementコンソールは、Security Token Serviceデプロイメントを管理するためのサービスを提供するJ2EEアプリケーションです。OAMデプロイメントの一部として、管理コンソールをWeblogic管理サーバーにデプロイする必要があります。

Security Token Serviceの場合、各WebLogic Serverドメインで1つのSecurity Token Serviceクラスタがサポートされます。OAMとSecurity Token Serviceのクラスタは、WebLogic Serverドメイン間にまたがることはできません。

Security Token Serviceは、主にOASIS WS-Trustプロトコルを基盤とします。ただし、Security Token Serviceは、SOAPメッセージに含まれるその他のWS-*プロトコルの処理を、JAX-WSスタックに委任します。

HTTP/SOAPのインバウンド接続には、外部ロード・バランサを使用することをお薦めします。LDAPに対するアウトバウンド外部接続は、接続フェイルオーバーのサポートとともにロード・バランシングされます。

8.1.1クライアントとクライアント接続

WS-Trustプロトコルを実装するWebサービス・クライアントは、トークンの発行および検証のために、Security Token Serviceと対話します。STSサーバーと対話するように設計されたクライアント(OWSMクライアントなど)は、リライイング・パーティへのWebサービス・コールの一環として、Security Token Serviceを呼び出すことができます。

このクライアント接続は、次のように処理されます。

1. Webサービス・クライアントは、httpまたはhttpsによってSOAPメッセージを送信します。
WSSプロトコルによって、メッセージを保護します。ペイロードには、実行する操作、発行または検証するトークンの種類、およびトークンの特性についての追加情報を示すWS-Trustリクエスト(RST)が格納されます。

2. サーバーはリクエストを処理して、そのリクエストをサーバーが受信したチャネルと同じチャネルでレスポンスを送信します。
WSSプロトコルによって、メッセージを保護します。処理が成功したときには、ペイロードにWS-Trustレスポンス(RSTRC)が格納されます。エラーが発生したときには、SOAP障害が格納されます。

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

Security Token Serviceアクセス・サーバーの各インスタンスは、他のインスタンスのピアになりますがインスタンス間の通信はありません。サーバーがリクエストを受信できるようになる前に、すべての初期化が組込のスロット機能と同時に行われるため、WebLogic ServerはSecurity Token Serviceアクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく急増する条件を適切に処理します。

クラスタが停止すると、Security Token Serviceは新しいリクエストを拒否し、アクセス・サーバーのアプリケーションが停止する前に既存のリクエストを完了できるようにします。強制停止が行われた場合、Security Token Serviceはその強制停止によって破損または無効になったデータをリカバリできます。

構成の変更は、Coherence分散オブジェクト・キャッシュを利用する分散メカニズムに基づいて、すべてのクラスタ・メンバー伝播されます。Coherenceレイヤーは、すべてのSecurity Token Serviceコンポーネントに変更イベントを通知します。その後、このコンポーネントはそれらの変更を取り込みます。Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。

注意:

アクセス・サーバーのインスタンスの追加または削除は、クラスタ内の他のSecurity Token Serviceインスタンスに対して透過的になります。特定のSecurity Token Serviceサーバーの削除が、ロードに影響しないことを確認してください。

8.2 Security Token Serviceコンポーネントの特性

この項では、Security Token Serviceコンポーネントの特性と、次の項目について説明します。

- 第8.2.1項「Security Token Serviceコンポーネントのライフサイクル」

- 第8.2.2項「ランタイム・プロセス」

- 第8.2.3項「構成アーティファクト」

- 第8.2.4項「外部依存性」

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

起動時に、Access ManagerとSecurity Token Service Serverは、バックエンド・リポジトリへの接続を初期化します。このリポジトリにアクセスできない場合、Access ManagerとSecurity Token Serviceサーバーは、指数関数的に増加するタイムアウトを使用してリポジトリへの接続を再試行します(このタイムアウトは上限を構成できます)。

Access ManagerとSecurity Token Service Serverは、バックエンドの接続が停止したときには、ローカルにキャッシュしたデータに基づいてサービスの持続性を提供します。サービスは、キャッシュの有効性が失われるか、バックエンドの接続が回復するまで持続されます。

8.2.2 ランタイム・プロセス

次の図は、Security Token Serviceのランタイム・プロセスを示しています。

図8-2 Security Token Serviceのランタイム・プロセス

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.2.2.1 Security Token Serviceの起動と停止

アクセス・サーバー(Security Token Serviceのデプロイ先)と管理コンソールは、どちらもJ2EEアプリケーションであるため、アプリケーション・サーバーが提供するユーザー・インタフェースやコマンド行ツールから起動できます。

8.2.2.2 J2EEのコンポーネントとサブコンポーネント

J2EEのコンポーネントとサブコンポーネントには、次のものがあります。

- STS: イベント・ベースのデザイン・パターンであり、Security Token Service 11g-PS1の中核部分を実装します。WARアプリケーションとしてAccess Manager EARファイルにパッケージ化されています。WSプロバイダ・サーブレットとJavaクラスが含まれています。STS Webアプリケーションは、/stsルート・パスにバインドされます。

- 管理コンソール: ADF/IDMシェルに基づくスタンドアロン・コンソールであり、.EARファイルとしてパッケージ化されています。

- JMX Mbeans: アクセス・サーバー・パッケージにパッケージ化されています。構成Mbeanは、スタンドアロンのJARファイルとしてパッケージ化されています。

- WSLTコマンド: Access Manager/Security Token Serviceパッケージに含まれているJavaクラスで構成されています。

- OWSMエージェント: WSSプロトコルのサポートを提供するWebサービスのインターセプタです。JRFに含まれます。

- ORAProvider: JRF Webサービス・プロバイダです。

8.2.2.3 セッションの状態情報

Security Token Serviceは、ステートレスのJ2EEアプリケーションですが、ユーザー名トークン用のNonceキャッシュがあり、Security Token Serviceはリプレイ攻撃を防止するために、Nonceが存在する場合は、提示されたユーザー名トークンを記録します。

8.2.3 構成アーティファクト

Access ManagerとSecurity Token Serviceは一組になるように構築され、構成やロギングなどのプロセスに同一のモジュールを使用します。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 — Access Manager/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証明書の検証に使用されるトラステッド・アンカーも格納されます。

- DOMAIN_HOME/config/fmwconfig/.cohstore.jks - Coherence SSL通信で使用されるトラスト・ストアです。

8.2.4 外部依存性

Security Token Serviceは、次の項目に対して外部依存性があります。

- LDAPベースのアイデンティティ・ストア

- ユーザー・アイデンティティ・リポジトリ

- ユーザー/ロールAPIによって抽象化されるLDAPアクセス

注意:

Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。

- OCSPレスポンダ・サービス

- リアルタイムX.509認証検証

- RDBMSポリシー・ストア/Coherenceストア

- ポリシー(認証および認可)リポジトリ

- OAMポリシー・エンジンによって抽象化されるRDBMSアクセス

- OPSSセキュリティ・ストア

8.3 Security Token Serviceの高可用性の構成手順

Security Token Serviceの高可用性は、Access Managerの一部として構成されます。Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。詳細は、第6.3項「Access Managerの高可用性の構成手順」を参照してください。

8.4 Security Token Serviceの高可用性の検証

個別のSecurity Token Serviceサーバー上のSecurity Token Serviceのエンドポイントが稼働状態であり実行中であることを検証できます。これを実行するには、Security Token ServiceのエンドポイントのWSDLドキュメント(http(s)://[hostname:port]/sts/[ENDPOINT]/WSDL)に直接アクセスします。

[ENDPOINT]の部分は、既存の公開エンドポイントに置換してください。

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

この項では、高可用性環境におけるSecurity Token Serviceのフェイルオーバーの特性について説明します。

Access Manager Access Serverは、ハートビート・チェック(HTTPによるPingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視して、そのアプリケーションを必要に応じて再起動できます。

WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。

ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出すると、後続のクライアント接続はアクティブなインスタンスにルーティングされます。このインスタンスは、セッション状態をCoherence分散オブジェクト・キャッシュから取得して処理を継続します。

フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。

別のサービスから例外を受信した場合、Access Managerは、外部接続リクエストを再試行します。再試行の回数は構成可能であり、no retriesのオプションもあります。

詳細は、次の各項を参照してください。

- 第8.5.1項「障害検出と再起動」

- 第8.5.2項「ノード障害」

8.5.1 障害検出と再起動

Access Manager Access ServerとSecurity Token Service Access Serverは、HTTPでPingリクエストを送信する方式によるハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャでは、アプリケーションを監視して、イベントが実行されていない場合にはアプリケーションを再起動できます。Access Manager Access Serverを再起動しても、その他のクラスタ・コンポーネントまたはメンバーに影響はありません。

8.5.2 ノード障害

外部接続のフェイルオーバーは、構成、再試行のタイムアウトおよび再試行の回数に基づいて行われます。ロード・バランサまたはプロキシ・サーバーはノード障害を検出すると、後続のクライアント接続をアクティブなインスタンスにルーティングし、このインスタンスが、Coherence DOCからセッション状態を取得して処理を継続します。

8.6 Security Token Serviceの有効化および無効化

Security Token Serviceは、デフォルトで有効化されています。Security Token Serviceを無効化するには、Oracle Access Managementコンソールを使用します。『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の使用可能なサービスの有効化または無効化に関する説明を参照してください。

8.7 セキュリティ・トークン・サービスのトラブルシューティング

Security Token Serviceのログは、管理対象サーバーのログ・ファイルに記録されます。ただし、logging.xmlを編集すると、Security Token Service情報を、<DomainHome>/config/fmwconfig/servers/<servername>/sts/log/フォルダの個別のログ・ファイル(diagnostic.log)に記録できます。

Security Token Serviceをトラブルシューティングするために、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 ログ・ファイルの場所

すべてのログ・メッセージは、アプリケーションがデプロイされたWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

8.9 その他の考慮事項

Security Token Serviceサーバーは、リプレイ攻撃などの偽のリクエストを検出できますが、リプレイ攻撃は、リクエストからトークン・データを不正入手しようとして、同じトークンで別のリクエストを送信した場合に発生することがあります。この場合には、サーバーは2番目の偽のリクエストを検出します。2番目に発行された<Env: Body>に同一のトークンを持つリクエストは、Security Token Serviceサーバーに送られます。このサーバーは、UNTトークン・キャッシュを確認して、リプレイ攻撃を示すリクエストを拒否します。

9 Identity Federationコンポーネントの高可用性の構成

この章では、Oracle Access Management Identity Federation 11gR2の高可用性について説明します。Identity Federationの詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のAccess Manager 11gR2との統合に関する項を参照してください。

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

- 第9.1項「Identity Federationコンポーネント・アーキテクチャ」

- 第9.2項「Identity Federationの高可用性の概要」

- 第9.3項「Identity Federationの高可用性の構成」

- 第9.4項「Identity Federationのフェイルオーバーおよび予想される動作」

- 第9.5項「Identity Federationの高可用性のトラブルシューティング」

9.1 Identity Federationコンポーネント・アーキテクチャ

Identity Federationサービスは、複数ドメインのアイデンティティ・ネットワークのOracle Access Management Access Managerに対してシングル・サインオン機能を提供します。もっとも広範なフェデレーション標準のセットがサポートされ、これにより、ソリューション・セットでその他のOracle Identity Management製品が実装されているかどうかに関係なく、異種環境とビジネス結合に属するユーザーのフェデレーションが可能になります。

Identity Federation 11gリリース2のみで、サービス・プロバイダ(SP)機能がサポートされます。アイデンティティ・プロバイダ(IDP)サポートでは、Identity Federation 11gリリース1を使用してください。

Identity Federationは、SPとして機能することで、帯域外の複数のセキュリティ・ドメイン間でユーザー同期をせずに、ユーザー認証をIDPにオフロードする間もリソース管理を可能にします。IDPで認証されると、SPは、ローカル・アクセス・ポリシーに応じて、そのSPのアプリケーションに対するユーザーのアクセスを許可または拒否できます。

ユーザーがそのIDPに対するアカウントを持っていない場合、フェデレーションは終了し、そのユーザーのドメイン間でのシングル・サインオンは自動的に無効化されます。

Identity Federationの主要な機能には、次のサポートが含まれます。

- SAML 1.x、SAML 2.0などの複数の主要なフェデレーション・プロトコル

- プロトコルを超えたシングル・サインオンおよびサインアウト

- X.509証明書検証

- Access Managerとのネイティブ統合

- Access ManagerによりサポートされるすべてのLDAPディレクトリとの統合

図9-1 Identity Federationアーキテクチャ

Identity FederationのAccess Managerとの統合方法の詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のAccess Manager 11gR2との統合に関する項を参照してください。

9.1.1 Identity Federationコンポーネントの特性

Identity Federationは、クロス・ドメイン・シングル・サインオンにSP機能を提供するOracle Access Managementコンポーネントです。Oracle Access Managementによるリモートアイデンティティ・プロバイダ・パートナへのユーザー認証の委任が可能になります。SAML 1.x、SAML 2.0などの広範なフェデレーション標準のセットをサポートします。

- 第9.1.1.1項「ランタイム・プロセス」

- 第9.1.1.2項「プロセスのライフサイクル」

- 第9.1.1.3項「リクエスト・フロー」

- 第9.1.1.4項「構成アーティファクト」

- 第9.1.1.5項「外部依存性」

- 第9.1.1.6項「Identity Federationのログ・ファイルの場所」

9.1.1.1 ランタイム・プロセス

Identity Federationは、WebLogic Server上にデプロイされるAccess Manager J2EEアプリケーションの一部です。

Identity FederationはAccess Server内で動作するため、ランタイム・プロセスはAccess Managerと同じです。詳細は、第6.1.1.2.1項「Access Managerプロセスのライフサイクル」を参照してください。

9.1.1.2 プロセスのライフサイクル

Identity FederationのプロセスのライフサイクルはAccess Managerと同じです。詳細は、第6.1.1.2.1項「Access Managerプロセスのライフサイクル」を参照してください。

9.1.1.3 リクエスト・フロー

Identity Federationのリクエスト・フローの詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のアーキテクチャに関する項を参照してください。

9.1.1.4 構成アーティファクト

Identity Federationの構成アーティファクトには、次のファイルが含まれます。

- 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/Identity Federationが所有する鍵と証明書を格納するキーストアです。

- 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証明書の検証に使用されるトラステッド・アンカーも格納されます。

- DOMAIN_HOME/config/fmwconfig/servers/servername/dms_config.xml — イベント構成ファイルです。

- DOMAIN_HOME/config/fmwconfig/component_events.xml — 監査定義です。

- DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml — 管理コンソールの権限です。

- DOMAIN_HOME/config/fmwconfig/cacerts.jks — 認証局証明書を格納するキーストアです。

9.1.1.5 外部依存性

Identity Federationサーバーの機能に必要な外部コンポーネントは次のとおりです。

- WebLogic Server

- 管理サーバー

- 管理対象サーバー

- LDAPベースのアイデンティティ・ストア

- ユーザー・アイデンティティ・リポジトリ

- ユーザー/ロールAPIによって抽象化されるLDAPアクセス

注意:

Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。

- OCSPレスポンダ・サービス

- リアルタイムX.509認証検証

- RDBMSポリシー・ストア/Coherenceストア

- ポリシー(認証および認可)リポジトリ

- Access Managerポリシー・エンジンによって抽象化されるRDBMSアクセス

- Oracle Entitlements Server (OAM経由)

- フェデレーション・データ・キャッシュ

- セッションおよびランタイム情報用。このために、メモリー・ストアまたはRDBMSストアを使用するようにIdentity Federationを構成できます。ただし、高可用性環境では、RDBMSストアを使用する必要があります。

データ・リポジトリ

フェデレーションに関連するセッション情報、ユーザーがサイン・インしたパートナおよびプロトコル・データはセッションおよびキャッシュに格納されます。このデータのために、メモリー・ストアまたはRDBMSストアを使用するようにIdentity Federationを構成できます。高可用性環境では、RDBMSストアを使用する必要があります。

9.1.1.6 Identity Federationのログ・ファイルの場所

WebLogic Serverのログ・ファイルのデフォルトの場所は次のとおりです。

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

ログ・ファイルを表示するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。

9.2 Identity Federationの高可用性の概要

この項では、Identity Federationを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。

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

- 第9.2.1項「Identity Federationの高可用性アーキテクチャ」

- 第9.2.2項「Identity Federationの前提条件」

9.2.1 Identity Federationの高可用性アーキテクチャ

図9-2は、Identity Federationのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。

図9-2 高可用性アーキテクチャのIdentity Federation

図9-2では、ハードウェアのロード・バランサが着信認証リクエストを受信し、それらをWeb層のWebサーバーにルーティングしています。これらのホストにはOracle HTTP Serverがインストールされています。Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohs.confが使用されてWebLogic管理対象サーバーにリクエストが転送されます。

ロード・バランシング・ルーターは、HTTPトラフィックに対してのみセッション・スティックネスを使用する必要があります。

Oracle Access Serverアプリケーションをホストする2つの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ・モードで動作できるように、クラスタで構成されます。

アクセスされるリソースがフェデレーション・スキームによって保護される場合、OAMはフェデレーション・エンジンを使用してユーザーを認証します。

フェデレーション・エンジンによって使用されるLDAPディレクトリは、クラスタ内にデプロイされます。

Oracle RACデータベースは、データ層における高可用性を提供します。

WebLogic管理サーバーは、管理対象サーバーの1つと同じホスト上で実行され、WebLogic管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Access Managementコンソールをデプロイします。2つ目の管理対象サーバーが動作するホスト・マシン上で、管理サーバーをアクティブ/パッシブ・モードで実行するように構成できます。この構成では、最初の管理サーバーが使用できなくなった場合に、2番目のホスト上の管理サーバーを手動で起動できます。

9.2.1.1 クラスタの起動と停止

Identity Federationクラスタは、OAMクラスタと同じ方法で起動および停止します。詳細は、第9.2.1.1項「クラスタの起動と停止」を参照してください。

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

1つのクラスタ・メンバーによって加えられた構成変更は、その構成が共有データベースに格納されているため、すべてのメンバーに自動的に伝播されます。詳細は、第9.2.1.2項「クラスタワイドの構成変更」を参照してください。

9.2.2 Identity Federationの前提条件

Identity FederationはOAMの一部のため、前提条件はOAMと同じです。詳細は、第9.2.1.2項「クラスタワイドの構成変更」を参照してください。

注意:

Identity Federationを高可用性デプロイメントで使用する場合は、クラスタ・ノードのシステム・クロックを同期する必要があります。

9.3 Identity Federationの高可用性の構成

OAMサーバー上で動作する機能として、Identity Federationの高可用性をOAMの高可用性の一部として構成します。OAMの高可用性を構成するには、第6.3項「Access Managerの高可用性の構成手順」を参照してください。Identity Federationの高可用性の構成時には、次の特別な考慮事項に注意してください。

- 第9.3.1項「ホスト名およびポートの設定」

- 第9.3.2項「プロバイダID値の変更」

- 第9.3.3項「Identity Federationのパラメータのチューニング」

9.3.1 ホスト名およびポートの設定

OAMとIdentity Federation構成のホスト名とポートには、ロード・バランサのホストとポートを設定することをお薦めします。このように設定しない場合、シングル・サインオンおよびログアウト操作でエラーが発生します。また、別のホスト上にリストアされた後に、対応するエージェントの構成を更新する必要がないように、OAM構成で仮想化されたホスト名を使用することをお薦めします。

9.3.2 プロバイダID値の変更

ProviderIdは、SPを一意に識別する文字列です。クラスタ内のすべてのサーバーのProviderIdは同一である必要があります。インストール時のProviderIdのデフォルトは、http://host:port/oam/fed/です。必要に応じて、インストール後にこの値を変更または設定しますが、運用時には変更しないでください。

9.3.3 Identity Federationのパラメータのチューニング

セッション・データが格納されているRACデータベースへの接続を調整できます。

アーティファクト・プロファイルを使用する場合は、WLSTを使用してSOAP接続の詳細を調整します。

設定可能なIdentity Federationパラメータは次のとおりです。

- 「発信SOAP接続」

- 「RDBMS一時ストアの非同期設定」

- 「RDBMSアーティファクトのメモリー・キャッシュ設定」

- 「RDBMSのメモリー・キャッシュ設定」

- 「RDBMSクリーン・アップ・スレッドの間隔」

発信SOAP接続

チューニング可能な発信SOAP接続のパラメータは次のとおりです。

- 最大合計接続数

- ホスト当たりの最大接続数

RDBMS一時ストアの非同期設定

表9-0は、RDBMS一時ストアの非同期設定を示します。

表9-1 RDBMS一時ストアの非同期設定

設定

説明

rdbmsasynchronousmanagerinterval

非同期のスレッド・マネージャに対する実行間隔

rdbmsasynchronousmanagersleep

非同期のスレッド・マネージャのスリープ間隔で、実行が発生したかどうかを確認します。

rdbmsasynchronousqueuesize

同じタイプのRDBMS操作(セッションの作成、アーティファクトの作成)が含まれるキューのサイズ

rdbmsasynchronousqueuesleep

キューがいっぱいの場合に、コール元スレッドがキューに操作の追加をリトライできるまでのスリープ時間

rdbmsasynchronousqueueretries

キューがいっぱいの場合に、キューに操作の追加を試みる際のリトライ数

rdbmsasynchronousthreadcore

RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでのデフォルトのスレッド数

rdbmsasynchronousthreadkeepalive

RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでの外部スレッドの最大保持時間

rdbmsasynchronousthreadmax

RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでの最大スレッド数

rdbmsasynchronousthreadpolicy

RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールのスレッド・ポリシー

rdbmsasynchronousthreadqueuesize

RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールのスレッドのキュー・サイズ

RDBMSアーティファクトのメモリー・キャッシュ設定

表9-0は、RDBMS非同期モジュールとともに使用されるRDBMSアーティファクトのメモリー・キャッシュ設定を示します。

表9-2 RDBMSアーティファクトのメモリー・キャッシュ設定

設定

説明

artifactrdbmscachetimeout

メモリー・キャッシュでの存続時間

artifactrdbmsretries

失敗を返すまでのRDBMSでのエントリ検出の最大リトライ数

artifactrdbmssleep

操作の参照をリトライする間のスリープ時間

RDBMSのメモリー・キャッシュ設定

表9-3は、RDBMSのメモリー・キャッシュ設定(アーティファクト設定を除く)を示します(表9-2を参照)。

表9-3 RDBMSのメモリー・キャッシュ設定

設定

説明

transientrdbmscachesize

キャッシュ・サイズ

transientrdbmscachetimeout

無効になるか、オブジェクトの検索時にRDBMSの参照操作が強制されるまでのキャッシュ・オブジェクトの存続時間

RDBMSクリーン・アップ・スレッドの間隔

RDBMSクリーンアップのスレッド間隔の設定はrdbmscleanupintervalで、これは、Identity Federationデータベース表から期限切れのエントリを削除するスレッドのスリープ間隔を示します。

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

この項では、高可用性環境にデプロイされたIdentity Federationインスタンスのフェイルオーバー操作の実行手順と、予想される動作について説明します。

Identity Federationインスタンスのフェイルオーバーのテストを実行し、Identity Federationのステータスを確認するには、次の手順に従います。

1. 管理サーバーのコンソールにログインします。「ホーム」→「セキュリティ・レルムのサマリー」→「myrealm」→「ユーザーとグループ」→「レルム・ロール」→「グローバル・ロールの編集」の順に移動します。グループOAMAdminstratorsを追加します。

2. OAM管理コンソールにログインします。「システム構成」→「共通設定」→「使用可能なサービス」の順に移動して、Identity Federationを有効化します。

3. IDPインスタンス(Oracle Identity Federation 11gリリース1インスタンス)とSPとして機能するこのIdentity Federation 11gリリース2インスタンス間に、Identity Federationを設定します。

4. OAM 11gR2と統合し、OIFSchemeでリソースを保護します。『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のAccess Manager 11gR2との統合に関する項の手順に従います。

5. 2つの管理対象サーバーのうちの1つを停止し、保護されたリソースへのアクセスを試みます。

6. IDPログイン・ページが表示されたら、前述の手順で停止した管理対象サーバーを再起動して、動作中の管理対象サーバーを停止し、操作の完了を試みます。

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

Identity Federationに関する問題をトラブルシューティングするには、次のヒントを使用します。

- Identity Federationのメッセージは、次のような管理対象サーバーのログ・ファイルに記録されます。

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

- Identity Federationサーバー構成のホスト名とポートには、ロード・バランサのホストとポートが設定されていることを確認します(このように設定しない場合、シングル・サインオン操作でエラーが発生します)。

- IDPとSPを実行する各コンピュータのシステム・クロックの時間が異なると、シングル・サインオンの際にエラーが発生します。これを修正するには、同じ時間になるようにシステム・クロックの時間を設定するか、Oracle Enterprise Manager Fusion Middleware Controlの「サーバー・プロパティ」ページを使用してサーバー・ドリフトを調整します。

- ProviderIdはIDP/SPを一意に識別する文字列であり、クラスタ内のすべてのサーバーで同一である必要があります。インストール時のProviderId文字列のデフォルトは、http://host:port/oam/fedです。ProviderIdを変更する必要がある場合は、運用時ではなく、インストール後に変更してください。

10 Oracle Entitlements Serverの高可用性の構成

この章では、Oracle Entitlements Serverの概要、およびOracle Entitlements Serverコンポーネントの高可用性環境の設定方法について説明します。

Oracle Entitlements Serverはきめ細やかな認可製品で、これにより組織はリソースへのアクセスと使用を制御するポリシーを定義して管理することで、そのリソースを保護することができます。ポリシーでは、誰が、どのリソースに、いつ、どのように行うことができるかを指定することによって、アクセス権限を定義します。ポリシーでは、ソフトウェア・コンポーネントやビジネス・オブジェクトを含む、すべてのタイプのリソースを制御できます。

- Oracle Entitlements Serverコンポーネント・アーキテクチャの図および説明は、『Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド』のOracle Entitlements Serverアーキテクチャの概要に関する説明を参照してください。

- Oracle Entitlements Server機能の詳細は、『Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド』のOracle Entitlements Server 11gR2の機能に関する説明を参照してください。

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

- 第10.1項「Oracle Entitlements Serverの高可用性の概要」

- 第10.2項「Oracle Entitlements Serverの高可用性の構成」

10.1 Oracle Entitlements Serverの高可用性の概要

この項では、Oracle Entitlements Serverを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。

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

- 第10.1.1項「Oracle Entitlements Serverの高可用性アーキテクチャ」

- 第10.1.2項「Oracle Entitlements Serverのセキュリティ・モジュールの高可用性」

- 第10.1.3項「ロード・バランシング」

- 第10.1.4項「フェイルオーバーに関する考慮事項」

- 第10.1.5「障害からの保護および予想される動作」

- 第10.1.6項「Oracle Entitlements Serverクラスタの起動と停止」

- 第10.1.7「クラスタワイドの構成変更」

- 第10.1.8「LDAPとの同期に関する考慮事項」

10.1.1 Oracle Entitlements Serverの高可用性アーキテクチャ

この項では、Oracle Entitlements Serverコンポーネントの次のような高可用性アーキテクチャのシナリオについて説明します。

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

- 第10.1.1.1項「Oracle Entitlements Serverの管理サーバーの高可用性」

- 第10.1.1.2項「セキュリティ・モジュール(OESクライアント)/ポリシー情報ポイントの高可用性」

- 第10.1.1.3項「Webサービスに対するプロキシ・モードでのセキュリティ・モジュール/制御プッシュ・モードの高可用性でのRMIセキュリティ・モジュール」

- 第10.1.1.4項「Webサービスに対するプロキシ・モードでのセキュリティ・モジュール/制御プル・モードの高可用性でのRMIセキュリティ・モジュール」

- 第10.1.1.5項「Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの高可用性」

10.1.1.1 Oracle Entitlements Serverの管理サーバーの高可用性

図10-1は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたOracle Entitlements Serverの管理サーバーを示しています。

図10-1 Oracle Entitlements Serverの管理サーバーの高可用性アーキテクチャ

OESHOST1には、次のインストールがあります。

- Oracle Entitlements ServerインスタンスはWLS_OES1管理対象サーバーにインストールされており、APMインスタンスはWLS_OES1管理対象サーバーにインストールされています。

- Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソースまたはGridLinkデータ・ソース内に構成されています。

- WebLogic Serverの管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。

OESHOST2には、次のインストールがあります。

- Oracle Entitlements ServerインスタンスはWLS_OES2管理対象サーバーにインストールされており、APMインスタンスはWLS_OES2管理対象サーバーにインストールされています。

- Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

- OESHOST1およびOESHOST2上のWLS_OES1およびWLS_OES2管理対象サーバーのインスタンスは、OES_CLUSTERクラスタとして構成されています。

- WebLogic Serverの管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OESHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。

2つのOracle Entitlements Serverの管理サーバーが登録サーバーとバックアップ登録サーバーとして機能するように、Oracle Entitlements Serverのセキュリティ・モジュールを制御プッシュ・モードで構成できます。登録サーバーが停止した場合、Oracle Entitlements Serverのセキュリティ・モジュールをバックアップ・サーバーに切り替えることができ、Oracle Entitlements Serverの管理サーバーから分散ポリシーを取得できます。フェイルオーバー・シナリオおよび動作の詳細は、第10.1.4項「フェイルオーバーに関する考慮事項」を参照してください。

10.1.1.2 セキュリティ・モジュール(OESクライアント)/ポリシー情報ポイントの高可用性

セキュリティ・モジュールが埋め込まれ、異なるポリシー情報ポイント(PIP)間でフェイルオーバーするよう構成できるように、セキュリティ・モジュールをデプロイできます。PIPはデータ・リポジトリであり、認可の決定用にポリシーを評価するときに使用するために取得できる情報のソースです。PIPの詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのポリシー情報ポイントに関する説明を参照してください。

デプロイメント・オプションについては次の項目を参照してください。

- 「複数のLDAP/JDBC URLを使用するOracle Entitlements Server PIP」

- 「RACおよびロード・バランサを使用するOracle Entitlements Server PIP」

複数のLDAP/JDBC URLを使用するOracle Entitlements Server PIP

図10-2は、高可用性デプロイメントでの埋込みセキュリティ・モジュール・インスタンスを示しています。LDAPおよびDBベースのPIPの両方を使用して、外部リソース間でフェイルオーバーするために、外部リソースの複数のエンドポイントを構成できます。DBベースのPIPでは、マルチソースのデータ・ソースも構成できます。

図10-2 セキュリティ・モジュール/ポリシー情報ポイントの高可用性

図10-2では、セキュリティ・モジュール(PDP)は、LDAP 1またはDatabase 1をプライマリPIPとして使用しています。フェイルオーバー時には、セキュリティ・モジュールはLDAP2およびDatabase 2にフェイルオーバーされます。

RACおよびロード・バランサを使用するOracle Entitlements Server PIP

Oracle Entitlements Serverの高可用性デプロイメントのもう1つのオプションでは、セキュリティ・モジュール(PDP)はロード・バランサとともにRACデータベースまたはLDAPサーバーを使用します。フェイルオーバー時には、図10-3に示すとおり、セキュリティ・モジュールはRACにフェイルオーバーされます。

図10-3 RACおよびロード・バランサを使用するOracle Entitlements Server PIP

10.1.1.3 Webサービスに対するプロキシ・モードでのセキュリティ・モジュール/制御プッシュ・モードの高可用性でのRMIセキュリティ・モジュール

Oracle Entitlements Serverでは、クライアントが認可サービスをリモートで起動できるプロキシ・モードがサポートされます。Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのセキュリティ・モジュールのプロキシ・モードの使用を参照してください。セキュリティ・モジュールのプロキシ・モードでのデプロイには、次の3つのデプロイメント・オプションがあります。

- 「WebLogic Serverデプロイメント上のWebサービスのセキュリティ・モジュール」

- 「スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメント」

- 「RMIのセキュリティ・モジュールのデプロイメント」

WebLogic Serverデプロイメント上のWebサービスのセキュリティ・モジュール

図10-4は、WebLogic Server上のWebサービスのセキュリティ・モジュールを示します。

図10-4 WebLogic Serverデプロイメント上のWebサービスのセキュリティ・モジュール

スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメント

図10-5は、スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメントを示します。

図10-5 スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメント

RMIのセキュリティ・モジュールのデプロイメント

図10-6は、RMIのセキュリティ・モジュールのデプロイメントを示します。

図10-6 RMIのセキュリティ・モジュールのデプロイメント

10.1.1.4 Webサービスに対するプロキシ・モードでのセキュリティ・モジュール/制御プル・モードの高可用性でのRMIセキュリティ・モジュール

Webサービスに対するプロキシ・モードでのセキュリティ・モジュールおよび制御プル・モードでのRMIセキュリティ・モジュールをデプロイするためのオプションは、次のとおりです。

- 「WebLogic Server上のWebサービスのセキュリティ・モジュール」

- 「スタンドアロンのWebサービスのセキュリティ・モジュール」

- 「RMIのセキュリティ・モジュール」

WebLogic Server上のWebサービスのセキュリティ・モジュール

図10-7は、WebLogic Server上のWebサービスのセキュリティ・モジュールを示します。

図10-7 WebLogic Server上のWebサービスのセキュリティ・モジュール

スタンドアロンのWebサービスのセキュリティ・モジュール

図10-8は、スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメントを示します。

図10-8 スタンドアロンのWebサービスのセキュリティ・モジュール

RMIのセキュリティ・モジュール

図10-9は、RMIのセキュリティ・モジュールのデプロイメントを示します。

図10-9 RMIのセキュリティ・モジュール

Webサービスのセキュリティ・モジュールのプロキシ・クライアントおよびRMIのセキュリティ・モジュールのプロキシ・クライアントの構成の詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのPDPプロキシに関する説明を参照してください。

10.1.1.5 Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの高可用性

OES WebLogic Serverの高可用性には、次の2つのデプロイメント・オプションがあります。

- 「Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュール、制御プッシュ・モード」

- 「Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの高可用性、制御プル・モードまたは非制御モード」

Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュール、制御プッシュ・モード

次の図は、制御プッシュ・モードのOracle Entitlements Server WebLogic Serverのセキュリティ・モジュールを示します。

図10-10 Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュール、制御プッシュ・モード

Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの高可用性、制御プル・モードまたは非制御モード

次の図は、制御プル・モードまたは非制御モードのWebLogic Serverのセキュリティ・モジュールを使用したOracle Entitlements Server を示します。

図10-11 Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの制御プル・モード/非制御モード

10.1.2 Oracle Entitlements Serverのセキュリティ・モジュールの高可用性

セキュリティ・モジュールが制御プルまたは非制御分散のOPSSセキュリティ・ストアからポリシーを読み取る場合、アプリケーションによるデータベースへのアクセスでは、Oracleが推奨する高可用性方法を使用してください。

10.1.3 ロード・バランシング

すべての高可用性のシナリオで、ロード・バランサをデプロイできます。

- ユーザー対APM通信に対するAuthorization Policy Manager (APM)の前面。ポリシー・ストアに永続化されないデータの損失を防ぐためにスティッキーな接続をお薦めします。

- クライアント対セキュリティ・モジュール通信に対するWebサービスのセキュリティ・モジュールの前面。キャッシュを最大限に使用するためにスティッキーな接続をお薦めします。

注意:

Oracle Entitlements Serverには、ロード・バランサに対するタイムアウト要件はありません。

10.1.4 フェイルオーバーに関する考慮事項

この項では、Oracle Entitlements Serverのフェイルオーバーに関する考慮事項について説明します。

表10-1 Oracle Entitlements Serverのフェイルオーバーのシナリオと動作

フェイルオーバーのシナリオ

フェイルオーバーの動作

OESポリシー・ストアの障害

マルチソースのデータ・ソースが使用されている場合、制御プルおよび非制御モードのAPMおよびセキュリティ・モジュールは、作業インスタンスに切り替わります。ポリシー・ストアのインスタンスが失われた場合も、トランザクションは処理されます。

- APMはユーザーにエラーを返し、そのユーザーはリクエストを繰り返すことができます。

- セキュリティ・モジュールは、トランザクションをリトライします。セキュリティ・モジュールは、読取り操作のみを使用します。セキュリティ・モジュールが制御プル・モードの場合、ローカルに維持されているポリシー・ストアのコピーを使用します。

OES管理サーバーの障害

- ユーザー対APM通信。ロード・バランサが存在する場合、ユーザーは別のAPMインスタンスにリダイレクトされます。ユーザー・セッションの保存されていないデータはすべて失われますが、ユーザーには、維持されているポリシー・データへの完全なアクセス権があります。

- セキュリティ・モジュール対APM通信。制御プッシュ配布では、セキュリティ・モジュールは起動時にOES Adminに登録され、プライマリ・インスタンスが停止している場合はバックアップ・インスタンスに対してリクエストをリトライします。リトライは、作業インスタンスが検出されるまで継続されます。OES Adminへの接続を試みる間、セキュリティ・モジュールは、ローカルに維持されているポリシー・ストアのコピーを使用します。

Webサービスのセキュリティ・モジュールまたはRMIのセキュリティ・モジュールの障害

セキュリティ・モジュールのプロキシは、構成されているリトライ数に達するまでリクエストをリトライします。

DBまたはLDAP属性ソースの障害

セキュリティ・モジュール(OESクライアント)は、構成されているリトライ数に達するまでデータの読取りを継続します。

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

この項では、Oracle Entitlements Serverのアクティブ/アクティブ・クラスタにおける様々な障害からの保護について説明します。

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

- 第10.1.5.2項「ノード障害」

- 第10.1.5.3項「データベース障害」

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

Oracle Entitlements Serverのフェイルオーバーは透過的ではありません。WebLogic Serverインスタンスのフェイルオーバー時は、Oracle Entitlements Serverを使用して接続を再確立する必要があります。

10.1.5.2 ノード障害

ノード障害は、WebLogic Serverのクラッシュと同じ方法で処理されます。

10.1.5.3 データベース障害

Oracle Entitlements Serverは、システムの初期設定時に構成したマルチ・データ・ソースの使用によって、データベースの障害から保護されます。マルチ・データ・ソースによって、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。

10.1.6 Oracle Entitlements Serverクラスタの起動と停止

高可用性アーキテクチャでは、Oracle Entitlements ServerをOracle WebLogicクラスタにデプロイしますが、このクラスタには、その一部として少なくとも2つのサーバーが存在します。

デフォルトでは、WebLogic Serverによって、このアプリケーションに対する様々なライフサイクル・イベントの起動、停止、監視および管理が行われます。Oracle Identity Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

Oracle Entitlements Serverのライフサイクル・イベントは、次に示すコマンド行ツールおよびコンソールを1つ以上使用して管理できます。

- WebLogic Server管理コンソール

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle WebLogic Scripting Tool (WLST)

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

高可用性環境では、すべてのOracle Entitlements Serverインスタンスが同じ構成リポジトリを共有するため、Oracle Entitlements Serverの1つのインスタンスの構成を変更するとその他すべてのインスタンスの構成も変更されます。ほぼすべてのOracle Entitlements Serverデプロイメントで、クラスタ構成が使用されます。唯一の例外はOracle Entitlements Serverの管理サーバーで、通常、これはクラスタ化されません。

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

LDAPとOracle Entitlements Serverデータベース間の同期は、調整と呼ばれるプロセスによって処理されますが、このプロセスは、主にバックグラウンドで実行されるスケジュール済プロセスです。このプロセスは手動で実行することもできます。

同期プロセス中にLDAPが停止した場合、Oracle Entitlements Serverによって取得されていないデータは、調整タスクの次回の実行時に取得されます。

10.2 Oracle Entitlements Serverの高可用性の構成

この項では、Oracle Entitlements Serverで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。

Oracle Entitlements Server管理サーバーの高可用性デプロイメントは、一般的なOracleアプリケーションと同じです。

Oracle Entitlements Serverの管理サーバー・ユーザー・インタフェースにアクセスするユーザーに対して高可用性を設定するには、WebLogicクラスタを使用します。

管理サーバー・ユーザー・インタフェースに対して高可用性データベースを設定するには、マルチ・ソース・データベース、Oracle RACおよびその他の一般的な要素を使用します。

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

- 第10.2.1項「Oracle Entitlements Serverの構成の前提条件」

- 第10.2.2項「OESHOST1でのOES管理サーバー用WebLogicドメインの構成」

- 第10.2.3項「構成後および検証」

- 第10.2.4項「制御プッシュ・モードのOESのセキュリティ・モジュールをOracle Entitlements Server管理サーバーを使用して高可用性に構成」

- 第10.2.5項「プロキシ・モードのOracle Entitlements Serverのセキュリティ・モジュールをPDPを使用して高可用性に構成」

- 第10.2.6項「高可用性でのOracle Entitlements Serverのポリシー情報ポイントの構成」

- 第10.2.7項「WebLogicでのOracle Entitlements Server Webサービスのセキュリティ・モジュールの高可用性の構成」

- 第10.2.8項「Oracle Entitlements Server WebLogicセキュリティ・モジュールの高可用性の構成」

- 第10.2.9項「制御プル・モードおよび非制御モードのセキュリティ・モジュールでのRACデータ・ソースの使用」

- 第10.2.10項「Web Tierと連携するためのOracle Entitlements Serverの構成」

10.2.1 Oracle Entitlements Serverの構成の前提条件

Oracle Entitlements Serverの高可用性を構成する前に、次の手順を完了します。

1. リポジトリ作成ユーティリティを使用して、Oracle Entitlements ServerスキーマをOracle RACデータベースに作成します。スキーマの作成の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Entitlements Serverのインストールと構成ロードマップに関する説明を参照してください。

2. OESHOST1およびOESHOST2にWebLogic Serverをインストールします。詳細は、第5.3.1.1.1項「Oracle WebLogic Serverのインストール」を参照してください。

3. OESHOST1およびOESHOST2にOracle Entitlements Serverの管理ソフトウェアをインストールします。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Entitlements Server管理サーバーのインストールに関する説明を参照してください。

4. Oracle Entitlements Serverクライアントをインストールします。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Entitlementsクライアントのインストールに関する説明を参照してください。

10.2.2 OESHOST1でのOES管理サーバー用WebLogicドメインの構成

OESHOST1でOES管理サーバー用WebLogicドメインを構成するには、次の手順を実行します。

1. <MW_HOME>/oracle_common/common/bin/config.shスクリプトを実行します。

2. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。「拡張ソースの選択」画面が表示されます。

3. 「拡張ソースの選択」画面で、「管理対象サーバーのOracle Entitlements Server - 11.1.1.0[Oracle_IDM1」を選択します。構成ウィザードによって、「Oracle JRF」、「Oracle Platform Security Service」および「Basic WebLogic Server Domain」が自動的に選択されます。
「次へ」をクリックします。

4. 「ドメイン名と場所の指定」画面で、作成しているドメインのドメイン名と場所を入力します。「次へ」をクリックします。「管理者ユーザー名およびパスワードの構成」画面が表示されます。

5. 管理者のユーザー名とパスワードを構成します。デフォルトのユーザー名はweblogicです。「次へ」をクリックします。

6. 「サーバーの起動モードおよびJDKの構成」画面で、WebLogicドメインの起動モードとJDKを選択します。

7. 「JDBCコンポーネント・スキーマの構成」画面で、すべてのスキーマのJDBCプロパティを構成し、「次へ」をクリックします。

8. 「JDBCコンポーネント・スキーマのテスト」画面で、「すべて選択」をクリックして「接続のテスト」をクリックします。「次」をクリックします。
データ・ソースの検証が成功したら、「次へ」をクリックします。

データ・ソースの検証に失敗した場合は、「前へ」をクリックして問題を修正し、もう一度実行します。

9. 「オプションの構成を選択」画面で、「管理対象サーバー、クラスタ、およびマシン」を選択します。「次へ」をクリックします。

10. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: All Local Addresses

- リスニング・ポート: 7001

- SSLリスニング・ポート: 7002

- 「SSL有効」を選択

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

11. 「管理対象サーバーの構成」画面では、この画面を初めて表示したときに、oes_server1という管理対象サーバーが自動的に作成されます。oes_server1の名前を変更し、このエントリに対する属性を更新できます。
例:

- 名前: oes_server1

- リスニング・アドレス: OESHOST1.example.com

- リスニング・ポート: 14600

- SSLポート: 14601

2つ目のOES_SERVERでは、「追加」をクリックして、次の値を入力します。

- 名前: oes_server2

- リスニング・アドレス: OESHOST2.example.com

- リスニング・ポート: 14600

- SSLポート: 14601

- 「SSL有効」を選択

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

12. 「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
名前oes_clusterを入力します。「クラスタのメッセージング・モード」に「ユニキャスト」を選択し、「クラスタ・アドレス」をoes_server1:portのリスニング・アドレスまたはDNS名,oes_server2:portmanaged server1:portのリスニング・アドレスまたはDNS名,managed server2: portの形式で入力します。

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

13. 「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。
右のウィンドウで、クラスタ名「oes_cluster」をクリックします。

管理対象サーバー「oes_server1」をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。

管理サーバーoes_server2について、前述の手順を繰り返します。

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

14. 「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
「Unix」タブをクリックします。

管理サーバー・ホストの場合:

- 名前: ホストの名前。ここではDNS名を使用します。

- ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。

- ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。

その他すべての値はデフォルト設定のままにします。

OESHOST1およびOESHOST2について前述の手順を繰り返し、次の値を入力します。その他すべての値はデフォルト設定のままにします。

- 名前: ホスト名です。DNS名を使用することをお薦めします。

- ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。

- ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。

Unixオペレーティング・システムでは、「マシン」タブの下にあるデフォルト・ローカル・マシンのエントリを削除します。

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

15. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
右側のウィンドウでマシンをクリックします。

左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。

矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。

すべての管理対象サーバーを適切なマシンに割り当てるまで、この手順を繰り返します。

次のように、サーバーをマシンに割り当てます。

- ADMINHOST: 管理サーバー

- OESHOST1: oes_server1

- OESHOST2: oes_server2

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

16. 「構成のサマリー」画面で、「作成」をクリックします。

17. OPSSセキュリティ・ストア構成の最初のRACデータベース・インスタンスが動作していることを確認します。

18. OPSSセキュリティ・ストアを構成します。『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOES管理サーバーのセキュリティ・ストアの構成に関する説明を参照してください。

10.2.3 構成後および検証

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

- 第10.2.3.1項「ノード・マネージャの起動」

- 第10.2.3.2項「WebLogic管理サーバーの検証」

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

- 第10.2.3.4項「リモート・ホストでのノード・マネージャの起動」

- 第10.2.3.5項「WebLogic管理サーバーの停止と起動およびoes_server1とoes_server2の起動」

10.2.3.1 ノード・マネージャの起動

管理ホスト(OESHOST1など)でノード・マネージャを起動するには、次の手順を実行します。

1. MW_HOME/wlserver_10.3/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行します。

2. setNMProps.shスクリプトを実行して、StartScriptEnabledプロパティをtrueに設定します。
cd MW_HOME/oracle_common/common/bin

3. ノード・マネージャ・プロセスを強制終了してノード・マネージャを停止します。

4. ノード・マネージャを起動します。

10.2.3.2 WebLogic管理サーバーの検証

次の手順を実行して、管理サーバーが適切に構成されていることを確認します。

1. 新しいドメインで./startWeblogic.shを使用して、WebLogic管理サーバーを起動します。

2. ブラウザで、次のようなOracle WebLogic Server管理コンソールのURLを入力します。
http://<OESHOST1>:7001/console

3. WebLogic管理者(たとえば、weblogic)としてログインします。

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

packおよびunpackコマンドを使用し、管理サーバーが使用するドメイン・ディレクトリをOESHOST1の管理対象サーバーが使用するドメイン・ディレクトリから分離します。

OESHOST1で独立ドメイン・ディレクトリを作成する手順は次のとおりです。

1. 次のようにpackコマンドを実行し、テンプレート・パックを作成します。
cd MW_HOME/oracle_common/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=domaintemplate.jar -template_name=domain_template

2. 次のようにunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
cd MW_HOME/oracle_common/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=domaintemplate.jar

10.2.3.3.1 リモート・サーバーへの変更内容の伝播

リモート・ホストの管理対象サーバー(OESHOST2など)を起動する前に、リモート・ホストでunpackを実行します。

1. 第10.2.3.3項「管理サーバーと同じノードでの管理対象サーバー用独立ドメイン・ディレクトリの作成」で作成したファイルdomaintemplate.jarをOESHOST2にコピーします。

2. 次のコマンドを使用して、OESHOST2のホストでunpackを実行します。
cd MW_HOME/oracle_common/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=domaintemplate.jar

10.2.3.4 リモート・ホストでのノード・マネージャの起動

リモート・ホストでノード・マネージャを起動するには、次の手順を実行します。

1. OESHOST2でノード・マネージャを起動して、MW_HOME/wlserver_10.3/server/binディレクトリにあるstartNodemanager.shスクリプトを使用してnodemanager.propertiesファイルを作成します。

2. setNMProps.shスクリプトを実行して、StartScriptEnabledプロパティをtrueに設定します。
cd MW_HOME/oracle_common/common/bin

./setNMProps.sh

3. ノード・マネージャを停止および起動します。

10.2.3.5 WebLogic管理サーバーの停止と起動およびoes_server1とoes_server2の起動

1. WebLogic管理サーバーを再起動します。

2. ブラウザで、次のようなOracle WebLogic Server管理コンソールのURLを入力します。
http://<OESHOST1>:7001/console

3. WebLogic管理者(たとえば、weblogic)としてログインします。

4. WebLogic Serverの管理コンソールからoes_server1およびoes_server2管理対象サーバーを起動します。

注意:

また、ドメイン・ディレクトリのサブフォルダbinでstartManagedWebLogic.shスクリプトを使用しても、管理対象サーバーを起動できます。例:

./startManagedWebLogic.sh oes_server1 http://localhost:7001

5. URL (http://<OESHOST1>:14600/apm)でAPMコンソールを開いて、OESHOST1のOES管理サーバー・インスタンスを検証します。
WebLogicユーザー名およびパスワードを使用してログインします。

6. http://<OESHOST2>:14600/apmをWebブラウザで指定してAPMコンソールを開き、OESHOST2のOES管理サーバー・インスタンスを検証します。

10.2.4 制御プッシュ・モードのOESのセキュリティ・モジュールをOracle Entitlements Server管理サーバーを使用して高可用性に構成

制御プッシュ・モードのOracle Entitlements Serverのセキュリティ・モジュールを高可用性で構成するには、OESセキュリティ・モジュールの構成ユーザー・インタフェースを使用して高可用性パラメータを設定します。

1. 適切なセキュリティ・モジュール・インスタンスのディレクトリのbinディレクトリに変更して、コマンド行から次のスクリプトを実行します。
cd $OES_CLIENT_HOME/oes_sm_instances/SM_Name/bin

2. oessmconfig.shを実行して、SMConfig UIを起動します。
詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのSMConfig UIの開始に関する説明を参照してください。

3. jps-config.xmlファイルに次のパラメータを設定します。

- oracle.security.jps.runtime.pd.client.backupRegistrationServerURL

- oracle.security.jps.runtime.pd.client.registrationRetryInterval
次の例は、RegistrationServerURLに障害が発生した場合にバックアップとして使用されるbackupRegistrationServerURLを示します。

<property name="oracle.security.jps.runtime.pd.client.backupRegistrationServerURL" value="https://slc00bqz:14601/pd-server"/>

詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのJavaセキュリティ・モジュールの構成に関する説明を参照してください。

10.2.5 プロキシ・モードのOracle Entitlements Serverのセキュリティ・モジュールをPDPを使用して高可用性に構成

プロキシ・モードのセキュリティ・モジュールをPDPを使用して高可用性に構成するには、次の手順を実行します。

1. プロキシ・モードのセキュリティ・モジュールを構成するには、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのセキュリティ・モジュールのプロキシ・モードの使用を参照してください。

2. PDPアドレス(例: oracle.security.jps.pdp.proxy.PDPAddress)に、カンマ区切りの値を追加することで変更します。
例:

oracle.security.jps.pdp.proxy.PDPAddress=http://ws1:9410,http://ws2:9410

詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのPDPプロキシ・クライアントの構成に関する説明を参照してください。

10.2.6 Oracle Entitlements Serverのポリシー情報ポイントの高可用性の構成

ポリシー情報ポイントの高可用性を構成するには、次の手順を実行します。

1. 適切なセキュリティ・モジュール・インスタンスのディレクトリのbinディレクトリに変更して、コマンド行から次のスクリプトを実行します。
cd $OES_CLIENT_HOME/oes_sm_instances/SM_Name/bin

2. oessmconfig.shを実行して、SMConfig UIを起動します。
詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのSMConfig UIの開始に関する説明を参照してください。

3. ポリシー情報ポイントの高可用性用に次の属性リトリーバ・パラメータを設定します。詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドの属性リトリーバの構成に関する説明を参照してください。

注意:

ldap.urlまたはjdbc.url属性リトリーバ・パラメータには、複数の値を設定できます。値はカンマで区切り、最初の値は1次値として処理されます。詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのLDAPリポジトリの属性リトリーバ・パラメータの構成に関する説明を参照してください。

10.2.7 WebLogicでのOracle Entitlements Server Webサービスのセキュリティ・モジュールの高可用性の構成

WebLogicのOracle Entitlements Server Webサービスのセキュリティ・モジュールを、WebLogicクラスタを使用して高可用性に構成できます。

WebLogicのOracle Entitlements Server Webサービスのセキュリティ・モジュールを構成するには、次の手順を実行します。

OESHOST1で、次の手順を実行します。

1. OESCLIENT_HOME/oessm/bin/config.shを実行して、Webサービスのセキュリティ・モジュールとWebLogic Serverドメインを作成します。
例:

./config.sh -smType ws -onWLS -smConfigId <ws_name> -serverLocation <wls_home> -pdServer <oes_admin_server> -pdPort <oes_admin_ssl_port>

2. 「ようこそ」画面で「WebLogicドメインの作成」を選択し、「次へ」をクリックします。

3. 「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。リストから「WebLogic上の管理対象サーバー用のOracle Entitlements Server Webサービスのセキュリティ・モジュール」を選択します。
「次へ」をクリックします。

4. 「ドメイン名と場所の指定」画面で、ドメインおよびそのすべてのアプリケーションの名前と場所を入力します。

- ドメイン名: <domain name>

- ドメインの場所: デフォルトのエントリを受け入れます。

5. 「管理サーバーのユーザー名とパスワードの構成」画面で、次のように入力します。

- 名前: weblogic

- ユーザー・パスワード: WebLogicユーザーのパスワード

- ユーザー・パスワードの確認: WebLogicユーザーのパスワード

- 説明: WebLogicユーザーの説明

6. 「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JDK」を選択します。

7. 「オプションの構成を選択」画面で、「AdminServer」および「管理対象サーバー」を選択します。「次へ」をクリックします。

8. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: All Local Addresses

- リスニング・ポート: 7001

- SSLリスニング・ポート: 7002

「SSL有効」を選択して「次へ」をクリックします。

9. 「管理対象サーバーの構成」画面で、デフォルトの管理対象サーバーwsonwls_server1が作成されます。wsonwls_server1の詳細を変更し、2つ目の管理対象サーバーを追加します。
wsonwls_server1では、次の値を入力します。

- 名前: wsonwls_server1

- リスニング・アドレス: WSSMHOST1

- リスニング・ポート: 14610

- SSLリスニング・ポート: 14611

2つ目の管理対象サーバーでは、「追加」をクリックして、次の値を入力します。

- 名前: wsonwls_server2

- リスニング・アドレス: WSSMHOST2

- リスニング・ポート: 14610

- SSLリスニング・ポート: 14611

10. 「クラスタの構成」画面で、「追加」をクリックしてwssm_clusterを入力します。「クラスタのメッセージング・モード」に「unicast」を選択し、クラスタ・アドレスをmanaged_ server1:port,managed_server2: portのように入力します。
「次へ」をクリックします。

11. 「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。

- 右のウィンドウで、クラスタ「wssm_cluster」をクリックします。

- 管理対象サーバー「wsonwls_server1」をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
管理サーバーwsonwls_server2について、前述の手順を繰り返します。

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

12. 「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
オペレーティング・システムがUnixの場合は、「Unix」タブをクリックします。

管理サーバー・ホストの場合:

- 名前: ホストの名前。ここでは、DNS名を使用することをお薦めします。

- ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。

- ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。

その他すべての値はデフォルト設定のままにします。

WSSMHOST1およびWSSMOESHOST2について前述の手順を繰り返し、次の値を入力します。その他すべての値はデフォルト設定のままにします。

- 名前: ホスト名です。DNS名を使用することをお薦めします。

- ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。

- ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。

Unixオペレーティング・システムでは、「マシン」タブの下にあるデフォルト・ローカル・マシンのエントリを削除します。

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

13. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを次の手順で割り当てます。
右側のウィンドウでマシンをクリックします。

左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。

矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。

すべての管理対象サーバーを適切なマシンに割り当てるまで、この手順を繰り返します。

次のように、サーバーをマシンに割り当てます。

- ADMINHOST: 管理サーバー

- WSSMHOST1: wsonwls_server1

- WSSMHOST2: wsonwls_server2

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

14. 「構成のサマリー」画面で、「作成」をクリックします。

15. 新しいドメインで./startWeblogic.shを使用して、WebLogic管理サーバーを起動します。

16. 管理対象サーバーを起動します。作成したドメイン・ディレクトリのサブフォルダbinに切り替え、./startManagedWebLogic.sh 管理対象サーバー名 http://wlsadminserver host:wls_adminserver_portを入力します。
例:

./startManagedWeblogic.sh wsonwls_server1 http://localhost:7001

OESHOST2で、次の手順を実行します。

packおよびunpackコマンドを使用し、OES WebサービスSMが使用するドメイン・ディレクトリをOESHOST1の管理対象サーバーが使用するドメイン・ディレクトリから分離します。

ドメイン・ディレクトリの分離手順は、第10.1.1.5項「Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの高可用性」を参照してください。

10.2.8 Oracle Entitlements Server WebLogicセキュリティ・モジュールの高可用性の構成

Oracle Entitlements Server WebLogicセキュリティ・モジュールを、WebLogicクラスタを使用して高可用性に構成できます。

Oracle Entitlements Server WebLogicセキュリティ・モジュールを構成するには、次の手順を実行します。

OESHOST1で、次の手順を実行します。

1. OESCLIENT_HOME/oessm/bin/config.shを実行して、WebLogicセキュリティ・モジュールとWebLogic Serverドメインを作成します。
例:

./config.sh -smType wls -smConfigId <wls_name> -serverLocation <wls_home> -pdServer <oes_admin_server> -pdPort <oes_admin_ssl_port>

2. 「ようこそ」画面で「WebLogicドメインの作成」を選択し、「次へ」をクリックします。

3. 「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。リストから「WebLogic上の管理対象サーバー用のOracle Entitlements Server WebLogicのセキュリティ・モジュール」を選択します。
「次へ」をクリックします。

4. 「ドメイン名と場所の指定」画面で、ドメインおよびそのすべてのアプリケーションの名前と場所を入力します。

- ドメイン名: <domain name>

- ドメインの場所: デフォルトのエントリを受け入れます。

5. 「管理サーバーのユーザー名とパスワードの構成」画面で、次のように入力します。

- 名前: weblogic

- ユーザー・パスワード: WebLogicユーザーのパスワード

- ユーザー・パスワードの確認: WebLogicユーザーのパスワード

- 説明: WebLogicユーザーの説明

6. 「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JDK」を選択します。

7. 「オプションの構成を選択」画面で、「AdminServer」および「管理対象サーバー」を選択します。「次へ」をクリックします。

8. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: All Local Addresses

- リスニング・ポート: 7001

- SSLリスニング・ポート: 7002

「SSL有効」を選択して「次へ」をクリックします。

9. 「管理対象サーバーの構成」画面で、デフォルトの管理対象サーバーwlssm_server1が作成されます。デフォルトの管理対象サーバーの詳細を変更し、2つ目の管理対象サーバーを追加します。
デフォルトの管理対象サーバーでは、次の値を入力します。

- 名前: wlssm_server1

- リスニング・アドレス: WLSSMHOST1

- リスニング・ポート: 14610

- SSLリスニング・ポート: 14611

2つ目の管理対象サーバーでは、「追加」をクリックして、次の値を入力します。

- 名前: wlssm_server2

- リスニング・アドレス: WLSSMHOST2

- リスニング・ポート: 14610

- SSLリスニング・ポート: 14611

10. 「クラスタの構成」画面で、「追加」をクリックしてwlssm_clusterを入力します。「クラスタのメッセージング・モード」に「unicast」を選択し、クラスタ・アドレスをmanaged_ server1:port,managed_server2: portのように入力します。
「次へ」をクリックします。

11. 「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。

- 右のウィンドウで、クラスタ「wlssm_cluster」をクリックします。

- 管理対象サーバー「wlssm_server1」をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
管理サーバーwlssm_server2について、前述の手順を繰り返します。

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

12. 「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
オペレーティング・システムにUnixを使用しているホストの場合は、「Unix」タブをクリックします。

管理サーバー・ホストの場合:

- 名前: ホストの名前。ここでは、DNS名を使用することをお薦めします。

- ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。

- ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。

その他すべての値はデフォルト設定のままにします。

WLSSHOST1およびWLSSMOESHOST2について前述の手順を繰り返し、次の値を入力します。その他すべての値はデフォルト設定のままにします。

- 名前: ホスト名です。DNS名を使用することをお薦めします。

- ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。

- ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。

Unixオペレーティング・システムでは、「マシン」タブの下にあるデフォルト・ローカル・マシンのエントリを削除します。

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

13. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
右側のウィンドウでマシンをクリックします。

左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。

矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。

すべての管理対象サーバーを適切なマシンに割り当てるまで、この手順を繰り返します。

次のように、サーバーをマシンに割り当てます。

- ADMINHOST: 管理サーバー

- WLSSMHOST1: wlssm_server1

- W:SSMHOST2: wlssm_server2

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

14. 「構成のサマリー」画面で、「作成」をクリックします。

15. 新しいドメインで./startWeblogic.shを使用して、WebLogic管理サーバーを起動します。

16. 管理対象サーバーを起動します。作成したドメイン・ディレクトリのサブフォルダbinに切り替え、./startManagedWebLogic.sh 管理対象サーバー名 http://wlsadminserver host:wls_adminserver_portを入力します。
次に例を示します。

./startManagedWeblogic.sh wlssm_server1 http://localhost:7001

packおよびunpackコマンドを使用し、WebLogic Serverセキュリティ・モジュールが使用するドメイン・ディレクトリをOESHOST1の管理対象サーバーが使用するドメイン・ディレクトリから分離します。

OESHOST1で独立ドメイン・ディレクトリを作成する手順は次のとおりです。

1. 次のようにpackコマンドを実行し、テンプレート・パックを作成します。
cd MW_HOME/oracle_common/common/bin

./pack.sh -managed=true -domain=domain_path -template==domaintemplate.jar -template_name=domain_template

2. 次のようにunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
cd MW_HOME/oracle_common/common/bin

./unpack.sh -domain=new_domain_path -template=domaintemplate.jar

たとえば管理対象サーバー(OESHOST2など)を起動する前に、リモート・ホストでunpackを実行します。

3. 手順1のファイルdomaintemplate.jarをOESHOST2にコピーします。

4. 次のコマンドを使用して、OESHOST2のホストでunpackを実行します。
cd MW_HOME/oracle_common/common/bin

./unpack.sh -domain=domain_path -template==domaintemplate.jar

5. 管理対象サーバーの起動後、作成したドメイン・ディレクトリのサブフォルダbinに切り替えます。./startManagedWebLogic.sh 管理対象サーバー名 http://wlsadminserver host:wls_adminserver_portを入力します。
例:

./startManagedWeblogic.sh wlssm_server2 http://localhost:7001

10.2.9 制御プル・モードおよび非制御モードのセキュリティ・モジュールでのRACデータ・ソースの使用

ポリシー・ストアへの接続は、制御プル・モードおよび非制御モードのOracle Entitlements Serverセキュリティ・モジュールで使用されます。SMConfig UIの制限によって、セキュリティ・モジュール・インスタンスの作成時にJDBCプロパティを構成する必要があります。

RACデータ・ソースをWebLogic Serverセキュリティ・モジュールまたはWebLogic Server上のWebサービスのセキュリティ・モジュールで使用するには、セキュリティ・モジュール・インスタンスの作成後に、次の手順を実行します。

1. セキュリティ・モジュールがデプロイされているドメインのWebLogic管理コンソールにログインします。Oracle Entitlements Serverの管理サーバーと同じデータベース情報を使用して、RACデータ・ソースを構成します。

2. SMConfig UIで、セキュリティ・モジュール構成を編集します。

- OES_CLIENT_HOME/oes_sm_instances/SM_Name/binを実行します。

- oessmconfig.shを実行します。

- 「JNDI名によるデータベース構成」を選択して、「* データソースJNDI名」フィールドにRACデータ・ソースJNDI名を入力します。「保存して閉じる」をクリックします。

10.2.10 Web Tierと連携するためのOracle Entitlements Serverの構成

この項では、Oracle Web Tierと連携するためのOracle Entitlements Serverの構成方法について、次の項目について説明します。

- 第10.2.10.1項「前提条件」

- 第10.2.10.2項「OESの管理対象サーバーをフロントエンドするためのOracle HTTP Serverの構成」

- 第10.2.10.3項「Oracle HTTP Serverの構成の検証」

10.2.10.1 前提条件

次のタスクが実行済であることを確認します。

1. Oracle Web TierをWEBHOST1とWEBHOST2にインストールしました。
WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールする手順は、第8.5.3.5.1項「Web Tier用のOracle HTTP Serverのインストール」を参照してください。

2. Oracle Entitlements Serverを、OESHOST1およびOESHOST2上にインストールし、構成しました。

3. ロード・バランサをWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(sso.example.com)で構成しました。

4. ロード・バランサをWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(oesinternal.example.com)で構成しました。

10.2.10.2 OESの管理対象サーバーをフロントエンドするためのOracle HTTP Serverの構成

1. WEBHOST1とWEBHOST2上の各Webサーバーで、oes.confと呼ばれるファイルをORACLE_INSTANCE/config/OHS/component/moduleconfディレクトリに作成します。このファイルには次の情報が記載されている必要があります。

NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName http://sso.example.com:7777
RewriteEngine On
RewriteOptions inherit
UseCanonicalName On

# OES admin console
<Location /apm>
SetHandler weblogic-handler
WebLogicCluster oeshost1.example.com:14600,
oeshost2.example.com:14600
</Location>

2. このファイルをWEBHOST1とWEBHOST2の両方に保存します。

3. WEBHOST1およびWEBHOST2の両方で、Oracle HTTP Serverインスタンスを停止および起動します。

10.2.10.3 Oracle HTTP Serverの構成の検証

Oracle HTTP Serverが適切に構成されていることを検証する手順は次のとおりです。

1. Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。
http://sso.example.com:7777/apm

2. APMのログイン・ページで、weblogicユーザーの資格証明を使用してログインします。

11 Mobile and Socialの高可用性の構成

この章では、Oracle Access Management Mobile and Socialの高可用性フレームワークについて説明します。内容は次のとおりです。

- 第11.1項「Oracle Access Management Mobile and Socialコンポーネント・アーキテクチャ」

- 第11.2項「Mobile and Socialコンポーネントの特性」

- 第11.3項「Mobile and Socialの高可用性の概要」

- 第11.4項「Mobile and Socialの高可用性の構成」

11.1 Oracle Access Management Mobile and Socialコンポーネント・アーキテクチャ

Oracle Access Management Mobile and Social (Mobile and Social)は、既存のIdentity Managementインフラストラクチャをモバイルおよびソーシャル・ネットワークに接続する軽量のセキュリティおよびアイデンティティ・ソリューションです。Mobile and Socialを使用することで、制御されたビューを外側の世界に安全に公開できます。Mobile and Socialでは、ソーシャル・メディアのユーザー・アイデンティティを管理されたエンタープライズ内のエンタープライズ・アプリケーションおよびポータルで使用するためのメカニズムが提供されています。Mobile and Socialは、OAMおよびIGFを含む既存のIDM製品と統合されます。Mobile and Socialの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Mobile and Socialに関する説明を参照してください。

図11-1は、Mobile and Socialコンポーネントのアーキテクチャを示しています。

図11-1 Mobile and Socialコンポーネント・アーキテクチャ

Oracle Access Management Mobile and Socialサービスは、保護されているリソースへのアクセスを必要とするユーザーと、リソースを保護するバックエンドのアクセス管理サービスおよびアイデンティティ管理サービスの間の橋渡しの役割を果たします。Mobile and Socialには簡易なクライアント・ライブラリが用意されており、開発者はこれを使用して、機能豊富な認証、認可およびアイデンティティ機能を登録済アプリケーションに簡単に追加できます。バックエンドのMobile and Socialサーバーのプラガブルなアーキテクチャにより、システム管理者は、ユーザーがインストールしたソフトウェアをアップデートしなくても、アイデンティティ管理サービスおよびアクセス管理サービスを追加、変更および削除することができます。

11.1.1 セッションの状態情報

モバイル・サービス・コンポーネントでは、セッション情報は記録されません。インターネット・アイデンティティ・サービスでは、短期間のトークンがメモリーに保持され、期限が切れると破棄されます。

11.1.2 コンポーネントのライフサイクル

Mobile and Socialは、Access Suite J2EEアプリケーション内のコンポーネントです。Mobile and SocialはAccess Suiteの一部としてデプロイおよび構成されるため、インストール、構成、サーバー・インスタンスはAccess Suiteと関連付けられます。

モバイル・サービスおよびインターネット・アイデンティティ・サービスの一部として、Mobile and Socialでは、クライアントで起動するHTTPインタフェースを提供しています。Mobile and Socialは、リクエストを処理してレスポンスを返しますが、クライアントはこれを使用して追加のリクエストを行う場合があります。Mobile and Socialはステートレスであり、クライアントから個別に送信されたすべてのリクエストを処理できます。Mobile and Socialでは、OAMなどの製品や、ソーシャル・ネットワーク認証およびディレクトリ・サーバーを使用したユーザー・プロファイル・サービスを使用した、モバイル・デバイスの登録サービスおよびユーザー認証サービスが提供されます。

Mobile and Socialは、Access Suiteサーバーの起動の一部として起動されます。MBeanサーバーは、Mobile and Socialの構成をロードします。

11.1.3 コンポーネントの構成アーティファクト

管理コンソールまたはWLSTコマンドを使用して、構成ファイルを編集します。表11-1に、Mobile and Socialの構成ファイルとその場所を示します。

表11-1 Mobile and Socialコンポーネントの構成ファイル

ファイル

場所

Idaas.xml

<DOMAIN_HOME>/config/fmwconfig

oic_rp.xml

<DOMAIN_HOME>/config/fmwconfig

11.1.4 Mobile and Socialデプロイメント・アーティファクト

A Mobile and Socialインストールでは、次のコンポーネントがoam-server.earの一部としてデプロイされます。

- oic_rest.war

- oic_rp.war

表11-2に、Mobile and Socialサービスのデプロイメントの場所を示します。

表11-2 Mobile and Social製品のデプロイメントの場所

Mobile and Social製品

デプロイメントの場所

管理サーバー

管理サーバーのユーザー・インタフェースは、OAM Adminの.ear (oam-admin.ear)の一部としてデプロイされます。

管理対象サーバー、RESTおよびインターネット・アイデンティティ・サービスのランタイム

OAMサーバーの.earファイル(oam-server.ear)の一部としてデプロイされます。

11.2 Mobile and Socialコンポーネントの特性

Mobile and Socialサービスは、モバイル・サービスとインターネット・アイデンティティ・サービスの2つのサブコンポーネントで構成されます。モバイル・サービスでは、認証、ユーザー・プロファイルおよび認可サービス用にRepresentational State Transfer (REST)インタフェースが提供されます。インターネット・アイデンティティ・サービスでは、ソーシャル・ネットワーク認証との統合が提供されます。

Mobile and Socialの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のモバイル・サービスの概要に関する説明を参照してください。

11.3 Mobile and Socialの高可用性の概要

この項では、Mobile and Socialの高可用性アーキテクチャおよびその要素について説明します。内容は次のとおりです。

- 第11.3.1項「Mobile and Socialの高可用性アーキテクチャ」

- 第11.3.1項「Mobile and Socialの高可用性アーキテクチャ」

11.3.1 Mobile and Socialの高可用性アーキテクチャ

図11-1は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたMobile and Socialを示しています。

図11-2 Mobile and Socialの高可用性アーキテクチャ

図11-2は、複数インスタンスのデプロイメントをサポートする標準的なクライアント・サーバー・アーキテクチャを示しています。ほとんどの場合、リクエストはステートレスで、永続性は必要ありません。Mobile and Socialサービスは、OAM/OIDなどの他の製品に依存しており、それらに独自の高可用性機能がある場合があります。状態が保持される場合(インターネット・アイデンティティ認証リクエスト)、高可用性はスティッキーなロード・バランシングを介して実現されます。

セッションのデータベース永続性やランタイム・データがないため、リクエストはどのサーバーにも送信されることができます。ロード・バランサは、Round Robinなどのポリシー・セットに基づいて、リクエストをMobile and Socialサービス1または2に返します。

アプリケーションでインターネット・アイデンティティ・サービスが起動されると、リクエストを処理するために、Google、Facebookまたはインターネット・アイデンティティ・プロバイダに制御が移ります。アイデンティティ・プロバイダからレスポンスが返されるときは、そのリクエストを開始した同じサーバーにレスポンスが返される必要があります。複数のMobile and Socialノード・デプロイメントがあり、アクセスがロード・バランサを介して行われる場合は、Mobile and Socialへのリクエストは、ロード・バランサのスティッキー・セッション機能を使用して同じサーバーに固定される必要があります。IDPへのリクエストを開始したMobile and SocialがIDPレスポンスを受信した後に、Mobile and Socialは、そのリクエストに対してさらに処理を行うことができます。

Mobile and Socialアプリケーションは、クラスタ内のすべてのメンバーにデプロイされます。クラスタでのデプロイ成功時に、Mobile and Socialアプリケーションは他のクラスタ・メンバーに通知はしません。

11.3.2 Mobile and Socialの高可用性とノードのフェイルオーバー

この項では、ノード障害からの保護を提供するMobile and Socialアーキテクチャの要素について説明します。

ノード・フェイルオーバーが発生した場合、Mobile and Socialは、WebLogic Serverの標準のフェイルオーバー手順に従うことに注意してください。クライアントから受信したリクエストをMobile and Socialで完了する前にノード障害が発生した場合、クライアントは、HTTP接続タイムアウトを介してエラーを受信します。

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

- 第11.3.2.1項「ロード・バランシングの要件および特性」

- 第11.3.2.2項「セッション状態レプリケーションとフェイルオーバー」

- 第11.3.2.3項「クライアント・アプリケーションの起動」

- 第11.3.2.3.1項「障害検出と再起動」

11.3.2.1 ロード・バランシングの要件および特性

Mobile and Socialコンポーネントは、WebLogic Server 10.3にデプロイされる標準のJ2EEアプリケーションで、ロード・バランシング向けの標準に準拠しています。次の点に注意してください。

- Mobile and Social/RPのリクエストではスティッキーなセッション・ルーティングを使用する必要がありますが、外部ロード・バンランサはサポートされています。

- コンポーネント間のロード・バランシングはありません。

- 永続接続がないため、タイムアウト要件はありません。

11.3.2.2 セッション状態レプリケーションとフェイルオーバー

Mobile and Socialの高可用性アーキテクチャは、フェイルオーバー要件についてはWebLogic Serverの標準のクラスタ・サポートに依存します。このアーキテクチャでは、セッション状態はレプリケートされません。

11.3.2.3 クライアント・アプリケーションの起動

Mobile and Socialインスタンスの起動時に、動作中のシステムの状態には影響しません。Mobile and Socialインスタンスは、WebLogic Serverのクラスタ化のシナリオに参加する場合を除いて、他の動作中のコンポーネントやクラスタ・メンバーには影響しません。

11.3.2.3.1 障害検出と再起動

障害検出およびコンポーネントの再起動に、Java EEコンポーネントのノード・マネージャおよびシステム・コンポーネントのOPMNを使用します。

11.4 Mobile and Socialの高可用性の構成

Mobile and Socialは、Oracle Access Managerと同一の管理対象サーバーの一部です。

Mobile and Socialは個別に、あるいはOAM、STSおよびIdentity Federationなどの別のコンポーネントとともにデプロイできます。

次のMobile and Social構成の前提条件に注意してください。

- 無効になっている場合は、Mobile and Socialを有効化する必要があります。Oracle Access Managementコンソールにログインし、「システム構成」タブを選択して、「使用可能なサービス」を開き、Mobile and Socialのステータスに緑色のチェックが表示されていることを確認します。

- ORACLE_INSTANCE/config/OHS/ohs1/moduleconfのoam.confファイルに次のマッピングを追加することによって、oic_restおよびoic_rpにOHSを構成する必要があります。

<Location /oic_rest>
SetHandler weblogic-handler
WebLogicCluster
oamhost1.example.com:14100,oamhost2.example.com:14100
</Location>

<Location /oic_rp>
SetHandler weblogic-handler
WebLogicCluster
oamhost1.example.com:14100,oamhost2.example.com:14100
</Location>

12 Oracle Privileged Account Managerコンポーネントの高可用性の構成

この章では、Oracle Privileged Account Managerの高可用性フレームワークについて説明します。内容は次のとおりです。

Oracle Privileged Account Managerは、他のどのOracle Identity Managementコンポーネントにも管理されない特権アカウントを管理します。機密データにアクセスできる場合、機密データへのアクセス権限を付与できる場合または機密データへのアクセスとアクセス権限の付与の両方ができる場合に、アカウントは特権とみなされます。

Oracle Privileged Account Managerの詳細とその機能は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のOracle Privileged Account Managerの理解に関する説明を参照してください。

- 第12.1項「Oracle Privileged Account Managerコンポーネント・アーキテクチャ」

- 第12.2項「Oracle Privileged Account Managerの高可用性の概要」

- 第12.3項「Oracle Privileged Account Managerの高可用性アーキテクチャ」

- 第12.4項「Oracle Privileged Account Managerの高可用性およびノード障害」

- 第12.5項「Oracle Privileged Account Managerの高可用性の構成」

12.1 Oracle Privileged Account Managerコンポーネント・アーキテクチャ

Oracle Privileged Account Manager (OPAM)は、Webアプリケーションとして実行されるサーバー、ユーザー・インタフェースおよびセッション・マネージャ・コンポーネントで構成されます。サーバーとユーザー・インタフェースはWebアプリケーションです。この時点で、セッション・マネージャは、Webインタフェースを持たない標準のJ2EEアプリケーションです。OPAMサーバーは、WebLogic管理対象サーバー内で実行されます。OPAMユーザー・インタフェースはOracle Identity Navigator (OIN)の一部で、OPAM WebLogic管理対象サーバーでも実行されます。OPAMセッション・マネージャは、管理対象サーバーでも実行されます。

OPAMデプロイメントのデフォルトの最も簡単な構成では、WebLogicドメイン内の単一のOPAM管理対象サーバーの実行が必要です。OPAMは、独自のスキーマを使用してターゲットのパスワード、アカウント、その他のアイテムを格納します。

次の図は、Oracle Privileged Account Managerのアーキテクチャとトポロジを示しています。

図12-1 Oracle Privileged Account Managerコンポーネント・アーキテクチャ

このアーキテクチャでは、次の点に注意してください。

- Oracle Privileged Account Managerのコア・ロジックはすべてOracle Privileged Account Managerサーバーに存在します。この機能は、Representational State Transfer (RESTまたはRESTful)サービスを介して公開されますが、データはJavaScript Object Notation (JSON)でエンコードされます。

注意:

Oracle Privileged Account Managerでは、Oracle Identity NavigatorのWebベースのユーザー・インタフェースおよびOracle Privileged Account Managerコマンド行ツールが提供されます。どちらのインタフェースも基本的に、Oracle Privileged Account Managerサーバーのクライアントです。

ただし、サードパーティはオープンなRESTfulサービスを利用することで、カスタム・アプリケーションなどの独自のクライアントに書き込むことができます。詳細は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のOracle Privileged Account ManagerのRESTfulインタフェースの使用に関する説明を参照してください。

- OPAMセッション・マネージャはOPAMのサブコンポーネントで、OPAMセッション管理機能を実行します。これは、OPAM RESTfulインタフェースを使用してOPAMサーバーと対話するJ2EEアプリケーションで、OPAMサーバーが使用するのと同じデータベースを共有します。さらに、OPAMセッション・マネージャは、SSHトラフィックをリスニングして応答し、SSH対応OPAMターゲットに対して特権セッションを確立します。

- Oracle Privileged Account Managerの認証は、WebLogicのJava Authentication & Authorization Service (JAAS)サポートに依存します。WebLogicでのJAASサポートの詳細は、Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの理解のWebLogicセキュリティ・サービス・アーキテクチャに関する説明を参照してください。

- Oracle Privileged Account Manager関連のコンポーネントとの、およびコンポーネント間のすべての通信(Oracle Privileged Account ManagerのWebベースのユーザー・インタフェース、コマンド行インタフェースおよびサーバーを含む)は、すべてSSL経由で行われます。

- Oracle Privileged Account Managerは、Oracle Privileged Account Managerのデプロイ先であるWebLogicドメインで構成されているIDストアおよびポリシー・ストアに依存し、それらを透過的に使用します。
詳細は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のDeployed in Oracle Fusion MiddlewareでのOracle Privileged Account Managerのデプロイに関する説明を参照してください。

- Oracle Privileged Account ManagerのWebベースのユーザー・インタフェースは、Oracle Application Development Framework (ADF)を利用して、表示されます。

- Oracle Privileged Account Managerは、Identity Connector Framework (ICF)コネクタを使用してターゲットに接続します。詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のIdentity Connector Frameworkの理解に関する説明を参照してください。

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

- 第12.1.1項「ランタイム・プロセス」

- 第12.1.2項「プロセスのライフサイクル」

- 第12.1.3項「セッションの状態」

- 第12.1.4項「外部依存性」

- 第12.1.5項「デプロイメント・アーティファクト」

- 第12.1.6項「ログ・ファイルの場所」

12.1.1 ランタイム・プロセス

OPAMサーバーは、WebLogic管理対象サーバーを実行するサーバー・コンポーネントです。OPAMセッション・マネージャは、OPAM WebLogic管理対象サーバーでも実行されるコンポーネントです。OPAMユーザー・インタフェースは、OPAM WebLogic管理対象サーバーで実行されるコンポーネントです。OPAMサーバーは、OPAMユーザー・インタフェースおよびコマンド行クライアントを含むクライアントとの通信に、RESTプロトコルを使用します。OPAMサーバーは、データ・ストアとしてOPAMデータベースを使用します。OPAMサーバーおよびユーザー・インタフェースは、複数のサーバーがあるWebLogicクラスタにデプロイでき、WebLogicコンソールを使用してプロセスを管理します。

12.1.2 プロセスのライフサイクル

OPAMサーバーおよびOPAMセッション・マネージャは、WebLogic ServerにデプロイされるJ2EEアプリケーションです。

起動時に、OPAM Lifecycle Listenerは、キーストアがそのドメインに存在するかどうかを確認します。

- キーストアが存在しない場合は、OPAM Lifecycle Listenerは、ランダムに生成されたキーストアのパスワードを使用してキーストアを作成し、ドメイン名を別名としたキーストア・エントリを作成し、そのキーストア・パスワードを使用してCSFを更新します。

- キーストアが存在する場合は、CSFからキーストア・パスワードを取得して、ドメイン名を別名とするエントリが存在するかどうかを確認します。

キーストアおよび目的のキーストアのCSFエントリが存在する場合は操作を行わないため、OPAMの高可用性環境はプロセスのライフサイクルに影響を与えません。

OPAMサーバーは、RESTfulインタフェースがクライアントにサービスを提供するサーブレット・モデルを使用します。このため、コンポーネントのライフサイクルは、その他の実行中のインスタンスに影響を与えません。

CSFの詳細は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のOracle Privileged Account Manager管理対象CSF資格証明に関する説明を参照してください。

12.1.3 セッションの状態

OPAMサーバーはRESTベースの通信を使用し、クライアントはHTTPS URLを使用します。セッションの状態情報は保存されません。各通信で操作を完了すると、セッションは保持されません。

OPAMセッション・マネージャは、円滑化する特権セッションごとにセッションの状態を維持します。セッションの確立後、セッション開始時に使用されたOPAMセッション・マネージャ・インスタンスは、そのセッションを継続する必要があります。セッション中にOPAMセッション・マネージャに障害が発生した場合は、バックグラウンド・スレッドが定期的に孤立したセッションをクリーンアップします。

12.1.4 外部依存性

OPAMサーバーの依存性の内容は次のとおりです。

- ICFコネクタ、ターゲット・システムとの通信用

- 外部IDストア、認証用(WebLogicで構成可能)

OPAMユーザー・インタフェースおよびOPAMコマンド行ツールはOPAMサーバーに依存します。HTTPS URLを使用するRESTであるクライアント接続は短期です。

12.1.5 デプロイメント・アーティファクト

OPAMを管理対象サーバーにデプロイした場合、Oracle Identity Navigatorは管理サーバーにデプロイされます。Oracle JRFは、管理サーバーと管理対象サーバーの両方にデプロイされます。表12-1は、OPAM製品アーティファクトのデプロイ先を示します。

表12-1 OPAMデプロイメント・アーティファクト

場所

製品アーティファクト

管理サーバー

Oracle JRF

管理対象サーバー

OPAMサーバー.earファイル、OPAMセッション・マネージャ.earファイル、
Oracle Identity Navigator .earファイル、Oracle JRF

12.1.6 ログ・ファイルの場所

WebLogic Serverのログおよび監査ログは、DOMAIN_HOMEに保存されます。

監査ログがWebLogicに構成されている場合は、監査データベースに保存されます。

12.2 Oracle Privileged Account Managerの高可用性の概要

クラスタ・レベルで、Connectorディレクトリ、時間制限などのOPAMプロパティを変更できます。

すべてのサーバーは、構成が保持されている共通ドメインのOPAMデータ・ストアに接続します。したがって、すべてのサーバーは共有データを取得します。

12.3 Oracle Privileged Account Managerの高可用性アーキテクチャ

図12-2は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたOracle Privileged Account Managerを示しています。

図12-2 高可用性アーキテクチャのOracle Privileged Account Manager

この構成では、Oracle Privileged Account Managerのサーバーは、同じドメインの一部であり、同じOPSSセキュリティ・ストアを使用します。複数のサーバーがOPSSセキュリティ・ストアと対話するため、データベースをOPSSバックエンドとして使用することをお薦めします。

このクラスタ構成では、クラスタ内の別のサーバーから同じデータを使用できます。各管理対象サーバーには独自のポート構成があります。構成にはロード・バランサが含まれています。

OPAMHOST1には、次のインストールがあります。

- WLS_OPAM1管理対象サーバーのOracle Privileged Account Managerインスタンス。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するために、JDBCマルチ・データ・ソースまたはGridLinkデータ・ソース内に構成されています。

- WebLogic Serverの管理サーバー。通常の運用時は、これがアクティブ管理サーバーになります。

OPAMHOST2には、次のインストールがあります。

- WLS_OPAM2管理対象サーバーのOracle Privileged Account Manager。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するために、JDBCマルチ・データ・ソースまたはGridLinkデータ・ソース内に構成されています。
WLS_OPAM2管理対象サーバーにあるインスタンスと、WLS_OPAM1管理対象サーバーにあるインスタンスは、CLUSTER_OPAMクラスタとして構成されています。

- WebLogic Serverの管理サーバー。通常の運用時は、これがパッシブ管理サーバーになります。HOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。アクティブ/パッシブ管理サーバーの構成の詳細は、第15章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。

12.3.1 クラスタの起動と停止

デフォルトでは、WebLogic Serverによって、このアプリケーションに対するライフサイクル・イベントの起動、停止、監視および管理が行われます。Oracle Privileged Account Managerアプリケーションは、基盤となるOracle WebLogicクラスタの高可用性機能を利用します。ハードウェアなどの障害が発生した場合は、障害発生ノードの処理の再開が可能な他のクラスタ・ノードがこのセッション状態を使用できます。

高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。

高可用性環境では、状態情報と構成情報は、クラスタ内のすべてのメンバーが共有するデータベースに格納されます。

12.4 Oracle Privileged Account Managerの高可用性およびノード障害

高可用性構成でのOracle Privileged Account Managerのノード障害には、次の特性があります。

- ノード障害はクライアントに影響しません。

- サーバーに障害が発生した場合、実行中のRESTベースの操作は停止しますが、フェイルオーバーされません。クライアントは使用可能なサーバーに接続して、リクエストをリトライまたは継続できます。デプロイメントにロード・バランサが含まれている場合、リクエストは使用可能なサーバーに送信されます。

12.5 Oracle Privileged Account Managerの高可用性の構成

この項では、Oracle Privileged Account Managerの高可用性で最大限の高可用性を得るためのデプロイメントを設定する高度な手順について説明します。この項では、次の項目について説明します。

- 第12.5.1項「適切なデプロイメント環境」

- 第12.5.2項「デプロイされるコンポーネント」

- 第12.5.3項「依存性」

- 第12.5.4項「高可用性の構成手順」

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

12.5.1 適切なデプロイメント環境

新しいWebLogicドメインにOracle Identity NavigatorとともにOracle Privileged Account Managerを構成し、Oracle Identity Navigatorの検出機能を実行する場合、このトピックの構成を実行してください。この機能により、Oracle Identity Manager、Oracle Access Management、Oracle Adaptive Access ManagerおよびOracle Privileged Account Managerの製品コンソールへのリンクが移入されます。これにより、個々の製品コンソールURLを覚えていなくても、Oracle Identity Navigatorインタフェースからこれらの製品コンソールにアクセスできます。

12.5.2 デプロイされるコンポーネント

この項の構成を実行すると、Oracle Privileged Account ManagerおよびOracle Identity Navigatorアプリケーションが新しいWebLogic管理サーバーにデプロイされます。

12.5.3 依存性

この項の構成は、次のものに依存しています。

- Oracle WebLogic Server

- Oracle Identity and Access Management 11gソフトウェアのインストール

詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Management (11.1.2.0.0)のインストールと構成に関する説明を参照してください。

12.5.4 高可用性の構成手順

この項の手順は次のとおりです。

- 第12.5.4.1項「OPAMHOST1でのOracle Identity and Access Managementの構成」

- 第12.5.4.2項「OPAMHOST1の起動」

- 第12.5.4.3項「OPAMHOST2でのOPAMの構成」

- 第12.5.4.4項「OPAMHOST2の起動」

12.5.4.1 OPAMHOST1でのOracle Identity and Access Managementの構成

Oracle Privileged Account ManagerおよびOracle Identity Navigatorの高可用性を最大化するように構成するには、次の手順を実行します。

1. Oracle WebLogic Serverをインストールし、Middlewareホームを作成します。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のWebLogic ServerおよびMiddlewareホームの要件に関する説明を参照してください。

2. Oracle Identity and Access Management 11gソフトウェアをインストールします。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Management (11.1.2.0.0)のインストールに関する説明を参照してください。

3. このコマンドを実行して、構成ウィザードを起動します。

ORACLE_HOME/oracle_common/common/bin/config.sh

注意:

config.shスクリプトは、Oracle Identity Manager、Access Manager、Oracle Adaptive Access Manager、Oracle Entitlements Server、Oracle Privileged Account Manager、Mobile and SocialおよびOracle Identity Navigatorが含まれているOracle Identity and Access Managementホーム・ディレクトリから実行する必要があります。

4. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。「ドメイン・ソースの選択」画面が表示されます。

5. 「ドメイン・ソースの選択」画面で、「次の製品をサポートするために、自動的に構成されたドメインを生成する」オプションが選択されていることを確認します。Oracle Privileged Account Manager - 11.1.2.0.0 [IAM_Home]を選択します。

注意:

「Oracle Privileged Account Manager - 11.1.2.0.0 [IAM_Home]」オプションを選択すると、「Oracle Identity Navigator」、「Oracle JRF」および「Oracle Platform Security Services」オプションもデフォルトで選択されます。

「次へ」をクリックします。「ドメイン名と場所の指定」画面が表示されます。

6. ドメイン名IDM_Domainを入力します。「ドメインの場所」および「アプリケーション・ディレクトリ」は、デフォルトのままにします。「次へ」をクリックします。「管理者ユーザー名およびパスワードの構成」画面が表示されます。

7. 管理者のユーザー名とパスワードを構成します。デフォルトのユーザー名はweblogicです。「次へ」をクリックします。

8. Oracle Fusion Middleware構成ウィザードの「サーバーの起動モードおよびJDKの構成」画面で、JRockit SDK 1.6.0_<version>と「本番モード」を選択します。

9. 「JDBCコンポーネント・スキーマの構成」画面で、OPAMスキーマおよびOPSSスキーマのデータベース・スキーマの詳細を入力します。

注意:

GridLinkデータ・ソースを使用することもできます。詳細は、第3.13項「GridLinkデータ・ソース」を参照してください。

(オプション)コンポーネント・スキーマのRAC構成に関するオプションを選択します。

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

10. 「コンポーネント・スキーマのテスト」画面で、構成ウィザードによりデータ・ソースの検証が試行されます。すべてのスキーマに対するテストが正常に完了したことを確認します。
データ・ソースの検証が成功したら、「次へ」をクリックします。

データ・ソースの検証に失敗した場合は、「前へ」をクリックして問題を修正し、もう一度実行します。

11. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

- デプロイメントとサービス

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

12. 「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。

13. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: OPAMHOST1.example.com

- リスニング・ポート: 7001
次のパラメータは設定または変更しないでください。

- SSLリスニング・ポート: 適用なし

- SSL有効または無効

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

14. 「管理対象サーバーの構成」画面で、トポロジのOPAMHOSTごとにエントリを作成しますが、つまり、OPAMHOST1上で実行されている OPAMサーバーに対して1つと、OPAMHOST2上で実行されているOPAMサーバーに対して1つ作成します。
OPAM_SERVERエントリを選択し、そのエントリを次の値に変更します。

- 名前: opamserver1

- リスニング・アドレス: OPAMHOST1.example.com

- リスニング・ポート: 18101

- SSLポート: 18102

2つ目のOPAM_SERVERでは、「追加」をクリックして、次の値を入力します。

- 名前: opam_server2

- リスニング・アドレス: OPAMHOST2.example.com

- リスニング・ポート: 18101

- SSLポート: 18102

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

15. 「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
OPAM_Clusterなどのクラスタの名前を入力します。その他すべてのフィールドはデフォルト設定のままにします。

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

16. 「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。
右のウィンドウで、クラスタ名「OPAM_Cluster」をクリックします。

管理対象サーバー「opam_server1」をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。

管理サーバーopam_server2について、前述の手順を繰り返します。

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

17. 「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。

次の情報を指定します。

- 名前: ホスト名です。ここでは、DNS名を使用することをお薦めします。

- ノード・マネージャ・リスニング・アドレス: ここにマシンのDNS名を入力します。

- ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。

OPAMHOST2について前述の手順を繰り返し、次の値を入力します。

- 名前: ホスト名です。DNS名OPAMHOST2を使用することをお薦めします。

- ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OPAMHOST.example.com)を入力します。

- ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。

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

18. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
右側のウィンドウでマシンをクリックします。

左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。

矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。

すべての管理対象サーバーが適切なマシンに割り当てられるまで、この手順を繰り返します。

例:

- ホスト1: 管理サーバー、OPAMHOST1およびopam_server1

- ホスト2: OPAMHOST2およびopam_server2

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

19. 「構成のサマリー」画面で、「作成」をクリックします。

12.5.4.1.1 データベース・セキュリティ・ストアの構成

ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、第12.5.4.1.1項「データベース・セキュリティ・ストアの構成」を参照してください。

12.5.4.1.2 OPAMHOST1上での管理サーバーの起動

管理サーバーを起動するには、次の手順を実行します。

1. DOMAIN_HOME/binディレクトリに移動します。startWeblogic.shを実行します。

2. プロンプトで、WebLogic管理者のユーザー名とパスワードを入力します。

注意:

次の手順は、管理サーバーを最初に起動したときのみに実行します。

注意:

opam-config.shを実行する次の手順に進む前に、ORACLE_HOME、JAVA_HOMEおよびANT_HOME環境変数を設定する必要があります。ANT_HOMEでは、middleware_home/modules/org.apache.ant_1.7.1などのAntおよびJARバイナリ・ファイルが含まれている場所をポイントしている必要があります。

3. 管理サーバーが起動したら、ORACLE_HOME/opam/binディレクトリに移動します。opam-config.shを実行します。

4. プロンプトで、WebLogicのユーザー名、パスワード、URL、ドメイン名およびMiddlewareホームを入力します。

5. opam-config.shの実行後、管理サーバーを再起動します。

12.5.4.2 OPAMHOST1の起動

この項では、OPAMHOST1の起動手順について説明します。

1. コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行します。
MW_HOME/oracle_common/common/bin/setNMProps.sh

2. コマンドMW_HOME/wlserver_10.3/server/bin/startNodeManager.shを使用して、ノード・マネージャを起動します。

12.5.4.2.1 OPAMHOST1でのOracle Privileged Account Managerの起動

OPAMHOST1上のOracle Privileged Account Managerを起動する手順は、次のとおりです。

1. 次のURLを使用して、WebLogic管理コンソールにログインします。

http://opamhost1.example.com:7001/console

2. WebLogic管理者のユーザー名とパスワードを入力します。

3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

4. 「制御」タブをクリックします。

5. サーバー「opam_server1」をクリックします。

6. 「起動」をクリックします。

7. 「OK」をクリックします。

12.5.4.3 OPAMHOST2でのOPAMの構成

OPAMHOST1で構成を完了したら、それをOPAMHOST2に伝播できます。これを実行するには、OPAMHOST1でpackスクリプトを使用してドメインをパックし、OPAMHOST2でunpackスクリプトを使用してドメインを解凍します。

どちらのスクリプトも、MW_HOME/oracle_common/common/binディレクトリにあります。

1. MW_HOMEおよびORACLE_HOMEディレクトリ構造がOPAMHOST1ディレクトリ構造と同じであることを確認します。

2. OPAMHOST1で次のように入力して、/tmpディレクトリにファイルidm_domain.jarを作成します。

pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain

-template=/tmp/idm_domain.jar -template_name="OPAM Domain" -managed=true

3. 前の手順で、idm_domain.jarファイルが/tmpディレクトリに作成されています。
このidm_domain.jarファイルを、OPAMHOST1からOPAMHOST2上の一時ディレクトリにコピーします。

4. idm_domain.jarをOPAMHOST2にコピーするには、次のように入力します。

unpack.sh -domain=MW_HOME/user_projects/domains/IDM_Domain
-template=/tmp/idm_domain.jar

5. jps-wls-trustprovider.jarを、MW_HOME/oracle_common/modules/oracle.jps_11.1.1からWLS_SERVER_HOME/server/lib/mbeantypesにコピーします。

12.5.4.4 OPAMHOST2の起動

この項では、OPAMHOST2の起動手順について説明します。

1. コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。ディレクトリMW_HOME/oracle_common/common/binにあるスクリプトsetNMProps.shを実行します。

2. コマンドMW_HOME/wlserver_10.3/server/bin/startNodeManager.shを使用して、ノード・マネージャを起動します。

3. OPAMHOST2でOracle Privileged Account Managerを起動します。第12.5.4.2.1項「OPAMHOST1でのOracle Privileged Account Managerの起動」を参照して、HOST1とserver1をHOST2とserver2に置き換えます。

12.5.5 OHSロード・バランサの構成

Oracle HTTP Server (OHS)を使用してOPAMサーバーをロード・バランシングできます。この項では、OHSと連携するようにOPAMを構成する手順について説明します。内容は次のとおりです。

- 第12.5.5.1項「SSLの構成」

- 第12.5.5.2項「Oracle HTTP Server構成の更新」

- 第12.5.5.3項「Oracle HTTP Serverの再起動」

12.5.5.1 SSLの構成

OPAMサーバーでは通信にSSLを使用するため、OHSロード・バランサでSSLオプションを構成する必要があります。次の手順を実行します。

1. OPAMの管理対象サーバーおよび管理サーバーと通信できるように、OHSからのアウトバウンドSSL接続を有効化します。これを行うには、『Oracle Fusion Middleware管理者ガイド』のOracle HTTP Serverからのアウトバウンド・リクエストでのSSLの有効化に関する説明を参照してください。

2. OPAMの管理対象サーバーおよび管理サーバーへのインバウンドSSL接続を有効化します。『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic ServerへのインバンドSSLに関する説明を参照してください。

12.5.5.2 Oracle HTTP Server構成の更新

OHSがインストールされているホストで、opam.confという名前のファイルを次のディレクトリに作成します。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

次の行を指定してファイルを作成します。

NameVirtualHost *:4443
<VirtualHost *:44443>

ServerName http://opam.example.com:4443
ServerAdmin user@example.com
RewriteEngine On
RewriteOptions inherit

<Location /opam>
SetHandler weblogic-handler
WebLogicCluster opamhost1.example.com:18102,opamhost2.example.com:18102
WLCookieName OPAMSESSIONID
WlSSLWallet "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_
NAME}/keystores/ohs_wallet"
WLProxySSL ON
WLProxySSLPassThrough ON
SecureProxy On
</Location>

</VirtualHost>

OPAMコンソールでOHSを構成するには、opam.confファイルを次の行で更新します。

NameVirtualHost *:7777
<VirtualHost *:7777>

ServerName http://opam.example.com:7777
ServerAdmin user@example.com
RewriteEngine On
RewriteOptions inherit

<Location /oinav>
SetHandler weblogic-handler
WebLogicCluster opamhost1.example.com:18101,opamhost2.example.com:18101
WLCookieName OPAMSESSIONID
</Location>

</VirtualHost>

12.5.5.3 Oracle HTTP Serverの再起動

Oracle HTTP Serverを再起動するには、ORACLE_INSTANCE/binから次のコマンドを実行します。

opmnctl stopall
opmnctl startall

13 Oracle Identity Navigatorの高可用性の構成

Oracle Identity Navigatorは、Oracle Identity Management製品のスタート地点として機能するよう設計されている管理ポータルです。これは、個々の製品コンソールに代わるものではありません。1つのサイトからOracle Identity Managementの各コンソールにアクセスできるようにするためのものです。Oracle Identity Navigatorの詳細は、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドを参照してください。

Oracle Identity Navigatorは、OPAM管理対象サーバー(opam_server1)にすぐに使用可能な状態でデプロイされます。

Oracle Privileged Account Managerと同じクラスタ化構成内でOracle Identity Navigatorを構成できます。ただし、構成の完了時にopam-config.shスクリプトを実行する必要はありません。

Oracle Identity NavigatorのOHSを構成するには、次の手順を実行します。

- 第13.1項「Oracle HTTP Server構成の更新」

- 第13.2項「Oracle HTTP Serverの再起動」

13.1 Oracle HTTP Server構成の更新

OHSがインストールされているホストで、oinav.confという名前のファイルを次のディレクトリに作成します。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

次の行を指定してファイルを作成します。

NameVirtualHost *:7777
<VirtualHost *:7777>

ServerName http://oinav.example.com:7777
ServerAdmin user@example.com
RewriteEngine On
RewriteOptions inherit

<Location /oinav>
SetHandler weblogic-handler
WebLogicCluster oinavhost1.example.com:18101,oinavhost2.example.com:18101
WLCookieName OPAMSESSIONID
</Location>

</VirtualHost>

13.2 Oracle HTTP Serverの再起動

Oracle HTTP Serverを再起動するには、ORACLE_INSTANCE/binから次のコマンドを実行します。

opmnctl stopall
opmnctl startall

14 Oracle Unified Directory

Oracle Unified Directoryは、大規模なデプロイメントへの対応、優れたパフォーマンスの提供および高い拡張性を実現するために設計された、Oracleの包括的な次世代ディレクトリ・サービスです。Oracle Unified Directoryは、簡単にデプロイ、管理および監視できるような設計にもなっています。

Oracle Unified Directoryの高可用性デプロイメントの詳細は、Oracle Fusion Middleware Oracle Unified Directory管理者ガイドのOracle Unified Directoryの高可用性デプロイメントの理解に関する項を参照してください。

15 Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ

この章では、アクティブ/パッシブ・トポロジを構成して管理する方法について説明します。次の項目が含まれます。

- 第15.1項「Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジの概要」

- 第15.2項「アクティブ/パッシブ・デプロイメントのためのOracle Fusion Middlewareの構成」

- 第15.3項「Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジ例」

- 第15.4項「コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換」

15.1 Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジの概要

Oracle Fusion Middlewareは、Oracle Fusion Middleware Cold Failover Cluster(コールド・フェイルオーバー・クラスタ)を使用して、すべてのコンポーネントにアクティブ/パッシブ・モデルを提供します。コールド・フェイルオーバー・クラスタ構成では、複数の管理対象サーバー・インスタンスが同じアプリケーション・ワークロードを処理するように構成されますが、アクティブになるインスタンスは常に1つのみです。

2つのノードのコールド・フェイルオーバー・クラスタを使用すると、中間層コンポーネントのアクティブ/パッシブ構成の可用性を実現できます。コールド・フェイルオーバー・クラスタでは、1つのノードがアクティブになり、別のノードはスタンバイ・ノードとしてパッシブになります。アクティブ・ノードで障害が発生すると、スタンバイ・ノードがアクティブ化され、中間層コンポーネントはそのノードからクライアント・リクエストの処理を続行します。すべての中間層コンポーネントが新しいアクティブ・ノードにフェイルオーバーします。フェイルオーバー後、障害ノードでは中間層コンポーネントは実行されなくなります。

コールド・フェイルオーバー・クラスタ構成の最も一般的なプロパティは、次のとおりです。

- 共有記憶域: 共有記憶域は、コールド・フェイルオーバー・クラスタにおける主要プロパティです。アクティブ/パッシブ構成におけるOracle Fusion Middlewareパッシブ・インスタンスは、アクティブ・インスタンスと同じように、Oracleバイナリ、構成ファイル、ドメイン・ディレクトリおよびデータにアクセスできます。コールド・フェイルオーバー・クラスタ構成にあるすべての参加ノードでアクセス可能な記憶域にこれらのアーティファクトを配置することで、このアクセスを構成します。通常、アクティブ・ノードでは共有記憶域がマウントされて、パッシブ・ノードではアンマウント状態になりますが、ノードがアクティブになるとこの記憶域にアクセス可能になります。この共有記憶域は、両方のノードでアクセス可能な二重ポート対応ディスク・デバイスにできますし、NASやSANなどのデバイスベース記憶域にもできます。共有記憶域は通常のファイル・システム上にインストールできます。コールド・フェイルオーバー・クラスタの場合、ボリュームをマウントするノードは一度に1つのみです。

- 仮想ホスト名: コールド・フェイルオーバー・クラスタ・ソリューションでは、2つのノードが1つの仮想ホスト名と1つの仮想IPを共有します。(仮想ホスト名と仮想IPは対応するもので、このガイドでは互換的に使用します。)ただし、この仮想IPを使用できるノードは、常に1つのアクティブ・ノードに限定されます。アクティブ・ノードで障害が発生してスタンバイ・ノードがアクティブになると、仮想IPが新しいアクティブ・ノードに移行します。この新しいアクティブ・ノードでは仮想IPによりすべてのリクエストが処理されます。仮想ホスト名により、デプロイメントの単一システム・ビューが実現されます。コールド・フェイルオーバー・クラスタのデプロイメントは、この仮想IP上でリスニングするように構成されます。たとえば、ハードウェア・クラスタの2つの物理ホスト名がnode1.example.comおよびnode2.example.comである場合、名前cfcvip.example.comによって、このクラスタの単一のビューが提供されます。DNSでは、cfcvip.example.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. パッシブ・ノード上で中間層サービスを起動し、アクティブにします。

フェイルオーバーを管理するには、計画スイッチオーバーの手順を手動で実行します(障害の検出およびフェイルオーバーは手動です)。

アクティブ/パッシブ・デプロイメントの場合、通常、サービスが停止する時間は短時間です。これは、同じノード上でインスタンスを再起動するのに要する時間、またはパッシブ・ノードにインスタンスをフェイルオーバーするに要する時間になります。

アクティブ/パッシブ・トポロジ: 長所

- 可用性の向上
アクティブ・インスタンスに障害が発生した場合や、アクティブ・インスタンスをオフラインにする必要がある場合、いつでも同一構成のパッシブ・インスタンスで処理の引継ぎができます。この構成では、通常の単一インスタンス型デプロイメントより可用性のレベルが高くなります。また、アクティブ/パッシブ・デプロイメントは、ハードウェアの計画メンテナンス操作や計画外メンテナンス操作に対して可用性と保護機能を実現します。計画メンテナンスのためにノードを停止する必要がある場合、パッシブ・ノード上のミドルウェア・サービスを起動できます。適切な時点で元のノードへスイッチバックします。

- 運用コストの削減
アクティブ/パッシブ構成では、1つのプロセス・セットのみが稼働して、リクエストを処理します。アクティブ・インスタンスの管理では通常、複数のアクティブ・インスタンスの配列の管理より低コストです。

- コールド・フェイルオーバー・クラスタ・トポロジの実装はそれほど難しくありません。それらのクラスタではロード・バランサが不要ですが、アクティブ/アクティブ・トポロジでは必要になるからです。

- ロード・バランシング・アルゴリズム、クラスタリング、レプリケーションなどのオプションを構成する必要がないため、コールド・フェイルオーバー・クラスタ・トポロジの実装は、アクティブ/アクティブ・トポロジほど難しくありません。

- アクティブ/パッシブ・トポロジでは、アクティブ/アクティブ・トポロジより正確に、1つのインスタンスのトポロジがシミュレートされます。

- アプリケーションの非依存性
一部のアプリケーションは、アクティブ/アクティブ構成に適さない場合があります。このようなアプリケーションには、アプリケーションの状態への依存度が高いアプリケーションや、ローカルに格納された情報への依存度が高いアプリケーションなどあります。シングルトン・アプリケーションには、アクティブ/パッシブ・デプロイメントが適しています。アクティブ/パッシブ構成では、常に1つのインスタンスのみがリクエストを処理します。

アクティブ/パッシブ・トポロジ: 短所

- アクティブ/パッシブ・トポロジは、アクティブ/アクティブ・トポロジほどスケーラビリティが高くありません。ノードをトポロジに追加して処理能力を増強することはできません。

- HTTPセッションの状態およびEJBステートフル・セッションBeanからの状態情報は、レプリケートされないため、ノードが予期せずに終了すると失われます。そのような状態は、データベースまたは共有記憶域にあるファイル・システムに永続的に保持されます。ただし、これは余分なオーバーヘッドを必要とするため、単一ノードのコールド・フェイルオーバー・クラスタ・デプロイメントのパフォーマンスに影響する可能性があります。

- アクティブ/パッシブ・デプロイメントでは、単一ノードのデプロイメントよりも停止時間が短縮されます。ただし、アクティブ/アクティブ・デプロイメントでは、さらに停止時間が短縮されます。

15.2 アクティブ/パッシブ・デプロイメントのためのOracle Fusion Middlewareの構成

Oracle Fusion Middlewareコンポーネントには、様々な種類の、Java EEコンテナにデプロイされたコンポーネントと非Java EEコンポーネントがあります。Oracle Internet Directory、Oracle Virtual DirectoryおよびOracle Reportsはシステム・コンポーネントです。Oracle SOA SuiteやOracle WebCenter Portalは、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デプロイメント)を変換します。

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

- 第15.2.1項「コールド・フェイルオーバー・クラスタの要件」

- 第15.2.2項「ディレクトリおよび環境変数の用語」

- 第15.2.3項「Oracle Fusion Middlewareインフラストラクチャ・コンポーネントの変換」

- 第15.2.4項「Oracle Fusion Middlewareコンポーネントの変換」

- 第15.2.5項「Fusion Middlewareフェイルオーバーの追加のアクション」

- 第15.2.6項「Oracle Databaseの変換」

15.2.1 コールド・フェイルオーバー・クラスタの要件

コールド・フェイルオーバー・クラスタのデプロイには、2つ以上のノードを使用します。これらのノードの1つにインストールを行い、もう一方のノードはパッシブ・ノードとなります。両方のノードの要件は、次のとおりです。

- 各ノードはオペレーティング・システム・レベルのあらゆる面で同じである必要があります。たとえば、オペレーティング・システム、バージョンおよびパッチ・レベルが同一である必要があります。

- 各ノードはハードウェアの特性が同じである必要があります。それによって、通常の運用中とフェイルオーバー時のパフォーマンスが予測可能になります。通常の役割を処理できる処理能力に加えて、フェイルオーバー・シナリオに対応するために対応が必要な負荷が増大しても処理できるように、各ノードを設計することをお薦めします。停止シナリオ中におけるパフォーマンスの低下がサービス・レベル合意(SLA)で許容される場合のみ、その必要はありません。

- 通常の運用中とフェイルオーバー時のどちらでも同じノードに対して共有記憶域をマウントできるように、各ノードで同じマウント・ポイントが解放されている必要があります。

- 2つのノードのユーザーIDとグループIDが類似しており、インスタンスを所有するユーザーのユーザーIDとグループIDが両方のノードで同じである必要があります。

- oraInventoryの場所が両方のノードで同じであり、インスタンスまたはドメインの所有者のアクセス・レベルが類似している必要があります。oraInst.locファイルの場所だけでなくbeahomelistファイルの場所も同じである必要があります。

- 指定インスタンスでは、現在アクティブになっているマシンには関係なく、同じリスニング・ポートを使用するため、コールド・フェイルオーバー・クラスタのインスタンスで使用するポートが両方のノードで解放されていることを確認します。

注意:

変換を開始する前に、ドメイン全体のバックアップを実行してください。また、ソース・ファイルの編集前にローカル・バックアップ・ファイルを作成することをお薦めします。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。次のバックアップを作成することをお薦めします。

- すべてのドメイン・ディレクトリ

- すべてのインスタンス・ホーム

- データベース・リポジトリ(オプション)

- Middlewareホーム(オプション)

15.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 Fusion Middlewareコンポーネントで使用されるOracleホーム、ドメイン・ホーム、およびドメイン・ディレクトリの値の例を示します。

コンポーネント

ORACLE_HOME

DOMAIN_HOME

ドメイン・ディレクトリ

Identity Management

MW_HOME/idm

IDMDomain

MW_HOME/user_projects/domains/IDMDomain

Oracle SOA

MW_HOME/soa

SOADomain

MW_HOME/user_projects/domains/SOADomain

WebCenter

MW_HOME/wc

WCDomain

MW_HOME/user_projects/domains/WCDomain

WebCenter Content

MW_HOME/wcc

WCCDomain

MW_HOME/user_projects/domains/WCCDomain

Oracle Portal

MW_HOME/portal

PortalDomain

MW_HOME/user_projects/domains/PortalDomain

Oracle Forms

MW_HOME/forms

FormsDomain

MW_HOME/user_projects/domains/FormsDomain

Oracle Reports

MW_HOME/reports

ReportsDomain

MW_HOME/user_projects/domains/ReportsDomain

Oracle Discoverer

MW_HOME/disco

DiscoDomain

MW_HOME/user_projects/domains/DiscoDomain

Web層

MW_HOME/web

適用なし

適用なし

ディレクトリ層

MW_HOME/idm

適用なし

適用なし

アプリケーション・ディレクトリの場所の例: ORACLE_BASE/admin/domain_name/apps

Oracleインスタンスの場所の例: ORACLE_BASE/admin/instance_name

共有記憶域のマウント・ポイントにはORACLE_BASEをお薦めします。多くの場合、この場所に、フェイルオーバー・ユニットのすべての永続ビットが同じ共有記憶域に格納されることになります。1つのノードに複数のコールド・フェイルオーバー・クラスタが存在する場合に、それぞれが独立してフェイルオーバーすると、フェイルオーバー・ユニットのそれぞれに対して異なるマウント・ポイントが存在します。

15.2.3 Oracle Fusion Middlewareインフラストラクチャ・コンポーネントの変換

Oracle Fusion Middlewareデプロイメントは、すべての製品セットに共通する基本インフラストラクチャ・コンポーネントで構成されます。この項では、これらのコンポーネントのコールド・フェイルオーバー・クラスタ変換手順について説明します。

コールド・フェイルオーバー・クラスタ構成では、2つの管理サーバー・トロポジがサポートされています。次の各項では、これら2つのトポロジについて説明します。また、コールド・フェイルオーバー・クラスタ変換用に管理サーバーを準備するためにインストールと構成を行う手順についても説明します。

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

- 第15.2.3.1項「管理サーバーのトポロジ1」

- 第15.2.3.2項「トポロジ1のインストール手順」

- 第15.2.3.3項「管理サーバーのトポロジ2」

- 第15.2.3.4項「トポロジ2のインストール手順」

- 第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」

- 第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」

- 第15.2.3.7項「ノード・マネージャの変換」

- 第15.2.3.8項「Oracle Process Management and Notification Serverの変換」

- 第15.2.3.9項「OracleインスタンスのOracle Enterprise Managerの変換」

- 第15.2.3.10項「Web層のコンポーネントとクライアントの変換」

15.2.3.1 管理サーバーのトポロジ1

図15-1は、Oracle Cold Failover Clusterにおける最初のサポート対象トポロジを示しています。

図15-1 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ1

図15-1では、管理サーバーは、ノード1とノード2という2つのノードで構成されているハードウェア・クラスタで稼働します。管理サーバーは、仮想IPまたはホスト名でリスニングします。Middlewareホームとドメイン・ディレクトリは、ある時点でノード1またはノード2にマウントされている共有ディスク上にあります。Middlewareホームとドメイン・ディレクトリは両方とも、同じ共有ディスク上、またはいっしょにフェイルオーバーできる複数の共有ディスク上にあります。複数のアプリケーションまたは環境用に複数のFusion Middlewareドメインがある企業では、管理サーバーの高可用性にはこのトポロジが最適です。1つのハードウェア・クラスタをデプロイすると、これら複数の管理サーバーをホストできます。それぞれの管理サーバーでは、その仮想IPおよび一連の共有ディスクを使用して、ドメイン・サービスの高可用性を実現できます。

15.2.3.2 トポロジ1のインストール手順

このトロポジの管理対象サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。

Middlewareホームのインストール

このインストールには、共有ディスク上におけるOracleホーム、WebLogicホームおよびドメイン・ホームが含まれます。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。ストレージ・サブシステムにおいて複数のノードでの同時マウントが可能な場合でも、これが推奨構成になります。これは、通常の単一インスタンス型インストールとして実行されます。管理サーバー(およびEnterprise Manager)の単体インストールの詳細は、当該コンポーネントに関連する章を参照してください。各スイートの全体的な手順は次のとおりです。

管理サーバーのみ:

1. WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

2. 構成ウィザードを起動して、管理サーバーのみのドメインを作成します。
「ドメイン・ソースの選択」画面で、次を選択します。

- 以下の製品をサポートするために、自動的に構成されたドメインを生成する

- 「Enterprise Manager」と「Oracle JRF」を選択します。

For Oracle SOA、Oracle WebCenter PortalまたはOracle WebCenter Contentの場合:

1. WebLogic Serverソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

2. Oracle SOA、Oracle WebCenter PortalまたはOracle WebCenter ContentのOracleホームをインストールします。
Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』または『Oracle WebCenter Contentインストレーション・ガイド』を参照してください。

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をプロビジョニングします。

/sbin/ifconfig interface:index IP_Address netmask netmask
/sbin/arping -q -U -c 3 -I interface IP_Address

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIP_addressが有効化されます。

/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

2. 第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。

3. 仮想IP上のコンソールにアクセスすることで、管理サーバーの変換を検証します。この仮想IPアドレスは、新規IPアドレスです。この仮想IPアドレスのみを使用することをお薦めします。
http://cfcvip.example.com:7001/console

http://cfcvip.example.com:7001/em

4. 次の手順に従って、管理サーバーを2番目のノードに手動でフェイルオーバーさせます。

注意:

管理サーバーがノード・マネージャによって管理されている場合は、コールド・フェイルオーバー・クラスタのノードマネージャを有効にする必要があります。

1. 管理サーバー・プロセス(および指定されているMiddlewareホームの外部で実行されているその他のプロセス)を停止します。

2. Middlewareホームとドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。

3. 記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。

4. rootユーザーとして次のコマンドを使用して、ノード1で仮想IPを無効化します。

/sbin/ifconfig interface:index down

次の例では、eth0インタフェースで仮想IP_Addressが無効化されます。

/sbin/ifconfig eth0:1 down

5. ステップ1と同じコマンドを使用して、ノード2で仮想IPを有効化します。

6. 管理サーバー・プロセスを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。

7. 管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。

15.2.3.3 管理サーバーのトポロジ2

図15-2は、Oracle Cold Failover Clusterにおける2番目のサポート対象管理サーバー・トポロジを示しています。

図15-2 管理サーバーのコールド・フェイルオーバー・クラスタ・トポロジ2

図15-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 Portal Suiteに対してのみサポートされています。

注意:

Oracle Identity Managementについては、コールド・フェイルオーバー・クラスタのための代替トポロジもサポートされています。詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

15.2.3.4 トポロジ2のインストール手順

このトロポジの管理サーバーのコールド・フェイルオーバー・クラスタをインストールおよび構成する手順は次のとおりです。

Middlewareホームのインストール

OracleホームとWebLogicホームを含むMiddlewareホームを、ドメインにある2つのノードに個別にインストールします。管理サーバー・ドメイン・ディレクトリは共有ディスク上に作成します。管理サーバー用のフェイルオーバー先として動作するすべてのノードによりこのディスクがマウントできる必要があります。使用されているストレージ・サブシステムによっては、共有ディスクは一度に1つのノードのみマウントできる場合があります。これは、通常の単一インスタンス型インストールです。管理サーバーおよびEnterprise Managerの単体インストールの詳細は、製品スイートを参照してください。

Oracle SOA Suite、Oracle WebCenter PortalまたはOracle WebCenter Contentの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をプロビジョニングします。例:

/sbin/ifconfig eth0:1 IP_Address netmask netmask
/sbin/arping -q -U -c 3 -I eth0 IP_Address

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。次の例では、eth0インタフェースでIP_Addressが有効化されます。

/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

2. 第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」の手順に従って、管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。

3. 仮想IP上でコンソールにアクセスして、管理サーバーを検証します。
http://cfcvip.example.com:7001/console

http://cfcvip.example.com:7001/em

4. 管理サーバーを2番目のノードに手動でフェイルオーバーさせます。

1. 管理サーバー・プロセス、および指定されているMiddlewareホームの外部で実行されているその他のプロセスを停止します。

2. Middlewareホームまたはドメイン・ディレクトリが存在するノード1から共有記憶域をアンマウントします。

3. 記憶域固有のコマンドを使用して、ノード2に共有記憶域をマウントします。

4. ノード1で仮想IPを無効化します。

/sbin/ifconfig interface:index down

次の例では、eth0インタフェースでIP_Addressが無効化されます。

/sbin/ifconfig eth0:1 down

5. ノード2で仮想IPを有効化します。

6. 次のコマンドを使用して、管理サーバー・プロセスを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

DOMAIN_HOMEは、ドメイン・ディレクトリの場所を示します。

7. 管理サーバーとEnterprise Managerコンソールの両方へのアクセスを検証します。

15.2.3.5 コールド・フェイルオーバー・クラスタ用の管理サーバーの変換

共有ディスクにインストールされている管理サーバーをノード1から変換するには、この項の手順に従ってください。この手順ではコンテナを変換するため、管理コンソールとOracle Enterprise Manager Fusion Middleware Controlの両方がコールド・フェイルオーバー・クラスタ用に変換されます。それにより、このコンテナにデプロイされるOWSM-PMなどの他のコンポーネントも、コールド・フェイルオーバー・クラスタ対応になります。これらすべてのサービスのアドレスがcfcvip.example.comに変換されます。インストール後、コールド・フェイルオーバー・クラスタでないインスタンスをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。

1. 管理コンソールにログインします。

2. 仮想ホストのマシンを作成します。

1. 「環境」、「マシン」の順に選択します。

2. 「チェンジ・センター」で、「ロックして編集」、「新規」の順にクリックします。

3. 「名前」フィールドにcfcvip.example.comと入力します。

4. 「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。

5. 「次」、「終了」の順にクリックします。

注意:

「リスニング・アドレス」フィールドはlocalhostに設定したままにします(CFCソリューションはこの設定に依存します)。これを仮想IP_Addressまたはその他の値に変更しないでください。

6. 「マシンのサマリー」タブで、作成したばかりのマシンの名前をクリックします。

7. 「サーバー」タブをクリックしてから、「追加」をクリックします。

8. サーバー選択のドロップダウン・リストで、「AdminServer」が選択されていることを確認します。

9. 「終了」をクリックします。

10. 「変更のアクティブ化」をクリックします。

3. cfcvip.example.com上でリスニングするように管理サーバーを構成します。

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 管理サーバー(AdminServer)をクリックします。

4. リスニング・アドレスをcfcvip.example.comに変更します。

5. 「保存」をクリックします。

6. 「変更のアクティブ化」をクリックします。

7. 管理サーバーを再起動します。

注意:

通常、管理サーバーのコールド・フェイルオーバー・クラスタへの変換はドメイン作成時に実行されることが期待されるため、ドメインにおいて他の部分への変更は行われないものと考えられます。この変更がドメイン作成後に行われ、他のコンポーネントがドメインにインストールされている場合、次の管理サーバー変換項で説明している手順に従ってください。

管理サーバーのクライアント側構成の変更

ドメインにある既存エンティティでは、管理サーバーとの通信に新しいアドレスを使用する必要があります。たとえば、管理対象サーバーを手動で起動する際は、管理サーバーのアドレスをcfcvip.example.comとして指定します。

ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるinstance.propertiesファイルで、次の変更を行います。

adminHost=cfcvip.example.com

OPMN登録コマンドを使用して、コールド・フェイルオーバー・クラスタ管理サーバーにOracleインスタンスを登録したり再登録する場合は、opmnctlコマンドのAdminHostの場所で管理サーバーの新しい場所(cfcvip.example.com)を参照します。

Oracle Enterprise Managerのクライアント側構成の変更

Enterprise Managerは管理サーバーが稼働する同じコンテナの一部であるため、管理サーバーをコールド・フェイルオーバー・クラスタに変換すると、Enterprise Managerも変換されます。ドメインの一部として構成されたEnterprise Managerエージェントが存在する場合は、それらのエージェント構成でEnterprise Managerの新しい場所を使用する必要があります。Enterprise Managerの新しい場所を構成するには、エージェントごとに次の手順を行います。

1. ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/configに設定します。

2. emd.propertiesファイルで、次の属性内のnode1.example.comをcfcvip.example.comに変更します。

- REPOSITORY_URL

- emdWalletSrcUrl

3. 次のコマンドを使用して、エージェントを停止してから再起動します。

cd ORACLE_INSTANCE/EMAGENT/emagent_dir/bin
./emctl stop agent
./emctl start agent
./emctl status agent

これによってリポジトリのURLが表示されます。このURLは新しいホストを指します。

15.2.3.6 Oracle WebLogic管理対象サーバーの変換

すべてのOracle Fusion Middlewareコンポーネントは、管理対象サーバーにデプロイされます。Oracle WebLogic Serverにデプロイされたアプリケーションやコンポーネントをコールド・フェイルオーバー・クラスタに変換する際の重要な手順としては、使用する仮想IPにリスニング・アドレスを変更することがあります。この変更は、対象のコンポーネントがデプロイされている特定の管理対象サーバーに対して実行します。この変更には、管理コンソールまたはWLSTコマンドを使用できます。

次の例では、WLS_EXMPLという管理対象サーバーをコールド・フェイルオーバー・クラスタに変換する一般的手順について説明します。これらの手順は、Fusion Middlewareコンポーネントの管理対象サーバーに適用されます。

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

- 第15.2.3.6.1項「Fusion Middleware管理コンソールによるOracle WebLogic Managed Serverの変換」

- 第15.2.3.6.2項「WLSTコマンド行によるOracle WebLogic管理対象サーバーの変換」

15.2.3.6.1 Fusion Middleware管理コンソールによるOracle WebLogic管理対象サーバーの変換

次の手順で、cfcvip.example.comはコールド・フェイルオーバー・クラスタに使用する仮想IPで、WLS_EXMPLは変換対象となる管理対象サーバーです。

1. 管理コンソールにログインします。

2. 仮想ホストのマシンを作成します。

1. 「環境」→「マシン」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックし「新規」をクリックします。

注意:

管理サーバーの変換で別のVIPを使用した場合にのみ、新しいマシンを作成します。その場合、手順gに進みます。

3. 「名前」フィールドでは、cfcvip.example.comと入力します。

4. 「マシンのOS」フィールドで、適切なオペレーティング・システムを選択します。

5. 「Next」をクリックして、「Finish」をクリックします。
ノード・マネージャを変換する場合は、次の手順を実行する必要があります。

6. 新しく作成したマシンをクリックします。

7. 「ノード・マネージャ」タブをクリックします。

8. リスニング・アドレスをcfcvip.example.comに更新します。

9. 「保存」をクリックします。

10. 「変更のアクティブ化」をクリックします。

11. 第15.2.3.7項「ノード・マネージャの変換」の手順を完了します。

3. WLS_EXMPL管理対象サーバーを停止します。

1. 「環境」→「サーバー」を選択します。

2. 「制御」をクリックします。

3. 「WLS_EXMPL」を選択します。

4. 「停止」ドロップダウン・メニューで、「ただちに強制停止」を選択します。

4. WLS_EXMPL管理対象サーバーを仮想ホストのマシンに関連付けます。

1. 「環境」→「サーバー」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 「構成」をクリックします。

4. 「WLS_EXMPL」を選択します。

5. 「マシン」では、プルダウン・メニューから新規作成マシンを選択して割り当てます。

6. 「リスニング・アドレス」にcfcvip.example.comと入力します。

7. 「保存」をクリックします。

8. 「変更のアクティブ化」をクリックします。

5. 管理対象サーバーWLS_EXMPLを起動します。

注意:

サーバー・インスタンスを起動および停止する方法は数種類あります。以前にサーバー・インスタンスを起動および停止した方法を使用してください。

15.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://cfcvip.example.com:7001')

wls:/DomainName/serverConfig> edit()
wls:/DomainName/edit> startEdit()
wls:/DomainName/edit !> create('cfcvip.example.com','Machine')
wls:/DomainName/edit !> cd('Machines/cfcvip.example.com/NodeManager/cfcvip.example.com')
wls:/DomainName/edit !> set('ListenAddress', 'cfcvip.example.com')
wls:/DomainName/edit !>cd ('Servers')
wls:/DomainName/edit/Servers !>cd ('WLS_EXMPL')
wls:/DomainName/edit/Servers/WLS_EXMPL !>set('Machine',' cfcvip.example.com ')
wls:/DomainName/edit/Servers/WLS_EXMPL !>set('ListenAddress',' cfcvip.example.com ')
wls:/DomainName/edit/Servers/WLS_EXMPL !> save()
wls:/DomainName/edit/Servers/WLS_EXMPL !> activate()
wls:/DomainName/edit/Servers/WLS_EXMPL> exit()

3. 管理対象サーバーを停止してから(停止していない場合)、再起動します。

管理対象サーバーの変換の完了後に、このサーバーに対するすべての参照で新しいリスニング・アドレスcfcvip.example.comが使用されていることを確認します。Oracle HTTP Serverがこの管理対象サーバーのフロントエンドとして機能している場合、この管理対象サーバー上のアプリケーションを参照しているマウント・ポイントでmod_wls_ohs構成をすべて変更して、新しいリスニング・エンド・ポイントにルーティングします。

注意:

Oracle FMW SOAサーバーを既存またはデプロイされているコンポジットを使用して変換する場合は、以前のサーバーのリスニング・アドレスが表示される可能性のある場所がいくつかあります。OHSまたはLBRがサーバーのフロントエンドとなる場合、参照は、サーバーのリスニング・アドレスを反映しないため変更されません。

- デプロイされたコンポジットには、特定のエンドポイント参照が含まれる場合があります。たとえば、特定の参照用のバインド・プロパティとして指定されたcallbackServerURLが使用される場合があります。これらの参照は、新しいサーバーのVIPに更新する必要があります。

- Enterprise Manager内のsoa-infraアプリケーションに指定されたSOAプロパティのコンポジット・リレー。ServerURLおよびCAllBackURLがデフォルトのNull値から変更されている場合は、これらを更新する必要があります。

- システムはサーバー・レベルで設定されたフロントエンド・アドレスを使用します。したがって、新しいVIPを反映するように更新する必要があります。

15.2.3.7 ノード・マネージャの変換

コールド・フェイルオーバー・クラスタ環境ではノード・マネージャを使用できます。コールド・フェイルオーバー・クラスタ・スタックの残りの部分とともにフェイルオーバーしないノード・マネージャ。この場合、ノード・マネージャはコールド・フェイルオーバー・クラスタ用に構成されずに、コールド・フェイルオーバー・クラスタの仮想IPだけでなく、マシン上のすべてのIPをリスニングします。また、フェイルオーバー・ノードには、同様に構成されているノード・マネージャが配置され、構成済になっています。WebLogicインスタンスに関連付けられたノードは、ローカル・ホスト上のノード・マネージャと通信します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』を参照してください。

一般的にコールド・フェイルオーバー・クラスタの場合、フェイルオーバー発生時にポートが競合しないように、ポートの使用を計画する必要があります。

ノード・マネージャをコールド・フェイルオーバー・クラスタに変換する手順は次のとおりです。

1. ノード・マネージャが実行されている場合は停止します。
ノード・マネージャが最初に起動された後にのみ、nodemanager.propertiesファイルは作成されます。

必要に応じて、ノード・マネージャを再起動します。

2. WL_HOME/common/nodemanager/ディレクトリにあるnodemanager.propertiesファイルで、ListenAddressを仮想IPに設定します。
例:

ListenAddress=cfcvip.example.com

3. WL_HOME/server/binディレクトリにあるstartNodeManager.shファイルを使用して、ノード・マネージャを再起動します。

注意:

WebLogic管理対象サーバーおよび管理サーバーでは、ホスト名の検証は特定のインストールで有効化または無効化できます。検証が有効でノード・マネージャがこれらのインスタンスを管理しているCFCインストールでは、ホスト名の検証の手順の中で仮想IPのcfcvip.example.comの証明書を使用する必要があります。

15.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.example.comに変更します。
たとえば、Oracle HTTP Serverインスタンスをコールド・フェイルオーバー・クラスタに変換するには、topology.xmlファイルで次のように設定します。

<property name="HTTPMachine" value="cfcvip.example.com"/>

インスタンス自体:

<ias-instance id="asinst " instance-home="/11gas3/MW/asinst" host="cfcvip.example.com" port="6701">

2. ORACLE_INSTANCE/config/OPMN/opmnディレクトリのinstance.propertiesファイルで、adminHost=<physical hostname>をadminHost=<cfcvip.example.com>に置き換えます。

3. すべてのOPMNコンポーネントを再起動します。

15.2.3.9 OracleインスタンスのOracle Enterprise Managerの変換

Oracleインスタンスをコールド・フェイルオーバー・クラスタに変換する場合は、そのOracleインスタンスの一部であるEnterprise Managerエージェントもコールド・フェイルオーバー・クラスタに変換する必要があります。このトピックでは、エージェントおよびサーバーを変換する方法について説明します。

Enterprise Managerエージェントを変換する手順は次のとおりです。

1. 次のコマンドを使用して、Enterprise Managerエージェントを停止します。

cd ORACLE_INSTANCE/EMAGENT/emagent_dir/bin
./emctl stop agent

2. ディレクトリをORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/configに設定します。

3. マネージドBeanを使用し、それに対する操作を設定して、物理ホスト名を仮想ホスト名に置換します。例: emoms.props:Location=AdminServer,name=emoms.properties,type=Properties,Application=em
属性ごとにこの操作を行うには、次の手順を実行します。

1. Enterprise Manager (http://cfcvip.example.com:7001/em)にログインします。

注意:

この手順では、仮想ホスト名cfcvip.example.comでリスニングするために、管理サーバーのリスニング・アドレスを変換しているものと仮定します。詳細は、第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。

2. 「WebLogicドメイン」を展開します。

3. ドメイン名を右クリックして、「システムMBeanブラウザ」を選択します。

4. 検索アイコン(双眼鏡)を選択します。enoms.props:Locationを入力して、マネージドBeanを表示します。

5. 「属性」タブを選択します。

6. 「プロパティ」を選択します。ホスト名は、要素のリスト内にあります。例:

+Element_ElementNumber
key example.sysman.emSDK.svlt.ConsoleServerName
value hostname.example.com:7001_Management_Service

+Element_ElementNumber
key example.sysman.emSDK.svlt.ConsoleServerHost
value hostname.example.com

7. 「操作」タブを選択してから、「SetProperty」リンクを選択します。

8. キー名と新しい値を入力します。「起動」を選択します。

4. emd.propertiesファイルで、EMD_URL属性のnode1.example.comをcfcvip.example.comに変更します。

5. エージェント側のtargets.xmlファイルを変更します。

cd ORACLE_INSTANCE/EMAGENT/emagent_dir/sysman/emd
cp targets.xml targets.xml.org

ホストとoracle_emdに関連付けられたターゲットのみが含まれるように、targets.xmlを変更します。他のエントリはすべて削除します。例:

<Targets AGENT_TOKEN="ad4e5899e7341bfe8c36ac4459a4d569ddbf03bc">
<Target TYPE="oracle_emd" NAME="cfcvip.example.com:port"/>
<Target TYPE="host" NAME="cfcvip.example.com"  DISPLAY_NAME="cfcvip.example.com/>"
</Targets>

6. エージェントを再起動します。

cd ORACLE_INSTANCE/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.example.comからcfcvip.example.comに変更します。

3. 管理サーバーを再起動します。

15.2.3.10 Web層のコンポーネントとクライアントの変換

Web層は、2つの主要コンポーネントであるOracle HTTP ServerとOracle Web Cacheで構成されます。次の2つの項では、Oracle HTTP ServerとOracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する方法について説明します。

15.2.3.10.1 Oracle HTTP Serverの変換

Oracle HTTP Serverをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。

1. ORACLE_INSTANCE/config/OHS/component_name/httpd.confで、次の属性を変更します。

Listen cfcvip.example.com:port #OHS_LISTEN_PORT
Listen cfcvip.example.com:port #OHS_PROXY_PORT
ServerName cfcvip.example.com

2. ORACLE_INSTANCE/config/OHS/component_name/admin.confで、次の属性を変更します。

Listen cfcvip.example.com:port #OHS_LISTEN_PORT
Listen cfcvip.example.com:port #OHS_ADMINISTRATOR_PORT
ServerName cfcvip.example.com

3. Oracle HTTP Serverを再起動します。

.cd ORACLE_INSTANCE/bin
./opmnctl restartproc process-type=OHS

また、第15.2.4.7項「シングル・サインオンの再登録(必要な場合)」で説明されているシングル・サインオンの登録も実行します。

Oracle HTTP Serverのクライアント

コールド・フェイルオーバー・クラスタに変換したOracle HTTP ServerにOracle Web Cacheインスタンスがルーティングされる場合は、ORACLE_INSTANCE/config/WebCache/component_name/webcache.xmlで次の属性を変更します。

node1.example.comをcfcvip.example.comに変更します(node1.example.comは変換前のOracle HTTP Serverのアドレスです)。

<HOST ID="h1" NAME="cfcvip.example.com" PORT="8888" LOADLIMIT="100"
OSSTATE="ON"/>
<HOST ID="h2" NAME="cfcvip.example.com" PORT="8890" LOADLIMIT="100" OSSTATE="ON"
SSLENABLED="SSL"/>

15.2.3.10.2 Oracle Web Cacheの変換

Oracle Web Cacheをコールド・フェイルオーバー・クラスタ用に変換する手順は次のとおりです。

1. クラスタの両方のノードにある/etc/hostsで、物理ホスト名に別名を設定します。
これはノードのIP_Addressの別名です。/etc/hosts内で設定します。この別名は、wcprfx.example.comです。たとえば、ノード1では、/etc/hostsファイルのエントリはn.n.n.n node1 node1.example.com wcprfx wcprfx.example.comになります。

フェイルオーバー・ノードのノード2では、/etc/hostsファイルのエントリはn.n.n.m node2 node2.example.com wcprfx wcprfx.example.comになります。

2. ORACLE_INSTANCE/config/WebCache/component_name/webcache.xmlで次を実行します。

- node1.example.comをcfcvip.example.comに変更します(node1.example.comはOracle Web Cacheがインストールされている場所であり、変換前にリスニング対象となるホスト・アドレスです)。

SITE NAME="cfcvip.example.com"

- SSLポートと非SSLポートで仮想ホスト名のエントリをcfcvip.example.comに変更します。例:

<HOST SSLENABLED="NONE" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8888"
NAME="cfcvip.example.com" ID="h0"/>
<HOST SSLENABLED="SSL" ISPROXY="NO" OSSTATE="ON" NUMRETRY="5"
PINGINTERVAL="10" PINGURL="/" LOADLIMIT="100" PORT="8890"
NAME="cfcvip.example.com" ID="h3"/>
<VIRTUALHOSTMAP PORT="8094" NAME="cfcvip.example.com">
<HOSTREF HOSTID="h3"/>
</VIRTUALHOSTMAP>
<VIRTUALHOSTMAP PORT="8090" NAME="cfcvip.example.com">
<HOSTREF HOSTID="h0"/>
</VIRTUALHOSTMAP>

- wcprfx.example.comに基づくように、キャッシュ名エントリを変更します(wcprfx.example.comは、クラスタにあるすべてのノードの/etc/hostsで作成された別名です)。例:

<CACHE WCDEBUGON="NO" CAPACITY="30" VOTES="1" INSTANCENAME="asinst_1"
COMPONENTNAME="wc1" ORACLEINSTANCE="ORACLE_INSTANCE"
HOSTNAME="wcprfx.example.com" ORACLEHOME="ORACLE_HOME"
NAME="wcprfx.example.com-WebCache">

- MULTIPORTセクションで、次の構成のIPADDRをANYからcfcvip.example.comに変更します。

PORTTYPE="NORM"
SSLENABLED="SSL" PORTTYPE="NORM"
PORTTYPE="ADMINISTRATION"
PORTTYPE="INVALIDATION"
PORTTYPE="STATISTICS"

例:

<MULTIPORT>
<LISTEN PORTTYPE="NORM" PORT="8090"
IPADDR="cfcvip.example.com"/>
<LISTEN SSLENABLED="SSL" PORTTYPE="NORM" PORT="8094"
IPADDR="cfcvip.example.com">
<WALLET>ORACLE_INSTANCE/config/WebCache/wc1/keystores/
default</WALLET>
</LISTEN>
<LISTEN PORTTYPE="ADMINISTRATION" PORT="8091"
IPADDR="cfcvip.example.com"/>
<LISTEN PORTTYPE="INVALIDATION" PORT="8093" IPADDR="
cfcvip.example.com"/>
<LISTEN PORTTYPE="STATISTICS" PORT="8092"
IPADDR="cfcvip.example.com"/>
</MULTIPORT>

3. Oracle Web Cacheを再起動します。

cd ORACLE_INSTANCE/bin
./opmnctl restartproc process-type=WebCache

15.2.4 Oracle Fusion Middlewareコンポーネントの変換

この項では、次のFusion Middlewareコンポーネントについて説明します。

- 第15.2.4.1項「Oracle Virtual Directoryおよびそのクライアントの変換」

- 第15.2.4.2項「Oracle Directory Integration PlatformおよびOracle Directory Services Managerとそれぞれのクライアントの変換」

- 第15.2.4.3項「Oracle Identity Federationおよびそのクライアントの変換」

- 第15.2.4.4項「Oracle Access Managerおよびそのクライアントの変換」

- 第15.2.4.5項「Oracle Adaptive Access Managerおよびそのクライアントの変換」

- 第15.2.4.6項「Oracle Identity Managerおよびそのクライアントの変換」

- 第15.2.4.7項「シングル・サインオンの再登録(必要な場合)」

製品コンポーネントの詳細は、このガイドで適切なコンポーネントに関連する章を参照してください。

15.2.4.1 Oracle Virtual Directoryおよびそのクライアントの変換

この項では、Oracle Virtual Directoryとそのクライアントを変換する方法について説明します。次の項目が含まれます。

- 第15.2.4.1.1項「Oracle Virtual Directoryの変換」

- 第15.2.4.1.2項「キーストアの新しい鍵の生成」

- 第15.2.4.1.3項「Oracle Virtual Directoryクライアントの変換」

15.2.4.1.1 Oracle Virtual Directoryの変換

Oracle Virtual Directoryサーバーを変換する手順は次のとおりです。

1. テキスト・エディタで、ORACLE_INSTANCE/config/OVD/componentnameディレクトリにあるlisteners.os_xmlファイルを開きます。

2. 次の値を入力し、LDAPアドレスを仮想IPに設定します。

<host>cfcvip.example.com</host>

3. opmnctlを使用して、Oracle Virtual Directoryサーバーを再起動します。
例:

ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1

15.2.4.1.2 キーストアの新しい鍵の生成

管理者は、(自己署名またはCAによって署名された)仮想ホスト名を使用して新規鍵ペアを生成し、この証明書をOVDリスナー構成で関連付ける必要があります。この証明書は、EMAgentによって信頼される必要があり、これに対して信頼できる証明書としてEMAgentのcwallet.ssoにインポートする必要があります。

詳細は、第8.3.5.2項「WLSTを使用したキーストアの新しい鍵の生成」を参照してください。

管理ゲートウェイ・リスナーまたはLDAP SSLエンドポイント・リスナーで異なるキーストアを選択するか、キーストアの証明書を変更する場合は、Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに証明書をインポートする必要があります。証明書をインポートしない場合、Oracle Enterprise Manager Fusion Middleware ControlはOracle Virtual Directoryに接続してパフォーマンス・メトリックを取得することができません。

Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに証明書をインポートする手順:

1. 次のコマンドを実行して、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

2. 次のコマンドを実行して、Oracle Virtual Directoryサーバーの証明書を、Oracle Enterprise Manager Fusion Middleware Controlエージェントのウォレットに追加します。

ORACLE_COMMON_HOME/bin/orapki wallet add -wallet \
$ORACLE_INSTANCE/EMAGENT/EMAGENT/sysman/config/monwallet \
-trusted_cert -cert OVD_SERVER_CERT_FILE -pwd WALLET_PASSWORD

15.2.4.1.3 Oracle Virtual Directoryクライアントの変換

Oracle Virtual Directoryのすべてのクライアントは、仮想IPのcfcvip.example.comを使用して、Oracle Virtual Directoryにアクセスする必要があります。たとえば、Oracle Directory Services Managerを使用してコールド・フェイルオーバー・クラスタのOracle Virtual Directoryインスタンスを管理する場合は、Oracle Virtual Directoryインスタンスの場所としてcfcvip.example.comを使用して接続を作成します。

15.2.4.2 Oracle Directory Integration PlatformおよびOracle Directory Services Managerとそれぞれのクライアントの変換

この項では、Oracle Directory Integration Platform、Oracle Directory Services Managerおよびそれぞれのクライアントを変換する方法について説明します。

15.2.4.2.1 Oracle Directory Integration PlatformとOracle Directory Services Managerの変換

Oracle Directory Integration PlatformとOracle Directory Services Managerは管理対象サーバーにデプロイされます。CFC変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_ODS管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。

15.2.4.2.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.example.comを使用してこれらのアプリケーションにアクセスする必要があります。

2. Oracle HTTP ServerがOracle Directory Services Managerのフロントエンドである場合、Oracle Directory Services Managerに関するWebLogic構成では、WLS_ODS管理対象サーバーのアドレスとして仮想IPのcfcvip.example.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.example.com
WebLogic port
</Location>

15.2.4.3 Oracle Identity Federationおよびそのクライアントの変換

この項では、Oracle Identity Federationとそのクライアントを変換する方法について説明します。

15.2.4.3.1 Oracle Identity Federationの変換

Oracle Identity Federationは、管理サーバーにデプロイされるコンポーネントです。コールド・フェイルオーバー・クラスタ変換の手順では、デプロイ先の管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OIF管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。Oracle Identity Federationコールド・フェイルオーバー・クラスタ・デプロイメントは通常、サービス・プロバイダとアイデンティティ・プロバイダに分割されるため、特定のデプロイメントに複数のWLS_OIFインスタンスが存在する場合があります。どちらのWLS_OIFインスタンスに対しても、同じコールド・フェイルオーバー・クラスタ手順を適用してください。

cfcvip.example.comの仮想IP上でリスニングするように管理対象サーバーを構成した後、Oracle Enterprise Manager Fusion Middleware Controlにログインして、次の手順を実行します。

1. 「ファーム」→「Identity and Access」→OIFに移動します。

2. 右側のフレームで、「Oracle Identity Federation」→「管理」に移動し、次の変更を行います。

1. サーバー・プロパティ: ホストをcfcvip.example.comに変更します。

2. 「アイデンティティ・プロバイダ」→「共通」: providerIdをcfcvip.example.comに変更します。

3. 「サービス・プロバイダ」→「共通」: providerIdをcfcvip.example.comに変更します。

4. データ・ストア: データ・ストアがLDAPの場合は、ユーザー・データ・ストアとフェデレーション・データ・ストアの接続URLの値をcfcvip.example.comに置き換えます。

5. 「認証エンジン」→「LDAPディレクトリ」: ConnectionURLをcfcvip.example.comに設定します。

3. メタデータを生成するため、管理対象サーバーを再起動します。

15.2.4.3.2 Oracle Identity Federationクライアントの変換

次の手順に従って、Oracle Identity Federationクライアントを変換します。

1. Oracle Identity Federationクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。

2. Oracle HTTP ServerがOracle Identity Federationのフロントエンドである場合、Oracle Identity FederationのWebLogic構成で、WLS_OIF管理対象サーバーのアドレスとして仮想IP cfcvip.example.comを指定する必要があります。そのためには、Oracle HTTP ServerおよびOracle Identity Federationで使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、oif.confファイルを次のように編集します。

#Oracle Identity Federation
<Location /oif>
SetHandler weblogic-handler
WebLogicHost cfcvip.example.com
WebLogic port
</Location>

15.2.4.4 Oracle Access Managerおよびそのクライアントの変換

この項では、Oracle Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定すること、および管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.example.com)に指定することによって設定可能です。この場合、明確な変換手順は不要です。

15.2.4.4.1 Oracle Access Managerの変換

Oracle Access Managerは管理対象サーバー(WLS_OAM1など)にデプロイされ、CFC変換を行うためには、この管理対象サーバーを、仮想IPのcfcvip.example.comでリスニングするように構成します。第15.2.3.6,項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、WLS_OAM1管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第15.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

Oracle Access Managerコンソールは、ドメインの管理サーバーの一部としてデプロイされます。このコンソールのコールド・フェイルオーバー・クラスタ構成では、管理サーバー全体をアクティブ/パッシブで構成する必要があります。管理サーバーは、同じ仮想IPのcfcvip.example.comを共有することも、個別の仮想IPと共有ディスクを使用して独立してフェイルオーバーするように構成することもできます。同じ仮想IPを使用している場合、管理サーバーとOracle Access Manager管理対象サーバーは1つのユニットとしてフェイルオーバーします。

15.2.4.4.2 Oracle Access Managerクライアントの変換

次の手順に従って、Oracle Access Managerクライアントを変換します。

1. Oracle Access Managerクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Identity ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.example.comを使用してアプリケーションにアクセスする必要があります。

2. Oracle HTTP ServerがOracle Access Managerのフロントエンドである場合、Oracle Access Managerに関するmod_weblogic構成では、Oracle Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.example.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

#Oracle Access Manager
<Location /oam>
SetHandler weblogic-handler
WebLogicHost cfcvip.example.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>

15.2.4.5 Oracle Adaptive Access Managerおよびそのクライアントの変換

この項では、Oracle Adaptive Access Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.example.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。

15.2.4.5.1 Oracle Adaptive Access Managerの変換

Oracle Adaptive Access Managerは管理対象サーバーにデプロイされます。両方とも単一のユニットとしてフェイルオーバーするようにデプロイされ、そのために同じ仮想IPと同じ共有記憶域を共有します。OAAM Admin管理対象サーバーおよびOAAM Server管理対象サーバーをCFC変換のために変換するには、これらの管理対象サーバーを、仮想IPのcfcvip.example.comでリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第15.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

15.2.4.5.2 Oracle Adaptive Access Managerクライアントの変換

次の手順に従って、Oracle Adaptive Access Managerクライアントを変換します。

1. Oracle Adaptive Access Managerクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Identity Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.example.comを使用してアプリケーションにアクセスする必要があります。

2. Oracle HTTP ServerがOracle Adaptive Access Managerのフロントエンドである場合、Oracle Adaptive Access Managerに関するmod_weblogic構成では、Oracle Adaptive Access Manager管理対象サーバーのアドレスとして仮想IPのcfcvip.example.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルを次のように編集します。

#Oracle Adaptive Access Manager
<Location /oaam_server>
SetHandler weblogic-handler
WebLogicHost cfcvip.example.com WebLogicPort port
</Location>

#Oracle Adaptive Access Manager Admin Console
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicHost cfcvip.example.com:port
</Location>

15.2.4.6 Oracle Identity Managerおよびそのクライアントの変換

この項では、Oracle Identity Managerをコールド・フェイルオーバー・クラスタ環境で機能するように変換する方法について説明します。

構成ウィザードを使用して作成したその他の管理対象サーバーと同様に、管理対象サーバーによる仮想IPでのリスニングを要するコールド・フェイルオーバー・クラスタは、最初の作成時に設定することも、管理対象サーバーのリスニング・アドレスを仮想ホスト名(cfcvip.example.com)に指定することによって設定することもできます。この場合、明確な変換手順は不要です。

15.2.4.6.1 Oracle Identity Managerの変換

Oracle Identity Managerは、管理対象サーバーにデプロイされます。一般的なCFCデプロイメントでは、Oracle Identity Manager管理対象サーバーと、Oracle SOAおよびOracle Web Services Managerを含む別の管理対象サーバーは1つのユニットとしてフェイルオーバーするようにデプロイされ、そのために同じ仮想IPと同じ共有記憶域を共有します。この両方の管理対象サーバーをCFC変換のために変換するには、これらの管理対象サーバーを、仮想IPのcfcvip.example.comでリスニングするように構成します。第15.2.3.6項「Oracle WebLogic管理対象サーバーの変換」の手順に従って、これらの管理対象サーバーを、cfcvip.example.comの仮想IP上でリスニングするように構成してください。Middlewareホームの配置およびフェイルオーバー可能な共有記憶域上のその他の関連するドメイン・アーティファクトに関する他のすべての要件は、第15.2.1項「コールド・フェイルオーバー・クラスタの要件」の説明のとおりです。

15.2.4.6.2 Oracle Identity Managerクライアントの変換

次の手順に従って、Oracle Identity Managerクライアントを変換します。

1. Oracle Identity Managerクライアントは、仮想IPのcfcvip.example.comを使用してこのアプリケーションにアクセスする必要があります。Oracle Access ManagerやOracle Adaptive Access Managerなどのコンポーネントで行う接続も、仮想IPのcfcvip.example.comを使用してアプリケーションにアクセスする必要があります。SOAもOracle Identity Managerでフェイルオーバーするように構成されているので、Oracle Identity ManagerからSOAへの接続でも共通の仮想IPを使用する必要があります。

2. Oracle HTTP ServerがOracle Identity Managerのフロントエンドである場合、Oracle Identity Managerに関するmod_weblogic構成では、管理対象サーバーのアドレスとして仮想IPのcfcvip.example.comを指定する必要があります。そのためには、使用されるマウント・ポイントのWebサーバー・プロキシ・プラグイン構成ファイルでWebLogicのホスト構成を変更します。たとえば、テキスト・エディタを使用して、mod_wl_ohs.confファイルまたはoim.confファイルを次のように編集します。

#Oracle Identity Manager
<Location /oim>
SetHandler weblogic-handler
WebLogicHost cfcvip.example.com:port
WebLogicPort port
</Location>

Oracle Identity Managerでの構成変更の詳細は、Oracle Fusion Middleware Oracle Identity Managerシステム管理者ガイドを参照してください。

15.2.4.7 シングル・サインオンの再登録(必要な場合)

シングル・サインオン(SSO)の再登録は通常、Oracle Portal、Forms、ReportsおよびDiscovererにのみ適用されます。この層のOracle HTTP Server上のフロントエンド・リスニング・エンドポイントが仮想IPに変更された後で、保護されるURLを仮想IPによって構成するために、SSOの再登録が必要になります。

注意:

11gでは、再登録ではなく新しいVIPを使用してWebGateを作成する必要があります。

SSOを再登録するには、SSOサーバーが配置されているIdentity Management 10.1.xインストールに対して次の手順を実行します。

1. ORACLE_HOME変数をSSOのORACLE_HOMEの場所に設定します。

2. 次のパラメータを指定して、ORACLE_HOME/sso/bin/ssoreg.shを実行します。

-site_name cfcvip.example.com:port
-mod_osso_url http://cfcvip.example.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_INSTANCE/binディレクトリから実行して、Oracle HTTP Serverを再起動します。

./opmnctl restartproc process-type=OHS

5. 次のURLでSSOサーバーにログインします。

http://sso.example.com/pls/orasso

6. 「管理」ページの「パートナ・アプリケーション管理」で、node1.example.comのエントリを削除します。

15.2.5 Fusion Middlewareフェイルオーバーの追加のアクション

コールド・フェイルオーバー・クラスタ環境では、フェイルオーバー・ノード(node2.example.com)をすべての面でインストール・マシン(node1.example.com)と同じにする必要があります。フェイルオーバー・ノードをインストール・ノードと同じにするには、フェイルオーバー・インスタンスで次の手順を実行します。

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番目のノードで作成します。

15.2.6 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.example.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.example.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. アプリケーション・サーバーのデータベース・サービスを作成します。
デフォルト・データベース・サービスとは別の、専用のサービスをお薦めします。このサービスを作成するには、次の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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

15.2.6.1 データベース・インスタンスの考慮事項

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番目のノードで作成します。

15.3 Oracle Fusion Middlewareコールド・フェイルオーバー・クラスタのトポロジ例

この項では、コールド・フェイルオーバー・クラスタのトポロジ例について説明します。トポロジでは様々な組合せが考えられるため、ここで示すトポロジは例にすぎません。これらのトポロジを実現するには、複数の変換手順が適用されます。変換を構成する方法の詳細は、前述の各手順を参照してください。

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

- 第15.3.1項「トポロジの例1」

- 第15.3.2項「トポロジの例2」

- 第15.3.3項「トポロジの例3」

15.3.1 トポロジ例1

図15-3は、Oracle WebCenter Portalのコールド・フェイルオーバー・クラスタ・デプロイメントを示しています。ドメイン内には管理サーバーとWebCenter管理対象サーバーの両方があり、1つのユニットとしてフェイルオーバーします。したがって、これらは同じ仮想IPを共有し、同じ共有ディスク上にまとめてインストールされています。このトポロジのフロントエンドとしてOracle HTTP Serverも使用できます。このトポロジ例では、別のノードに配置されています。同じノードに配置して、コールド・フェイルオーバー・クラスタ・デプロイメントの一部とすることも可能です。この例では、データベースも別のノードに配置されています。しかし、データベースも同様に、同じクラスタ上に配置して、コールド・フェイルオーバー・クラスタベースにする場合もあります(仮想IPと共有ディスクは専用のものを使用)。

図15-3 コールド・フェイルオーバー・クラスタのトポロジ例1

15.3.2 トポロジ例2

図15-4は、SOAコールド・フェイルオーバー・クラスタ・デプロイメント例を示しています。この例では、SOAインスタンスのみがコールド・フェイルオーバー・クラスタとしてデプロイされ、管理サーバーは別のノードに配置されています。このトポロジ例では、データベースも別のノードに配置されています。この例では、Oracle HTTP Serverはコールド・フェイルオーバー・クラスタ・デプロイメントの一部であり、SOA管理対象サーバーと同じフェイルオーバー・ユニットの一部になります。このトポロジの重要なバリエーションの1つは、同じハードウェア・クラスタにコールド・フェイルオーバー・クラスタ管理サーバーを組み込むことです。この場合、仮想IPと共有ディスクをSOA管理対象サーバーと共有するか(管理サーバーをSOAと同じフェイルオーバー・ユニットに組み込む)、別の仮想IPと共有ディスクを使用(管理サーバーを別個にフェイルオーバーさせる)できます。同様に、マシンの処理能力に応じて、データベース・インスタンスも同じハードウェア・クラスタに配置できます。

図15-4 コールド・フェイルオーバー・クラスタのトポロジ例2

15.3.3 トポロジ例3

図15-5は、Oracle Identity Managementデプロイメントを示しています。このトポロジ例では、すべてのコンポーネントが、2つのノードのハードウェア・クラスタに配置されています。Identity Managementは1つのユニットとしてフェイルオーバーし、Java EEコンポーネント(管理サーバーとWLS_ods管理対象サーバー)とシステム・コンポーネントの両方が、同じフェイルオーバー・ユニットの一部となっています。これらは同じ仮想IP (cfcvip1.example.com)と共有ディスクを使用しています。データベースも同じハードウェア・クラスタに配置されています。異なる仮想IP cfcvip2.example.comと、異なる共有ディスク・セットを使用しています。通常の運用中では、データベースはノード2で実行し、IDMスタックはノード1で実行します。それぞれのノードは互いにバックアップ・ノードとして機能します。

このトポロジは、ほとんどのコールド・フェイルオーバー・クラスタ・デプロイメントの推奨トポロジです。例ではIdentity Managementを使用していますが、Oracle SOA、Oracle WebCenter Portal、Oracle Portal、Forms、ReportsおよびDiscovererスイートにも有効です。推奨アーキテクチャでは、Oracle Fusion Middlewareはハードウェア・クラスタの1つのノードとして実行します。別のノードではOracle Databaseを実行します。各ノードは互いにバックアップ・ノードになります。Oracle Fusion Middlewareインスタンスとデータベース・インスタンスは、異なる共有ディスクと異なるVIPを使用し、互いに独立してフェイルオーバーします。また、このアーキテクチャでは、ハードウェア・クラスタ・リソースの使用率が最適化されます。

図15-5 コールド・フェイルオーバー・クラスタのトポロジ例3

15.4 コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換

この項では、既存のドメインの管理サーバーをコールド・フェイルオーバー・クラスタに変換する手順について説明します。

注意:

管理サーバーの変換後、第15.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」で述べられているように、管理サーバーおよびEnterprise Managerのクライアント側の変更が必要になる場合があります。

前提事項

この項の手順は、次を前提としています。

- すべてのFusion Middlewareコンポーネントは、nostageデプロイメントに配置されています。

- 起動トポロジが製品スイートのアクティブ/アクティブ・クラスタです(ノード1およびノード2)。

- 開始する管理サーバーはノード1です。

- ノード1の管理対象サーバーと同じドメイン・ホームを共有しています。

- MW_HOMEパスがノード1とノード2で同じです。

これらの手順は、前提が満たされていれば、Oracle WebLogicクラスタ・インストールにデプロイされているカスタマ・アプリケーションにも適用されます。

開始トポロジ

図15-6は、管理サーバーを変換する前の開始トポロジの例を示しています。

図15-6 コールド・フェイルオーバー・クラスタの開始トポロジ例

15.4.1 変換後トポロジ

図15-7に、コールド・フェイルオーバー・クラスタ用に管理サーバーを変換した後の可能なトポロジを示します。このトポロジは、次のような特性を持ちます。

- 管理サーバー・ドメイン・ホームは、ノード1とノード2の両方でマウント可能な共有ディスクに移動しますが、任意の時点では片方のみがマウントされます。

- 引き続き、ノード1とノード2からアクセスできる元のMiddlewareホームが使用されます。

- 管理サーバーのリスニング・アドレスは、仮想IPになります。

図15-7 変換後の可能なトポロジ

15.4.2 コールド・フェイルオーバー・クラスタ変換の手順

既存のドメインで管理サーバーを変換するには、次の手順を実行します。

1. コンポーネントの管理対象サーバーおよび管理サーバーのクラスタをシャットダウンします。

2. 各ノードでノード・マネージャ・プロセスが稼働していれば、それをシャットダウンします。

3. ドメイン全体をバックアップします。

4. ノード1で仮想IPをプロビジョニングします。例:

/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_Addressが有効化されます。

/sbin/ifconfig eth0:1 130.35.46.17 netmask 255.255.224.0
/sbin/arping -q -U -c 3 -I eth0 IP_Address

ここで、IP_Addressは、仮想IPアドレスです。また、netmaskは、関連付けられたネットマスクです。

次の例では、Local Area ConnectionのインタフェースでIP_Addressが有効化されます。

netsh interface ip add address "Local Area connection" IP_Address netmask

5. ローカルのドメイン・ホームから管理サーバーを起動します。

cd DOMAIN_HOME/bin
./startWeblogic.sh

6. 管理サーバー・インスタンスをコールド・フェイルオーバー・クラスタに変換します。
管理コンソールにログインします。

仮想ホストのマシンを作成します。

1. 「環境」、「マシン」の順に選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。「新規」をクリックします。

3. 「名前」フィールドにcfcvip.example.comと入力します。

注意:

「リスニング・アドレス」フィールドはlocalhostに設定したままにします(CFCソリューションはこの設定に依存します)。これを仮想IP_Addressまたはその他の値に変更しないでください。

管理サーバーには、ローカルだけでなく複数のノード・マネージャと対話できるように新しい仮想ホスト・マシンが必要です。各ホストの各ノード・マネージャは、実際のIPおよびローカル・ホスト(127.0.0.1)の両方のすべてのインタフェースでリスニングします。管理サーバーは、新しい仮想ホスト・マシン定義を排他的に使用します。

localhostはすべてのアクティブなマシンの相対内部アドレスであり、管理サーバーに固定されるため、仮想ホスト・マシンはlocalhostを指す必要があります。管理サーバーをあるホストから別のホストに変更しても、同じ仮想名およびVIPが保持されます。管理サーバーはlocalhost属性と1つ目のノードを組み合せて使用し、フェイルオーバー後は2つ目のノードも使用するため、管理サーバーと関連付けられているノード・マネージャも変更されます。図xを参照してください。

4. 適切なオペレーティング・システムを選択して、「OK」をクリックします。

5. 作成したマシンを選択します。

6. 「サーバー」タブをクリックしてから、「追加」をクリックします。

7. 既存のサーバーを選択して、このマシンに関連付けます。

8. 「サーバーの選択」ドロップダウン・リストで、「AdminServer」が選択されていることを確認します。

9. 「終了」→「変更のアクティブ化」をクリックします。

cfcvip.example.com上でリスニングするように管理サーバーを構成します。

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

3. 管理サーバー(AdminServer)をクリックします。

4. 「リスニング・アドレス」をcfcvip.example.comに変更し、「保存」をクリックします。

管理コンソールから管理サーバーを停止します。

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」をクリックします。

3. その横にあるチェック・ボックスをクリックして、「Adminserver」を選択します。

4. 「停止」プルダウン・メニューで、「ただちに強制停止」を選択して、管理サーバーをシャットダウンします。

5. 「はい」をクリックします。

コマンド行から、システムでVIPが有効で、管理サーバーが起動していることを確認します。

cd DOMAIN_HOME/bin
./startWeblogic.sh

7. 仮想IP上でコンソールにアクセスして、管理サーバーを検証します。

- http://cfcvip.example.com:7001/console

- http://cfcvip.example.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.example.com:7001/console

- http://cfcvip.example.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を無効化します。

ifconfig interface:index down

次の例では、eth0インタフェースでIP_Addressが無効化されます。

ifconfig eth0:1 down

netsh interface ip delete address interface addr=IP_Address

この場合、IP_Addressは仮想IP_Addressです。

次の例では、IP_AddressはインタフェースLocal Area Connection上で有効になります。

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)にフェイルバックします。

第III部

付録

この部は、次の付録で構成されています。

- 付録A「Oracle RACデータベース・ストアを使用した監査の設定」

- 付録B「推奨されるマルチ・データ・ソース」

- 付録C「Oracle Identity Managementのワークブック」

- 付録D「ascrsctlのオンライン・ヘルプ」

- 付録E「MDSに対する分散通知の構成」

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)によって、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.example.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 Oracle Identity Managementのワークブック

この付録では、Oracle Identity Managementコンポーネントの高可用性の構成を実行する際に使用できるワークブックを掲載しています。

このワークブックでは、Oracle Identity Managementコンポーネントの高可用性の構成時に、環境内で使用する予定の構成内容を入力できます。

C.1 Oracle Identity Managementのワークブック表

次の各表を使用して、Oracle Identity Managementの高可用性構成で使用することを予定している構成内容を記録します。

表C-1には、構成に使用するアプリケーションのURLを入力します。

表C-1 アプリケーションのURL

アプリケーション

URL

Oracle WebLogic管理コンソール

Oracle Enterprise Manager Fusion Middleware Control

Oracle Access Managerコンソール

表C-2には、構成に使用する仮想IPアドレスを入力します。

表C-2 仮想IPアドレス

用途

IPアドレス

DNS名

Oracle WebLogic管理サーバー

表C-3には、構成に使用する次の汎用ファイルの場所を入力します。

表C-3 汎用ファイルの場所

タイプ

場所

共有

ORACLE_BASE

いいえ

MW_HOME

いいえ

表C-4には、構成に使用するIDMHOSTnのファイルの場所を入力します。

表C-4 IDMHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

ORACLE_HOME

いいえ

管理サーバーのORACLE_INSTANCE

いいえ

WLS_ODS1のORACLE_INSTANCE

いいえ

WLS_ODS2のORACLE_INSTANCE

いいえ

WL_HOME

いいえ

DOMAIN_HOME

いいえ

表C-5には、構成に使用するOIDHOSTnのファイルの場所を入力します。

表C-5 OIDHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表C-6には、構成に使用するOVDHOSTnのファイルの場所を入力します。

表C-6 OVDHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表C-7には、構成に使用するOAMHOSTnのファイルの場所を入力します。

表C-7 OAMHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

IDM_ORACLE_HOME

いいえ

IAM_ORACLE_HOME

いいえ

SOA_ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表C-8には、構成に使用するOIMHOSTnのファイルの場所を入力します。

表C-8 OIMHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

IAM_ORACLE_HOME

いいえ

ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表C-9には、構成に使用するOAAMHOSTnのファイルの場所を入力します。

表C-9 OAAMHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

IDM_ORACLE_HOME

いいえ

IAM_ORACLE_HOME

いいえ

SOA_ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表C-10には、構成に使用するOIFHOSTnのファイルの場所を入力します。

表C-10 OIFHOSTnのファイルの場所

環境アーティファクト

ディレクトリの場所

共有

ORACLE_HOME

いいえ

管理サーバーのORACLE_INSTANCE

いいえ

WLS_OIF1のORACLE_INSTANCE

いいえ

WLS_OIF2のORACLE_INSTANCE

いいえ

WL_HOME

いいえ

DOMAIN_HOME

いいえ

表C-11には、構成に使用するWeb層のファイルの場所を入力します。

表C-11 Web層のファイルの場所

環境アーティファクト

ディレクトリの場所

共有

ORACLE_HOME

いいえ

ORACLE_INSTANCE

いいえ

表C-12には、構成に使用するOracle Identity Managementの詳細を入力します。

表C-12 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ポート

表C-13には、Oracle Identity Federation構成に使用する認証LDAPのアーティファクトの詳細を入力します。

表C-13 Oracle Identity Federation用の認証LDAPのアーティファクト

認証LDAPのアーティファクト

値

LDAPタイプ

LDAP URL

LDAPバインドDN

LDAPバインドDNのパスワード

ユーザー資格証明ID属性

ユーザーの一意ID属性

個人オブジェクト・クラス

ベースDN

表C-14には、構成でLDAPユーザー・データ・ストアを使用する場合のOracle Identity Federationのアーティファクトを入力します。

表C-14 Oracle Identity Federation用のLDAPユーザー・データ・ストアのアーティファクト

LDAPユーザー・データ・ストアのアーティファクト

値

LDAPタイプ

LDAP URL

LDAPバインドDN

LDAPバインドDNのパスワード

ユーザー説明属性

ユーザーID属性

個人オブジェクト・クラス

ベースDN

表C-15には、構成でLDAPフェデレーション・データ・ストアを使用する場合のOracle Identity Federationのアーティファクトを入力します。

表C-15 Oracle Identity Federation用のLDAPフェデレーション・データ・ストアのアーティファクト

フェデレーション・データ・ストアのアーティファクト

値

LDAPタイプ

LDAP URL

LDAPバインドDN

LDAPバインドDNのパスワード

ユーザー・フェデレーション・レコード・コンテキスト

LDAPコンテナ・オブジェクト・クラス

表C-16には、構成でRDBMSユーザー・データ・ストアを使用する場合のOracle Identity Federationのアーティファクトを入力します。

表C-16 Oracle Identity Federation用のRDBMSユーザー・データ・ストアのアーティファクト

RDBMSユーザー・データ・ストアのアーティファクト

値

ホスト名

ユーザー名

パスワード

ログイン表

ユーザーID属性

ユーザー説明属性

表C-17には、構成でRDBMSフェデレーション・データ・ストアを使用する場合のOracle Identity Federationのアーティファクトを入力します。

表C-17 Oracle Identity Federation用のRDBMSフェデレーション・データ・ストアのアーティファクト

RDBMSフェデレーション・データ・ストアのアーティファクト

値

ホスト名

ユーザー名

パスワード

表C-18には、Oracle Identity Federation構成に使用するRDBMS一時データ・ストアのアーティファクトを入力します。

表C-18 Oracle Identity Federation用のRDBMS一時データ・ストアのアーティファクト

一時データ・ストアのアーティファクト

値

ホスト名

ユーザー名

パスワード

表C-19には、構成に使用するメタデータ・リポジトリのデータベース情報を入力します。

表C-19 メタデータ・リポジトリのデータベース情報

データベースの詳細

値

データベース・ホスト(Oracle RACを使用する場合はVIP)

リスナー・ポート

データベース・サービス名

RCU接頭辞

メイン・スキーマの名前/パスワード

補助スキーマの名前/パスワード

SYSのパスワード

表C-20には、構成に使用するロード・バランサの構成情報を入力します。

表C-20 ロード・バランサの構成

用途

仮想名

ポート

外部から参照可能

SSL

接続先ホスト

接続先ポート

SSL

Oracle Internet Directory

Oracle Virtual Directory

管理サーバー

Oracle Identity Manager

シングル・サインオン

表C-21には、構成に使用するポート情報を入力します。

表C-21 ポート情報

コンポーネント

ホスト

ポート

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 ascrsctlのオンライン・ヘルプ

ascrsctl helpコマンドで生成される手順に従うことで、ascrsctlの詳細な使用方法がわかります。この付録には、オフラインでの詳細な参照用に、ヘルプ・ページのすべての内容が収録されています。

D.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.example.com

D.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

D.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

D.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.example.com
ascrsctl switch -n ora.myvip.cfcvip -np

D.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

D.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)。

プロパティの名前と値の範囲を表D-1に示しますが、この表では、as、stおよびraを除くすべての数値は秒単位です。これらのプロパティは、ASCRSの構成ファイルで構成できます。プロパティが構成されていない場合やこのオプションで指定されていない場合、デフォルト値が使用されます。

表D-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

D.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)。

プロパティの名前と値の範囲を表D-2に示しますが、この表では、as、stおよびraを除くすべての数値は秒単位です。

表D-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"

D.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)。

プロパティの名前と値の範囲を表D-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

D.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)。

プロパティの名前と値の範囲を表D-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

D.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)。

プロパティの名前と値の範囲を表D-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

D.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)。

プロパティの名前と値の範囲を表D-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

D.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)。

プロパティの名前と値の範囲を表D-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

D.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)。

プロパティの名前と値の範囲を表D-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

D.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)。

プロパティの名前と値の範囲を表D-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

D.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)。

プロパティの名前と値の範囲を表D-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

E MDSに対する分散通知の構成

MDSデータベース・リポジトリには、MetadataObjectとそれらのコンテンツをキャッシュするためにJavaオブジェクト・キャッシュを使用する機能があります。MDSを使用する各ノードには独自のJavaオブジェクト・キャッシュ・インスタンスがあり、そのノードによってリポジトリからMetadataObjectが読み取られるとそれらがキャッシュされ、そのMetadataObjectを構成するドキュメントに対するローカルな更新が行われるとそのローカル・キャッシュでそれらが無効化されます。

MDSでは、 MetadataObjectをレプリケートするために分散Javaオブジェクト・キャッシュが使用されることはありません。MDSは、そのリポジトリにローカルな変更がフラッシュされるたびに、他のノードによって行われたリポジトリに対する変更を検出し、それに従って関連するローカル・キャッシュ・エントリを無効化します。さらに、各クラスタ・メンバーによって30秒ごとに(これはデフォルトの間隔であり、構成可能です)リポジトリへのポーリングが行われ、ドキュメントが変更されたかどうかが検知され、同様の方法でローカル・キャッシュ・エントリが無効化されます。

ただし、MDSデータベース・リポジトリには、そのリポジトリ内のドキュメントがクラスタ・メンバーによって変更されたときに、クラスタワイドの通知を送信する機能もあります。この機能が有効化されている場合、すべてのクラスタ・メンバーは、ローカル・コミットやリポジトリのポーリングが実行されるまで待つことなく、変更が行われた時点でドキュメントに対する変更を通知されます。したがって、高可用性環境では、パフォーマンス上の理由により、分散通知を有効化することをお薦めします。各クラスタ・メンバー上で分散Javaオブジェクト・キャッシュを構成すると、分散通知が使用可能になります。クラスタ・メンバーがドキュメントに対する変更の通知を受信すると、そのドキュメントの現在のローカル・バージョンは無効化され、更新されたドキュメントがかわりに使用されます。

この機能が動作するためには、各ノードでJavaオブジェクト・キャッシュを構成し、各ノードがそのリポジトリを指すために使用するJNDI名をすべてのノードで同一にして、ポーリングを有効化する必要があります(ポーリングはデフォルトで有効化されていますが、無効化しないでください)。

クラスタ内のノード上での分散Javaオブジェクト・キャッシュの構成の手順は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』のトピック「Javaオブジェクト・キャッシュの設定」を参照してください。

オラクル社の法律上の注意点について

コピーライトについて

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

商標と登録商標について

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

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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

危険な用途への使用について

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。