目次

図一覧

表一覧

タイトルと著作権情報

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 11g リリース2 (11.1.2.2)の新機能と変更機能

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

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

- 1.2 エンタープライズ・デプロイメント・ガイドの規則

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

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

- 1.4.1 組込みセキュリティ

- 1.4.2 高可用性

2 導入と計画

- 2.1 デプロイメントの計画

- 2.1.1 デプロイメント・トポロジ

- 2.1.1.1 Web層

- 2.1.1.2 アプリケーション層

- 2.1.1.3 データ層

- 2.1.1.4 ロード・バランサ

- 2.1.1.5 ファイアウォール

- 2.1.2 分割ドメイン・トポロジを使用するメリット

- 2.2 Oracle Directory Services Managerについて

- 2.3 トポロジの理解

- 2.3.1 Web層について

- 2.3.1.1 アーキテクチャに関する注意

- 2.3.1.2 高可用性プロビジョニング

- 2.3.1.3 セキュリティ・プロビジョニング

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

- 2.3.2.1 WebLogicドメインについて

- 2.3.2.2 LDAPディレクトリについて

- 2.3.2.3 アーキテクチャに関する注意

- 2.3.2.4 高可用性プロビジョニング

- 2.3.2.5 セキュリティ・プロビジョニング

- 2.3.3 オプションのディレクトリ層について

- 2.3.4 データベース層について

- 2.4 エンタープライズ・デプロイメントのハードウェア要件

- 2.5 エンタープライズ・デプロイメントのソフトウェア・コンポーネント

- 2.5.1 ソフトウェアのバージョン

- 2.5.2 ソフトウェアの入手について

- 2.5.3 Oracleホームのまとめ

- 2.5.4 パッチおよび回避策の適用

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

- 2.6.1 Oracle Identity and Access Managementエンタープライズ・デプロイメント処理のフロー・チャート

- 2.6.2 Oracle Identity and Access Managementエンタープライズ・デプロイメント処理の手順

- 2.7 その他のドキュメント

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

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

- 3.2 ネットワークの計画

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

- 3.3.1 IDSTORE.mycompany.com

- 3.3.2 IADADMIN.mycompany.com

- 3.3.3 IGDADMIN.mycompany.com

- 3.3.4 IDMINTERNAL.mycompany.com

- 3.3.5 SSO.mycompany.com

- 3.4 ハードウェア・ロード・バランサの構成

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

- 3.4.2 ロード・バランサの構成手順

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

- 3.5 IPアドレスおよび仮想IPアドレスについて

- 3.6 ファイアウォールとポートの構成

- 3.7 Access Manager通信プロトコルの管理

- 3.7.1 Access Managerプロトコル

- 3.7.2 統合リクエストの概要

- 3.7.3 ユーザー・リクエストの概要

- 3.7.4 通信のマルチキャスト要件について

- 3.7.5 ネットワーク接続の確認

4 エンタープライズ・デプロイメント用の記憶域の準備

- 4.1 エンタープライズ・デプロイメント用の記憶域の準備の概要

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

- 4.3 ファイル・システムについて

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

- 4.4.1 バイナリ(Middlewareホーム)ディレクトリの推奨事項

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

- 4.4.1.2 単一のMiddlewareホームの共有について

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

- 4.4.1.4 ライフサイクル・リポジトリについて

- 4.4.2 ドメイン構成ファイルの推奨事項

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

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

- 4.4.2.3 管理対象サーバー・ドメイン構成ファイルに対するローカル記憶域の要件

- 4.4.3 JMSファイル・ストアとトランザクション・ログ用の共有記憶域に関する推奨事項

- 4.4.4 ディレクトリの推奨場所

- 4.4.4.1 ライフサイクル管理とデプロイメント・リポジトリ

- 4.4.4.2 共有記憶域

- 4.4.4.3 プライベート記憶域

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

- 5.1 サーバー構成の概要

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

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

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

- 5.4.1 カーネル・パラメータの構成

- 5.4.2 オープン・ファイル制限の設定

- 5.4.3 シェル制限の設定

- 5.4.4 ローカルHostsファイルの構成

- 5.5 Unicodeサポートの有効化

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

- 5.6.1 必要な仮想IPアドレスの概要

- 5.6.2 既存のネットワーク・インタフェースでの仮想IPアドレスの有効化

- 5.7 共有記憶域のホストへのマウント

- 5.7.1 共有記憶域の概要

- 5.7.2 共有記憶域のマウント

- 5.7.3 共有記憶域の構成の検証

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

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

- 6.1 Identity and Access Managementエンタープライズ・デプロイメント用のデータベースの準備の概要

- 6.2 エンタープライズ・デプロイメントのデータベース要件の検証

- 6.2.1 必要なデータベース

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

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

- 6.2.4 Oracle Database 11g (11.2.0.2.0)のパッチ要件

- 6.2.5 Oracle Databaseの最小要件

- 6.2.5.1 一般的なデータベース特性

- 6.2.5.2 最小初期化パラメータ

- 6.3 エンタープライズ・デプロイメント用のデータベースのインストール

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

- 6.4.1 10.xおよび11.1.xデータベース用のデータベース・サービスの作成

- 6.4.2 11.2.xデータベース用のデータベース・サービスの作成

- 6.4.3 データベースのチューニング

- 6.5 RCUを使用したOracle RAC DatabaseへのIdentity and Access Managementスキーマのロード

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

7 デプロイの準備

- 7.1 Identity and Access Managementのデプロイメントのための情報収集

- 7.2 Oracle Identity and Access Managementのソフトウェア・リポジトリの作成

- 7.3 Javaの検証

- 7.4 IAMデプロイメント・ウィザードのインストール

- 7.5 ポート可用性のチェック

8 デプロイメント・プロファイルの作成

- 8.1 ようこそ

- 8.2 IAMインストール・オプション

- 8.3 セキュリティ・アップデートの指定

- 8.4 レスポンス・ファイルの説明

- 8.5 IAM製品の選択

- 8.6 トポロジの選択

- 8.7 インストールと構成の場所の選択

- 8.8 仮想ホストの構成

- 8.9 ユーザー名およびパスワードの設定

- 8.10 Oracle Unified Directoryの構成

- 8.11 Oracle HTTP Serverの構成

- 8.12 Oracle Identity Managerの構成

- 8.13 Oracle Identity Managerデータベースの構成

- 8.14 SOAの構成

- 8.15 Oracle Access Managerの構成

- 8.16 Oracle Access Managerデータベースの構成

- 8.17 HTTP/HTTPSロード・バランサの構成

- 8.18 サマリー

9 Identity and Access Managementのデプロイ

- 9.1 デプロイメント処理の概要

- 9.1.1 デプロイ・ステージ

- 9.1.2 処理順序

- 9.2 デプロイメント手順

- 9.2.1 デプロイメント・コマンドの実行

- 9.2.2 バックアップの作成

- 9.3 チェック・リスト

- 9.4 共通のLCM_HOMEのないIdentity and Access Managementのデプロイメント

10 デプロイ後構成の実行

- 10.1 デプロイ後のOPSSの手順

- 10.2 デプロイ後のOracle Unified Directoryの手順

- 10.2.1 Oracle Unified Directory変更ログ・アクセスの更新

- 10.2.2 LDAP同期化のためのOracle Unified Directory ACIの更新

- 10.3 デプロイ後のOracle Identity Managerの手順

- 10.3.1 既知の問題に対処するためのデプロイメント後の手順

- 10.3.2 サーバー起動パラメータの更新

- 10.4 デプロイ後の電子メール・サーバーの手順

- 10.5 デプロイ後のAccess Managerの手順

- 10.5.1 アイドル・タイムアウト値の更新

- 10.5.2 Webゲート・エージェントの更新

- 10.6 トラスト・ストアへのロード・バランサ証明書の追加

- 10.7 すべてのコンポーネントの再起動

11 デプロイメントの検証

- 11.1 管理サーバーの検証

- 11.1.1 接続の検証

- 11.1.2 フェイルオーバーの検証

- 11.2 Access Managerの構成の検証

- 11.3 Oracle Identity Managerの検証

- 11.4 Web層からのSOAインスタンスの検証

- 11.5 Oracle Unified Directoryの検証

- 11.6 WebゲートおよびAccess Managerのシングル・サインオンのセットアップの検証

- 11.7 デプロイメントの検証

12 Oracle Adaptive Access Managerを追加するためのドメインの拡張

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

- 12.2 OAAMの詳細

- 12.3 前提条件

- 12.3.1 高可用性データベースの作成

- 12.3.2 LDAPにおけるOAAMユーザーとグループの作成

- 12.4 Oracle Adaptive Access Managerのドメインの拡張

- 12.5 OAMHOST1上での管理サーバーの再起動

- 12.6 ローカル・ストレージへの管理対象サーバーの構成の展開

- 12.7 スクリプトを起動および停止するためのOAAMサーバーの追加

- 12.8 OAMHOST1上でのOAAMの起動と検証

- 12.8.1 OAMHOST1におけるOracle Adaptive Access Managerの起動

- 12.8.2 OAMHOST1上でのOAAMの検証

- 12.9 OAMHOST2上でのOAAMの起動と検証

- 12.9.1 OAMHOST2におけるOracle Adaptive Access Managerの起動

- 12.9.2 OAMHOST2上でのOAAMの検証

- 12.10 Web層と連携するためのOAAMの構成

- 12.10.1 Oracle HTTP Serverからのアクセスの構成

- 12.10.1.1 IADADMIN.mycompany.comの更新

- 12.10.1.2 sso.mycompany.comの更新

- 12.10.1.3 Oracle HTTP ServerおよびOAAM管理対象サーバーの再起動

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

- 12.10.3 Oracle Adaptive Access Managerの検証

- 12.11 Oracle Adaptive Access Managerシード・データのロード

- 12.12 Oracle Adaptive Access ManagerとOracle Access Management Access Managerの統合

- 12.12.1 簡易モード用のグローバル・パスフレーズの取得

- 12.12.2 サード・パーティ・アプリケーションとしてのOAAMの登録

- 12.12.3 検証

- 12.12.4 Access ManagerのOAAMプロパティの設定

- 12.12.5 テスト・リソースの作成

- 12.12.5.1 Oracle Adaptive Access Managerポリシーの作成

- 12.12.5.2 Access Managerでのリソースの作成

- 12.12.6 Oracle Adaptive Access Managerの検証

- 12.12.7 TAPリソースのLDAPポリシーへの移動

- 12.13 Oracle Adaptive Access Manager 11gとOracle Identity Manager 11gの統合

- 12.13.1 CSFでのOracle Identity Manager暗号化鍵の構成

- 12.13.2 Oracle Identity ManagerとOracle Adaptive Access Manager間のクロス・ドメインの信頼の構成

- 12.13.3 Oracle Identity Manager用のOracle Adaptive Access Managerプロパティの設定

- 12.13.4 OAAMのOracle Identity Managerプロパティの設定

- 12.13.5 IAMAccessDomainとIAMGovernanceDomainの再起動

- 12.13.6 OAAMとOracle Identity Managerの統合の検証

- 12.13.7 Oracle Identity ManagerとOAAMの統合の検証

- 12.14 Oracle Adaptive Access Managerの保護へのドメインの変更

- 12.15 アプリケーション層の構成のバックアップ

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

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

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

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

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

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

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

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

- 13.8 サーバー移行構成のバックアップ

14 エンタープライズ・デプロイメントのスケーリング

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

- 14.2 LDAPディレクトリのスケーリング

- 14.2.1 スケール・アウト時のMiddlewareホームのマウント

- 14.2.2 Oracle Unified Directoryのスケーリング

- 14.2.2.1 Oracle Unified Directoryをスケーリングするための情報収集

- 14.2.2.2 追加のOracle Unified Directoryインスタンスの構成

- 14.2.2.3 新しいOracle Unified Directoryインスタンスの検証

- 14.2.2.4 新しいOracle Unified Directoryインスタンスのロード・バランサへの追加

- 14.3 Identity and Access Managementアプリケーションのスケーリング

- 14.3.1 情報の収集

- 14.3.1.1 Access Managerのスケーリングのための情報収集

- 14.3.1.2 Oracle Identity Managerのスケーリングのための情報収集

- 14.3.1.3 Oracle Adaptive Access Managerのスケーリングのための情報収集

- 14.3.2 スケール・アウト時のMiddlewareホームのマウントと新しいマシンの作成

- 14.3.3 スケール・アウト時の新しいノード・マネージャの作成

- 14.3.4圧縮/解凍の実行

- 14.3.5 アプリケーション固有の手順の実行

- 14.3.5.1 既存の管理対象サーバーのクローンの作成

- 14.3.5.2 Oracle Access Management Access Managerのスケーリング

- 14.3.5.2.1 圧縮/解凍の実行

- 14.3.5.2.2 Oracle Access Management Access Managerへの管理対象サーバーの登録

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

- 14.3.5.2.4 Web層の更新

- 14.3.5.3 Oracle Identity Managerのスケーリング

- 14.3.5.3.1 新しいJMSサーバーの構成

- 14.3.5.3.2 スケール・アウト時の圧縮/解凍の実行

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

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

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

- 14.3.5.3.6 Oracle Identity Manager構成手順の完了

- 14.3.5.4 Oracle Adaptive Access Managerの統合の更新

- 14.3.6 Oracle HTTP Server構成ファイルへの新しいWebLogic管理対象サーバーの追加

- 14.4 Web層のスケーリング

- 14.4.1 Web層のスケーリング用の情報収集

- 14.4.2 スケール・アウト時のMiddlewareホームのマウントとOracle HTTP Serverファイルのコピー

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

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

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

- 14.5 すべてのコンポーネントのスケーリング後の手順

- 14.5.1 トポロジ・ストアの更新

- 14.5.2 起動/停止スクリプトの更新

- 14.5.3 ノード・マネージャ構成の更新

- 14.5.3.1 ノード・マネージャの起動と停止

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

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

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

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

- 14.5.3.2.4 keytoolユーティリティを使用したトラスト・キーストアの作成

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

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

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

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

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

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

- 15.1.1 起動順序

- 15.1.2 スクリプトを使用したすべてのサーバーの起動と停止

- 15.1.2.1 すべてのサーバーの起動

- 15.1.2.2 すべてのサーバーの停止

- 15.1.3 Identity and Access Managementコンポーネントの手動での起動と停止

- 15.1.3.1 Oracle Unified Directoryの起動と停止

- 15.1.3.1.1 Oracle Unified Directoryの起動

- 15.1.3.1.2 Oracle Unified Directoryの停止

- 15.1.3.2 何も実行されていないときのOracle Access Manager管理対象サーバーの起動

- 15.1.3.3 WebLogic管理サーバーの起動と停止

- 15.1.3.3.1 WebLogic管理サーバーの起動

- 15.1.3.3.2 WebLogic管理サーバーの停止

- 15.1.3.4 WebLogic管理対象サーバーの起動と停止

- 15.1.3.4.1 WebLogic管理対象サーバーの起動

- 15.1.3.4.2 WebLogic管理対象サーバーの停止

- 15.1.3.5 ノード・マネージャの起動と停止

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

- 15.1.3.5.2 ノード・マネージャの停止

- 15.2 Identity and Access ManagementコンソールのURLについて

- 15.3 エンタープライズ・デプロイメントの監視

- 15.3.1 Oracle Unified Directoryの監視

- 15.3.2 WebLogic管理対象サーバーの監視

- 15.4 Identity and Access Managementの監査

- 15.5 バックアップとリカバリの実行

- 15.5.1 ベースライン・バックアップの実行

- 15.5.2 ランタイム・バックアップの実行

- 15.5.3 インストール時および構成時のバックアップの実行

- 15.5.3.1 Middlewareホームのバックアップ

- 15.5.3.2 LDAPディレクトリのバックアップ

- 15.5.3.2.1 Oracle Unified Directoryのバックアップ

- 15.5.3.2.2 サード・パーティのディレクトリのバックアップ

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

- 15.5.3.4 WebLogicドメインIAMGovernanceDomainのバックアップ

- 15.5.3.5 WebLogicドメインIAMAccessDomainのバックアップ

- 15.5.3.6 Web層のバックアップ

- 15.5.3.6.1 Oracle HTTP Serverのバックアップ

- 15.6 エンタープライズ・デプロイメントのパッチ適用

- 15.7 SQLのタイムアウトの防止

- 15.8 WebLogic管理サーバーの手動フェイルオーバー

- 15.8.1 OAMHOST2への管理サーバーのフェイルオーバー

- 15.8.2 OAMHOST2上での管理サーバーの起動

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

- 15.8.4 OAMHOST1への管理サーバーのフェイルバック

- 15.9 起動場所の変更

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

- 15.10.1 Identity and Access Managementのデプロイメントのトラブルシューティング

- 15.10.1.1 属性のホストまたはドメイン名のフォーマットが正しくありませんというエラーでデプロイメントが失敗する

- 15.10.1.2 デプロイメントが失敗する

- 15.10.2 起動/停止スクリプトのトラブルシューティング

- 15.10.2.1 領域不足により事前検査が不適切に失敗する

- 15.10.2.2 起動/停止スクリプトが管理対象サーバーの起動または停止に失敗する

- 15.10.3 Oracle Access Management Access Manager 11gのトラブルシューティング

- 15.10.3.1 Access Managerのメモリーが不足している

- 15.10.3.2 セッション数が最大許容値に達した

- 15.10.3.3 Oracle Access Management Access Managerを初めてインストールしたときにポリシーが作成されない

- 15.10.3.4 保護されたリソースにアクセスしても、資格証明を要求するメッセージが表示されない

- 15.10.3.5 Access Managementコンソールにログインできない

- 15.10.4 Oracle Identity Managerのトラブルシューティング

- 15.10.4.1 Oracle Identity Managerの構成実行時のjava.io.FileNotFoundException

- 15.10.4.2 Oracle Identity Managerでのユーザー作成時のResourceConnectionValidationxception

- 15.10.4.3 Oracle Identity Managerのリコンシリエーション・ジョブが失敗する

- 15.10.5 Oracle SOA Suiteのトラブルシューティング

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

A プロセスの自動化

- A.1 setenv.sh

- A.2 setlocalenv.sh

- A.3 deploy.sh

- A.4 スクリプトの使用

B IAMデプロイ再実行前の環境のクリーンアップ

C スケーリングのためのトポロジ・ツール・コマンド

- C.1 トポロジ・ツールの構文

- C.1.1 コマンド

- C.1.2 Addで使用するコマンド行オプション

- C.1.3 Modifyで使用する、ロード・バランサ・マッピングを更新するコマンド行オプション

- C.2 一般的に使用されるコマンド行操作

- C.3 手順とコマンド行の例

- C.3.1 ディレクトリ層のスケール・アウト/スケール・アップ

- C.3.1.1 ディレクトリ層に関する注意

- C.3.1.2 Oracle Unified Directoryをスケーリングするためのトポロジ・ツールの手順

- C.3.1.3 Oracle Unified Directoryのスケール・アウト・コマンド

- C.3.1.4 Oracle Unified Directoryのスケール・アップ・コマンド

- C.3.2 アプリケーション層のスケール・アウト/スケール・アップ

- C.3.2.1 アプリケーション層に関する注意

- C.3.2.2 OAMのトポロジ・ツールの手順

- C.3.2.3 OAMのスケール・アウト・コマンド

- C.3.2.4 OAMのスケール・アップ・コマンド

- C.3.2.5 OIMのトポロジ・ツールの手順

- C.3.2.6 OIMのスケール・アウト・コマンド

- C.3.2.7 OIMのスケール・アップ・コマンド

- C.3.2.8 SOAのトポロジ・ツールの手順

- C.3.2.9 SOAのスケール・アウト・コマンド

- C.3.2.10 SOAのスケール・アップ・コマンド

- C.3.2.11 OAM/OIM/SOAのスケール・アウトのみのためのノード・マネージャの追加手順

- C.3.2.12 OAMのスケール・アウトのためのノード・マネージャ追加コマンド

- C.3.2.13 OIMのスケール・アウトのためのノード・マネージャ追加コマンド

- C.3.2.14 SOAのスケール・アウトのためのノード・マネージャ追加コマンド

- C.3.3 Web層のスケール・アウト/スケール・アップ

- C.3.3.1 Web層に関する注意

- C.3.3.2 OHSをスケーリングするためのトポロジ・ツールの手順

- C.3.3.3 Webのスケール・アウト・コマンド

- C.3.3.4 OHSのスケール・アップ・コマンド

- C.3.3.5 Web層のスケール・アップおよびスケール・アウトのためのOPMNの追加手順

- C.3.3.6 Web層のスケール・アップおよびスケール・アウトのためのOPMNインスタンスの追加コマンド

図一覧

- 2-1 分割ドメイン・トポロジ

- 2-2 Oracle Identity and Access Managementエンタープライズ・デプロイメント処理のフロー・チャート

- 3-1 IP アドレスおよびVIPアドレス: 分散

- 3-2 IP アドレスおよびVIPアドレス: 統合

- 4-1 デプロイメント・リポジトリ

- 4-2 共有記憶域

- 4-3 プライベート記憶域

- 4-4 プライベート・バイナリ記憶域

- 15-1 監査イベント・フロー

表一覧

- 2-1 分散トポロジ内のコンポーネントの場所

- 2-2 統合トポロジ内のコンポーネントの場所

- 2-3 分散トポロジの一般的なハードウェア要件

- 2-4 統合トポロジの一般的なハードウェア要件

- 2-5 使用するソフトウェアのバージョン

- 2-6 ホームの概要

- 2-7 製品パッチ・ディレクトリ

- 2-8 Oracle Identity and Access Managementエンタープライズ・デプロイメント処理の手順

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

- 3-2 VIPアドレスおよび仮想ホスト

- 3-3 Oracle Identity and Access Managementエンタープライズ・デプロイメント・トポロジで使用されるポート

- 4-1 共有記憶域上のボリューム: 分散トポロジ

- 4-2 共有記憶域上のボリューム: 統合トポロジ

- 4-3 プライベート記憶域のディレクトリ

- 5-1 UNIXのカーネル・パラメータ

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

- 5-3 共有記憶域のマウント

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

- 6-2 Oracle Database 11g (11.2.0.2.0)に必要なパッチ

- 6-3 Oracleデータベースの最小初期化パラメータ

- 7-1 ホスト: 分散トポロジ

- 7-2 ホスト: 統合トポロジ

- 7-3 インストール場所

- 7-4 ポート

- 7-5 仮想ホスト

- 7-6 データベース情報

- 7-7 LDAP

- 7-8 ロード・バランサ

- 7-9 電子メール・サーバー(オプション)

- 7-10 ユーザー

- 7-11 OAM

- 12-1 OAAMの詳細

- 13-1 PATH環境変数に必要なファイル

- 13-2 管理対象サーバーの移行

- 15-1 コンソールのURL

- 15-2 Identity and Access Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクト

- 15-3 Identity and Access Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト

Oracle® Fusion Middleware

Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド

11gリリース2 (11.1.2.2.0)

B71694-10(原本部品番号:E48618-05)

2014年9月

このドキュメントは、システム管理者を対象に、Oracle Fusion Middlewareのエンタープライズ・デプロイメントにおける、Oracle Identity and Access Managementコンポーネントのインストールおよび構成方法について説明しています。

Oracle Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド11gリリース2 (11.1.2.2.0)

B71694-10

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

原本主著者: Ellen Desmond(ライター)、Janga Aliminati(設計者)、Michael Rhys(協力エンジニア)

原本協力者: Nagasravani Akula、Christelle Balon、Jeremy Banford、Bruce Jiang、Sindhura Palakodety

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

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

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

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

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

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

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

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

はじめに

ここでは、『Oracle Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド』の対象読者、内容および使用される表記規則について説明します。

対象読者

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

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

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

Oracleサポートへのアクセス

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

関連ドキュメント

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

- Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド

- Oracle Fusion Middleware Oracle Identity and Access Managementデプロイメント・ガイド

- Oracle Fusion Middleware管理者ガイド

- Oracle Fusion Middleware高可用性ガイド

- Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド

- Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド

- Oracle Fusion Middleware Oracle Unified Directory管理者ガイド

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

- Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド

- Oracle Fusion Middleware Oracle Access Management管理者ガイド

- Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド

- Oracle Fusion Middleware Oracle Identity Manager管理者ガイド

- Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド

- Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for Linux

- Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for Solaris Operating System

- Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for HP-UX

- Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for hp Tru64 UNIX

- Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for AIX Based Systems

- Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for Microsoft Windows

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

表記規則

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

規則

意味

太字

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

イタリック

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

固定幅フォント

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

このガイドで説明する新機能

次の各トピックでは、Oracle Identity and Access Managementの新機能と変更機能およびこのガイドで説明する主な変更について紹介し、追加情報へのリンクを示します。

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

Oracle Exalogic Elastic Cloud Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド 11gリリース2 (11.1.2.2)は、コンポーネントのほとんどがIdentity and Access Managementライフサイクル・ツールを使用して構成される点で、前のバージョンと異なります。

このリリースでは、Oracle Internet DirectoryまたはActive Directoryをディレクトリ・ストアとしてサポートしていません。Oracle Internet DirectoryまたはActive Directory用のデプロイメント環境の構成は、デプロイメント処理とは別に実行する必要があります。

最新情報は、「注意: 1662923.1: 『Oracle Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド11gリリース2 (11.1.2.2.0)』のアップグレード」を参照してください。このドキュメントは、My Oracle Support (https://support.oracle.com)で入手できます。

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

この章では、Oracle Identity and Access Managementのエンタープライズ・トポロジの概要について説明します。

この章の構成は、次のとおりです。

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

- 第1.2項「エンタープライズ・デプロイメント・ガイドの規則」

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

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

Oracle Identity and Access Managementはアイデンティティ管理およびアクセス管理全般に対応する総合的な製品スイートです。このガイドでは、Oracle Fusion MiddlewareのOracle Identity And Access Managementインフラストラクチャ・コンポーネント向けの参照エンタープライズ・トポロジを説明します。また、エンタープライズ・デプロイメントのガイドラインに沿ってトポロジを作成するための詳しい手順と推奨事項についても説明します。

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

エンタープライズ・デプロイメントは、定評のあるOracle高可用性テクノロジとOracle Fusion Middlewareに関する推奨事項に基づいた、Oracleベスト・プラクティスの青写真です。このマニュアルに示す高可用性ベスト・プラクティスは、Oracle Database、Oracle Fusion Middleware、Oracle Applications、Oracle Enterprise Manager Cloud Controlなど、技術スタック全体におよぶOracle製品を対象とした様々な高可用性ベスト・プラクティスの1つです。

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

- 様々なビジネス上のサービス・レベル合意(SLA)を考慮し、高可用性に対するベスト・プラクティスを可能なかぎり広範囲に適用できるようにします。

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

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

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

- 各Oracleバージョンと共に内容が向上し、ハードウェアとオペレーティング・システムからは完全に独立しています。

高可用性の実現に関する詳細は、次のOracle Technology Networkで、Oracle Databaseの高可用性のページを参照してください。

http://www.oracle.com/technetwork/database/features/availability/index-087701.html

注意:

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

1.2 エンタープライズ・デプロイメント・ガイドの規則

このガイドで示されているUNIXおよびLinuxのコマンド例はすべて、bashシェルを使用して実行されます。

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

OracleホームやOracleインスタンスなどの一般的な用語は、『Oracle Fusion Middlewareコンセプト・ガイド』の主要概念の理解に関する項を参照してください。

この項では、このガイドで使用されている追加のエンタープライズ・デプロイメント用語について説明します。

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

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

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

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

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

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

- Middlewareホームのソフトウェア

- AdminServerドメイン・ホーム

- JMS

- Tlogs(該当する場合)

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

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

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

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

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

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

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

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

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

注意:

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

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

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

これらについては、以降の章で詳しく説明されています。

1.4 Oracle推奨事項のメリット

このマニュアルで取り上げるOracle Fusion Middleware構成は、すべてのトランザクションのセキュリティの確保、ハードウェア・リソースの最大化、および各種アプリケーションを使用するエンタープライズ・コンピューティングのための標準に準拠した信頼性の高いシステムの提供を目的としています。Oracle Fusion Middleware構成のセキュリティと高可用性のメリットは、ファイアウォール・ゾーンの分離とソフトウェア・コンポーネントのレプリケーションを通じて実現されます。

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

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

- 第1.4.2項「高可用性」

1.4.1 組込みセキュリティ

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

- ポート80 (HTTP_PORT)で受信するすべての外部通信がポート443 (HTTP_SSL_PORT)にリダイレクトされます。

- 外部との通信には、Secure Socket Layer (SSL)セキュアWebプロトコルを使用します。この通信はサイトのロード・バランサで終了します。

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

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

- コンポーネントは、Web層、アプリケーション層およびデータベース層の各ゾーン間で分離されます。

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

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

- LDAPディレクトリはディレクトリ層ゾーンに分離できます。(Oracle Unified Directoryはアプリケーション層ゾーン内に配置されます。)

- Identity And Access Managementコンポーネントはアプリケーション層ゾーン内に配置されます。

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

1.4.2 高可用性

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

2 導入と計画

この章では、このガイドで使用するエンタープライズ・デプロイメント参照用トポロジについて説明します。

エンタープライズ・デプロイメントを成功させるには、計画および準備が重要です。この章の最後にあるインストールと構成のロード・マップでは、実行する必要のあるタスクが記載されている章へと導きます。この章は、このガイドで使用する例を独自のデプロイメントにマップする際に役立ちます。

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

- 第2.1項「デプロイメントの計画」

- 第2.3項「トポロジの理解」

- 第2.4項「エンタープライズ・デプロイメントのハードウェア要件」

- 第2.5項「エンタープライズ・デプロイメントのソフトウェア・コンポーネント」

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

- 2.7項「その他のドキュメント」

2.1 デプロイメントの計画

Identity and Access Managementのエンタープライズ・デプロイメントは、次の部分から構成されます。

- ポリシー情報およびデプロイするアイデンティティおよびアクセス管理コンポーネント固有の情報を格納するための高可用性データベース。

- アイデンティティ情報の作成および管理をサポートし、データベースおよびアイデンティティ・ストア内に格納されたポリシーおよびアイデンティティに基づいてリソースへのアクセスを制限するように高可用性の方法でインストールされたIdentity and Access Managementコンポーネント。Identity and Access Managementコンポーネントは、次の3つのカテゴリに分類できます。

- Directory Services: アイデンティティ情報を格納するための1つ以上の高可用性ディレクトリ

- Identity Managementプロビジョニング: Oracle Identity Manager

- アクセス制御: Oracle Access Management Access Manager

- Identity and Access Managementコンポーネントへのアクセスに使用される高可用性Web層。これらのコンポーネントへのアクセスを制限し、企業のリソースにアクセスしようとする人やプロセスのアイデンティティを確認するために使用されます。

- Webサーバー間に負荷を分散するために使用する高可用性ロード・バランサ。また、このロード・バランサを使用してSSL暗号化をオフロードし、ユーザー・セッションとOracle Identity and Access Managementとの間の通信を確実に暗号化しながらも、個々のIdentity and Access Managementコンポーネント間のSSLを有効にする必要のあるオーバーヘッドをなくすことができます。

これらのコンポーネント・パーツを同時に配置する方法は多数あります。このガイドでは、1つのトポロジをデプロイする方法を詳細に説明します。Oracleがサポートしているのはこのトポロジのみではありませんが、これが最も一般的なものと考えられます。

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

- 第2.1.1項「デプロイメント・トポロジ」

- 第2.1.2項「分割ドメイン・トポロジを使用するメリット」

2.1.1 デプロイメント・トポロジ

トポロジは、コンポーネントのデプロイメント・マップです。Oracle Identity and Access Managementコンポーネントをインストールして、動作するIdentity and Access Managementのソリューションを提供する方法は複数あります。トポロジは、アーキテクチャの青写真としても記述できます。このガイドでは、Oracle Identity and Access Managementの共通のデプロイメント・トポロジを説明します。

Oracle Identity and Access Managementをエンタープライズ・デプロイメントにデプロイする方法は多数あります。2つの最も一般的なデプロイメント・モデルは、すべてを単一のドメインに配置する方法と、運用コンポーネントと管理コンポーネントを別のドメインに分離する方法です。次の図は、分割ドメインのデプロイメント・モデルを示しています。

図2-1 分割ドメイン・トポロジ

この図は、エンタープライズ・トポロジのグラフィカル表示です。これには、ハードウェア・ロード・バランサ、ホスト・コンピュータ、ファイアウォールおよびトポロジのその他の要素を表すアイコンおよび記号が含まれています。上位レベルには、トポロジの主コンポーネントが示されています。このガイドの手順では、このトポロジ用にソフトウェアをインストールして構成する方法を説明します。

詳細は、第2.3項「トポロジの理解」を参照してください。

トポロジは、次の層に分かれます。

2.1.1.1 Web層

2つのサーバーがあり、それぞれがOracle HTTP ServerとOracle Webゲートをホストしています。

2.1.1.2 アプリケーション層

アプリケーション層は、次のコンポーネントで構成されます。

- 各ドメイン用のOracle WebLogic管理サーバー。管理サーバーの内部には、Oracle WebLogicコンソール、Oracle Enterprise Manager Fusion Middleware Control、Access Managementコンソールなど、ドメインの管理およびナビゲーション用のコンポーネントがあります。
WebLogic管理サーバーは、シングルトン・プロセスです。つまり、一度に1つのサーバーでのみ起動できます。管理サーバーを実行しているホストで障害が発生した場合、管理サーバーを別のホストで手動で起動できます。Oracle Access ManagementのWebLogic管理対象サーバーはIAMAccessDomainというドメインに配置され、Oracle Identity Managerの管理対象サーバーおよびSOAコンポーネントはIAMGovernanceDomainというドメインに配置されています。

- Oracle Access Management Access Manager。これは、Access Server、Federationおよび対応するJava Required Files/Oracle Platform Security Servicesプロセスをホストしています。

- Oracle Adaptive Access ManagerサーバーおよびOracle Adaptive Access Management管理および対応するJava Required Files/Oracle Platform Security Servicesプロセス。

- Oracle Identity Manager。これは、Oracle Identity Manager Serverおよび対応するJRF/OPSSプロセスをホストしています。

- Oracle SOA。これは、SOAサーバーおよび対応するJava Required Files/Oracle Platform Security Servicesプロセスをホストしています。

- Oracle Unified Directory。アイデンティティ情報用のLDAPディレクトリです。Oracle Unified Directoryインスタンスは、Oracle Unified Directoryのレプリケーションによって最新に保たれます。

図のアプリケーション層のコンポーネントは、物理ホスト内の論理ホストに示されています。これらの論理ホストは、仮想マシンまたはより低い仕様のハードウェア・サーバーにすることができます。これらのコンポーネントは、論理ホストを使用して分散トポロジ内にデプロイするか、論理ホストが結合されてより大きい物理ホストになる統合トポロジにデプロイできます。

分散トポロジ

分散トポロジでは、アプリケーション層のコンポーネントは次のように配置されます。

表2-1 分散トポロジ内のコンポーネントの場所

マシン

コンポーネント

ドメイン

OAMHOST1

WebLogic管理サーバー

Oracle Access Management Access Manager

Oracle Adaptive Access Manager

IAMAccessDomain

OIMHOST1

WebLogic管理サーバー

Oracle Identity Manager

Oracle SOA

Oracle Authorization Policy Manager

IAMGovernanceDomain

LDAPHOST1

Oracle Unified Directory

OAMHOST2

WebLogic管理サーバー(パッシブ)

Oracle Access Management Access Manager

Oracle Adaptive Access Manager

IAMAccessDomain

OIMHOST2

WebLogic管理サーバー(パッシブ)

Oracle Identity Manager

Oracle SOA

IAMGovernanceDomain

LDAPHOST2

Oracle Unified Directory

統合トポロジ

統合トポロジでは、アプリケーション層のコンポーネントは次のように配置されます。

表2-2 統合トポロジ内のコンポーネントの場所

マシン

コンポーネント

ドメイン

IAMHOST1

WebLogic管理サーバー

Oracle Access Management Access Manager

Oracle Adaptive Access Manager

IAMAccessDomain

WebLogic管理サーバー

Oracle Identity Manager

Oracle SOA

Oracle Authorization Policy Manager

IAMGovernanceDomain

Oracle Unified Directory

IAMHOST2

WebLogic管理サーバー(パッシブ)

Oracle Access Management Access Manager

Oracle Adaptive Access Manager

IAMAccessDomain

WebLogic管理サーバー(パッシブ)

Oracle Identity Manager

Oracle SOA

IAMGovernanceDomain

Oracle Unified Directory

Oracle Adaptive Access Managerは、デプロイメントのオプション・コンポーネントです。

2.1.1.3 データ層

これはデータベースがある場所です。データベースには、アプリケーション層の製品が必要とする顧客データおよびスキーマが含まれています。

2.1.1.4 ロード・バランサ

ロード・バランサは非武装地帯(DMZ)にあり、SSO.mycompany.com、IADADMIN.mycompany.comおよびIDMINTERNAL.mycompany.comで受信したリクエストをOracle HTTPサーバーに転送します。SSO.mycompany.comの場合、リクエストはSSL暗号化されます。これはロード・バランサで終了します。IGDADMIN.mycompany.comおよびIDMINTERNAL.mycompany.comは、HTTPプロトコルを使用してリクエストを処理します。

また、ロード・バランサは、ロード・バランサの仮想ホストであるIDSTORE.mycompany.comを使用して、LDAPリクエストをLDAPHOST1とLDAPHOST2のOracle Unified Directoryインスタンス間に分散します。

2.1.1.5 ファイアウォール

これらは、Web層、アプリケーション層およびデータ層を異なるゾーンに分離するために使用します。WEBHOST1とWEBHOST2はDMZに配置されています。

2.1.2 分割ドメイン・トポロジを使用するメリット

分割ドメイン・トポロジは、デプロイメントの各コンポーネントに対して個別の制御を必要とする大規模な組織に適しています。

分割ドメイン・トポロジの主な長所は、パッチ適用の柔軟性に関係しています。具体的には次のとおりです。

- 各コンポーネント(Oracle Identity ManagerおよびAccess Manager)が異なるドメインに配置されているため、目的のコンポーネントのみを更新するようにパッチを適用できます(ドメイン・レベルのものであっても同様)。

- Oracle Identity Managerなどの管理コンポーネントを制御して停止する必要なくパッチ適用できます。この制御停止は、Access Managerなどの運用コンポーネントの更新では必要です。

2.2 Oracle Directory Services Managerについて

Oracle Directory Services Managerでは、LDAPディレクトリ内にインストールされた構成およびデータに直接アクセスできます。これは、デプロイメント・ツールとみなされるため、エンタープライズ・デプロイメント・トポロジには含まれません。

2.3 トポロジの理解

各トポロジは、セキュリティおよび保護を向上するために複数の層に分割されます。層は、ある層から次の層へのアクセスを制御するファイアウォールによって分離されます。その目的は、未承認のトラフィックを防止することです。たとえば、インターネットに面しているトポロジでは、インターネット領域からデータベースに直接アクセスできないことが必要です。アプリケーション領域にデプロイされているアプリケーションのみがデータベースにアクセスできる必要があります。

図は次の3つの層を示しています。

- Web層

- アプリケーション層

- データベース層

図には表示されていませんが、ディレクトリ層(データベース層に含まれることが多い)も存在できます。専用のディレクトリ層が導入される場合、LDAPディレクトリをこの層内に配置できます。

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

- 第2.3.1項「Web層について」

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

- 第2.3.3項「オプションのディレクトリ層について」

- 第2.3.4項「データベース層について」

2.3.1 Web層について

Web層はDMZパブリック・ゾーンにあります。HTTPサーバーはWeb層にデプロイされます。

Identity and Access Managementコンポーネントの多くはWeb層なしで動作できますが、エンタープライズ・デプロイメントではWeb層が望ましいことが多くなります。Oracle Single Sign-OnやAccess Managerなどの製品を使用して全社レベルのシングル・サインオンをサポートするには、Web層が必要です。

Oracle Enterprise Manager Fusion Middleware ControlやWebLogicコンソールなどのコンポーネントはWeb層なしで動作できますが、必要に応じてWeb層を使用するように構成できます。

Web層:

- WEBHOST1とWEBHOST2には、Oracle HTTP Server、Webゲート(Access Managerコンポーネント)およびmod_wl_ohsプラグイン・モジュールがインストールされています。mod_wl_ohsプラグイン・モジュールにより、アプリケーション層で実行されているWebLogic ServerにOracle HTTP Serverからリクエストをプロキシすることができます。

- Oracle HTTP ServerのWebゲート(Oracle Access Management Access Managerコンポーネント)は、Oracle Accessプロトコル(OAP)を使用して、アイデンティティ管理ゾーンのOAMHOST1およびOAMHOST2上で実行するAccess Managerと通信します。WebゲートとAccess Managerは、ユーザー認証などの操作の実行に使用されます。

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

2.3.1.1 アーキテクチャに関する注意

WEBHOST1とWEBHOST2上のOracle HTTP Serverはmod_wl_ohsで構成され、これらのサーバーは、OAMHOST1、OAMHOST2、OIMHOST1およびOIMHOST2上にあるWebLogic ServerにデプロイされたOracle Identity and Access Management J2EEアプリケーションへのリクエストをプロキシします。

2.3.1.2 高可用性プロビジョニング

Oracle HTTPサーバーがWEBHOST上で障害が発生した場合、Oracle Process Management and Notification (OPMN)サーバーはこれを再起動しようとします。

2.3.1.3 セキュリティ・プロビジョニング

URL SSO.mycompany.com、IGDADMIN.mycompany.comおよびIADADMIN.mycompany.comを使用して受信したリクエストをOracle HTTP Serverで処理します。IADADMIN.mycompany.comおよびIGDADMIN.mycompany.comの名前は、ファイアウォール内でのみ解決可能です。これによって、Oracle WebLogic ServerコンソールやOracle Enterprise Manager Fusion Middleware Controlコンソールなどの機密リソースをパブリック・ドメインからアクセスされないようになります。

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

アプリケーション層は、Java EEアプリケーションが配置される層です。Oracle Identity Manager、Oracle Enterprise Manager Fusion Middleware Controlなどの製品が、この層にデプロイできる主要なJava EEコンポーネントです。この層にあるアプリケーションは、Oracle WebLogic Serverの高可用性サポートにおけるメリットを享受します。

アプリケーション層にあるIdentity and Access Managementアプリケーションは、次に示すようにディレクトリ層と対話的に処理を行います。

- エンタープライズ・アイデンティティ情報についてはディレクトリ層が活用されます。

- 場合によっては、アプリケーション・メタデータではディレクトリ層(およびデータ層のデータベースの場合もある)が活用されます。

- Oracle Enterprise Manager Fusion Middleware Controlは、アプリケーション層だけでなくディレクトリ層にもあるコンポーネントに対して管理機能を提供する管理ツールです。

- WebLogic Serverには、Webサーバーのサポートが組み込まれています。有効にされていると、HTTPリスナーはアプリケーション層にも配置されます。ただし、図1-1に示したエンタープライズ・デプロイメントでは、お客様はApacheやOracle HTTP ServerなどのWebサーバーに依存する別のWeb層を使用しています。

アプリケーション層には、次のコンポーネントがあります。これらのアプリケーション層内の場所は、表2-1「分散トポロジ内のコンポーネントの場所」および表2-2「統合トポロジ内のコンポーネントの場所」に記載されています。

- Oracle Access Management Access Manager (OAM)。これは、Oracle WebLogic Server内で実行されるJ2EEアプリケーションです。

- Oracle Adaptive Access Manager (OAAM)。

- Oracle Identity ManagerおよびOracle Entitlements Server Policy Manager。これらはユーザー・プロビジョニングおよびポリシー管理に使用されます。

- ガバナンス・コンポーネント。Oracle Authorization Policy Manager (APM)、Oracle Identity Manager (OIM)およびOracle SOA Suite (SOA)。

- Oracle Identity ManagerなどのIdentity and Access Managementの管理コンポーネント。これはユーザー・プロビジョニングに使用されます。注意: これらのサーバーは、Oracle Identity Managerによって排他的に使用されるOracle SOAも実行します。Oracle Identity Manager (OIM)はディレクトリ層と通信します。

さらに、次のような特徴があります。

- 分散トポロジのOAMHOST1または統合トポロジのIAMHOST1。IAMAccessDomain用のOracle WebLogic管理サーバーをホストします。管理サーバーの内部には、Oracle WebLogicコンソール、Oracle Enterprise Manager Fusion Middleware Control、Access Managementコンソールなど、ドメインの管理およびナビゲーション用のコンポーネントがあります。

- 分散トポロジのOIMHOST1または統合トポロジのIAMHOST1。IAMGovernanceDomain用のOracle WebLogic管理サーバーをホストします。管理サーバーの内部には、Oracle WebLogicコンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Authorization Policy Managerなど、ドメインの管理およびナビゲーション用のコンポーネントがあります。

- WebLogic管理サーバーは、シングルトン・プロセスです。つまり、一度に1つのサーバーでのみ起動できます。管理サーバーを実行しているホストで障害が発生した場合、管理サーバーを別のホストで手動で起動できます。

2.3.2.1 WebLogicドメインについて

ドメインは、WebLogic Serverインスタンスの基本的な管理単位です。ドメインは、単一の管理サーバーを使用して管理する1つ以上のWebLogic Serverインスタンス(およびその関連リソース)から構成されています。様々なシステム管理者の責任、アプリケーション境界、またはサーバーの地理的な場所に基づいて複数のドメインを定義できます。一方で、1つのドメインを使用して、すべてのWebLogic Server管理アクティビティを集中管理できます。

ガイドのこのバージョンで使用されるトポロジでは、アクセス・ドメインおよびガバナンス・ドメインは、カスタマ・アプリケーションがデプロイされる可能性のあるドメインとは別のWebLogic Serverドメインにあります。Oracle Identity Managerは、他の製品に依存せずにパッチ適用できるように個別の専用ドメインにデプロイされます。

2.3.2.2 LDAPディレクトリについて

アイデンティティ情報は、LDAP対応ディレクトリに格納されます。この実装では、これはOracle Unified Directoryになります。Oracle Unified Directoryは、記憶域、プロキシ、同期および仮想機能を持つオールインワンのディレクトリ・ソリューションです。これにより、何十億ものエントリに対するスケーラビリティ、容易なインストール、順応性のあるデプロイメント、エンタープライズの管理性および効率的な監視が可能になります。この柔軟なデプロイメント・アーキテクチャにより、アプリケーション要件を満たす高いパフォーマンス・レベルが提供されます。

注意:

このリリースの『Oracle Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド』では、Oracle Internet DirectoryおよびActive Directoryをディレクトリ・ストアとしてサポートしていません。Oracle Internet DirectoryまたはActive Directory用のデプロイメント環境の構成は、デプロイメント処理とは別に実行する必要があります。

標準的なLDAPポートは、非SSLポートでは389 (LDAP_LBR_PORT)になり、SSLポートでは636 (LDAP_LBR_SSL_PORT)になります。イントラネットの電子メール・クライアントなどのクライアントによりホワイト・ページが検索される際に、LDAPサービスが使用されることがあります。ロード・バランサ上のポート389と636は、通常、個々のディレクトリ・インスタンスによって使用される権限のないポートにリダイレクトされます。LDAPリクエストは、ハードウェア・ロード・バランサを使用してOracle Unified Directoryホスト間に分散されます。

多くの組織には、既存のディレクトリ・デプロイメントがあります。既存のデプロイメントがない場合、このガイドを使用して、このロールを引き受けるようにOracle Unified Directoryを構成する方法を学習できます。既存のディレクトリがある場合、このガイドを使用して、そのディレクトリを構成してOracle Identity and Access Managementで使用する方法を学習できます。ディレクトリがなく、Oracle Unified Directory以外のディレクトリを使用する場合、これらのディレクトリを高可用性の方法で構成する方法の詳細は、ディレクトリのドキュメントを参照してください。

Oracle Unified Directoryは、Berkeleyデータベースに情報をローカルに格納します。高可用性を確保するために、Oracle Unified Directoryレプリケーションを使用して、この情報が別のOracle Unified Directoryインスタンスにレプリケーションされます。

Oracle Unified Directoryサーバー・インスタンスは、本来、レプリケーションを使用して、埋込みデータベースの同期状態を保持します。デフォルトでは、レプリケーションは、操作結果がアプリケーションに戻った後に更新をレプリカにレプリケーションするゆるやかな一貫性モデルを使用します。したがってこのモデルでは、データをレプリカに書き込んでから、書込みの少し後に古い情報を別のレプリカから読み取ってしまう可能性があります。レプリケーション・プロセスが高速で1ミリ秒の桁で達成できるように、Oracle Unified Directoryレプリケーションで多くの作業が行われました。

レプリカ内のデータの一貫性を保証するように開発された保証レプリケーション・モデルを使用するようにOracle Unified Directoryを構成できます。保証レプリケーションの安全読取りモードを使用すると、アプリケーションは、レプリケーション・プロセスが書込み操作の結果を返す前に完了することを保証します。

保証レプリケーションを使用すると、書込み操作の応答時間に悪影響があります。これは、保証レプリケーションではリモート・レプリカとの通信の後に操作結果を返す必要があるためです。遅延時間は、使用するネットワークおよびOracle Unified Directoryをホストしているサーバーの容量によって異なります。保証レプリケーションを使用しても、読取り操作への影響はほとんどありません。

ディレクトリへの大量の書込みを定期的に実行することが予想される場合、ロード・バランサを構成して、アクティブ/パッシブ・モードでOracle Unified Directoryインスタンスにリクエストを分散することを検討してください。こうすることによって、レプリカから古いデータ読み取る機会がなくなりますが、使用しているOracle Unified Directoryホストがすべてのリクエストを処理する能力がない場合、全体のパフォーマンスが低下する可能性があります。

このガイドの目的のために、複数のサーバーにリクエストを処理させる機能の方が保証モードでのリクエストの書込みによって生じる追加のオーバーヘッドより重要であると想定されます。この目的のために、このガイドでは、保証レプリケーションを使用したOracle Unified Directoryの構成を示します。ただし、次のOracle Unified Directoryの構成は両方ともサポートされます。

- 保証構成のアクティブ/アクティブ

- 非保証構成のアクティブ/パッシブ

詳細は、Oracle Fusion Middleware Oracle Unified Directory管理者ガイドの保証レプリケーションに関する項を参照してください。

Oracle Unified Directoryは、通常、内部変更番号を使用して変更を追跡します。変更番号は、各Oracle Unified Directoryインスタンス固有で、あるOracle Unified Directoryインスタンスで障害が発生し、レプリケーションされるエントリがない場合に問題となる可能性があります。このような障害は、Oracle Identity Managerのリコンシリエーションに影響する可能性があります。

注意:

Oracle Unified Directoryで障害が発生しても、自動的には再起動されません。Oracle Unified Directoryは、ロード・バランサによって正常なインスタンスにリダイレクトするリクエストを待ちます。

2.3.2.3 アーキテクチャに関する注意

- Oracle Entitlement Serverの埋込みバージョンは、Oracle Fusion Middlewareコンポーネントへのアクセス制御に使用されます。

- Oracle Entitlements Serverは、データベース内に格納されている集中管理されたポリシー・ストアを使用します。

- Oracle Adaptive Access Managerは、オプション・コンポーネントです。

- Access Managerは、OPSSポリシー・ストアを使用して、ポリシー情報を格納します。

- 分割ドメイン構成では、Oracle Identity ManagerおよびSOAは、他のコンポーネントから分離されたドメインにインストールされます。

- Oracle WebLogic Serverコンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびAccess Managementコンソールは、常に管理サーバーのリスニング・アドレスにバインドされます。

- WebLogic管理サーバーはシングルトン・サービスです。一度に1つのノード上でのみ実行されます。障害が発生した場合は、正常なノード上で再起動されます。

- 管理対象サーバーWLS_OAM1およびWLS_OAM2はクラスタにデプロイされ、Access Managerアプリケーションはそのクラスタにデプロイされます。

- 管理対象サーバーWLS_OIM1およびWLS_OIM2はクラスタにデプロイされ、Identity Managerアプリケーションはそのクラスタにデプロイされます。

- 管理対象サーバーWLS_SOA1およびWLS_SOA2はクラスタにデプロイされ、Identity Managerアプリケーションはそのクラスタにデプロイされます。

2.3.2.4 高可用性プロビジョニング

- Access Manager Server、Oracle Identity ManagerおよびSOAはアクティブ/アクティブ・デプロイメントです。これらのサーバーは実行時にデータ層と通信します。

- WebLogic管理サーバーとOracle Enterprise Managerのデプロイメントは、アクティブ/パッシブです(他のコンポーネントはアクティブ/アクティブ)。ドメインごとに1つの管理サーバーがあります。

- WebLogic管理サーバーは、アクティブ/パッシブ構成でデプロイされるシングルトン・コンポーネントです。プライマリに障害が発生したときや、管理サーバーが割り当てられたホスト上で起動しない場合、セカンダリ・ホスト上で管理サーバーを起動できます。WebLogic管理対象サーバーで障害が発生すると、このホストで動作しているノード・マネージャはこのサーバーの再起動を試行します。

2.3.2.5 セキュリティ・プロビジョニング

Oracle WebLogic Serverコンソール、Oracle Enterprise Manager Fusion Middleware ControlコンソールおよびOracle Access Managementコンソールには、ロード・バランサ上に構成された仮想ホスト経由でのみアクセスできます。このロード・バランサは、ファイアウォール内でのみ使用できます。

2.3.3 オプションのディレクトリ層について

このガイドでは、通常アプリケーション層に配置されているOracle Unified Directoryの使用を扱っているため、第2.1.1項「デプロイメント・トポロジ」ではディレクトリ層は示していません。また、通常ディレクトリ層はファイアウォールで保護されているため、セキュリティを向上するためにOracle Unified Directoryをディレクトリ層に配置できます。ディレクトリ層より上にあるアプリケーションは、指定LDAPホスト・ポート(管理ポートの場合もあります。管理ポートは、そのファイアウォールで開く必要があります)によりLDAPサービスにアクセスします。

通常ディレクトリ層は、エンタープライズLDAPサービスをサポートするディレクトリ管理者が管理します。

2.3.4 データベース層について

11gリリース2 (11.1.2)以降、ポリシー情報はデータベースに格納されます。このデータベースは、デプロイされるIdentity and Access Managementコンポーネント固有の情報の格納にも使用されます。

場合によっては、ディレクトリ層とデータ層は同じ管理者グループで管理することもあります。ただし、多くの企業ではデータベース管理者がデータ層を所有し、ディレクトリ管理者がディレクトリ層を所有しています。

ダイアグラムには示されていませんが、ディレクトリをデータベース層に配置してセキュリティを向上する必要がある場合があります。

2.4 エンタープライズ・デプロイメントのハードウェア要件

分散トポロジまたは統合トポロジのいずれかをデプロイできます。統合トポロジは、少数の強力なサーバーを使用し、デプロイメントを単純にします。ただし、このような強力なサーバーの使用は必須ではありません。分散トポロジは、小規模のサーバーを多数使用します。

これらのサーバーは、表2-3「分散トポロジの一般的なハードウェア要件」または表2-4「統合トポロジの一般的なハードウェア要件」で示された最小仕様を備えている必要があります。

詳細要件またはその他のプラットフォームの要件は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

表2-3 分散トポロジの一般的なハードウェア要件

サーバー

プロセッサ

ディスク

メモリー

TMPディレクトリ

スワップ

データベース・ホストIAMDBHOSTn

1.5GHz以上で動作するX Pentiumが4個以上

nXm

n=ディスク数。最小4個(1個のディスクとしてストライプ化)

m=ディスクのサイズ(最小30GB)

6から16GB

デフォルト

デフォルト

WEBHOSTn

1.5GHz以上で動作するX Pentiumが2個以上

10GB

4GB

デフォルト

デフォルト

OIMHOSTn

1.5GHz以上で動作するX Pentiumが6個以上

10GB

8GB

デフォルト

デフォルト

OAMHOSTn

1.5GHz以上で動作するX Pentiumが6個以上

10GB

8GB

デフォルト

デフォルト

LDAPHOSTn

1.5GHz以上で動作するX Pentiumが2個以上

10GB

4GB

デフォルト

デフォルト

表2-4 統合トポロジの一般的なハードウェア要件

サーバー

プロセッサ

ディスク

メモリー

TMPディレクトリ

スワップ

データベース・ホストIAMDBHOSTn

1.5GHz以上で動作するX Pentiumが4個以上

nXm

n=ディスク数。最小4個(1個のディスクとしてストライプ化)

m=ディスクのサイズ(最小30GB)

6から16GB

デフォルト

デフォルト

WEBHOSTn

1.5GHz以上で動作するX Pentiumが2個以上

25GB

4GB

デフォルト

デフォルト

IAMHOSTn

1.5GHz以上で動作するX Pentiumが6個以上

30GB

25GB

デフォルト

デフォルト

これらは標準的なハードウェア要件です。層ごとに、負荷、スループット、応答時間などの要件を慎重に考慮して、実際に必要な容量を計画してください。必要なノード数、CPU、およびメモリーは、デプロイメント・プロファイルに応じて層ごとに異なる可能性があります。本番での要件は、アプリケーションおよびユーザー数によって異なる場合があります。

このガイドで説明するエンタープライズ・デプロイメント構成は、それぞれの層に2つのサーバーを使用して、フェイルオーバー機能を提供します。ただし、アプリケーションまたはユーザーの入力に対して適切な計算リソースとはみなされません。システムのワークロードが増えてパフォーマンスが低下する場合、第14.4項「Web層のスケーリング」の説明に従ってWebLogicサーバーまたはディレクトリ/OHSインスタンスを追加できます。

注意:

オペレーティング・システム・レベル、パッチ・レベル、ユーザー・アカウント、およびユーザー・グループに関して、トポロジ内のノードすべての構成を同一にすることをお薦めします。

2.5 エンタープライズ・デプロイメントのソフトウェア・コンポーネント

この項では、Oracle Identity and Access Managementエンタープライズ・デプロイメントで必要なソフトウェアについて説明します。

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

- 2.5.1項「ソフトウェアのバージョン」

- 第2.5.2項「ソフトウェアの入手について」

- 第2.5.3項「Oracleホームのまとめ」

- 第2.5.4項「パッチおよび回避策の適用」

2.5.1 ソフトウェアのバージョン

表2-5「使用するソフトウェアのバージョン」に、このガイドの手順を開始する前に入手しておく必要があるOracleソフトウェアを示します。

図2-5 使用するソフトウェアのバージョン

短縮名

製品

バージョン

OHS11G

Oracle HTTP Server

11.1.1.7.0

JRockit

Oracle JRockit

jrockit-jdk1.6.0_29-R28.2.0-4.0.1以降

WLS

Oracle WebLogic Server

10.3.6.0

IAM

Oracle Identity and Access Management

11.1.2.2.0

SOA

Oracle SOA Suite

11.1.1.7.0

WebGate

WebGate 11g

11.1.2.2.0

RCU

リポジトリ作成アシスタント

11.1.2.2.0

OUD

Oracle Unified Directory

11.1.2.2.0

2.5.2 ソフトウェアの入手について

Oracle Identity and Access Management 11gリリース2 (11.1.2.2)の自動インストールを実行するには、Oracle Identity and Access Managementデプロイメント・リポジトリ11.1.2.2.0を次からダウンロードします。

- Oracle Software Delivery Cloud: http://edelivery.oracle.com/

- Oracle Identity and Access Managementのダウンロード・ページ: http://www.oracle.com/technetwork/middleware/id-mgmt/downloads/oid-11gr2-2104316.html

注意:

- 2014年4月8日より前のバージョンのOracle Identity and Access Managementデプロイメント・リポジトリをダウンロードした場合は、次の手順に進む前に、新しいバージョンで置き換える必要があります。

- 64ビットのLinuxマシン(32ビット・システム・ライブラリを使用できない場合)でRCUを実行している場合は、互換性のために、該当のライブラリをインストールするか、64ビット・バージョンのRCU 11.1.2.2.0を個別にダウンロードし、デプロイメント・リポジトリに存在するライブラリのかわりに使用します。

Oracle Fusion Middlewareソフトウェアの詳細なダウンロード方法は、http://docs.oracle.com/cd/E23104_01/download_readme.htmのこのリリースのOracle Fusion Middlewareのダウンロード、インストールおよび構成のReadMeファイルを参照してください。

2.5.3 Oracleホームのまとめ

OracleバイナリはOracle Fusion Middlewareホームにインストールされます。個別の製品は、Middlewareホーム内のOracleホームにインストールされます。表2-6は、このドキュメントで使用するMiddlewareホームとOracleホームのまとめです。

Oracle Identity Managementのインストールと構成は、このガイドでは説明しません。詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

表2-6 ホームの概要

ホーム名

ホームの説明

インストールされる製品

IAD_MW_HOME

Oracle Identity Managerで必要なORACLE_HOMEを含むOracle Middlewareホーム。

IGD_MW_HOME

Oracle Access Managerで必要なORACLE_HOMEを含むOracle Middlewareホーム。

DIR_MW_HOME

Oracle Unified Directoryで必要なORACLE_HOMEを含むOracle Middlewareホーム。

WL_HOME

これは、Oracle WebLogic Serverがインストールされるルート・ディレクトリです。WL_HOMEディレクトリは、Oracleホーム・ディレクトリのピアであり、MW_HOME内にあります。

Oracle WebLogic Server

IAD_ORACLE_HOME

Oracle Identity and Access Managementに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します。IAD_MW_HOME/iam内にあります。

Access Manager

IGD_ORACLE_HOME

Oracle Identity and Access Managementに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します(IGD_MW_HOME/iam内にあります)。

Oracle Identity Manager

OUD_ORACLE_HOME

Oracle Unified Directoryに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します。IAD_MW_HOME/oud内にあります。

Oracle Unified Directory

WEBGATE_ORACLE_HOME

Oracle Webゲートのバイナリを格納します。WEB_MW_HOME/web内にあります。

Oracle Webゲート

SOA_ORACLE_HOME

Oracle SOA Suiteに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します。IGD_MW_HOME/soa内にあります。

Oracle SOA Suite

ORACLE_COMMON_HOME

汎用Oracleホーム・ファイルを格納します。このOracleホームは、いずれかの製品をインストールすると自動的に作成され、MW_HOME/oracle_common内にあります。

汎用コマンド

LCM_HOME

ライフサイクル・リポジトリ。

REPOS_HOME

ソフトウェア・リポジトリ。

WEB_MW_HOME

Web層で必要なORACLE_HOMEを含むOracle Middlewareホーム。

WEB_ORACLE_HOME

Oracle HTTP Serverに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します。

2.5.4 パッチおよび回避策の適用

適用するパッチのリストは、使用中のプラットフォームおよびオペレーティング・システムに関するOracle Fusion Middlewareリリース・ノートを参照してください。ソフトウェアを期待どおりに動作させるには、パッチを適用する必要があります。

パッチはhttp://support.oracle.comからダウンロードできます。各パッチをデプロイする手順は、同封のREADME.htmlファイルにあります。

デプロイメントを開始する前に、リリース・ノートにリストされたパッチと、使用している環境に該当する他のパッチをダウンロードします。これらのパッチは、デプロイメント・ツールにより実行時に自動的に適用できます。

http://support.oracle.comからパッチをダウンロードし、表2-7に示される、製品に該当するディレクトリに各パッチを解凍します。ディレクトリが存在しない場合は作成します。

パッチの解凍後、(表2-7に示される)パッチ・ディレクトリに数字のディレクトリが含まれていることを確認します。ディレクトリには、次のようなディレクトリやファイルが含まれます。

- etc

- files

- README.txt

これが大半のパッチのディレクトリ・レイアウトです。バンドル・パッチなどの一部のケースでは、レイアウトは次のようになる場合があります。

bundle_patch_no/product/product_patch_no

この場合、パッチ・ディレクトリに現れるのは、bundle_patch_noではなく、product_patch_noとなるようにします。

バンドル・パッチに複数の製品の修正が含まれる場合、個々のパッチが次に示されるように正しいパッチ・ディレクトリに現れるようにします。

表2-7 製品パッチ・ディレクトリ

製品

パッチ・ディレクトリ

Oracle共通

REPOS_HOME/installers/oracle_common/patch

ディレクトリ

REPOS_HOME/installers/oud/patch/oud

REPOS_HOME/installers/oud/patch/odsm

Oracle Access Management Access Manager

REPOS_HOME/installers/iamsuite/patch/oam

OHS

REPOS_HOME/installers/webtier/patch

WebGate

REPOS_HOME/installers/webgate/patch

Oracle Identity Manager

REPOS_HOME/installers/iamsuite/patch/oim

SOA

REPOS_HOME/installers/soa/patch

WebLogic Server

REPOS_HOME/installers/weblogic/patch

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

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

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

- 第2.6.1項「Oracle Identity and Access Managementエンタープライズ・デプロイメント処理のフロー・チャート」

- 第2.6.2項「Oracle Identity and Access Managementエンタープライズ・デプロイメント処理の手順」

2.6.1 Oracle Identity and Access Managementエンタープライズ・デプロイメント処理のフロー・チャート

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

図2-2 Oracle Identity and Access Managementエンタープライズ・デプロイメント処理のフロー・チャート

2.6.2 Oracle Identity and Access Managementエンタープライズ・デプロイメント処理の手順

表2-8では、図2-2で示したOracle Identity and Access Managementのエンタープライズ・デプロイメント処理のフロー・チャートの各手順を説明します。この表では、処理における各手順の詳細について、その参照先も示します。

表2-8 Oracle Identity and Access Managementエンタープライズ・デプロイメント処理の手順

手順

説明

詳細情報

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

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

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

エンタープライズ・デプロイメント用の記憶域の準備

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

第4章「エンタープライズ・デプロイメント用の記憶域の準備」

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

エンタープライズ・デプロイメント用のサーバーを準備するには、サーバーがハードウェア要件およびソフトウェア要件を満たしていることを確認し、Unicodeサポートおよび仮想IPアドレスを有効にし、共有記憶域をマウントし、ユーザーおよびグループを構成し、必要に応じてソフトウェアを複数のホームを持つシステムにインストールします。

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

自動化の準備(オプション)

必要に応じて、1コマンド・デプロイメント用のスクリプトを用意します。

付録A「プロセスの自動化」

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

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

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

デプロイの準備

デプロイメントの準備をするには、必要な情報を収集し、リポジトリを作成し、Javaを検証し、ツールをインストールして、ポート可用性を検証します。

第7章「デプロイの準備」

デプロイメント・プロファイルの作成

ウィザードを実行してデプロイメント・レスポンス・ファイルを作成します。

第8章「デプロイメント・プロファイルの作成」

Identity and Access Managementのデプロイ

ツールを使用してデプロイメントのすべてのステージを実行します。

第9章「Identity and Access Managementのデプロイ」

デプロイ後構成の実行

デプロイ後タスクを実行します。

第10章「デプロイ後構成の実行」

デプロイメントの検証

検証チェックを行います。

第11章「デプロイメントの検証」

Oracle Adaptive Access Managerを追加するためのドメインの拡張

このオプションのコンポーネントとともにドメインを拡張します。

第12章「Oracle Adaptive Access Managerを追加するためのドメインの拡張」

2.7 その他のドキュメント

最新情報は、「注意: 1662923.1: 『Oracle Fusion Middleware Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド11gリリース2 (11.1.2.2.0)』のアップグレード」を参照してください。このドキュメントは、My Oracle Support (https://support.oracle.com)で入手できます。

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

この章では、Oracle Identity and Access Managementインフラストラクチャのエンタープライズ・デプロイメント・トポロジの前提条件について説明します。

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

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

- 第3.2項「ネットワークの計画」

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

- 第3.4項「ハードウェア・ロード・バランサの構成」

- 第3.5項「IPアドレスおよび仮想IPアドレスについて」

- 第3.6項「ファイアウォールとポートの構成」

- 第3.7項「Access Manager通信プロトコルの管理」

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

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

3.2 ネットワークの計画

第2.3項「トポロジの理解」のデプロイメント・トポロジの図に示すように、各デプロイメントは複数のゾーン間に広げることができます。ゾーンは、インフラストラクチャのコンポーネントへのアクセスを実際にアクセスを必要とする人に制限する方法です。このガイドの例では、2つのゾーンを示します。

- パブリック・ゾーン: ここでは外部からシステムにアクセスできます。ロード・バランサやWeb層など外部からアクセスする必要があるコンポーネントのみをこのゾーンに配置します。このゾーンの下の任意のサーバーまたはサービスに外部のユーザーがアクセスしようとすると、ファイアウォールがアクセスを阻止します。
パブリック・ゾーンは、このゾーンのサーバーがプライベート・ゾーンのアプリケーション・サーバーとやり取りできるように構成されます。

- イントラネットゾーン: これは、データベースなどのコア・サービスを含むサーバーを配置する場所です。これらのサービスは、最も機密性の高いデータが含まれているため、組織によって非常に厳密に制御されます。

この方法を使用することによって、情報を必要とするコンポーネントのみに情報へのアクセスを制限します。この方法は、組織の外部のユーザーがいる場合に有効です。

エクストラネットのかわりに(すべての通信が信頼できるソースからである)イントラネットを設定している場合、ゾーンの1つまたは複数を合理的に廃棄できる場合があります。

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

仮想サーバー名は、組織で使用される実際のホスト名のIDを隠すために使用され、アプリケーションへのエントリ・ポイントとして使用されます。

仮想サーバー名を使用する利点の1つは、新しいホスト名でアプリケーションを再構成する必要なく、バックエンド・サーバー名を変更できることです。

仮想サーバー名を使用する他の利点は、これらのサーバー名をロード・バランサに追加することで、ロード・バランサで単一の名前を使用して、同じ機能の複数のバックエンド・サーバー間でリクエストを分散できることです。これにより、可用性が実現し、スケーラビリティを簡単に向上できます。

ロード・バランサに追加すると、アプリケーションとクライアント間で暗号化されたトラフィックの維持をアプリケーションで可能にする、SSLをロード・バランサで終了することもできますが、同時に、各コンポーネント間でトラフィックを暗号化する必要なく、アプリケーションを効率的に実行できます。

仮想サーバー名は、組織のDNSサーバーに含まれます。外部アプリケーションのエントリは外部DNSサーバーに構成されます。

これにより、公衆アクセス・ポイントがインターネットで解決可能になり、プライベート・アクセス・ポイントを組織内でのみ使用可能にすることができます。

Premのみ:

IDSTORE.mycompany.comやIDMINTERNALなどの仮想サーバーの一部では、DNSから一緒に除外し、使用中のこれらのサーバーのみを解決する必要が生じる場合があります。

両方:

仮想サーバー名は単一のIPアドレスに解決されます。このIPアドレスは、ロード・バランサの仮想ホストに関連付けられます。

Exalogic:

- IDSTORE.mycompany.com

- IADADMIN.mycompany.com

- IGDADMIN.mycompany.com

- IDMINTERNAL.mycompany.com

- SSO.mycompany.com

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

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

このガイドの残りの部分では、デプロイメントは第2章「導入と計画」で示したデプロイメントの1つであることを前提とします。

3.3.1 IDSTORE.mycompany.com

- この仮想サーバーは、すべてのアイデンティティ・ストアのLDAPトラフィックのアクセス・ポイントとして機能します。SSLと非SSLの両方へのトラフィックが構成されます。クライアントは、アドレスIDSTORE.mycompany.com:636 (SSLの場合)およびIDSTORE.mycompany.com:389(非SSLの場合)を使用してこのサービスにアクセスします。

- Oracle Unified Directoryのアイデンティティ・ストアが直接アクセスされたため、Oracle Unified Directoryプロセスのハートビートを監視する必要があります。Oracle Unified Directoryプロセスが停止した場合、ロード・バランサは稼動しているOracle Unified DirectoryインスタンスへのLDAPトラフィックのルーティングを継続する必要があります。

- この仮想サーバーは、ポート389 (LDAP_LBR_PORT)で受信したトラフィックを、ポート1389 (LDAP_DIR_PORT)でOracle Unified Directoryの各インスタンスに転送します。

- この仮想サーバーは、ポート1636 (LDAP_LBR_SSL_PORT)で受信したトラフィックを、ポート1636 (LDAP_DIR_SSL_PORT)でOracle Unified Directoryの各インスタンスに転送します。

- この仮想サーバーは、ローカル(Exalogic内)でのみ解決可能です。

3.3.2 IADADMIN.mycompany.com

- この仮想サーバーは、アクセス・ドメイン内の管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスIADADMIN.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (WEB_HTTP_PORT)に転送されます。この仮想ホスト上でアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Controlなどがあります。

- この仮想サーバーは、企業のDNSでのみ解決可能です。

- ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/console、/oamconsole、/oaam_adminおよび/emのURLにアクセスすることを防止します。DMZ内部のトラフィックのみがIADADMINVHN.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。

3.3.3 IGDADMIN.mycompany.com

- この仮想サーバーは、ガバナンス・ドメイン内の管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスIGDADMIN.mycompany.com:80 (HTTP_PORT)を使用してこのサービスにアクセスし、続いてトラフィックがWEBHOST1およびWEBHOST2のポート7777(WEB_HTTP_PORT)に転送されます。この仮想ホストでアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Authorization Policy Managerなどがあります。

- ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/sysadmin、/apm、/consoleおよび/emのURLにアクセスすることを防止します。DMZ内部のトラフィックのみがIGDADMINVHN.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。

- この仮想サーバーは、企業のDNSでのみ解決可能にする必要があります。

3.3.4 IDMINTERNAL.mycompany.com

- クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスIDMINTERNAL.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (WEB_HTTP_PORT)に転送されます。SOA管理対象サーバーは、この仮想ホストにアクセスして、Oracle Identity Manager Webサービスのコールバックを行います。

- ファイアウォールでルールを作成し、外部トラフィックがこの仮想ホストにアクセスすることを防止します。DMZ内部のトラフィックのみがIDMINTERNAL.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。

- この仮想サーバーは、ローカルまたは企業のDNSのいずれかで解決可能にする必要があります。

- IDMINTERNALはプロセス間通信用に設計されているため、これをDNSには含めず、内部ホスト・ファイル内でのみ解決可能にすることが期待されます。

3.3.5 SSO.mycompany.com

- これは、すべてのIdentity and Access Managementコンポーネント(Access Management、Oracle Identity Managerなど)に対する仮想名です。

- この仮想サーバーは、シングル・サインオン・サービスへ送信されるすべてのHTTPトラフィックのアクセス・ポイントとして機能します。クライアントからの受信トラフィックはSSLに対応しています。このため、クライアントはアドレスSSO.mycompany.com:443を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (WEB_HTTP_PORT)に転送されます。シングル・サインオン対応の保護リソースへのアクセスは、すべてこの仮想ホスト上で行われます。

- ロード・バランサでポート80 (HTTP_PORT)とポート443 (HTTP_SSL_PORT)の両方を使用してこの仮想サーバーを構成します。

- この仮想サーバーは、ローカルまたは企業のDNSのいずれかで解決可能にする必要があります。

- この仮想ホストは、リクエストのクライアントIPアドレスを保持するように構成する必要があります。一部のロード・バランサでは、ロード・バランサを有効にしてリクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入することにより、これを構成します。

3.4 ハードウェア・ロード・バランサの構成

ハードウェア・ロード・バランサは、アプリケーション(この場合はOracle Identity and Access Management)から、アプリケーション・コンポーネントを構成する各ホストにリクエストを送信します。

ロード・バランサは仮想ホストとともに構成されます。各仮想ホストは、ロード・バランサで提供される異なるIPアドレスに関連付けられます。ロード・バランサの仮想ホストは、次に、デプロイメントのWebサーバーで構成される元のサーバーのプールに関連付けられます。

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

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

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

- 第3.4.1項「ロード・バランサの要件」

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

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

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

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

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

- ポート変換の構成。

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

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

- ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、Oracle WebLogicクラスタの場合は、1つの仮想サーバーとHTTPおよびHTTPSの両トラフィック用のポートを指定してロード・バランサを構成する必要があります。

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

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

- リソースの監視/ポートの監視/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を(通知またはその他の方法によって)検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。ご使用の外部ロード・バランサに障害の自動検出機能がある場合、これを使用する必要があります。

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

- スティッキーなルーティング機能: CookieまたはURLに基づくコンポーネントへのスティッキーな接続を維持する機能

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

- SSLアクセラレーション: SSLトランザクションで実行され、公開鍵暗号化アルゴリズムをハードウェア・アクセラレータにオフロードします。この機能は推奨されますが、必須ではありません。

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

- クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。

- WL-Proxy-SSL: trueをHTTP要求ヘッダーに追加する機能。これを自動で行うロード・バランサもあります。

3.4.2 ロード・バランサの構成手順

ロード・バランサの構成手順は、ロード・バランサの特定のタイプによって異なります。実際の手順は、ベンダーが提供するドキュメントを参照してください。次の手順では、一般的な構成フローを示します。

1. サーバーのプールを作成します。このプールには、ロード・バランシング定義に含まれるサーバーおよびポートのリストが存在します。たとえば、Webホスト間のロード・バランシングの場合、リクエストをポート7777 (WEB_HTTP_PORT)で受信するトポロジのWebサーバーに、リクエストを送信するサーバーのプールを作成します。

2. 特定のホストとサービスが使用可能かどうかを決定するルールを作成し、手順1で説明したサーバーのプールに割り当てます。

3. ロード・バランサ上に仮想サーバーを作成します。これは、アプリケーションにより使用されるリクエストを受信するアドレスとポートです。たとえば、Web層のリクエストをロード・バランシングするには、SSO.mycompany.com:80に対する仮想サーバーを作成します。

4. ロード・バランサでサポートされている場合は、仮想サーバーが内部から、外部から、またはその両方から利用できるのかどうかを指定します。内部アドレスはネットワーク内からのみ解決可能であることを確認します。

5. 適用可能な場合は、仮想サーバーに対するSSL終端を構成します。

6. 手順1で作成したサーバーのプールを、仮想サーバーに割り当てます。

7. 表3-3「Oracle Identity and Access Managementエンタープライズ・デプロイメント・トポロジで使用されるポート」にリストされているタイムアウト設定を調整します。これには、サービスが停止しているかどうかを検出する時間も含まれます。

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

Identity and Access Managementデプロイメントの場合、表3-1に示すようにロード・バランサを構成します。

表3-1 ロード・バランサの構成

仮想ホスト

サーバー・プール

プロトコル

SSL終端

外部

必要なその他の構成/コメント

SSO.mycompany.com:80 (HTTP_PORT)

WEBHOST1.mycompany.com:7777

WEBHOST2.mycompany.com:7777

HTTP

いいえ

はい

Identity and Access Managementでは、次のコードをHTTPヘッダーに追加する必要があります。

Header Name: IS_SSL

Header Value: ssl

SSO.mycompany.com:443 (HTTP_SSL_PORT)

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTPS

はい

はい

Identity and Access Managementでは、次のコードをHTTPヘッダーに追加する必要があります。

Header Name: IS_SSL

Header Value: ssl

IADADMIN.mycompany.com:80 (HTTP_PORT)

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

いいえ

いいえ

IADADMINVHN.mycompany.com:80 (HTTP_PORT)

IGDADMIN.mycompany.com:80 (HTTP_PORT)

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

いいえ

いいえ

IGDADMINVHN.mycompany.com:80 (HTTP_PORT)

IDMINTERNAL.mycompany.com:80 (HTTP_PORT)

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

いいえ

いいえ

IDSTORE.mycompany.com:389

LDAPHOST1.mycompany.com:1389

LDAPHOST2.mycompany.com:1389

LDAP

いいえ

いいえ

Identity and Access ManagementユーザーがOracle Unified Directoryに格納されている場合のみ必要です。

IDSTORE.mycompany.com:636

LDAPHOST1.mycompany.com:1636

LDAPHOST2.mycompany.com:1636

LDAPS

いいえ

いいえ

Identity and Access ManagementユーザーがOracle Unified Directoryに格納されている場合のみ必要です。

3.5 IPアドレスおよび仮想IPアドレスについて

仮想IPアドレスは、ホストの主要IPアドレスと同じサブネットに属する、未使用のIPアドレスです。このアドレスはホストに手動で割り当てられ、Oracle WebLogic管理対象サーバーはこのIPアドレスをリスニングするように構成されます。障害が発生した場合、割り当てられた管理対象サーバーの実行を新しいノードが引き継ぐことができるように、IPアドレスが同じサブネット内の別のノードに割り当てられます。

次に、Oracle Identity and Access Managementが必要とする仮想IPアドレスのリストを示します。

- IADADMINVHN.mycompany.com
エンタープライズ・デプロイメントでは、WebLogic管理サーバーが、配置されているホストに障害が発生した後でも、リクエストの処理を継続できることが必要です。仮想IPアドレスは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。WebLogic管理サーバーは、後でこの仮想IPアドレスをリスニングするように構成されます。これについては、本ドキュメントで後述します。この仮想IPアドレスは、管理サーバーとともに、OAMHOST1からOAMHOST2に(またはその逆に)フェイルオーバーします。

- IGDADMINVHN.mycompany.com
エンタープライズ・デプロイメントでは、WebLogic管理サーバーが、配置されているホストに障害が発生した後でも、リクエストの処理を継続できることが必要です。仮想IPアドレスは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。WebLogic管理サーバーは、後でこの仮想IPアドレスをリスニングするように構成されます。これについては、本ドキュメントで後述します。この仮想IPアドレスは、管理サーバーとともに、OIMHOST1からOIMHOST2に(またはOIMHOST2からOIMHOST1に)フェイルオーバーします。

- SOAHOSTxVHN.mycompany.com
SOA管理対象サーバーごとに1つの仮想IPアドレスが必要です。これにより、サーバーをサーバー移行の処理対象にすることができます。

アプリケーション層内で仮想IPアドレスをプロビジョニングすることにより、アプリケーション層にある任意のホストのネットワーク・インタフェースにこのアドレスをバインドできるようにします。

- OIMHOSTxVHN.mycompany.com
Oracle Identity Manager管理対象サーバーごとに1つの仮想IPアドレスが必要です。これにより、サーバーをサーバー移行の処理対象にすることができます。

アプリケーション層内で仮想IPアドレスをプロビジョニングすることにより、アプリケーション層にある任意のホストのネットワーク・インタフェースにこのアドレスをバインドできるようにします。

図3-0に示すように、異なる仮想IPと物理IPでリスニングするように、管理サーバーと管理対象サーバーを構成してください。

図3-1 IPアドレスおよびVIPアドレス: 分散

図3-2 IPアドレスおよびVIPアドレス: 統合

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

表3-2 VIPアドレスおよび仮想ホスト

仮想IP

VIPのマップ先

説明(統合)

デフォルト・ホスト(統合)

デフォルト・ホスト(分散)

VIP1

IADADMINVHN

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

IAMHOST1

OAMHOST1

VIP2

IGDADMINVHN

IGDADMINVHNは、Oracle Identity Manager管理サーバーのリスニング・アドレスとなる仮想ホスト名です。これは、管理サーバーの手動フェイルオーバーに伴ってフェイルオーバーします。これは、Oracle Identity Manager管理サーバー・プロセスが実行されているノードで有効化されます。

IAMHOST1

OIMHOST1

VIP3

SOAHOST1VHN

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

IAMHOST1

OIMHOST1

VIP4

OIMHOST1VHN

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

IAMHOST1

OIMHOST1

VIP5

SOAHOST2VHN

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

IAMHOST2

OIMHOST2

VIP6

OIMHOST2VHN

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

IAMHOST2

OIMHOST2

これらの仮想IPアドレスは、仮想ホスト名に関連付けられます。このため、必要に応じて、基礎となるIPアドレスを変更できます。次の例は、このドキュメントで必要な仮想ホスト名を示しています。これらは、前述の仮想IPアドレスに関連付けられます。

3.6 ファイアウォールとポートの構成

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

ほとんどのポート番号はインストール後に割り当てられます。必要に応じて別のポート番号を使用できます。表3-3に示したポート番号は、一貫性を保つためにこのガイド全体にわたって使用する例です。別のポート番号を使用する場合、その値が使用される場所では必ずその値を表の値のかわりに使用する必要があります。

表3-3は、Oracle Identity and Access Managementトポロジで使用されるポートの一覧です。これには、トポロジ内のファイアウォール上で開く必要があるポートが含まれます。

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

- FW0は、最も外側のファイアウォールを表します。

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

- FW2は、アプリケーション層とデータベース層の間のファイアウォールを表します。

表3-3 Oracle Identity and Access Managementエンタープライズ・デプロイメント・トポロジで使用されるポート

タイプ

ファイアウォール

ポートとポートの範囲

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

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

タイムアウト

ブラウザ・リクエスト

FW0

80

HTTP/ロード・バランサ

両方

Oracle Identity and Access Managementで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツに応じて、タイムアウトは異なります。

ブラウザ・リクエスト

FW0

443

HTTPS/ロード・バランサ

両方

Oracle Identity and Access Managementで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツに応じて、タイムアウトは異なります。

ブラウザ・リクエスト

FW1

80

HTTPS/ロード・バランサ

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

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

ブラウザ・リクエスト

FW1

443

HTTPS/ロード・バランサ

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

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

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

n/a

7777

HTTP

n/a

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

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

FW1

7001

HTTP/t3

インバウンド

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

Oracle Weblogic管理サーバー(IAMAccessDomain)へのWeb層アクセス

FW1

7001

HTTP/Oracle HTTP Serverと管理サーバー

インバウンド

N/A

Oracle Weblogic管理サーバー(IAMGovernanceDomain)へのWeb層アクセス

FW1

7101

HTTP/Oracle HTTP Serverと管理サーバー

インバウンド

N/A

Enterprise Managerエージェント - Web層からEnterprise Managerへ

FW1

5160

HTTP/Enterprise ManagerエージェントとEnterprise Manager

両方

N/A

Oracle HTTP ServerからWLS_OAMへ

FW1

14100

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

Oracle HTTP Server WLS_OIM

FW1

14000

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

Oracle HTTP Server WLS_SOA

FW1

8001

HTTP/Oracle HTTP ServerからWebLogic Serverへ

両方

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

管理サーバーによるOracle HTTP Serverの管理

FW1

OPMNリモート・ポート(6701)およびOHS管理ポート(7779)

それぞれTCPとHTTP

アウトバウンド

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

Access Managerサーバー

FW1

5575

OAP

両方

N/A

Access Manager Coherenceポート

FW1

9095

TCMP

両方

N/A

OAAMサーバー・ポート

FW1

14300

HTTP/Enterprise Manager

両方

N/A

OAAM管理ポート

FW1

14200

HTTP/Enterprise Manager

両方

N/A

Oracle Coherenceポート

FW1

8000 - 8088

TCMP

両方

N/A

WLS_OAAMから管理サーバー

FW2

OPMNリモート・ポート

HTTP/管理サーバーからOPMNへ

インバウンド

N/A

アプリケーション層からデータベース・リスナーへ

FW2

1521

SQL*Net

両方

Oracle Identity and Access Managementで使用されるプロセス・モデルのタイプとすべてのデータベース・コンテンツに応じて、タイムアウトは異なります。

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

Gridlink用に必要。ONSサーバーは各データベース・サーバー上で稼働します。

OUDポート

FW2

1389

LDAP

インバウンド

理想的には、タイムアウトが発生しないようにこれらの接続を構成します。

OUD SSLポート

FW2

14636

LDAPS

インバウンド

理想的には、タイムアウトが発生しないようにこれらの接続を構成します。

ロード・バランサLDAPポート

FW2

386

LDAP

インバウンド

理想的には、タイムアウトが発生しないようにこれらの接続を構成します。

ロード・バランサLDAP SSLポート

FW2

636

LDAPS

インバウンド

理想的には、タイムアウトが発生しないようにこれらの接続を構成します。

ノード・マネージャ

N/A

5556

TCP/IP

N/A

該当なし

Oracle Unified Directoryレプリケーション

該当なし

8989

TCP/IP

該当なし

該当なし

注意:

外部ドメイン(SOA、WebCenter Portalドメインなど)のアプリケーションをこのIdentity and Access Managementドメインで認証できるように、ファイアウォール間で追加のポートを開く必要が生じることがあります。

3.7 Access Manager通信プロトコルの管理

ここでは、Oracle Accessプロトコル(OAP)について説明し、ユーザー・リクエストの概要を示します。

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

- 第3.7.1項「Access Managerプロトコル」

- 第3.7.2項「統合リクエストの概要」

- 第3.7.3項「ユーザー・リクエストの概要」

- 3.7.4項「通信のマルチキャスト要件について」

- 3.7.5項「ネットワーク接続の確認」

3.7.1 Access Managerプロトコル

Oracle Accessプロトコル(OAP)は、ユーザー認証および認可の間に、アクセス・システム・コンポーネント(Access Managerサーバー、Webゲートなど)間の通信を可能にします。このプロトコルは、以前NetPointアクセス・プロトコル(NAP)またはCOREidアクセス・プロトコルと呼ばれていました。

3.7.2 統合リクエストの概要

Oracle Access Management Access Managerは、ユーザーのセッションを作成します。Identity and Access Managementが別のアイデンティティ管理コンポーネント(Oracle Identity Managerなど)と統合すると、認証はそのコンポーネントに委任されます。

典型的なリクエスト・フローは次のようになります。

1. ユーザーは、最初にリソースにアクセスしようとします。

2. Webゲートは、リクエストを捕捉し、ユーザーが認証されていないことを検出します。

3. Access Managerの資格証明コレクタが呼び出され、ユーザーはプロンプトに応答してユーザー名およびパスワードを入力します。Access Managerは、パスワード・ポリシーが最初のログイン時にパスワードの変更を要求することを認識しているため、ユーザーのブラウザはOracle Identity Managerにリダイレクトされます。

4. ユーザーは、パスワードの変更およびチャレンジ質問の設定を求められます。

5. この時点で、Oracle Identity Managerは、新しく入力したパスワードを使用してユーザーを認証しています。Oracle Identity Managerは、TAPリクエストを作成し、Access Managerがユーザーにセッションを作成できることを通知します。つまり、ユーザーは再ログインを求められません。これは、Access Managerが読み取ることができるユーザーのブラウザにトークンを追加することによって行われます。
Access ManagerへのTAPリクエストには次のことが含まれています。

- Access Managerサーバーの配置場所。

- 使用するWebゲート・プロファイル。

- Webゲート・プロファイルのパスワード。

- 証明書(Access Managerが簡易モードまたは証明書モードで動作している場合)。

3.7.3 ユーザー・リクエストの概要

ユーザーがアクセスをリクエストするときのリクエスト・フローは、次のとおりです。

1. ユーザーは、HTTPまたはHTTPSを介して保護されたリソースへのアクセスをリクエストします。

2. Webゲートはリクエストを捕捉します。

3. Webゲートは、Oracle Accessプロトコルを使用してリクエストをAccess Managerサーバーに転送し、リソースが保護されているかどうか、どのように保護されているか、またユーザーが認証されているかどうかを判別します(認証されていない場合は、チャレンジが行われます)。

4. Access Managerサーバーは、ユーザーIDやパスワードなどの資格証明についてディレクトリ・サーバーを確認し、Oracle Accessプロトコルを使用してWebゲートに情報を送り返し、ユーザーを認証するための暗号化Cookieを生成します。

5. 認証の後、WebゲートはOracle Accessプロトコルを使用してAccess Managerサーバーに指示し、Access Managerサーバーは該当するセキュリティ・ポリシーを検索してユーザーのアイデンティティと比較し、ユーザーの認証レベルを判別します。

- アクセス・ポリシーが有効な場合、ユーザーは目的のコンテンツまたはアプリケーション(あるいはこれら両方)へのアクセスを許可されます。

- ポリシーが偽の場合、ユーザーはアクセスを拒否され、組織の管理者が決めた別のURLにリダイレクトされます。

3.7.4 通信のマルチキャスト要件について

トポロジにあるノードはユニキャスト通信を使用して通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストはクロスネットワーク構成を必要としません。ユニキャストを使用することによって、マルチキャスト・アドレスの競合によるネットワーク・エラーを回避します。

ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。

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

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

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

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

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

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

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

注意:

ユニキャストを使用してクラスタ通信を設定できますが、キャッシングに使用する場合、Oracle Identity Managerでは、マルチキャストを使用します(キャッシングに使用する場合)。このため、マシン間でマルチキャストを有効にする必要があります。

3.7.5 ネットワーク接続の確認

ネットワークを定義したら、すべてのネットワーク名が各計算ノード/vServerから解決可能であることを確認します。

これを行うには、各計算ノード/vServer上で次のコマンドを実行します。

ping -I interface hostname

4 エンタープライズ・デプロイメント用の記憶域の準備

この章では、Oracle Identity and Access Managementエンタープライズ・デプロイメント用の記憶域を準備する方法を説明します。

このガイドで説明する記憶域モデルは、可用性の最大化、コンポーネントの最良の独立性、構成の対称性およびバックアップと災害からのリカバリの容易化を実現するために選択されました。このガイドの残りの部分では、この記憶域モデルに基づいたディレクトリ構造およびディレクトリ用語を使用します。その他のディレクトリ・レイアウトも可能で、サポートされています。

この章では、次の項目について説明します。

- 第4.1項「エンタープライズ・デプロイメント用の記憶域の準備の概要」

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

- 第4.3項「ファイル・システムについて」

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

4.1 エンタープライズ・デプロイメント用の記憶域の準備の概要

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

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

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

この項では、Oracle Identity and Access Managementエンタープライズ・デプロイメントを構成するためにこのガイドで使用されるディレクトリ変数について説明します。これらを環境変数として設定する必要はありません。このガイドでは、インストールして構成するディレクトリを次のディレクトリ変数を使用して説明しています。

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

- MW_HOME: この変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが配置されている場所を参照しています。MW_HOMEは、WL_HOME、ORACLE_COMMON_HOME、および1つ以上のORACLE_HOMEからなります。
各製品スイートに対して異なるMW_HOMEがあります。

このガイドでは、この値の前に製品スイートの略語が付く場合があります(DIR_MW_HOME、IAD_MW_HOME、IGD_MW_HOME、WEB_MW_HOMEなど)。

- WL_HOME: この変数および関連ディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれます。WL_HOMEディレクトリは、Oracleホーム・ディレクトリのピアであり、MW_HOME内にあります。

- ORACLE_HOME: この変数は、Oracle Fusion Middleware製品(Oracle HTTP Server、Oracle SOA Suiteなど)がインストールされている場所を示し、その製品のバイナリが現在のプロシージャで使用されています。このガイドでは、この値の前に製品スイートの略語が付く場合があります(IAD_ORACLE_HOME、IGD_ORACLE_HOME、WEB_ORACLE_HOME、WEBGATE_ORACLE_HOME、SOA_ORACLE_HOME、OUD_ORACLE_HOMEなど)。
ホームの詳細は、表2-6「ホームのまとめ」を参照してください。

- ORACLE_COMMON_HOME: この変数および関係するディレクトリ・パスは、Oracle Fusion Middleware Common Java Required Files (JRF)ライブラリおよびOracle Fusion Middleware Enterprise Managerライブラリがインストールされている場所を表します。例: MW_HOME/oracle_common

- ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Serverなどのシステム・コンポーネントが1つ以上含まれています。Oracleインスタンスのディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されます。
このガイドでは、この値の前に製品スイートの略語が付く場合があります(WEB_ORACLE_INSTANCEなど)。

- JAVA_HOME: Oracle JRockitがインストールされている場所です。

- ASERVER_HOME: このパスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されているファイル・システムの場所を示します。
使用されるドメイン(特にIGD_ASERVER_HOMEおよびIAD_ASERVER_HOME)ごとに異なるASERVER_HOMEがあります。

- MSERVER_HOME: このパスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されているローカル・ファイル・システムの場所を示します。このディレクトリは、pack/unpackユーティリティによって生成され、ASERVER_HOMEのサブセットになります。管理対象サーバーの起動および停止に使用されます。管理サーバーは、これまでどおりASERVER_HOMEディレクトリから起動されます。
使用されるドメインごとに異なるMSERVER_HOMEがあります。オプションで、管理対象サーバーの起動および停止に使用できます。

- LCM_HOME: ライフ・サイクル管理ツールおよびソフトウェア・リポジトリの場所です。

これらの変数の詳細および例は、4.4.4項「ディレクトリの推奨場所」を参照してください。

4.3 ファイル・システムについて

記憶域にパーティションを作成した後、ファイル・システムをパーティションに配置して、Oracleファイルを格納できるようにする必要があります。ローカル記憶域または直接接続された共有記憶域の場合、ファイル・システム・タイプは、オペレーティング・システムのデフォルト・タイプである可能性が非常に高いです(たとえばLinuxの場合はEXT3)。

共有記憶域が、2つ以上のホストから排他的または同時にアクセスされるネットワーク接続記憶域(NAS)の場合、サポートされているクラスタ・ファイル・システム(NFSバージョン3や4など)を使用する必要があります。このようなファイル・システムは、競合解決およびロック機能を提供します。

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

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

- 第4.4.1項「バイナリ(Middlewareホーム)ディレクトリの推奨事項」

- 第4.4.2項「ドメイン構成ファイルの推奨事項」

- 第4.4.3項「JMSファイル・ストアとトランザクション・ログ用の共有記憶域に関する推奨事項」

- 第4.4.4項「ディレクトリの推奨場所」

4.4.1 バイナリ(Middlewareホーム)ディレクトリの推奨事項

次の項では、Oracle Fusion MiddlewareのMiddlewareホーム・ディレクトリに対して共有記憶域を使用する際のガイドラインについて説明します。

- 第4.4.1.1項「バイナリ(Middlewareホーム)ディレクトリについて」

- 第4.4.1.2項「単一のMiddlewareホームの共有について」

- 第4.4.1.3項「冗長バイナリ(Middlewareホーム)ディレクトリの使用について」

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

Oracle Fusion Middleware製品をインストールする際には、製品のバイナリをMiddlewareホームにインストールします。Middlewareホームにインストールされたバイナリ・ファイルは読取り専用であり、Middlewareホームにパッチが適用されるか新しいバージョンにアップグレードされるまで変更されることはありません。

標準的な本番環境では、Middlewareホーム・ファイルは、Oracle Fusion Middleware構成ウィザードを使用して作成するドメイン構成ファイルとは別の場所に保存します。

Oracle Fusion Middlewareインストール用のMiddlewareホームには、Oracle WebLogic Serverのバイナリ、Oracle Fusion Middlewareインフラストラクチャ・ファイルおよび任意のOracle Fusion Middleware製品固有のディレクトリが含まれています。

アプリケーション・ホストとは異なるゾーンにLDAPHOSTがある場合、ゾーン間でバイナリ・インストールの場所を共有しないことをお薦めします。このモデルを採用し、LDAPバイナリの別の場所が必要な場合、SANにアプリケーション層のバイナリ用と、ディレクトリ・バイナリ用の2つのバイナリ用の共有を作成します。1つ目の共有はアプリケーション層のサーバーにマウントし、2つ目の共有はディレクトリ層のサーバーにマウントします。共有は異なりますが、これらは同じマウント・ポイントを使用してサーバーにマウントされます。たとえば、/u01/oracle/productsです。

Web層バイナリは共有されません。これらはローカル記憶域に配置されるため、SANストレージをDMZにマウントする必要はありません。

Oracle Fusion Middlewareホームの構造および内容の詳細は、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteインストレーション・ガイドを参照してください。

4.4.1.2 単一のMiddlewareホームの共有について

Oracle Fusion Middlewareでは、1つのMiddlewareホームから複数のOracle WebLogic Serverドメインを構成できます。これにより、共有ボリューム上の単一の場所にMiddlewareホームをインストールし、複数のホストのインストールにMiddlewareホームを再利用できます。

Middlewareホームが異なるホスト上の複数のサーバーにより共有されている場合、留意するべきいくつかのベスト・プラクティスがあります。特に、整合性およびパッチの適用のため、各ホストにあるOracleインベントリが更新されていることを確認してください。

ホストのoraInventoryを更新して、Middlewareホームを共有記憶域に追加するには、次のコマンドを使用します。

ORACLE_HOME/oui/bin/attachHome.sh

Oracleインベントリの詳細は、Oracle Universal Installerコンセプト・ガイドのOracle Universal Installerインベントリに関する項を参照してください。

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

可用性が最大になるように、共有記憶域上でバイナリの冗長インストールを使用することをお薦めします。

このモデルでは、Oracle Fusion Middlewareソフトウェアの2つの同じMiddlewareホームを2つの異なる共有ボリュームにインストールします。まず、Middlewareホームの1つをサーバーの1セットにマウントし、もう一方を残りのサーバーにマウントします。いずれのMiddlewareホームも同じマウント・ポイントを持つため、サーバーがどのMiddlewareホームを使用しているかにかかわらず、Middlewareホームは常に同じパスを持ちます。

一方のMiddlewareホームが破損または使用不可になっても、影響を受けるのは半分のサーバーのみです。さらに保護を強化するために、これらのボリュームのディスク・ミラーを行うことをお薦めします。

共有記憶域で個別ボリュームが使用不可の場合、同じボリューム内の別々のディレクトリを使用して個別ボリュームをシミュレートしたり、ホスト側の同じマウント場所に個別ボリュームをマウントしたりすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

これは通常、デプロイメント後に次の手順を実行して行われます。

1. バイナリ用の新しい共有ボリュームを作成します。

2. 奇数番号のサーバー上の元のマウント・ボリューム(OAMHOST1、OIMHOST1など)を残します。

3. 偶数のマウント・サーバーの同じ場所に新しいボリューム(OAMHOST2、OIMHOST2など)をマウントします。

4. 奇数のホストから偶数のホストにコピーすることで、ボリューム1のファイルをボリューム2にコピーします。

4.4.1.4 ライフサイクル・リポジトリについて

ライフサイクル・リポジトリには、デプロイメント・ツールやパッチ適用ツールなどのライフサイクル管理ツールが含まれています。また、インストールされるソフトウェアおよび適用されるパッチを含むソフトウェア・リポジトリも含まれます。

プロビジョニング中に、トポロジ内の各ホストにライフサイクル・リポジトリをマウントすることをお薦めします。こうすることにより、デプロイメント・プロセスがこの場所にファイルを置き、別のホストで実行している可能性のある他のプロセス手順がこれを使用する準備ができるようになります。集中管理されたリポジトリを持つことで、プロビジョニング・プロセス中に手動でファイルをコピーする手間を省くことができます。

集中管理されたリポジトリを持つことは、パッチ適用においても重要です。リポジトリは、プロビジョニングまたはパッチ適用が発生したときのみ必要になります。それ以外のときには、このディスク共有はホストのいずれかまたはすべてからアンマウントして、ゾーンにわたるセキュリティを維持できます。

共有のライフサイクル・リポジトリを持つ利点は次のとおりです。

1. ソフトウェア用の場所が1つになる。

2. デプロイメント・プロビジョニングが容易。

3. パッチ適用が容易。

組織によっては、最初のプロビジョニングまたはパッチ適用中のみであっても、ゾーン間でファイル・システムをマウントすることを禁止しているところもあります。この場合、デプロイメント・プロビジョニングを行う際、ソフトウェア・リポジトリを複製し、デプロイメント処理中に手動でのファイルのコピーを何度も行う必要があります。

簡単にするために、このガイドでは単一の共有のライフサイクル・リポジトリを使用することをお薦めします。ただし、このガイドには、これが不可能な場合のために、必要となる追加の手動での手順も含まれています。

4.4.2 ドメイン構成ファイルの推奨事項

次の項では、エンタープライズ・デプロイメントでOracle Fusion Middleware製品を構成する際に作成するOracle WebLogic Serverドメイン構成ファイルで共有記憶域を使用するためのガイドラインについて説明します。

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

- 第4.4.2.2項「管理サーバーのドメイン構成ファイル用の共有記憶域の要件」

- 第4.4.2.3項「管理対象サーバーのドメイン構成ファイル用のローカル記憶域の要件」

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

Oracle Fusion Middleware製品を構成すると、Oracle WebLogic Serverドメインが作成または拡張されます。各Oracle WebLogic Serverドメインは、1つの管理サーバーおよび1つ以上の管理対象サーバーで構成されます。

Oracle WebLogic Serverドメインの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解』を参照してください。

エンタープライズ・デプロイメントでは、ドメイン内の管理対象サーバーをアクティブ/アクティブ型の高可用性用に構成できることを理解することが重要です。ただし、管理サーバーではこのようなことはありません。管理サーバーはシングルトン・サービスです。つまり、管理サーバーは1つのホスト上で所定の時間にのみ有効です。

ASERVER_HOMEはドメイン構成のプライマリの場所です。MSERVER_HOMEは管理対象サーバーの起動と停止に使用するドメイン構成のコピーです。WebLogic管理サーバーは、ASERVER_HOMEドメイン構成に適用された構成の変更を、ドメインの一部として登録されているすべてのMSERVER_HOME構成ディレクトリに自動的にコピーします。ただし、MSERVER_HOMEディレクトリには、管理対象サーバーに固有のデプロイメントおよびデータも含まれています。そのため、バックアップを実行する際には、ASERVER_HOMEとMSERVER_HOMEの両方を含める必要があります。

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

管理サーバーの構成ファイルは共有記憶域に配置する必要があります。これにより、プライマリ・ホストが使用できなくなった場合でも、別のホストで管理サーバーを起動できます。管理サーバー・ファイルがあるディレクトリは、ASERVER_HOMEディレクトリと呼ばれています。このディレクトリは共有記憶域に配置され、アプリケーション層の各ホストにマウントされます。

競合に関連するパフォーマンス上の問題を回避するために、管理対象サーバーの構成ファイルはローカル記憶域上に配置する必要があります。管理対象サーバーの構成ファイルがあるディレクトリは、MSERVER_HOMEディレクトリと呼ばれています。管理対象サーバー・ドメイン構成ファイルは、ローカル記憶域に配置することを強くお薦めします。

4.4.2.3 管理対象サーバー・ドメイン構成ファイルに対するローカル記憶域の要件

共有記憶域を使用する必要がある場合は、ノードごとに記憶域パーティションを作成し、その記憶域をそのノードに排他的にマウントすることをお薦めします。

このエンタープライズ・デプロイメント・トポロジに対して用意されている構成手順では、管理対象サーバーごとに各ノードのローカル・ドメイン・ディレクトリが使用されると想定しています。

4.4.3 JMSファイル・ストアとトランザクション・ログ用の共有記憶域に関する推奨事項

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

JMSおよびJTA情報のファイル・ストアへの保存の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用に関する項を参照してください。

4.4.4 ディレクトリの推奨場所

この項では、共有記憶域およびローカル記憶域のお薦めされる使用方法を説明します。

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

- 第4.4.4.1項「ライフサイクル管理とデプロイメント・リポジトリ」

- 第4.4.4.2項「共有記憶域」

- 第4.4.4.3項「プライベート記憶域」

4.4.4.1 ライフサイクル管理とデプロイメント・リポジトリ

ライフサイクル管理ツールおよびデプロイメント・リポジトリを保持するには、個別の共有が必要です。この共有は、デプロイメントおよび以降のパッチ適用の間にのみ必要になります。デプロイメントが完了すると、各ホストからこの共有をアンマウントできます。

注意:

注: パッチ管理ツールを使用してデプロイするパッチがある場合、パッチの適用中にこの共有を再マウントする必要があります。

理想的には、プロビジョニング中に、すべてのホストにこの共有をマウントします。こうすることで、Web層で必要なキーストアなど、ファイルを手動でコピーする必要がなくなるため、プロビジョニング・プロセスを簡単にできます。組織で、(デプロイメントの間であっても) LCM_HOMEをWeb層のホストに共有することを禁止している場合、DMZホスト上にこの共有のコンテンツのローカル・コピーを作成し、デプロイメント・フェーズ中に手動でファイルをコピーする必要があります。

図4-1 デプロイメント・リポジトリ

4.4.4.2 共有記憶域

エンタープライズ・デプロイメントでは、ホストOAMHOST1、OAMHOST2、OIMHOST1およびOIMHOST2にある共有記憶域に、ボリュームVOL1/OracleIAMを作成することをお薦めします。マウント・ポイントは/u01/oracleにする必要があります。

表4-1および表4-2には、推奨されるレイアウトの説明が記載されており、図4-2にはそれが図で表されています。

注意:

共有されていない場合でも、IDM_TOPの場所は書込み可能にする必要があります。

表4-1 共有記憶域上のボリューム: 分散トポロジ

環境変数

ボリューム名

マウント・ポイント

マウントされるホスト

排他

SW_ROOT

Binaries

/u01/oracle/products

OAMHOST1 OAMHOST2 OIMHOST1 OIMHOST2 LDAPHOST1 LDAPHOST2脚注 1

いいえ

SHARED_CONFIG_DIR

sharedConfig

/u01/oracle/config

OAMHOST1 OAMHOST2 OIMHOST1 OIMHOST2

いいえ

DIR_MW_HOME脚注 2

dirBinaries

/u01/oracle/products/dir

LDAPHOST1 LDAPHOST2

いいえ

脚注 1 ディレクトリがアプリケーション・ゾーン内にあるときにのみLDAPHOST1およびLDAPHOST2にマウントします。

脚注 2 ディレクトリがディレクトリ・ゾーンまたはデータベース・ゾーンに配置された場合にのみ必要です。

表4-2 共有記憶域上のボリューム: 統合トポロジ

環境変数

ボリューム名

マウント・ポイント

マウントされるホスト

排他

SW_ROOT

Binaries

/u01/oracle/products

IAMHOST1 IAMHOST2 LDAPHOST1 LDAPHOST2脚注 1

いいえ

SHARED_CONFIG_DIR

sharedConfig

/u01/oracle/config

IAMHOST1 IAMHOST2

いいえ

DIR_MW_HOME脚注 2

dirBinaries

/u01/oracle/products/dir

LDAPHOST1 LDAPHOST2

いいえ

脚注 1 ディレクトリがアプリケーション・ゾーン内にあるときにのみLDAPHOST1およびLDAPHOST2にマウントします。

脚注 2 ディレクトリがディレクトリ・ゾーンまたはデータベース・ゾーンに配置された場合にのみ必要です。

図4-2 共有記憶域

この図は、共有記憶域のディレクトリ階層を示しています。マウント・ポイント/u01/oracle (SW_ROOT)の下にはディレクトリconfigおよびproductsがあります。

アプリケーション層とは異なるゾーンにディレクトリをデプロイすることを計画し、記憶域をゾーン全体にわたってマウントしない場合、DIR_MW_HOMEを保持する目的で、ディレクトリ層専用の共有記憶域を作成できます。この場合でも、アプリケーション層の共有記憶域と同じマウント・ポイント(/u01/oracleなど)となります。

ディレクトリconfigにはdomainsが含まれ、これには次のものが含まれます。

- IAMAccessDomain (IAD_ASERVER_HOME)。IAMAccessDomainには3つのサブディレクトリ(applications、servers、keystores)があります。serversディレクトリにはサブディレクトリAdminServerがあります。

- IAMGovernanceDomain (IGD_ASERVER_HOME)。IAMGovernanceDomainには、5つのサブディレクトリ(applications、servers、keystores、jmsおよびlogs)があります。serversディレクトリにはサブディレクトリAdminServerがあります。

productsディレクトリには、access、dirおよびidentityのディレクトリが含まれます。

access (IAD_MW_HOME)ディレクトリには、iam (IAD_ORACLE_HOME)、oracle_common (ORACLE_COMMON_HOME)、wlserver_10.3 (WL_HOME)およびjdk6 (JAVA_HOME)の4つのサブディレクトリがあります。

dir (DIR_MW_HOME)ディレクトリには、oud (OUD_ORACLE_HOME)およびjdk6(JAVA_HOME)の2つのサブディレクトリがあります。

identity (IGD_MW_HOME)ディレクトリには、iam (IGD_ORACLE_HOME)、soa (SOA_ORACLE_HOME)、oracle_common (ORACLE_COMMON_HOME)、wlserver_10.3 (WL_HOME)およびjdk6 (JAVA_HOME)の5つのサブディレクトリがあります。

ディレクトリprovisioningは、Identity and Accessのデプロイ・ウィザードで使用され、デプロイメント・プランに関連する情報が含まれます。

専用のディレクトリ層がある場合には、SW_ROOTの共有はLDAPHOST上であるかIAMHOST上であるかによって異なります。

4.4.4.3 プライベート記憶域

エンタープライズ・デプロイメントでは、次のディレクトリを、ローカル記憶域または特定のホストに排他的にマウントされた共有記憶域に作成することをお薦めします。

表4-3 プライベート記憶域のディレクトリ

層

環境変数

ディレクトリ

ホスト

Web層

WEB_MW_HOME

/u01/oracle/products/web

WEBHOST1 WEBHOST2

Web層

WEB_ORACLE_INSTANCE

/u02/private/oracle/config/instances/ohsn

WEBHOST1 WEBHOST2

アプリケーション層

OUD_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oudn

LDAPHOST1 LDAPHOST2

IAD_MSERVER_HOME

/u02/private/oracle/config/domains/IAMAccessDomain

OAMHOST1 OAMHOST2

IGD_MSERVER_HOME

/u02/private/oracle/config/domains/IAMGovernanceDomain

OIMHOST1 OIMHOST2

図4-3 プライベート記憶域

この図は、ローカル記憶域のディレクトリ階層を示しています。最上位ディレクトリ/u02/private/oracle (LOCAL_ROOT)には、サブディレクトリconfigがあります。

configディレクトリには、インスタンスを持つ各製品、つまりWebサーバーおよびLDAP (この場合Oracle HTTP ServerおよびOracle Unified Directory)のためのサブディレクトリがあります。適切なディレクトリが関連するホストにのみ現れます。つまり、WEB_ORACLE_INSTANCEディレクトリはWEBHOSTSにのみ現れます。

domainsディレクトリには、トポロジ内の各ドメイン(IAMAccessDomainおよびIAMGovernanceDomain)に対して1つのサブディレクトリが含まれます。

IAMAccessDomain (IAD_MSERVER_HOME)には、applicationsおよびserversが含まれます。serversディレクトリにはwls_oamnがあり、ここでnはAccess Managerのインスタンスです。OAAMが構成される場合、このフォルダにはwls_oaamnおよびwls_oaam_adminnも含まれます。

IAMGovernanceDomain (IGD_MSERVER_HOME)には、applicationsおよびserversが含まれます。serversディレクトリにはwls_oimnおよびwls_soanがあり、ここでnはそれぞれOracle Identity ManagerおよびSOAのインスタンスです。

図4-4 プライベート・バイナリ記憶域

図4-4は、ローカル・バイナリ記憶域のディレクトリ階層を示しています。最上位ディレクトリ/u01/oracle ()には、サブディレクトリproductsがあります。

productsディレクトリには、webディレクトリ(WEB_MW_HOME)があり、これには4つのサブディレクトリweb (WEB_ORACLE_HOME)、webgate (WEBGATE_ORACLE_HOME)、oracle_common (ORACLE_COMMON_HOME)およびjdk6 (JAVA_HOME)があります。

注意:

WEB_ORACLE_INSTANCEディレクトリをローカル記憶域に配置することをお薦めしますが、共有記憶域も使用できます。共有記憶域を使用する場合、HTTPロック・ファイルを別の場所に配置する必要があります。

Oracle Identity ManagementのExalogic Storageの構成

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

この章では、エンタープライズ・デプロイメント用のサーバーを準備する方法を説明します。

次の項が含まれます:

- 第5.1項「サーバー構成の概要」

- 第5.2項「サーバーおよびオペレーティング・システムの検証」

- 第5.3項「最小ハードウェア要件の達成」

- 第5.4項「オペレーティング・システム要件の達成」

- 第5.5項「Unicodeサポートの有効化」

- 第5.6項「仮想IPアドレスの有効化」

- 第5.7項「共有記憶域のホストへのマウント」

- 第5.8項「ユーザーおよびグループの構成」

5.1 サーバー構成の概要

Oracle Fusion Middlewareを新しいハードウェアにデプロイする前に、Oracleソフトウェアが最適に動作できるように、使用する計画のサーバーを設定する必要があります。具体的には、次のことを確認する必要があります。

- 必要なソフトウェア・パッチがインストールされている動作保証済オペレーティング・システムをサーバーが実行中。

- UNIXカーネルを正しく構成済。

- Oracleソフトウェアを所有するユーザーおよびグループを作成済。

この章で説明する設定は単なる見本です。Oracleソフトウェアを使用した後、オペレーティング・システムのユーティリティを使用して構成を調整し、サーバーの能力を最大化していることを確認する必要があります。

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

使用する計画のサーバーおよびオペレーティング・システムが使用する計画の製品の動作保証済の組合せであることを確認します。詳細は、Oracle動作保証マトリックスを参照してください。

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

Oracleエンタープライズ・デプロイメントでサーバーを使用するには、第2.4項「エンタープライズ・デプロイメントのハードウェア要件」に記載されている最小仕様をそのサーバーが満たしていることを確認する必要があります。別のデプロイメント・アーキテクチャ(より多いまたはより少ないコンポーネントを様々な数のボックスにデプロイしたアーキテクチャなど)を使用する計画の場合、Oracle Identity and Access Management用のOracle® Fusion Middlewareのシステム要件と仕様を確認し、これらのサーバーにデプロイする計画の製品に対応する最小仕様を備えていることを確認する必要があります。

仮想サーバー環境にデプロイしている場合、仮想サーバーそれぞれが最小要件を満たしていることを確認します。

十分なローカル・ディスクがあり、共有記憶域が第4章「エンタープライズ・デプロイメント用の記憶域の準備」で説明されているように構成されていることを確認します。

十分なスワップ領域および一時領域を確保します。具体的には次のとおりです。

- スワップ領域: システムに512MB以上ある必要があります。

- 一時領域: /tmpに500MB以上の空き領域がある必要があります。

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

Identity and Access Managementのデプロイメントを実行する前に、次のタスクを実行する必要があります。

1. 動作保証済オペレーティング・システムをインストールします。

2. リリース・ノートにリストされている必要なパッチおよびパッケージをすべてインストールします。

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

- 第5.4.1項「カーネル・パラメータの構成」

- 第5.4.2項「オープン・ファイル制限の設定」

- 第5.4.3項「シェル制限の設定」

- 第5.4.4項「ローカルHostsファイルの構成」

5.4.1 カーネル・パラメータの構成

次のカーネル・パラメータおよびシェル制限の値は、単なる推奨値です。本番システムでは、これらの値をチューニングしてシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータのチューニングの詳細は、オペレーティング・システムのドキュメントを参照してください。

カーネル・パラメータは、トポロジのすべてのノードで次の最小値以上の値に設定する必要があります。

次の表の値は、現行のLinuxの推奨値です。Linuxおよびその他のオペレーティング・システムの最新の推奨値は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

データベースをホストにデプロイしている場合、追加のカーネル・パラメータを変更する必要がある場合があります。ご使用のプラットフォームは、11gリリース2 Oracle Grid Infrastructureインストレーション・ガイドを参照してください。

表5-1 UNIXのカーネル・パラメータ

パラメータ

値

kernel.sem

256 32000 100 142

kernel.shmmax

2147483648以上

これらのパラメータを設定するには:

1. rootとしてログインし、ファイル/etc/sysctl.confのエントリを追加または修正します。

2. ファイルを保存します。

3. 次のコマンドを発行して変更をアクティブ化します。

/sbin/sysctl -p

5.4.2 オープン・ファイル制限の設定

すべてのUNIXオペレーティング・システムにおいて、最小オープン・ファイル制限は4096です。

注意:

次の例はLinuxオペレーティング・システム用です。オペレーティング・システムのドキュメントを確認して、システムで使用するコマンドを判別します。

次のコマンドでオープンになっているファイル数を確認できます。

/usr/sbin/lsof | wc -l

オープン・ファイル制限を確認するには、次のコマンドを使用します。

Cシェル:

limit descriptors

Bash:

ulimit -n

5.4.3 シェル制限の設定

注意:

制限がこれらの値より大きい値にすで設定されている場合は、変更する必要はありません。

ほとんどのLinuxバージョン

シェル制限を変更するには、rootとしてログインし、/etc/security/limits.confファイルを編集します。

次の行を追加します。

* soft  nofile  65536
* hard  nofile  150000
* soft  nproc   2048
* hard  nproc   16384

Oracle Linux 6およびRed Hat Enterprise Linux 6のみ

シェル制限を変更するには、rootとしてログインし、/etc/security/limits.confファイルを編集します。

次の行を追加します。

* soft  nofile  65536
* hard  nofile  150000

/etc/security/limits.d/90-nproc.confも編集します。

次の行を追加します。

* soft  nproc   2048
* hard  nproc   16384

最新の推奨値は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

ファイルを編集したら、マシンを再起動します。

5.4.4 ローカルHostsファイルの構成

Oracleソフトウェアのインストールを開始する前に、ローカル/etc/hostsファイルが次のようにフォーマットされていることを確認します。

IP_Address Fully_Qualified_Name Short_Name

たとえば、次のようになります。

192.168.30.1 iamhost1.mycompany.com iamhost1

5.5 Unicodeサポートの有効化

オペレーティング・システムの構成がOracle Fusion Middleware製品でサポートされる文字の動作に影響を与えることがあります。

UNIXオペレーティング・システムでは、LANG環境変数をUTF-8文字セットを使用したロケールに設定し、Unicodeサポートを有効化することを強くお薦めします。これにより、Unicodeのすべての文字が処理できるようになります。たとえば、Oracle SOA SuiteテクノロジはUnicodeに基づいています。

LANGUAGE環境変数を次のように設定します。

LANG=en_GB.UTF-8

オペレーティング・システムがUTF-8以外のエンコードを使用するように構成されている場合、Oracle SOA Suiteコンポーネントが予期しない動作をする可能性があります。たとえば、ASCII以外のファイル名の場合は、ファイルにアクセスできず、エラーが発生する可能性があります。オペレーティング・システムの制約によって発生した問題は、オラクル社ではサポートしていません。

5.6 仮想IPアドレスの有効化

エンタープライズ・デプロイメントでは、WebLogic管理サーバーやSOA管理対象サーバーを実行する特定のホストは仮想IPアドレスを使用する必要があります。各サーバーで適切なIPアドレスを有効化する必要があります。

第3章「エンタープライズ・デプロイメント用のネットワークの準備」では、IPアドレスのサーバーへのマッピングについて説明しています。

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

- 第5.6.1項「必要な仮想IPアドレスの概要」

- 第5.6.2項「既存のネットワーク・インタフェースでの仮想IPアドレスの有効化」

5.6.1 必要な仮想IPアドレスの概要

他のOracle Fusion Middlewareコンポーネントを後でインストールするかしないかに関係なく、WebLogic管理サーバーのフェイルオーバーを行うには仮想IPアドレスが必要です。

管理サーバーを仮想IPアドレスと関連付けます。これにより、プライマリ・ホストで障害が発生している場合に、別のホストで管理サーバーを起動させることができます。

仮想ホストが次のように有効化されていることを確認します。

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

VIP

ホスト上で有効(分散)

ホスト上で有効(統合)

IADADMINVHN.mycompany.com

OAMHOST1

IAMHOST1

IGDADMINVHN.mycompany.com

OIMHOST1

IAMHOST1

OIMHOST1VHN.mycompany.com

OIMHOST1

IAMHOST1

OIMHOST2VHN.mycompany.com

OIMHOST2

IAMHOST2

SOAHOST1VHN.mycompany.com

OIMHOST1

IAMHOST1

SOAHOST2VHN.mycompany.com

OIMHOST2

IAMHOST2

注意:

これは、浮動IPアドレスに関連付けられているDNS名です。これは、ロード・バランサ上で構成される仮想ホストのDNS名ではありません。

5.6.2 既存のネットワーク・インタフェースでの仮想IPアドレスの有効化

表5-2に示された物理IPアドレスのみをIAMHOST1およびIAMHOST2で有効にするには、次の手順を実行します。

1. ifconfigコマンドを使用して仮想IPアドレスを作成します。

ifconfig subinterface virtual_ip_address netmask netmask_value

たとえば、IAMHOST1上で次のように入力します。

ifconfig bond0:1 192.168.20.3 netmask 255.255.240.0

2. 定義する各仮想IPアドレスごとに、次のコマンドを使用してARPキャッシュを更新します。

arping -b -A -c 3 -I bond0 192.168.20.3

5.7 共有記憶域のホストへのマウント

第4章「エンタープライズ・デプロイメント用の記憶域の準備」に示されるように、共有記憶域を使用する予定の各ホストがそれを使用できるようにする必要があります。

5.7.1 共有記憶域の概要

次のように共有記憶域をマウントします。

表5-3 共有記憶域のマウント

トポロジ

ボリューム

マウント・ポイント

マウントされるホスト

ディレクトリ層

一時

統合

binaries

/u01/oracle/products

IAMHOST1 IAMHOST2

いいえ

sharedConfig

u01/oracle/config

IAMHOST1 IAMHOST2 LDAPHOST1 LDAPHOST2

N/A

いいえ

LCM

/u01/lcm

WEBHOST1 WEBHOST2 IAMHOST1 IAMHOST2

N/A

はい

分散

binaries

/u01/oracle/products

OAMHOST1 OAMHOST2 OIMHOST1 OIMHOST2

いいえ

dirBinaries

/u01/oracle/products

LDAPHOST1 LDAPHOST2

いいえ

sharedConfig

/u01/oracle/config

OAMHOST1 OAMHOST2 OIMHOST1 OIMHOST2

N/A

いいえ

LCM

/u01/lcm

WEBHOST1 WEBHOST2 OAMHOST1 OAMHOST2 OIMHOST1 OIMHOST2 LDAPHOST1 LDAPHOST2

N/A

はい

次の点に注意してください:

- 各ホストでは、適切な権限をNASまたはSAN内で設定し、共有記憶域への書込みを可能にする必要があります。

- 一時マウントはプロビジョニング中およびパッチ適用中にのみ必要になります。

- ディレクトリ層が専用ゾーンに配置された場合、分散トポロジの2つのディレクトリ・ホスト間でORACLE_BASEを共有する必要があります。

- WEBHOST1およびWEBHOST2がDMZにある場合、ORACLE_BASEは2つのホスト間で共有されません。

- 共有記憶域のマウントについては、組織のベスト・プラクティスに従ってください。この項では、NFS記憶域を使用してUNIXまたはLinuxでこれを行う方法の例を示します。

注意:

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

5.7.2 共有記憶域のマウント

共有記憶域の場所を作成してマウントし、各アプリケーション層ホストがバイナリ・インストール用に同じ場所を参照できるようにする必要があります。

次のコマンドを使用して、共有記憶域をNAS記憶域デバイスからLinuxホストにマウントします。別のタイプの記憶域デバイスまたはオペレーティング・システムを使用している場合、これを行う方法の詳細は製造元のドキュメントを参照してください。

ホストに共有記憶域をマウントするには、次のようなコマンドを使用します。

mount -t nfs nasfiler:volume mountpoint

例:

mount -t nfs nasfiler:VOL1/OracleIAM /u01/oracle

nasfilerは共有記憶域デバイスの名前です。

説明のようにmountコマンドを使用すると、ホストが再起動するまで共有記憶域がマウントされます。再起動したら、ホストに記憶域を再マウントする必要があります。

ホストの再起動に続いて記憶域を確実に使用可能にするには、次のようにファイル/etc/fstabにエントリを配置します。

nasfiler:VOL1/OracleIAM /u01/oracle nfs auto,rw,bg,hard,nointr,proto=tcp,vers=3,timeo=300,rsize=32768,wsize=32768

注意:

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

mount -t nfs -o rw,bg,hard,nointr,proto=tcp,vers=3,timeo=300,rsize=32768,wsize=32768 nasfiler:VOL1/OracleIAM /u01/oracle

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

5.7.3 共有記憶域の構成の検証

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

例:

cd /u01/oracle/products
touch testfile

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

ls -l testfile

ファイルを削除します。

rm testfile

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

次のユーザーおよびグループをローカルに作成するか、NISまたはLDAPサーバーに作成します。このユーザーはOracleソフトウェア所有者です。

次の手順は、ユーザーをローカルで作成する場合を対象にしています。ユーザー/グループをNISサーバーに作成する方法の詳細は、NISドキュメントを参照してください。

グループ

各ノードに次のグループを作成する必要があります。

- oinstall

- dba

グループを作成し、次のコマンドをrootとして使用する手順:

groupadd groupname

たとえば、次のようになります。

groupadd -g 500 oinstall
groupadd -g 501 dba

Users

各ノードに次のユーザーを作成する必要があります。

- oracle: Oracleソフトウェアの所有者。別の名前も使用できます。このアカウントのプライマリ・グループはoinstallにする必要があります。このアカウントは、dbaグループにも属している必要があります。

注意:

- グループoinstallは、Oracleソフトウェアが使用する共有記憶域およびローカル記憶域のすべてのファイル・システムに対する書込み権限を持っている必要があります。

- 各グループは、ノードごとに同じグループIDを持っている必要があります。

- 各ユーザーは、ノードごとに同じユーザーIDを持っている必要があります。

- NFSv4マウント要件のため、ユーザーおよびグループはNISサーバーに存在する必要があります。

ユーザーを作成し、次のコマンドをrootとして使用する手順:

useradd -g primary group -G optional groups -u userid username

例:

useradd -g oinstall -G dba -u 500 oracle

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

この章では、Identity and Access Managementデータベース・リポジトリをインストールし、構成する方法について説明します。

この章では、次の項目について説明します。

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

- 第6.2項「エンタープライズ・デプロイメント用のデータベース要件の検証」

- 第6.3項「エンタープライズ・デプロイメント用のデータベースのインストール」

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

- 第6.5項「RCUを使用したOracle RAC DatabaseへのIdentity and Access Managementスキーマのロード」

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

6.1 Identity and Access Managementエンタープライズ・デプロイメント用のデータベースの準備の概要

エンタープライズ・デプロイメントのIdentity and Access Managementコンポーネントはデータベース・リポジトリを使用します。この章では、次の手順を実行する方法について説明します。

- 第6.2項「エンタープライズ・デプロイメントのデータベース要件の検証」で説明されているデータベース要件の検証。

- Oracleデータベース・リポジトリのインストールと構成。「はじめに」の「関連ドキュメント」にリストされているインストレーション・ガイドおよび第6.3項「エンタープライズ・デプロイメント用のデータベースのインストール」を参照してください。

- 第6.4項「データベース・サービスの作成」で説明されているデータベース・サービスの作成。

- リポジトリ作成ユーティリティ(RCU)用のデータベースの準備。第7.2項「Oracle Identity and Access Managementのソフトウェア・リポジトリの作成」を参照してください。

- リポジトリ作成ユーティリティ(RCU)を使用したデータベースで必要なOracleスキーマの作成。第6.5項「RCUを使用したOracle RAC DatabaseへのIdentity and Access Managementスキーマのロード」を参照してください。

6.2 エンタープライズ・デプロイメントのデータベース要件の検証

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

- 第6.2.1項「必要なデータベース」

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

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

- 6.2.4項「Oracle Database 11g (11.2.0.2.0)のパッチ要件」

- 6.2.5項「Oracle Databaseの最小要件」

6.2.1 必要なデータベース

Oracle Identity and Access Managementでは、多数の別個のデータベースを使用すること推奨します。表6-1には、これらのデータベースの概要が提供されます。どのデータベースを使用するかは、実装しているトポロジによって異なります。

Oracle Metadata Services (MDS)リポジトリは、一部のOracle Fusion Middlewareコンポーネントのメタデータを含む特定のリポジトリのタイプです、ユーザーの組織で開発したカスタムJava EEアプリケーションを含むこともできます。

このリリースのIAMでは、各ドメインで個別のRCUスキーマ接頭辞を使用する必要があります。これにより、必要な場合、製品ごとに異なるデータベースを使用できます。

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

データベース名

データベース・ホスト

SCANアドレス

サービス名

RCU接頭辞

データベースのスキーマ

IAMDB

IAMDBHOST1

IAMDBHOST2

IAMDBSCAN

OAMEDG.mycompany.com

EDGIAD

OAM、IAU、MDS、OPSS

OIMEDG.mycompany.com

EDGIGD

OIM、SOAINFRA、MDS、OPSS、ORASDPM

OAAMEDG.mycompany.com

EDGIAD

OAAM

次の各項は、表6-1にリストされたデータベースすべてに適用されます。

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

メタデータ・リポジトリを格納するために使用するデータベースは、可用性を最大化するために本質的に高可用性を実現する必要があります。Oracleは、Oracle Real Application Clusters (RAC)データベースの使用をお薦めします。

データベースにデータを格納するにはOracle Automatic Storage Management (ASM)を使用することが理想的ですが、必須ではありません。

ASMを使用する場合、ASMを独自のOracleホームにインストールし、ASMに2つのディスク・グループを備える必要があります。

- 1つはデータベース・ファイル用です。

- 1つはフラッシュ・リカバリ領域用です。

Oracle ASMを使用している場合、Oracle管理対象ファイルも使用することをお薦めします。

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

デプロイメント・ツールでは、Oracle RACデプロイメントにOracle Database 11.2.0.0以上が必要です。

ご使用のデータベースが動作保証されているかどうかの確認または動作保証済データベースすべての表示を行うには、動作保証ドキュメントの動作保証済データベースの項を参照してください。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

インストール済Oracle Databaseのバージョンを判別するには、SQLプロンプトで次の問合せを実行します。

select version from sys.product_component_version where product like 'Oracle%';

6.2.4 Oracle Database 11g (11.2.0.2.0)のパッチ要件

Oracle Database 11g (11.2.0.2.0)を使用する場合は、必ずRDBMSパッチ番号10259620に適した(プラットフォームに基づく)バージョンをダウンロードしてインストールしてください。これは、Oracle Identity Managerスキーマをインストールするための前提条件です。

表6-2に、Oracle Database 11gリリース2 (11.2.0.2.0)を使用するOracle Identity Managerの構成に必要なパッチをリストします。Oracle Identity Managerスキーマを作成する前に、必ず次のパッチをダウンロードしてインストールしてください。

表6-2 Oracle Database 11g (11.2.0.2.0)に必要なパッチ

プラットフォーム

My Oracle Supportでのパッチ番号および説明

Linux x86 (32ビット)

Linux x86 (64ビット)

RDBMS個別パッチ番号10259620。

このパッチが適用されない場合、ユーザーおよびロールの検索やマネージャのルックアップで問題が発生する可能性があります。また、検索結果として空の結果が戻されることもあります。

注意:

- このパッチはオンライン・モードで適用してください。実行するステップについては、パッチにバンドルされているreadme.txtファイルを参照してください。

- 一部の環境では、RDBMS個別パッチを使用して問題を解決することはできませんが、公開されている回避策が役立ちます。回避策については、不具合: 8352378 [MetalinkノートID 1264550.1]の修正が原因で機能ベースの索引およびOR拡張を使用した11.2.0.2で結果が正しくないのノートをhttp://support.oracle.comで参照してください。このノートを実行して、ALTER SYSTEM SET <param>=<value> scope=<memory>または<both>を使用してデータベース・インスタンス・レベルでパラメータを変更する必要があるという唯一の例外に応じてパラメータを設定できます。

6.2.5 Oracle Databaseの最小要件

Oracle Databaseでは、いくつかの最小要件を満たす必要があります。

6.2.5.1 一般的なデータベース特性

- 文字セット - 文字セットはUnicode準拠(AL32UTF8など)である必要があります。

- データベース・オプション – 次のデータベース・オプションがデータベースにインストールされている必要があります。

- Oracle JVM

- Oracle Text

- データベース・ビュー – 次のデータベース・ビューがデータベースに作成されている必要があります。

- XAVIEWS

- データベース・パッケージ – 次のデータベース・パッケージがデータベースに存在している必要があります。

- DBMS_SHARED_POOL

6.2.5.2 最小初期化パラメータ

データベースは、次の最小初期化パラメータを定義済である必要があります。

表6-3 Oracleデータベースの最小初期化パラメータ

パラメータ

値

aq_tm_processes

1

dml_locks

200

job_queue_processes

10

open_cursors

1600

session_max_open_files

50

sessions

500

processes

500

sga_target

512M

pga_aggregate_target

100M

sga_max_size

4G

session_cached_cursors

500

データベースの作成時に、これらのパラメータをデータベース構成アシスタントに設定することお薦めします。これをまだ行っていない場合は、alter systemデータベース・コマンドを使用して、作成後に調整できます。例:

sqlplus / as sysdba
alter system set aq_tm_processes=1 scope=spfile;

spfileで変更を行ったら、データベースを再起動します。たとえば、次のようになります。

srvctl stop database -d iamdb
srvctl start database -d iamdb

注意:

データベースの最適なパラメータを設定するためのガイドラインについては、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。

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

次のようにデータベース・リポジトリをインストールして構成します。

Oracle Clusterware

- 10gリリース2 (10.2)については、「関連ドキュメント」で、ご使用のプラットフォームに対応したOracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイドを参照してください。

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

自動ストレージ管理

- 10gリリース2 (10.2)については、「関連ドキュメント」で、ご使用のプラットフォームに対応したOracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイドを参照してください。

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

- インストーラの実行時に構成の選択画面で「自動ストレージ管理(ASM)の構成」オプションを選択して、独立した自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

- 10gリリース2 (10.2)については、「関連ドキュメント」で、ご使用のプラットフォームに対応したOracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイドを参照してください。

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

Oracle Real Application Clustersデータベース

次の特性を持つReal Applications Clustersデータベースを作成します。

- バックアップおよびリカバリを容易にするために、データベースはアーカイブ・ログ・モードにする必要がある。

- オプションで、フラッシュバック・データベースを有効にできる。

- Oracle Identity Managerのリコンシリエーション・プロセス時のロールバック要件に対応できるように、十分なサイズのUNDO表領域を作成する。

- データベースは、ALT32UTF8文字セットで作成されている。

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

この項では、Oracle Fusion Middleware 11gメタデータ用のデータベースを構成する方法について説明します。次のトピックが含まれます:

- 第6.4.1項「10.xおよび11.1.xデータベース用のデータベース・サービスの作成」

- 第6.4.2項「11.2.xデータベース用のデータベース・サービスの作成」

- 第6.4.3項「データベースのチューニング」

6.4.1 10.xおよび11.1.xデータベース用のデータベース・サービスの作成

データベース・サービス作成の詳細な手順は、Oracle Database Oracle ClusterwareおよびOracle Real Application Clusters管理およびデプロイメント・ガイドのワークロード管理に関する章を参照してください。複数の製品スイートが同じデータベースを共有する場合でも、製品スイートに固有のデータベース・サービスを使用することをお薦めします。また、使用されるデータベース・サービスはデフォルトのデータベース・サービスとは別のものをお薦めします。

CREATE_SERVICEサブプログラムを使用して、トポロジ内のコンポーネント用のデータベース・サービスを作成します。作成されるサービスの一覧は、表6-1「データベースとスキーマ間のマッピング」に示されています。

1. 次のように入力して、sysdbaユーザーとしてSQL*Plusにログオンします。

sqlplus "sys/password as sysdba"

次のコマンドを実行して、Access Manager用のOAMEDG.mycompany.comというサービスを作成します。

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

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

srvctl add service -d iamdb -s OAMEDG.mycompany.com -r iamdb1,iamdb2

3. srvctlを使用してサービスを開始します。

srvctl start service -d iamdb -s OAMEDG.mycompany.com

6.4.2 11.2.xデータベース用のデータベース・サービスの作成

srvctlを使用して、トポロジ内のコンポーネント用のデータベース・サービスを作成します。作成されるサービスの一覧は、表6-1「データベースとスキーマ間のマッピング」に示されています。

1. 次のように、コマンドsrvctl add serviceを使用してサービスを作成します。

srvctl add service -d iamdb -s OAMEDG.mycompany.com -r iamdb1,iamdb2 -q FALSE -m NONE -e SELECT -w 0 -z 0

コマンド行引数の意味は、次のとおりです。

オプション

引数

-d

データベースの一意の名前

-s

サービス名

-r

優先インスタンスのカンマ区切りリスト

-q

AQ HA通知(TRUEまたはFALSE)

-e

フェイルオーバー・タイプ(NONE、SESSIONまたはSELECT)

-m

フェイルオーバー方式(NONEまたはBASIC)

-w

フェイルオーバー遅延(整数)

-z

フェイルオーバー再試行回数(整数)

2. srvctl start serviceを使用してサービスを開始します。

srvctl start service -d iamdb -s OAMEDG.mycompany.com

3. 次のようにsrvctl status serviceを使用して、開始したサービスを検証します。

srvctl status service -d iamdb -s OAMEDG.mycompany.com
Service OAMEDG.mycompany.com is running on instance(s) iamdb1,iamdb2

4. srvctl config serviceを使用して、サービスが正しく作成されたことを検証します。

srvctl config service -d iamdb -s OAMEDG.mycompany.com
Service name: OAMEDG.mycompany.com
Service is enabled
Server pool: IAMDB_OAMEDG.mycompany.com
Cardinality: 2
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SELECT
Failover method: NONE
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Preferred instances: iamdb1,iamdb2
Available instances:

注意:

SRVCTLコマンドの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。

6.4.3 データベースのチューニング

6.2.5.2項「最小初期化パラメータ」で定義したデータベース・パラメータは単なる見本です。システムの使用後、追加のチューニングを実行する必要が生じることがあります。詳細は、データベース・パフォーマンス・チューニング・ガイドを参照してください。

データベースを最初にロードした後、継続的に、データベース統計をリフレッシュしてください。このためには、スキーマごとにSQL*Plusコマンドを発行します。次の例は、スキーマEDGIGD_OIMの場合です。

exec DBMS_STATS.GATHER_SCHEMA_STATS(OWNNAME=> 'EDGIGD_OIM', ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE, DEGREE=>8, OPTIONS=>'GATHER AUTO', NO_INVALIDATE=>FALSE);

6.5 RCUを使用したOracle RAC DatabaseへのIdentity and Access Managementスキーマのロード

リポジトリ作成ユーティリティを実行して、Identity and Access Managementに必要なスキーマをデータベースに設定する必要があります。リポジトリ作成ユーティリティは、2回実行する必要があります(異なる接頭辞を指定するドメインごとに1回ずつ)。

1. 次のコマンドを発行して、RCUを起動します。

RCU_HOME/bin/rcu &

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

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

4. 「データベース接続の詳細」画面で、既存のデータベースに接続するために必要な情報を入力します。例:
データベース・タイプ: Oracle Database

- ホスト名: RACデータベース・ノードの1つのVIPアドレスまたはデータベースSCANアドレスを入力します(たとえば、IAMDBSCAN.mycompany.com)

- ポート: データベース・リスナーのポート番号((DB_LSNR_PORT))。たとえば、1521です。

- サービス名: データベースのサービス名。たとえば、OAMEDG.mycompany.com。
手順6で表から選択するコンポーネントのサービス名を使用します。

- ユーザー名: sys

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

- ロール: SYSDBA

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

5. 「前提条件の確認」画面で前提条件を確認したら、「OK」をクリックします。

6. 「コンポーネントの選択」画面で、次の値を入力します。
新規接頭辞の作成: データベース・スキーマに追加する接頭辞を入力します。すべてのスキーマに接頭辞を付ける必要があります。表6-1「データベースとスキーマ間のマッピング」または次のRCU接頭辞の表を参照してください。

コンポーネント: 使用しているトポロジに対して次の表から適切なコンポーネントを選択します。

RCU接頭辞

製品

RCUオプション

サービス名

コメント

EDGIAD

Oracle Platform Security Services for IAMAccessDomain

AS共通スキーマ: Oracle Platform Security Service

OAMEDG.mycompany.com

ポリシー・ストア情報を保持するために必要です。

EDGIAD

Oracle Access Management Access Manager

Oracle Identity Management – Oracle Access Manager

OAMEDG.mycompany.com

監査サービスも選択されます。

EDGIAD

Oracle Adaptive Access Manager

Oracle Identity Management – Oracle Adaptive Access Manager

OAAMEDG.mycompany.com

必要に応じて。

EDGIGD

Oracle Platform Security Services for IAMGovernanceDomain

AS共通スキーマ: Oracle Platform Security Service

OIMEDG.mycompany.com

ポリシー・ストア情報を保持するために必要です。

EDGIGD

Oracle Identity Manager

Identity Management–Oracle Identity Manager

OIMEDG.mycompany.com

メタデータ・サービス、SOAインフラストラクチャおよびユーザー・メッセージングも選択されます。

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

注意:

ご使用のトポロジが複数のデータベースを必要とする場合、次の重要な考慮事項が適用されます。

- 正しいスキーマを正しいデータベースにインストールしてください。

- 指定のトポロジにすべてのスキーマを作成するためにRCUを複数回実行する必要がある場合があります。

- この章の表6-1にスキーマと対応するデータベースの間の推奨マッピングを示します。この表を参照して、正しい詳細情報をこの画面に入力してください。

7. 「前提条件の確認」画面で前提条件を確認したら、「OK」をクリックします。

8. 「スキーマ・パスワード」画面で、スキーマのパスワードを入力します。すべてのスキーマに同じパスワードを使用するか、またはスキーマそれぞれに異なるパスワードを使用することを選択できます。デプロイメント・ウィザードでは、特定の接頭辞のパスワードはすべて同じである必要があります。
「次へ」をクリックします。

9. 「表領域のマップ」画面でデフォルトを受け入れ、「次へ」をクリックします。

10. 「確認」画面で「OK」をクリックして、表領域の作成を許可します。

11. 「表領域の作成中」画面で「OK」をクリックして、表領域の作成を確認します。

12. 「サマリー」画面で、入力した詳細情報が正確であることを確認します。「作成」をクリックして、スキーマ作成プロセスを開始します。

13. 「完了サマリー」画面で、スキーマが作成されたことを確認します。
「閉じる」をクリックして終了します。

6.6 データベースのバックアップ

データベースの準備が完了したら、第15.5.3.3項「データベースのバックアップ」の説明に従ってバックアップを作成します。

7 デプロイの準備

この章では、Oracle Identity and Access Managementエンタープライズ・デプロイメントで必要なソフトウェアのインストールについて説明します。

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

- 第7.1項「Identity and Access Managementのデプロイメントのための情報収集」

- 第7.2項「Oracle Identity and Access Managementのソフトウェア・リポジトリの作成」

- 第7.3項「Javaの検証」

- 第7.4項「IAMデプロイメント・ウィザードのインストール」

- 第7.5項「ポート可用性のチェック」

7.1 Identity and Access Managementのデプロイメントのための情報収集

デプロイメントの前に次の情報を収集します。このガイドのPDF版から表を印刷して自分の値を記録できます。

このガイドでは、理解しやすくするために、次のホスト名を繰り返し使用します。

- WEBHOST1/2

- OAMHOST1/2

- OIMHOST1/2

- LDAPHOST1/2

実際の値は、使用しているデプロイメント・トポロジのタイプによって異なります。表7-1の値は、これらのホストがトポロジにリストされているホストをどのように参照しているかを示しています。

ホスト名に加えて、ドキュメントの一部のホストにはVHN接尾辞がある場合もあります。これは、仮想ホスト名の識別に使用されます。

注意:

- ハイフン(-)文字を含むホスト名は使用しないでください。15.10.1.1項「属性のホストまたはドメイン名のフォーマットが正しくありませんというエラーでデプロイメントが失敗する」を参照してください。

- Identity and Access Managementのデプロイメントに権限付きポート(< 1024)を使用しないでください。

表7-1 ホスト: 分散トポロジ

説明

変数

ドキュメント内での値

実際の値

Access Managementホスト1

OAMHOST1

OAMHOST1.mycompany.com

Access Managementホスト2

OAMHOST2

OAMHOST2.mycompany.com

アイデンティティ・ガバナンス・ホスト1

OIMHOST1

OIMHOST1.mycompany.com

アイデンティティ・ガバナンス・ホスト2

OIMHOST2

OIMHOST2.mycompany.com

ディレクトリ・ホスト1

LDAPHOST1

LDAPHOST1.mycompany.com

ディレクトリ・ホスト2

LDAPHOST2

LDAPHOST2.mycompany.com

最初のWeb層ホスト

WEBHOST1

WEBHOST1.mycompany.com

2番目のWeb層ホスト

WEBHOST2

WEBHOST2.mycompany.com

表7-2 ホスト: 統合トポロジ

説明

変数

ドキュメント内での値

実際の値

Access Managementホスト1

OAMHOST1

IAMHOST1.mycompany.com

Access Managementホスト2

OAMHOST2

IAMHOST2.mycompany.com

アイデンティティ・ガバナンス・ホスト1

OIMHOST1

IAMHOST1.mycompany.com

アイデンティティ・ガバナンス・ホスト2

OIMHOST2

IAMHOST2.mycompany.com

ディレクトリ・ホスト1

LDAPHOST1

IAMHOST1.mycompany.com

ディレクトリ・ホスト2

LDAPHOST2

IAMHOST2.mycompany.com

最初のWeb層ホスト

WEBHOST1

IAMHOST1.mycompany.com

2番目のWeb層ホスト

WEBHOST2

IAMSHOST2.mycompany.com

表7-3 インストール場所

説明

変数

ドキュメント内での値

実際の値

ソフトウェア・リポジトリの場所

REPOS_HOME

/u01/lcm/repository

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

SW_ROOT

/u01/oracle/products

共有の構成場所

SHARED_CONFIG_DIR

/u01/oracle/config

ローカルの構成場所

LOCAL_CONFIG_DIR

/u02/private/oracle/config

ライフサイクル管理ストアの場所

LCM_HOME

/u01/lcm

表7-4 ポート

説明

変数

ドキュメント内での値

実際の値

Access Management WLSサーバー・ポート

IAD_WLS_PORT

7001

アイデンティティ・ガバナンスWLSポート

IGD_WLS_PORT

7101

Oracle Identity Managerポート、2番目のOracle Identity Managerポート

OIM_PORT

14000

SOAポート、ホスト1および2

SOA_PORT

8001

Access Managerポート、2番目のAccess Managerポート

OAM_PORT

14100

Access Managerプロキシ・ポート

OAM_PROXY_PORT

5575

WebサーバーHTTPポート

WEB_HTTP_PORT

7777

WebサーバーHTTPSポート

WEB_HTTPS_PORT

4443

LDAPポート

LDAP_PORT

1389

LDAP SSLポート

LDAP_SSL_PORT

1636

LDAP管理ポート

LDAP_ADMIN_PORT

4444

LDAPレプリケーション・ポート

LDAP_REPLIC_PORT

8989

ノード・マネージャ・ポート

NMGR_PORT

5556

OAAMポート

OAAM_PORT

14300

OAAM管理ポート

OAAM_ADMIN_PORT

14200

表7-5 仮想ホスト

説明

変数

ドキュメント内での値

実際の値

アクセス・ドメイン管理サーバーの仮想ホスト

IADADMINVHN

IADADMINVHN.mycompany.com

ガバナンス・ドメイン管理サーバーの仮想ホスト

IGDADMINVHN

IGDADMINVHN.mycompany.com

最初のOracle Identity Managerサーバーの仮想ホスト

OIMHOST1VHN

OIMHOST1VHN.mycompany.com

2番目のOracle Identity Managerサーバーの仮想ホスト

OIMHOST2VHN

OIMHOST2VHN.mycompany.com

最初のSOAサーバーの仮想ホスト

SOAHOST1VHN

SOAHOST1VHN.mycompany.com

2番目のSOAサーバーの仮想ホスト

SOAHOST2VHN

SOAHOST2VHN.mycompany.com

表7-6 データベース情報

説明

変数

ドキュメント内での値

実際の値

SCANアドレス

SCAN_ADDRESS

IAMDBSCAN.mycompany.com

SCANリスナー・ポート

DB_LSNR_PORT

1521

Oracle Identity Manager DBサービス名

OIM_DB_SERVICENAME

OIMEDG.mycompany.com

Access Manager DBサービス名

OAM_DB_SERVICENAME

OAMEDG.mycompany.com

OAAM DBサービス名

OAAM_DB_SERVICENAME

OAAMEDG.mycompany.com

Oracle Identity Manager DBスキーマ・パスワード

OIM_SCHEMA_PASSWD

表7-7 LDAP

説明

変数

ドキュメント内での値

実際の値

LDAPレルムDN、

REALM_DN

dc=mycompany,dc=com

アイデンティティ・ストア・バインドDN

LDAP_ADMIN_USER

cn=oudadmin

表7-8 ロード・バランサ

説明

変数

ドキュメント内での値

実際の値

IAMAccessDomain管理機能へのアクセスに使用するロード・バランサ・エンド・ポイント

IAD_DOMAIN_ADMIN_LBRVHN

IADADMIN.mycompany.com

IAMGovernanceDomain管理機能へのアクセスに使用するロード・バランサ・エンド・ポイント

IGD_DOMAIN_ADMIN_LBRVHN

IGDADMIN.mycompany.com

ロード・バランサ管理ポート

HTTP_PORT

80

ロード・バランサ管理ポートはSSL?

No

ロード・バランサ内部コールバック仮想ホスト名

IAM_INTERNAL_LBRVHN

IDMINTERNAL.mycompany.com

ロード・バランサ内部コールバック・ポート

IAM_INTERNAL_PORT

80

ロード・バランサSSLポート

HTTP_SSL_PORT

443

ロード・バランサIDストア仮想ホスト名

LDAP_IDSTORE_NAME

IDSTORE.mycompany.com

ロード・バランサIDストア・ポート

LDAP_LBR_PORT

389

ロード・バランサIDストアSSLポート

LDAP_LBR_SSL_PORT

1636

SSOメイン・アプリケーション・エントリ・ポイント

IAM_LOGIN_LBRVHN

SSO.mycompany.com

表7-9 電子メール・サーバー(オプション)

説明

変数

ドキュメント内での値

実際の値

送信電子メール・サーバー名

EMAIL_SERVER

EMAIL.mycompany.com

送信電子メール・サーバー・ポート

EMAIL_PORT

465

送信電子メール・セキュリティ

EMAIL_PROTOCOL

SSL

電子メール・ユーザー名

EMAIL_USER

電子メール・パスワード

EMAIL_PASSWORD

注意:

内部コールバックは常に非暗号化(HTTP)です。メインのエントリ・ポイントsso.mycompany.comは常に暗号化(HTTPS)されます。

表7-10 ユーザー

説明

変数

ドキュメント内での値

実際の値

IAMデプロイメント・ウィザードの共通のIAMパスワード

COMMON_IAM_PASSWORD

Identity Store Access Manager管理ユーザー

OAMADMINUSER

oamadmin

Identity Store Access Managerソフトウェア・ユーザー

OAMLDAPUSER

oamLDAP

Identity Store Oracle Identity Manager管理ユーザー

OIMLDAPUSER

oimLDAP

表7-11 OAM

説明

変数

ドキュメント内での値

実際の値

Access Manager転送モード

OAM_MODE

Simple(AIXではOpen)

Access Manager Cookieドメイン

OAM_COOKIE_DOMAIN

.mycompany.com

7.2 Oracle Identity and Access Managementのソフトウェア・リポジトリの作成

Oracle Identity and Access Managementで必要とされるソフトウェアは、Oracle Fusion Middlewareのデプロイメント・リポジトリに配置されています。配置されていない場合には、『Oracle Fusion Middleware Oracle Identity and Access Managementデプロイメント・ガイド』に記載されているように、Oracle Fusion Middlewareのプロビジョニング・リポジトリを作成する必要があります。

すでに配置されている場合には、RCU zipファイルREPOS_HOME/installers/fmw_rcu/linux/rcuHome.zipを次の場所に解凍します。

REPOS_HOME/installers/rcu

7.3 Javaの検証

デプロイメント・リポジトリに必ずJavaが含まれるようにしてください。これはjdk6というディレクトリに配置される必要があります。

次のように、Javaがインストールされ、機能していることを確認できます。

JAVA_HOMEをJAVA_HOMEに設定します。

次のコマンドを実行します。

JAVA_HOME/bin/java -version
JAVA_HOME/bin/javac -version

7.4 IAMデプロイメント・ウィザードのインストール

IAM Deploymentウィザードは、プロビジョニング中およびその後のパッチ適用中に、トポロジ内の各ホストから参照可能である必要があります。

IAMライフ・サイクル・ツール(IAMデプロイメント・ウィザードおよびIAMパッチ適用ツール)のインストール・スクリプトは、次のディレクトリにあります。

REPOS_HOME/installers/idmlcm/Disk1

ツールのインストールを開始するには、ディレクトリをこのディレクトリに変更し、スクリプトを起動します。

cd REPOS_HOME/installers/idmlcm/idmlcm/Disk1
./runInstaller -jreLoc REPOS_HOME/jdk6

次の手順を実行します。

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

2. UNIXプラットフォームでウィザードを実行している場合、インベントリ・ディレクトリの場所が要求されます。これはこのホストにインストールされたすべてのOracle製品の追跡に使用されます。
「オペレーティング・システム・グループID」フィールドで、インベントリ・ディレクトリへのアクセス権を付与するメンバーが所属するグループを選択します。このグループのすべてのメンバーが、このホストに製品をインストールできます。「OK」をクリックして続行します。

「インベントリの場所の確認」ダイアログにより、inventory_directory/createCentralInventory.shスクリプトをrootとして実行し、/etc/oraInst.locファイルを作成するように求められます。このファイルは、中央インベントリへのポインタで、サイレント・インストールの際に存在している必要があります。このファイルには次の2行が含まれます。

inventory_loc=path_to_central_inventory

inst_group=install_group

このファイルの標準的な場所は/etc/oraInst.locですが、どこにでも作成できます。/etc以外のディレクトリに作成した場合、-invPtrLoc引数を含め、Identity and Access Managementデプロイメント・ウィザードまたはrunIAMDeploymentスクリプトを実行した際のインベントリの場所を入力する必要があります。

このホストでrootアクセス権がない場合にインストールを続行するには、「ローカル・インベントリを使用してインストールを続行」を選択します。

「OK」をクリックして続行します。

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

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

1. Oracle Middlewareホーム: これは、Identity and Access Managementデプロイメント・ウィザードがインストールされる親ディレクトリです。これはたとえば、次のような共有記憶域にある必要があります。
/u01/lcm/tools

2. Oracleホーム・ディレクトリ: これは、ウィザードがインストールされる、前述のディレクトリのサブディレクトリです。たとえば、次のようになります。
idmlcm

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

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

6. 「インストールの進行状況」画面で、「次へ」をクリックします。

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

7.5 ポート可用性のチェック

環境のデプロイを開始する前に、使用予定のすべてのポートがすでに使用されていないことを確認する必要があります。

これを行うには、次の手順を実行します:

1. コンポーネントを実行するマシンにログオンします。

2. 次のコマンドを使用して、そのポートを使用して実行しているプロセスがないことを確認します。

netstat -an | grep port

portは確認するポートのポート番号です。

たとえば、Oracle HTTPサーバーではコマンドは次のようになります。

netstat -an | grep 7777

デフォルトのポートの詳細なリストは、表3-3「Oracle Identity and Access Managementエンタープライズ・デプロイメント・トポロジで使用されるポート」を参照してください。

8 デプロイメント・プロファイルの作成

この章では、Identity and Access Managementデプロイメント・ウィザードを使用して、デプロイメント・プロファイルを作成する方法について説明します。

この章では、次のウィザード画面について説明します。

- 第8.1項「ようこそ」

- 第8.2項「IAMインストール・オプション」

- 第8.3項「セキュリティ・アップデートの指定」

- 第8.4項「レスポンス・ファイルの説明」

- 第8.5項「IAM製品の選択」

- 第8.6項「トポロジの選択」

- 第8.7項「インストールと構成の場所の選択」

- 第8.8項「仮想ホストの構成」

- 第8.9項「ユーザー名およびパスワードの設定」

- 第8.10項「Oracle Unified Directoryの構成」

- 第8.11項「Oracle HTTP Serverの構成」

- 第8.12項「Oracle Identity Managerの構成」

- 第8.13項「Oracle Identity Managerデータベースの構成」

- 第8.14項「SOAの構成」

- 第8.15項「Oracle Access Managerの構成」

- 第8.16項「Oracle Access Managerデータベースの構成」

- 第8.17項「HTTP/HTTPSロード・バランサの構成」

- 第8.18項「サマリー」

デプロイメントを実行する前に、使用しているトポロジについての情報をIdentity and Access Managementデプロイメント・ウィザードに提供する必要があります。必要な項目をすべて入力すると、デプロイメント操作の実行に使用できるデプロイメント・ファイルがウィザードにより作成されます。

第7.1項「Identity and Access Managementのデプロイメントのための情報収集」で収集した情報を参照してください。この章の画面の説明で使用される変数名は、その項で説明されています。

Identity and Access Managementデプロイメント・ウィザードを起動するには、IDMCLM/provisioning/binから次のコマンドを実行します。

JAVA_HOMEをREPOS_HOME/jdk6に設定します。

次のコマンドを発行します。

./iamDeploymentWizard.sh

ウィザードが起動したら、次の各項の説明に従って画面を進めます。

注意:

Identity and Access Managementの処理では、デプロイメントのすべてのホスト上で同じデプロイメント・プロファイルを使用する必要があります。デプロイメント・プロファイルは、デプロイメント処理中に一度のみ作成してください。

8.1 ようこそ

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

8.2 IAMインストール・オプション

「IAMインストール・オプション」画面で「新規Identity and Access Managementデプロイメント・レスポンス・ファイルの作成」を選択し、「次へ」をクリックします。

8.3 セキュリティ・アップデートの指定

セキュリティ・アップデートの指定画面を使用して、My Oracle Supportからのセキュリティ関連アップデートおよびインストール関連情報の通知プリファレンスを設定します。この情報はオプションです。

- 電子メール: この方法でアップデートが送信されるようにするには、電子メール・アドレスを指定します。

- セキュリティ・アップデートをMy Oracle Support経由で受け取ります。: My Oracle Supportアカウントに直接アップデートが送信されるようにするには、このオプションを選択します。このオプションを選択する場合、My Oracle Supportパスワードを入力する必要があります。

「次へ」をクリックして続行してください。

8.4 レスポンス・ファイルの説明

「レスポンス・ファイルの説明」画面で次の情報を入力します。

- レスポンス・ファイルのタイトル: Identity and Access Management Deployment Response Fileなどのタイトルです。

- レスポンス・ファイルのバージョン: Ver 1.0

- レスポンス・ファイルの説明: IAM Deployment Response Fileなどのレスポンス・ファイルの説明です。

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

8.5 IAM製品の選択

「IAM製品の選択」画面で、「OIM-OAM統合およびOracle Unified Directory (OUD)」を選択します。

デプロイするIAMコンポーネントの選択後に、製品の選択を変更するために以降の画面で「戻る」ボタンをクリックしないでください。

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

8.6 トポロジの選択

「トポロジの選択」画面で「高可用性(HA)」を選択し、次の情報を入力します。

注意:

すべてのホスト名は完全修飾である必要があります。

次を入力します。

- ディレクトリ: LDAPHOST1.mycompany.com (LDAPHOST1)

- アイデンティティ・ガバナンス/OIM: OIMHOST1.mycompany.com (OIMHOST1)

- アクセス管理: OAMHOST1.mycompany.com (OAMHOST1)

- Web層: WEBHOST1.mycompany.com (WEBHOST1)

「2つ目のノードに詳細を提供する」が選択されていることを確認し、次の情報を入力します。

- ディレクトリ: LDAPHOST2.mycompany.com (LDAPHOST2)

- アイデンティティ・ガバナンス/OIM: OIMHOST2.mycompany.com (OIMHOST2)

- アクセス管理: OAMHOST2.mycompany.com (OAMHOST2)

- Web層: WEBHOST2.mycompany.com (WEBHOST2)

ディレクトリ・サーバーが専用のセキュリティ・ゾーンにあり、アイデンティティ・ガバナンス/アクセス管理サーバーと同じSW_ROOTディレクトリを共有しない場合、「専用ゾーンにディレクトリをインストール」を選択します。このオプションが選択された場合、ディレクトリ・サーバー間で個別のSW_ROOTが共有されます。詳細は、第4章「エンタープライズ・デプロイメント用の記憶域の準備」を参照してください。

SW_ROOTの場所がローカルのDMZ内の専用のWeb層を使用する場合、「DMZのWeb層をインストール」を選択します。これは、デフォルトのエンタープライズ・デプロイメント・トポロジです。

注意:

Exalogicデプロイメントの場合は、Exalogic External OHSトポロジ以外のすべてでDMZのWeb層をインストールが選択解除されます。

注意:

- OHSは中間層またはLDAPコンポーネントと同じホストに配置されません。このガイドで説明するトポロジでは、OHSは追加のセキュリティのためにDMZに配置されます。

- OHSはLDAPホストに配置できません。

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

8.7 インストールと構成の場所の選択

「インストール場所の構成」画面で次の情報を入力します。

- ライフサイクル管理ストアの場所: これはたとえば、/u01/lcm (LCM_HOME)などのライフサイクル管理をサポートするためにデータを格納する場所です。

- LCM_HOMEディレクトリをディレクトリ・ホストにマウントしている場合、「ディレクトリ・ホストにマウント済」を選択します。

- LCM_HOMEディレクトリをWebホストにマウントしている場合、「Webホストにマウント済」を選択します。

注意:

第5.7項「共有記憶域のホストへのマウント」で説明したように、Identity and Access Managementのデプロイメントの間に各ホストにLCM_HOMEディレクトリをマウントする必要があります。これが終わったら、これら両方の「マウント先」オプションを選択します。

ただし、ディレクトリをプロビジョニング中にマウントできない場合でもデプロイメントは実行できますが、さらに手動の手順をいくつか実行する必要があります。詳細は、第9.4項「共通のLCM_HOMEのないIdentity and Access Managementのデプロイメント」を参照してください。

- ソフトウェア・リポジトリの場所: これはたとえば、/u01/lcm/Repository (ワークシート中のREPOS_HOME)などのデプロイメント・リポジトリの場所です。

- ソフトウェア・インストールの場所: これはたとえば、/u01/oracle (IDM_TOP)などの、Middlewareホームを配置する共有記憶域上の場所です。

注意:

注: このリリースでは、この場所の最大長は45文字です。

- 共有構成の場所: たとえば、/u01/oracle/config (SHARED_CONFIG_DIR)などの、共有構成の場所を入力します。

- ローカル構成の場所の有効化: エンタープライズ・デプロイメントにはこれを選択します。

- ローカル構成の場所: これはたとえば、/u02/private/oracle/config (LOCAL_CONFIG_DIR)などの、Oracle HTTP ServerのMiddlewareホームおよびローカル構成ファイルを格納する、ローカル記憶域上の場所です。

注意:

Identity and Access Managementの処理では、デプロイメントのすべてのホスト上で同じデプロイメント・プロファイルを使用する必要があります。したがって、この画面で入力する場所は、すべてのホストにわたって一貫している必要があります。

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

8.8 仮想ホストの構成

「仮想ホストの構成」画面で、「仮想ホストの構成」を選択します。

トポロジ内の各管理対象サーバーに対して「仮想ホスト名」をたとえば次のように入力します。

- ドメイン管理サーバーのアクセス: IADADMINVHN.mycompany.com (IADADMINVHN)

- ガバナンス・ドメイン管理サーバー: IGDADMINVHN.mycompany.com (IGDADMINVHN)

- SOAサーバー: SOAHOST1VHN.mycompany.com (SOAHOST1VHN)

- SOAサーバー2: SOAHOST2VHN.mycompany.com (SOAHOST2VHN)

- OIMサーバー: OIMHOST1VHN.mycompany.com (OIMHOST1VHN)

- OIMサーバー2: OIMHOST2VHN.mycompany.com (OIMHOST2VHN)

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

8.9 ユーザー名およびパスワードの設定

「ユーザー名およびパスワード」画面には、デプロイメント処理中に作成されるユーザーが表示されます。一覧されたユーザー・アカウントのすべてに対して共通のパスワードを設定するか、必要に応じてアカウントのそれぞれに対して個別のパスワードを設定できます。また、作成された一部のデフォルトのユーザー名を必要に応じて変更することもできます。

共通のIAMパスワードの入力 (COMMON_IDM_PASSWORD): これは、アカウント基準によりアカウント上でオーバーライドされないかぎり、すべてのアカウントで使用されるデフォルトのパスワードです。

共通のIAMパスワードの確認: パスワードを確認します。

注意:

このガイドでは、共通のIAMパスワードが使用されていることを前提としています。

ユーザー・アカウントのユーザー名およびパスワードの変更: デフォルトのユーザー名および共通のパスワードをオーバーライドする場合にはこれを選択します。

変更するアカウントの横の「編集」を選択します。

必要に応じて「ユーザー名」および「パスワード」をオーバーライドします。

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

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

8.10 Oracle Unified Directoryの構成

「Oracle Unified Directory構成」画面で、次の情報を入力します。

- 最初のOUDインスタンスのポート: たとえば、1389 (LDAP_PORT)など、LDAPHOST1でのOUD非セキュア接続に使用するポートです。

- 最初のOUDインスタンスのSSLポート: たとえば、1636 (LDAP_SSL_PORT)など、LDAPHOST1でのOUDセキュア接続に使用するポートです。

- 2番目のOUDインスタンスのポート: たとえば、1389 (LDAP_PORT)など、LDAPHOST2でのOUD非セキュア接続に使用するポートです。

- 2番目のOUDインスタンスのSSLポート: たとえば、1636 (LDAP_SSL_PORT)など、LDAPHOST2でのOUDセキュア接続に使用するポートです。

- OUDレプリケーション・ポート: 8989 (LDAP_REPLIC_PORT)

- アイデンティティ・ストア・レルムDN: dc=mycompany,dc=com (REALM_DN)

- LDAPロード・バランサ詳細:

- エンドポイント: たとえば、OUD Endpoint for ID Storeなどのエンドポイント名です。

- 仮想ホスト名: たとえば、idstore.mycompany.com (LDAP_IDSTORE_NAME)などのアイデンティティ・ストアの仮想ホストです。

- ポート: 1389 (LDAP_LBR_PORT)

- SSLポート: 1636 (LDAP_LBR_SSL_PORT)

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

8.11 Oracle HTTP Serverの構成

「Oracle HTTP Server構成」画面で、必要に応じてポート番号をOracle HTTP Serverの管理対象サーバーが使用するポートに変更します。たとえば、次のようにします。

- ポート: 7777 (WEB_HTTP_PORT)

- SSLポート: 4443 (WEB_HTTPS_PORT)

- 2番目のOHS SSLポート: 7777 (WEB_HTTP_PORT)

- 2番目のOHS SSLポート: 4443 (WEB_HTTPS_PORT)

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

8.12 Oracle Identity Managerの構成

「Oracle Identity Managerの構成」画面の、「Oracle Identity Manager構成パラメータ」に次の情報を入力します。

管理サーバー・ポート: たとえば、7101 (IGD_WLS_PORT)など、IAMGovernanceDomain管理サーバーが使用するポート番号です。

ポート: たとえば、14000 (OIM_PORT)など、最初のOIM管理対象サーバーが使用するポート番号です。

2番目のOIMポート: たとえば、14000 (OIM_PORT)など、最初の管理対象サーバーが使用するポート番号です。

OIMを電子メール通知を送信するように構成する場合には、「電子メール・サーバーの構成」を選択し、次の詳細情報を入力します。

- 送信サーバー名: たとえば、EMAIL.mycompany.com (EMAIL_SERVER)などの、送信電子メール・サーバーの名前です。

- 送信サーバー・ポート: たとえば、465 (EMAIL_PORT)などの、電子メール・サーバーが使用するポートです。

- 送信電子メール・セキュリティ: 「なし」、「SSL」または「TLS」(EMAIL_PROTOCOL)を選択します。

- ユーザー名: 電子メール・サーバーでの認証に使用するユーザー名(EMAIL_USER)です。

- パスワード: 前述のユーザーのパスワード(EMAIL_PASSWORD)です。

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

8.13 Oracle Identity Managerデータベースの構成

Oracle Identity ManagerのDB構成画面で、Identity Managerの情報が格納されるOracle Databaseについて詳細を入力します。

- スキーマ接頭辞: これは、リポジトリ作成アシスタントを実行してデータベース・スキーマを作成したときに使用した接頭辞です。たとえば、EDGIGDなどです。

- サービス名: たとえば、OIMEDG.mycompany.com (OIM_DB_SERVICENAME)などの、データベース・サービスのサービス名です。

- スキーマ・パスワード: RCUでOracle Identity Managerスキーマを作成する際に使用したパスワード、OIM_SCHEMA_PASSWORDです。

- 「RAC DB」を選択します。

- SCANアドレス: たとえば、IAMDBSCAN.mycompany.com (SCAN_ADDRESS)などの、Grid InfrastructureのSCANアドレスを入力します。

注意:

Gridlinkに使用されるOracle Notification Server (ONS)のSCANアドレスのデフォルトの値は、データベースSCANアドレスです。

- スキャン・リスナー・ポート: たとえば、1521 (DB_LSNR_PORT)など、グリッド・インフラストラクチャ・リスナーに使用されるポートを入力します。

- スキャン・ポート: Oracle DatabaseサーバーでRAC srvctlコマンドを次の例に示すように使用して、スキャン(ONS)ポートを決定します。

srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

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

8.14 SOAの構成

次の情報を入力します。

- ポート: たとえば、8001 (SOA_PORT)など、最初のSOA管理対象サーバーが使用するポートです。

- 2番目のSOAポート: たとえば、8001 (SOA_PORT)など、2番目のSOA管理対象サーバーが使用するポートです。

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

8.15 Oracle Access Managerの構成

「Oracle Access Managerの構成」画面で、次の情報を入力します。

- 管理サーバー・ポート: たとえば、7001 (IAD_WLS_PORT)など、IAMAccessDomain管理サーバーが使用するポートです。

- OAMポート: たとえば、14100 (OAM_PORT)など、最初のOAM管理対象サーバーが使用するポートです。

- 2番目のOAMポート: たとえば、14100 (OAM_PORT)など、2番目のOAM管理対象サーバーが使用するポートです。

- Cookieドメイン: たとえば、.mycompany.com (OAM_COOKIE_DOMAIN)などです。

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

8.16 Oracle Access Managerデータベースの構成

デフォルトで、「Oracle Access Manager DB構成」画面には、「Oracle Identity Managerの構成」画面と同じ値が表示されます。必要に応じて、Access Managerの情報が格納されるOracle Databaseについての詳細を入力します。

- スキーマ接頭辞: これは、リポジトリ作成アシスタントを実行してデータベース・スキーマを作成したときに使用した接頭辞です。たとえば、EDGIADなどです。

- サービス名: たとえば、OAMEDG.mycompany.com (OAM_DB_SERVICENAME)などの、データベース・サービスのサービス名です。

- スキーマ・パスワード: RCUでOracle Access Managerスキーマを作成する際に使用したパスワード、OAM_SCHEMA_PASSWORDです。

- 「RAC DB」を選択します。

- SCANアドレス: たとえば、IAMDBSCAN.mycompany.com (SCAN_ADDRESS)などの、Grid InfrastructureのSCANアドレスを入力します。

注意:

Gridlinkに使用されるOracle Notification Server (ONS)のSCANアドレスのデフォルトの値は、データベースSCANアドレスです。

- スキャン・リスナー・ポート: たとえば、1521 (DB_LSNR_PORT)など、グリッド・インフラストラクチャ・リスナーに使用されるポートを入力します。

- スキャン・ポート: srvctlコマンドを次の例に示すように使用して、スキャン(ONS)ポートを決定します。

srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

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

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

8.17 HTTP/HTTPSロード・バランサの構成

「HTTP/HTTPSロード・バランサ」画面で、ロード・バランサの仮想ホストについての詳細を入力します。

「HTTP/HTTPSロード・バランサ詳細」で、各「エンドポイント」に対して「仮想ホスト名」および「ポート」を入力します。

- IAMアクセス・ドメイン管理: IAMAccessDomain管理機能(IAD_DOMAIN_LBRVHN)へのアクセスに使用されるロード・バランサ・エンドポイントです。たとえば、IADADMIN.mycompany.com、ポート80、非SSLなどです。

- IAMガバナンス・ドメイン管理: IAMGovernanceDomain管理機能(IGD_DOMAIN_LBRVHN)へのアクセスに使用されるロード・バランサ・エンドポイントです。たとえば、IGDADMIN.mycompany.com、ポート80、非SSLなどです。

- 内部コールバック: これは、内部コール・バック仮想ホストおよびポート(IAM_INTERNAL_LBRVHN)です。たとえば、idminternal.mycompany.com、ポート80などです。

- SSO: これはメイン・アプリケーション・エントリ・ポイント(IAM_LOGIN_LBRVHN)です。たとえば、sso.mycompany.com、ポート443、常にSSLなどです。

注意:

この画面で入力した4つの仮想ホスト名は、一意にする必要があります。

8.18 サマリー

「サマリー」画面では、「デプロイメント・レスポンス・ファイル名」および格納する「ディレクトリ」を入力します。「デプロイメント・サマリー」フィールドを変更するか、デフォルトのままにしておくことができます。

Identity and Access Managementデプロイメント・ウィザードは、「サマリー」画面で指定するディレクトリに、デプロイメント・レスポンス・ファイルを作成します。また、たとえば、provisioning_dataなど、responsefilename_dataという名前のフォルダを作成します。フォルダには、cwallet.ssoファイルが含まれ、このファイルには暗号化および復号化の情報があります。このデプロイメント・レスポンス・ファイルを別の場所に移動した場合、cwallet.ssoファイルを含むresponsefilename_dataフォルダも同じ場所に移動またはコピーする必要があります。

「終了」をクリックするとデプロイメント・レスポンス・ファイルが作成されます。

9 Identity and Access Managementのデプロイ

この章では、Identity Managementをデプロイする方法について説明します。

次の項で構成されます。

- 第9.1項「デプロイメント処理の概要」

- 第9.2項「デプロイメント手順」

- 第9.3項「チェック・リスト」

- 第9.4項「共通のLCM_HOMEのないIdentity and Access Managementのデプロイメント」

9.1 デプロイメント処理の概要

この項では、デプロイメント処理について説明します。

9.1.1 デプロイ・ステージ

デプロイには、8つのステージがあります。これらのステージは次のとおりです。

1. 事前検査: トポロジで使用しているサーバーのそれぞれが、インストールおよび構成されているソフトウェアの最低要件を満たしていることを確認します。また、スキーマおよびポート可用性のためのデータベース接続についても確認します。

2. インストール: インストールで必要なソフトウェアをすべてインストールします。また、これには、リポジトリに含まれるすべてのパッチに対するバイナリ・パッチも含まれます。

3. 事前構成: 次のことを行います。

- Oracle Unified Directoryインスタンスを作成し、それらをユーザーまたはグループでシードします。

- WebLogicドメインを作成し、ドメインを各種製品向けに拡張します。

- OHSインスタンスを作成します。

- データベースにポリシー・ストアを移行します。

4. 構成: 次のことを行います。

- 必要に応じて管理対象サーバーを起動します。

- Access ManagerをOracle Unified Directoryと関連付けます。

- Oracle Identity Managerを構成します。

5. セカンダリの構成: 次のことを行います。

- WeblogicドメインをWeb層に統合します。

- ドメインにWeb層を登録します。

- Access ManagerとOracle Identity Managerを統合します。

6. 事後構成: 次のことを行います。

- Oracle Identity Managerのリコンシリエーションを実行します。

- UMSメール・サーバーを構成します。

- Access Managerキーストアを生成します。

- Webゲートを構成します。

7. 起動: トポロジ内のすべてのコンポーネントを起動し、必要なアーティファクト・パッチを適用します。

8. 検証: 構築されたトポロジ上で数多くのチェックを行い、すべてが期待どおりに機能していることを確認します。

各ステージは、次の項で説明するように、特定の順序ですべてのホストで完了する必要があります。各ステージは、次のステージを開始する前に、トポロジ内の各ホストで完了している必要があります。ステージが失敗すると、クリーンアップおよび再起動が必要になります。詳細は、付録B「IAMデプロイ実行前の環境のクリーンアップ」を参照してください。

9.1.2 処理順序

次の順序でホストを処理する必要があります。

1. LDAPホスト1

2. LDAPホスト2

3. アイデンティティ・ガバナンス・ホスト1

4. アイデンティティ・ガバナンス・ホスト2

5. Access Managementホスト1

6. Access Managementホスト2

7. Webホスト1

8. Webホスト2

これは、このガイドのホストの次の順序と同様です。

統合リスト

1. IAMHOST1

2. IAMHOST2

3. WEBHOST1

4. WEBHOST2

分散リスト

1. LDAPHOST1

2. LDAPHOST2

3. OIMHOST1

4. OIMHOST2

5. OAMHOST1

6. OAMHOST2

7. WEBHOST1

8. WEBHOST2

9.2 デプロイメント手順

次の項では、デプロイメントを実行するための手順を説明します。

- 第9.2.1項「デプロイメント・コマンドの実行」

- 第9.2.2項「バックアップの作成」

9.2.1 デプロイメント・コマンドの実行

Identity and Access Managementをデプロイするには、次の場所からトポロジ内の各ホストでrunIAMDeployment.shを複数回実行します。

IDMLCM_HOME/provisioning/bin

デプロイメント処理を開始する前に、この項全体をお読みください。処理中に実行する必要のある、さらに詳しい手順を次に説明します。

注意:

- デプロイメントのすべてのターゲットおよびすべてのホストにおいて、同じバージョンのデプロイメント・プロファイル(IDMLCM_HOME/provisioning/bin/provisioning.rsp)を使用する必要があります。

- 次のコマンドを実行する前に、トポロジ内の各ホストで各コマンドを指定された順序で実行する必要があります。

デプロイメント・ツールを実行する前に、次の環境変数を設定します。

- JAVA_HOMEをREPOS_HOME/jdk6に設定します。

実行する必要のあるコマンドは次のとおりです。

runIAMDeployment.sh -responseFile IDMLCM_HOME/provisioning/bin/provisioning.rsp -target preverify

runIAMDeployment.sh -responseFile IDMLCM_HOME/provisioning/bin/provisioning.rsp -target install

runIAMDeployment.sh -responseFile IDMLCM_HOME/provisioning/bin/provisioning.rsp -target preconfigure

runIAMDeployment.sh -responseFile IDMLCM_HOME/provisioning/bin/provisioning.rsp -target configure

runIAMDeployment.sh -responseFile IDMLCM_HOME/provisioning/bin/provisioning.rsp -target configure-secondary

runIAMDeployment.sh -responseFile IDMLCM_HOME/provisioning/bin/provisioning.rsp -target postconfigure

runIAMDeployment.sh -responseFile IDMLCM_HOME/provisioning/bin/provisioning.rsp -target startup

runIAMDeployment.sh -responseFile IDMLCM_HOME/provisioning/bin/provisioning.rsp -target validate

9.2.2 バックアップの作成

次の時点でファイル・システムおよびデータベースのバックアップを取ることが大切です。

1. デプロイメントの開始前。

2. インストール・フェーズの最後。

3. デプロイメントの完了後。

これら3つのフェーズ以外でバックアップをリストアすることはサポートされていません。

9.3 チェック・リスト

デプロイメント処理を記録するために、このガイドのPDF版からこのチェック・リストを印刷して利用できます。示されているホストで各ステージを実行し、実行が完了したら対応する行にチェック・マークを付けてください。

統合:

デプロイ・ステージ

ホスト

完了

事前検査

IAMHOST1

IAMHOST2

WEBHOST1

WEBHOST2

インストール

IAMHOST1

IAMHOST2

WEBHOST1

WEBHOST2

事前構成

IAMHOST1

IAMHOST2

WEBHOST1

WEBHOST2

構成

IAMHOST1

IAMHOST2

WEBHOST1

WEBHOST2

セカンダリの構成

IAMHOST1

IAMHOST2

WEBHOST1

WEBHOST2

事後構成

IAMHOST1

IAMHOST2

WEBHOST1

WEBHOST2

起動

IAMHOST1

IAMHOST2

WEBHOST1

WEBHOST2

検証

IAMHOST1

IAMHOST2

WEBHOST1

WEBHOST2

分散:

デプロイ・ステージ

ホスト

完了

事前検査

LDAPHOST1

LDAPHOST2

OIMHOST1

OIMHOST2

OAMHOST1

OAMHOST2

WEBHOST1

WEBHOST2

インストール

LDAPHOST1

LDAPHOST2

OIMHOST1

OIMHOST2

OAMHOST1

OAMHOST2

WEBHOST1

WEBHOST2

事前構成

LDAPHOST1

LDAPHOST2

OIMHOST1

OIMHOST2

OAMHOST1

OAMHOST2

WEBHOST1

WEBHOST2

構成

LDAPHOST1

LDAPHOST2

OIMHOST1

OIMHOST2

OAMHOST1

OAMHOST2

WEBHOST1

WEBHOST2

セカンダリの構成

LDAPHOST1

LDAPHOST2

OIMHOST1

OIMHOST2

OAMHOST1

OAMHOST2

WEBHOST1

WEBHOST2

事後構成

LDAPHOST1

LDAPHOST2

OIMHOST1

OIMHOST2

OAMHOST1

OAMHOST2

WEBHOST1

WEBHOST2

起動

LDAPHOST1

LDAPHOST2

OIMHOST1

OIMHOST2

OAMHOST1

OAMHOST2

WEBHOST1

WEBHOST2

検証

LDAPHOST1

LDAPHOST2

OIMHOST1

OIMHOST2

OAMHOST1

OAMHOST2

WEBHOST1

WEBHOST2

9.4 共通のLCM_HOMEのないIdentity and Access Managementのデプロイメント

前述のデプロイメント手順は、デプロイメント処理中にLCM_HOMEディレクトリがトポロジ内の各ホスト間で共有されていることを前提としています。

組織でこの共有が許可されていない場合でも、各ホストでLCM_HOMEをローカルで使用可能にしてデプロイメントを実行できます。追加で次の手動の手順が必要になります。

1. ソフトウェア・リポジトリを含むLCM_HOMEディレクトリのローカル・バージョンを作成します。

2. デプロイメント・レスポンス・ファイル、responsefilename_dataフォルダおよび第8.18項「サマリー」で作成したサマリーを各ホストの同じ場所にコピーします。

3. デプロイメント・ツールは、LCM_HOME/provisioningにあるディレクトリの内容を使用して、正常に実行されたステージを判断します。したがって、各コマンドの実行後、runIAMDeployment.shコマンドを実行する前に、このディレクトリの内容をすべてのノードにコピーします。
LCM_HOMEがディレクトリ・ホストに共有されていない場合、LDAPHOSTで事前構成を実行する前に、OAMHOST1からLDAPHOST1およびLDAPHOST2にLCM_HOME/internalをコピーします。

LCM_HOME/internalは、OAMHOSTでのインストール・フェーズ後に作成されます。

4. OIMHOST1で事前構成を実行する前に、LDAPHOST1からOAMHOST1にLCM_HOME/keystoresをコピーします。

5. LCM_HOMEがWEBHOST1およびWEBHOST2にマウントされていない場合、WEBHOST1での事後構成フェーズの実行前に、OAMHOST1からWEBHOST1およびWEBHOST2にLCM_HOME/keystores/webgate_artifactsをコピーします。
OAMHOST1に対する構成セカンダリ・フェーズの後にLCM_HOME/keystores/webgate_artifactsが作成されます。

10 デプロイ後構成の実行

この章では、デプロイ後に実行する必要のあるタスクについて説明します。

次の項で構成されます。

- 第10.1項「デプロイ後のOPSSの手順」

- 第10.2項「デプロイ後のOracle Unified Directoryの手順」

- 第10.3項「デプロイ後のOracle Identity Managerの手順」

- 第10.5項「デプロイ後のAccess Managerの手順」

- 10.6項「トラスト・ストアへのロード・バランサ証明書の追加」

- 第10.7項「すべてのコンポーネントの起動」

10.1 デプロイ後のOPSSの手順

このリリースのIdentity and Access Managementでは、最適化されたOPSSが使用可能です。この最適化されたOPSSを使用するには、OPSSスキーマをアップグレードする必要があります。デプロイメント・ツールではこれは行われないため、プロビジョニングの最後にパッチ・セット・アシスタントを使用してこの手順を手動で実行する必要があります。

EDGIADおよびEDGIGDのOPSSスキーマをアップグレードする手順:

1. IAD_MW_HOME/oracle_common/binの場所からpsaコマンドを実行してパッチ・セット・アシスタントを起動します。例:

./psa

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

3. 「コンポーネントの選択」画面で、「Oracle Platform Security Services」のみを選択し、「次へ」をクリックします。

4. 「前提条件」画面で、データベース・バックアップがあるかどうか、そのデータベースのバージョンは保証されているかどうかを指定します。
「次へ」をクリックします。

5. 「スキーマ」ページで次のように入力します。

- スキーマ・ユーザー名: 例: EDGIAD_OPSS

- パスワード: RCUを実行した際に提供したパスワード。

- データベース・タイプ: Oracle Database

- 接続文字列: IDMDB-SCANOAM :DB_LSNR_PORT/OAM_DB_SERVICENAME(例: IAMDB-SCAN.mycompany.com:1521/oamedg.mycompany.com)

- DBAユーザー名: sys as sysdba

- DBAパスワード: PASSWORD

「接続」をクリックします。

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

6. 「調査」ページに「成功」が表示されていることを確認し、「次へ」をクリックします。

7. 「アップグレード・サマリー」ページで、情報が正しいことを確認し、「アップグレード」をクリックします。

8. アップグレードが完了したら、「次へ」をクリックします。

9. 「アップグレード成功」ページで「閉じる」をクリックします。

10. 次の場所にあるログ・ファイルを確認してスキーマのアップグレードが成功したことを確認します。

IAD_MW_HOME/oracle_common/upgrade/logs/psa/psatimestamp.log

11. ドメインを再起動します。

12. OPSSスキーマをアップグレードしたら、次のコマンドを実行します。

SELECT VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY WHERE OWNER='<RCU_Prefix>_OPSS';

バージョンは11.1.1.7.2で、「アップグレード」フラグは「はい」になります。

10.2 デプロイ後のOracle Unified Directoryの手順

Oracle Unified Directoryで次の手順を実行します。

10.2.1 Oracle Unified Directory変更ログ・アクセスの更新

Oracle Unified DirectoryおよびOracle Identity Managerを使用している場合、すべてのOUDホスト(LDAPHOST1およびLDAPHOST2)で次の手順を実行して、変更ログへのアクセス権を付与します。

変更ログへのアクセス権を付与する手順:

1. レプリケーションしたOUDホストのいずれかで次のコマンドを発行して、既存の変更ログの権限を削除します。

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--remove global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; deny (all) userdn=\"ldap:///anyone\";)" \
--hostname OUD_HOST \
--port OUD_ADMIN_PORT \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile passwordfile \
--no-prompt

例:

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--remove global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; deny (all) userdn=\"ldap:///anyone\";)" \
--hostname LDAPHOST1.mycompany.com \
--port 4444 \
--trustAll  \
--bindDN cn=oudadmin \
--bindPasswordFile mypasswordfile \
--no-prompt

2. 次の新しいACIを追加します。

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--add global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; allow (read,search,compare,add,write,delete,export) groupdn=\"ldap:///cn=OIMAdministrators,cn=groups,dc=mycompany,dc=com\";)" \
--hostname OUD_HOST \
--port OUD_ADMIN_PORT \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile passwordfile \
--no-prompt

例:

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--add global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; allow (read,search,compare,add,write,delete,export) groupdn=\"ldap:///cn=OIMAdministrators,cn=groups,dc=mycompany,dc=com\";)" \
--hostname LDAPHOST1.mycompany.com \
--port 4444 \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile mypasswordfile \
--no-prompt

10.2.2 LDAP同期化のためのOracle Unified Directory ACIの更新

次に、LDAP同期が有効な場合のOracle Unified Directory操作の失敗時の回避策を説明します。

LDAP同期が有効にされている環境では、Oracle Unified Directoryに対する特定の操作が、Oracle Unified Directoryログにおける次のエラーで失敗となります。

The request control with Object Identifier (OID) "1.2.840.113556.1.4.319" cannot be used due to insufficient access rights

この問題を回避するには、Oracle Unified Directoryの両方のインスタンスの構成ファイルを編集する必要があります。

1. Oracle Unified Directoryの構成ファイルOUD_ORACLE_INSTANCE/OUD/config/config.ldifにおいて、次のように制御1.2.840.113556.1.4.319のACIをldap://allからldap://anyoneに変更します。
変更前:

ds-cfg-global-aci: (targetcontrol="1.3.6.1.1.12 || 1.3.6.1.1.13.1 || 1.3.6.1.1.13.2 || 1.2.840.113556.1.4.319 || 1.2.826.0.1.3344810.2.3 || 2.16.840.1.113730.3.4.18 || 2.16.840.1.113730.3.4.9 || 1.2.840.113556.1.4.473 || 1.3.6.1.4.1.42.2.27.9.5.9") (version 3.0; acl "Authenticated users control access"; allow(read) userdn="ldap:///all";)

変更後:

ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 || 2.16.840.1.113730.3.4.16 || 2.16.840.1.113894.1.8.31 || 1.2.840.113556.1.4.319") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";)

2. 第15.1項「コンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryサーバーを再起動します。

10.3 デプロイ後のOracle Identity Managerの手順

次のデプロイ後の手順を実行します。

- 10.3.1項「既知の問題に対処するためのデプロイメント後の手順」

- 10.3.2項「サーバー起動パラメータの更新」

10.3.1 既知の問題に対処するためのデプロイメント後の手順

既知の問題により、ノード・マネージャSSLは完全に構成されていません。回避策は、各ドメインのデプロイメントの管理サーバーおよび管理対象サーバーごとに、次の手順を実行します。

1. 15.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、ドメインのWebLogicコンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「環境」→「サーバー」に移動します。

4. サーバー名(例: wls_oam1)をクリックします。

5. 「SSL」タブをクリックします。

6. 「拡張オプション」を展開し、「ホスト名の検証」を「BEAホスト名の検証」に変更します。

7. 「保存」をクリックします。

8. ドメインのサーバーごとに繰り返します。

9. 「変更のアクティブ化」をクリックします。

10. ドメインを再起動します。

11. 2番目のドメインで繰り返します。

10.3.2 サーバー起動パラメータの更新

Identity and Access Managementデプロイメント・ツールの既知の問題の回避策として、Oracle Identity Managerプロパティを追加する必要があります。次の手順を実行してください。

1. IAMGovernanceDomainのWebLogicコンソールにログインします。(コンソールのURLは第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されています。)

2. 「環境」→「サーバー」と移動します。

3. 「ロックして編集」をクリックします。

4. 「WLS_OIM1」サーバーをクリックします。

5. 「サーバーの起動」サブタブをクリックします。

6. 「引数」フィールドに次の追加を行います。

-Djava.net.preferIPv4Stack=true

7. 「保存」をクリックします。

8. 管理対象サーバー「WLS_OIM2」に対し手順4から7を繰り返します。

9. 「変更のアクティブ化」をクリックします。

10.4 デプロイ後の電子メール・サーバーの手順

第8.12項「Oracle Identity Managerの構成」で電子メール・サーバーを構成しており、電子メール・サーバーのセキュリティがSSLの場合、次の追加手順を実行します。

1. プロキシが環境用に設定されていることを確認します。

1. IAMGovernanceDomain管理サーバーおよびOIM管理対象サーバー(wls_oim1/2)を停止します。

2. IGD_MSERVER_HOME/bin/setDomainEnv.shをバックアップします。

3. IGD_MSERVER_HOME/bin/setDomainEnv.shをプロキシ設定を含むように変更します。

4. このコマンドを環境設定の一部としてsetDomainEnv.shファイルに含めます。

export PROXY_SETTINGS="-Dhttp.proxySet=true -Dhttp.proxyHost=www-proxy.mycompany.com -Dhttp.proxyPort=80 -Dhttp.nonProxyHosts=localhost|$.mycompany.com|.mycompany.com|.oracle.com"

例:

export JAVA_PROPERTIES
export PROXY_SETTINGS="-Dhttp.proxySet=true -Dhttp.proxyHost=www-proxy.mycompany.com -Dhttp.proxyPort=80 -Dhttp.nonProxyHosts=localhost|${HOST}|*.mycompany.com"ARDIR="${WL_HOME}/server/lib"
export ARDIR

2. SOA環境からDemoTrustストア参照を削除します。これによりSOAを非SSLモードで実行することになります。

1. DemoTrust参照を削除するために、IGD_MSERVER_HOMEを変更します。

2. setDomainEnv.shからこの参照を削除します。

-Djavax.net.ssl.trustStore=$<WL_HOME>/server/lib/DemoTrust.jks from EXTRA_JAVA_PROPERTIES

3. 管理サーバーおよび管理対象サーバーの両方を再起動します。

10.5 デプロイ後のAccess Managerの手順

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

- 第10.5.1項「アイドル・タイムアウト値の更新」

- 第10.5.2項「Webゲート・エージェントの更新」

10.5.1 アイドル・タイムアウト値の更新

デフォルトでAccess Managerのアイドル・タイムアウトは2時間に設定されています。これは、セッションがタイムアウトになった後にログアウトしていない状態で問題が発生する場合があります。この値を15分に更新します。

アイドル・タイムアウト値を更新する手順:

1. 第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用して、Access Managementコンソールにログインします。

2. 8.9項「ユーザー名およびパスワードの設定」で作成したAccess Manager管理者ユーザー(例: oamadmin)としてログインします。

3. 「構成」の「共通設定」をクリックします。

4. 「アイドル・タイムアウト(分)」を15に変更します。

5. 「適用」をクリックします。

10.5.2 Webゲート・エージェントの更新

デプロイメント後に、既存のWebゲート・エージェントを更新します。Identity and Access ManagementコンソールのURLは第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されています。

すでに設定されているはずのWebgate_IDMおよびWebgate_IDM_11g以外の、Webゲート・プロファイルのAccess Managerセキュリティ・モデルを更新します。さらにIAMSuiteAgentプロファイルのパスワードを、統合用のOAAMに使用できるように設定します。(IAMSuiteAgentはAccess Managerがインストールされたときに作成されています。)

これらのWebゲート・エージェントを更新する手順:

1. 8.9項「ユーザー名およびパスワードの設定」のエントリで特定されたAccess Management管理者ユーザーとしてAccess Managementコンソールにログインします。

2. 「Access Manager」ボックスの「SSOエージェント」をクリックします。

3. 「Webゲート」タブが選択されていることを確認します。

4. 「検索」をクリックします。

5. たとえば、「IAMSuiteAgent」などのエージェントをクリックします。

6. 第8.15項「Oracle Access Managerの構成」の「Access Manager構成」画面の「OAM転送モード」に定義した値と同じセキュリティ値を設定します。
「適用」をクリックします。

7. 「プライマリ・サーバー」リストで、「+」をクリックし、不足しているAccess Managerサーバーを追加します。

8. まだパスワードを割り当てていない場合には、アクセス・クライアント・パスワード・フィールドにパスワードを入力し、「適用」をクリックします。
アクセス・クライアント・パスワードを設定した場合には、第8.9項「ユーザー名およびパスワードの設定」で使用した共通のIAMパスワード(COMMON_IDM_PASSWORD)、またはAccess Manager独自のパスワードなどを割り当てます。

9. プライマリ・サーバーのリストに表示されているすべてのAccess Managerサーバーについて、「接続の最大数」を20に設定します。(これはプライマリ・サーバーの合計の最大接続数で、10 x WLS_OAM1接続プラス10 x WLS_OAM2接続となります。)

10. 「ユーザー定義パラメータ」に次のように表示されている場合、

logoutRedirectUrl=http://OAMHOST1.mycompany.com:14100/oam/server/logout

これを次のように変更します。

logoutRedirectUrl=https://sso.mycompany.com/oam/server/logout

11. 「適用」をクリックします。

12. Webゲートごとに手順を繰り返します。

13. セキュリティ設定が、使用しているAccess Managerサーバーの設定と一致していることを確認します。

10.6 トラスト・ストアへのロード・バランサ証明書の追加

Oracle Privileged Account Manager (OPAM)では、ロード・バランサで使用されるSSL証明書を、OPAMで使用されるJDK内の信頼できる証明書に追加する必要があります。

証明書を追加する手順:

1. ロード・バランサから証明書を取得します。
ロード・バランサの証明書は、Firefoxなどのブラウザを使用して取得できます。ただし、証明書を取得する最も簡単な方法は、opensslコマンドを使用します。コマンドの構文は、次のとおりです。

openssl s_client -connect LOADBALANCER -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM > SHARED_CONFIG_DIR/keystores/sso.mycompany.com.pem

例:

openssl s_client -connect sso.mycompany.com:443 -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM > SHARED_CONFIG_DIR/keystores/sso.mycompany.com.pem

このコマンドでは、次のディレクトリ内のsso.mycompany.com.pemの名前のファイルに証明書が保存されます。

SHARED_CONFIG_DIR/keystores

2. 次のコマンドを実行して、CA証明書ファイルsso.mycompany.com.pemをIGD_MW_HOME Java、およびノード・マネージャのトラスト・ストアにインポートし、証明書をJDKおよびノード・マネージャのトラスト・ストアにロードします。

set JAVA_HOME to IGD_MW_HOME/jdk6
set PATH to include JAVA_HOME/bin

keytool -importcert -file SHARED_CONFIG_DIR/keystores/sso.mycompany.com.pem -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts

keytool -importcert -file SHARED_CONFIG_DIR/keystores/sso.mycompany.com.pem -trustcacerts -keystore
SHARED_CONFIG_DIR/keystores/appTrustKeyStore-oimhost1vhn.mycompany.com.jks

keytool -importcert -file SHARED_CONFIG_DIR/keystores/sso.mycompany.com.pem -trustcacerts -keystore
SHARED_CONFIG_DIR/keystores/appTrustKeyStore-oimhost2vhn.mycompany.com.jks

keytool -importcert -file SHARED_CONFIG_DIR/keystores/sso.mycompany.com.pem -trustcacerts -keystore
SHARED_CONFIG_DIR/keystores/appTrustKeyStore-oimhost1.mycompany.com.jks

keytool -importcert -file SHARED_CONFIG_DIR/keystores/sso.mycompany.com.pem -trustcacerts -keystore
SHARED_CONFIG_DIR/keystores/appTrustKeyStore-oimhost2.mycompany.com.jks

ここで、JAVA_HOMEはIGD_MW_HOME/jdk6に設定されます。

キーストアのパスワードを入力するように求められます。JDKのデフォルトのパスワードはchangeitで、ノード・マネージャのキーストアのデフォルトのパスワードはCOMMON_IAM_PASSWORDです。証明書が有効であることを確認するようにも求められます。

注意:

OIMサーバーに割り当てた仮想ホストの名前は、oimhost1vhnおよびoimhost2vhnです。

10.7 すべてのコンポーネントの再起動

第15.1項「コンポーネントの起動と停止」の説明に従い、すべてのコンポーネントを再起動します。

11 デプロイメントの検証

デプロイメント処理には、すべてが正常に動作していることを確認する複数の検証チェックがあります。この章では、追加の健全性のチェックを実行できる追加チェックについて説明します。

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

- 第11.1項「管理サーバーの検証」

- 第11.2項「Access Managerの構成の検証」

- 第11.3項「Oracle Identity Managerの検証」

- 第11.4項「Web層からのSOAインスタンスの検証」

- 第11.5項「Oracle Unified Directoryの検証」

- 第11.6項「WebゲートおよびAccess Managerのシングル・サインオンのセットアップの検証」

11.1 管理サーバーの検証

WebLogic管理サーバーは次のように検証します。

11.1.1 接続の検証

次のURLにアクセスして、ユーザーweblogic_idmとしてログインし、WebLogic管理コンソールにアクセスできることを確認します。

http://IADADMIN.mycompany.com/console

http://IGDADMIN.mycompany.com/console

すべての管理対象サーバーがステータス「実行中」を示していることを確認します。

次のURLにアクセスして、ユーザーweblogic_idmとしてログインし、Oracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認します。

http://IADADMIN.mycompany.com/em

http://IGDADMIN.mycompany.com/em

11.1.2 フェイルオーバーの検証

第15.8項「WebLogic管理サーバーの手動フェイルオーバー」で説明されているように、OAMHOST2へのアクセス管理サーバーのフェイルオーバーをテストし、OAMHOST1にフォールバックします。

第15.8項「WebLogic管理サーバーの手動フェイルオーバー」で説明されているように、OIMHOST2へのアイデンティティ・ガバナンス管理サーバーのフェイルオーバーをテストし、OIMHOST1にフォールバックします。

11.2 Access Managerの構成の検証

ここまでの操作が正しいことを確認する手順は次のとおりです。

1. http://IADADMIN.mycompany.com/oamconsoleにあるAccess Managementコンソールにアクセスします。

2. oamadminユーザーまたは第8.9項「ユーザー名およびパスワードの設定」のエントリで特定されたユーザーとしてログインします。

3. 「システム構成」タブをクリックします。

4. 「Access Manager」セクションの「SSOエージェント」をクリックします。

5. 「検索」をクリックします。

6. Webゲート・エージェントWebgate_IDM、Webgate_IDM_11g、IAMSuiteAgentおよびaccessgate-oicが表示されます。

11.3 Oracle Identity Managerの検証

Webブラウザで次のURLを指定してOracle Identity Managerセルフ・サービス・コンソールを起動することによって、Oracle Identity Managerサーバー・インスタンスを検証します。

https://SSO.mycompany.com:443/identity

https://igdadmin.mycomapany.com/identity

xelsysadmユーザー名とパスワードを使用して、ログインします。

11.4 Web層からのSOAインスタンスの検証

次のURLにアクセスし、SOAを検証します。

http://IDMINTERNAL.mycompany.com:80/soa-infra

またxelsysadmユーザー名とパスワードを使用して、ログインできることを確認します。

11.5 Oracle Unified Directoryの検証

構成後、単純検索を実行することによってOracle Unified Directoryが動作することを検証できます。これを実行するには、次のコマンドを発行します。

OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h LDAPHOST1.mycompany.com -p 1389 -D cn=oudadmin -b "" -s base "(objectclass=*)" supportedControl

OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h LDAPHOST2.mycompany.com -p 1389 -D cn=oudadmin -b "" -s base "(objectclass=*)" supportedControl

OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h IDSTORE.mycompany.com -p 389 -D cn=oudadmin -b "" -s base "(objectclass=*)" supportedControl

Oracle Unified Directoryが正常に動作している場合、リストsupportedControlエントリが返されます。

Oracle Unified Directoryレプリケーションが有効になっていることを確認するには、次のコマンドを発行します。

OUD_ORACLE_INSTANCE/OUD/bin/status

サーバー証明書を信頼する方法を求められた場合、有効なオプションは次のとおりです。

- 自動的に信頼

- トラストストアを使用

- 手動で検証

いずれかを選択します。

管理者バインドDN (cn=oudadmin)およびそのパスワードの入力を要求されます。

次の例のような出力が表示されます。レプリケーションは有効に設定されます。

--- Server Status ---
Server Run Status: Started
Open Connections: 2

--- Server Details ---
Host Name: ldaphost1
Administrative Users: cn=oudadmin
Installation Path: /u01/oracle/products/dir/oud
Instance Path: /u02/private/oracle/config/instances/oud1/OUD
Version: Oracle Unified Directory 11.1.2.2.0
Java Version: 1.6.0_29
Administration Connector: Port 4444 (LDAPS)

--- Connection Handlers ---
Address:Port : Protocol : State
-------------:-------------:---------
-- : LDIF : Disabled
8989 : Replication : Enabled
0.0.0.0:161 : SNMP : Disabled
0.0.0.0:1389 : LDAP : Enabled
0.0.0.0:1636 : LDAPS : Enabled
0.0.0.0:1689 : JMX : Disabled

--- Data Sources ---
Base DN: dc=mycompany,dc=com
Backend ID: userRoot
Entries: 1
Replication: Enabled
Missing Changes: 0
Age Of Oldest Missing Change: <not available>

11.6 WebゲートおよびAccess Managerのシングル・サインオンのセットアップの検証

Webゲートが正しく機能していることを検証するには、Webブラウザを開き、http://IADADMIN.mycompany.com/oamconsoleにあるAccess Managementコンソールに移動します。

これでAccess Managerのログイン・ページが表示されます。Access Manager管理者ユーザー名(oamadminなど)とパスワードを入力し、「ログイン」をクリックします。Access Managementコンソールが表示されます。

シングル・サインオン設定を検証するには、ブラウザを開き、http://IADADMIN.mycompany.com/consoleにあるWebLogic管理コンソールおよびhttp://IADADMIN.mycompany.com/emにあるOracle Enterprise Manager Fusion Middleware Controlに移動します。

シングル・サインオン・ログイン・ページが表示されます。weblogic_idmユーザーの資格証明を入力してログインします。

11.7 デプロイメントの検証

次のテストは、デプロイメントを確実に行うために実行可能な一連のテストです。

SSOのテスト

次のURLを使用して、ユーザーxelsysadmとしてOracle Identity Managerセルフ・サービス・コンソールにログインします。

https://sso.mycompany.com/identity(xelsysadmnとして)

次のURLを使用して、OIMシステム管理コンソールにログインを試みます。

http://igdadmin.mycompany.com/sysadmin

前述の手順ですでにOIMセルフ・サービス・コンソールにログインしているため、xelsysadm証明書を再度入力するように求められることはありません。

OAMで使用するOUDでの新規ユーザーの作成

OUDに新規ユーザーを作成する手順:

1. 次のURLを使用して、xelsysadminとしてOracle Identity Managementセルフ・サービス・コンソールにログインします。

http://sso.mycompany.com:443/identity

2. 「管理」の「ユーザー」をクリックします。

3. 「アクション」メニューから「作成」を選択します。

4. 表示されるフォームで、ユーザーに関する情報を入力し、「送信」をクリックします。

5. 「サインアウト」をクリックします。

6. 次のURLを使用して、新規作成したユーザーとしてOracle Identity Managementセルフ・サービス・コンソールにログインします。

http://sso.mycompany.com:443/identity

最初のログイン時に、チャレンジ質問を設定する必要があります。これは、ユーザーがOUDに追加され、OAMを使用してOIMにログインできることを示します。

承認用のSOAワークフローのテスト

承認用のSOAワークフローをテストする手順:

1. 次のように、保護されたリソースにアクセスします。

http://igdadmin.mycompany.com/sysadmin

2. 新規アカウントの登録をクリックします。

3. 新規アカウントの情報を入力し、「登録」をクリックします。

4. 「戻る」をクリックして、リクエスト番号をメモします。

5. xelsysadmユーザーとして、Oracle Identity Managementセルフ・サービス・コンソールにログインします。

6. 「受信トレイ」をクリックします。

7. リクエストは「承認の保留」のリストに表示されます。

8. リクエストをクリックし、「アクション」メニューから「承認」を選択します。

9. Identity Managementセルフ・サービス・コンソールからログアウトします。

10. 新規作成したユーザーとして再度ログインします。

12 Oracle Adaptive Access Managerを追加するためのドメインの拡張

この章では、Identity and Access Managementのドメインを拡張して、Oracle Adaptive Access Managerを追加する手順を説明します。

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

- 第12.1項「OAAMを追加するためのドメインの拡張の概要」

- 第12.2項「OAAMの詳細」

- 第12.3項「前提条件」

- 第12.4項「Oracle Adaptive Access Managerのドメインの拡張」

- 第12.5項「OAMHOST1上での管理サーバーの再起動」

- 第12.6項「ローカル・ストレージへの管理対象サーバーの構成の展開」

- 第12.7項「スクリプトを起動および停止するためのOAAMサーバーの追加」

- 12.8項「OAMHOST1上でのOAAMの起動と検証」

- 12.9項「OAMHOST2上でのOAAMの起動と検証」

- 第12.10項「Web層と連携するためのOAAMの構成」

- 第12.12項「Oracle Adaptive Access ManagerとOracle Access Management Access Managerの統合」

- 第12.12項「Oracle Adaptive Access ManagerとOracle Access Management Access Managerの統合」

- 12.13項「Oracle Adaptive Access Manager 11gとOracle Identity Manager 11gの統合」

- 第12.14項「Oracle Adaptive Access Managerの保護へのドメインの変更」

- 第12.15項「アプリケーション層の構成のバックアップ」

12.1OAAMを追加するためのドメインの拡張の概要

Oracle Adaptive Access Manager (OAAM)は、プラットフォームのプレゼンテーション層、ビジネス・ロジック層およびデータ層を独立させた、Java EEベースの複数層デプロイメント・アーキテクチャ上に構築されています。このように各層が独立しているので、OAAMは、お客様のパフォーマンス要件に合せてすばやく規模を調整できます。このアーキテクチャでは、Java、XMLおよびオブジェクト・テクノロジを組み合せた、最も柔軟でサポート対象となっているクロス・プラットフォームのJava EEサービスを利用できます。このアーキテクチャによって、OAAMはスケーラブルでフォルト・トレラントなソリューションとなっています。

Oracle Adaptive Access Managerは、次の2つのコンポーネントで構成されています。

- OAAM管理アプリケーション

- OAAMサーバー・アプリケーション

12.2 OAAMの詳細

このワークシートを使用してOAAMの情報を記録します。

表12-1 OAAMの詳細

説明

ドキュメント内での変数

ドキュメント内での値

実際の値

OAAM管理対象サーバーの名前

wls_oaam1

wls_oaam2

OAAM管理対象サーバーのポート

OAAM_PORT

14300

OAAM管理対象サーバーのSSLポート

OAAM_SSL_PORT

14301

OAAM管理サーバーの名前

wls_oaam_admin1

wls_oaam_admin2

OAAM管理ポート

OAAM_ADMIN_PORT

14200

OAAM管理SSLポート

OAAM_ADMIN_SSL_PORT

14201

アイデンティティ・ストア・ホスト

LDAP_HOST

LDAPHOST1.mycompany.com

アイデンティティ・ストア・ポート

LDAP_PORT

1389

アイデンティティ・ストア・バインドDN

LDAP_ADMIN_USER

cn=oudadmin

アイデンティティ・ストア管理者ポート

LDAP_DIR_ADMIN_PORT

4444

アイデンティティ・ストア・グループ検索ベース

LDAP_GROUP

cn=Groups,dc=mycompany,dc=com

OAAM管理ユーザー

OAAMADMINUSER

oaamadmin

Access Managerホスト1(統合)

OAMHOST1

IAMHOST1

Access Managerホスト2(統合)

OAMHOST2

IAMHOST2

Access Managerホスト1(分散)

OAMHOST1

OAMHOST1

Access Managerホスト2(分散)

OAMHOST2

OAMHOST2

注意:

1つのLDAPHOSTのみを指定する必要があり、LDAPロード・バランサ名にしないでください。

12.3 前提条件

次の各項では、分散モードについて説明します。統合デプロイメントを使用している場合、表12-1に示されたOAMHOST1およびOAMHOST2への参照はIAMHOST1およびIAMHOST2に置き換える必要があります。

Oracle Adaptive Access Manager (OAAM)を含めるようにドメインを拡張する前に、次の前提条件が完了していることを確認する必要があります。

12.3.1 高可用性データベースの作成

IAMDBを使用していない場合、OAAMデータ格納用に高可用性データベースを作成します。第6.5項「RCUを使用したOracle RAC DatabaseへのIdentity and Access Managementスキーマのロード」に記載されているように、リポジトリ作成ユーティリティを使用して、OAAMデータ・オブジェクトとともにデータベースを事前生成してください。

12.3.2 LDAPにおけるOAAMユーザーとグループの作成

OAAMユーザーとグループを次のように作成します。

次の内容を含む構成ファイルを作成します。

# Common
IDSTORE_HOST: LDAPHOST1.mycompany.com
IDSTORE_PORT: 1389
IDSTORE_ADMIN_PORT: 4444
IDSTORE_BINDDN: cn=oudadmin
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users, dc=mycompany,dc=com
IDSTORE_OAAMADMINUSER: oaamadmin

説明:

- IDSTORE_HOST (LDAP_HOST)およびIDSTORE_PORT (LDAP_PORT)は、それぞれアイデンティティ・ストア・ディレクトリのホストおよびポートです。たとえば、次のとおりです。
OUD: LDAPHOST1と1389

- IDSTORE_ADMIN_PORT (LDAP_DIR_ADMIN_PORT)は、Oracle Unified Directoryインスタンスの管理ポートです。

- IDSTORE_BINDDN (LDAP_ADMIN_USER)は、アイデンティティ・ストア・ディレクトリの管理ユーザーです。

- IDSTORE_GROUPSEARCHBASEは、グループを格納するディレクトリ内の場所です。これは、第7.1項「Identity and Access Managementのデプロイメントのための情報収集」で定義されたREALM_DNと組み合されたcn=Groupsで構成されます(例: cn=Groups,dc=mycompany,dc=com)。

- IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリ内の場所です。これは、第7.1項「Identity and Access Managementのデプロイメントのための情報収集」で定義されたREALM_DNと同じです(例: cn=Users,dc=mycompany,dc=com)。

- IDSTORE_USERNAMEATTRIBUTEは、ユーザーの名前を含むディレクトリ属性の名前です(例: cn)。これはログイン名とは異なります。

- IDSTORE_LOGINATTRIBUTEはユーザーのログイン名を含むLDAP属性です(例: uid)。

- IDSTORE_USERSEARCHBASEは、ユーザーを格納するディレクトリ内の場所です。これは、7.1項「Identity and Access Managementのデプロイメントのための情報収集」で定義されたREALM_DNと組み合されたcn=Usersで構成されます(例: dc=mycompany,dc=com)。

- IDSTORE_OAAMADMINUSER (OAAMADMINUSER)は、Oracle Adaptive Access Managerの管理者として作成するユーザーの名前です。

idmConfigToolを使用してユーザーを作成します。

Identity and Access Managementコンポーネントで必要なユーザーとグループでアイデンティティ・ストアをシードする必要があります。アイデンティティ・ストアにユーザーおよびグループをシードするには、OAMHOST1で次のタスクを実行する必要があります。

1. 環境変数を設定します。

- MW_HOMEをIAD_MW_HOMEに設定します。

- ORACLE_HOMEをIAD_ORACLE_HOMEに設定します。

- JAVA_HOMEをJAVA_HOMEに設定します。

2. IAD_ORACLE_HOME/idmtools/binにあるidmConfigToolコマンドを使用して、アイデンティティ・ストアを構成します。
Linuxの場合、このコマンドの構文は次のとおりです。

idmConfigTool.sh -prepareIDStore mode=OAAM input_file=configfile

configfileは、この項の冒頭で作成した構成ファイルの名前です。

3. このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを入力するように要求されます。
コマンドの実行中に、作成するアカウントにパスワードを指定するように要求されます。全体で共通のパスワードを使用している場合は、簡単に使用できるように、COMMON_IDM_PASSWORDを指定することをお薦めします。

各コマンドを実行した後、ログ・ファイルでエラーまたは警告を確認し、修正します。このツールを実行したディレクトリにautomation.logというファイルが作成されます。

12.4 Oracle Adaptive Access Managerのドメインの拡張

OAMHOST1で次のコマンドを実行して構成ウィザードを起動します。

IAD_MW_HOME/oracle_common/common/bin/config.sh

次のように実行します。

1. 「ようこそ」画面で「既存のWebLogicドメインの拡張」を選択します。「次へ」をクリックします。

2. 「WebLogicドメインの選択」画面で、ナビゲータを使用して管理サーバーのドメイン・ホームを選択します(例: IAD_ASERVER_HOME (IAMAccessDomain))。
「次へ」をクリックします。

3. 「拡張ソースの選択」画面で、次を選択します。

- Oracle Adaptive Access Manager - サーバー

- Oracle Adaptive Access Manager - 管理サーバー

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

4. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。
次を選択します。

- OAAM管理スキーマ

- OAAM Serverスキーマ

- OAAM管理MDSスキーマ

- OWSM MDSスキーマ

「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。

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

5. GridLink RACコンポーネント・スキーマ画面が表示されます。この画面で、次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。Exadata SDP接続の場合は、TCPパラメータを次に入力します。後で、これをSDP接続文字列に変換する必要があります。

- ドライバ: OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

- 「FANの有効化」を選択します。

- 次のいずれかを実行します。

- ONS通知を暗号化するためのSSLが構成されていない場合は、「SSL」の選択を解除します。

- SSLを選択し、適切なWalletおよびWalletのパスワードを指定します。

- サービス・リスナー: 使用するRACデータベースのためのSCANアドレスとポートを入力します。このアドレスは、データベース内のパラメータremote_listenerを問い合せれば識別できます。

SQL>show parameter remote_listener;

NAME            TYPE   VALUE
-------------------------------------------------------------
remote_listener string iamdbscan.mycompany.com:1521

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例: DBHOST1-VIP.mycompany.com (ポート1521)およびDBHOST2-VIP.mycompany.com (ポート1521)、ここでの1521はDB_LSNR_PORTです。

- ONSホスト: Oracle RACデータベースのSCANアドレスおよびデータベースから報告されたONSリモート・ポートを入力します。

srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11g リリース1 (11.1)では、次の例のように、各データベースのONSサービスのホスト名とポートを使用します。

DBHOST1.mycompany.com (port 6200)

および

DBHOST2.mycompany.com (port 6200)

次のRACコンポーネント・スキーマ情報を入力します。

スキーマの名前

サービス名

スキーマの所有者

パスワード

OAAM管理スキーマ

oaamedg.mycompany.com

EDGIAD_OAAM

password

OAAM管理MDSスキーマ

oaamedg.mycompany.com

EDGIAD_MDS

password

OAAM Serverスキーマ

oaamedg.mycompany.com

EDGIAD_OAAM

password

OWSM MDSスキーマ

oamedg.mycompany.com

EDGIAD_MDS

password

6. 「コンポーネント・スキーマのテスト」画面で、構成ウィザードによりデータ・ソースを検証します。データ・ソースの検証が成功した場合、「次へ」をクリックします。失敗した場合、「前へ」をクリックして問題に対処してから、再試行します。

7. 「オプションの構成を選択」画面で、「管理対象サーバー、クラスタ、およびマシン」を選択します。「次へ」をクリックします。

8. 「管理対象サーバーの構成」画面を初めて見る際には、Access Managerなどのすでに構成されているコンポーネントのエントリが表示されています。さらに、ウィザードによりOAAM用の2つの新しい管理対象サーバーが作成されます。

注意:

最初にこの画面を表示すると、構成ウィザードによってデフォルトの管理対象サーバーが作成されています。

このデフォルトの管理対象サーバーに関する詳細を変更して、次の詳細を反映させます。つまり、エントリを1つ変更し、新しいエントリを1つ追加します。

以前のアプリケーション・デプロイメントの一部として構成されている管理対象サーバーの構成は変更しないでください。

デフォルト名

名前

リスニング・アドレス

リスニング・ポート

SSLリスニング・ポート

SSL有効

oaam_server_server1

wls_oaam1脚注 1

OAMHOST1

14300 (OAAM_ADMIN_PORT)脚注 2

14301 (OAAM_ADMIN_SSL_PORT)

選択

wls_oaam2

OAMHOST2

14300 (OAAM_ADMIN_PORT)

14301 (OAAM_ADMIN_SSL_PORT)

選択

oam_admin_server1

wls_oaam_admin1

OAMHOST1

14200 (OAAM_PORT)

14201 (OAAM_SSL_PORT)

選択

wls_oaam_admin2

OAMHOST2

14200 (OAAM_PORT)

14201 (OAAM_SSL_PORT)

選択

脚注 1 自動パッチ適用を行うには、表に一覧された名前を必ず使用してください。

脚注 2 第B.3項を参照してください。

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

9. 「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成し、次の表のoaam_clusterの値を指定します。次に、「追加」をクリックして2つ目のクラスタを作成し、次の表のoaam_admin_clusterの値を指定します。

名前

クラスタ・メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

oaam_cluster

ユニキャスト

n/a

n/a

空白のままにします。

oaam_admin_cluster

ユニキャスト

n/a

n/a

空白のままにします。

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

10. 「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。クラスタ名を右側のペインでクリックします。「サーバー」で管理対象サーバーをクリックしてから矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
次のように、サーバーをクラスタに割り当てます。

クラスタ

サーバー

oaam_cluster

wls_oaam1

wls_oaam2

oaam_admin_cluster

wls_oaam_admin1

wls_oaam_admin2

注意:

以前のアプリケーション・デプロイメントの一部として構成されているクラスタの構成は変更しないでください。

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

11. 「マシンの構成」画面で「次へ」をクリックします。

注意:

デプロイメントによりマシンが作成されます。

12. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- OAMHOST1: wls_oaam1, wls_oaam_admin1

- OAMHOST2: wls_oaam2, wls_oaam_admin2

「次へ」をクリックして、続行します。

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

注意:

次に示す警告が出力された場合:

CFGFWK: Server listen ports in your domain configuration conflict with ports in use by active processes on this host

「OK」をクリックします。

管理対象サーバーが以前のインストールの一部として定義されている場合、この警告が表示されますが、無視してかまいません。

12.5 OAMHOST1上での管理サーバーの再起動

OAMHOST1上でWebLogic管理サーバーを再起動します。第15.1項「コンポーネントの起動と停止」を参照してください。

12.6 ローカル・ストレージへの管理対象サーバーの構成の展開

構成が完了したら、OAMHOST1およびOAMHOST2の管理対象サーバーのディレクトリにOracle Adaptive Access Managerの構成を伝播する必要があります。

最初に共有記憶域の場所からドメインIAMAccessDomainを圧縮して、ローカル記憶域の管理対象サーバーのディレクトリに解凍し、Oracle Adaptive Access Managerを伝播します。

これを行うには、ドメインの圧縮と解凍を実行します。最初にOAMHOST1のIAMAccessDomainでドメインを圧縮し、次にOAMHOST1およびOAMHOST2でそれを解凍します。

次の手順を実行して、管理対象サーバーのドメイン・ディレクトリにドメインを伝播します。

1. OAMHOST1上で、ORACLE_COMMON_HOME/common/bin/からpackユーティリティを起動します。

./pack.sh -domain=IAD_ASERVER_HOME -template=iam_domain.jar  -template_name="IAM Domain" -managed=true

これによってiam_domain.jarというファイルが作成されます。このファイルをOAMHOST2にコピーします。

2. OAMHOST1とOAMHOST2でunpackユーティリティを起動します。このユーティリティもORACLE_COMMON_HOME/common/bin/ディレクトリにあります。

./unpack.sh -domain=IAD_MSERVER_HOME -template=iam_domain.jar -overwrite_domain=true -app_dir=IAD_MSERVER_HOME/applications

次のようなメッセージが表示された場合、無視しても問題ありません。

--------------------------------------------------------
>>  Server listen ports in your domain configuration conflict with ports in use by active processes on this host.
Port 14100 on wls_oam2
----------------------------------------------------------------

12.7 スクリプトを起動および停止するためのOAAMサーバーの追加

デプロイメントでは、ドメインで定義された管理対象サーバーを起動および停止する一連のスクリプトが作成されます。ドメインで新しい管理対象サーバーを作成するごとに、新しく作成された管理対象サーバーもこれらの起動および停止スクリプトで起動できるように、ドメイン構成を更新する必要があります。これを、各OAAM管理対象サーバーに対しても行う必要があります。

ドメイン構成を更新するには、SHARED_CONFIG_DIR/scriptsディレクトリにあるserverInstancesCustom.txtファイルを編集します。

新しいマシンでノード・マネージャを起動する場合には、次のようなエントリを追加します。

newmachine.mycompany.com NM nodemanager_pathname nodemanager_port

次に例を示します。

OAMHOST3.mycompany.com NM /u01/oracle/config/nodemanager/oamhost3.mycompany.com 5556

第12.4項「Oracle Adaptive Access Managerのドメインの拡張」、手順8 (「管理対象サーバーの構成」画面)の表のOAAM管理対象サーバーのそれぞれに対し、次のようなエントリを追加します。

newmachine.mycompany.com OAAM ManagedServerName

次に例を示します。

OAMHOST1 OAAM wls_oaam1 IADADMINVHN 7001
OAMHOST1 OAAM wls_oaam_admin1 IADADMINVHN 7001
OAMHOST2 OAAM wls_oaam2 IADADMINVHN 7001
OAMHOST2 OAAM wls_oaam_admin2 IADADMINVHN 7001

ファイルを保存します。

12.8 OAMHOST1上でのOAAMの起動と検証

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

- 第12.8.1項「OAMHOST1におけるOracle Adaptive Access Managerの起動」

- 12.8.2項「OAMHOST1上でのOAAMの検証」

12.8.1 OAMHOST1におけるOracle Adaptive Access Managerの起動

15.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、IAMAccessDomainのWebLogic管理コンソールを起動します。

ドメイン構造メニューから「環境」→「サーバー」を選択し、「コントロール」をクリックします。

サーバーwls_oaam_admin1およびwls_oaam1を選択し、「起動」をクリックします。

12.8.2 OAMHOST1上でのOAAMの検証

次の場所にあるOAAM管理サーバーに接続することによって実装を検証します。

http://OAMHOST1.mycompany.com:14200/oaam_admin

OAAMサーバー:

http://OAMHOST1.mycompany.com:14300/oaam_server

OAAMサーバーのログイン・ページが表示され、第12.3.2項「LDAPにおけるOAAMユーザーとグループの作成」で作成されたoaamadminアカウントを使用してログインできる場合、この実装は有効です。

12.9 OAMHOST2上でのOAAMの起動と検証

この項では、Oracle Adaptive Access ManagerをOAMHOST2で構成する方法について説明します。

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

- 第12.9.1項「OAMHOST2におけるOracle Adaptive Access Managerの起動」

- 12.9.2項「OAMHOST2上でのOAAMの検証」

12.9.1 OAMHOST2におけるOracle Adaptive Access Managerの起動

第15.1項「コンポーネントの起動と停止」のWebLogic管理対象サーバーwls_oaam2およびwls_oaam_admin2用の起動手順に従って、OAMHOST2のOracle Adaptive Access Managerを起動します。

12.9.2 OAMHOST2上でのOAAMの検証

http://OAMHOST2.mycompany.com:14200/oaam_adminでOAAM管理サーバーに接続することで、実装を検証します。OAAM管理コンソールのログイン・ページが表示され、第12.3.2項「LDAPにおけるOAAMユーザーとグループの作成」で作成されたoaamadminアカウントを使用してログインできる場合、この実装は有効です。

http://OAMHOST2.mycompany.com:14300/oaam_serverでOAAMサーバーに接続することで、実装を検証します。OAAMサーバーのログイン・ページが表示されると、実装は有効です。

12.10 Web層と連携するためのOAAMの構成

この項では、Oracle Adaptive Access Managerを構成してOracle HTTP Serverと連携する方法について説明します。

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

- 12.10.1項「Oracle HTTP Serverからのアクセスの構成」

- 第12.10.2項「WebLogicにおけるホスト・アサーションの変更」

- 第12.11項「Oracle Adaptive Access Managerシード・データのロード」

- 第12.10.3項「Oracle Adaptive Access Managerの検証」

12.10.1 Oracle HTTP Serverからのアクセスの構成

WEBHOST1およびWEBHOST2上の次のファイルを更新して、OAAMをWeb層構成に含める必要があります。

12.10.1.1 IADADMIN.mycompany.comの更新

次のものをWEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconf/idmadmin_vh.confに追加します。

######################################################
## Entries Required by Oracle Adaptive Access Manager
######################################################

# OAAM Console
<Location /oaam_admin>
SetHandler weblogic-handler
WebLogicCluster OAMHOST1.mycompany.com:14200,OAMHOST2.mycompany.com:14200
</Location>

12.10.1.2 sso.mycompany.comの更新

次のものをWEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconf/sso_vh.confに追加します。

######################################################
## Entries Required by Oracle Adaptive Access Manager
######################################################

<Location /oaam_server>
SetHandler weblogic-handler
WebLogicCluster OAMHOST1.mycompany.com:14300,OAMHOST2.mycompany.com:14300
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

12.10.1.3 Oracle HTTP ServerおよびOAAM管理対象サーバーの再起動

第15.1項「コンポーネントの起動と停止」の説明に従って、WEBHOST1およびWEBHOST2上のOracle HTTP Serverを再起動します。

第15.1項「コンポーネントの起動と停止」の説明に従って、管理対象サーバーwls_oaam1、wls_oaam2、wls_oaam_admin1およびwls_oaam_admin2を再起動します。

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

Oracle HTTP Serverは、WebLogicのプロキシとして機能するため、デフォルトでは、特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。

これを行うには、第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用して、IAMAccessDomainのWebLogic管理コンソールにログインします。

次のように実行します。

1. 「クラスタ」をホーム・ページで選択するか、「ドメイン」構造メニューで「環境」→「クラスタ」を選択します。

2. 「チェンジ・センター」ウィンドウの「ロックして編集」をクリックして、編集を有効にします。

3. クラスタ名(oaam_cluster)をクリックします。

4. 「HTTP」を選択し、(第7.1項「Identity and Access Managementのデプロイメントのための情報収集」より)次の値を入力します。

- フロントエンド・ホスト: sso.mycompany.com (IAM_LOGIN_URI)

- フロントエンドHTTPポート: 80 (HTTP_PORT)

- フロントエンドHTTPSポート: 443 (HTTP_SSL_PORT)

これによって、WebLogicで作成されたHTTPS URLが、ロード・バランサでポート443に転送されるようになります。

5. 「保存」をクリックします。

6. 「クラスタ」をホーム・ページで選択するか、「ドメイン」構造メニューで「環境」→「クラスタ」を選択します。

7. クラスタ名(oaam_admin_cluster)をクリックします。

8. 「HTTP」を選択し、(第7.1項「Identity and Access Managementのデプロイメントのための情報収集」より)次の値を入力します。

- フロントエンド・ホスト: IADADMIN.mycompany.com (IAD_DOMAIN_ADMIN_LBRVHN)

- フロントエンドHTTPポート: 80 (HTTP_PORT)

9. 「保存」をクリックします。

10. 「チェンジ・センター」ウィンドウの「変更のアクティブ化」をクリックして、編集を有効にします。

12.10.3 Oracle Adaptive Access Managerの検証

13.5.2項「WebLogicコンソールにおけるOAAM管理ユーザーの作成」で作成したoaamadminアカウントを使用して、15.2項「Identity and Access ManagementコンソールのURLについて」に示されたURLにあるOracle Adaptive Access Management管理コンソールにログインします。

また、oaamadminアカウントとtestパスワードを使用して、https://sso.mycompany.com/oaam_serverのOracle Adaptive Access Managerサーバーにログインします。

次のURLをアクセスできることを確認します。

https://sso.mycompany.com:443/oaam_server/oamLoginPage.jsp

12.11 Oracle Adaptive Access Managerシード・データのロード

この項では、シード・データをOracle Adaptive Access Managerにロードする方法について説明します。

注意:

OAMHOST1から(ブラウザを実行している)ローカル・マシンにファイルをコピーするか、この手順をOAMHOST1で起動したブラウザから実行します。

1. 15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle Adaptive Access Management管理コンソールにログインします。
第12.3.2項「LDAPにおけるOAAMユーザーとグループの作成」で作成したoaamadminアカウントを使用して接続します。

2. 「ナビゲーション」→「環境」メニューにあるシステムのスナップショットをクリックします。
「開く」をクリックします。

3. 「ファイルからロード」をクリックします。

4. 次の情報を入力します。

- 名前: Default Snapshot

- ノート: Default Snapshot

現在のシステムを今すぐにバックアップを選択します。

「続行」をクリックします。

5. 「OK」をクリックして、バックアップの作成を確認します。

6. 「ファイルの選択」をクリックします。

7. 次の場所にあるファイル「oaam_base_snapshot.zip」を選択します。
IAD_ORACLE_HOME/oaam/init

8. 「ロード」をクリックします。
スナップショットのファイルが正常にロードされたことを通知するメッセージが表示されます。「OK」をクリックして、このメッセージを確認します。

9. 右上近くの「リストア」をクリックします。

10. ロードが完了するとメッセージが表示されます。「OK」をクリックします。

12.12 Oracle Adaptive Access ManagerとOracle Access Management Access Managerの統合

この項では、OAAMとAccess ManagerおよびOracle Identity Managerの統合方法について説明します。OAAMがAccess Managerと統合されると、標準のAccess ManagerログインではなくOAAMを使用して、リソースへのアクセスを検証できます。OAAMは認証を実行しますが、それはAccess Managerの中のユーザーに対する認証です。

OAAMをOracle Identity Managerと統合すると、ユーザー名やパスワードを忘れたユーザーをOracle Identity Managerを使用して補助できます。

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

- 第12.12.1項「簡易モード用のグローバル・パスフレーズの取得」

- 第12.12.2項「サード・パーティ・アプリケーションとしてのOAAMの登録」

- 12.12.3項「検証」

- 第12.12.4項「Access ManagerのOAAMプロパティの設定」

- 12.12.5項「テスト・リソースの作成」

- 12.12.6項「Oracle Adaptive Access Managerの検証」

- 第12.12.7項「TAPリソースのLDAPポリシーへの移動」

12.12.1 簡易モード用のグローバル・パスフレーズの取得

Access Managerは「簡易」モード通信用のランダムなグローバル・パスフレーズを、インストール中に生成します。次の手順では、このパスフレーズの取得方法について説明します。これはこの章の後半で必要になります。

簡易モードの通信用にランダムなグローバル・パスフレーズを取得するには、OAMHOST1でIAM_ORACLE_HOME/common/binにあるWebLogic Scripting Toolを起動します。wlstシェルで、接続のコマンドを入力します。

./wlst.sh
wls:/offline> connect()

次のようにプロンプトに応答します。

Please enter your username [weblogic] : weblogic
Please enter your password [weblogic] : COMMON_IDM_PASSWORD
Please enter your server URL [t3://localhost:7001] : t3://IADADMINVHN:7001
wls:/IAMAccessDomain/serverConfig>

次のコマンドを入力して、場所を読取り専用のdomainRuntimeツリーに変更します。ヘルプを表示するにはhelp(domainRuntime)を使用します。

wls:/IAMAccessDomain/domainRuntime>domainRuntime()

次のコマンドを入力して、グローバル・パスフレーズを表示します。

wls:/IAMAccessDomain/domainRuntime> displaySimpleModeGlobalPassphrase()

このパスフレーズをメモして、exitコマンドを使用してwlstを終了します。

wls:/IAMAccessDomain/domainRuntime> exit()

12.12.2 サード・パーティ・アプリケーションとしてのOAAMの登録

Access Managerを簡易セキュリティ・トランスポート・プロトコルを使用するように構成した場合は、OAAMをサード・パーティ・アプリケーションとして登録する必要があります。

OAAMをサード・パーティ・アプリケーションとして登録する手順:

1. OAAMキーストアを保持するディレクトリを作成します。このディレクトリをIAD_ASERVER_HOMEに配置すると、すべてのOAAMホストがこれを使用できるようになります。

mkdir -p IAD_ASERVER_HOME/keystores

2. OAMHOST1で、IAD_ORACLE_HOME/common/binディレクトリからWLSTシェルを起動します。たとえば、Linuxで次のように入力します。

./wlst.sh

3. 次のwlst connectコマンドを使用して、WebLogic管理サーバーに接続します。

connect('AdminUser',"AdminUserPassword",t3://hostname:port')

次に例を示します。

connect("weblogic","admin_password","t3://IADADMINVHN.mycompany.com:7001")

4. registerThirdPartyTAPPartnerコマンドを次のように実行します。

registerThirdPartyTAPPartner(partnerName = "partnerName", keystoreLocation= "path to keystore" , password="keystore password", tapTokenVersion="v2.0", tapScheme="TAPScheme", tapRedirectUrl="OAAM login URL")

次に例を示します。

registerThirdPartyTAPPartner(partnerName = "OAAMTAPPartner", keystoreLocation= "IAD_ASERVER_HOME/keystores/oaam_keystore.jks" , password="password", tapTokenVersion="v2.0", tapScheme="TAPScheme", tapRedirectUrl="https://sso.mycompany.com/oaam_server/oamLoginPage.jsp")

説明:

- partnerNameは一意の名前です。Access Managerにパートナが存在する場合は、その構成が上書きされます。

- keystoreLocationは、既存のキー・ストアの場所です。指定したディレクトリ・パスが存在しない場合、エラーが発生します。

- passwordは、キー・ストアを暗号化するために指定されるパスワードです。これは、後で必要になるため覚えておいてください。

- tapTokenVersionは常にv2.0です。

- tapSchemeは更新される認証スキームです。

- tapRedirectUrlはアクセス可能なURLです。そうではない場合、Error! Hyperlink reference not validというメッセージが表示され登録は失敗します。

注意:

不具合のため、tapRedirectURLはHTTP URLにする必要があります。これは後でHTTPSに変更されます。

- tapRedirectUrlは次のとおりです。

https://sso.mycompany.com/oaam_server/oamLoginPage.jsp

5. WLSTを終了します。

exit()

6. 15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用して、Access Management管理コンソールにログインします。

7. 「Access Manager」セクションの「認証スキーム」をクリックします。
「認証スキームの検索」ページが表示されます。

「検索名」ボックスにTAPSchemeと入力し、「検索」をクリックします。

8. 「TAPScheme」をクリックします。

9. 「チャレンジURL」が次のように設定されていることを確認します。
/oaam_server/oamLoginPage.jsp

パラメータTAPPartnerId=OAAMTAPPartnerおよびSERVER_HOST_ALIAS=OAMSERVERは、チャレンジ・パラメータとして、すでにリストされている必要があります。次のチャレンジ・パラメータを追加します。

- MatchLDAPAttribute=uid

- TAPOverrideResource=https://sso.mycompany.com:443/oamTAPAuthenticate

10. 「適用」をクリックします。

11. 第15.1項「コンポーネントの起動と停止」で説明されているようにwls_oaam1およびwls_oaam2を再起動します。

12.12.3 検証

この統合が正常に完了したことを確認するには、OAM Access Testerツールを使用します。

この統合が正常に完了したことを確認する手順:

1. 環境にJAVA_HOMEが設定されていることを確認します。

2. PATHにJAVA_HOME/binを追加します。たとえば、次のように指定します。

export PATH=$JAVA_HOME/bin:$PATH

3. 次のディレクトリに移動します。
IAD_ORACLE_HOME/oam/server/tester

4. 次のコマンドを使用して、ターミナル・ウィンドウでこのテスト・ツールを起動します。

java -jar oamtest.jar

5. 次の値を使用して接続します。

- プライマリOAMホスト: OAMHOST1

- ポート: 5575 (OAM_PROXY_PORT)

- エージェントID: IAMSuiteAgent

- エージェント・パスワード: IAMSuiteAgentプロファイルに割り当てたパスワード。

- モード: AIXプラットフォームには「オープン」を選択します。それ以外には「簡易」を選択します。

- グローバル・パスフレーズ: 簡易モードを選択した場合、第12.12.1項「簡易モード用のグローバル・パスフレーズの取得」で取得したAccess Managerのグローバル・パスフレーズを入力します。

「接続」をクリックします。

6. 保護されたリソースのURIを指定します。

- スキーム: http

- ホスト: IAMSuiteAgent

- ポート: 空白のままにします。

- リソース: /oamTAPAuthenticate

「検証」をクリックします。

7. ユーザーID oamadminとoamadminのパスワードを指定します。
認証をクリックします。認証に成功すれば、統合は正常に完了しています。

OAMHOST2についても同じ検証を実行します。

12.12.4 Access ManagerのOAAMプロパティの設定

oaam_cli.propertiesファイルを編集して、Access ManagerのOAAMプロパティを設定します。

OAMHOST1上でOAAMプロパティを設定する手順:

1. IAD_ORACLE_HOME/oaam/cliを一時的な場所にコピーします。次に例を示します。

cp -r IAD_ORACLE_HOME/oaam/cli /u01/oracle/oaam

2. 次のディレクトリにあるファイルoaam_cli.propertiesを編集します。
/u01/oracle/oaam/conf/bharosa_properties.

ファイル内の次のプロパティ値を設定します。

パラメータ

値

oaam.adminserver.hostname

IADADMINVHN.mycompany.com

oaam.adminserver.port

7001

oaam.adminserver.username

weblogic

oaam.adminserver.password

weblogicユーザーのパスワード

oaam.db.url

OAAMデータベースのDBC URL。形式: jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=IAMDBSCAN) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=oaamedg.mycompany.com)))

oaam.uio.oam.tap.keystoreFile

第12.12.2項「サード・パーティ・アプリケーションとしてのOAAMの登録」で作成されたキーストアの場所。例:

IAD_ASERVER_HOME/keystores/oaam_keystore.jks

oaam.uio.oam.tap.partnername

OAAMTAPPartner

oaam.uio.oam.host

OAMHOST1

oaam.uio.oam.port

Access Managerサーバー・プロキシ・ポートOAM_PROXY_PORT。例: 5575

oaam.uio.oam.webgate_id

IAMSuiteAgent

oaam.uio.oam.secondary.host

OAMHOST2

oaam.uio.oam.secondary.host.port

2番目のAccess ManagerサーバーのAccess Managerサーバー・プロキシ・ポートOAM_PROXY_PORT。例: 5575

oaam.uio.oam.security.mode

これは、使用しているAccess Managerトランスポート・セキュリティ・モードにより異なります。これがAIXビルドの場合値は1 (オープン)になり、それ以外の場合は2 (簡易)になります。

oam.uio.oam.rootcertificate.keystore.filepath

ルート証明書用に生成されたキーストア・ファイルの場所。

IAD_ASERVER_HOME/output/webgate-ssl/oamclient-truststore.jks

これは、セキュリティ・モードが2(簡易)および3(証明書)の場合にのみ必要です。

oam.uio.oam.privatekeycertificate.keystore.filepath

秘密鍵用に生成されたキーストア・ファイルの場所。

IAD_ASERVER_HOME/output/webgate-ssl/oamclient-keystore.jks

これは、セキュリティ・モードが2(簡易)および3(証明書)の場合に必要です。

ファイルを保存します。

3. 次のディレクトリにあるコマンドsetupOAMTapIntegration.shを発行することによって、OAAM CLIツールを実行します。
/u01/oracle/oaam

次のようにします。

ORACLE_MW_HOMEをIAD_MW_HOMEに設定します。

JAVA_HOMEをJAVA_HOMEに設定します。

WLS_HOMEをIAD_MW_HOME/wlserver_10.3に設定します。

APP_SERVER_TYPEをweblogicに設定します。

次のコマンドを実行します。

chmod +x /u01/oracle/oaam/setupOAMTapIntegration.sh
/u01/oracle/oaam/setupOAMTapIntegration.sh /u01/oracle/oaam/conf/bharosa_properties/oaam_cli.properties

コマンドが実行されると、次の情報の入力を求められます。

- OAAM AdminServerユーザー名: weblogic

- OAAM AdminServerパスワード: weblogicアカウントのパスワード

- OAAM DBユーザー名: EDG_OAAM

- OAAM DBパスワード: OAAMデータベース・ユーザーのパスワード。

- CSFに格納されるOAM Webゲートの資格証明: Webゲートのパスワード(COMMON_IDM_PASSWORD)を入力します。

- OAM TAPキー・ストア・ファイルのパスワード: 12.12.2項「サード・パーティ・アプリケーションとしてのOAAMの登録」でサード・パーティ・アプリケーションとしてOAAMを登録したときに割り当てたパスワード(COMMON_IDM_PASSWORD)。

- OAM秘密鍵証明書キー・ストア・ファイルのパスワード: 第12.12.1項「簡易モード用のグローバル・パスフレーズの取得」で取得したAccess Managerのグローバル・パスフレーズ。

- OAMグローバル・パスフレーズ: OAAM簡易セキュリティ・モデルを使用している場合、これは第12.12.1項「簡易モード用のグローバル・パスフレーズの取得」で取得した値となります。

12.12.5 テスト・リソースの作成

この検証を実行するには、まずテスト・リソースを作成します。

WEBHOST1とWEBHOST2で、テスト・ページoaam_sso.htmlを作成します。最も簡単な方法は、WEB_ORACLE_INSTANCE/config/OHS/component/htdocsディレクトリで、次の内容のoaam_sso.htmlファイルを作成する方法です。

<html>
<body>
<center>
<p>
<h2>
OAAM Protected Resource
</h2>
</p>
</center>
</body>
</html>

12.12.5.1 Oracle Adaptive Access Managerポリシーの作成

IAMSuiteアプリケーション・ドメインのOAAM保護リソース用のグループを作成します。

1. 前に作成したoamadminアカウントを使用して、15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLにある、Access Managementコンソールにログインします。

2. 「アプリケーション・ドメイン」をクリックします。

3. 「検索」をクリックします。

4. 「IAMスイート」をクリックします。「IAMスイート・ドメイン」ページが表示されます。

5. 「認証ポリシー」タブをクリックします。

6. 「認証ポリシーの作成」をクリックし、次の情報を入力します。

- 名前: OAAM Protected Resources

- 説明: Resources protected by OAAM

- 認証スキーム: TAPScheme

7. 「適用」をクリックします。

8. 手順1から7を繰り返しますが、「認証ポリシーの作成」をクリックした後、次の値を入力します。

- 名前: LDAP Protected Resource

- 説明: Resources protected by LDAPScheme

- 認証スキーム: LDAPScheme

12.12.5.2 Access Managerでのリソースの作成

保護されるものを作成したので、今度はリソースをAccess Managerで作成してから、前に作成したポリシー・グループのいずれかに割り当てる必要があります。

1. 第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用して、Access Managementコンソールにログインします。

2. 「アプリケーション・ドメイン」をクリックします。

3. 「検索」をクリックします。

4. 「IAMスイート」をクリックします。

5. 「リソース」タブをクリックします。

6. 「新規リソース」をクリックし、次の情報を入力します。

- タイプ: http

- 説明: OAAM Test Page

- ホスト識別子: IAMSuiteAgent

- リソースURL: /oaam_sso.html

- 保護レベル: Protected

- 認証ポリシー: OAAM Protected Resources

- 認可ポリシー: Protected Resource Policy

7. 「適用」をクリックします。

12.12.6 Oracle Adaptive Access Managerの検証

https://sso.mycompany.com:443/oaam_sso.htmlのURLを使用して、保護されているリソースにアクセスします。登録およびチャレンジのため、OAAMにリダイレクトされます。Access Managerログイン・ページのかわりにOAAMログイン・ページが表示されます。oamadminなどの認可されたAccess Managerユーザーを使用してログインします。ログインすると、oaamで保護されているリソースが表示されます。

12.12.7 TAPリソースのLDAPポリシーへの移動

1. 前に作成したoamadminアカウントを使用して、15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLにある、Access Managementコンソールにログインします。

2. 「Access Manager」セクションの「アプリケーション・ドメイン」をクリックします。
「アプリケーション・ドメイン検索」画面が表示されます。

「検索」をクリックします。

「IAMスイート」をクリックし、「IAMスイート・ドメイン」ページを開きます。

「認証ポリシー」サブタブをクリックします。

3. より上位の保護されているポリシーをクリックします。

4. 「リソース」サブタブをクリックします。

5. リソース・ウィンドウで「/oamTAPAuthenticate」をクリックします。

6. 「削除」をクリックします。

7. 「適用」をクリックします。

8. 「Access Manager」セクションの「アプリケーション・ドメイン」をクリックします。
「アプリケーション・ドメイン検索」画面が表示されます。

「検索」をクリックします。

「IAMスイート」をクリックし、「IAMスイート・ドメイン」ページを開きます。

「認証ポリシー」サブタブをクリックします。

9. 「LDAP保護リソース」をクリックします。

10. 「参照」タブの下にあるツールバーの「開く」をクリックします。

11. リソース・ウィンドウで「追加」をクリックします。
「検索」ボックスが表示されたら、次のように入力します。

リソースURL: /oamTAPAuthenticate

「検索」をクリックします。

検索結果から「/oamTAPAuthenticate」をクリックします。

「選択済の追加」をクリックします。

12. リソース「/oamTAPAuthenticate」を選択します。

13. 「適用」をクリックします。

12.13 Oracle Adaptive Access Manager 11gとOracle Identity Manager 11gの統合

OAAMには広範なチャレンジ質問が用意されています。これには次のような機能があります。

- 必要に応じて認証の前後に一連の質問でユーザーにチャレンジします。

- 質問をイメージとして提示し、多様な入力装置により回答を求めます。

- 1つずつ順に質問し、正しい答えが指定された場合のみ次の質問が表示されます。

Oracle Identity Managerにも基本的なチャレンジ質問機能があります。これによりユーザーは、パスワードを忘れた場合に、一連の構成可能な質問に答え、パスワードを再設定できます。OAAMとは異なり、Oracle Identity Managerには豊富なパスワード検証機能も用意されており、これにより、簡単な属性に加えて、所有するアカウントに基づいてポリシーを設定できます。

Identity and Access Managementのデプロイメントでは、単一セットのチャレンジ質問を登録し、単一セットのパスワード・ポリシーを使用することをお薦めします。OAAMをOracle Identity Managerと統合することで、OAAMではチャレンジ質問が処理され、Oracle Identity Managerではパスワードの検証、保管および伝播が処理されます。これによりOAAMの不正防止機能を使用すると同時にパスワード検証にOracle Identity Managerを使用できます。OAAMをOracle Identity Managerと統合すると、ユーザー名やパスワードを忘れたユーザーをOracle Identity Managerを使用して補助できます。

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

- 第12.13.1項「CSFでのOracle Identity Manager暗号化鍵の構成」

- 第12.13.2項「Oracle Identity ManagerとOracle Adaptive Access Manager間のクロス・ドメインの信頼の構成」

- 第12.13.3項「Oracle Identity Manager用のOracle Adaptive Access Managerプロパティの設定」

- 第12.13.4項「OAAMのOracle Identity Managerプロパティの設定」

- 12.13.5項「IAMAccessDomainとIAMGovernanceDomainの再起動」

- 第12.13.6項「OAAMとOracle Identity Managerの統合の検証」

- 第12.13.7項「Oracle Identity ManagerとOAAMの統合の検証」

12.13.1 CSFでのOracle Identity Manager暗号化鍵の構成

1. 第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用して、ドメインIAMAccessDomain用のOracle Enterprise Manager Fusion Middleware Controlに移動します。

2. WebLogic管理者アカウント(たとえば、weblogic_idm)を使用して、ログインします。

3. 左側ペインのナビゲーション・ツリーで「WebLogicドメイン」アイコンを展開します。

4. 「IAMAccessDomain」を選択して右クリックします。メニュー・オプション「セキュリティ」を選択し、サブ・メニューでオプション「資格証明」を選択します。

5. 「oaam」をクリックしてマップを選択します。次に「キーの作成」をクリックします。

6. ポップアップ・ウィンドウで「マップの選択」が「oaam」に設定されていることを確認します。

7. 次を入力します。

- キー名: oim.credentials

- タイプ: Password

- ユーザー名: xelsysadm

- パスワード: xelsysadmアカウントのパスワード、COMMON_IDM_PASSWORD

8. 「OK」をクリックして、秘密鍵を資格証明ストア・フレームワークに保存します。

12.13.2 Oracle Identity ManagerとOracle Adaptive Access Manager間のクロス・ドメインの信頼の構成

Oracle Adaptive Access Managerをデプロイする際に、Oracle Identity ManagerおよびOracle Adaptive Access Managerが別々のドメインにある場合、クロス・ドメインの信頼を構成する必要があります。

IAMAccessDomainドメインでクロス・ドメインの信頼を次のように構成します。

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

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」で「IAMAccessDomain」をクリックし、「セキュリティ」タブを選択します。

4. 「拡張」セクションを展開します。

5. 「クロス・ドメイン・セキュリティの有効化」を選択します。

6. クロス・ドメインの信頼の確認に使用するパスワードを選択し、それを「資格証明と資格証明の確認」フィールドに入力します。

7. 「保存」をクリックします。

8. 「変更のアクティブ化」をクリックします。

IAMGovernanceDomainドメインでクロス・ドメインの信頼を次のように構成します。

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

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」で「IAMGovernanceDomain」をクリックし、「セキュリティ」タブを選択します。

4. 「拡張」セクションを展開します。

5. 「クロス・ドメイン・セキュリティの有効化」を選択します。

6. IAMAccessDomainの資格証明フィールドに入力したパスワードを「資格証明と資格証明の確認」フィールドに入力します。

7. 「保存」をクリックします。

8. 「変更のアクティブ化」をクリックします。

12.13.3 Oracle Identity Manager用のOracle Adaptive Access Managerプロパティの設定

第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用して、OAAM管理コンソールに移動します。

第12.3.2項「LDAPにおけるOAAMユーザーとグループの作成」で作成したoaamadminアカウントを使用してログインします。

次のように実行します。

1. ナビゲーション・ツリーで、「環境」見出しの「プロパティ」をクリックしてから、「開く」をクリックします。プロパティ検索ページが表示されます。

2. プロパティ値を設定するには、「名前」フィールドに名前を入力して「検索」をクリックします。現在値が検索結果ウィンドウに表示されます

3. エントリをクリックします。「値」フィールドが表示されます。新しい値を入力し「保存」をクリックします。

4. Oracle Adaptive Access ManagerとOracle Identity Managerの統合のため、次のプロパティを設定します。

- bharosa.uio.default.user.management.provider.classname: com.bharosa.vcrypt.services.OAAMUserMgmtOIM

- bharosa.uio.default.signon.links.enum.selfregistration.url: https://sso.mycompany.com:443/identity/faces/register?&backUrl=https://sso.mycompany.com:443/identity

- bharosa.uio.default.signon.links.enum.trackregistration.enabled: true

- bharosa.uio.default.signon.links.enum.selfregistration.enabled: true

- bharosa.uio.default.signon.links.enum.trackregistration.url: https://sso.mycompany.com:443/identity/faces/trackregistration?&backUrl=https://sso.mycompany.com:443/identity

- oaam.oim.passwordflow.unlockuser: true

- oaam.oim.url: t3://oimhost1vhn.mycompany.com:14000,oimhost2vhn.mycompany.com:14000

12.13.4 OAAMのOracle Identity Managerプロパティの設定

1. 15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle Identity Managerシステム管理コンソールにログインします。

2. 「システム管理」見出しの「システム構成」をクリックします。「システム構成」ウィンドウが開きます。

3. 「システム・プロパティの検索」で「検索」をクリックします。

4. 表示されたプロパティをそれぞれクリックして、「編集」を選択します。次のように各プロパティの値を設定して、「保存」をクリックします。

注意:

プロパティ名が「キーワード」列に表示されます。

- OIM.DisableChallengeQuestions: TRUE

- OIM.ChangePasswordURL: https://sso.mycompany.com:443/oaam_server/oimChangePassword.jsp

- OIM.ChallengeQuestionModificationURL: https://sso.mycompany.com:443/oaam_server/oimResetChallengeQuestions.jsp

12.13.5 IAMAccessDomainとIAMGovernanceDomainの再起動

第15章「コンポーネントの起動と停止」の説明に従い、次の管理サーバーおよび管理対象サーバーを再起動します。

- WebLogic管理サーバー

- wls_oam1およびwls_oam2

- wls_oim1およびwls_oim2

- wls_oaam1およびwls_oaam2

12.13.6 OAAMとOracle Identity Managerの統合の検証

前の説明で作成したテスト・ページ(例: http://sso.mycompany.com/oaam_sso.html)にアクセスします。OAAMログイン・ページが表示されます。「登録」または「登録の追跡」のリンクをクリックします。統合が機能している場合には、OIMに移動します。

12.13.7 Oracle Identity ManagerとOAAMの統合の検証

Oracle Identity ManagerがOAAMと統合されていることを次のように検証します。

Oracle Identity Managerセルフ・サービス・コンソールにxelsysadmユーザーとしてログインします。

チャレンジ質問とOAAM固有のセキュリティ・ポリシーを設定するように求められます。

12.14 Oracle Adaptive Access Managerの保護へのドメインの変更

OAAMでの特定のリソースの保護は、12.12.5.2項「Access Manager.でのリソースの作成」で作成したOAAM保護リソース認可ポリシーを追加すると可能になります。

すべてに対してOAAM認可を使用する手順:

1. 第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用して、Access Managementコンソールにログインします。

2. 「アプリケーション・ドメイン」をクリックします。

3. 「検索」をクリックします。

4. 「IAMスイート」をクリックします。

5. 「認証ポリシー」タブをクリックします。

6. 「保護された上位レベル・ポリシー」ポリシーをクリックします。

7. 「認証スキーム」の値をTAPSchemeに変更します。

8. 「適用」をクリックします。

12.15 アプリケーション層の構成のバックアップ

ベスト・プラクティスとしては、インストールと各層の構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

インストールをこのポイントにバックアップする手順は次のとおりです。

1. 第15.5.3.6項「Web層のバックアップ」の説明に従って、Web層をバックアップします。

2. データベースをバックアップします。これは全データベースのバックアップで、ホット・バックアップかコールド・バックアップになります。お薦めするツールはOracle Recovery Managerです。

3. 15.5.3.4項「WebLogicドメインIAMGovernanceDomainのバックアップ」の説明に従って、管理サーバー・ドメイン・ディレクトリをバックアップします。

4. 第15.5.3.2項「LDAPディレクトリのバックアップ」の説明に従って、ディレクトリをバックアップします。

アプリケーション層の構成をバックアップする方法の詳細は、第15.5項「バックアップとリカバリの実行」を参照してください。

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

サーバー移行を構成すると、SOAおよびOracle Identity Managerで管理されているサーバーをあるホストから別のホストに移行できるようになります。これにより、いずれかのサーバーをホストしているノードに障害が発生しても、他のノードでサービスを継続できます。この章では、Identity and Access Managementのエンタープライズ・デプロイメントでサーバー移行を構成する方法について説明します。

この章で説明する手順は次のとおりです。

- 第13.1項「エンタープライズ・デプロイメント用のサーバー移行の概要」

- 第13.2項「サーバー移行leasing表のユーザーと表領域の設定」

- 第13.3項「Oracle WebLogic管理コンソールを使用したLeasingのGridLinkデータ・ソースの作成」

- 第13.4項「ノード・マネージャのプロパティ・ファイルの編集」

- 第13.5項「wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定」

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

- 第13.7項「サーバー移行のテスト」

- 第13.8項「サーバー移行構成のバックアップ」

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

WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2の各管理対象サーバーのサーバー移行を構成します。管理対象サーバーWLS_OIM1およびWLS_SOA1は、障害発生時にOIMHOST2上で再起動されるように構成されます。管理対象サーバーWLS_OIM2およびWLS_SOA2は、障害発生時にOIMHOST1上で再起動されるように構成されます。WLS_OIM1、WLS_SOA1、WLS_OIM2、およびWLS_SOA2サーバーは、WebLogicサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。

次の項の手順を実行し、WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2の管理対象サーバーのサーバー移行を構成します。

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

この項では、サーバー移行leasing表のためのユーザーと表領域を設定します。

注意:

同一ドメイン内の他のサーバーがサーバー移行用にすでに構成されている場合には、同じ表領域とデータ・ソースを使用できます。その場合、データベースleasing用のデータソースおよびマルチ・データソースを再作成する必要はありませんが、サーバー移行で構成されているクラスタを再度ターゲットに設定する必要があります。

1. leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。

create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. leasingという名前のユーザーを作成し、そのユーザーにleasing表領域を割り当てます。

create user leasing identified by password;
grant create table to leasing;
grant create session to leasing;
alter user leasing default tablespace leasing;
alter user leasing quota unlimited on leasing;

3. leasing.ddlスクリプトを使用してleasing表を作成します。

1. 次のいずれかのディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。

WL_HOME/server/db/oracle/817
WL_HOME/server/db/oracle/920

2. leasingユーザーとしてデータベースに接続します。

3. SQL*Plusでleasing.ddlスクリプトを実行します。

@Copy_Location/leasing.ddl;

4. この時点では、変更はまだコミットされていません。ツールの実行が完了したら、SQL*Plusプロンプトに次のように入力します。

commit;

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

この項では、Oracle WebLogic Server管理コンソールでリース表のGridLinkデータ・ソースを作成します。

GridLinkデータ・ソースを作成する手順は次のとおりです。

1. 第15.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、IAMGovernanceDomainのOracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

- 名前: データ・ソースの論理名を入力します。たとえば、leasingです。

- 「JNDI」: JNDIの名前を入力します。たとえば、jdbc/leasingです。

- データベース・ドライバ: データベース・ドライバには、Oracle Driver (Thin) for GridLink Connections Versions: 11以上を選択します。

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

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名(IGD_SERVICE_NAME)を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。たとえば、OIMEDG.mycompany.comです。

- ホスト名とポート: 使用中のRACデータベースのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。

show parameter remote_listener;

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string      IAMDBSCAN.mycompany.com:1521

注意:

- データベース・ユーザー名: leasing。

- パスワード: たとえば、welcome1などを入力します。

- パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。接続が成功したときに表示される通知の一例を示します。

Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=IAMDBSCAN.mycompany.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=OIMEDG.mycompany.com))) succeeded.

ポート1521はDB_LSNR_PORT、oimedg.mycompany.comはOIM_DB_SERVICE_NAMEです。

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

9. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- ここにも、データベースから報告されたRACデータベースのSCANアドレスおよびONSリモート・ポートを次のように入力し、「追加」をクリックします。

srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

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

注意:

Oracle Database 11g リリース1 (11.1)では、次の例のように、各データベースのONSサービスのホスト名とポートを使用します。

IAMDBHOST1.mycompany.com (port 6200)

および

IAMDBHOST2.mycompany.com (port 6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
接続が成功したときに表示される通知の一例を示します。

Connection test for IAMDBSCAN.mycompany.com:6200 succeeded.

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

11. 「ターゲットの選択」ページで、ターゲットとしてoim_clusterおよびsoa_clusterを選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 「変更のアクティブ化」をクリックします。

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

この項では、ノード・マネージャのプロパティ・ファイルを編集します。この操作は、サーバーが実行されているノード上のノード・マネージャに対して行う必要があります(OIMHOST1およびOIMHOST2)。

nodemanager.propertiesファイルは次のディレクトリにあります。

SHARED_CONFIG_DIR/nodemanager

次のプロパティを追加してサーバー移行が正常に動作するようにします。

- Interface:

Interface=bond0

このプロパティは浮動IPのインタフェース名を指定します。これは、ほとんどのトポロジでbond0になります。外部Oracle HTTPサーバーが使用されている場合、管理対象サーバーはbond1でリスニングしています。この場合、bond1インタフェースをここで使用する必要があります。

- NetMask:

NetMask=255.255.254.0

このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。このネット・マスクは、インタフェースのネット・マスクと同じにする必要があります。

- UseMACBroadcast:

UseMACBroadcast=true

このプロパティは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、言い換えれば、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力は、次のように表示されます。

StateCheckInterval=500
bond0=*,NetMask=255.255.254.0
UseMACBroadcast=true

注意:

サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

1. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

2. WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行し、OIMHOST1とOIMHOST2でノード・マネージャを起動するか、15.1.3.5.1項「ノード・マネージャの起動」で説明されている手順を使用します。

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

Linuxでは、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。

表13-1に一覧表示されているファイルがPATH環境変数に含まれていることを確認します。

表13-1 PATH環境変数に必要なファイル

ファイル

ディレクトリの場所

wlsifconfig.sh

IGD_MSERVER_HOME/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

WL_HOME/common/nodemanager

パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

セキュリティ上の理由から、sudoを、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。

注意:

この手順の実行に適するsudo権限とシステム権限については、システム管理者に問い合せてください。

スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。

パスワードによる制限を設けずにsudo権限をWebLogicユーザー('oracle')に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

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

この項では、サーバー移行ターゲットを構成します。クラスタ移行を構成することにより、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。

クラスタ内の移行を構成する手順は次のとおりです。

1. 第15.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、IAMGovernanceDomainのOracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

3. 表の「名前」列で、移行を構成するクラスタ(oim_cluster)をクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行先として許可するマシン(OIMHOST1およびOIMHOST2)を選択して、右向き矢印をクリックします。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、リース・データ・ソースを選択します。

8. 「保存」をクリックします。

9. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

10. 移行を構成するサーバーを選択します。

11. 「移行」タブをクリックします。

12. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。

13. 「変更のアクティブ化」をクリックします。

14. SOAクラスタについて手順2 - 13を繰り返します。

15. 第15.1項「コンポーネントの起動と停止」の説明に従って、WebLogic管理サーバー、ノード・マネージャ、およびサーバー移行を構成したサーバーを再起動します。

13.7 サーバー移行のテスト

この項では、サーバーの移行が適切に機能していることをテストします。

サーバーの移行を検証するには、15.1.3.5.1項「ノード・マネージャの起動」の説明に従って、コンソール・ウィンドウでノード・マネージャを手動で起動することをお薦めします。

OIMHOST1からテストするには:

1. WLS_OIM1管理対象サーバーを停止します。これには、次のコマンドを実行します。

kill -9 pid

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノードのPIDを識別できます。

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. 仮想ホスト名を使用してOracle Identity Managerコンソールにアクセスします(例: http://OIMHOST1VHN.mycompany.com:14000/identity)。

前述の手順に従い、管理対象サーバーWLS_OIM2、WLS_SOA1およびWLS_SOA2に対してサーバーの移行をテストします。

表13-2は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。

表13-2 管理対象サーバーの移行

管理対象サーバー

移行元

移行先

WLS_OIM1

OIMHOST1

OIMHOST2

WLS_OIM2

OIMHOST2

OIMHOST1

WLS_SOA1

OIMHOST1

OIMHOST2

WLS_SOA2

OIMHOST2

OIMHOST1

WebLogic管理コンソールからの検証

移行は管理コンソールで確認することもできます。

1. 15.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、IAMGovernanceDomainのWebLogic管理コンソールにログインします。

2. 左側のペインでIAMGovernanceDomainをクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルバックするには、Oracle WebLogic管理コンソールから移行される管理対象サーバーを停止し、適切なノード・サーバーが、元々割り当てられていたマシン上の管理対象サーバーを起動することを確認します。

13.8 サーバー移行構成のバックアップ

第15.5.3項「インストール時および構成時のバックアップの実行」の説明に従って、データベースとWebLogicドメインをバックアップします。

14 エンタープライズ・デプロイメントのスケーリング

このガイドで取り上げている参照エンタープライズ・トポロジはスケーラビリティが高くなっています。スケール・アップもスケール・アウトも可能です。この章では、その方法を説明します。

トポロジをスケール・アップするには、すでに1つ以上のコンポーネント・インスタンスを実行しているノードに、新しいコンポーネント・インスタンスを追加します。トポロジをスケール・アウトするには、新しいノードに新しいコンポーネント・インスタンスを追加します。

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

- 第14.1項「トポロジのスケーリング」

- 第14.2項「LDAPディレクトリのスケーリング」

- 第14.3項「Identity and Access Managementアプリケーションのスケーリング」

- 第14.4項「Web層のスケーリング」

- 第14.5項「すべてのコンポーネントのスケーリング後の手順」

14.1 トポロジのスケーリング

このガイドで説明しているOracle Identity and Access Managementトポロジには、ディレクトリ層、アプリケーション層およびWeb層の3つの層があります。このガイドで説明しているOracle Identity and Access Managementトポロジの3つすべての層内のコンポーネントは、スケール・アップまたはスケール・アウトが可能です。

このリリースでは、Identity and Access Managementデプロイメント・ツールを使用してコンポーネントをスケール・アウトまたはスケール・アップすることはできません。この章で説明するように、スケール・アップまたはスケール・アウトは手動の処理になります。

トポロジのスケールアップは、すでに1つ以上のサーバー・インスタンスが実行しているノードに、新しいサーバー・インスタンスを追加して実行します。トポロジのスケール・アウトは、新しいノードに新しいコンポーネントを追加して実行します。

14.2 LDAPディレクトリのスケーリング

LDAPディレクトリは次のようにスケーリングします。

14.2.1 スケール・アウト時のMiddlewareホームのマウント

OracleバイナリはLDAPホスト間で共有されます。スケール・アウト時、新しいホストに共有バイナリ・ディレクトリをマウントする必要があります。これを行うには、第5.7項「共有記憶域のホストへのマウント」の手順を実行してください。

14.2.2 Oracle Unified Directoryのスケーリング

Oracle Unified DirectoryのバイナリはIDM_TOPにあり、これはLDAPHOST間で共有されています。Oracle Unified Directoryを新しいホストにスケール・アウトする際、このディレクトリが新しいホストにマウントされていることを確認します。第5.7項「共有記憶域のホストへのマウント」を参照してください。

ディレクトリ層には2つのOracle Unified Directoryノード(LDAPHOST1とLDAPHOST2)があり、それぞれでOracle Unified Directoryインスタンスを実行しています。いずれかのノードのOracle Unified Directoryバイナリを使用して、Oracle Unified Directoryの新しいインスタンスを作成できます。

次のようにします。

1. 第14.2.2.1項「Oracle Unified Directoryをスケーリングするための情報収集」に示されるように情報を収集します。

2. スケール・アウトの場合、共有記憶域を新しいLDAPHOSTにマウントします。

3. 第14.2.2.2項「追加のOracle Unified Directoryインスタンスの構成」の手順に従います。

4. 第14.2.2.3項「新しいOracle Unified Directoryインスタンスの検証」の手順に従います。

5. 第14.2.2.4項「新しいOracle Unified Directoryインスタンスのロード・バランサへの追加」の手順に従います。

6. 第14.4.5項「ロード・バランサの再構成」に記載されているように、新しいOracle Unified Directoryインスタンスのホストおよびポートの情報を使用して、ロード・バランサを再構成します。

14.2.2.1 Oracle Unified Directoryをスケーリングするための情報収集

Oracle Unified Directoryをスケーリングする前に次の情報を収集します。

説明

変数

ドキュメント内での値

実際の値

新しいOracle Unified Directoryのホスト名

LDAP_HOST

LDAPHOST3.mycompany.com

Oracle Unified Directoryのリスニング・ポート

LDAP_PORT

1389

Oracle Unified DirectoryのSSLポート

LDAP_SSL_PORT

1636

Oracle Unified Directory管理ポート

LDAP_ADMIN_PORT

4444

Oracle Unified Directoryのレプリケーション・ポート

LDAP_REPLIC_PORT

8989

Oracleインスタンスの場所

OUD_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oudn

Oracle Unified Directoryの既存のインスタンス/コンポーネント名

oudn

oud1

新しく作成されたインスタンス/コンポーネント名

oudn

oud3

Oracle Unified Directoryの管理者パスワード

COMMON_IDM_PASSWORD

共通のパスワード

COMMON_IDM_PASSWORD

14.2.2.2 追加のOracle Unified Directoryインスタンスの構成

別のマシンにスケール・アウトする場合、ポート1389 (LDAP_PORT)、1636 (LDAP_SSL_PORT)、4444 (LDAP_ADMIN_PORT)および8989を使用できます。スケール・アップする場合には、これらのポートはすでに使用されており、一意のポートを選択する必要があります。使用しているオペレーティング・システムに対して次のコマンドを発行して、使用を計画しているポートがコンピュータ上の他のサービスに使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても出力は何も返されません。

netstat -an | grep "1389"

ポートが使用されている(コマンドからどちらかのポートを識別する出力が返された)場合は、ポートを解放する必要があります。

解放したポートのエントリを/etc/servicesファイルから削除し、サービスを再起動するか、コンピュータを再起動します。

環境変数JAVA_HOMEを設定します

環境変数INSTANCE_NAMEを../../../../u02/private/oracle/config/instances/oud3などの新しいインスタンス値に設定します。

ツールはインスタンス・ホームをOUD_ORACLE_HOMEを基準にして作成するため、前のディレクトリを含めてOUD_ORACLE_INSTANCEで作成したインスタンスを取得する必要があります。

ディレクトリをOUD_ORACLE_HOMEに変更します

次のコマンドを実行してOracle Unified Directory構成アシスタントを起動します。

./oud-setup

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

2. 「サーバー設定」画面で、次を入力します。

- ホスト名: Oracle Unified Directoryが実行されているホストの名前(たとえばLDAPHOST3)

- LDAPリスナー・ポート: スケール・アウトの場合1389 (LDAP_PORT)、スケール・アップの場合一意のポート。

- 管理コネクタ・ポート: 4444 (LDAP_ADMIN_PORT)

- LDAPセキュア・アクセス

- 「構成」をクリックします

- 「SSLアクセス」を選択します

- ポートでSSLを有効化: 1636 (LDAP_SSL_PORT)

- 証明書: 自己署名証明書を生成するまたは独自の証明書の詳細を提供します。

- 「OK」をクリックします。

- ルート・ユーザーDN: 管理ユーザーを入力します(たとえば、cn=oudadmin)

- パスワード: ouadminユーザーに割り当てるパスワードを入力します。COMMON_IDM_PASSWORDを使用することをお薦めします。

- パスワード(確認): パスワードを再入力します。

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

3. トポロジ・オプション画面で、次を入力します。

- このサーバーは、レプリケーション・トポロジの一部になります

- レプリケーション・ポート: (LDAP_REPLIC_PORT) 8989

- レプリケーション・トラフィックを暗号化する場合には、「セキュアとして構成する」を選択します。

- トポロジにはすでにサーバーがあります: 選択済。
次の内容を入力します。

- ホスト名: このインスタンス用のOracle Unified Directoryサーバー・ホストの名前(たとえばLDAPHOST1.mycompany.com)

- 管理者コネクタ・ポート: 4444 (LDAP_ADMIN_PORT)

- 管理ユーザー: LDAPHOST1のOracle Unified Directory管理ユーザーの名前(たとえば、cn=oudadmin)

- 管理者パスワード: 管理者パスワード。COMMON_IDM_PASSWORDを使用することをお薦めします。

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

信頼されていない証明書ダイアログが表示される場合、これは自己署名証明書を使用しているためです。「永久受入れ」をクリックします。

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

4. グローバル管理者の作成画面で、次を入力します。

- グローバル管理者ID: Oracle Unified Directoryレプリケーションを管理するために使用するアカウントの名前(たとえば、oudmanager)

- グローバル管理者パスワード / 確認: このアカウントのパスワードを入力します。COMMON_IDM_PASSWORDを使用することをお薦めします。

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

5. データ・レプリケーション画面で、dc=mycompany,dc=comを選択し、「次へ」をクリックします。

6. Oracleコンポーネントの統合画面で、「次へ」をクリックします。

7. ランタイム・オプション画面で、「次へ」をクリックします。

8. 「確認」画面で、表示された情報が正しいことを確認し、「終了」をクリックします。

9. 「終了」画面で、「閉じる」をクリックします。

14.2.2.3 新しいOracle Unified Directoryインスタンスの検証

構成後、単純検索を実行することによってOracle Unified Directoryが動作することを検証できます。これを実行するには、次のコマンドを発行します。

OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h LDAPHOST3.mycompany.com -p 1389 -D cn=oudadmin -b "" -s base "(objectclass=*)" supportedControl

Oracle Unified Directoryが正常に動作している場合、リストsupportedControlエントリが返されます。

14.2.2.4 新しいOracle Unified Directoryインスタンスのロード・バランサへの追加

新しいOracle Unified Directoryインスタンスを、インスタンス間でリクエストを分散するためにロード・バランサで定義された既存のサーバー・プールに追加します。

14.3 Identity and Access Managementアプリケーションのスケーリング

アプリケーション層にはOracle Access Management Access Manager用の管理対象サーバーを実行する2つのノード(OAMHOST1およびOAMHOST2)と、Oracle Identity Managerの管理対象サーバーを実行する2つのノード(OIMHOST1およびOIMHOST2)があります。オプションで、アプリケーション層にはOracle Adaptive Access Managerの管理対象サーバーを実行する2つのノード(OAMHOST1およびOAMHOST2)がある場合もあります。

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

- 第14.3.1項「情報の収集」

- 第14.3.2項「スケール・アウト時のMiddlewareホームのマウントと新しいマシンの作成」

- 第14.3.3項「スケール・アウト時の新しいノード・マネージャの作成」

- 第14.3.4項「圧縮/解凍の実行」

- 第14.3.5項「アプリケーション固有の手順の実行」

- 第14.3.6項「Oracle HTTP Server構成ファイルへの新しいWebLogic管理対象サーバーの追加」

14.3.1 情報の収集

次の表を使用して、必要な値を収集します。

14.3.1.1 Access Managerのスケーリングのための情報収集

Access Managerをスケーリングする前に次の情報を収集します。

説明

変数

ドキュメント内での値

実際の値

ホスト名

NEWHOSTn

既存のAccess Managerサーバー

WLS_OAM1

新しいAccess Managerのサーバー名

WLS_OAMn

WLS_OAM3

サーバー・リスニング・ポート

OAM_PORT

14100

WebLogic管理ホスト

WLS_ADMIN_HOST

IADADMINVHN.mycompany.com

WebLogic管理ポート

IAD_WLS_PORT

7001

WebLogic管理ユーザー

weblogic_idm

WebLogic管理パスワード

14.3.1.2 Oracle Identity Managerのスケーリングのための情報収集

説明

変数

ドキュメント内での値

実際の値

ホスト名

NEWHOSTn

SOAの仮想サーバー名

SOAHOSTxVHN

Oracle Identity Managerの仮想サーバー名

OIMHOSTxVHN

クローニングする既存のSOA管理対象サーバー

WLS_SOAn

WLS_SOA1

クローニングする既存のOracle Identity Manager管理対象サーバー

WLS_OIMn

WLS_OIM1

新しいSOA管理対象サーバー名

WLS_SOAn

WLS_SOA3

新しいOracle Identity Manager管理対象サーバー名

WLS_OIMn

WLS_OIM3

新しいJMSサーバー用の数値拡張

n

3

WebLogic管理ホスト

WLS_ADMIN_HOST

IGDADMINVHN.mycompany.com

WebLogic管理ポート

WLS_ADMIN_PORT

7101

WebLogic管理ユーザー

weblogic_idm

WebLogic管理パスワード

14.3.1.3 Oracle Adaptive Access Managerのスケーリングのための情報収集

Oracle Adaptive Access Managerをスケーリングする前に次の情報を収集します。

説明

変数

ドキュメント内での値

実際の値

ホスト名

NEWHOSTn

既存のOAAMサーバー

WLS_OAAM1

新しいOAAMのサーバー名

WLS_OAAMn

WLS_OAAM3

サーバー・リスニング・アドレス

OAAM管理対象サーバーのポート

OAAM_PORT

14200

OAAM管理サーバーのポート

OAAM_ADMIN_PORT

14300

WebLogic管理ホスト

WLS_ADMIN_HOST

IADADMINVHN.mycompany.com脚注 1

WebLogic管理ポート

WLS_ADMIN_PORT

7001

WebLogic管理ユーザー

weblogic_idm

WebLogic管理パスワード

脚注 1 これはスケーリングするドメインのことです。

14.3.2 スケール・アウト時のMiddlewareホームのマウントと新しいマシンの作成

OAMアプリケーション層のコンポーネントをスケール・アウトする前に、Middlewareホームをマウントして、新しいマシンを作成します。

Middlewareホームをマウントして新しいマシンを作成する手順:

1. 新しいノードで、Oracle Fusion Middlewareのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできるようにします。詳細は、第5.7項「共有記憶域のホストへのマウント」を参照してください。

2. 共有記憶域内のIAD_ORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

cd IAD_ORACLE_HOME/oui/bin
./attachHome.sh -jreLoc JAVA_HOME

注意:

この項では、例としてIAD_ORACLE_HOMEを使用します。同じ手順をIGD_ORACLE_HOMEに使用します。

3. Middlewareホーム・リストを更新するには、HOME/bea/beahomelistファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、IAD_MW_HOME/oui/binをこのファイルに追加します。

4. 第15.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、IAMAccessDomainのWebLogic管理コンソールにログインします。

5. 使用する新しいノード用の新しいマシンを作成して、そのマシンを次のようにドメインに追加します。

1. 「ナビゲーション」メニューから「環境」→「マシン」を選択します。

2. 「ロックして編集」をクリックします。

3. 「マシン・サマリー」画面で「新規」をクリックします。

4. 次の情報を入力します。
名前: マシンの名前(NEWHOSTn)

マシンのOS: UNIXを選択します。

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

6. 「ノード・マネージャのプロパティ」ページで、次の情報を入力します。
タイプ: SSL。

リスニング・アドレス: NEWHOSTn.

7. 「終了」をクリックします。

8. 「変更のアクティブ化」をクリックします。

14.3.3 スケール・アウト時の新しいノード・マネージャの作成

新しいホスト上のWebLogic管理対象サーバーを起動および停止するにはノード・マネージャを使用します。新しいホスト用の新しいノード・マネージャを作成するには次の手順を実行します。

1. 新しいノード・マネージャ用の新しいディレクトリを既存のものをコピーして作成します。ディレクトリSHARED_CONFIG/nodemanager/oamhost1.mycompany.comをSHARED_CONFIG/nodemanager/newiamhost.mycompany.comにコピーします。
例:

cp -r $SHARED_CONFIG/nodemanager/oamhost1.mycompany.com $SHARED_CONFIG/nodemanager/newiamhost.mycompany.com

2. ディレクトリを新しく作成したディレクトリに変更します。

cd SHARED_CONFIG/nodemanager/NEWHOST3.mycompany.com

3. nodemanager.propertiesファイルを、OAMHOST1に対するエントリをすべてOAMHOST3に変更するよう編集します。次に例を示します。

DomainsFile=/u01/oracle/config/nodemanager/OAMHOST1.mycompany.com/nodemanager.domain

は次のようになります。

DomainsFile=/u01/oracle/config/nodemanager/NEWHOST3.mycompany.com/nodemanager.domain

4. startNodeManagerWrapper.shファイルを、OAMHOST1に対するエントリをすべてOAMHOST3に変更するよう編集します。たとえば、

NM_HOME=/u01/oracle/config/nodemanager/oamhost1.mycompany.com

は次のようになります。

NM_HOME=/u01/oracle/config/nodemanager/oamhost3.mycompany.com

5. 次のコマンドを実行してノード・マネージャを起動します。

./startNodeManagerWrapper.sh

6. 第14.5.3項「ノード・マネージャ構成の更新」の手順に従ってノード・マネージャ構成を更新し、新しいホスト用の証明書が作成されるようにします。

14.3.4圧縮/解凍の実行

ドメインを新しい管理対象サーバーを含むように拡張するときには常に、ドメイン構成で必要になるものをASERVER_HOMEの場所からMSERVER_HOMEの場所へ抽出する必要があります。これは、スケール・アップおよびスケール・アウトのいずれにも適用されます。これを行うには、次の手順を実行します。

注意:

次の手順は、IAMAccessDomainの圧縮および解凍の例です。

1. 管理サーバーのあるホスト上でドメインを圧縮します(たとえば、OAMHOST1では次のようにします)。

pack.sh -domain=IAD_ASERVER_HOME -template =/templates/managedServer.jar -template_name="template_name" -managed=true

pack.shスクリプトは、ORACLE_COMMON_HOME/common/binにあります。

2. 次のコマンドを使用して、スケール・アウトの場合は新しいホスト上で、スケール・アップの場合は既存のホスト上でドメインを解凍します。

unpack.sh -domain=IAD_MSERVER_HOME -template=/templates/managedServer.jar -app_dir=IAD_MSERVER_HOME/applications

unpack.shスクリプトは、ORACLE_COMMON_HOME/common/binにあります。

3. スケール・アウトする場合、ノード・マネージャを起動して、プロパティ・ファイルを更新します。

1. 第15.1項「コンポーネントの起動と停止」の説明に従い、ノード・マネージャを起動および停止します。

2. ORACLE_COMMON_HOME/common/binにあるスクリプトsetNMProps.shを実行して、ノード・マネージャのプロパティ・ファイルを更新します。たとえば、次のように指定します。

cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

3. 第15.1項「コンポーネントの起動と停止」の説明に従い、ノード・マネージャをもう一度起動します。

14.3.5 アプリケーション固有の手順の実行

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

- 第14.3.5.1項「既存の管理対象サーバーのクローンの作成」

- 第14.3.5.2項「Oracle Access Management Access Managerのスケーリング」

- 第14.3.5.2項「Oracle Access Management Access Managerのスケーリング」

- 第14.3.5.3項「Oracle Identity Managerのスケーリング」

- 第14.3.5.4項「Oracle Adaptive Access Managerの統合の更新」

14.3.5.1 既存の管理対象サーバーのクローンの作成

同じタイプの既存の管理対象サーバーをクローニングして新規管理対象サーバーを作成できます。Access Managerをスケール・アウト/アップするには、wls_oam1をクローニングします。同様に、Identity Managerをスケール・アウト/アップするには、wls_oim1をクローニングします。

次の例はAccess Managerの管理対象サーバーのクローニングの例ですが、手順はすべての製品で同じです。

1. 15.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、クローニングする管理対象サーバーのドメイン用のOracle WebLogic管理コンソールにログインします。この例では、ドメインはIAMAccessDomainです。

2. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開き、「サーバー」を選択します。「サーバーのサマリー」ページが表示されます。

3. 「チェンジ・センター」メニューで「ロックして編集」をクリックします。

4. 拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1)。

5. 「クローンの作成」をクリックします。

6. 次の情報を入力します。

- サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。

- サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
スケール・アウトする場合、デフォルトのポート14100 (表7–1のOAM_PORT)を使用できます。スケール・アップする場合には、一意のポートを選択します。

7. 「OK」をクリックします。

8. 新しく作成したサーバーWLS_OAM3をクリックします。

9. 「マシン」を第14.3.2項「スケール・アウト時のMiddlewareホームのマウントと新しいマシンの作成」で作成したマシンになるように設定します。

10. 「保存」をクリックします。

11. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。Oracle WebLogic管理サーバーとNEWHOST内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名検証を無効にする手順は次のとおりです。

1. Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

12. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

14.3.5.2 Oracle Access Management Access Managerのスケーリング

この項では、Access Manager固有のスケーリング手順について説明します。

注意:

共有記憶域を使用している場合は、その共有記憶域に新しいホストがアクセスできるようにします。

次の各項の手順を実行して、Oracle Access Management Access Managerをスケーリングします。

- 第14.3.5.2.1項「圧縮/解凍の実行」

- 第14.3.5.2.2項「Oracle Access Management Access Managerへの管理対象サーバーの登録」

- 第14.3.5.2.3項「Webゲート・プロファイルの更新」

- 第14.3.5.2.4項「Web層の更新」

14.3.5.2.1 圧縮/解凍の実行

第 15.3.4項「圧縮/解凍の実行」で説明されているようにpackおよびunpackを実行します。

14.3.5.2.2 Oracle Access Management Access Managerへの管理対象サーバーの登録

Oracle Access Management Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをAccess Managerサーバーとして構成する必要があります。これはOracle Access Managementコンソールから行います。次のようにします。

1. 8.9項「ユーザー名およびパスワードの設定」のエントリで特定されたユーザーとして、http://IADADMIN.mycompany.com/oamconsoleにあるAccess Managementコンソールにログインします。

2. 「システム構成」タブをクリックします。

3. 「サーバー・インスタンス」をクリックします。

4. 「アクション」メニューから「作成」を選択します。

5. 次の情報を入力します。

- サーバー名: WLS_OAM3

- ホスト: サーバーを実行するホスト。

- ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポートです。

- OAMプロキシ・ポート: Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。

- プロキシ・サーバーID: AccessServerConfigProxy

- モード: 既存のAccess Managerサーバーと同じモードに設定します。

6. 「コヒーレンス」タブをクリックします。
「ローカル・ポート」をそのホストで一意の値に設定します。

7. 「適用」をクリックします。

8. 第15.1項「コンポーネントの起動と停止」の説明に従い、WebLogic管理サーバーを再起動します。

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

新しく作成したAccess Managerサーバーを使用する可能性のあるすべてのWebゲート・プロファイル(Webgate_IDM、Webgate_IDM_11g、IAMSuiteAgentなど)にそのサーバーを追加します。

たとえば、Webgate_IDMにAccess Managerサーバーを追加するには、http://IADADMIN.mycompany.com/oamconsoleにあるAccess Managementコンソールにアクセスします。

次の手順を実行します。

1. Access Manager管理ユーザーとしてログインします。

2. 「システム構成」タブをクリックします。

3. 「Access Managerの設定」→「SSOエージェント」→「OAMエージェント」を開きます。

4. フォルダを開くアイコンをクリックして「検索」をクリックします。
Webゲート・エージェントWebgate_IDMが表示されます。

5. エージェントWebgate_IDMをクリックします。

6. 「アクション」メニューから「編集」を選択します。

7. 「プライマリ・サーバー」リスト(これがセカンダリ・サーバーである場合は「セカンダリ・サーバー」リスト)で「+」をクリックします。

8. 「サーバー」リストから、新しく作成した管理対象サーバーを選択します。

9. 「接続の最大数」を10に設定します。

10. 「適用」をクリックします。

Webgate_IDM_11g、IAMSuiteAgentおよび使用している可能性のあるその他すべてのWebゲートで、手順5から10を繰り返します。

これで第15.1項「コンポーネントの起動と停止」の手順に従い、新しい管理対象サーバーを起動できるようになります。

14.3.5.2.4 Web層の更新

第14.3.6項「Oracle HTTP Server構成ファイルへの新しいWebLogic管理対象サーバーの追加」で説明されているように、新しく追加された管理対象サーバーのホスト名およびポートをWebLogicClusterパラメータのリストに追加します。

このファイルを保存し、第15.1項「コンポーネントの起動と停止」の説明に従ってOracle HTTP Serverを再起動します。

14.3.5.3 Oracle Identity Managerのスケーリング

Oracle SOA SuiteおよびOracle Identity Managerのコンポーネントを使用して構成された管理対象サーバーを実行するノードがすでにあります。このノードには、Middlewareホーム、SOA Oracleホーム、Oracle Identity Manager Oracleホーム、および既存の管理対象サーバーのドメイン・ディレクトリが含まれています。新しい管理対象サーバーWLS_SOAおよびWLS_OIMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にOracle Identity and Access ManagementまたはOracle SOA Suiteバイナリをインストールする必要はありません。

スケール・アップする場合、既存のノードに管理対象サーバーWLS_SOAおよびWLS_OIMを追加します。

いずれの場合にも、圧縮と解凍を実行する必要があります。

トポロジをスケール・アウトする際は、Oracle Identity ManagerおよびSOAを使用して構成された新しい管理対象サーバーを新しいノードに追加します。まず、新しいノードがWebLogic Server、Oracle Identity ManagerおよびSOAの既存のホーム・ディレクトリにアクセスできることを確認します。圧縮および解凍を実行して、新しいノードでドメイン構成をブートストラップする必要はありません。

トポロジをスケーリングするには、次の各項の手順を実行してください。

- 第14.3.5.3.1項「新しいJMSサーバーの構成」

- 第14.3.5.3.2項「スケール・アウト時の圧縮/解凍の実行」

- 第14.3.5.3.3項「コンポジットのデプロイでのOracle Coherenceの構成」

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

- 第14.3.5.3.5項「Oracle Coherenceによって使用されるホスト名の指定」

- 第14.3.5.3.6項「Oracle Identity Manager構成手順の完了」

14.3.5.3.1 新しいJMSサーバーの構成

新しい管理対象サーバー上に、SOA、Oracle Identity Manager、UMSおよびBPMそれぞれのJMSサーバーを作成します。この操作は次のように実行します。

1. 第15.2項「Identity ManagementコンソールのURLについて」に記載されているように、IAMGovernanceDomainのWebLogic管理サーバーにログインし、「サービス」→「メッセージング」→「JMSサーバー」の順に移動します。

2. 「新規」をクリックします。

3. 「名前」に、BPMJMSServer_auto_3などの値を入力します。

4. 「新規ストアの作成」をクリックします。

5. リストからFileStoreを選択します。

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

7. 「名前」に、BPMJMSFileStore_auto_3などの値を入力します。

8. 次の値を入力します。
ターゲット: 現在作成している新しいサーバー。

ディレクトリ: IGD_ASERVER_HOME/jms/BPMJMSFileStore_auto_3

9. 「OK」をクリックします。

10. 「JMSサーバー」画面に戻り、新しく作成したファイル・ストアをリストから選択します。

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

12. 次の画面で、「ターゲット」を作成しているサーバーに設定します。

13. 「終了」をクリックします。

作成する管理対象サーバーに応じて、次のJMSキューを作成します。

サーバー

JMSサーバー名

ファイル・ストア名

ディレクトリ

ターゲット

WLS_SOAn

BPMJMSServer_auto_n

BPMJMSFileStore_auto_n

IGD_ASERVER_HOME/jms/BPMJMSFileStore_auto_n

WLS_SOAn

WLS_SOAn

SOAJMSServer_auto_n

SOAJMSFileStore_auto_n

IGD_ASERVER_HOME/jms/SOAJMSFileStore_auto_n

WLS_SOAn

WLS_SOAn

UMSJMSServer_auto_n

UMSJMSFileStore_auto_n

IGD_ASERVER_HOME/jms/UMSJMSFileStore_auto_n

WLS_SOAn

WLS_OIMn

JRFWSAsyncJmsServer_auto_n

JRFWSAsyncFileStore_auto_n

IGD_ASERVER_HOME/jms/RFWSAsyncFileStore_auto_n

WLS_OIMn

WLS_OIMn

OIMJMSServer_auto_n

OIMJMSFileStore_auto_n

IGD_ASERVER_HOME/jms/OIMJMSFileStore_auto_n

wls_OIMn

WLS_SOAn

PS6SOAJMSServer_auto_n

PS6SOAJMSFileStore_auto_n

IGD_ASERVER_HOME/jms/PS6SOAJMSFileStore_auto_n

wls_SOAn

次の手順を実行して、新しく作成したJMSキューを既存のJMSモジュールに追加します。

1. 第15.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、IAMGovernanceDomainのWebLogic管理コンソールにログインします。

2. 「サービス」→「メッセージング」→「JMSモジュール」に移動します。

3. SOAJMSModuleなどのJMSモジュールをクリックします。

4. 「サブデプロイメント」タブをクリックします。

5. 表示されたサブ・デプロイメントをクリックします。

注意:

このサブデプロイメント・モジュール名は、JMSServerNameXXXXXXという形式のランダムな名前で、構成ウィザードJMS構成から生成されます。

6. 新しく作成したJMSサーバーを割り当てます(SOAJMSServer_autonなど)。

7. 「保存」をクリックします。

8. これを、次の表に記載されている各JMSモジュールに対して実行します。

JMSモジュール

JMSサーバー

BPMJMSModule

BPMJMSServer_auto_n

JRFWSAsyncJmsModule

JRFWSAsyncJmServer_auto_n

OIMJMSModule

OIMJMSServer_auto_n

SOAJMSModule

SOAJMSServer_auto_n

UMSJMSSystemResource

UMSJMSServe_auto_n

9. 構成のアクティブ化を「チェンジ・センター」メニューでクリックします。

14.3.5.3.2 スケール・アウト時の圧縮/解凍の実行

この項は、スケール・アウトを行う際のみ必要になります。

第14.3.4項「圧縮/解凍の実行」で説明されているようにpackおよびunpackを実行します。

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

コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効にしている場合は、ユニキャストを使用します。

ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。したがって、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加した新しいノードから既存ノードのいずれかを検出するために必要な数のノードを指定するだけでかまいません。この結果、クラスタに追加した新しいノードからクラスタにある他のすべてのノードを検出できます。また、同じシステムで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

注意:

デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。

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

tangosol.coherence.wkanシステム・プロパティを使用してノードを指定します(nは1から9の番号)。最大9つのノードを指定できます。番号は、1から開始します。連続した番号を指定する必要があり、途切れていてはなりません。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(例:SOAHOST3VHN)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します。また、既存のエントリに新しいサーバーを追加する必要もあります。

ヒント:

SOAコンポジットのデプロイメント時の高可用性を保証するためには、十分なノードを指定して、いつでも最低1つのコンポジットが実行されているようにします。

注意:

SOAHOST3VHNは、SOAHOST3でWLS_SOA3がリスニングする仮想IPにマップされる仮想ホスト名です。

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

管理コンソールを使用して、Oracle Coherenceで使用するホスト名を指定します。

Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。

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

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列にハイパーリンクで表示されているサーバーの名前(WLS_SOA1またはWLS_SOA2)をクリックします。選択したサーバーの設定ページが表示されます。

5. 「ロックして編集」をクリックします。

6. 「サーバーの起動」タブをクリックします。

7. 「引数」フィールドで、WLS_SOA1、WLS_SOA2およびWLS_SOA3について次のように入力します。
WLS_SOA1については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN
-Dtangosol.coherence.wka2=SOAHOST2VHN
-Dtangosol.coherence.wka3=SOAHOST3VHN
-Dtangosol.coherence.localhost=SOAHOST1VHN

WLS_SOA2については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN
-Dtangosol.coherence.wka2=SOAHOST2VHN
-Dtangosol.coherence.wka3=SOAHOST3VHN
-Dtangosol.coherence.localhost=SOAHOST2VHN

WLS_SOA3については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN
-Dtangosol.coherence.wka2=SOAHOST2VHN
-Dtangosol.coherence.wka3=SOAHOST3VHN
-Dtangosol.coherence.localhost=SOAHOST3VHN

注意:

異なる-Dパラメータの間には、空白の行を入れないでください。管理コンソールの引数テキスト・フィールドに、このテキストをコピーまたは貼り付けないでください。Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。

注意:

デプロイメントに使用されるCoherenceクラスタは、デフォルトでポート8088を使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。たとえば、次のようにします。

WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN
-Dtangosol.coherence.wka2=SOAHOST2VHN
-Dtangosol.coherence.wka3=SOAHOST3VHN
-Dtangosol.coherence.localhost=SOAHOST1VHN
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
-Dtangosol.coherence.wka3.port=8089

WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN
-Dtangosol.coherence.wka2=SOAHOST2VHN
-Dtangosol.coherence.wka3=SOAHOST3VHN
-Dtangosol.coherence.localhost=SOAHOST2VHN
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
-Dtangosol.coherence.wka3.port=8089

WLS_SOA3(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN
-Dtangosol.coherence.wka2=SOAHOST2VHN
-Dtangosol.coherence.wka3=SOAHOST3VHN
-Dtangosol.coherence.localhost=SOAHOST3VHN
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
-Dtangosol.coherence.wka3.port=8089

Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。

8. 「保存」→「変更のアクティブ化」をクリックします。

注意:

これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります。(これらの変数はサーバーの出力ログに記録されます。)Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。

注意:

マルチキャスト・アドレスとユニキャスト・アドレスは、クラスタ通信においてWebLogic Serverクラスタで使用するアドレスとは異なります。2つのエンティティ(コンポジットの配置先となるグループとWebLogic Serverクラスタ)における通信プロトコルが異なっていても、1つのWebLogic Serverクラスタに属するメンバーにコンポジットが配置されることがSOAで保証されます。

14.3.5.3.6 Oracle Identity Manager構成手順の完了

1. 新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。
WebLogic管理コンソールで、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の下の「ディレクトリ」に、デフォルト永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

2. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。OIMHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間の通信用のサーバー証明書を構成した後で、これを再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。
ホスト名検証を無効にする手順は次のとおりです。

1. Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。

2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

3. WLS_OIMnの各管理対象サーバーでも、手順6a - 6hを繰り返してホスト名検証を無効にします。手順6dでは、表の「名前」列で「WLS_OIMn」を選択します。

4. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

5. 第15.1項「コンポーネントの起動と停止」の説明に従い、WebLogic管理サーバーを再起動します。

6. 管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーを停止します。

2. 新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。

3. 新しく作成した管理対象サーバー(http://vip:port/soa-infra)上のアプリケーションにアクセスします。アプリケーションが機能している必要があります。

7. 新しく作成した管理対象サーバーを、サーバー移行ができるように構成します。第13.6項「サーバー移行ターゲットの構成」の手順に従って、サーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域のインストール内容が使用されているため、このノードではすでにノード・マネージャが使用されているとともに、ネットマスク、インタフェースおよびwlsifconfigスクリプトのスーパーユーザー権限が含まれたサーバー移行向けに構成された環境が使用されています。新しいノードには、すでに新しい管理対象サーバーの浮動IPアドレスが存在します。

8. この新規サーバーのサーバー移行をテストします。新規サーバーの追加先となったノードで、次の手順を実行します。

1. 管理対象サーバーWLS_SOAnを停止します。
このためには、次のコマンドを実行します。

kill -9 pid

このコマンドでは、その管理対象サーバーのプロセスID (PID)を指定します。ノードのPIDを確認するには、次のコマンドを使用します。

ps -ef | grep WLS_SOAn

2. ノード・マネージャのコンソールを確認します。WLS_SOA1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。

4. ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

5. WLS_OIMnに対し、aからdの手順を繰り返します。

14.3.5.4 Oracle Adaptive Access Managerの統合の更新

Oracle Adaptive Access Managerでドメインを拡張し、Oracle Identity ManagerをOracle Adaptive Access Managerと統合している場合、Oracle Adaptive Access Managerを新しいOracle Identity Managerサーバーを認識するように更新する必要があります。詳細は、第12.13.3項「Oracle Identity Manager用のOracle Adaptive Access Managerプロパティの設定」を参照してください。

14.3.6 Oracle HTTP Server構成ファイルへの新しいWebLogic管理対象サーバーの追加

アプリケーション層のコンポーネントのスケーリングでは、通常、新しいWebLogic管理対象サーバーを作成する必要があります。トポロジに新しい管理対象サーバーを追加する場合は、その管理対象サーバーを追加した後で、Oracle HTTP Serverの構成ファイルをすべてのノードで更新し、既存のWebLogicクラスタ・ディレクティブにその新しいサーバーを追加する必要があります。

Web層では、WEB_ORACLE_INSTANCE/config/OHS/componentname/moduleconfに、admin_vh.conf、sso_vh.confおよびidminternal_vh.confなどの構成ファイルがいくつかあります。それぞれに、ロケーション・ブロックのエントリが数多く含まれます。ブロックが2つのサーバー・インスタンスを参照しているときに3つ目を追加する場合、そのブロックを新しいサーバーを使用して更新する必要があります。

たとえば、新しいAccess Managerサーバーを追加する場合は、その新しい管理対象サーバーが含まれるようにsso_vh.confを更新する必要があります。新しいサーバーを、ファイル内のWebLogicClusterディレクティブに追加します。次に例を示します。

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100
</Location>

<Location /oamfed>
SetHandler weblogic-handler
WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100
</Location>

を次のように変更します。

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100,OAMHOST1.mycompany.com:14101
</Location>

<Location /oamfed>
SetHandler weblogic-handler
WebLogicCluster OAMHOST1.mycompany.com:14100,OAMHOST2.mycompany.com:14100,OAMHOST3.mycompany.com:14100
</Location>

構成ファイルを更新したら、第15.1項「コンポーネントの起動と停止」の説明に従ってOracle HTTPサーバーを再起動します。サービスの停止を防止するため、再起動は順次的に行うことをお薦めします。

14.4 Web層のスケーリング

Web層には、Oracle HTTP Serverのインスタンスが実行されている1つのノードがすでにあります。既存のOracle HTTP Serverバイナリを使用して、新しいOracle HTTP Serverインスタンスを作成できます。

Oracle HTTP Serverをスケーリングするには、次の各項の手順を実行します。

- 第14.4.1項「Web層のスケーリング用の情報収集」

- 第14.4.2項「スケール・アウト時のMiddlewareホームのマウントとOracle HTTP Serverファイルのコピー」

- 第14.4.3項「構成ウィザードによるHTTP Serverの構成」

- 第14.4.4項「WebLogic ServerへのOracle HTTP Serverの登録」

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

14.4.1 Web層のスケーリング用の情報収集

Web層をスケーリングする前に次の情報を収集します。

説明

変数

ドキュメント内での値

実際の値

ホスト名

WEBHOST1.mycompany.com

OHSポート

WEB_HTTP_PORT

7777

インスタンス名

webn

web1またはweb2

コンポーネント名

webn

web1またはweb2

WebLogic管理ホスト、IAMAccessDomain

IADADMINVHN

IADADMINVHN.mycompany.com

Access Management WLSサーバー・ポート

IAD_WLS_PORT

7001

WebLogic管理ユーザー

weblogic_idm

WebLogic管理パスワード

14.4.2 スケール・アウト時のMiddlewareホームのマウントとOracle HTTP Serverファイルのコピー

新しいノードで、既存のMiddlewareホームをマウントします。

既存のWeb層構成のORACLE_INSTANCE/config/OHS/component/moduleconf内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。

14.4.3 構成ウィザードによるHTTP Serverの構成

次の手順を実行して、Oracle Web層を構成します。

1. Oracle HTTP Serverが使用するポートを含むファイルを作成します。インストール・メディアのDisk1で、ファイルstage/Response/staticports.iniを探します。これをohs_ports.iniというファイルにコピーします。ohs_ports.iniからOHS PORTとOPMN Local Portを除くすべてのエントリを削除します。OPMN Local Portの値を6700に変更します。スケール・アウトする場合、OHS PORTにデフォルト値7777を使用できます。スケール・アップする場合には、マシン上のインスタンスに対して一意の値を選択する必要があります。

注意:

ファイルのポート名がOHS PORTおよびOPMN Local Portと若干異なる場合、ファイルでこれらの名前を使用します。

2. Oracle Fusion Middleware構成ウィザードの場所にディレクトリを変更します。

cd WEB_ORACLE_HOME/bin

3. 構成ウィザードを起動します。

./config.sh

構成ウィザードに次の情報を入力します。

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

2. 「コンポーネントの構成」画面で「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」が選択されていることを確認します。

Oracle Web Cacheが選択されていないことを確認してください。

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

3. 「WebLogicドメインの指定」画面で、次を入力します。

- ドメイン・ホスト名: IADADMINVHN.mycompany.com

- ドメインのポート番号: 7001、ここで7001は第7.1項「Identity and Access Managementのデプロイメントのための情報収集」のIAD_WLS_PORTです。

- ユーザー名: Weblogic管理ユーザー(たとえば、weblogic)

- パスワード: Weblogic管理ユーザー・アカウントのパスワード

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

4. 「コンポーネントの詳細の指定」画面で、次の値を指定します。
WEBHOSTnに次の値を入力します。ここでnは、新しいホストの番号です(たとえば3など)。

- インスタンス・ホームの場所: WEB_ORACLE_INSTANCE (例: /u02/local/oracle/config/instances/ohs1)

- インスタンス名: webn

- OHSコンポーネント名: webn

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

5. 「ポートの構成」画面で、手順1で作成したohs_ports.iniファイルを使用して、使用するポートを指定します。こうすることによって、自動ポート構成をバイパスできます。

1. 構成ファイルを使用してポートを指定を選択します。

2. 「ファイル名」フィールドでohs_ports.iniを指定します。

3. 「保存」→「次へ」をクリックします。

6. セキュリティ更新の指定画面で、次の値を指定します。

- 電子メール・アドレス: My Oracle Supportアカウント用の電子メール・アドレスです。

- My Oracle Supportパスワード: My Oracle Supportアカウント用のパスワードです。

「セキュリティ・アップデートをMy Oracle Support経由で受け取ります。」を選択します。

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

7. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。
「構成」をクリックします。

「構成」画面で、複数のConfiguration Assistantが起動されます。このプロセスは、時間がかかることがあります。終了したら、「次へ」をクリックします。

「インストール完了」画面で、「終了」をクリックし、選択を確定して終了します。

14.4.4 WebLogic ServerへのOracle HTTP Serverの登録

Oracle Enterprise Manager Fusion Middleware Controlで新しいOracle HTTP Serverを管理および監視できるようにするには、Oracle HTTP ServerをIAMAccessDomainに登録する必要があります。これを行うには、新しいサーバーが実行しているホスト上で次のコマンドを実行して、WebLogic ServerにOracle HTTP Serverを登録する必要があります。

cd WEB_ORACLE_INSTANCE/bin
./opmnctl registerinstance -adminHost IADADMINVHN.mycompany.com \
-adminPort WLS_ADMIN_PORT -adminUsername weblogic

14.4.5 ロード・バランサの再構成

新しいOracle HTTP Serverインスタンスを、HTTPインスタンス間でリクエストを分散するためにロード・バランサで定義された既存のサーバー・プールに追加します。

14.5 すべてのコンポーネントのスケーリング後の手順

次のスケーリング後の手順を実行します。

- 第14.5.1項「トポロジ・ストアの更新」

- 第14.5.2項「起動/停止スクリプトの更新」

- 第14.5.3項「ノード・マネージャ構成の更新」

14.5.1 トポロジ・ストアの更新

デプロイメント中に、デプロイされたトポロジの詳細が含まれるトポロジ・ストアが作成されます。環境にパッチ適用する際、ライフサイクル・ツールは、パッチ計画を作成して実行するためにストアを読み取ります。トポロジをスケール・アウトまたはスケール・アップする場合、デプロイメントへの新しい追加に対応するストアへ新しいエントリを追加する必要があります。

これを行うには、付録C「スケーリングのためのトポロジ・ツール・コマンド」の手順に従います。

14.5.2 起動/停止スクリプトの更新

デプロイメントでは、ドメインで定義された管理対象サーバーを起動および停止する一連のスクリプトが作成されます。ドメインに新しい管理対象サーバーを作成する際には、新しく作成された管理対象サーバーもこれらの起動および停止スクリプトで起動できるように、ドメイン構成を更新する必要があります。

ドメイン構成を更新するには、SHARED_CONFIG/scriptsディレクトリにあるserverInstancesCustom.txtファイルを編集します。

14.5.3 ノード・マネージャ構成の更新

次の各項の説明に従って、ノード・マネージャ構成を更新します。

- 第14.5.3.1項「ノード・マネージャの起動と停止」

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

14.5.3.1 ノード・マネージャの起動と停止

新しいマシンでノード・マネージャを起動する場合には、次のようなエントリを追加します。

newmachine.mycompany.com NM nodemanager_pathname nodemanager_port

たとえば、次のようにします。

OAMHOST3.mycompany.com NM /u01/oracle/config/nodemanager/oamhost3.mycompany.com 5556

WLS_OIM3という管理対象サーバーを起動する場合には、次のようなエントリを追加します。

newmachine.mycompany.com OIM ManagedServerName

たとえば、次のようにします。

OAMHOST3 OIM WLS_OIM3

ファイルを保存します。

新しいノード・マネージャを追加した場合、第14.5.3.2項「エンタープライズ・デプロイメント用のノード・マネージャの設定」に従って、そのノードに対してSSLを有効にする必要があります。

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

この項では、Oracleのベスト・プラクティスの推奨事項に従ってノード・マネージャを構成する方法を説明します。この項の内容は次のとおりです。

- 第14.5.3.2.1項「ノード・マネージャのホスト名検証証明書の有効化」

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

- 第14.5.3.2.3項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」

- 第14.5.3.2.4項「keytoolユーティリティを使用した信頼キーストアの作成」

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

- 第14.5.3.2.6項「カスタム・キーストアを使用するための管理対象WebLogic Serverの構成」

- 第14.5.3.2.7項「管理対象サーバーのホスト名検証設定の変更」

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

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

この項では、ノード・マネージャと管理サーバーとの通信で使用するホスト名検証証明書を設定する方法について説明します。

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

この章で(例として)追加する証明書は、ノード・マネージャが物理ホスト名(HOST.mycompany.com)でリスニングし、WebLogic管理対象サーバーが仮想ホスト名(VIP.mycompany.com)でリスニングする構成に対応します。サーバーが仮想ホスト名を使用している場合は、サーバーを1つのノードから別のノードに移行できることを意味します。したがって、キーストアおよびトラスト・キーストアを保持するディレクトリは、理想としては、フェイルオーバーが発生してもアクセス可能な共有記憶域に配置する必要があります。同じノードまたは別のノードで別のホスト名を使用する場合は、この例の手順を次のように拡張する必要があります。

1. 証明書ストアに必要なホスト名を追加します(必要なホスト名がHOST.mycompany.comおよびVIP.mycompany.comと異なる場合)。

2. アイデンティティ・ストアおよびトラスト・ストアの場所に関する情報を、ノード・マネージャ(ノード・マネージャで別のホスト名を使用する場合)またはサーバー(管理対象サーバーで別のホスト名を使用する場合)で変更します。

次の手順に従って、HOSTに自己署名証明書を作成します。これらの証明書はネットワーク名または別名を使用して作成する必要があります。かわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。次の例では、HOST.mycompany.comとVIP.mycompany.comの証明書を構成します。すなわち、HOSTで物理ホスト名(HOST)と仮想ホスト名(VIP)の両方を使用することを想定しています。また、HOST.mycompany.comはノード・マネージャが使用するアドレスであり、VIP.mycompany.comは管理対象サーバーまたは管理サーバーが使用するアドレスであることも想定しています。これは、管理サーバーとFusion Middlewareコンポーネントをホストするノードや、共存する2つの管理対象サーバーの一方が物理ホスト名をリスニングし、もう一方が仮想ホスト名を使用(移行サーバーを使用するサーバーの場合)するノードで、よく見られる状況です。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して、環境を設定します。Bourneシェルで、次のコマンドを実行します。

cd WL_HOME/server/bin
. ./setWLSEnv.sh

CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

2. 証明書用のユーザー定義ディレクトリを作成します。たとえば、ASERVER_HOMEディレクトリにkeystoresという名前のディレクトリを作成します。証明書はWebLogicドメイン間で共有できることに注意してください。

cd SHARED_CONFIG
mkdir keystores

注意:

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。各種目的(HTTPの起動用のSSL設定など)で使用する証明書には、中央ストアまたは共有ストアを使用することをお薦めします。

3. ディレクトリを今しがた作成したディレクトリに変更します。

cd keystores

4. utils.CerGenツールを使用して、トポロジ内の各物理ホストおよび仮想ホストに対する証明書を作成します。
構文(すべて1行に記述):

java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name
[export | domestic] [Host_Name]

次に例を示します。

java utils.CertGen Key_Passphrase NEWHOST.mycompany.com_cert NEWHOST.mycompany.com_key domestic NEWHOST.mycompany.com

また新しい仮想ホストに対しても証明書を作成します。

java utils.CertGen Key_Passphrase NEWVHN.mycompany.com_cert NEWVHN.mycompany.com_key domestic NEWVHN.mycompany.com

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

新しいホストを追加する際には、次の手順を実行します。

1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreというIDキーストアを新しく作成します。このキーストアの作成場所は、証明書と同じディレクトリ(ASERVER_HOME/keystores)とします。

注意:

アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。

2. 先ほど作成した証明書のそれぞれに対する証明書および秘密鍵を、アイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
構文(すべて1行に記述):

java utils.ImportPrivateKey Keystore_File Keystore_Password
Certificate_Alias_to_Use Private_Key_Passphrase
Certificate_File
Private_Key_File
[Keystore_Type]

例:

java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityNEWHOST Key_Passphrase SHARED_CONFIG/keystores/NEWHOST.mycompany.com_cert.pem SHARED_CONFIG/keystores/NEWHOST.mycompany.com_key.pem

14.5.3.2.4 keytoolユーティリティを使用したトラスト・キーストアの作成

次の手順に従って、各新しいホストに対する新しいキーストアを作成します。

1. 新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアCA証明書を、証明書が存在するディレクトリにコピーします。たとえば、次のようにします。

cp WL_HOME/server/lib/cacerts SHARED_CONFIG/keystores/appTrustKeyStoreNEWHOST.jks

2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは常に変更することをお薦めします。それには、keytoolユーティリティを使用します。構文は次のとおりです。

keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password

たとえば、次のようにします。

keytool -storepasswd -new Key_Passphrase -keystore appTrustKeyStoreNEWHOST.jks -storepass changeit

3. このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用します。これは、WL_HOME/server/libディレクトリにあります。keytoolユーティリティを使用して、このCA証明書をappTrustKeyStoreにインポートする必要があります。構文は次のとおりです。

keytool -import -v -noprompt -trustcacerts -alias Alias_Name
-file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password

たとえば、次のようにします。

keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStoreNEWHOST.jks -storepass Key_Passphrase

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

新しいノード・マネージャを追加したら、それを第14.5.3.2.4項「keytoolユーティリティを使用した信頼キーストアの作成」に記載の新しいカスタム・キーストアを使用するように構成する必要があります。カスタム・キーストアを使用するようにノード・マネージャを構成するには、SHARED_CONFIG/nodemanager/hostnameディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します(ここでhostnameは、ノード・マネージャが実行するホストの名前です)。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity_Keystore
CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password
CustomIdentityAlias=Identity_Keystore_Alias
CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate

たとえば、次のようにします。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=SHARED_CONFIG/keystores/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=Key_Passphrase
CustomIdentityAlias=appIdentityNEWHOST
CustomIdentityPrivateKeyPassPhrase=Key_Passphrase

第15.1項「コンポーネントの起動と停止」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。このファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

14.5.3.2.6 カスタム・キーストアを使用するための管理対象WebLogic Serverの構成

次の手順に従って、WLS_SERVERのIDキーストアとトラスト・キーストアを構成します。

1. 第15.2項「Identity ManagementコンソールのURLについて」で指定されたアドレスで拡張されたドメイン用のOracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

5. IDキーストアとトラスト・キーストアを構成するサーバー名(WLS_SERVER)をクリックします。選択したサーバーの設定ページが表示されます。

6. 「構成」をクリックし、「キーストア」をクリックします。

7. 「キーストア」フィールドで、秘密鍵とデジタル証明書の組合せおよび信頼できるCA証明書の格納と管理のために「カスタムIDとカスタム信頼」メソッドを選択します。

8. 「ID」セクションで、IDキーストアの次の属性を定義します。

- カスタムIDキーストア: IDキーストアへの完全修飾パス。

SHARED_CONFIG/keystores/appIdentityKeyStore.jks

- カスタムIDキーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

- カスタムIDキーストアのパスフレーズ: 第14.5.3.2.4項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

9. 「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。

- カスタム信頼キーストア: トラスト・キーストアへの完全修飾パス。

SHARED_CONFIG/keystores/appTrustKeyStoreNEWHOST.jks

- カスタム信頼キーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

- カスタム信頼キーストアのパスフレーズ: 第14.5.3.2.4項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(New_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

10. 「保存」をクリックします。

11. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

12. 「構成」をクリックし、「SSL」をクリックします。

13. 「ロックして編集」をクリックします。

14. 「秘密鍵の別名」フィールドに、管理対象サーバーでリスニングするホスト名に使用した別名を入力します(例:appIdentityNEWHOST)。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第14.5.3.2.3項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。

15. 「保存」をクリックします。

16. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

17. 第15.1項「コンポーネントの起動と停止」の説明に従って、変更を適用したサーバーを再起動します。

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

前述の手順を実行した後、影響を受ける管理対象サーバーのホスト名検証をBea Hostname Verifierに設定します。これを行うには、IAMAccessDomainおよびIAMGovernanceDomainの両方で次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインします。(コンソールのURLは第15.2項「Identity and Access ManagementコンソールのURLについて」に記載されています。)

2. 「チェンジ・センター」で「ロックして編集」を選択します。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

5. 表の「名前」列で管理対象サーバーを選択します。選択したサーバーの設定ページが表示されます。

6. 「SSL」タブを開きます。

7. ページの「詳細」セクションを開きます。

8. ホスト名検証をBea Hostname Verifierに設定します。

9. 「保存」をクリックします。

10. 「変更のアクティブ化」をクリックします。

14.5.3.2.8 ノード・マネージャの起動

次のコマンドを実行してノード・マネージャを起動します。

cd SHARED_CONFIG/nodemanager/hostname
./startNodeManagerWrapper.sh

注意:

ノード・マネージャの出力にある適切なストアと別名を、そのノード・マネージャで使用していることを確認します。ノード・マネージャの起動時に次の内容が出力されます。

<Loading identity key store:
FileName=ASERVER_HOME/keystores/appIdentityKeyStore.jks, Type=jks, PassPhraseUsed=true>

テスト構成の変更を該当のサーバーに適用して、ノード・マネージャからSSLエラーが報告されることなく、それが正常に完了していれば、ホスト名検証は機能しています。

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

この章では、Identity Management and Accessのトポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップ、トラブルシューティングなどがあります。

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

- 第15.1項「コンポーネントの起動と停止」

- 第15.2項「Identity and Access ManagementコンソールのURLについて」

- 第15.3項「エンタープライズ・デプロイメントの監視」

- 第15.4項「Identity and Access Managementの監査」

- 第15.5項「バックアップとリカバリの実行」

- 第15.6項「エンタープライズ・デプロイメントへのパッチ適用」

- 第15.7項「SQLのタイムアウトの防止」

- 第15.8項「WebLogic管理サーバーの手動フェイルオーバー」

- 第15.9項「起動場所の変更」

- 第15.10項「トラブルシューティング」

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

この項では、Oracleエンタープライズ・デプロイメントの各種コンポーネントを起動、停止および再起動する方法を説明します。

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

- 第15.1.1項「起動順序」

- 第15.1.2項「スクリプトを使用したすべてのサーバーの起動と停止」

15.1.1 起動順序

インフラストラクチャ全体を起動するときは、次の順序で各コンポーネントを起動します(トポロジ内に存在しないコンポーネントは無視してください)。

1. データベース

2. データベース・リスナー

3. LDAPホスト

4. OAMホスト

5. OIMホスト

6. Webホスト

7. Oracle Identity Manager管理対象サーバー

8. アイデンティティ・アクセス・ドメインのWebLogic管理サーバー

9. Oracle Access Management Access Managerサーバー

10. OAAM管理サーバー

11. OAAM管理対象サーバー(OAAMがトポロジの一部の場合)

12. Oracle HTTP Server

15.1.2 スクリプトを使用したすべてのサーバーの起動と停止

環境内のすべてのサーバーを起動および停止するためのスクリプトが、デプロイメント中にSHARED_CONFIG_DIR/config/scriptsディレクトリに作成されています。コマンド行から使用してすべてのIdentity and Access Managementサーバーを起動および停止できるスクリプトが2つあります。残りのスクリプトは内部的に使用され、コマンド行からは実行しません。

注意:

これらのスクリプトは、データベースの起動および停止は行いません。

15.1.2.1 すべてのサーバーの起動

特定のサーバーのコンポーネントすべてを起動するには、デプロイメントで作成されたstartall.shというファイルを使用します。すべてを正しい順序で起動するには、ホスト上で次の順序でコマンドを実行します。

統合トポロジ

- LDAPHOST1

- LDAPHOST2

- IAMHOST1

- IAMHOST2

- WEBHOST1

- WEBHOST2

分散トポロジ

- LDAPHOST1

- LDAPHOST2

- OAMHOST1

- OIMHOST1

- OAMHOST2

- OIMHOST2

- WEBHOST1

- WEBHOST2

単一のホスト上のサービスを起動するには、そのホスト上でコマンドを実行します。

実行中、Weblogicおよびノード・マネージャの管理者パスワードを入力するように要求されます。

スクリプトにより、特定のホストにインストールされているコンポーネントが次の順序で起動されます。何が起動されるかは、スクリプトを実行中のホストにインストールされているものによって異なります。

1. Oracle Unified Directory

2. ノード・マネージャ

3. 管理サーバー

4. SOA管理対象サーバー

5. OIM管理対象サーバー

6. OAM管理対象サーバー

7. Oracle HTTP Server

8. OAAM管理対象サーバー

15.1.2.2 すべてのサーバーの停止

すべてのサーバーを停止するスクリプトはstopall.shです。

すべてのサーバーを起動するために使用するのと逆の順序で、ホスト上でコマンドを実行します。

実行中、Weblogicおよびノード・マネージャの管理者パスワードを入力するように要求されます。

15.1.3 Identity and Access Managementコンポーネントの手動での起動と停止

次の各項での説明に従って、個々のIdentity and Access Managementコンポーネントを起動および停止します。

15.1.3.1 Oracle Unified Directoryの起動と停止

Oracle Unified Directoryは次のように起動および停止します。

15.1.3.1.1 Oracle Unified Directoryの起動

Oracle Unified Directoryを起動するには、次のコマンドを実行します。

OUD_ORACLE_INSTANCE/OUD/bin/start-ds

15.1.3.1.2 Oracle Unified Directoryの停止

Oracle Unified Directoryを停止するには、次のコマンドを実行します。

OUD_ORACLE_INSTANCE/OUD/bin/stop-ds

15.1.3.2 何も実行されていないときのOracle Access Manager管理対象サーバーの起動

通常、Access Managerの管理対象サーバーはWebLogicコンソールを使用して起動します。管理コンソールのシングル・サインオンを有効にした後は、コンソールにアクセスするには1つ以上のAccess Managerサーバーが実行されている必要があります。Access Managerサーバーが実行されていない場合は、WLSTを使用して起動できます。

LinuxまたはUNIXでWLSTを起動するには、次のコマンドを入力します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルが開始されたら、次のコマンドを実行します。

nmConnect('Admin_User','Admin_Password', 'OAMHOST','Port', 'domain_name','IAD_MSERVER_HOME')
nmStart('wls_oam1')

ここで、PortはNMGR_PORT、domain_nameはドメインの名前、Admin_UserおよびAdmin_Passwordはノード・マネージャのユーザー名およびパスワードです。たとえば、次のようになります。

nmConnect('weblogic','password', 'OAMHOST1','5556', 'IAMAccessDomain','IAD_MSERVER_HOME')

Access Manager管理対象サーバーがすでに実行している場合、他のWebLogic管理対象サーバーを起動するのと同じように、WebLogic管理コンソールからAccess Manager管理対象サーバーを起動できます。

15.1.3.3 WebLogic管理サーバーの起動と停止

次の項の説明に従って、WebLogic管理サーバーの起動と停止を行います。

注意:

- Admin_UserとAdmin_Passwordのみを使用して、ノード・マネージャとクライアントとの間の接続を認証します。これらはサーバー管理IDおよびパスワードとは独立しており、IAD_ASERVER_HOME/config/nodemanager/nm_password.propertiesファイルに格納されます。

- IAMAccessDomain管理サーバーを起動する場合、ASERVER_HOMEはIAD_ASERVER_HOMEになります。IAMGovernanceDomain管理サーバーを起動する場合、ASERVER_HOMEはIGD_ASERVER_HOMEになります。

15.1.3.3.1 WebLogic管理サーバーの起動

管理サーバーを起動するために推奨される方法は、WLSTを使用してノード・マネージャに接続することです。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

ここで、ORACLE_COMMON_HOMEは、起動または停止するドメインに関連するMW_HOMEのものです。

アクセス・ドメインで管理サーバーを起動するには、次のコマンドを使用します。

nmConnect('Admin_User','Admin_Password','IADADMINVHN','5556', 'IAMAccessDomain','IAD_ASERVER_HOME')
nmStart('AdminServer')

例:

nmConnect('Admin_User','Admin_Password','IADADMINVHN','5556', 'IAMAccessDomain','/u01/oracle/config/domains/IAMAccessDomain')
nmStart('AdminServer')

次のコマンドを実行して、ガバナンス・ドメインで管理サーバーを起動します。

nmConnect('Admin_User','Admin_Password','IGDADMINVHN','5556', 'IAMGovernanceDomain','IGD_ASERVER_HOME')
nmStart('AdminServer')

例:

nmConnect('weblogic','password', 'IADADMINVHN','5556', 'IAMAccessDomain','IAD_MSERVER_HOME')

または、次のコマンドを使用して管理サーバーを起動することもできます。

ASERVER_HOME/bin/startWebLogic.sh

15.1.3.3.2 WebLogic管理サーバーの停止

管理サーバーを停止するには、第15章「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。

次のように実行します。

1. 「制御」タブをクリックします。

2. 「AdminServer(admin)」を選択します。

3. 「停止」をクリックし、「ただちに強制停止」を選択します。

4. 管理サーバーを停止してよいか確認を求められたら「はい」をクリックします。

15.1.3.4 WebLogic管理対象サーバーの起動と停止

管理対象サーバーは次のように起動および停止します。

15.1.3.4.1 WebLogic管理対象サーバーの起動

管理対象サーバーを起動するには、第15章「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。

次のように実行します。

1. 「制御」タブをクリックします。

2. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

3. wls_oim1などの管理対象サーバーを選択します。

4. 「起動」ボタンをクリックします。

5. サーバーを起動してよいか確認を求められたら、「はい」をクリックします。

15.1.3.4.2 WebLogic管理対象サーバーの停止

管理対象サーバーを停止するには、第15章「Identity and Access ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。その後、次のようにします。

1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

2. 「制御」タブをクリックします。

3. wls_oim1などの管理対象サーバーを選択します。

4. 「停止」ボタンをクリックしてから、「ただちに強制停止」を選択します。

5. サーバーを停止してよいか確認を求められたら、「はい」をクリックします。

15.1.3.5 ノード・マネージャの起動と停止

ノード・マネージャを起動および停止するには、次のようにします。

15.1.3.5.1 ノード・マネージャの起動

起動しようとするノード・マネージャが、管理サーバーを制御するノード・マネージャである場合は、その起動の前に次のコマンドを発行します。

export JAVA_OPTIONS=-DDomainRegistrationEnabled=true

ノード・マネージャを起動するには、次のコマンドを実行します。

cd SHARED_CONFIG_DIR/nodemanager/hostname
./startNodeManagerWrapper.sh

15.1.3.5.2 ノード・マネージャの停止

ノード・マネージャを停止するには、前の項で起動したプロセスを強制終了します。

15.2 Identity and Access ManagementコンソールのURLについて

表15-1は、このガイドの中で使用されている管理コンソールとそのURLの一覧です。

表15-1 コンソールのURL

ドメイン

コンソール

URL

ユーザー名

IAMAccessDomain

WebLogic管理コンソール

http://IADADMIN.mycompany.com/console

weblogic_idm

Enterprise Manager FMWコントロール

http://IADADMIN.mycompany.com/em

weblogic_idm

Access Managementコンソール

http://IADADMIN.mycompany.com/oamconsole

oamadmin

OAAMサーバー

https://SSO.mycompany.com/oaam_server

n/a

OAAM管理コンソール

http://IADADMIN.mycompany.com/oaam_admin

oaamadmin

IAMGovernanceDomain

WebLogic管理コンソール

http://IGDADMIN.mycompany.com/console

weblogic_idm

Enterprise Manager FMWコントロール

http://IGDADMIN.mycompany.com/em

weblogic_idm

Identity Managerシステム管理コンソール

http://IGDADMIN.mycompany.com/sysadmin

xelsysadm

Identity Managerセルフ・サービス・コンソール

https://SSO.mycompany.com/identity

xelsysadm

認可ポリシー・マネージャ

http://IGDADMIN.mycompany.com/apm

oamadmin

15.3 エンタープライズ・デプロイメントの監視

この項では、このマニュアルで説明しているIdentity and Access Managementエンタープライズ・デプロイメントの監視について説明します。

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

- 第15.3.1項「Oracle Unified Directoryの監視」

- 第15.3.2項「WebLogic管理対象サーバーの監視」

15.3.1 Oracle Unified Directoryの監視

次のコマンドを実行することによって、Oracle Unified Directoryのステータスを確認できます。

OUD_ORACLE_INSTANCE/OUD/bin/status

このコマンドは、ローカルで実行されているOracle Unified Directoryのインスタンスにアクセスし、ディレクトリのステータスをレポートします(レプリケーションの有効/無効、LDAPまたはLDAPSの有効/無効など)。

15.3.2 WebLogic管理対象サーバーの監視

Oracle Enterprise Manager Fusion Middleware Controlを使用すると、管理対象サーバーおよび他のFusion Middlewareコンポーネント(Access Manager、Oracle Identity Manager、Oracle Identity Federation、SOAなど)を監視できます。詳細は、「関連ドキュメント」の「はじめに」で一覧表示されている各管理者ガイドを参照してください。

15.4 Identity and Access Managementの監査

Oracle Fusion Middleware監査フレームワークは、Oracle Fusion Middleware 11gで追加された新しいサービスです。これは、ミドルウェア製品ファミリの集中監査フレームワークです。このフレームワークでは、Oracle Platform Security Services (OPSS)やOracle Web Servicesなどのプラットフォーム・コンポーネントに対して監査サービスが提供されます。また、これは、Oracle固有のJavaEEコンポーネントをはじめ、様々なJavaEEアプリケーションのフレームワークとしても機能します。Java EEアプリケーションは、アプリケーション固有の監査イベントを作成できます。ミドルウェアのOracleコンポーネントのうちJavaEE以外のもの、たとえばCやJavaSEのコンポーネントについても、JavaEEアプリケーションと同様、エンドツーエンドのフレームワーク構造を実現します。

図15-1は、Oracle Fusion Middleware監査フレームワーク・アーキテクチャの概要図です。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

図15-1 監査イベント・フロー

Oracle Fusion Middleware監査フレームワークは、次の主要コンポーネントで構成されます。

- 監査API
このAPIは、Oracle Fusion Middleware監査フレームワークと統合される監査対応の任意のコンポーネントのために、監査フレームワークによって提供されます。これらのAPIは、実行中にアプリケーション・コード内で発生している特定イベントに関する必要な情報を監査するためにアプリケーションによってコールします。アプリケーションはこのインタフェースにより、監視対象イベントのコンテキストの提供に必要な、ユーザー名やその他属性などのイベント詳細を指定できます。

- 監査イベントと構成
Oracle Fusion Middleware監査フレームワークでは、アプリケーションの監査イベントに簡単にマッピングできる一連の汎用イベントが提供されます。それらの汎用イベントには、認証などの共通のイベントも含まれています。このフレームワークでは、アプリケーションでアプリケーション固有イベントも定義できます。

これらのイベントの定義と構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成は、Enterprise Manager (UI)およびWLST(コマンド行ツール)で更新できます。

- 監査バスストップ
バスストップは、監査リポジトリに送られる前の監査データを含むローカル・ファイルです。データベース・リポジトリが構成されていない場合には、バスストップ・ファイルをファイル・ベースの監査リポジトリとして使用できます。バスストップ・ファイルは、問い合せて特定の監査イベントを簡単に見つけることができるシンプルなテキスト・ファイルです。DBベースのリポジトリが作成されると、バスストップはコンポーネントと監査リポジトリの間で仲介役を勤めます。ローカル・ファイルは構成された周期で定期的に監査リポジトリにアップロードされます。

- 監査ローダー
名前が示すように、監査ローダーは監査バスストップから監査リポジトリにファイルをロードします。プラットフォームおよびJavaEEアプリケーション監査の場合、監査ローダーはJavaEEコンテナの起動と同時に起動されます。システム・コンポーネントの場合、監査ローダーは定期的に発生するプロセスです。

- 監査リポジトリ
監査リポジトリには、リポジトリ作成ユーティリティ(RCU)によって作成された定義済Oracle Fusion Middleware監査フレームワーク・スキーマが含まれます。一度構成されると、すべての監査ローダーはリポジトリを認識し、それに定期的にデータをアップロードします。監査リポジトリ内の監査データは累積され時間の経過とともに増加します。監査ストアは、他のアプリケーションによって使用される運用データベースではなく、監査専用のスタンドアロン型RDBMSであるのが理想的です。高可用性構成の場合、監査データ・ストアとしてOracle Real Application Cluster (RAC)データベースの使用をお薦めします。

- Oracle Business Intelligence Publisher
監査リポジトリ内のデータは、Oracle Business Intelligence Publisherの定義済レポートにより出力されます。このレポートでは、監査データを様々な条件に基づいてドリルダウンできます。例:

- ユーザー名

- 時間範囲

- アプリケーション・タイプ

- 実行コンテキストID (ECID)

Oracle Fusion Middleware監査フレームワークの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。

Oracle Fusion Middleware監査フレームワーク用にリポジトリを構成する方法の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査の構成と管理」を参照してください。

EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成が含まれていません。監査データをバスストップ・ファイルに生成する機能と監査ローダーの構成は、製品がインストールされた後に使用可能になります。主な留意点は、監査データを保管する監査データベース・リポジトリです。監査データのボリュームと履歴特性により、運用中のストアや他のミドルウェア・コンポーネントによって使用されるストアとは別のデータベースを使用することを強くお薦めします。

15.5 バックアップとリカバリの実行

ほとんどのバックアップでは、UNIXのtarコマンドを使用できます。一般的な使用方法は次のとおりです。

tar -czvpsPf BACKUP_LOCATION/backup_file.tar directories

また、リカバリでもUNIXのtarコマンドを使用できます。一般的な使用方法は次のとおりです。

tar -xzvpsPf BACKUP_LOCATION/backup_file.tar

データベースのバックアップとリカバリでは、データベース・ユーティリティのRMANを使用できます。このコマンドの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

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

- 第15.5.1項「ベースライン・バックアップの実行」

- 第15.5.2項「ランタイム・バックアップの実行」

- 第15.5.3項「インストール時および構成時のバックアップの実行」

15.5.1 ベースライン・バックアップの実行

システムを構築するとき、およびOracleバイナリなどの静的なアーティファクトを更新するためのパッチを適用するときに、ベースライン・バックアップを実行します。

ベースライン・バックアップを実行した後は、ランタイム・バックアップも実行します。

表15-2 Identity and Access Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクト

タイプ

ホスト

場所

層

Oracleホーム(データベース)

Oracle RACデータベースのホスト:

IAMDBHOST1

IAMDBHOST2

ユーザー定義

データベース

Oracle Unified Directoryバイナリ

LDAPHOST1

LDAPHOST2

Middlewareホーム: DIR_MW_HOME

ディレクトリ層

Oracle Access Managementバイナリ

OAMHOST1

OAMHOST2

Middlewareホーム: IAD_MW_HOME

アプリケーション層

Oracle Identity Governanceバイナリ

OIMHOST1

OIMHOST2

Middlewareホーム: IGD_MW_HOME

アプリケーション層

Web層バイナリ

WEBHOST1

WEBHOST2

Middleware Oracleホーム、WEB_ORACLE_HOME:

Web層

インストール関連ファイル

各ホスト

OraInventory:

ORACLE_BASE/oraInventory

/etc/oratab、/etc/oraInst.loc

~/bea/beahomelist (WebLogic Serverがインストールされているホスト上)

対象外

注意:

ロード・バランサの構成もバックアップすることをお薦めします。その方法については、ベンダーのドキュメントを参照してください。

Oracle Fusion Middlewareコンポーネントのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

15.5.2 ランタイム・バックアップの実行

ランタイム・バックアップは継続的に実行します。ランタイム・バックアップには、データベース内のデータ、ドメイン構成情報、LDAPディレクトリ内のアイデンティティ情報など、頻繁に変更される項目の情報が含まれます。

表15-3 Identity and Access Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト

タイプ

ホスト

場所

層

IAMAccessDomainホーム

OAMHOST1

OAMHOST2

管理サーバーおよび共有ファイル: IAD_ASERVER_HOME

管理対象サーバー: IAD_MSERVER_HOME

アプリケーション層

IAMGovernanceDomainホーム

OIMHOST1

OIMHOST2

管理サーバーおよび共有ファイル: IGD_ASERVER_HOME

管理対象サーバー: IGD_MSERVER_HOME

アプリケーション層

Oracle HTTP Server

WEBHOST1

WEBHOST2

WEB_ORACLE_INSTANCE

Web層

Oracle RACデータベース

IAMDBHOST1

IAMDBHOST2

ユーザー定義

ディレクトリ層

Oracle Unified Directory

LDAPHOST1

LDAPHOST2

OUD_ORACLE_INSTANCE

アプリケーション層

15.5.3 インストール時および構成時のバックアップの実行

ベスト・プラクティスとしては、インストールと各層の構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

- 第15.5.3.1項「Middlewareホームのバックアップ」

- 第15.5.3.2項「LDAPディレクトリのバックアップ」

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

- 15.5.3.4項「WebLogicドメインIAMGovernanceDomainのバックアップ」

- 15.5.3.5項「WebLogicドメインIAMAccessDomainのバックアップ」

- 第15.5.3.6項「Web層のバックアップ」

15.5.3.1 Middlewareホームのバックアップ

新しいMiddlewareホームを作成する場合、またはMiddlewareホームにコンポーネントを追加する場合には、必ずMiddlewareホームをバックアップします。このガイドで使用されるMiddlewareホームは、表15-2に示されるOracle Identity ManagementおよびOracle Identity and Access Managementです。

15.5.3.2 LDAPディレクトリのバックアップ

LDAPのデータを更新する操作を実行する場合は、必ずディレクトリ・コンテンツをバックアップします。

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

- 第15.5.3.2.1項「Oracle Unified Directoryのバックアップ」

- 第15.5.3.2.2項「サード・パーティのディレクトリのバックアップ」

15.5.3.2.1 Oracle Unified Directoryのバックアップ

Oracle Unified Directoryをバックアップするには、次の手順を実行します。

1. 第15.1項「コンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryのインスタンスを停止します。

2. 各ホスト上のOUD_ORACLE_INSTANCEディレクトリをバックアップします。

3. 第15.1項「コンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryのインスタンスを再起動します。

15.5.3.2.2 サード・パーティのディレクトリのバックアップ

ディレクトリのバックアップの詳細は、オペレーティング・システムのベンダーのドキュメントを参照してください。

15.5.3.3 データベースのバックアップ

構成にコンポーネントを追加して作成する場合は、必ずIAMDBデータベースをバックアップします。このバックアップは、ドメインの作成またはOracle Access Management Access ManagerまたはOracle Identity Managerなどのコンポーネントの追加後に実行します。

15.5.3.4 WebLogicドメインIAMGovernanceDomainのバックアップ

WebLogicドメインをバックアップするには、次の手順を実行します。

1. 第15.1項「コンポーネントの起動と停止」の説明に従って、ドメインで実行されているWebLogic管理サーバーとすべての管理対象サーバーを停止します。

2. 共有記憶域のIGD_ASERVER_HOMEディレクトリをバックアップします。

3. 各ホストのIGD_MSERVER_HOMEディレクトリをバックアップします。

4. WebLogic管理サーバーおよび管理対象サーバーを再起動します。

15.5.3.5 WebLogicドメインIAMAccessDomainのバックアップ

WebLogicドメインをバックアップするには、次の手順を実行します。

1. 第15.1項「コンポーネントの起動と停止」の説明に従って、ドメインで実行されているWebLogic管理サーバーとすべての管理対象サーバーを停止します。

2. 共有記憶域のIAD_ASERVER_HOMEディレクトリをバックアップします。

3. 各ホストのIAD_MSERVER_HOMEディレクトリをバックアップします。

4. WebLogic管理サーバーおよび管理対象サーバーを再起動します。

15.5.3.6 Web層のバックアップ

Web層をバックアップするには、次の手順を実行します。

15.5.3.6.1 Oracle HTTP Serverのバックアップ

次のように、Oracle HTTP Serverをバックアップします。

1. 第15.1項「コンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを停止します。

2. ローカル記憶域上のWEB_ORACLE_INSTANCEディレクトリをバックアップします。

3. 第15.1項「コンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを起動します。

15.6 エンタープライズ・デプロイメントのパッチ適用

Identity and Access Managementライフサイクル・ツールとともに含まれる自動パッチ適用ソリューションを使用して、エンタープライズ・デプロイメントにパッチを適用することをお薦めします。

次にパッチ適用のプロセスをまとめます。

1. パッチ最上位を作成します。パッチ最上位ディレクトリには、パッチが適用される各製品ごとに分類されたパッチが含まれます。

2. パッチ・マネージャを実行して、パッチ計画を生成します。デプロイメント・トポロジおよび提供されたパッチに基づいて、マネージャがそれらのパッチに適用する最適な計画を作成します。

3. 計画による影響を受けるすべてのホストに対してPatcherを実行します。特定の計画で必要とされる場合、特定のホストで複数回Patcherを実行する必要がある場合があります。各Patcherの実行が完了するごとに、次のPatcherを実行する場所が指示されます。

Patcherを実行する際に、必要に応じてサーバー・インスタンスを停止または起動し、パッチが正しい順序で適用されて依存性が満たされるようにします。

IDMパッチ適用フレームワークの使用方法の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementパッチ適用ガイド』に記載されています。また、このガイドには、必要に応じてOPatchツールを使用して手動でデプロイメントにパッチ適用する説明も記載されています。

15.7 SQLのタイムアウトの防止

ほとんどの本番デプロイメント環境ではファイアウォールが使用されます。データベース接続は複数のファイアウォールにまたがって確立されるため、データベース接続がタイムアウトにならないようにファイアウォールを構成することをお薦めします。Oracle Real Application Cluster (Oracle RAC)については、データベース接続はOracle RAC VIPとデータベース・リスナー・ポートを使用して確立されます。ファイアウォールがこれらの接続をタイムアウトさせないように構成する必要があります。そのような構成が不可能な場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルで、SQLNET.EXPIRE_TIME=nというパラメータを設定します(nは分単位の時間)。この値を、ネットワーク・デバイス(ファイアウォール)の既知のタイムアウト値より小さい値に設定します。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。

15.8 WebLogic管理サーバーの手動フェイルオーバー

この項では、プライマリ・ホストに障害が発生した後に、管理サーバーを新しいホストにフェイルオーバーする方法について説明します。この項の例では、Access Management管理サーバーをOAMHOST1からOAMHOST2にフェイルオーバーする方法を示します。Oracle Identity Manager管理サーバーをフェイルオーバーする場合には、そのドメイン用に適した値に置き換えてください。

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

- 15.8.1項「OAMHOST2への管理サーバーのフェイルオーバー」

- 第15.8.2項「OAMHOST2上での管理サーバーの起動」

- 第15.8.3項「Oracle HTTP Serverを介したOAMHOST2へのアクセスの検証」

- 第15.8.4項「OAMHOST1への管理サーバーのフェイルバック」

15.8.1 OAMHOST2への管理サーバーのフェイルオーバー

あるノードで障害が発生した場合、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをOAMHOST1からOAMHOST2にフェイルオーバーする方法について説明します。

前提事項:

- 管理サーバーがIADADMINVHN.mycompany.comをリスニングし、任意のアドレスをリスニングしないように構成されている。

- 管理サーバーはOAMHOST1からOAMHOST2にフェイルオーバーされ、この2つのノードに次のIPアドレスがある。

- OAMHOST1: 100.200.140.165

- OAMHOST2: 100.200.140.205

- IADADMINVHN: 100.200.140.206
これは、管理サーバーが稼働している仮想IPアドレスで、OAMHOST1とOAMHOST2で使用可能なinterface:index (eth1:2など)に割り当てられています。

- 管理サーバーがOAMHOST1内で実行されるドメイン・ディレクトリは、共有記憶域にあり、OAMHOST2からもマウントされている。

注意:

OAMHOST2内のNMは、この時点ではドメインを制御しません。これは、unpack/nmEnrollがまだOAMHOST2上で実行されていないからです。ただし、AdminServerのフェイルオーバー、およびAdminServer自体の制御に対しては、ノード・マネージャは完全に機能します。

- Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントは、前の章の説明のとおり、OAMHOST2にインストールされている。つまり、OAMHOST1に存在するIAD_ORACLE_HOMEとIAD_MW_HOMEのパスは、OAMHOST2でも使用できます。

次の手順は、管理サーバーを異なるノード(OAMHOST2)にフェイルオーバーする方法を示します。

1. 15.1項「コンポーネントの起動と停止」の説明に従い、OAMHOST1上の管理サーバーを停止します。

2. IPアドレスを2番目のノードに移行します。

1. OAMHOST1で次のコマンドをrootとして実行します(ここでx:yはIADADMINVHN.mycompany.comが使用する現在のインタフェースです)。

/sbin/ifconfig x:y down

例:

/sbin/ifconfig eth0:1 down

2. OAMHOST2で次のコマンドを実行します。

/sbin/ifconfig interface:index IP_Address netmask netmask

例:

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクおよびインタフェースがOAMHOST2の使用可能なネットワーク構成と一致することを確認します。

3. OAMHOST2上でarpingを使用してルーティング表を更新します。例:

/sbin/arping -q -U -c 3 -I eth0 100.200.140.206

15.8.2 OAMHOST2上での管理サーバーの起動

次の手順を実行して、OAMHOST2上でノード・マネージャを起動します。

1. OAMHOST2にまだ管理サーバー・ドメイン・ディレクトリがマウントされていない場合は、これをマウントします。たとえば、次のようにします。

mount /u01/oracle

2. 次のコマンドを使用してノード・マネージャを起動します。

cd WL_HOME/server/bin
./startNodeManager.sh

3. ノード・マネージャ・プロセスを強制終了してノード・マネージャを停止します。

注意:

この時点でのノード・マネージャの起動および停止は、ノード・マネージャを初めて実行するときにのみ必要です。起動および停止により、前もって定義されたテンプレートからプロパティ・ファイルが作成されます。次の手順では、そのプロパティ・ファイルにプロパティを追加します。

4. setNMProps.shスクリプトを実行して、ノード・マネージャを起動する前にStartScriptEnabledプロパティをtrueに設定します。

cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

注意:

クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

5. 第15.1項「コンポーネントの起動と停止」の説明に従い、ノード・マネージャを起動します。

6. OAMHOST2上で管理サーバーを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルで一度、次のコマンドを実行します。

nmConnect('admin','Admin_Password', 'OAMHOST2','5556', 'IAMAccessDomain','/u1/oracle/config/domains/IAMAccessDomain')
nmStart('AdminServer')

7. 次の方法でOAMHOST2上の管理サーバーにアクセスできることをテストします。

1. 次のアドレスを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://IADADMINVHN.mycompany.com/console

2. http://IADADMINVHN.mycompany.com/emで、Oracle Enterprise Managerのコンポーネントのステータスにアクセスし、検証できることを確認します。

15.8.3 Oracle HTTP Serverを介したOAMHOST2へのアクセスの検証

第11.1.1項「接続の確認」と同じ手順を実行します。この目的は、OAMHOST2で稼働中の管理サーバーにアクセスできることを確認することにあります。

15.8.4 OAMHOST1への管理サーバーのフェイルバック

この手順では、管理サーバーをフェイルバックできる(つまり、OAMHOST2上で停止し、OAMHOST1上で実行できる)ことを確認します。これを行うには、次の手順に従って、IADADMINVHNを元のOAMHOST1ノードに移行して戻します。

1. OAMHOST2上で管理サーバーが実行されていないことを確認します。その場合は、WebLogicコンソールから停止するか、またはコマンドstopWeblogic.shをIAD_ASERVER_HOME/binから実行します。

2. OAMHOST2上で、管理サーバー・ドメイン・ディレクトリをアンマウントします。たとえば、次のようにします。

umount /u01/oracle

3. OAMHOST1上で、管理サーバー・ドメイン・ディレクトリをマウントします。たとえば、次のようにします。

mount /u01/oracle

4. OAMHOST2上のIADADMINVHN.mycompany.comの仮想IPアドレスを無効にして、OAMHOST2で次のコマンドをrootとして実行します。

/sbin/ifconfig x:y down

ここで、x:yはIADADMINVHN.mycompany.comが使用する現在のインタフェースです。

5. OAMHOST1で次のコマンドを実行します。

/sbin/ifconfig interface:index 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクおよびインタフェースがOAMHOST1の使用可能なネットワーク構成と一致することを確認します。

6. arpingを使用してルーティング表を更新します。次のコマンドをOAMHOST1から実行します。

/sbin/arping -q -U -c 3 -I interface 100.200.140.206

7. ノード・マネージャがまだOAMHOST1上で起動されていない場合は、第15.1項「コンポーネントの起動と停止」の説明に従って起動します。

8. OAMHOST1で管理サーバーを再起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルが開始されたら、次のコマンドを実行します。

nmConnect(admin,'Admin_Pasword, OAMHOST1,'5556',
'IAMAccessDomain','/u01/oracle/config/domains/IAMAccessDomain'
nmStart('AdminServer')

9. 次のアドレスを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://IADADMINVHN.mycompany.com:7001/console

ここで、7001は第7.1項「Identity and Access Managementのデプロイメントのための情報収集」のWLS_ADMIN_PORTです。

10. 次のアドレスを使用してOracle Enterprise Managerのコンポーネントのステータスにアクセスし、検証できることを確認します。
http://IADADMIN.mycompany.com/em

15.9 起動場所の変更

環境がデプロイされたときに、トポロジのコンポーネントを起動および停止するために起動および停止スクリプトが生成されています。デプロイメント時に、アクセス・ドメイン管理サーバーはOAMHOST1上で起動するように構成されています。これをOAMHOST2上で起動するように永続的に変更するには、次の手順を実行します。

サーバーおよびホストの名前を変更する手順と同じ手順を使用して、ガバナンス・ドメイン管理サーバーをOIMHOST1ではなくOIMHOST2で起動するように変更します。

SHARED_CONFIG_DIR/scriptsディレクトリにあるserverInstancesInfo.txtファイルを編集します。

次のような行を探します。

OAMHOST1.mycompany.com AS AdminServer

OAMHOST1をOAMHOST2に変更し、ファイルを保存します。

15.10 トラブルシューティング

この項では、このマニュアルで説明しているIdentity and Access Managementエンタープライズ・デプロイメントで発生する可能性のある一般的な問題のトラブルシューティング方法を説明します。

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

- 第15.10.1項「Identity and Access Managementのデプロイメントのトラブルシューティング」

- 第15.10.2項「起動/停止スクリプトのトラブルシューティング」

- 第15.10.3項「Oracle Access Management Access Manager 11gのトラブルシューティング」

- 第15.10.4項「Oracle Identity Managerのトラブルシューティング」

- 第15.10.5項「Oracle SOA Suiteのトラブルシューティング」

15.10.1 Identity and Access Managementのデプロイメントのトラブルシューティング

この項では、デプロイメントに関する一般的な問題について説明します。次のトピックが含まれます:

- 15.10.1.1項「属性のホストまたはドメイン名のフォーマットが正しくありませんというエラーでデプロイメントが失敗する」

- 第15.10.1.2項「デプロイメントが失敗する」

15.10.1.1 属性のホストまたはドメイン名のフォーマットが正しくありませんというエラーでデプロイメントが失敗する

問題

次のようなエラーでデプロイメントが失敗します。

Incorrect host format for attibute : PRIMARY_OAM_SERVERS : server-123.mycompany.com

バグにより、デプロイメント処理中に起動されたツールのいずれかがハイフン(-)文字を含むホスト名またはドメイン名を処理できません。

ソリューション

ハイフン(-)文字を含まないホスト名およびドメイン名を使用してください。

15.10.1.2 デプロイメントが失敗する

問題

デプロイに失敗します。

ソリューション

次のディレクトリにあるデプロイメント・ログを確認してください。

LCM_HOME/provisioning/logs/hostname

ここでhostnameは、デプロイメント手順が失敗したホストです。

15.10.2 起動/停止スクリプトのトラブルシューティング

この項では、起動または停止スクリプトに関する一般的な問題について説明します。次のトピックが含まれます:

- 第15.10.2.1項「領域不足により事前検査が不適切に失敗する」

- 第15.10.2.2項「起動/停止スクリプトが管理対象サーバーの起動または停止に失敗する」

15.10.2.1 領域不足により事前検査が不適切に失敗する

問題

事前検査を実行する際、ディレクトリIDM_TOPに使用可能な領域が十分にあることを確認します。IDM_TOP/productsおよびIDM_TOP/configに対して別々のマウント・ポイントを作成した場合、事前検査では2つのマウント・ポイントに割り当てられた領域を合計しないため、チェックは不適切に失敗します。

ソリューション

次のファイルを編集して、空き領域のチェックを無効にします。

LCM_HOME/provisioning/idm-provisioning-build/idm-common-preverify-build.xml

エントリを探します。

<target name="common-preverify-tasks">

次のエントリをコメントアウトして、編集後に次のようになるようにします。

<!--antcall target="private-preverify-free-space"/-->

ファイルを保存します。

15.10.2.2 起動/停止スクリプトが管理対象サーバーの起動または停止に失敗する

問題

問題: 起動または停止スクリプトが管理対象サーバーの起動または停止に失敗します。

SHARED_CONFIG_DIR/scripts/logsディレクトリの起動または停止ログには、次のようなエラーが含まれています。

weblogic.utils.AssertionError: ***** ASSERTION FAILED *****
at weblogic.server.ServerLifeCycleRuntime.getStateRemote(ServerLifeCycleRuntime.java:734)
at weblogic.server.ServerLifeCycleRuntime.getState(ServerLifeCycleRuntime.java:581)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

ソリューション

1. 失敗した管理対象サーバーを停止します。プロセスを停止する必要のある場合があります。

2. 管理対象サーバーのLDAPデータをバックアップしてから削除します。たとえば、次のようにします。

rm –rf LOCAL_CONFIG_DIR/domains/IAMAccessDomain/servers/server_name/data/ldap

server_nameは失敗した管理対象サーバーの名前です。

3. 管理対象サーバーを再起動します。

15.10.3 Oracle Access Management Access Manager 11gのトラブルシューティング

この項では、Access Managerで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

- 第15.10.3.1項「Access Managerのメモリーが不足している」

- 第15.10.3.2項「セッション数が最大許容値に達した」

- 第15.10.3.3項「Oracle Access Management Access Managerを初めてインストールしたときにポリシーが作成されない」

- 第15.10.3.4項「保護されたリソースにアクセスしても、資格証明を要求するメッセージが表示されない」

- 15.10.3.5項「Access Managementコンソールにログインできない」

15.10.3.1 Access Managerのメモリーが不足している

問題

Access Managerがしばらく実行した後、次のエラー・メッセージが出力されます。

Attempting to allocate 1G bytes
There is insufficient native memory for the Java Runtime Environment to continue.

考えられる理由:

- システムで物理RAMまたはスワップ領域が不足している。

- 32ビット・モードでプロセスのサイズ制限に到達した。

解決策

- システムのメモリー・ロードを減らします。

- 物理メモリーまたはスワップ領域を増やします。

- スワップのバックエンドのデータストアが一杯かどうかを確認します。

- 64ビットOSで64ビットJavaを使用します。

- Javaヒープ・サイズを減らします(-Xmx/-Xms)。

- Javaスレッドの数を減らします。

- Javaスレッドのスタック・サイズを減らします(-Xss)。

- 圧縮参照を無効にします(-XXcompressedRefs=false)。

- コマンド行からコマンド行ツールadrciを実行できることを確認します。

- at oracle.dfw.impl.incident.ADRHelper.invoke(ADRHelper.java:1309)

- at oracle.dfw.impl.incident.ADRHelper.createIncident(ADRHelper.java:929)

- at oracle.dfw.impl.incident.DiagnosticsDataExtractorImpl.createADRIncident(DiagnosticsDataExtractorImpl.java:1116)

- OAMHOST1上およびOAMHOST2上で、IAD_MSERVER_HOME/binにあるファイルsetSOADomainEnv.shを編集し、次のように開始する行を探します。

PORT_MEM_ARGS=

この行を次を読み取るように変更します。

PORT_MEM_ARGS="-Xms768m -Xmx2560m"

15.10.3.2 セッション数が最大許容値に達した

問題

Access Managerサーバーで次のようなエラー・メッセージが表示されます。

The user has already reached the maximum allowed number of sessions. Please close one of the existing sessions before trying to login again.

ソリューション

ログアウトせずに何回もログインすると、構成されているセッションの最大数を超えることがあります。Access Management管理コンソールを使用して、構成されているセッションの最大数を変更できます。

Access Management管理コンソールを使用してこの構成を変更するには、次の手順に従います。

1. 「システム構成」→「共通構成」→「セッション」を選択します。

2. どのユーザーにも想定されるすべての同時ログイン・セッションに対処できるように、「1ユーザー当たりの最大セッション数」フィールドの値を大きくします。このフィールドには、1以上の任意の値を指定できます。

15.10.3.3 Oracle Access Management Access Managerを初めてインストールしたときにポリシーが作成されない

問題

Access Managerを構成した後、管理サーバーの起動に長時間を要します。

ソリューション

Access Managerのデータベースを調整します。Access Managerを構成した後で管理サーバーを初めて起動すると、データベースにいくつかのデフォルト・ポリシーが作成されます。データベースが遠方にある場合やチューニングを必要とする場合は、この作業に膨大な時間を要することがあります。

Resources
Authentication Policies
Protected Higher Level Policy
Protected Lower Level Policy
Publicl Policy
Authorization Policies
Authorization Policies

これらの項目が表示されない場合は、最初の移入に失敗しています。管理サーバーのログ・ファイルで詳細を確認します。

15.10.3.4 保護されたリソースにアクセスしても、資格証明を要求するメッセージが表示されない

問題

保護されたリソースにアクセスすると、本来はAccess Managerからユーザー名とパスワードの入力を要求されます。たとえば、簡単なHTMLページを作成してリソースとして追加すると、資格証明の入力画面が表示されます。

ソリューション

資格証明の入力画面が表示されない場合は、次の手順を実行します。

1. IAMAccessDomainのホストの別名が設定されていることを確認します。IAMAccessDomain:80、IAMAccessDomain:Null、IADADMIN.mycompany.com:80およびSSO.mycompany.com:443の別名が必要です。ここで、ポート80はHTTP_PORT、ポート443はHTTP_SSL_PORTです。

2. Webゲートがインストールされていることを確認します。

3. IAD_ASERVER_HOME/outputからWebゲートのLibディレクトリにObAccessClient.xmlがコピーされ、OHSが再起動されたことを確認します。

4. ObAccessClient.xmlが最初に作成されたとき、このファイルは適切な形式になっていません。OHSを再起動すると、そのファイルが再検査されて適切な形式になります。OHSを初めて起動すると、このファイルの新しいバージョンがAccess Managerから取得されます。

5. Access Managerサーバーを停止し、保護されたリソースへのアクセスを試みます。Access Managerサーバーが使用できないというエラーが表示されます。このエラーが表示されない場合は、Webゲートをインストールしなおします。

15.10.3.5 Access Managementコンソールにログインできない

問題

Access Managementコンソールにログインできません。管理サーバーの診断ログに次のようなエラー・メッセージが含まれる場合があります。

Caused by: oracle.security.idm.OperationFailureException:
oracle.security.am.common.jndi.ldap.PoolingException [Root exception is oracle.ucp.UniversalConnectionPoolException:
Invalid life cycle state.
Check the status of the Universal Connection Pool]
at
oracle.security.idm.providers.stdldap.UCPool.acquireConnection(UCPool.java:112)

ソリューション

/tmp/UCP*のファイルを削除し、管理サーバーを再起動します。

15.10.4 Oracle Identity Managerのトラブルシューティング

この項では、Oracle Identity Managerで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

- 第15.10.4.1項「Oracle Identity Managerの構成実行時のjava.io.FileNotFoundException」

- 第15.10.4.2項「Oracle Identity Managerでのユーザー作成時のResourceConnectionValidationxception」

- 第15.10.4.3項「Oracle Identity Managerのリコンシリエーション・ジョブが失敗する」

15.10.4.1 Oracle Identity Managerの構成実行時のjava.io.FileNotFoundException

問題

Oracle Identity Manager構成を実行すると、java.io.FileNotFoundException: soaconfigplan.xml (Permission denied)のエラーが表示され、Oracle Identity Manager構成が失敗することがあります。

ソリューション

この問題を回避するには、次の手順を実行します。

1. ファイル/tmp/soaconfigplan.xmlを削除します。

2. 構成を再開します(OH/bin/config.sh)。

15.10.4.2 Oracle Identity Managerでのユーザー作成時のResourceConnectionValidationxception

問題

アクティブ/アクティブ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)
.
.
.

ソリューション

この例外が発生しても、ユーザーは正しく作成されます。

15.10.4.3 Oracle Identity Managerのリコンシリエーション・ジョブが失敗する

問題

Oracle Identity Managerのリコンシリエーション・ジョブが失敗するか、ログ・ファイルに次のメッセージが示されます。

LDAP Error 53 : [LDAP: error code 53 - Full resync required. Reason: The provided cookie is older than the start of historical in the server for the replicated domain : dc=mycompany,dc=com]

このエラーは、Oracle Unified Directoryが特定期間書き込まれなかったために、Oracle Unified Directory変更ログCookieのデータが期限切れになったことにより発生します。

解決策:

1. ブラウザを開いて、次の場所に移動します。

http://igdadmin.mycompany.com/sysasdmin

2. COMMON_IDM_PASSWORDを使用して、xelsysadmとしてログインします。

3. 「システム管理」で「スケジューラ」をクリックします。

4. 「スケジュール済ジョブの検索」で、LDAP * (*の前にスペースあり)と入力し[Enter]を押します。

5. 検索結果のジョブごとに、左側のジョブ名をクリックし、右側の「無効化」をクリックします。
すべてのジョブに対してこれを行います。ジョブがすでに無効化されている場合には何もしません。

6. LDAPHOST1で次のコマンドを実行します。

cd OUD_ORACLE_INSTANCE/OUD/bin
./ldapsearch -h ldaphost1 -p 1389 -D "cn=oudadmin" -b "" -s base "objectclass=*" lastExternalChangelogCookie

Password for user 'cn=oudadmin': <OudAdminPwd>
dn: lastExternalChangelogCookie: dc=mycompany,dc=com:00000140c682473c263600000862;

lastExternalChangelogCookie:に続く出力文字列をコピーします。この値は次の手順で必要になります。たとえば、次のようにします。

dc=mycompany,dc=com:00000140c682473c263600000862;

16進数部は28文字の長さである必要があります。値が2つ以上の16進数部を持つ場合、28文字部分をスペースで分けます。たとえば、次のようにします。

dc=mycompany,dc=com:00000140c4ceb0c07a8d00000043 00000140c52bd0b9104200000042 00000140c52bd0ba17b9000002ac 00000140c3b290b076040000012c;

7. 次の各LDAPリコンシリエーション・ジョブを1回ずつ実行し、最後の変更番号をリセットします。

- LDAPロール削除のリコンシリエーション

- LDAPユーザー削除のリコンシリエーション

- LDAPロール作成および更新のリコンシリエーション

- LDAPユーザー作成および更新のリコンシリエーション

- LDAPロール階層のリコンシリエーション

- LDAPロール・メンバーシップのリコンシリエーション

ジョブを実行する手順:

1. OIMシステム管理コンソールにユーザーxelsysadmとしてログインします。

2. 「システム管理」で「スケジューラ」をクリックします。

3. 「スケジュール済ジョブの検索」で、LDAP * (*の前にスペースあり)と入力し[Enter]を押します。

4. 実行するジョブをクリックします。

5. パラメータ「最終変更番号」を手順6で取得した値に設定します。
例:

dc=mycompany,dc=com:00000140c4ceb0c07a8d00000043 00000140c52bd0b9104200000042 00000140c52bd0ba17b9000002ac 00000140c3b290b076040000012c;

6. 「即時実行」をクリックします。

7. リストのジョブごとに、この手順の最初から繰り返します。

8. 最後の変更ログ番号がリセットされている増分リコンシリエーション・ジョブごとに、ジョブを実行し、ジョブが正常に完了したことを確認します。

9. ジョブが正常に実行されたら、要件に従い、ジョブの定期的な実行を再有効化します。

問題の発生が続く場合、各OUDインスタンスで次のコマンドを実行して、Cookieの保持期間を2か月延ばします。

増分ジョブを再有効化して正常に実行した後に、エラーが再度表示される場合(完全再同期が必要です。理由: 指定したCookieが古くなっています...)、OUD Cookieの保存期間を延ばします。この値に関する杓子定規はありませんが、問題を回避するには十分長くする一方、OUDでの不要なリソース消費を回避するには十分短くする必要があります。1-2週間で十分ですが、次の例では2週間が指定されています。

./dsconfig set-replication-server-prop --provider-name "Multimaster Synchronization" --set replication-purge-delay:8w -D cn=oudadmin --trustAll -p 4444 -h LDAPHOST1

Password for user 'cn=oudadmin':  <OudAdminPswd>
Enter choice [f]: f

15.10.5 Oracle SOA Suiteのトラブルシューティング

この項では、Oracle SOA Suiteで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

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

問題: 次のトランザクション・タイムアウト・エラーがログに表示されます。

Internal Exception: java.sql.SQLException: Unexpected exception while enlisting
XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start()
failed on resource 'SOADataSource_soaedg_domain': XAER_NOTA : The XID
is not valid

解決方法: トランザクション・タイムアウト設定を確認し、JTAトランザクション・タイムアウトがデータ・ソースXAトランザクション・タイムアウトよりも短いことを確認します(後者はデータベースでのdistributed_lock_timeoutよりも短い)。

出荷時の設定では、SOAデータ・ソースではXAタイムアウト値は設定されていません。Set XA Transaction Timeout構成パラメータはWebLogic Server管理コンソールでは確認されません。この場合、データ・ソースはドメイン・レベルのJTAタイムアウトを使用します。これは30に設定されています。また、データベースのdistributed_lock_timeoutのデフォルト値は60です。この結果、トランザクションにかかる時間がこれらの値よりも短いと想定されるシステムでは、SOA構成は正しく動作します。特定の操作に想定されるトランザクション時間に合せて、これらの値を調整します。

A プロセスの自動化

この付録では、単一のホストからすべてのスクリプトを起動するスクリプトの記述方法について説明します。

スクリプトを単一のホストからすべてのスクリプトを起動するように記述することで、1コマンドでのデプロイメント作成の効果が得られます。

次のサンプルスクリプトは、これを行うように変更できます。

免責事項:

これらのスクリプトは実行例であり、デプロイメント処理を自動化する方法を示す概念を証明するものとして現状のまま提供されます。スクリプトは、使用している環境固有のニーズに合わせてカスタマイズおよびテストする必要があります。

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

- 第A.1項「setenv.sh」

- 第A.2項「setlocalenv.sh」

- 第A.3項「deploy.sh」

- 第A.4項「スクリプトの使用」

A.1 setenv.sh

このスクリプトは環境を設定します。

#!/bin/sh
#
# setenv.sh
#
# Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
#
#    NAME
#     setenv.sh - captures details of environment to be deployed
#
#    DESCRIPTION
#      <short description of component this file declares/defines>
#
#    NOTES
#      <other useful comments, qualifications, etc.>
#
#    MODIFIED   (MM/DD/YY)
#
CURRENT_HOST=`hostname`

export USERNAME=<unix user eg oracle>

export IDMTOP=SW_ROOT
export SHARED_CONFIG_DIR=$IDMTOP/config
export LOCAL_CONFIG_DIR=<LOCAL_ROOT>
export REPOSITORY=<REPOS_HOME>
export INSTALLERS=$REPOSITORY/installers
export RESPONSE_FILE=<FULLY QUALIFIED PATH TO DEPLOYMENT RESPONSE FILE>
export PROVISIONING=<IDMLCM_HOME>/provisioning
export SCRIPTS_DIR=<DIRECTORY CONTAINING THESE SCRIPTS>
export JAVA_HOME=$REPOSITORY/jdk6
export ANT_HOME=$REPOSITORY/provisioning/ant
export PRIMORDIAL_TO_DMZ_SHARE=$PROVISIONING/dmzShare

export RCU_HOME=$INSTALLERS/rcu
export RCU_LOG_LOCATION=$SCRIPTS_DIR/rcu/logs-$$
export RCU_LOG_NAME=rcu.log
export RCU_TIMESTAMP_LOG_DIR=false
export DB_SCHEMA_PREFIX=DEV

PHASES_TO_RUN='preverify install preconfigure configure configure-secondary postconfigure startup validate'

export ALL_HOSTS='<LDAPHOST1> <LDAPHOST2> <OAMHOST1> <OAMHOST2> <OIMHOST1> <OIMHOST2> <WEBHOST1> <WEBHOST2>'

export DB_CONNECT_STRING=<DB-SCAN>:<DB_LSNR_PORT>:<IDSTORE_SERVICE_NAME>
export DB_PASSWORD_SYS=<DB SYS PWD>
export DB_PASSWORD_SCHEMA=<RCU_SCHEMA_PASSWORD>

mkdir -p $PRIMORDIAL_TO_DMZ_SHARE

function timer()
{
if [[ $# -eq 0 ]]; then
echo $(date '+%s')
else
local  stime=$1
etime=$(date '+%s')

if [[ -z "$stime" ]]; then stime=$etime; fi
dt=$((etime - stime))
ds=$((dt % 60))
dm=$(((dt / 60) % 60))
dh=$((dt / 3600))
printf '%d:%02d:%02d' $dh $dm $ds
fi
}

execCmd()
{
HOST=$1
shift
CMD_LINE=$*
CMD="ssh $USERNAME@$HOST $CMD_LINE"

echo "[idmprov] " `date` $CMD
tmr=$(timer)
$CMD

printf '[idmprov] Elapsed time: %s\n' $(timer $tmr)
}

A.2 setlocalenv.sh

#!/bin/sh
#
# setlocalenv.sh
#
# Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
#
#    NAME
#     setenv.sh - captures details of environment to be deployed
#
#    DESCRIPTION
#      <short description of component this file declares/defines>
#
#    NOTES
#      <other useful comments, qualifications, etc.>
#
#    MODIFIED   (MM/DD/YY)

#
CURRENT_HOST=`hostname`

export USERNAME=<software owner>

export IDMTOP=<SW_ROOT>
export SHARED_CONFIG_DIR=$IDMTOP/config
export LOCAL_CONFIG_DIR=<LOCAL_ROOT>
export REPOSITORY=<REPOS_HOME>
export INSTALLERS=$REPOSITORY/installers
export RESPONSE_FILE=<FULLY QUALIFIED PATH TO DEPLOYMENT RESPONSE FILE>
export PROVISIONING=<IDMLCM_HOME>/provisioning
export SCRIPTS_DIR=<DIRECTORY CONTAINING THESE SCRIPTS>
export JAVA_HOME=$REPOSITORY/jdk6
export ANT_HOME=$REPOSITORY/provisioning/ant
export PRIMORDIAL_TO_DMZ_SHARE=$PROVISIONING/dmzShare

A.3 deploy.sh

これは、デプロイメント・スクリプトです。

#!/bin/sh
#
# deploy.sh
#
# Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
#
#    NAME
#      provision.sh - this script starts executing Deployment phases in all hosts
#
#    DESCRIPTION
#      <short description of component this file declares/defines>
#
#    NOTES
#      - copy all scripts named prov_*.sh to a directory in primordial host
#      - make sure this directory is accessible using the same path from all hosts being provisioned
#      - update prov_env.sh with environment specific details (directories, hostnames, db, etc)
#      - run this script from the primordial host
#      - script will create one log file for each phase in each host - named prov_run-<phase>-<host>.log
#      - script will stop when Deployment completes or on detecting 1st failure (absence of "BUILD SUCCESSFUL" in the log file)
#
#    MODIFIED   (MM/DD/YY)
#

. <DIRECTORY CONTAINING THESE SCRIPTS>/setenv.sh

if [ ! -e $SCRIPTS_DIR/logs ]then
mkdir -p $SCRIPTS_DIR/logs
fi

rm -r $SCRIPTS_DIR/logs/* LCM_ROOT/provisioning* <LCM_ROOT>/internal LCM_ROOT/lcmconfig LCM_ROOT/keystores 2> /dev/null

starttmr=$(timer)

for PHASE in $PHASES_TO_RUN
do
phasetmr=$(timer)
for HOST in $ALL_HOSTS
do
echo "[idmprov] Running $PHASE on  $HOST"
logFile=$SCRIPTS_DIR/logs/$PHASE-$HOST.log

execCmd $HOST ". $SCRIPTS_DIR/setlocalenv.sh; cd $PROVISIONING/bin; ./runIAMDeployment.sh -responseFile $RESPONSE_FILE -target $PHASE" > $logFile

fgrep -s "BUILD SUCCESSFUL" $logFile
if [ "$?" = "1" ]
then
echo "ERROR: $PHASE failed in $HOST"
exit 1
fi

done

echo -e "[idmprov] Total $PHASE\c"
printf ' time: %s\n' $(timer $phasetmr)
done

printf '[idmprov] Total Elapsed time: %s\n' $(timer $starttmr)

A.4 スクリプトの使用

スクリプトの使用方法は、次のとおりです。

1. このスクリプトをトポロジ内の各ホスト上の使用可能な場所にコピーします。

2. スクリプトを編集し、<SW_ROOT>のようなエントリを、ご使用の環境に適用可能なエントリと置き換えます。これを行いやすくするには、第7.1項「Identity and Access Managementのデプロイメントのための情報収集」を使用してください。

3. 最初のホストからトポロジ内の他のホストのそれぞれに、ssh等価を設定します。詳細については、オペレーティングシステムのドキュメントを参照してください。

4. 最初のホストからトポロジ内の各ホストに次のコマンドを発行して、ssh等価が機能していることを検証します。このコマンドでは、プロンプトなしで各リモート・マシンでの日付を示す必要があります。

ssh hostname date

5. 第8章「デプロイメント・プロファイルの作成」で生成されたデプロイメント・レスポンス・ファイルを、これらのスクリプトのあるディレクトリと同じディレクトリにコピーします。

6. deploy.shスクリプトを実行します。

7. デプロイメントの完了後、ssh等価を削除します。

B IAMデプロイ再実行前の環境のクリーンアップ

この付録では、Identity and Accessのデプロイを再実行する前に環境をクリーンアップする方法について説明します。

runIAMDeployment.shコマンドを使用してOracle Identity and Access Managementをプロビジョニングする場合、トポロジの各ステージを完了してから次のステージを指定された順番に開始する必要があります。ステージが失敗した場合、クリーンアップして最初からやり直す必要があります。

デプロイされた環境を、デプロイメントの別のサイクルを開始する前にクリーンアップするには、次の手順を実行します。

1. 各ホストですべてのIdentity and Access Managementのプロセスを停止します。これを行うには、ホストを再起動する必要があります。

2. 各ホストで、ディレクトリLOCAL_ROOTの内容を削除します。

3. 共有記憶域のディレクトリPIDM_TOの内容を削除します。

注意:

この例では、SHARED_CONFIG_DIRはIDM_TOPにネストされます。その結果、これも削除されます。ただし、異なる場所にSHARED_CONFIG_DIRがある場合は、これも明示的に削除します。

4. Oracle Unified DirectoryのかわりにOracle Internet Directoryをディレクトリのホストとして使用している場合、RCUを使用してデータベース・スキーマを削除します。

これらの手順の実行後、runIAMDeployment.shを再実行できます。

C スケーリングのためのトポロジ・ツール・コマンド

この付録では、Identity and Access Managementエンタープライズ・デプロイメントをスケーリングするために利用できるtopotool.shコマンドについて説明します。

デプロイメント中に、デプロイされたトポロジの詳細が含まれるトポロジ・ストアが作成されます。環境にパッチ適用する際、ライフサイクル・ツールは、パッチ計画を作成して実行するためにストアを読み取ります。

第14章「エンタープライズ・デプロイメントのスケーリング」で、各種ツールを使用してデプロイメントをスケール・アップまたはスケール・アウトする方法を説明しています。スケーリング手順の一部として、デプロイメントへの新しい追加に対応するストアへ新しいエントリを追加する必要があります。これは、IAMトポロジ・ツールを使用して行います。

このツールは、IDMLCM_HOME/topotool/binにあります。

トポロジ・ツールを実行する前に、LCM_ROOT/lcmconfig/topologyディレクトリ全体をバックアップしてください。

注意:

コマンド行オプションの多くは、たとえばOUD3のような数字を含むインスタンス名またはコンポーネント名を使用します。これらの名前は、スケーリング用の情報を収集した際にすでに決定しているはずです。第14章「エンタープライズ・デプロイメントのスケーリング」の情報収集に関する項を参照してください。

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

- 第C.1項「トポロジ・ツールの構文」

- 第C.2項「一般的に使用されるコマンド行操作」

- 第C.3項「手順とコマンド行の例」

C.1 トポロジ・ツールの構文

一般的な構文は次のとおりです。

topotool.sh command [-option]

ヘルプについては次のようになります。

topotool.sh [-help]

topotool.sh command [-help]

注意:

この項では、トポロジ・ツールの構文を詳細には説明していません。この項で示されるコマンドおよびオプションは、このガイドで使用されるもののみです。

C.1.1 コマンド

Add

トポロジ・ストアに情報を追加します。

topotool.sh add [options]

Modify

トポロジ・ストアの情報を変更します。

topotool.sh modify [options]

C.1.2 Addで使用するコマンド行オプション

-component

コンポーネントの追加を指定します。

-confighomename oudn | oimn | oamn | soan | NodeManager:Access | NodeManager:Identity | ohsn

追加するローカルまたは共有の構成ホームを指定します。-instanceとともに使用します。

-dbname DBNAME

使用するOracle Databaseを指定します。-instanceとともに使用します。このガイドでは、DBNAMEは常にOIM:DBとなります。

-description STRING

-machineおよび-confighomeとともに使用します。STRINGは、"oim3 machine"などの引用符付き文字列です。

-fqdn HOSTNAME

ホストを指定します。HOSTNAMEの形式は、ldaphost3.mycompany.com、oimhost4.mycompany.comなどの完全修飾ドキュメント名です。-hostとともに使用します。

-hometype OUD | IAM | SOA | WEBTIER

追加するホーム・タイプを指定します。-instanceとともに使用します。

-host

ホストの追加を指定します。

-instance

インスタンスの追加を指定します。

-instancegroup STRING

インスタンス・グループを指定します。このガイドでは、-instancegroupとともに使用した場合、STRINGは常に1となります。-instanceとともに使用します。

-machine

マシンの追加を指定します。

-machinename MACHINE

追加するマシンを指定します。-instanceおよび-machineとともに使用します。MACHINEの形式は、ldaphost3.mycompany.com、oimhost4.mycompany.comなどの完全修飾マシン名です。

-mwhomename Directorytier:MW_HOME | Access:MW_HOME | Identity:MW_HOME | Webtier:MW_HOME | Webtier:MW_HOME_2 | Webtier:MW_HOME_n

追加するMiddlewareホームを指定します。-instanceとともに使用します。

-name NAME

マシンまたはインスタンスの名前を指定します。-machineとともに使用する場合、NAMEの形式はldaphost3.mycompany.comなどの完全修飾ホスト名になります。

-instanceまたは-confighomeとともに使用した場合、NAMEの形式は、たとえばoid3などのproductnになります。

-instanceとともに使用した場合、NAMEの形式はホスト名とポートのペアで、この形式は非SSLポートではproductn:host:plain、SSLポートではproductn:host:sslとなり、ここでproductはOUDまたはOIMなどのコンポーネント、nはインスタンス番号を表します。

OPMNインスタンスの追加に使用する場合、NAMEの形式のホスト名の部分は、たとえばOPMN:webhost3:sslなどのOPMNとなります。

-path PATH

"/u01/oracle/config/nodemanager/oimhost3.mycompany.com"などの引用符付きディレクトリ・パスを指定します。-confighomeとともに使用します。

-port PORT

5556などのポート番号を指定します。-hostとともに使用します。

-secure true | false

SSLポートにはtrueを、非SSLポートにはfalseを指定します。-hostとともに使用します。

-shared true | false

-confighomeとともに使用して、共有またはローカルの構成ホームであることを示します。

-sharedlcmconfigaccessible true | false

共有のLCM構成がアクセス可能かどうかを指定します。-machineとともに使用します。このガイドでは、アプリケーション層のマシンを追加する場合にはtrue、Web層のマシンの場合にはfalseに設定します。

-tier DIRECTORY | IDM | WEB |

第14章「エンタープライズ・デプロイメントのスケーリング」に示された層を指定します。

-type TYPE

インスタンスまたはコンポーネントのタイプを指定します。どちらの場合もTYPEは、使用する特定の型定義を表し、追加するインスタンスまたはコンポーネントを照合します。

-instanceとともに使用すると、値はOUD | OHS_HTTPD | OPMN WLS_ADMIN | WLS_MANAGED | WLS_NODE_MANAGERのいずれかになります。

-componentとともに使用すると、値はOHS_WEBGATE | WLS_ADMIN_OAM_CONSOLE | WLS_ADMIN_WLS_CONSOLE | WLS_MANAGED_OAM | WLS_MANAGED_OIM | WLS_MANAGED_SOAのいずれかになります。

-virtual true | false

追加されるホストが仮想ホストかどうかを指定します。-hostとともに使用します。このガイドでは常にfalseとなります。

C.1.3 Modifyで使用する、ロード・バランサ・マッピングを更新するコマンド行オプション

-lbrmapping

新しいホストの追加によるロード・バランサ・マッピングの変更を指定します。

-lbrname LBRNAME

-lbrmappingとともに使用します。ロード・バランサの名前を指定します。このガイドでは、LBRNAMEは常に、LBR1またはLBR2です。

-name idstore | idstore_ssl

-lbrmappingとともに使用します。ロード・バランサのマッピング名を指定します。

-physicalhosts HOSTS

-lbrmappingとともに使用します。ホストまたはカンマ区切りのホストのリストを指定します。非SSLホストでは、たとえば、OUD:LDAP:oud1:ldaphost1,oud2:ldaphost2,oud3:ldaphost3のようにproductn:hostの形式になります。SSLホストでは、たとえば、oud3:ldaphost3:sslのようにproductn:host:sslの形式になります。

C.2 一般的に使用されるコマンド行操作

マシンの追加:

topotool.sh add -machine -name MACHINE -sharedlcmconfigaccessible true_false

非SSLホストの追加:

topotool.sh add -host -name HOST -fqdn FQDN -port PORT -secure false -virtual false

SSLホストの追加:

topotool.sh add -host -name HOST_SSL -fqdn FQDN -port SSL_PORT -secure false -virtual false

ローカルの構成ホームの追加:

topotool.sh add -confighome -name LOCAL_CONFIG -path PATH -shared false

共有の構成ホームの追加:

topotool.sh add -confighome -name SHARED_CONFIG -path "/u01/oracle/config/instances/oud3" -shared true

インスタンスの追加:

topotool.sh add -instance -machinename MACHINE -name INSTANCE -type TYPE -tier TIER -mwhomename MWHOME-hometype  -confighomename  LOCAL_OR_SHARED_CONFIG -instancegroup 1

コンポーネントの追加:

topotool.sh add -component -instancename INSTANCE -type TYPE -hosts HOST

LBRマッピングの更新:

topotool.sh modify -lbrmapping -lbrname LBR -name LBR_MAPPING -physicalhosts HOST
topotool.sh modify -lbrmapping -lbrname LBR_SSL -name LBR_MAPPING -physicalhosts HOST_SSL

C.3 手順とコマンド行の例

この項では、各層について注意事項、層内でコンポーネントをスケール・アウトする一般的な手順およびコマンド行例を示します。内容は次のとおりです。

- 第C.3.1項「ディレクトリ層のスケール・アウト/スケール・アップ」

- 第C.3.2項「アプリケーション層のスケール・アウト/スケール・アップ」

- 第C.3.3項「Web層のスケール・アウト/スケール・アップ」

注意:

ディレクトリ例は使用しないでください。値は自分のデータに置き換える必要があります。

C.3.1 ディレクトリ層のスケール・アウト/スケール・アップ

以降の項では、ディレクトリ層のスケーリングについて説明します。

- 第C.3.1.1項「ディレクトリ層に関する注意」

- 第C.3.1.2項「Oracle Unified Directoryをスケーリングするためのトポロジ・ツールの手順」

- 第C.3.1.3項「Oracle Unified Directoryのスケール・アウト・コマンド」

- 第C.3.1.4項「Oracle Unified Directoryのスケール・アップ・コマンド」

C.3.1.1 ディレクトリ層に関する注意

- スケール・アップおよびスケール・アウトがサポートされています。

- OracleバイナリはLDAPホスト間で共有されます。

- スケール・アウトの際、共有のバイナリ・ディレクトリが新しいホストにマウントされます。

- 共有のconfigディレクトリも新しいホストにマウントされます。

- ロード・バランサのマッピングを再構成してください。

C.3.1.2 Oracle Unified Directoryをスケーリングするためのトポロジ・ツールの手順

1. sharedlcmconfigaccessibleをtrueに設定してマシンを追加します。(スケール・アウトのみ)。

2. Oracle Unified Directoryが非SSLポートでリスニングしている場合には、非SSLホストを追加します。

3. Oracle Unified DirectoryがSSLポートでリスニングしている場合には、SSLホストを追加します。

4. 構成ホームを追加します。共有構成であるかローカル構成であるかに基づいて、共有をtrueまたはfalseに設定します。

5. 既存のMiddlewareホームを使用して、OUDタイプ、DIRECTORY層、OUDホーム・タイプのインスタンスを追加します。

6. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたDEFAULTタイプのインスタンス用のコンポーネントを追加します。

7. 新しく作成された非SSLまたはSSLホストでロード・バランサ・マッピングを更新します。

C.3.1.3 Oracle Unified Directoryのスケール・アウト・コマンド

- 新しいマシンの追加

topotool.sh add -machine -name ldaphost3.mycompany.com -description "oud3 machine" -sharedlcmconfigaccessible true

- 新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name oud3:ldaphost3 -fqdn ldaphost3.mycompany.com -port 1389 -secure false -virtual false

- SSL:

topotool.sh add -host -name oud3: ldaphost3:ssl -fqdn ldaphost3.mycompany.com -port 1390 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name oud3 -description "oud3 local configuration home" -path "/u02/private/oracle/config/instances/oud3" -shared false

- 共有構成:

topotool.sh add -confighome -name oud3 -description "oud3 configuration home" -path "/u01/oracle/config/instances/oud3" -shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename ldaphost3.mycompany.com -name oud3 -description "oud3" -type OUD -tier DIRECTORY -mwhomename Directorytier:DIR_MW_HOME -hometype OUD -confighomename oud3 -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename oud3 -type DEFAULT  -hosts oud3:ldaphost3,oud3:ldaphost3:ssl

- ロード・バランサ・マッピングへの新しいホストの追加

- 非SSL:

topotool.sh modify -lbrmapping -lbrname LBR2 -name idstore -physicalhosts oud3:ldaphost3

- SSL:

topotool.sh  modify -lbrmapping -lbrname LBR2 -name idstore-ssl  -physicalhosts oud3:ldaphost3:ssl

C.3.1.4 Oracle Unified Directoryのスケール・アップ・コマンド

- 新しいマシンの追加

topotool.sh add -machine -name ldaphost3.mycompany.com -description "oud3 machine" -sharedlcmconfigaccessible true

- 新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name oud3:ldaphost3 -fqdn ldaphost3.mycompany.com -port 1389 -secure false -virtual false

- SSL:

topotool.sh add -host -name oud3: ldaphost3:ssl -fqdn ldaphost3.mycompany.com -port 1390 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name oud3 -description "oud3 local configuration home" -path "/u02/private/oracle/config/instances/oud3" -shared false

- 共有構成:

topotool.sh add -confighome -name oud3 -description "oud3 configuration home" -path "/u01/oracle/config/instances/oud3" -shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename ldaphost3.mycompany.com -name oud3 -description "oud3" -type OUD -tier DIRECTORY -mwhomename Directorytier:DIR_MW_HOME -hometype OUD -confighomename oud3 -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename oud3 -type DEFAULT  -hosts oud3:ldaphost3,oud3:ldaphost3:ssl

- ロード・バランサ・マッピングへの新しいホストの追加

- 非SSL:

topotool.sh modify -lbrmapping -lbrname LBR2 -name idstore -physicalhosts oud3:ldaphost3

- SSL:

topotool.sh  modify -lbrmapping -lbrname LBR2 -name idstore-ssl  -physicalhosts oud3:ldaphost3:ssl

C.3.2 アプリケーション層のスケール・アウト/スケール・アップ

以降の項では、アプリケーション層のスケーリングについて説明します。

- 第C.3.2.1項「アプリケーション層に関する注意」

- 第C.3.2.2項「OAMのトポロジ・ツールの手順」

- 第C.3.2.3項「OAMのスケール・アウト・コマンド」

- 第C.3.2.4項「OAMのスケール・アップ・コマンド」

- 第C.3.2.5項「OIMのトポロジ・ツールの手順」

- 第C.3.2.6項「OIMのスケール・アウト・コマンド」

- 第C.3.2.7項「OIMのスケール・アップ・コマンド」

- 第C.3.2.8項「SOAのトポロジ・ツールの手順」

- 第C.3.2.9項「SOAのスケール・アウト・コマンド」

- 第C.3.2.10項「SOAのスケール・アップ・コマンド」

C.3.2.1 アプリケーション層に関する注意

- スケール・アップおよびスケール・アウトがサポートされています。

- Oracleバイナリはホスト間で共有されます。

- スケール・アウトの際、共有のバイナリ・ディレクトリが新しいホストにマウントされます。

- 共有のconfigディレクトリも新しいホストにマウントされます。

- スケール・アウトの場合、ノード・マネージャが追加されます。

C.3.2.2 OAMのトポロジ・ツールの手順

1. sharedlcmconfigaccessibleをtrueに設定してマシンを追加します。(スケール・アウトのみ)。

2. OAMが非SSLポートでリスニングしている場合には、非SSLホストを追加します。

3. OAMがSSLポートでリスニングしている場合には、SSLホストを追加します。

4. OAPのホストを追加します。

5. 構成ホームを追加します。共有構成であるかローカル構成であるかに基づいて、共有をtrueまたはfalseに設定します。

6. 既存のMiddlewareホームを使用して、WLS_MANAGEDタイプ、IDM層、IAMホーム・タイプのインスタンスを追加します。

7. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたDEFAULTタイプのインスタンス用のコンポーネントを追加します。

8. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたWLS_MANAGED_OAMタイプのインスタンス用のコンポーネントを追加します。

C.3.2.3 OAMのスケール・アウト・コマンド

- 新しいマシンの追加

topotool.sh add -machine -name oamhost3.mycompany.com -description "oam3 machine" -sharedlcmconfigaccessible true

- OAMの新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name oam3:oamhost3 -fqdn oamhost3.mycompany.com -port 14100 -secure false -virtual false

- SSL:

topotool.sh add -host -name oam3:oamhost3:ssl -fqdn oamhost3.mycompany.com -port 14101 -secure true -virtual false

- OAPの新しいホストの追加(ホスト名+ポートの組合せ)

topotool.sh add -host -name oam3:slc03oap3 -fqdn oamhost3.mycompany.com -port 5575 -secure false -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name oam3 -description "oam3 local configuration home" -path "/u02/private/oracle/config/domains/IAMAccessDomain" -shared false

- 共有構成:

topotool.sh add -confighome -name oam3 -description "oam3 shared configuration home" -path "/u01/oracle/config/domains/IAMAccessDomain/" -shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename oamhost3.mycompany.com -name oam3 -description "oam3" -type WLS_MANAGED -tier IDM -mwhomename Access:IAD_MW_HOME -hometype IAM -confighomename oam3 -dbname OIM:DB -domainname   IAMAccessDomain -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename oam3 -type WLS_MANAGED_OAM  -hosts oam3:oamhost3, oam3:oamhost3:ssl,oam3:slc03oap3

topotool.sh add -component -instancename oam3 -type DEFAULT  -hosts oam3:oamhost3,oam3:oamhost3:ssl

C.3.2.4 OAMのスケール・アップ・コマンド

- OAMの新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name oam3:oamhost3 -fqdn oamhost3.mycompany.com -port 14100 -secure false -virtual false

- SSL:

topotool.sh add -host -name oam3:oamhost3:ssl -fqdn oamhost3.mycompany.com -port 14101 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name oam3 -description "oam3 local configuration home" -path "/u02/private/oracle/config/domains/IAMAccessDomain" -shared false

- 共有構成:

topotool.sh add -confighome -name oam3 -description "oam3 shared configuration home" -path "/u01/oracle/config/domains/IAMAccessDomain/" -shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename oamhost3.mycompany.com -name oam3 -description "oam3" -type WLS_MANAGED -tier IDM -mwhomename Access:IAD_MW_HOME -hometype IAM -confighomename oam3 -dbname OIM:DB -domainname   IAMAccessDomain -instancegroup 1

- コンポーネントの追加

topotool.sh add -component -instancename oam3 -type WLS_MANAGED_OAM  -hosts oam3:oamhost3, oam3:oamhost3:ssl,oam3:slc03oap3

topotool.sh add -component -instancename oam3 -type DEFAULT  -hosts oam3:oamhost3,oam3:oamhost3:ssl

C.3.2.5 OIMのトポロジ・ツールの手順

1. sharedlcmconfigaccessibleをtrueに設定してマシンを追加します。(スケール・アウトのみ)。

2. OIMが非SSLポートでリスニングしている場合には、非SSLホストを追加します。

3. OIMがSSLポートでリスニングしている場合には、SSLホストを追加します。

4. 構成ホームを追加します。共有構成であるかローカル構成であるかに基づいて、共有をtrueまたはfalseに設定します。

5. 既存のMiddlewareホームを使用して、WLS_MANAGEDタイプ、IDM層、IAMホーム・タイプのインスタンスを追加します。

6. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたDEFAULTタイプのインスタンス用のコンポーネントを追加します。

7. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたWLS_MANAGED_OIMタイプのインスタンス用のコンポーネントを追加します。

C.3.2.6 OIMのスケール・アウト・コマンド

- 新しいマシンの追加

topotool.sh add -machine -name oimhost3.mycompany.com -description "oim3 machine" -sharedlcmconfigaccessible true

- OIMの新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name oim3:oimhost3 -fqdn oimhost3.mycompany.com -port 14000 -secure false -virtual false

- SSL:

topotool.sh add -host -name oim3:oimhost3:ssl -fqdn oimhost3.mycompany.com -port 14001 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name oim3 -description "oim3 local configuration home" -path "/u02/private/oracle/config/domains/IAMGovernanceDomain" -shared false

- 共有構成:

topotool.sh add -confighome -name oim3 -description "oim3 shared configuration home" -path " /u01/oracle/config/domains/IAMGovernanceDomain"-shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename oimhost3.mycompany.com -name oim3 -description "oim3" -type WLS_MANAGED -tier IDM -mwhomename Identity::IGD_MW_HOME -hometype IAM -confighomename oim3 -dbname OIM:DB -domainname   IAMGovernanceDomain -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename oim3 -type WLS_MANAGED_OIM -hosts oim3:oimhost3,oim3:oimhost3:ssl

topotool.sh add -component -instancename oim3 -type DEFAULT -hosts oim3:oimhost3,oim3:oimhost3:ssl

C.3.2.7 OIMのスケール・アップ・コマンド

- OIMの新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name oim3:oimhost3 -fqdn oimhost3.mycompany.com -port 14000 -secure false -virtual false

- SSL:

topotool.sh add -host -name oim3:oimhost3:ssl -fqdn oimhost3.mycompany.com -port 14001 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name oim3 -description "oim3 local configuration home" -path "/u02/private/oracle/config/domains/IAMGovernanceDomain" -shared false

- 共有構成:

topotool.sh add -confighome -name oim3 -description "oim3 shared configuration home" -path " /u01/oracle/config/domains/IAMGovernanceDomain"-shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename oimhost3.mycompany.com -name oim3 -description "oim3" -type WLS_MANAGED -tier IDM -mwhomename Identity::IGD_MW_HOME -hometype IAM -confighomename oim3 -dbname OIM:DB -domainname   IAMGovernanceDomain -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename oim3 -type WLS_MANAGED_OIM -hosts oim3:oimhost3,oim3:oimhost3:ssl

topotool.sh add -component -instancename oim3 -type DEFAULT -hosts oim3:oimhost3,oim3:oimhost3:ssl

C.3.2.8 SOAのトポロジ・ツールの手順

1. sharedlcmconfigaccessibleをtrueに設定してマシンを追加します。(スケール・アウトのみ)。

2. SOAが非SSLポートでリスニングしている場合には、非SSLホストを追加します。

3. SOAがSSLポートでリスニングしている場合には、SSLホストを追加します。

4. 構成ホームを追加します。共有構成であるかローカル構成であるかに基づいて、共有をtrueまたはfalseに設定します。

5. 既存のMiddlewareホームを使用して、WLS_MANAGEDタイプ、IDM層、SOAホーム・タイプのインスタンスを追加します。

6. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたDEFAULTタイプのインスタンス用のコンポーネントを追加します。

7. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたWLS_MANAGED_SOAタイプのインスタンス用のコンポーネントを追加します。

C.3.2.9 SOAのスケール・アウト・コマンド

- 新しいマシンの追加

topotool.sh add -machine -name oimhost3.mycompany.com -description "soa3 instance machine" -sharedlcmconfigaccessible true

- SOAの新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name soa3:oimhost3 -fqdn oimhost3.mycompany.com -port 8001 -secure false -virtual false

- SSL:

topotool.sh add -host -name soa3:oimhost3:ssl -fqdn oimhost3.mycompany.com -port 8002 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name soa3 -description "soa3 local configuration home" -path "/u02/private/oracle/config/domains/IAMGovernanceDomain" -shared false

- 共有構成:

topotool.sh add -confighome -name soa3 -description "soa3 shared configuration home" -path " /u01/oracle/config/domains/IAMGovernanceDomain"-shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename oimhost3.mycompany.com -name soa3 -description "soa3 " -type WLS_MANAGED -tier IDM -mwhomename Identity::IGD_MW_HOME -hometype SOA -confighomename soa3 -dbname OIM:DB -domainname   IAMGovernanceDomain -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename soa3 -type WLS_MANAGED_SOA -hosts soa3:oimhost3,soa3:oimhost3:ssl

topotool.sh add -component -instancename soa3 -type DEFAULT -hosts soa3:oimhost3,soa3:oimhost3:ssl

C.3.2.10 SOAのスケール・アップ・コマンド

- SOAの新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name soa3:oimhost3 -fqdn oimhost3.mycompany.com -port 8001 -secure false -virtual false

- SSL:

topotool.sh add -host -name soa3:oimhost3:ssl -fqdn oimhost3.mycompany.com -port 8002 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name soa3 -description "soa3 local configuration home" -path "/u02/private/oracle/config/domains/IAMGovernanceDomain" -shared false

- 共有構成:

topotool.sh add -confighome -name soa3 -description "soa3 shared configuration home" -path " /u01/oracle/config/domains/IAMGovernanceDomain"-shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename oimhost3.mycompany.com -name soa3 -description "soa3 " -type WLS_MANAGED -tier IDM -mwhomename Identity::IGD_MW_HOME -hometype SOA -confighomename soa3 -dbname OIM:DB -domainname   IAMGovernanceDomain -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename soa3 -type WLS_MANAGED_SOA -hosts soa3:oimhost3,soa3:oimhost3:ssl

topotool.sh add -component -instancename soa3 -type DEFAULT -hosts soa3:oimhost3,soa3:oimhost3:ssl

C.3.2.11 OAM/OIM/SOAのスケール・アウトのみのためのノード・マネージャの追加手順

1. ノード・マネージャが非SSLポートでリスニングしている場合には、非SSLホストを追加します。

2. ノード・マネージャがSSLポートでリスニングしている場合には、SSLホストを追加します。

3. 構成ホームを追加します。共有構成であるかローカル構成であるかに基づいて、共有をtrueまたはfalseに設定します。

4. 既存のMiddlewareホームを使用して、WLS_NODE_MANAGERタイプ、IDM層、IAMホーム・タイプのインスタンスを追加します。

5. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたDEFAULTタイプのインスタンス用のコンポーネントを追加します。

6. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたWLS_NODE_MANAGERタイプのインスタンス用のコンポーネントを追加します。

C.3.2.12 OAMのスケール・アウトのためのノード・マネージャ追加コマンド

- ノード・マネージャOAMの新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name NodeManager:oamhost3 -fqdn oamhost3.mycompany.com -port 5556 -secure false -virtual false

- SSL:

topotool.sh add -host -name NodeManager:oamhost3:ssl -fqdn oamhost3.mycompany.com -port 5556 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name NodeManager:Access -description "node manager local configuration home" -path "/u01/oracle/config/nodemanager/oamhost3.mycompany.com" -shared false

- 共有構成:

topotool.sh add -confighome -name NodeManager:Access -description " node manager shared configuration home " -path "/u01/oracle/config/nodemanager/oamhost3.mycompany.com" -shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename oamhost3.mycompany.com -name NodeManager:Access -description "node manager  instance" -type WLS_NODE_MANAGER -tier IDM -mwhomename Access:IAD_MW_HOME -hometype IAM -confighomename NodeManager:Access  -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename NodeManager:Access -type DEFAULT -hosts NodeManager:oamhost3, NodeManager:oamhost3:ssl

C.3.2.13 OIMのスケール・アウトのためのノード・マネージャ追加コマンド

- ノード・マネージャOIMの新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name NodeManager:oimhost3 -fqdn oimhost3.mycompany.com -port 5556-secure false -virtual false

- SSL:

topotool.sh add -host -name NodeManager:oimhost3:ssl -fqdn oimhost3.mycompany.com -port 5556 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name NodeManager:Identity -description "node manager local configuration home" -path "/u01/oracle/config/nodemanager/oimhost3.mycompany.com" -shared false

- 共有構成:

topotool.sh add -confighome -name NodeManager:Identity -description " node manager shared configuration home " -path "/u01/oracle/config/nodemanager/oimhost3.mycompany.com" -shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename oimhost3.mycompany.com -name NodeManager:Identity -description "node manager  instance" -type WLS_NODE_MANAGER -tier IDM -mwhomename Identity::IGD_MW_HOME -hometype IAM -confighomename NodeManager:Identity  -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename NodeManager:Identity -type DEFAULT -hosts NodeManager:oimhost3, NodeManager:oimhost3:ssl

C.3.2.14 SOAのスケール・アウトのためのノード・マネージャ追加コマンド

- ノード・マネージャSOAの新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name NodeManager:oimhost3 -fqdn oimhost3.mycompany.com -port 5556-secure false -virtual false

- SSL:

topotool.sh add -host -name NodeManager:oimhost3:ssl -fqdn oimhost3.mycompany.com -port 5556 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name NodeManager:Identity -description "node manager local configuration home" -path "/u01/oracle/config/nodemanager/oimhost3.mycompany.com" -shared false

- 共有構成:

topotool.sh add -confighome -name NodeManager:Identity -description " node manager shared configuration home " -path "/u01/oracle/config/nodemanager/oimhost3.mycompany.com" -shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename oimhost3.mycompany.com -name NodeManager:Identity -description "node manager  instance" -type WLS_NODE_MANAGER -tier IDM -mwhomename Identity::IGD_MW_HOME -hometype IAM -confighomename NodeManager:Identity  -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename NodeManager:Identity -type DEFAULT -hosts NodeManager:oimhost3, NodeManager:oimhost3:ssl

C.3.3 Web層のスケール・アウト/スケール・アップ

以降の項では、Web層のスケーリングについて説明します。

- 第C.3.3.1項「Web層に関する注意」

- 第C.3.3.2項「OHSをスケーリングするためのトポロジ・ツールの手順」

- 第C.3.3.3項「Webのスケール・アウト・コマンド」

- 第C.3.3.4項「OHSのスケール・アップ・コマンド」

- 第C.3.3.5項「Web層のスケール・アップおよびスケール・アウトのためのOPMNの追加手順」

- 第C.3.3.6項「Web層のスケール・アップおよびスケール・アウトのためのOPMNインスタンスの追加コマンド」

C.3.3.1 Web層に関する注意

- スケール・アップおよびスケール・アウトがサポートされています。

- Oracleバイナリは共有されません。ローカルになります。

- configディレクトリはマウントされません。

- ロード・バランサを再構成してください。

C.3.3.2 OHSをスケーリングするためのトポロジ・ツールの手順

1. sharedlcmconfigaccessibleをfalseに設定してマシンを追加します。(スケール・アウトのみ)。

2. OHSが非SSLポートでリスニングしている場合には、非SSLホストを追加します。

3. OHSがSSLポートでリスニングしている場合には、SSLホストを追加します。

4. 共有セットをfalseとして新しいMiddlewareホームを追加します。(スケール・アウトのみ)

5. 新しいOracleホームを追加します。(スケール・アウトのみ)

6. 構成ホームを追加します。共有構成であるかローカル構成であるかに基づいて、共有をtrueまたはfalseに設定します。

7. 新しく作成されたMiddlewareホームを使用して、またはスケール・アップの場合は既存のMiddlewareホームを使用して、OHS_HTTPDタイプ、WEB層、WEBTIERホーム・タイプのインスタンスを追加します。

8. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたDEFAULTタイプのインスタンス用のコンポーネントを追加します。

9. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたOHS_WEBGATEタイプのインスタンス用のコンポーネントを追加します。

10. 新しく作成された非SSLまたはSSLホストで、SSO、IDMINTERNAL、OIMADMIN、OAMADMINのロード・バランサのマッピングを更新します。

C.3.3.3 Webのスケール・アウト・コマンド

- 新しいマシンの追加

topotool.sh add -machine -name webhost3.mycompany.com -description "ohs3 machine" -sharedlcmconfigaccessible false

- 新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name ohs3:webhost3 -fqdn webhost3.mycompany.com -port 7777 -secure false -virtual false

- SSL:

topotool.sh add -host -name ohs3:webhost3:ssl -fqdn webhost3.mycompany.com -port 7778 -secure true -virtual false

- 新しいMWホームの追加

topotool.sh add -mwhome -name Webtier:WEB_MW_HOME -path /u01/oracle/idmtop/products/ohs/ -shared false

- 新しいOracleホームの追加

topotool.sh add -home -mwhomename Webtier:WEB_MW_HOME -type ORACLE_COMMON -path /u01/oracle/idmtop/products/ohs/oracle_common

topotool.sh add -home -mwhomename Webtier:WEB_MW_HOME -type WEBTIER -path /u01/oracle/idmtop/products/ohs/ohs

topotool.sh add -home -mwhomename Webtier:WEB_MW_HOME -type OAM_WG -path /u01/oracle/idmtop/products/ohs/webgate

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name ohs3 -description "ohs3 local configuration home" -path " /u02/private/oracle/config/instances/ohs1 " -shared false

- 共有構成:

topotool.sh add -confighome -name ohs3 -description "ohs3 shared configuration home" -path " /u02/private/oracle/config/instances/ohs3" -shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename webhost3.mycompany.com -name ohs3 -description "ohs3 instance" -type OHS_HTTPD -tier WEB -mwhomename Webtier:WEB_MW_HOME -hometype WEBTIER -confighomename ohs3 -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename ohs3 -type OHS_WEBGATE -hosts ohs3:webhost3,ohs3:webhost3:ssl -clienthosts oam3:slc03oap3

topotool.sh add -component -instancename ohs3 -type DEFAULT -hosts ohs3:webhost3,ohs3:webhost3:ssl

- ロード・バランサ・マッピングへの新しいホストの追加

- sso LBRマッピングへの追加

topotool.sh modify -lbrmapping -lbrname LBR1 -name -physicalhosts ohs3:webhost3,ohs3:webhost3:ssl

- idminternal LBRマッピングへの追加

topotool.sh modify -lbrmapping -lbrname LBR1 -name idminternal -physicalhosts ohs3:webhost3,ohs3:webhost3:ssl

- oimadmin LBRマッピングへの追加

topotool.sh modify -lbrmapping -lbrname LBR1 -name oimadmin -physicalhosts ohs3:webhost3,ohs3:webhost3:ssl

- oamadmin LBRマッピングへの追加

topotool.sh modify -lbrmapping -lbrname LBR1 -name oamadmin -physicalhosts ohs3:webhost3,ohs3:webhost3:ssl

C.3.3.4 OHSのスケール・アップ・コマンド

- 新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name ohs3:webhost3 -fqdn webhost3.mycompany.com -port 7777 -secure false -virtual false

- SSL:

topotool.sh add -host -name ohs3:webhost3:ssl -fqdn webhost3.mycompany.com -port 7778 -secure true -virtual false

- 新しい構成ホームの追加

- ローカル構成:

topotool.sh add -confighome -name ohs3 -description "ohs3 local configuration home" -path " /u02/private/oracle/config/instances/ohs1 " -shared false

- 共有構成:

topotool.sh add -confighome -name ohs3 -description "ohs3 shared configuration home" -path " /u02/private/oracle/config/instances/ohs3" -shared true

- 新しいインスタンスの追加

topotool.sh add -instance -machinename webhost3.mycompany.com -name ohs3 -description "ohs3" -type OHS_HTTPD -tier WEB -mwhomename Webtier:MW_HOME -hometype WEBTIER -confighomename ohs3 -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename ohs3 -type OHS_WEBGATE -hosts ohs3:webhost3,ohs3:webhost3:ssl -clienthosts oam3:slc03oap3

topotool.sh add -component -instancename ohs3 -type DEFAULT -hosts ohs3:webhost3,ohs3:webhost3:ssl

- ロード・バランサ・マッピングへの新しいホストの追加

- sso LBRマッピングへの追加

topotool.sh modify -lbrmapping -lbrname LBR1 -name sso  -physicalhosts ohs3:webhost3,ohs3:webhost3:ssl

- idminternal LBRマッピングへの追加

topotool.sh modify -lbrmapping -lbrname LBR1 -name idminternal -physicalhosts ohs3:webhost3,ohs3:webhost3:ssl

- oimadmin LBRマッピングへの追加

topotool.sh modify -lbrmapping -lbrname LBR1 -name oimadmin -physicalhosts ohs3:webhost3,ohs3:webhost3:ssl

- oamadmin LBRマッピングへの追加

topotool.sh modify -lbrmapping -lbrname LBR1 -name oamadmin -physicalhosts ohs3:webhost3,ohs3:webhost3:ssl

C.3.3.5 Web層のスケール・アップおよびスケール・アウトのためのOPMNの追加手順

1. OPMNが非SSLポートでリスニングしている場合には、非SSLホストを追加します。

2. OPMNがSSLポートでリスニングしている場合には、SSLホストを追加します。

3. 構成ホームを追加します。共有構成であるかローカル構成であるかに基づいて、共有をtrueまたはfalseに設定します。

4. 既存のWeb層Middlewareホームを使用して、OPMNタイプ、WEB層、WEBTIERホーム・タイプのインスタンスを追加します。

5. 新しく作成された非SSLまたはSSLホストを使用して新しく作成されたDEFAULTタイプのインスタンス用のコンポーネントを追加します。

C.3.3.6 Web層のスケール・アップおよびスケール・アウトのためのOPMNインスタンスの追加コマンド

- 新しいホストの追加(ホスト名+ポートの組合せ)

- 非SSL:

topotool.sh add -host -name OPMN:ohs3 -fqdn webhost3.mycompany.com -port 6700 -secure false -virtual false

- SSL:

topotool.sh add -host -name OPMN:webhost3:ssl -fqdn webhost3.mycompany.com -port 6701 -secure true -virtual false

- 新しいインスタンスの追加

topotool.sh add -instance -machinename webhost3.mycompany.com -name OPMN:ohs3 -description "opmn for ohs third instance" -type OPMN -tier WEB -mwhomename Webtier:MW_HOME -hometype WEBTIER -confighomename ohs3 -instancegroup 1

- 新しいコンポーネントの追加

topotool.sh add -component -instancename OPMN:ohs3 -type DEFAULT -hosts OPMN:webhost3, OPMN:webhost3:ssl

オラクル社の法律上の注意点について

コピーライトについて

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。