ヘッダーをスキップ
Oracle® Fusion Middleware高可用性ガイド
11g リリース2(11.1.2)
B69538-03
  目次へ移動
目次
前
前 		 次
次		  

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

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

Oracle Identity and Access Management 11gリリース2 (11.1.2)には次のコンポーネントが含まれており、この章で説明します。

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

第8章「Identity Managementコンポーネントの高可用性の構成」では、11gリリース2にアップデートしていない、使用可能な11gリリース1のIdentity Managementコンポーネントについて説明しています。これらのコンポーネントには、次のものが含まれます。

9.1 Oracle Identity Managerの高可用性

この項では、Oracle Identity Managerの概要およびOracle Identity Managerの高可用性環境の設計とデプロイについて説明します。

Oracle Identity Managerは、アプリケーションおよびディレクトリからユーザー・アカウントを追加、更新および削除するプロセスを自動化するユーザー・プロビジョニングおよび管理ソリューションです。また、誰が何にアクセスしたかを示すきめ細かいレポートを提供することで、法規制コンプライアンスの向上にも寄与します。Oracle Identity Managerは、スタンドアロン製品として、またはOracle Identity and Access Management Suiteの一部として使用可能です。

ユーザー・アイデンティティのプロビジョニングを自動化すると、ITの管理コストを削減し、セキュリティを高めることができます。プロビジョニングは、法規制コンプライアンスにおいても重要な役割を果たします。Oracle Identity Managerの主要機能には、パスワード管理、ワークフローとポリシーの管理、アイデンティティ調整、レポートと監査、アダプタによる拡張性などがあります。

Oracle Identity Managerの機能は、次のとおりです。

Oracle Identity Managerの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドを参照してください。

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

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

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

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

図9-1の説明が続きます
「図9-1 Oracle Identity Managerコンポーネント・アーキテクチャ」の説明

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

Oracle Identity Manager Serverは、Java EE標準に準拠した、スタンドアロンの自己完結型アイデンティティ管理ソリューションです。ユーザー管理、ワークフローおよびポリシー、パスワード管理、監査およびコンプライアンス管理、ユーザー・プロビジョニング、および組織およびロール管理機能を提供します。

Oracle Identity Managerは、標準Java EEアプリケーションであり、Oracle WebLogic Server上にデプロイされ、データベースを使用してランタイムおよび構成データを格納します。MDSスキーマには構成情報が含まれ、OIMスキーマにはランタイムおよびユーザー情報が格納されます。

Oracle Identity Managerは、RMIを使用してSOA管理対象サーバーに接続し、SOA EJBを呼び出します。

Oracle Identity Managerは、Oracle SOA Suiteのヒューマン・ワークフロー・モジュールを使用して、そのリクエスト・ワークフローを管理します。Oracle Identity Managerは、SOA用のフロントエンドURLであるSOAサーバーのT3 URLを使用してSOAに接続します。クラスタ化されたSOAサーバーでは、ロード・バランサまたはWebサーバーのURLを使用することをお薦めします。ワークフローが完了すると、SOAはOIMFrontEndURLを使用してOracle Identity Manager Webサービスをコールバックします。Oracle SOAは、Oracle Identity Managerとともにデプロイされます。

いくつかのOracle Identity ManagerモジュールはJMSキューを使用します。各キューは、個別のメッセージドリブンBean(MDB)によって処理されます。MDBもOracle Identity Managerアプリケーションの一部です。メッセージ・プロデューサもOracle Identity Managerアプリケーションの一部です。

Oracle Identity Managerは、埋込みOracle Entitlements Serverを使用しますが、これもOracle Identity Managerエンジンの一部です。Oracle Entitlements Server(OES)は、Oracle Identity Manager内部で認可の確認に使用されます。たとえば、ポリシー制約の1つで、特定のロールを持つユーザーのみがユーザーの作成を許可されると決定されているとします。これは、Oracle Identity Managerユーザー・インタフェースを使用して定義します。

Oracle Identity Managerは、スケジュール済アクティビティのためにクォーツ・ベースのスケジューラを使用します。バックグラウンドで実行される様々なスケジュール済アクティビティがあります。たとえば、スケジュール済タスクの1つは、ユーザーの終了日後にそのユーザーを無効化することです。

Oracle Identity Managerは、すべてのレポート作成機能のためにOracle BI Publisherと連携します。BI Publisherは、異なるドメインまたは同じドメインに配置され、単純な静的なURL統合のみで統合されます。BI PublisherとOracle Identity Managerランタイム・コンポーネントとの間に相互作用はありません。BI Publisherは、レポート作成のために同じOIMデータベース・スキーマを使用するように構成されます。

LDAPSyncが外部ディレクトリ・サーバー(Oracle Internet Directory、ODSEE、Microsoft Active Directoryなど)と直接通信できるようにすると、高可用性とフェイルオーバー機能をサポートするためにIdentity Virtualization Library (libOVD)の構成が必要になります。

libOVDを構成するには、WLSTコマンドのaddLDAPHostを使用します。libOVDを管理する場合は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のIdentity Virtualization Library (libOVD)アダプタの管理に関する説明でWLSTコマンドのリストを参照してください。

9.1.1.2 ランタイム・プロセス

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

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

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

Oracle Identity Managerは、外部的に管理されるアプリケーションとしてOracle WebLogic Serverにデプロイされます。WebLogic Serverはデフォルトで、Oracle Identity Managerアプリケーションに対する他のライフサイクル・イベントの起動、停止、監視および管理を行います。

Oracle Identity Managerは、標準Java EEアプリケーションであり、アプリケーション・サーバー・コンポーネントが起動した後に起動します。また、Oracle Identity Managerでは、Oracle Identity Managerコンポーネント・メカニズムの一部である認証システムも使用され、それはWebLogic JNDIが初期化されてアプリケーションが起動する前に起動されます。これは、OIM ORACLE_HOMEからロードされます。

Oracle Identity Managerでは、クォーツ・ベースのスケジューラが使用されます。クォーツは、すべてのWebLogic Serverインスタンスでスケジューラ・スレッドを起動します。データベースが、スケジュール済アクティビティの選択と実行のための中央記憶域として使用されます。スケジューラ・インスタンスの1つがジョブを選択した場合、その他のインスタンスがその同じジョブを選択することはありません。

Oracle Identity Managerは、データベースから、サーバー・インスタンスのメモリー内のキャッシュに特定のシステム構成値をキャッシュします。これらのキャッシュは独立してロードされ、サーバー間で共有されません。システム構成が変更されるとキャッシュがクリーンアップされ、これはクラスタ内のすべてのサーバーに通知されます。Oracle Identity Managerは、この目的のためにOSCache、JGroupsを使用します。JGroupsはマルチキャスト・アドレスを使用します。有効なマルチキャスト・アドレスは、インストール中にランダムに生成され、Oracle Identity Managerメタデータ・リポジトリ・ファイルにシードされます。

WebLogicノード・マネージャは、サーバー・プロセスを監視し、障害発生時にそのプロセスを再起動するように構成できます。

Oracle Enterprise Manager Fusion Middleware Controlは、アプリケーションの監視および構成の変更に使用します。

9.1.1.4 Oracle Identity Managerの起動と停止

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

  • Oracle WebLogic Scripting Tool(WLST)

  • WebLogic Server管理コンソール

  • Oracle Enterprise Manager Fusion Middleware Control

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

9.1.1.5 構成アーティファクト

Oracle Identity Managerサーバーの構成は、MDSリポジトリに格納され、MBeanを使用して管理されます。oim-config.xmlファイルがメイン構成ファイルです。OIM構成は、Oracle Enterprise Manager Fusion Middleware ControlまたはコマンドラインMDSユーティリティを介してMBeanブラウザを使用して管理します。oim-config.xmlファイルは、MDSリポジトリの/db/oim-config.xmlの場所に格納されています。

MDSユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のMDSユーティリティに関する説明を参照してください。

JMSは、インストーラによってすぐに使用可能な状態に構成されます。JMSキュー、接続プール、データ・ソースなど必要なものはすべて、WebLogicアプリケーション・サーバー上に構成されます。次のキューが、Oracle Identity Managerをデプロイするときに作成されます。

  • oimAttestationQueue

  • oimAuditQueue

  • oimDefaultQueue

  • oimKernelQueue

  • oimProcessQueue

  • oimReconQueue

  • oimSODQueue

Design ConsoleおよびRemote Managerの構成は、xlconfig.xmlに格納されます。

9.1.1.6 外部依存性

Oracle Identity Managerは、Oracle WebLogic管理対象サーバーにデプロイされるJava EEアプリケーションです。Oracle Identity Managerは、Oracle SOA Suiteのワークリストおよびヒューマン・ワークフロー・モジュールを使用して、そのリクエスト・フローを管理します。Oracle Identity Managerは、外部リポジトリと対話して、構成およびランタイム・データを格納します。Oracle Identity Managerでは、初期化およびランタイム時に、これらのリポジトリが使用可能である必要があります。Oracle Identity Managerの資格証明はすべて、OIMリポジトリに格納されます。Oracle Identity Managerサーバーの機能に必要な外部コンポーネントは次のとおりです。

  • WebLogic Server

    • 管理サーバー

    • 管理対象サーバー

  • データ・リポジトリ

    • 構成リポジトリ(MDSスキーマ)

    • ランタイム・リポジトリ(OIMスキーマ)

    • ユーザー・リポジトリ(OIMスキーマ)

    • SOAリポジトリ(SOAスキーマ)

  • 外部LDAPストア(LDAP同期を使用する場合)

  • BI Publisher

Design Consoleは、管理者が、開発とカスタマイズのために使用するツールです。Design Consoleは、Oracle Identity Managerエンジンと直接通信し、Oracle Identity Managerサーバーが依存するものと同じコンポーネントに依存します。

Remote Managerは、オプションの独立したスタンドアロン・アプリケーションであり、ローカル・システムのカスタムAPIを呼び出します。そのため、それらのカスタムAPIのJARファイルがそのクラスパスに含まれている必要があります。

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

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

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

DOMAIN_HOME/servers/serverName/logs

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

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

9.1.2 Oracle Identity Managerの高可用性の概要

この項では、Oracle Identity Managementの高可用性の概要およびOracle Identity Managerの高可用性環境の設計とデプロイについて説明します。


注意:

Oracle Identity Managerを高可用性構成にデプロイする場合は、次のことに注意してください。

  • Oracle Identity ManagerはOracle RACデータベースにデプロイできますが、Oracle RACのフェイルオーバーは、このリリースではOracle Identity Managerに対して透過的ではありません。Oracle RACのフェイルオーバーが発生すると、エンド・ユーザーは、各自のリクエストを再送信する必要がある場合があります。

  • Oracle Identity Managerは常に、SOAクラスタ内で少なくとも1つのノードが使用可能であることを必要とします。SOAクラスタが使用可能でない場合、エンド・ユーザーのリクエストは失敗します。Oracle Identity Managerノードは、失敗したSOA呼出しに対して再試行しません。そのため、SOA呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。

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

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

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

図9-2の説明が続きます
「図9-2 Oracle Identity Managerの高可用性アーキテクチャ」の説明

OIMHOST1では、次のインストールが実行されています。

  • Oracle Identity ManagerインスタンスはWLS_OIM1管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA1管理対象サーバーにインストールされています。

  • Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

  • WebLogic管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。

OIMHOST2では、次のインストールが実行されています。

  • Oracle Identity ManagerインスタンスはWLS_OIM2管理対象サーバーにインストールされており、SOAインスタンスはWLS_SOA2管理対象サーバーにインストールされています。

  • Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。

  • OIMHOST1およびOIMHOST2上のWLS_OIM1およびWLS_OIM2管理対象サーバーのインスタンスは、OIM_Clusterクラスタとして構成されています。

  • OIMHOST1およびOIMHOST2上のWLS_SOA1およびWLS_SOA2管理対象サーバーのインスタンスは、SOA_Clusterクラスタとして構成されています。

  • WebLogic管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OIMHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。

図9-2のOracle Identity Managerの高可用性構成では、次の仮想ホスト名が使用されています。

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

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

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

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

  • VHNは、Oracle Real Application Clusters(Oracle RAC)データベース・ホストの仮想IPアドレスを指します。

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

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

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

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

  • WebLogic Server管理コンソール

  • Oracle Enterprise Manager Fusion Middleware Control

  • Oracle WebLogic Scripting Tool(WLST)

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

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

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

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

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

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

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

この項には、高可用性を得るためのOracle Identity Managementの構成に関する次の項目があります。

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

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

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

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

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

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

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


    注意:

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

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

    Oracle Internet Directoryのインストールと構成の詳細は、第8.3.3項「Oracle Internet Directoryの高可用性の構成手順」を参照してください。Oracle Virtual Directoryのインストールと構成の詳細は、第8.4.3項「Oracle Virtual Directoryの高可用性の構成手順」を参照してください。Oracle Identity Managerは、Oracle Internet Directoryと直接通信しないことに注意してください。それは、Oracle Virtual Directoryと通信し、Oracle Virtual DirectoryがOracle Internet Directoryと通信します。

  • wlfullclient.jarファイルを、OIMHOST1およびOIMHOST2で作成します。

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

    wlfullclient.jarファイルを作成するには、次の手順を実行します。

    1. MW_HOME/wlserver_10.3/server/libディレクトリに移動します。

    2. JAVA_HOMEをMW_HOME/jdk160_18に設定し、JAVA_HOME/binディレクトリがパスに含まれていることを確認します。

    3. 次のファイルを実行することによって、wlfullclient.jarファイルを作成します。

      java -jar wljarbuilder.jar

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

OIMHOST1およびOIMHOST2にOracle Identity ManagerおよびSOAインスタンスをインストールする前に、リポジトリ作成ユーティリティ(RCU)を使用して、Oracle Identity Managerで使用するスキーマのコレクションを作成しておく必要があります。

RCUは、Oracle Fusion Middleware 11gキットの部品として付属する専用のCDに収録されています。

RCUを実行し、Oracle RACデータベース・リポジトリにOracle Identity Managerスキーマを作成するには、次の手順を実行します。

  1. 次のコマンドを発行します。

    prompt> RCU_HOME/bin/rcu &

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

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

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

  4. 「データベース接続の詳細」画面で、既存のデータベースの接続情報を次のように入力します。

    • データベース・タイプ: Oracle Database

    • ホスト名: データベースを実行しているコンピュータの名前。Oracle RACデータベースの場合は、VIP名またはノード名を指定します。例: OIMDBHOST1-VIPまたはOIMDBHOST2-VIP

    • ポート: データベースのポート番号。例: 1521

    • サービス名: データベースのサービス名。例: oim.mycompany.com

    • ユーザー名: SYS

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

    • ロール: SYSDBA

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

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

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

    接頭辞の新規作成: ha

    コンポーネント:

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

      • Oracle Identity Manager - OIM

      • Oracle Platform Security Services - OPSS

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

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

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

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

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

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

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

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

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

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

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

9.1.3.1.2 Oracle WebLogic Serverのインストール

WebLogic Serverをインストールする前に、お使いのマシンが、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』に指定されているシステム、パッチ、カーネルなどの要件を満たしていることを確認します。

インストーラを起動し、OIMHOST1およびOIMHOST2で次の手順を実行します。

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

  2. 「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。

    「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。

    ORACLE_BASE/product/fmw


    注意:

    ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。推奨値は/u01/app/oracleです。

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

  3. セキュリティ・アップデートが通知されるようにするために、「セキュリティ更新のための登録」画面で連絡先情報を入力します。

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

  4. 「インストール・タイプの選択」画面で、「カスタム」を選択します。

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

  5. 「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。

  6. 「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。

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

  7. 「インストールの概要」画面で「次へ」をクリックします。

  8. 「インストール完了」画面で、「Quickstartの実行」の選択を解除します。

    「完了」をクリックします。

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

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

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

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

HOST1> runInstaller

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

次のように実行します。

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

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

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

    • Oracle Middlewareホーム: MW_HOMEのリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。

      /u01/app/oracle/product/fmw

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

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

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

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

    プロンプトが表示されたら、LinuxおよびUNIXインストールでは、rootユーザーとして、スクリプトoracleRoot.shを実行します。

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

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

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

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

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

HOST1> runInstaller

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

次のように実行します。

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

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

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

    • Oracle Middlewareホーム: MW_HOMEのリストから前にインストールしたMiddlewareホームを選択します。次に例を示します。

      /u01/app/oracle/product/fmw

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

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

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

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

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

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

OIMHOST1にドメインを作成するには、次の手順を実行します。

  1. このコマンドを実行して、構成ウィザードを起動します。

    MW_HOME/oracle_common/common/bin/config.sh

  2. 「ようこそ」画面で、「WebLogicドメインの作成」を選択します。

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

  3. 「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。

    リストから、次のように選択します。

    • Oracle Identity Manager

      Oracle SOA Suite、Oracle Enterprise Manager、Oracle Platform Security Service、Oracle JRF、Oracle JRF WebServices AsynchronousサービスおよびOracle WSM Policy Managerが自動的に選択されます。

    • Oracle Enterprise Manager

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

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

    次の項目を入力します。

    • ドメイン名: IDMDomain

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

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

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

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

    • 名前: weblogic

    • User Password: weblogicユーザーのパスワードを入力します。

    • Confirm User Password: weblogicユーザーのパスワードを入力します。

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

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

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

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

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

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

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

    • OIM MDSスキーマ

    • OWSM MDSスキーマ

    • SOA MDSスキーマ

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

    • OPSSスキーマ

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


    注意:

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

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

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

    • サービス名: oim.mycompany.com

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

      • ホスト名: OIMDBHOST1-VIP.mycompany.com

      • インスタンス名: oimdb1

      • ポート: 1521

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

      • ホスト名: OIMDBHOST2-VIP.mycompany.com

      • インスタンス名: oimdb2

      • ポート: 1521

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

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

    スキーマ名 スキーマ所有者 パスワード

    SOAインフラストラクチャ

    HA_SOAINFRA

    <パスワードを入力>

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

    HA_ORASDPM

    <パスワードを入力>

    OIM MDSスキーマ

    HA_MDS

    <パスワードを入力>

    OWSM MDSスキーマ

    HA_MDS

    <パスワードを入力>

    SOA MDSスキーマ

    HA_MDS

    <パスワードを入力>

    OIMスキーマ

    HA_OIM

    <パスワードを入力>

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

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

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

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

    • 管理サーバー

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

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

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

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

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

    • 名前: AdminServer

    • Listen address: oimhost1.mycompany.com

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

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

    • SSL有効: 選択を解除

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

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

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

    JMSシステム・リソース 共通/重み設定された分散宛先

    UMSJMSSystemResource

    UDD

    SOAJMSModule

    UDD

    OIMJMSModule

    UDD

    BPMJMSModule

    UDD

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

    「オーバーライドの警告」ボックスに次のメッセージが表示されます。

    「CFGFWK-40915: 共通分散宛先(UDD)への変換対象として少なくとも1つのJMSシステム・リソースが選択されています。この変換は、JMSシステム・リソースがクラスタに割り当てられている場合にのみ行われます。」

    「警告」ボックスで「OK」をクリックします。

  13. 「管理対象サーバーの構成」画面を初めて表示した場合、構成ウィザードによって2つのデフォルト管理対象サーバー(oim_server1とsoa_server1)が作成されています。デフォルトの管理対象サーバーの詳細を変更し、2つ目の管理対象サーバーを追加します。次の手順に従います。

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

    • 名前: WLS_OIM1

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

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

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

    • 名前: WLS_SOA1

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

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

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

    • 名前: WLS_OIM2

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

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

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

    • 名前: WLS_SOA2

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

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

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


    注意:

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

  14. 「クラスタの構成」画面で、「追加」をクリックして2つのクラスタを作成します。

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

    • 名前: oim_cluster

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

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

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

    • 名前: soa_cluster

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

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

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

  15. 「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタと関連付けます。右のウィンドウでクラスタ名をクリックします。

    サーバーの下の管理対象サーバーをクリックし、矢印をクリックしてそれをクラスタに割り当てます。

    WLS_OIM1およびWLS_OIM2管理対象サーバーをoim_clusterのメンバーになるように割り当てます。

    WLS_SOA1およびWLS_SOA2管理対象サーバーをsoa_clusterのメンバーになるように割り当てます。

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

  16. 「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。

    ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。

    次の情報を指定します。

    • 名前: ホスト名です。ここでは、DNS名を使用することをお薦めします。

    • ノード・マネージャ・リスニング・アドレス: ここにマシンのDNS名を入力します。

    • ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。

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


    注意:

    UNIXでは、「マシン」タブの下のデフォルト・ローカル・マシン・エントリを削除します。

  17. 「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。

    右側のウィンドウでマシンをクリックします。

    左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。

    矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。

    すべての管理対象サーバーが適切なマシンに割り当てられるまで、この手順を繰り返します。

    一般的な例は、次のようになります。

    • Host1: Admin Server、WLS_OIM1、およびWLS_SOA1

    • Host2: WLS_OIM2およびWLS_SOA2

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

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

    名前 ディレクトリ

    UMSJMSFileStore_auto_1

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

    UMSJMSFileStore_auto_2

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

    BPMJMSServer_auto_1

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

    BPMJMSServer_auto_1

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

    BPMJMSServer_auto_2

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

    JRFWSAsyncFileStore_auto_1

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

    JRFWSAsyncFileStore_auto_2

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

    SOAJMSFileStore_auto_1

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

    SOAJMSFileStore_auto_2

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

    OIMJMSFileStore_auto_1

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

    OIMJMSFileStore_auto_2

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

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

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

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

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

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

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

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

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

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

MW_HOME/oracle_common/common/bin
9.1.3.4.2 OIMHOST1でのノード・マネージャの起動

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

MW_HOME/wlserver_10.3/server/bin
9.1.3.4.3 OIMHOST1での管理サーバーの起動

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

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

    DOMAIN_HOME/bin/startWebLogic.sh

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

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

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

    • Oracle Enterprise Manager Fusion Middleware Control:

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

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

9.1.3.5 OIMHOST1でのOracle Identity Managerの構成

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

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

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

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


注意:

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

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

  1. 「Oracle Identity Manager用のディレクトリ・スキーマの拡張」

  2. 「Oracle Identity Manager用のユーザーとグループの作成」

  3. 「Oracle Virtual Directoryでのアダプタの作成」

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

アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。

アイデンティティ・ストアを事前構成するには、OIMHOST1で次の手順を実行します。

  1. 環境変数MW_HOME、JAVA_HOMEおよびORACLE_HOMEを設定します。

    ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

  2. 次の項目を含む、プロパティ・ファイルextend.propsを作成します。

    IDSTORE_HOST : idstore.mycompany.com

    IDSTORE_PORT : 389

    IDSTORE_BINDDN: cn=orcladmin

    IDSTORE_USERNAMEATTRIBUTE: cn

    IDSTORE_LOGINATTRIBUTE: uid

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

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

    IDSTORE_SEARCHBASE: dc=mycompany,dc=com

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

    説明:

    • IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。非OIDディレクトリを使用している場合は、Oracle Virtual Directoryのホストを指定します(これは、IDSTORE.mycompany.comになるはずです)。

    • IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。

    • IDSTORE_USERSEARCHBASEは、ユーザーが格納されるディレクトリの場所です。

    • IDSTORE_GROUPSEARCHBASEは、グループが格納されるディレクトリの場所です。

    • IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。

    • IDSTORE_SYSTEMIDBASEは、メイン・ユーザー・コンテナに配置する必要のないユーザーを配置できるディレクトリにあるコンテナの場所です。このような事態はほとんどありませんが、その一例としてOracle Virtual DirectoryアダプタのバインドDNユーザーにも使用されるOracle Identity Managerリコンシリエーション・ユーザーがあげられます。

  3. idmConfigToolコマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。

    Linuxのコマンド構文:

    idmConfigTool.sh -preConfigIDStore input_file=configfile

    Windowsのコマンド構文:

    idmConfigTool.bat -preConfigIDStore input_file=configfile

    例:

    idmConfigTool.sh -preConfigIDStore input_file=extend.props

    このコマンドを実行すると、IDストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。

    次に、コマンドの出力例を示します。

    ./preconfig_id.sh 
Enter ID Store Bind DN password : 
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: 

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif
The tool has completed its operation. Details have been logged to automation.log

  4. ログ・ファイルを確認して、エラーや警告を修正します。

Oracle Identity Manager用のユーザーとグループの作成

oimadminユーザーをアイデンティティ・ストアに追加する手順を実行して、そのユーザーをOracle Identity Manager管理者グループに割り当てます。また、リコンシリエーションを実行するために、標準の場所cn=Users以外にもユーザーを作成します。Oracle Virtual Directoryを使用したディレクトリに直接接続するときには、このユーザーをバインドDNとして選択することをお薦めします。


注意:

このコマンドでは、アイデンティティ・ストアに予約用のコンテナも作成します。

xelsysadmユーザーをアイデンティティ・ストアに追加して、そのユーザーを管理グループに割り当てるには、OIMHOST1で次のタスクを実行します。

  1. 環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。

    IDM_HOMEをIDM_ORACLE_HOMEに設定します。

    ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

  2. 次の項目を含む、プロパティ・ファイルoim.propsを作成します。

    IDSTORE_HOST : idstore.mycompany.com

    IDSTORE_PORT : 389

    IDSTORE_BINDDN : cn=orcladmin

    IDSTORE_USERNAMEATTRIBUTE: cn

    IDSTORE_LOGINATTRIBUTE: uid

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

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

    IDSTORE_SEARCHBASE: dc=mycompany,dc=com

    POLICYSTORE_SHARES_IDSTORE: true

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

    IDSTORE_OIMADMINUSER: oimadmin

    IDSTORE_OIMADMINGROUP:OIMAdministrators

    

    説明:
    

      

    • 

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

      • 

    • 

      IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
      

      • 

    • 

      IDSTORE_OIMADMINUSERは、Oracle Identity Managerコンソールにログインするために使用する、管理ユーザーの名前です。
      

      • 

    • 

      IDSTORE_OIMADMINGROUPは、Oracle Identity Manager管理ユーザーを保持するために作成するグループの名前です。
      

      • 

    • 

      IDSTORE_USERSEARCHBASEは、ユーザーを配置するアイデンティティ・ストアの場所です。
      

      • 

    • 

      IDSTORE_GROUPSEARCHBASEは、グループを配置するアイデンティティ・ストアの場所です。
      

      • 

    • 

      IDSTORE_SYSTEMIDBASEは、Oracle Identity Managerリコンシリエーション・ユーザーを配置するディレクトリの場所です。
      

      • 

    • 

      POLICYSTORE_SHARES_IDSTOREは、ポリシー・ストアとアイデンティティ・ストアが同じディレクトリに存在する場合にはtrueを設定します。そうでない場合は、falseを設定します。
      

      • 

    

    3. 

  3. 

    idmConfigToolコマンドを使用してアイデンティティ・ストアを構成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
    

    Linuxコマンドの構文:
    

    idmConfigTool.sh -prepareIDStore mode=OIM input_file=configfile
    

    Windowsコマンドの構文:
    

    idmConfigTool.bat -prepareIDStore mode=OIM input_file=configfile
    

    例:
    

    idmConfigTool.sh -prepareIDStore mode=OIM input_file=oim.props

    

    

    このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。また、システムは、そのアカウントに割り当てるパスワードの入力も要求します。
    

    IDSTORE_OIMADMINUSER
oimadmin

    

    oimadminは、Oracle Identity Manager構成の一部として作成したアカウントと同じ値を設定するようにお薦めします。
    

    次に、コマンドの出力例を示します。
    

    Enter ID Store Bind DN password : 
*** Creation of oimadmin ***
Apr 5, 2011 4:58:51 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_user_template.ldif
Enter User Password for oimadmin: 
Confirm User Password for oimadmin: 
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_template.ldif
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_member_template.ldif
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_groups_acl_template.ldif
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_reserve_template.ldif
*** Creation of Xel Sys Admin User ***
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_user_template.ldif
Enter User Password for xelsysadm: 
Confirm User Password for xelsysadm: 
The tool has completed its operation. Details have been logged to /home/oracle/idmtools/oim.log

    

    4. 

  4. 

    ログ・ファイルを確認して、エラーや警告を修正します。
    

    5. 




Oracle Virtual Directoryでのアダプタの作成


Oracle Identity Managerは、Oracle Virtual Directoryを使用して外部LDAPストアに接続します。Oracle Identity ManagerがOracle Internet Directoryなどの外部LDAPストアに接続できるようにするには、ユーザー・アダプタと変更ログ・アダプタをOracle Virtual Directoryに作成する必要があります。次の手順に従って、アダプタを作成します。













注意:


Oracle Internet Directoryのみを実装する場合は、Oracle Virtual Directoryにアダプタを作成する必要はありません。












ユーザー・アダプタ


OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれにユーザー・アダプタを作成します。


Oracle Directory Services Managerを使用して、Oracle Virtual Directoryにユーザー・アダプタを作成する手順は次のとおりです。


    

  1. 

    ブラウザを開き、ODSMコンソール(http://admin.mycompany.com/odsm)を表示します。
    

    


    

    


    


    注意:
    

    Oracle Directory Services Managerは、図9-2には記載されていませんが、Oracle Internet DirectoryとOracle Virtual Directoryを管理するために必要です。Oracle Directory Services Managerが環境に存在している必要があります。
    
    		

    
    

    

    

    

    2. 

  2. 

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

    3. 

  3. 

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

    4. 

  4. 

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

    5. 

  5. 

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

    6. 

  6. 

    「新規アダプタ・ウィザード」で次のパラメータを指定して、新しいアダプタを作成します。
    

    


    

    


    


    注意:
    

    前にユーザー・アダプタを作成した場合は、アダプタを作成する手順をスキップし、アダプタを編集する手順に従います。
    
    		

    
    

    

    

    

    

    





    
画面
フィールド
値/手順

    
    


    


    タイプ
    
    		


    アダプタ・タイプ
    
    		


    LDAP
    
    		

    

    

    		


    アダプタ名
    
    		


    ユーザー・アダプタ
    
    		

    

    

    		


    アダプタ・テンプレート
    
    		


    User_OID
    
    		

    

    


    接続
    
    		


    DNS設定を使用
    
    		


    いいえ
    
    		

    

    

    		


    ホスト
    
    		


    oid.mycompany.com
    
    		

    

    

    		


    ポート
    
    		


    389
    
    		

    

    

    		


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


    cn=oimadmin,cn=systemids,dc=mycompany,dc=com
    
    		

    

    

    		


    プロキシ・パスワード
    
    		


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

    

    


    接続テスト
    
    		

    		


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

    

    


    ネームスペース
    
    		


    リモート・ベース
    
    		


    dc=mycompany,dc=com
    
    		

    

    

    		


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


    dc=mycompany,dc=com
    
    		

    

    


    概要
    
    		

    		


    概要に誤りがないことを確認し、「終了」をクリックします。
    
    		

    
    

    

    

    7. 

  7. 

    ユーザー・アダプタを次のように編集します。
    

      

    1. 

      OIMユーザー・アダプタを選択します。
      

      2. 

    2. 

      「プラグイン」タブをクリックします。
      

      3. 

    3. 

      「ユーザー管理」プラグインをクリックし、プラグイン表で「編集」をクリックします。プラグインの編集ウィンドウが表示されます。
      

      4. 

    4. 

      「パラメータ」表で、次のようにパラメータ値を更新します。
      

      

      




      
パラメータ
値

      
      


      


      directoryType
      
      		


      oid
      
      		

      

      


      pwdMaxFailure
      
      		


      10
      
      		

      

      


      oamEnabled
      
      		


      true
      
      		

      
      

      

      

      5. 

    5. 

      「OK」をクリックします。
      

      6. 

    6. 

      「適用」をクリックします。
      

      7. 

    

    8. 



変更ログ・アダプタ


OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンスそれぞれに変更ログ・アダプタを作成します。次の手順に従い、Oracle Directory Services Managerを使用してOracle Virtual Directoryに変更ログ・アダプタを作成します。


    

  1. 

    ブラウザを開き、ODSMコンソール(http://admin.mycompany.com/odsm)を表示します。
    

    2. 

  2. 

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

    3. 

  3. 

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

    4. 

  4. 

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

    5. 

  5. 

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

    6. 

  6. 

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

    

    





    
画面
フィールド
値/手順

    
    


    


    タイプ
    
    		


    アダプタ・タイプ
    
    		


    LDAP
    
    		

    

    

    		


    アダプタ名
    
    		


    OIM変更ログ・アダプタ
    
    		

    

    

    		


    アダプタ・テンプレート
    
    		


    Changelog_OID
    
    		

    

    


    接続
    
    		


    DNS設定を使用
    
    		


    いいえ
    
    		

    

    

    		


    ホスト
    
    		


    oid.mycompany.com
    
    		

    

    

    		


    ポート
    
    		


    389
    
    		

    

    

    		


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


    cn=oimadmin,cn=systemids,dc=mycompany,dc=com
    
    		

    

    

    		


    プロキシ・パスワード
    
    		


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

    

    


    接続テスト
    
    		

    		


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

    

    


    ネームスペース
    
    		


    リモート・ベース
    
    		


    cn=changelog
    
    		

    

    


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

    		


    cn=changelog
    
    		

    

    


    概要
    
    		

    		


    概要に間違いがないことを確認してから、「終了」をクリックします。
    
    		

    
    

    

    

    7. 

  7. 

    変更アダプタを編集する手順は、次のとおりです。
    

      

    1. 

      OIM変更ログ・アダプタを選択します。
      

      2. 

    2. 

      「プラグイン」タブをクリックします。
      

      3. 

    3. 

      「デプロイ済プラグイン」表で、「変更ログ」プラグインをクリックしてから、「編集」をプラグイン表でクリックします。プラグインの編集ウィンドウが表示されます。
      

      4. 

    4. 

      「パラメータ」表で、パラメータ値を更新します。
      

      5. 

    5. 

      「OK」をクリックします。
      

      6. 

    6. 

      「適用」をクリックします。
      

      7. 

    

    変更ログ・アダプタを編集してプロパティを追加または変更し、それらが次の表に示す値に一致するようにします。mapObjectclass、modifierDNFilter、sizeLimit、およびtargetDNFilterプロパティをアダプタに追加する必要があります。
    

    

    




    
パラメータ
値

    
    


    


    directoryType
    
    		


    oid
    
    		

    

    


    mapAttribute
    
    		


    targetGUID=orclguid
    
    		

    

    


    requiredAttribute
    
    		


    orclguid
    
    		

    

    


    modifierDNFilter
    
    		


    cn=oimadmin,cn=systemids,dc=mycompany,dc=com
    
    		

    

    


    sizeLimit
    
    		


    1000
    
    		

    

    


    targetDNFilter
    
    		


    dc=mycompany,dc=com
    

    調整が必要な検索ベース。この値は、OIMのインストール時に指定したLDAP SearchDNと同一である必要があります。
    
    		

    

    


    mapUserState
    
    		


    true
    
    		

    

    


    oamEnabled
    
    		


    true
    
    		

    
    

    

    

    8. 



Oracle Internet DirectoryとOracle Virtual Directoryの起動と停止


次のインスタンスを起動および停止します。


    

  • 

    OVDHOST1とOVDHOST2上で実行されているOracle Virtual Directoryインスタンス。
    

    • 

  • 

    OIDHOST1とOIDHOST2上で実行されているOracle Internet Directoryインスタンス。
    

    • 



手順は、第8.7項「コンポーネントの起動と停止」を参照してください。








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


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


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


    

  • 

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

    • 

  • 

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

    • 

  • 

    wls_soa1が実行中であること。
    

    • 

  • 

    環境変数DOMAIN_HOMEおよびWL_HOMEが現在のシェル内で設定されていないこと。
    

    • 



Oracle Identity Managementの構成ウィザードは、Identity ManagementのOracleホームの下にあります。次のように入力します。


IAM_ORACLE_HOME/bin/config.sh


次の手順を実行します。


    

  1. 

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

    2. 

  2. 

    構成するコンポーネント画面で、OIMサーバーを選択します。トポロジに必要な場合は、OIM Remote Managerを選択します。
    

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

    3. 

  3. 

    「データベース」画面で、次の値を入力します。
    

      

    • 

      接続文字列: OIMデータベースの接続文字列。例:
      

      oimdbhost1-vip.mycompany.com:1521:oimdb1^oimdbhost2-vip.mycompany.com:1521:oimdb2@oim.mycompany.com
      

      • 

    • 

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

      • 

    • 

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

      • 

    • 

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

      • 

    • 

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

      • 

    

    「次へ」を選択します。
    

    4. 

  4. 

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

      

    • 

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

      • 

    • 

      ユーザー名: weblogic
      

      • 

    • 

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

      • 

    

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

    5. 

  5. 

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

      

    • 

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

      • 

    • 

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

      • 

    • 

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

      • 

    • 

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

      • 

    

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

    6. 

  6. 

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

    LDAP同期の有効化を選択します。
    

    


    

    


    


    注意:
    

    		

    
    

    

    

    

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

    7. 

  7. 

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

      

    • 

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

      • 

    • 

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

      • 

    • 

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

      • 

    • 

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

      • 

    • 

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

      • 

    • 

      サーバー検索DN: 検索DN。たとえば、dc=mycompany,dc=comです。
      

      • 

    

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

    8. 

  8. 

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

      

    • 

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

      • 

    • 

      LDAPユーザーコンテナ: ユーザー・コンテナのDNです。これは、OIMユーザーが格納されているコンテナです。たとえば、cn=Users,dc=mycompany,dc=comです。
      

      • 

    • 

      ユーザー予約コンテナ: ユーザー予約コンテナのDNです。
      

      


      

      


      


      注意:
      

      「Oracle Identity Manager用のユーザーとグループの作成」の手順のidmconfigtoolで作成したコンテナDN値と同じ値を使用してください。
      
      		

      
      

      

      

      

      • 

    

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

    9. 

  9. 

    Remote Manager画面で、次の値を指定します。
    

    


    

    


    


    注意:
    

    この画面は、ステップ2でRemote Managerユーティリティを選択した場合にのみ表示されます。
    
    		

    
    

    

    

    

      

    • 

      サービス名: HA_RManager
      

      • 

    • 

      RMIレジストリ・ポート: 12345
      

      • 

    • 

      リスニング・ポート(SSL): 12346
      

      • 

    

    10. 

  10. 

    「構成サマリー」画面で、サマリー情報を確認します。
    

    「構成」をクリックし、Oracle Identity Managerインスタンスを構成します。
    

    11. 

  11. 

    「構成の進行状況」画面で、構成が正常に完了すると、「次へ」をクリックします。
    

    12. 

  12. 

    「構成が完了しました」画面で、構成されたOracle Identity Managerインスタンスの詳細を確認します。
    

    「終了」をクリックし、Configuration Assistantを終了します。
    

    13. 

  13. 

    第8.7項「コンポーネントの起動と停止」の説明に従い、WebLogic管理サーバーを停止します。
    

    14. 

  14. 

    第8.7項「コンポーネントの起動と停止」の説明に従い、WebLogic管理サーバーを起動します。
    

    15. 











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


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


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






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


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


    

  1. 

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

    2. 

  2. 

    「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
    

    3. 

  3. 

    「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
    

    4. 

  4. 

    表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)をクリックします。選択したサーバーの設定ページが表示されます。
    

    5. 

  5. 

    「サーバーの起動」タブをクリックします。
    

    6. 

  6. 

    「引数」フィールドで、WLS_SOA1とWLS_SOA2について次のように入力します。
    

    WLS_SOA1について、改行を入れず、1行で次のように入力します。
    

    -Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1

    

    WLS_SOA2について、改行を入れず、1行で次のように入力します。
    

    -Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1

    7. 

  7. 

    「保存」をクリックして、変更をアクティブ化します。
    

    この変更を有効にするには、SOAサーバーの再起動が必要です。
    

    8. 









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


次の手順に従い、OIMHOST1上のWLS_SOA1およびWLS_OIM1管理対象サーバーを起動します。


    

  1. 

    OIMHOST1上のWebLogic管理サーバーを停止します。この操作にはWebLogic管理コンソールを使用します。
    

    2. 

  2. 

    $DOMAIN_HOME/binディレクトリの下にあるstartWebLogic.shスクリプトを使用して、OIMHOST1上のWebLogic管理サーバーを起動します。例:
    

    /u01/app/oracle/admin/OIM/bin/startWebLogic.sh > /tmp/admin.out 2>1&

    3. 

  3. 

    WebLogic管理コンソールを表示して、WebLogic管理サーバーが正常に起動されたことを確認します。
    

    4. 

  4. 

    WebLogic管理コンソールを使用して、WLS_SOA1管理対象サーバーを起動します。
    

    5. 

  5. 

    WebLogic管理コンソールを使用して、WLS_OIM1管理対象サーバーを起動します。
    

    6. 











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


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


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


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



xelsysadmパスワードを使用してログインします。








9.1.3.8 OIMHOST2へのOracle Identity Managerの伝播


OIMHOST1で構成を完了したら、その構成をOIMHOST2に伝播できます。これを行うには、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。


次の手順に従い、OIMHOST1上のドメインをパックし、それをOIMHOST2上で解凍します。


    

  1. 

    OIMHOST1上で、MW_HOME/oracle_common/common/binディレクトリにあるpackユーティリティを呼び出します。
    

    pack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
template =/u01/app/oracle/admin/templates/oim_domain.jar -
template_name="OIM Domain" -managed=true

    2. 

  2. 

    前の手順で作成したoim_domain.jarファイルは、次のディレクトリにあります。
    

    /u01/app/oracle/admin/templates

    

    このoim_domain.jarファイルをOIMHOST1からOIMHOST2上の一時ディレクトリにコピーします。
    

    3. 

  3. 

    OIMHOST2上で、MW_HOME/oracle_common/common/binディレクトリにあるunpackユーティリティを呼び出し、その一時ディレクトリにあるoim_domain.jarファイルの場所を指定します。
    

    unpack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
template=/tmp/oim_domain.jar

    4. 









9.1.3.9 OIMHOST2におけるインストール後の手順


この項では、OIMHOST2で実行するインストール後の手順について説明します。これらの項目が含まれます。






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


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


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


MW_HOME/oracle_common/common/bin







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


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


MW_HOME/wlserver_10.3/server/bin







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


次の手順に従い、OIMHOST2上のWLS_SOA2およびWLS_OIM2管理対象サーバーを起動します。


    

  1. 

    WebLogic管理コンソールを表示して、WebLogic管理サーバーが正常に起動されたことを確認します。
    

    2. 

  2. 

    WebLogic管理コンソールを使用して、WLS_SOA2管理対象サーバーを起動します。
    

    3. 

  3. 

    WebLogic管理コンソールを使用して、WLS_OIM2管理対象サーバーを起動します。WLS_OIM2管理対象サーバーを起動する前に、WLS_SOA2管理対象サーバーを起動してください。
    

    4. 











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


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


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


http://identityvhn2.mycompany.com:14000/oim



xelsysadmパスワードを使用してログインします。








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


統合環境では、Oracle Identity ManagerはOHSによってフロントエンド処理されます。すべてのSOAサーバーのデフォルト・コンポジットを更新する必要があります。SOAサーバーのデフォルト・コンポジットの更新手順は、Oracle Fusion Middleware Oracle Identity Management統合ガイドのSOAサーバーのデフォルト・コンポジットの更新に関する説明を参照してください。








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













注意:


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


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












現在のリリースでは、LDAPConfigPostSetupスクリプトを使用すると、LDAPSync関連の増分リコンシリエーション・スケジューラ・ジョブがすべて有効になります。これらのジョブはデフォルトでは無効です。LDAP構成ポストセットアップ・スクリプトは、IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあります。スクリプトを実行する手順は、次のとおりです。


    

  1. 

    IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあるldapconfig.propsファイルを編集して、次の値を指定します。
    

    

    





    
パラメータ
値
説明

    
    


    


    OIMProviderURL
    
    		


    t3://OIMHOST1VHN.mycompany.com:14000,OIMHOST2VHN.mycompany.com:14000
    
    		


    Oracle Identity Manager管理対象サーバーのリスト。
    
    		

    

    


    LDAPURL
    
    		


    次の例のような、Oracle Virtual DirectoryインスタンスのURLを指定します。ldap://idstore.mycompany.com:389
    
    		


    アイデンティティ・ストアのURL。Oracle Virtual Directoryを使用してIDストアにアクセスする場合のみ必要です。
    
    		

    

    


    LDAPAdminUserName
    
    		


    cn=oimadmin,cn=systemids,dc=mycompany,dc=com
    
    		


    アイデンティティ・ストアへの接続に使用するユーザーの名前。アイデンティティ･ストアがOracle Virtual Directoryに存在する場合のみ必要です。このユーザーは、cn=Users,dc=mycompany,dc=comに配置しないでください。
    
    		

    

    


    LIBOVD_PATH_PARAM
    
    		


    MSERVER_HOME/config/fmwconfig/ovd/oim
    
    		


    Oracle Virtual Directoryを使用してアイデンティティ･ストアにアクセスしない場合は必要です。
    
    		

    
    

    

    


    


    

    


    


    注意:
    

    usercontainerName、rolecontainernameおよびreservationcontainernameは、この手順で使用しません。
    
    		

    
    

    

    

    

    2. 

  2. 

    ファイルを保存します。
    

    3. 

  3. 

    次のように、JAVA_HOME、WL_HOME、APP_SERVER、OIM_ORACLE_HOMEおよびDOMAIN_HOME環境変数を設定します。
    

      

    • 

      JAVA_HOMEをMW_HOME/jrockit_versionに設定
      

      • 

    • 

      WL_HOMEをMW_HOME/wlserver_10.3に設定
      

      • 

    • 

      APP_SERVERをweblogicに設定
      

      • 

    • 

      OIM_ORACLE_HOMEをIAM_ORACLE_HOMEに設定
      

      • 

    • 

      DOMAIN_HOMEをMSERVER_HOMEに設定
      

      • 

    

    4. 

  4. 

    LDAPConfigPostSetup.shを実行します。このスクリプトでは、LDAPの管理者パスワードとOracle Identity Managerの管理者パスワードが要求されます。例:
    

    IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh path_to_property_file

    

    例:
    

    IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh IAM_ORACLE_HOME/server/ldap_config_util

    5. 









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


この高可用性トポロジでは、管理対象サーバーWLS_OIM1、WLS_SOA1、WLS_OIM2、WLS_SOA2に対してサーバー移行を構成することをお薦めします。サーバー全体の移行を使用する利点と推奨する理由については、第3.9項「サーバー全体の移行」を参照してください。


    

  • 

    OIMHOST1上のWLS_OIM1およびWLS_SOA1管理対象サーバーは、OIMHOST1で障害が発生した場合に、OIMHOST2で自動的に再起動するように構成されます。
    

    • 

  • 

    OIMHOST2上のWLS_OIM2およびWLS_SOA2管理対象サーバーは、OIMHOST2で障害が発生した場合に、OIMHOST1で自動的に再起動するように構成されます。
    

    • 



このような構成では、WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2サーバーは、WebLogicサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。


次の手順を実行すると、WLS_OIM1、WLS_SOA1、WLS_OIM2、およびWLS_SOA2管理対象サーバーのサーバー移行を行うことができ、これにより、サーバーまたはプロセスの障害時に、管理対象サーバーは別のノードにフェイルオーバーできます。






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


最初の手順では、サーバー移行リース表のユーザーと表領域を設定します。













注意:


同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。この場合、データベース・リース用にデータ・ソースおよびマルチ・データ・ソースを再作成する必要はありませんが、これらをサーバー移行用に構成しているクラスタにターゲット指定しなおす必要があります。












    

  1. 

    leasingという名前の表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。
    

    SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;

    2. 

  2. 

    leasingという名前のユーザーを作成し、リース表領域に割り当てます。
    

    SQL> create user leasing identified by welcome1;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

    3. 

  3. 

    leasing.ddlスクリプトを使用してリース表を作成します。
    

      

    1. 

      WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。
      

      2. 

    2. 

      leasingユーザーとしてデータベースに接続します。
      

      3. 

    3. 

      SQL*Plusでleasing.ddlスクリプトを実行します。
      

      SQL> @Copy_Location/leasing.ddl;

      4. 

    

    4. 









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


マルチ・データ・ソースの設定プロセスで、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバルleasingマルチ・データ・ソースの両方について作成します。データ・ソースを作成するときには、次の点に留意してください。


    

  • 

    このデータ・ソースが非XAデータ・ソースであることを確認します。
    

    • 

  • 

    マルチ・データ・ソースの名前の形式は、<MultiDS>-rac0、<MultiDS>-rac1などです。
    

    • 

  • 

    Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
    

    • 

  • 

    データ・ソースは、グローバル・トランザクションのサポートを必要としません。したがって、データ・ソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。
    

    • 

  • 

    これらのデータ・ソースをクラスタにターゲット指定します。
    

    • 

  • 

    データ・ソースの接続プールの初期容量が0(ゼロ)に設定されていることを確認します。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」、「接続プール」タブの順にクリックし、「初期容量」フィールドに0(ゼロ)を入力します。
    

    • 




マルチ・データ・ソースの作成


マルチ・データ・ソースを作成する手順は、次のとおりです。


    

  1. 

    管理者の資格証明を使用して、管理コンソールにログインします。
    

    2. 

  2. 

    「ドメイン構造」ウィンドウで「サービス」ノードを開き、次に、「データ・ソース」ノードを開きます。
    

    3. 

  3. 

    「チェンジ・センター」で「ロックして編集」をクリックします。
    

    4. 

  4. 

    「新規」をクリックしてから、「マルチ・データ・ソース」をクリックします。
    

    5. 

  5. 

    名前として、leasingと入力します。
    

    6. 

  6. 

    JNDI名として、jdbc/leasingと入力します。
    

    7. 

  7. 

    アルゴリズムとして、「フェイルオーバー」(デフォルト)を選択します。「次」をクリックします。
    

    8. 

  8. 

    ターゲット・クラスタを選択します。「次へ」をクリックします。
    

    9. 

  9. 

    「非XAドライバ」(デフォルト)を選択します。「次へ」をクリックします。
    

    10. 

  10. 

    「新しいデータ・ソースの作成」をクリックします。
    

    11. 

  11. 

    名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、「Oracle Driver (Thin) for RAC server-Instance connection Version 10,11」を選択します。
    

    


    

    


    


    注意:
    

    リース表のマルチ・データ・ソースを作成する場合は、名前を<MultiDS>-rac0や<MultiDS>-rac1などの形式で入力します。
    
    		

    
    

    

    

    

    12. 

  12. 

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

    13. 

  13. 

    「グローバル・トランザクションのサポート」の選択を解除します。「次へ」をクリックします。
    

    14. 

  14. 

    leasingスキーマのサービス名、データベース名(racdb1やracdb2などのRACノードのインスタンス名)、ホスト・ポートおよびパスワードを入力します。「次へ」をクリックします。
    

    15. 

  15. 

    「構成のテスト」をクリックして、接続が機能しているかどうかを確認します。「次へ」をクリックします。
    

    


    

    


    


    注意:
    

    作成するデータ・ソースすべての作成を完了するまで、「終了」をクリックしないでください。作成したデータ・ソースが表示されない場合は、「終了」をクリックするのが早すぎたことを示しています。「終了」をクリックすると、データ・ソースをターゲット指定する画面が管理コンソールに表示されなくなります。
    
    		

    
    

    

    

    

    16. 

  16. 

    データ・ソースをクラスタにターゲット指定します。
    

    17. 

  17. 

    データ・ソースを選択して、右の画面に追加します。
    

    18. 

  18. 

    Oracle RACデータベースの2番目のインスタンスについて「新しいデータ・ソースの作成」をクリックして、そのターゲットをクラスタに設定してから、Oracle RACデータベースの2番目のインスタンスについても同じ手順を繰り返します。
    

    19. 

  19. 

    2つ目のデータ・ソースをマルチ・データ・ソースに追加します。
    

    20. 

  20. 

    保存して、「変更のアクティブ化」をクリックします。
    

    21. 









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


nodemanager.propertiesファイルを編集して、サーバー移行を構成するノードごとに次のプロパティを追加する必要があります。


Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true



    

  • 

    Interface: 浮動IPのインタフェース名(eth0など)を指定します。
    

    


    

    


    


    注意:
    

    サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。
    
    		

    
    

    

    

    

    


    

    


    


    注意:
    

    Windowsの場合、Interfaceには、ネットワーク・インタフェース名を設定する必要があります。例: Interface="Local Area Connection"
    
    		

    
    

    

    

    

    • 

  • 

    NetMask: 浮動IPのインタフェースのネット・マスクを指定します。ネット・マスクは、インタフェース上のネット・マスクと同じである必要があります(255.255.255.0は一例です)。実際の値は、ネットワークにより異なります。
    

    • 

  • 

    UseMACBroadcast: ARPパケットの送信時にノードのMACアドレスを使用するかどうか、つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。
    

    • 



これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力で、次のようなエントリが表示されることを確認します。


...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...














注意:


サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合、次の手順は必要ありません。












    

  1. 

    nodemanager.propertiesファイルで次のプロパティを設定します。
    

      

    • 

      StartScriptEnabled: このプロパティをtrueに設定して、ノード・マネージャが管理対象サーバーで起動するようにします。
      

      • 

    

    2. 

  2. 

    WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、OIMHOST1とOIMHOST2でノード・マネージャを起動します。
    

    3. 














注意:


共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個別にパラメータを指定します。たとえば、HOSTnで異なるインタフェース(eth3)を使用するには、Interface環境変数をHOSTn> export JAVA_OPTIONS=-DInterface=eth3のように使用して、この変数がシェル内で設定された後にノード・マネージャを起動します。


















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


サーバー移行を構成するノードごとにwlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定する手順は、次のとおりです。













注意:


Windowsでは、このスクリプトはwlsifconfig.cmdであり、管理者権限を持つユーザーがこれを実行できます。












    

  1. 

    PATH環境変数に次のファイルが含まれていることを確認します。
    

    

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

    




    
ファイル
格納されているディレクトリ

    
    


    


    wlsifconfig.sh
    
    		


    DOMAIN_HOME/bin/server_migration
    
    		

    

    


    wlscontrol.sh
    
    		


    WL_HOME/common/bin
    
    		

    

    


    nodemanager.domains
    
    		


    WL_HOME/common
    
    		

    
    

    

    

    2. 

  2. 

    wlsifconfig.shスクリプトに対するsudo構成権限を付与します。
    

      

    • 

      パスワード・プロンプトを使用しないで機能するsudoを構成します。
      

      • 

    • 

      セキュリティ上の理由から、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定することをお薦めします。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。
      

      • 

    • 

      WebLogicユーザー(oracle)に、パスワードによる制限なしのsudo権限を付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
      

      • 

    • 

      WebLogicユーザーがこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。
      

      oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

      • 

    

    


    

    


    


    注意:
    

    この手順で使用できるsudoとシステム権限はシステム管理者にお問い合せください。
    
    		

    
    

    

    

    

    3. 









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


まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。


    

  1. 

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

    2. 

  2. 

    「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
    

    3. 

  3. 

    「名前」列で、移行を構成するクラスタをクリックします。
    

    4. 

  4. 

    「移行」タブをクリックします。
    

    5. 

  5. 

    「ロックして編集」をクリックします。
    

    6. 

  6. 

    「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
    

    7. 

  7. 

    自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
    

    8. 

  8. 

    「保存」をクリックします。
    

    9. 

  9. 

    「変更のアクティブ化」をクリックします。
    

    10. 

  10. 

    サーバー移行の候補となるマシンを設定します。このタスクは、次の手順に従って、すべての管理対象サーバーについて実行する必要があります。
    

      

    1. 

      管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開いて、「サーバー」を選択します。
      

      


      

      


      


      ヒント:
      

      「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックして、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動し、サーバーが実行されているマシンを表示します。サーバーが自動的に移行される場合、これは実際の構成とは異なります。
      
      		

      
      

      

      

      

      2. 

    2. 

      移行を構成するサーバーを選択します。
      

      3. 

    3. 

      「移行」タブをクリックします。
      

      4. 

    4. 

      「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
      

      5. 

    5. 

      「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
      

      6. 

    6. 

      「保存」をクリックしてから、「変更のアクティブ化」をクリックします。
      

      7. 

    7. 

      追加の管理対象サーバーに対して、前述の手順を繰り返します。
      

      8. 

    8. 

      管理サーバー、ノード・マネージャ、サーバー移行が構成されたサーバーを再起動します。
      

      9. 

    

    11. 









9.1.3.13.6 サーバー移行のテスト


サーバー移行が適切に機能していることを確認する手順は次のとおりです。



OIMHOST1から次の処理を実行します。


    

  1. 

    WLS_OIM1管理対象サーバーを停止します。これには、次のコマンドを実行します。
    

    OIMHOST1> kill -9 pid

    

    pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
    

    OIMHOST1> ps -ef | grep WLS_OIM1

    2. 

  2. 

    ノード・マネージャのコンソールを確認します。WLS_OIM1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
    

    3. 

  3. 

    ノード・マネージャがWLS_OIM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。
    

    4. 

  4. 

    ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
    

    5. 




OIMHOST2から次の処理を実行します。


    

  1. 

    ローカルのノード・マネージャのコンソールを確認します。OIMHOST1でのWLS_OIM1の再起動が前回試行されてから30秒間経過した後に、WLS_OIM1の浮動IPが表示されサーバーをこのノードで再起動することを示すメッセージがOIMHOST2のノード・マネージャにより表示されます。
    

    2. 

  2. 

    同じIPでsoa-infraコンソールにアクセスします。
    

    3. 



前述の手順に従い、WLS_OIM2、WLS_SOA1、およびWLS_SOA2管理対象サーバーのサーバー移行をテストします。


表9-4は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。




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









管理対象サーバー
移行元
移行先








WLS_OIM1




OIMHOST1




OIMHOST2








WLS_OIM2




OIMHOST2




OIMHOST1








WLS_SOA1




OIMHOST1




OIMHOST2








WLS_SOA2




OIMHOST2




OIMHOST1












管理コンソールからの検証


移行は管理コンソールで確認することもできます。


    

  1. 

    管理者の資格証明を使用して、管理コンソール(http://oimhost1.mycompany.com:7001/console)にログインします。
    

    2. 

  2. 

    左側のコンソールで、「ドメイン」をクリックします。
    

    3. 

  3. 

    「監視」タブをクリックし、「移行」サブタブをクリックします。
    

    「移行の状態」表に、移行の状態に関する情報が表示されます。
    

    4. 














注意:


サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。




















9.1.3.14 共有JMS永続ストアの構成


OIMHOST1とOIMHOST2の両方から参照できる共有ディレクトリに、すべての永続ストアの場所を構成します。JMSメッセージは、各サーバーのローカル・ファイル・システムのファイル・システムで永続化されているため、WebLogicサーバー移行のためにはJMS永続ストア用の共有記憶域が必要です。共有記憶域がない場合、移行先サーバーからは保留中のJMSメッセージにアクセスできなくなります。













注意:


JMSメッセージ、トランザクション・ログおよびファイル・ストアでのロックの解放の詳細は、「NFSでのファイル・ストアの使用に関する考慮事項」を参照してください。












共有のベース・ディレクトリを使用するように、すべての永続ストアを変更する手順は、次のとおりです。


    

  1. 

    管理者の資格証明を使用して、管理コンソール(http://oimhost1.mycompany.com:7001/console)にログインします。
    

    2. 

  2. 

    「ドメイン構造」ウィンドウで、「サービス」ノードを開いて「永続ストア」ノードをクリックします。「永続ストアの概要」ページが表示されます。
    

    3. 

  3. 

    表BPM、SOA、OIMおよびUMSの「名前」列から、永続ストアのハイパーリンクを選択します。その永続ストアの「設定」ページが表示されます。
    

    4. 

  4. 

    「構成」タブの「ディレクトリ」フィールドに、クラスタ内の他のサーバーで使用可能な永続記憶域ソリューション(NASやSANなど)の場所を入力します。この場所を指定することで、保留中のJMSメッセージを送信できます。
    

    5. 

  5. 

    場所は、次のディレクトリ構造に従う必要があります。
    

      

    • 

      WLS_SOA1およびWLS_SOA2サーバーについては、次のようなディレクトリ構造を使用します。
      

      ORACLE_BASE/admin/domainName/soaClusterName/jms

      • 

    • 

      WLS_OIM1およびWLS_OIM2サーバーについては、次のようなディレクトリ構造を使用します。
      

      ORACLE_BASE/admin/domainName/oimClusterName/jms

      

      


      

      


      


      注意:
      

      WLS_OIM1およびWLS_OIM2サーバーは、このディレクトリにアクセスできる必要があります。
      

      WLS_SOA1およびWLS_SOA2 サーバーは、このディレクトリにアクセスできる必要があります。
      

      このディレクトリは、サーバーを再起動する前に存在している必要があります。
      
      		

      
      

      

      

      

      • 

    

    6. 

  6. 

    「保存してアクティブ化」をクリックします。
    

    7. 

  7. 

    サーバーを再起動して、永続ストア内の変更を有効化します。
    

    8. 









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


各Oracle WebLogic管理対象サーバーにはトランザクション・ログがあり、サーバーによって調整された、未完了の可能性のある、進行中のトランザクションについての情報が格納されます。WebLogic Serverは、システム障害やネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、クラスタ内のすべてのサーバーからアクセス可能な場所にトランザクション・ログを格納します。共有記憶域がないと、サーバーに障害が発生したときにクラスタ内の他のサーバーがトランザクション・リカバリを実行できず、操作の再試行が必要になることがあります。













注意:


可能であれば、この場所にはデュアル・ポートのSCSIディスクまたはストレージ・エリア・ネットワーク(SAN)を使用します。












Oracle Identity ManagerおよびSOAサーバーのデフォルトの永続ストアの場所を設定する手順は次のとおりです。


    

  1. 

    管理者の資格証明を使用して、管理コンソール(http://oimhost1.mycompany.com:7001/console)にログインします。
    

    2. 

  2. 

    「ドメイン構造」ウィンドウで、「環境」ノードを開いて「サーバー」ノードをクリックします。「サーバーのサマリー」ページが表示されます。
    

    3. 

  3. 

    表の「名前」列で、サーバーの名前(ハイパーリンクとして表示)を選択します。選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
    

    4. 

  4. 

    「サービス」タブをクリックします。
    

    5. 

  5. 

    ページの「デフォルト・ストア」セクションに、デフォルトの永続ストアがデータファイルを格納するフォルダのパスを入力します。パスのディレクトリ構造は、次のようにする必要があります。
    

      

    • 

      WLS_SOA1およびWLS_SOA2サーバーについては、次のようなディレクトリ構造を使用します。
      

      ORACLE_BASE/admin/domainName/soaClusterName/tlogs

      • 

    • 

      WLS_OIM1およびWLS_OIM2サーバーについては、次のようなディレクトリ構造を使用します。
      

      ORACLE_BASE/admin/domainName/oimClusterName/tlogs

      • 

    

    6. 

  6. 

    「保存」をクリックします。
    

    


    

    


    


    注意:
    

    トランザクション回復サービスの移行機能を有効化するには、クラスタ内の管理対象サーバーで利用可能な永続記憶域ソリューション上の場所を指定します。WLS_SOA1、WLS_SOA2、WLS_OIM1、およびWLS_OIM2は、このディレクトリにアクセスできる必要があります。
    
    		

    
    

    

    

    

    7. 









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


WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールする手順は、第8.6.3.4.1項「Web Tier用のOracle HTTP Serverのインストール」を参照してください。








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


この項では、Oracle Identity Managerを構成してOracle Web Tierと連携する方法について説明します。





9.1.3.17.1 前提条件


次のタスクが実行済であることを確認します。


    

  1. 

    Oracle Web TierをWEBHOST1とWEBHOST2にインストールしました。
    

    2. 

  2. 

    Oracle Identity ManagerがOIMHOST1およびOIMHOST2にインストールされ、構成済であること。
    

    3. 

  3. 

    ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(sso.mycompany.com)で構成済であること。
    

    4. 

  4. 

    ロード・バランサがWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(oiminternal.mycompany.com)で構成済であること。
    

    5. 

  5. 

    ロード・バランサのVIPの構成の詳細は、第8.2.5.4項「ロード・バランサの仮想サーバー名とポートの構成」を参照してください。
    

    6. 









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


    

  1. 

    WEBHOST1とWEBHOST2上の各Webサーバーで、oim.confと呼ばれるファイルをORACLE_INSTANCE/config/OHS/component/moduleconfディレクトリに作成します。このファイルには次の情報が記載されている必要があります。
    

    # oim admin console(idmshell based)
   <Location /admin>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>
 
# oim self and advanced admin webapp consoles(canonic webapp)
 
  <Location /oim>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>

  <Location /identity>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid 
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>

  <Location /sysadmin>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>

# SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
  <Location /sodcheck>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:8001,oimvhn2.mycompany.com:8001
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>

# Callback webservice for SOA. SOA calls this when a request is approved/rejected
# Provide the SOA Managed Server Port
  <Location /workflowservice>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# xlWebApp - Legacy 9.x webapp (struts based)
   <Location /xlWebApp>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# Nexaweb WebApp - used for workflow designer and DM
  <Location /Nexaweb>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# used for FA Callback service.
  <Location /callbackResponseService>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# spml xsd profile
  <Location /spml-xsd>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

  <Location /HTTPClnt>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>
 

  <Location /reqsvc>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicCluster slc00apd.us.mycompany.com:14000,
    slc00dej.us.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

    2. 

  2. 

    ORACLE_INSTANCE/config/OHS/component/moduleconfにvirtual_hosts.confというファイルを作成します。このファイルは、次の情報を含む必要があります。
    

    NameVirtualHost *:7777
<VirtualHost *:7777>

  ServerName http://sso.mycompany.com:7777
  RewriteEngine On
  RewriteOptions inherit
  UseCanonicalName On
  </VirtualHost>

<VirtualHost *:7777>
  ServerName http://oiminternal.mycompany.com:80
  RewriteEngine On
  RewriteOptions inherit
  UseCanonicalName On
</VirtualHost>

    3. 

  3. 

    WEBHOST1とWEBHOST2の両方でファイルを保存します。
    

    4. 

  4. 

    第8.7項「コンポーネントの起動と停止」の説明に従い、WEBHOST1およびWEBHOST2上のOracle HTTP Serverインスタンスを停止してから起動します。
    

    5. 











9.1.3.18 Oracle HTTP Serverの構成の検証


Oracle HTTP Serverが適切に構成されていることを検証する手順は次のとおりです。


    

  1. 

    Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。
    

    http://sso.mycompany.com:7777/identity

    

    Oracle Identity Managerコンソール・ログイン・ページが表示されます。
    

    2. 

  2. 

    xelsysadmユーザーの資格証明を使用してOracle Identity Managerコンソールにログインします。
    

    3. 









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


高可用性環境では、WebLogicノード・マネージャはOracle WebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。


高可用性環境では、ハードウェア・ロード・バランサを使用して、複数のOracle Identity Managerインスタンス間のリクエストをロード・バランシングします。Oracle Identity Managerインスタンスのいずれかに障害が発生した場合は、ロード・バランサによって障害が検出され、障害が発生していないインスタンスにリクエストがルーティングされます。


高可用性環境では、状態情報と構成情報は、クラスタ内のすべてのメンバーが共有するデータベースに格納されます。


状態情報が共有データベースに格納されており、クラスタ内のすべてのメンバーがこの情報を使用できるため、障害が発生していないOracle Identity Managerインスタンスでは、障害が発生したインスタンスで開始された未完了のトランザクションの処理をシームレスに継続します。


Oracle Identity Managerインスタンスのいずれかで障害が発生すると、そのデータベースとLDAP接続は解放されます。アクティブ/アクティブ・デプロイメント内にある障害が発生していないインスタンスは、独自の接続を行い、障害が発生したインスタンス上にある未完了のトランザクションの処理を継続します。


Oracle Identity Managerを高可用性構成にデプロイする場合は、次のことに注意してください。


    

  • 

    Oracle Identity ManagerはOracle RACデータベースにデプロイできますが、Oracle RACのフェイルオーバーは、このリリースではOracle Identity Managerに対して透過的ではありません。Oracle RACのフェイルオーバーが発生すると、エンド・ユーザーは、各自のリクエストを再送信する必要がある場合があります。
    

    • 

  • 

    Oracle Identity Managerは常に、SOAクラスタ内で少なくとも1つのノードが使用可能であることを必要とします。SOAクラスタが使用可能でない場合、エンド・ユーザーのリクエストは失敗します。Oracle Identity Managerノードは、失敗したSOA呼出しに対して再試行しません。そのため、SOA呼出しが失敗すると、エンド・ユーザーは再試行する必要があります。
    

    • 









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


アクティブ/アクティブOracle Identity Manager構成において、Oracle Identity Managerでユーザーを作成していて(Oracle Identity Managerにログインし、「管理」タブをクリックして、「ユーザーの作成」リンクをクリックし、フィールドに必要な情報を入力してから、「保存」をクリックします)、そのリクエストを処理中のOracle Identity Managerサーバーに障害が発生した場合、Oracle Identity Managerログ・ファイルに次のようなResourceConnectionValidationxceptionが記述されることがあります。


[2010-06-14T15:14:48.738-07:00] [oim_server2] [ERROR] [] [XELLERATE.SERVER]
[tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: xelsysadm] [ecid:
004YGJGmYrtEkJV6u3M6UH00073A0005EI,0:1] [APP: oim#11.1.1.3.0] [dcid:
12eb0f9c6e8796f4:-785b18b3:12938857792:-7ffd-0000000000000037] [URI:
/admin/faces/pages/Admin.jspx] Class/Method:
PooledResourceConnection/heartbeat encounter some problems: Operation timed
out[[
com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception: Operation
timed out
        at
oracle.iam.ldapsync.impl.repository.LDAPConnection.heartbeat(LDAPConnection.ja
va:162)
        at
com.oracle.oim.gcp.ucp.PooledResourceConnection.heartbeat(PooledResourceConnec
tion.java:52)
         .
         .
         .



この例外を受け取った場合でも、ユーザーは正常に作成されます。








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


Oracle Identity Manager高可用性トポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。





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


この場合は、SOAコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードには、既存の管理対象サーバーのMiddlewareホーム、Oracleホーム(SOA)およびドメイン・ディレクトリが含まれます。


新しいWLS_OIMおよびWLS_SOAサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。OIMおよびSOAのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。


トポロジをスケール・アップするには、次の手順を実行します。


    

  1. 

    管理コンソールを使用して、WLS_OIM1またはWLS_SOA1のクローンを新しい管理対象サーバーに作成します。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
    

    管理対象サーバーのクローンを作成する手順は次のとおりです。
    

      

    1. 

      管理コンソールから「環境」→「サーバー」を選択します。
      

      2. 

    2. 

      クローンを作成する管理対象サーバー(WLS_OIM1やWLS_SOA1など)を選択します。
      

      3. 

    3. 

      「クローンの作成」を選択します。
      

      4. 

    4. 

      新しい管理対象サーバーにWLS_OIMnまたはWLS_SOAnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
      

      5. 

    

    この後の手順では、すでにWLS_SOA1およびWLS_OIM1を実行しているOIMHOST1に新しいサーバーを追加することを想定しています。
    

    2. 

  2. 

    リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPを割り当てます。このサーバーでお薦めしているサーバー移行を実行する予定の場合は、別のノードへの移動を可能にするために、このアドレスはVIP(別称: 浮動IP)である必要があります。このVIPは、実行されている管理対象サーバーとは別のものを使用してください。
    

    3. 

  3. 

    新しい管理対象サーバーにSOA、OIM、BPMおよびUMSのJMSサーバーを作成します。
    

      

    1. 

      管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_nのような名前を付けます。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      
      		

      
      

      

      

      

      2. 

    2. 

      SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n)。このJMSサーバーに対して、SOAJMSFileStore_nを使用します。SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      3. 

    3. 

      新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      4. 

    4. 

      UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。このJMSサーバーに対して、UMSJMSFileStore_nを使用します。UMSJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      5. 

    5. 

      新しいOIMJMSServerの新しい永続ストアを作成します(たとえば、OIMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいOIM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      6. 

    6. 

      OIMの新しいJMSサーバーを作成します(たとえば、OIMJMSServer_n)。このJMSサーバーに対して、OIMJMSFileStore_nを使用します。OIMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。
      

      7. 

    7. 

      新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      8. 

    8. 

      サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      9. 

    9. 

      新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUCMJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      10. 

    10. 

      サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      11. 

    11. 

      新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      12. 

    12. 

      サブデプロイメント「OIMMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      13. 

    

    4. 

  4. 

    第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、コンポジットをデプロイする場合のOracle Coherenceを構成します。
    

    


    

    


    


    注意:
    

    サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例:
    

    Dtangosol.coherence.localhost=SOAHOST1VHNn
    
    		

    
    

    

    

    

    5. 

  5. 

    新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
    

    管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
    

    6. 

  6. 

    新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
    

    ホスト名の検証を無効化するには、次の手順を実行します。
    

      

    1. 

      Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
      

      2. 

    2. 

      「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
      

      3. 

    3. 

      「サーバー」をクリックします。表の「名前」列で「WLS_SOAn」を選択します。
      

      4. 

    4. 

      「SSL」タブをクリックします。「詳細」をクリックします。
      

      5. 

    5. 

      「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
      

      6. 

    

    7. 

  7. 

    管理コンソールから新しい管理対象サーバーを起動して、テストします。
    

      

    1. 

      クラスタ内の既存の管理対象サーバーを停止します。
      

      2. 

    2. 

      新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。
      

      3. 

    3. 

      新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。
      

      4. 

    

    8. 

  8. 

    管理コンソールにログインします。「サービス」→「外部JNDIプロバイダ」リンクを選択します。「ForeignJNDIProvider-SOA」を選択し、新しいサーバーを既存の値に追加します。
    

    9. 

  9. 

    新しい管理対象サーバーに対してサーバー移行を構成します。
    

    


    

    


    


    注意:
    

    これはスケール・アップ操作であるため、ノード・マネージャ、サーバー移行に対して構成された環境および新しいSOA管理対象サーバーの浮動IPがあらかじめノードに用意されている必要があります。
    
    		

    
    

    

    

    

    サーバー移行を構成する手順は次のとおりです。
    

      

    1. 

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

      2. 

    2. 

      左側のペインで、「環境」を開き、「サーバー」を選択します。
      

      3. 

    3. 

      移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。
      

      4. 

    4. 

      「移行」タブをクリックします。
      

      5. 

    5. 

      「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。ノードの既存のサーバーと同じ移行ターゲットを選択します。
      

      たとえば、すでにWLS_SOA1が実行されているSOAHOST1上の新しい管理対象サーバーには、SOAHOST2を選択します。すでにWLS_SOA2が実行されているSOAHOST2上の新しい管理対象サーバーには、SOAHOST1を選択します。
      

      移行時に管理対象サーバーを同時に実行できるように、適切なリソースが使用可能になっていることを確認してください。
      

      6. 

    6. 

      「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
      

      7. 

    7. 

      「保存」をクリックします。
      

      8. 

    8. 

      管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
      

      9. 

    9. 

      新しく作成したWLS_OIMn管理対象サーバーに対してサーバー移行を構成するために、このリストの手順を繰り返します。
      

      10. 

    

    10. 

  10. 

    この新規サーバーのサーバー移行をテストするには、新規サーバーの追加先となったノードで、次の手順を実行します。
    

      

    1. 

      管理対象サーバーWLS_SOAnを停止します。
      

      そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDを調べるには、ps -ef | grep WLS_SOAnを入力します。
      

      2. 

    2. 

      ノード・マネージャ・コンソールに、WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
      

      3. 

    3. 

      ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
      

      4. 

    4. 

      ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーがローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
      

      5. 

    

    11. 









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


トポロジのスケール・アウトでは、SOAで構成された新しい管理対象サーバーを新しいノードに追加します。


この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。


    

  • 

    SOAで構成された管理対象サーバーを実行しているノードがトポロジ内に存在していること。
    

    • 

  • 

    新しいノードがWebLogic ServerとSOAの既存のホーム・ディレクトリにアクセスできること。(新しい管理対象サーバーWLS_SOAまたはWLS_WSMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやSOAバイナリをインストールする必要はありませんが、packとunpackを実行して、新しいノードでドメイン構成をブートストラップする必要があります。)
    

    


    

    


    


    注意:
    

    共有記憶域にインストールが存在しない場合は、第5.13項「Oracle SOAインフラストラクチャとコンポーネント・サービス・エンジンの高可用性の構成」の説明に従って、新しいノードにWebLogic ServerとSOAをインストールする必要があります。
    
    		

    
    

    

    

    

    


    

    


    


    注意:
    

    ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、user_home/bea/beahomelistファイルを編集します。次の手順を参照してください。
    
    		

    
    

    

    

    

    • 



トポロジをスケール・アウトするには、次の手順を実行します。


    

  1. 

    新しいノードで、SOAのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
    

    2. 

  2. 

    共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。
    

    SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>

    

    Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
    

    3. 

  3. 

    Oracle WebLogic管理コンソールにログインします。
    

    4. 

  4. 

    新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
    

    5. 

  5. 

    このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
    

    6. 

  6. 

    管理コンソールを使用し、WLS_SOA1のクローンを作成して新しい管理対象サーバーにします。このサーバーにWLS_SOAnという名前を付けます。nは番号です。
    

    


    

    


    


    注意:
    

    これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。
    
    		

    
    

    

    

    

    7. 

  7. 

    新しい管理対象サーバーでその管理対象サーバーのリスニング・アドレスに使用するホスト名またはIPを割り当てます。
    

    このサーバーに対してサーバー移行の使用を計画している場合は(推奨)、このアドレスにサーバーのVIP(浮動IPともいう)を割り当てる必要があります。このVIPは、既存の管理対象サーバーとは別のものを使用してください。
    

    8. 

  8. 

    新しい管理対象サーバーにSOA、OIM(該当する場合)およびUMSのJMSサーバーを作成します。
    

      

    1. 

      管理コンソールを使用して、新しいSOAJMSServerの新しい永続ストアを作成し、SOAJMSFileStore_nのような名前を付けます。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      
      		

      
      

      

      

      

      2. 

    2. 

      SOAの新しいJMSサーバーを作成します(たとえば、SOAJMSServer_n)。このJMSサーバーに対して、SOAJMSFileStore_nを使用します。SOAJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      3. 

    3. 

      新しいUMSJMSServerの新しい永続ストアを作成します(たとえば、UMSJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいUMS JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      4. 

    4. 

      UMSの新しいJMSサーバーを作成します(たとえば、UMSJMSServer_n)。このJMSサーバーに対して、UMSJMSFileStore_nを使用します。UMSJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_SOAn)にターゲット指定します。
      

      5. 

    5. 

      新しいOIMJMSServerの新しい永続ストアを作成します(たとえば、OIMJMSFileStore_n)。このストアのパスを指定します。これは、共有記憶域上のディレクトリである必要があります。
      

      ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n

      

      


      

      


      


      注意:
      

      このディレクトリは、管理対象サーバーが起動される前から存在している必要があります。そうでないと、起動操作が失敗します。
      

      新しいOIM JMSサーバーのストアとしてSOAJMSFileStore_nを割り当てることもできます。わかりやすさと独立性を保つために、以降の手順では個別の永続ストアを使用します。
      
      		

      
      

      

      

      

      6. 

    6. 

      OIMの新しいJMSサーバーを作成します(たとえば、OIMJMSServer_n)。このJMSサーバーに対して、OIMJMSFileStore_nを使用します。OIMJMSServer_nサーバーを、新たに作成した管理対象サーバー(WLS_OIMn)にターゲット指定します。
      

      7. 

    7. 

      新たに作成されたSOA JMSサーバーが含まれるように、SOA JMSモジュールのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「SOAJMSModule」(表の「名前」列でハイパーリンクとして表示されている)をクリックします。SOAJMSModuleの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。SOAJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたSOAJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      8. 

    8. 

      サブデプロイメント「SOAJMSServerXXXXXX」をクリックします。このサブデプロイメントに、SOAJMSServer_nと呼ばれる、SOAの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      9. 

    9. 

      新たに作成されたUMS JMSサーバーが含まれるように、UMSJMSSystemResourceのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「UMSJMSSystemResource」(表の「名前」列にハイパーリンクとして表示)をクリックします。UMSJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。UMSJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_SOA1とWLS_SOA2)のJMS構成から生成されたUCMJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      10. 

    10. 

      サブデプロイメント「UMSJMSServerXXXXXX」をクリックします。このサブデプロイメントに、UMSJMSServer_nと呼ばれる、UMSの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      11. 

    11. 

      新たに作成されたOIM JMSサーバーが含まれるように、OIMJMSModuleのSubDeploymentターゲットを更新します。このためには、「サービス」ノード→「メッセージング」ノードを開きます。管理コンソールの「ドメイン構造」ウィンドウから、「JMSモジュール」を選択します。「JMSモジュール」ページが表示されます。「OIMJMSSystemResource」をクリックします(表の「名前」列にハイパーリンクとして表示されています)。OIMJMSSystemResourceの「設定」ページが表示されます。「サブデプロイメント」タブをクリックします。OIMJMSのサブデプロイメント・モジュールが表示されます。
      

      


      

      


      


      注意:
      

      このサブデプロイメント・モジュール名は、構成ウィザードにおける最初の2つのサーバー(WLS_OIM1とWLS_OIM2)のJMS構成から生成されたOIMJMSServerXXXXXXという形式のランダム名です。
      
      		

      
      

      

      

      

      12. 

    12. 

      サブデプロイメント「OIMMSServerXXXXXX」をクリックします。このサブデプロイメントに、OIMJMSServer_nと呼ばれる、OIMの新しいJMSサーバーを追加します。「保存」をクリックします。
      

      13. 

    

    9. 

  9. 

    次のようにpackコマンドをSOAHOST1で実行し、テンプレート・パックを作成します。
    

    SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true/
-domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

    

    次のコマンドをSOAHOST1で実行し、作成したテンプレート・ファイルをSOAHOSTnにコピーします。
    

    SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/
ORACLE_BASE/product/fmw/soa/common/bin

    

    次のようにSOAHOSTnでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
    

    SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/common/bin
SOAHOSTN> ./unpack.sh /
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar

    10. 

  10. 

    第5.13.8項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、コンポジットをデプロイする場合のOracle Coherenceを構成します。
    

    


    

    


    


    注意:
    

    サーバーに対して変更が必要なのは、ローカル・ホスト・フィールドのみです。ローカル・ホストを、新しく追加されたサーバーのリスニング・アドレスに置き換えます。例:
    

    Dtangosol.coherence.localhost=SOAHOST1VHNn
    
    		

    
    

    

    

    

    11. 

  11. 

    新しいサーバーに対してトランザクション永続ストアを構成します。これは、他のノードからアクセス可能な共有記憶域の場所である必要があります。
    

    管理コンソールから、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の「ディレクトリ」に、デフォルトの永続ストアがデータ・ファイルを格納するフォルダのパスを入力します。
    

    12. 

  12. 

    新しい管理対象サーバーのホスト名の検証を無効化します。WLS_SOAn管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。Oracle WebLogic管理サーバーとSOAHOSTn内のノード・マネージャとの通信のためのサーバー証明書を構成すると、ホスト名の検証を再び有効化できます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるため、これらの手順は不要です。
    

    ホスト名の検証を無効化するには、次の手順を実行します。
    

      

    1. 

      Oracle Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
      

      2. 

    2. 

      「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
      

      3. 

    3. 

      「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
      

      4. 

    4. 

      表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。
      

      5. 

    5. 

      「SSL」タブをクリックします。
      

      6. 

    6. 

      「詳細」をクリックします。
      

      7. 

    7. 

      「ホスト名の検証」を「なし」に設定します。
      

      8. 

    8. 

      「保存」をクリックします。
      

      9. 

    

    13. 

  13. 

    新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
    

    SOAHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip

    14. 

  14. 

    管理コンソールから新しい管理対象サーバーを起動して、テストします。
    

      

    1. 

      クラスタ内の既存の管理対象サーバーを停止します。
      

      2. 

    2. 

      新たに作成した管理対象サーバーWLS_SOAnが起動していることを確認します。
      

      3. 

    3. 

      新たに作成した管理対象サーバー上のアプリケーション(http://vip:port/soa-infra)にアクセスします。アプリケーションが機能している必要があります。
      

      4. 

    

    15. 

  15. 

    新しい管理対象サーバーに対してサーバー移行を構成します。
    

    


    

    


    


    注意:
    

    この新しいノードでは既存の共有記憶域インストールを使用しているため、ノードではすでに、ノード・マネージャと、ネットマスク、インタフェース、wlsifconfigスクリプトのスーパーユーザー権限などの、サーバー移行用に構成された環境が使用されています。新しいノードには、すでに新しいSOA管理対象サーバーの浮動IPが存在します。
    
    		

    
    

    

    

    

    次の手順を実行してサーバー移行を構成します。
    

      

    1. 

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

      2. 

    2. 

      左側のペインで、「環境」を開き、「サーバー」を選択します。
      

      3. 

    3. 

      移行を構成するサーバー(ハイパーリンクとして示されています)を選択します。このサーバーの「設定」ページが表示されます。
      

      4. 

    4. 

      「移行」タブをクリックします。
      

      5. 

    5. 

      「移行の構成」セクションの「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。
      

      


      

      


      


      注意:
      

      マシンのうち、負荷が最も低いものを新しいサーバーの移行ターゲットとして指定します。このノードのリソースが追加の管理対象サーバーの持続に十分対応できるように、必須の容量計画を立てる必要があります。
      
      		

      
      

      

      

      

      6. 

    6. 

      「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
      

      7. 

    7. 

      「保存」をクリックします。
      

      8. 

    8. 

      管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。
      

      9. 

    

    16. 

  16. 

    この新しいサーバーのサーバー移行をテストします。新しいサーバーを追加したノードで次の手順を実行します。
    

      

    1. 

      管理対象サーバーWLS_SOAnを停止します。
      

      そのためには、管理対象サーバーのPIDに対してkill -9 pidを実行します。ノードのPIDは、ps -ef | grep WLS_SOAnを使用して確認できます。
      

      2. 

    2. 

      ノード・マネージャ・コンソールを確認します。WLS_SOA1の浮動IPが無効になっていることを示すメッセージが表示されています。
      

      3. 

    3. 

      ノード・マネージャがWLS_SOAnの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
      

      4. 

    4. 

      ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。これで、サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
      

      5. 

    

    17. 















9.2 Oracle Access Management Access Managerの高可用性


この項では、Oracle Access Management Access Manager (Access Manager)の概要、およびAccess Managerの高可用性環境の設計およびデプロイ方法について説明します。


Access Managerによって、すべての認証および認可サービスの一元的な提供が可能になります。提供されるコア・サービスは、有効なセッション・トークンのチェック、セッション・トークンが無効であるか見つからない場合の資格証明の要求、セッション・トークンの発行、リソース・リクエストのインターセプト、およびリソースへのアクセスを制御するためのアクセス制御ポリシーの評価です。Access Managerは、Pure Javaサーバーの機能を備えていますが、Oracle Single Sign-On 10gおよびOracle Access Manager 10gエージェント・コンポーネントも引き続き使用します。Access Managerの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Access Managerの概要に関する説明を参照してください。


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






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


図9-3は、Access Managerコンポーネントのアーキテクチャを示しています。




図9-3 Access Managerの単一インスタンス・アーキテクチャ

図9-3の説明が続きます
 「図9-3 Access Managerの単一インスタンス・アーキテクチャ」の説明
 



図9-2は、次のコンポーネントを示しています。


    

  • 

    ユーザー・エージェント: これらには、Webブラウザ、Javaアプリケーション、およびWebサービス・アプリケーションが含まれます。ユーザー・エージェントは、HTTPを使用してアクセス・サーバーと管理および構成ツールにアクセスします。
    

    • 

  • 

    保護されたリソース: 保護されたリソースとは、それへのアクセスが制限されたアプリケーションまたはWebページのことです。保護されたリソースへのアクセスは、WebGateまたはカスタム・エージェントによって制御されます。
    

    • 

  • 

    管理および構成ツール: Access Managerは、Oracle Access Managementコンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Enterprise Manager Grid ControlおよびWebLogic Scripting Tool (WLST)を使用して管理および構成します。
    

    • 

  • 

    アクセス・サーバー: アクセス・サーバーには、資格証明コレクタ、OSSOプロキシおよびOAMプロキシ・コンポーネントが含まれます。Coherence分散オブジェクト・キャッシュは、アクセス・サーバー間で構成ファイルの変更を伝播するために使用されます。
    

    • 






9.2.1.1 Access Managerコンポーネントの特性


Access Managerデプロイメントは、次のシステム・エンティティで構成されます。


    

  • 

    Access Managerエージェント: Access Managerエージェントは、アクセス・サーバーの拡張機能であり、アクセス・サーバーで管理されているポリシーに従ってアクセスが制御されるようにする役割を担います。
    

    エージェントがその機能を実行するには、アクセス・サーバー・コンポーネントが必要です。アクセス・サーバーが使用できない場合、保護されるサーバーへのアクセスは許可されないため、ユーザーはシステムからロックアウトされます。
    

    • 

  • 

    保護されたリソース(パートナ・アプリケーション): Access Managerによって保護されたアプリケーションです。これらのリソースへのアクセスは、Access Managerのアクセス制御ポリシーに従って行われ、保護されたリソースのアクセス・パスにデプロイされたAccess Managerエージェント(WebサーバーにデプロイされたAccess Managerエージェントなど)によって制御されます。
    

    • 

  • 

    アクセス・サーバー: コア・ランタイム・アクセス管理サービスを提供するサーバー・サイド・コンポーネントです。
    

    • 

  • 

    JMX Mbean: ランタイムMBeanは、アクセス・サーバー・パッケージの一部としてパッケージ化されています。構成Mbeanは、スタンドアロンWARファイルとしてパッケージ化されています。
    

    • 

  • 

    WebLogic 11g SSPIプロバイダは、Access Java Access JDKとともにSSPIインタフェースを実現するJavaクラスで構成されています。AccessGateは、Pure Java Access JDKを使用して構築されています。
    

    • 

  • 

    Oracle Access Managementコンソール: 管理コンソールをホストするJ2EEアプリケーションであり、Access Managerデプロイメントを管理するための管理や構成などのサービスを提供します。
    

    • 

  • 

    WebLogic Scripting Tool(WLST)は、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。Access Managerデプロイメントの管理の一部は、コマンドラインからサポートされます。
    

    • 

  • 

    Fusion Middleware ControlおよびEnterprise Manager Grid Control: Access Managerは、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。
    

    • 

  • 

    Coherence分散オブジェクト・キャッシュ: Access Managerコンポーネントは、このインフラストラクチャに依存して、変更をリアルタイムに伝播します。
    

    • 

  • 

    Access Manager Proxyは、Apache MINAサーバーのカスタマイズ・バージョン(JCAアーキテクチャに基づく)であり、Javaサーバー・クラスに加えてMessageDrivenBeanおよびResourceAdapterが含まれています。
    

    • 

  • 

    Oracle Single Sign-On(OSSO)プロキシは、アクセス・サーバー・パッケージに含まれているJavaクラスで構成されています。
    

    • 

  • 

    データ・リポジトリ: Access Managerは、アイデンティティ、ポリシー、パートナ、セッション、一時データを含む様々なタイプの情報を処理します。
    

      

    • 

      アイデンティティ・データ用LDAP
      

      • 

    • 

      構成およびパートナ・データ用ファイル
      

      • 

    • 

      セッションおよび一時データ用Coherenceインメモリー
      

      • 

    • 

      ポリシー・データはファイルまたはRDBMSに格納されます
      

      • 

    

    • 

  • 

    Oracle Access Manager 10g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。
    

    • 

  • 

    Oracle Single Sign-On Apacheモジュールは、Oracle HTTP Server Webサーバーにデプロイすることを意図したCベースのエージェントです。
    

    • 

  • 

    Access Manager 11g WebGateは、Webサーバーにデプロイすることを意図したCベースのエージェントです。
    

    • 






9.2.1.1.1 Access Managerの状態情報


認証ユーザー・セッション情報は、Coherence分散オブジェクト・キャッシュを介して永続化されます。Access Managerに対しては、Coherence分散オブジェクト・キャッシュ・インメモリー・モードを使用します。


Access Managerによって、ログイン処理中に、認証されていないユーザーに対して一時状態が作成されることがあります。この状態は、通常、Access Managerノード間でレプリケートされません。ログイン処理中のノードの障害の影響を防止するために、オプションでその状態を暗号化されたクライアントCookieに格納することができます。


認証されていないユーザーの一時状態をログイン処理中に格納するには、次の手順に従ってOAMサーバー・パラメータRequestCacheTypeをBASICからCOOKIEに変更します。


    

  1. 

    次のコマンドを実行して、WLSTの環境を設定します。
    

    DOMAIN_HOME/bin/setDomainEnv.sh

    2. 

  2. 

    次のコマンドを発行して、WLSTを起動します。
    

    Start WLST by issuing this command:
ORACLE_HOME/common/bin/wlst.sh

    3. 

  3. 

    ドメインに接続します。
    

    wls:/IDM_Domain/serverConfig> connect()

    4. 

  4. 

    WebLogic管理ユーザー名とパスワードを入力し、管理サーバーのURLを次の形式で入力します。
    

    t3://OAMHOST1.mycompany.com:7001

    5. 

  5. 

    次のコマンドを発行します。
    

    wls:/IDM_Domain/serverConfig> configRequestCacheType(type="COOKIE")

    6. 

  6. 

    次のコマンドを発行して、コマンドが動作したことを確認します。
    

    wls:/IDM_Domain/serverConfig> displayRequestCacheType()

    7. 

  7. 

    Access Manager管理対象サーバーを再起動します。
    

    8. 









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


Access Managerのリクエスト・フローの手順を次に説明します。


    

  1. 

    ユーザーが、Access Managerによって保護されたWebリソースに、Webブラウザを使用してアクセスを試みます。
    

    2. 

  2. 

    Access Managerエージェント脚注1 によって、そのリクエストはインターセプトされ、ユーザーが認証済セッションを持っているかどうかの確認が試みられます。
    

    3. 

  3. 

    これは、ユーザーの最初のアクセスであるため、ユーザーは認証のためにAccess Manager 11gアクセス・サーバーにリダイレクトされます。
    

    4. 

  4. 

    アクセス・サーバーの資格証明コレクタ脚注2 ・コンポーネントによってログイン・フォームが表示されます。脚注3 ユーザーは、自身の資格証明をアクセス・サーバーに送信します。
    

    5. 

  5. 

    アクセス・サーバーによって、ユーザーの資格証明が検証され、セキュリティ・トークン(Cookie)が生成されます。ユーザーは、ステップ1でアクセスを試みたリソースにリダイレクトされます。
    

    6. 

  6. 

    Access Managerエージェントによってリクエストがインターセプトされ、セキュリティ・トークン(Cookie)が抽出されます。
    

    7. 

  7. 

    Access Managerエージェントによってアクセス・サーバーにバック・チャネル呼出し脚注4 (TCPを介したOAP)が行われ、セッションが検証され、リクエストが認可されます。
    

    8. 

  8. 

    アクセス・サーバーによって、そのWebリソースの構成済ポリシーに対してユーザーの権限が検証されます。
    

    9. 

  9. 

    アクセス・サーバーは、WebGateリクエストに応答し、そのアクセスが許可されることを示します。
    

    10. 

  10. 

    Access Managerエージェントによって、リクエストの通過が許可されます。脚注5 
    

    11. 

  11. 

    ユーザーは、手順1でアクセスを試みたWebリソースにアクセスできるようになります。
    

    12. 






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


アクセス・サーバーと管理コンソールは、WebLogic Serverの提供するユーザー・インタフェースおよびコマンドライン・ツールから起動できます。


アクセス・サーバーは、障害の検出のためにロード・バランサで使用できるヘルス・チェック・リクエスト(HTTPを介したpingリクエスト)をサポートしています。


Access Managerエージェントは、保護されたアプリケーション環境に常駐するネイティブ・アプリケーションです。OAMの一部として提供されているツールはありませんが、環境固有のツールが使用可能な場合は、それが前述の目的で使用されます。


Access Managerは、サーバー・サイド・メトリック用(DMSを使用)にインスツルメント処理されており、この情報はWebLogic管理コンソールに公開されます。コンポーネントの監視のかわりとして、DMSメトリック収集を使用してエージェントおよびサーバー・コンポーネント・メトリックを監視できます。さらに、Access Managerは、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。


アクセス・サーバーは、起動時にバックエンド・リポジトリへの接続を初期化します。リポジトリに到達不能な場合、アクセス・サーバーはリポジトリへの接続を再試行します。この接続の再試行には指数関数的に増加するタイムアウトが使用されます。タイムアウトの上限は構成可能です。


アクセス・サーバーは、バックエンド接続が停止した場合はローカルにキャッシュしたデータに基づいてサービスの継続性を提供します。これは、キャッシュが失効するか、バックエンド接続が復活するまで継続されます。








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


Access Managerの構成アーティファクトには、次のファイルが含まれています。


    

  • 

    DOMAIN_HOME/config/fmwconfig/oam-configuration.xml
    

    構成ファイル。インスタンス固有の情報が含まれています。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/oam-policy.xml
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/.oamkeystore
    

    これは、対称鍵および非対称鍵の格納に使用されます。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/component_events.xml
    

    監査定義に使用されます。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/jazn-data.xml
    

    管理コンソールの権限に使用されます。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/servers/インスタンス名/logging.xml
    

    ロギング構成に使用されます。このファイルは、手動では編集しないでください。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/servers/インスタンス名/dms_config.xml
    

    トレース・ロギングに使用されます。このファイルは、手動では編集しないでください。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/cwallet.sso
    

    OAMがアイデンティティ・ストア、データベースおよびその他のエンティティへの接続に使用するストア・パスワードに使用されます。これは、エンド・ユーザー用のパスワードではありません。
    

    • 









9.2.1.1.5 Access Managerの外部依存性


Access Managerは、次の項目に対して外部ランタイム依存性があります。


    

  • 

    LDAPベースのアイデンティティ・ストア
    

      

    • 

      ユーザー・アイデンティティ・リポジトリ
      

      • 

    • 

      ユーザー/ロールAPIによって抽象化されるLDAPアクセス
      

      


      

      


      


      注意:
      

      Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。
      
      		

      
      

      

      

      

      • 

    

    • 

  • 

    OCSPレスポンダ・サービス
    

      

    • 

      リアルタイムX.509認証検証
      

      • 

    

    • 

  • 

    RDBMSポリシー・ストア
    

      

    • 

      ポリシー(認証および認可)リポジトリ
      

      • 

    • 

      OAMポリシー・エンジンによって抽象化されるRDBMSアクセス
      

      • 

    

    • 

  • 

    Oracle Identity Manager(OIMベースのパスワード管理が有効化されている場合)
    

      

    • 

      Oracle Identity Managerはパスワード管理サービスを提供します。これはOracle Access Manager 10g Identity Serverにかわるものです。
      

      • 

    

    • 

  • 

    Oracle Identity Managerポリシー・ストア(Oracle Identity Managerベースのパスワード管理が有効化されている場合)
    

      

    • 

      構成、メタデータなどを格納するために使用されるOblixスキーマ要素を含むLDAPリポジトリ
      

      • 

    

    • 

  • 

    Oracle Adaptive Access Manager(Oracle Adaptive Access Managerの拡張認証スキームが選択されている場合)
    

    • 

  • 

    Identity Federation(Identity Federationの認証スキームが選択されている場合)
    

    • 






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


Access ManagerはWebLogic Server上にデプロイされます。すべてのログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。デフォルトのサーバー・ログの場所は次のとおりです。


WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log















9.2.2 Access Managerの高可用性の概要


この項では、Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。





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


図9-4は、Access Managerの高可用性アーキテクチャを示しています。




図9-4 Access Managerの高可用性アーキテクチャ

図9-4の説明が続きます
 「図9-4 Access Managerの高可用性アーキテクチャ」の説明
 



図9-4では、着信認証リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohs.confが使用されてWebLogic管理対象サーバーにリクエストが転送されます。分散型資格証明コレクタにより、Webゲートが資格証明を収集し、OAPプロトコルによりAccess Managerサーバーに送信することが可能になります。


ロード・バランシング・ルーターは、HTTPトラフィックに対してのみセッション・スティックネスを使用する必要があります。OAPトラフィックは、ロード・バランシング・ルーターを使用しません。そのため、OAPトラフィックに対してはセッション・スティックネスは必要ありません。


他のOracle HTTP Serverからアクセスされ、さらにはアクセスが制限されているリソースを持つアプリケーションには、WebGate、Oracle Single Sign-On Serverエージェント(mod_ossoエージェント)、OpenSSOポリシー･エージェントまたはカスタム・エージェントを構成する必要があります。WEBHOST3上のWebGateは、OAPを使用してアプリケーション層のOAMHOST1およびOAMHOST2上のアクセス・サーバーと通信します。WEBHOST3は、アプリケーションWebサーバーであり、認証のためにHTTPリダイレクトを使用して、リクエストをロード・バランサへ、そしてWEBHOST1およびWEBHOST2にルーティングします。高可用性デプロイメントにするために、オプションでWEBHOST3と同じコンポーネントを持つホストをもう1つ(たとえばWEBHOST4)を構成できます。


OAMHOST1およびOAMHOST2は、Oracle Access Serverアプリケーションをホストする管理対象サーバーをデプロイします。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。


Oracle WebLogic管理サーバーはOAMHOST1上で実行され、WebLogic管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Access Managementコンソールをデプロイします。管理サーバーは、OAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAMHOST1が使用不可になった場合に、管理サーバーをOAMHOST2上で手動で起動できます。


ディレクトリ層で、仮想IP ovd.mycompany.comは、Oracle Virtual DirectoryリクエストをOVDHOST1とOVDHOST2にルーティングするように設定されます。OVDHOST1とOVDHOST2は、アクティブ/アクティブのOracle Virtual Directoryクラスタを構成します。仮想IP oid.mycompany.comは、Oracle Internet DirectoryリクエストをOIDHOST1とOIDHOST2にルーティングするように設定されます。OIDHOST1とOIDHOST2は、アクティブ/アクティブのOracle Internet Directoryクラスタを構成します。


Oracle RACデータベースは、データ層における高可用性を提供します。


Access Manager 11gでは、WebLogic ServerドメインごとにサポートされるAccess Managerクラスタは1つのみです。Access Managerクラスタは、複数のWebLogic Serverドメインにわたることはできません。


単一インスタンスのAccess Managerデプロイメントは、次の高可用性要件を満たします。


    

  • 

    ロード処理
    

    • 

  • 

    外部接続管理と監視
    

    • 

  • 

    リカバリ
    

    • 

  • 

    フォルト包含
    

    • 

  • 

    フォルト診断
    

    • 

  • 

    管理サーバーのオフライン
    

    • 



複数インスタンスのAccess Managerデプロイメントは、さらに次の高可用性要件を満たします。


    

  • 

    冗長性
    

    • 

  • 

    クライアント接続のフェイルオーバー/継続性
    

    • 

  • 

    クライアントのロード・バランシング
    

    • 

  • 

    状態管理
    

    • 



インバウンドHTTP接続の場合は、外部ロード・バランシング・ルーターの使用をお薦めします。LDAPサーバー(またはOAMポリシー・エンジンPDP/PIP)へのアウトバウンド外部接続はロード・バランシングされ、接続フェイルオーバーに対してもサポートされます。Access Managerエージェント、通常Webゲートは、複数のアクセス・サーバーにわたる接続をロード・バランシングできます。


Access Managerエージェントは、アクセス・サーバーへの永続TCP接続を開きます。これには、TCP接続の早すぎる終了を回避するためにファイアウォール接続タイムアウトを十分大きい値にする必要があります。


アクセス・サーバーとAccess Manager管理コンソールは、ポリシー評価および管理のために、OAMポリシー・エンジンと連動します。OAMポリシー・エンジンは、ポリシー・リポジトリとしてのデータベースに内部依存します。データベースの相互作用はOAMポリシー・エンジン内にカプセル化され、Access Managerからは、その接続構成情報のみを管理できます。Access ManagerとOAMポリシー・エンジン間の相互作用の高可用性の特性は、次のとおりです。


    

  • 

    データベース接続情報は、Access Managerインスタンス間で同期されるAccess Manager構成ファイルで構成されます。
    

    • 

  • 

    データベース通信はOAMポリシー・エンジン内で管理され、通常、Access ManagerとOAMポリシー・エンジンの相互作用からは分離されます。ただし、OAMサーバー・インスタンスの最初の起動は、データベースに到達不能な場合、失敗します。OAMポリシー・エンジンのブートストラップの障害はAccess Managerによって致命的として処理され、起動操作は中断されます。
    

    • 

  • 

    一時的なデータベースの使用不能は、OAMポリシー・エンジン・ポリシー評価サービスによって透過的に許容され、Access Managerサーバー・ランタイムは中断されることなく継続的に機能します。最初のOAMポリシー・エンジンのブートストラップの後、データベースが到達不能でも、Access Managerインスタンスは再起動でき、OAMポリシー・エンジンはそのローカルにキャッシュされたポリシーに対して処理を継続します。
    

    • 

  • 

    Access Managerポリシー管理インタフェース(Oracle Access ManagementコンソールおよびCLIツール内)は、OAMポリシー・エンジン管理サービス・インタフェースからみてデータベースが到達不能である場合に失敗します。操作は後で再試行できますが、管理操作に対して自動化された再試行は提供されていません。
    

    • 

  • 

    データベース・リポジトリでポリシーが変更されると、OAMサーバー・ランタイムのOAMポリシー・エンジン・レイヤーが、(Access Managerの構成で構成される)構成可能なOAMポリシー・エンジン・データベース・ポーリング間隔内でその変更を取得し、アクティブ化します。ポリシー変更の肯定応答を、各OAMサーバー・ランタイムから受信する必要がありますが、それ以外の場合は、そのポリシー変更はアクティブ化に成功したとみなされません。管理者は、Oracle Access Managementコンソールを使用して、サービスから、ポリシー・アクティブ化が失敗したAccess Managerインスタンスを削除できます。
    

    • 






9.2.2.1.1 クラスタの起動と停止


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


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


高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。





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


Access Managerが使用する標準Java EEアーティファクトは、Access ManagerがインストールされているOracle WebLogicのドメインの一部として構成されます。Oracle WebLogicクラスタは、WebLogic Serverドメイン全体にわたる、データ・ソースなどのアーティファクトの自動構成同期化機能を提供します。同時に、WebLogic Serverクラスタは、デプロイメントと、Access Managerコンポーネントで使用されるライブラリを同期します。


さらに、Access Managerのアプリケーション・レベルの構成は、Access Managerリポジトリに格納されます。すべてのクラスタ・メンバーへのAccess Managerの構成変更の伝播は、Coherence分散オブジェクト・キャッシュを活用する配布メカニズムに基づきます。すべてのAccess Managerコンポーネントは、変更イベントをCoherenceレイヤーから通知されて取得します。変更の原子性を確保するために、Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。


Access Managerの構成は、クラスタ内のすべてのインスタンスに適用されます。Access Managerでサポートされる前述の構成(インスタンス固有の構成)の例外は、Access Managerプロキシ・ホスト、Access Managerプロキシ・ポートおよびインスタンス固有のCoherence構成(Well Knownアドレス(WKA)が使用されている場合)のみです。プロキシ・ホストのIPアドレスおよびプロキシ・ポートは、構成ファイルに格納されます。Access Managerプロキシ・ポートは、エージェントからのOAPリクエストのエンドポイントです。Coherence WKAのIPアドレスも、構成ファイルに格納されます。Coherence WKAは、Access Manager固有のトラフィックを受信する権限を付与されたCoherenceノードを判別するために使用されます。oam-configuration.xmlファイルは、この構成情報を格納する構成ファイルです。


アクセス・サーバー・インスタンスの追加および削除は、クラスタ内の他のAccess Manager Access Serverインスタンスに対して透過的です。ただし、特定のアクセス・サーバーの削除が、エージェントのロード・バランシングとフェイルオーバーの特性に影響を与えないように注意してください。


Access Manager Access Serverを再起動しても、クラスタ内の他の実行中のコンポーネントやメンバーには影響ありません。












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


この項では、Oracle Identity Managementの高可用性クラスタ・デプロイメントによって、コンポーネントを障害から保護する仕組みと、コンポーネントの障害が発生したときに予想される動作について説明します。


WebLogic Serverインフラストラクチャにより、Identity Managementサービス・インフラストラクチャ・システムは、あらゆるプロセス障害から保護されます。


また、次の機能もAccess Managerの高可用性構成を障害から保護します。


    

  • 

    バック・チャネルOAPバインディングでは、フェイルオーバーのためにプライマリ/セカンダリ・モデルが使用されます。フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。
    

    • 

  • 

    セッションの状態は、Coherence分散オブジェクト・キャッシュで保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。Coherenceキャッシュに格納されたデータは、データベースに非同期的に書き込まれます。このデータは、すべてのアクセス･サーバーが再起動されても保持されます。ただし、書込みの非同期的な性質により少量のデータが失われる可能性があります。
    

    • 

  • 

    アクセス・サーバーで障害が発生した場合、そのサーバーへの永続接続を持つWebGateは、接続がタイムアウトするまで待機し、その後にセカンダリ(バックアップ)アクセス・サーバーに切り替えます。未処理のリクエストは、セカンダリ・サーバーにフェイルオーバーされます。
    

    • 

  • 

    Access Manager Access Serverは、ハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視して、そのアプリケーションを再起動できます。
    

    • 

  • 

    WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。
    

    • 

  • 

    ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、そのセッション状態を取得して処理を継続します。
    

    • 

  • 

    接続の存続時間が期限切れした場合、保留中のリクエストは接続が終了する前に完了します。接続オブジェクトはプールに戻されます。
    

    • 

  • 

    別のサービスから例外を受信した場合、Access Managerは、外部接続リクエストを再試行します。再試行回数は設定が可能です。
    

    • 






9.2.2.2.1 WebLogic Serverのクラッシュ


WLS_OAMxサーバーで障害が発生すると、ノード・マネージャはこのサーバーの再起動をローカルで試行します。


HTTP Serverからの処理中のリクエストはタイムアウトして、新しいリクエストは他のWLS_OAMxサーバーに送られます。障害が発生したノードでサーバーが正常に再起動されると、Oracle HTTP Serverは、受信したリクエストのサーバーへのルーティングを再開します。













注意:


Access Managerサーバーは、アクセス・サーバーがそのリクエストにサービスを提供できるかどうかを判別するため、ハートビート・チェックをサポートします。次のチェックを行います。


    

  • 

    LDAPストアにアクセスできるかどうか。
    

    • 

  • 

    ポリシー・ストアにアクセスできるかどうか。
    

    • 



ハートビート・チェックに成功した場合、アクセス・サーバーはリクエストの処理が可能であり、リクエストがそれに送信されます。ハートビート・チェックで問題がある場合、リクエストはアクセス・サーバーにルーティングされません。


















9.2.2.2.2 ノード障害


ノード障害は、WebLogic Serverの障害と同じ方法で処理されます。








9.2.2.2.3 データベース障害


Access Managerサービス・インフラストラクチャは、マルチ・データ・ソースの使用によりデータベースの障害から保護されます。通常、これらのマルチ・データ・ソースは、システムの初期設定時に構成されます(Oracle Fusion Middleware構成ウィザードで、インストール時にこれらのマルチプールを直接定義できます)。これらのソースによって、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。


Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。












9.2.3 Access Managerの高可用性の構成手順


この項では、Access Managerで高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAMサーバーに配布します。これらのOAMサーバーは、Oracle Real Application Clusters (Oracle RAC)データベースおよび、(オプションで)外部LDAPストアと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。


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






9.2.3.1 Access Managerの構成のための前提条件


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









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


作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。RCUを実行するには、Oracle Fusion Middlewareインストレーション計画ガイドおよびOracle Fusion Middlewareリポジトリ作成ユーティリティ･ユーザーズ･ガイドを参照してください。








9.2.3.3 Oracle WebLogic Serverのインストール


Oracle WebLogic Serverをインストールする前に、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』で指定されているように、ご使用のマシンのシステム、パッチ、カーネルの要件、およびその他の要件が満たされていることを確認します。


インストーラを起動し、次の手順を実行します。


    

  1. 

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

    2. 

  2. 

    「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
    

    「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
    

    ORACLE_BASE/product/fmw
    

    


    

    


    


    注意:
    

    ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。推奨値は/u01/app/oracleです。
    
    		

    
    

    

    

    

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

    3. 

  3. 

    セキュリティ・アップデートが通知できるようにするために、連絡先情報を入力します。
    

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

    4. 

  4. 

    「インストール・タイプの選択」画面で、「カスタム」を選択します。
    

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

    5. 

  5. 

    「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。
    

    6. 

  6. 

    「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。
    

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

    7. 

  7. 

    「インストールの概要」画面で「次へ」をクリックします。
    

    8. 

  8. 

    「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
    

    「完了」をクリックします。
    

    9. 









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


この項では、Oracle Fusion MiddlewareコンポーネントをOAMHOST1およびOAMHOST2にインストールする方法について説明します。





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


この項では、Oracle Identity Managementソフトウェアを、前に作成したMiddlewareホーム・ディレクトリにインストールする手順について説明します。OAMHOST1およびOAMHOST2上で手順を実行します。


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


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


OAMHOST1> runInstaller



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


次のように実行します。


    

  1. 

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

    2. 

  2. 

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

    3. 

  3. 

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

      

    • 

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

      /u01/app/oracle/product/fmw

      • 

    • 

      Oracleホーム・ディレクトリ: idmを入力します。
      

      • 

    

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

    4. 

  4. 

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

    5. 

  5. 

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

    6. 









9.2.3.4.2 OAMHOST1でのOracle Identity Managementの構成


この項では、OAMHOST1にOracle Identity Managementドメインを作成します。


次のコマンドを実行して、構成ウィザードを起動します。


MW_HOME/oracle_common/common/bin/config.sh



次のように実行します。


    

  1. 

    「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
    

    2. 

  2. 

    「ドメイン・ソースの選択」画面で、次を選択します。
    

    「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
    

    次の製品を選択します。
    

      

    • 

      Oracle Enterprise Manager
      

      • 

    • 

      Oracle JRF(デフォルトで選択)
      

      • 

    • 

      Oracle Access Management
      

      • 

    • 

      Oracle Platform Security Service
      

      • 

    

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

    3. 

  3. 

    「ドメイン名と場所の指定」画面で、次を入力します。
    

      

    • 

      ドメイン名: IDM_Domain
      

      • 

    • 

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

      • 

    • 

      アプリケーション・ディレクトリ: デフォルトを受け入れます。
      

      • 

    

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

    4. 

  4. 

    「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
    

    5. 

  5. 

    「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
    

      

    • 

      WebLogicドメインの起動モード: 「本番モード」を選択します。
      

      • 

    • 

      JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。
      

      • 

    

    6. 

  6. 

    「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
    

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

    7. 

  7. 

    「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAMインフラストラクチャを選択し、次の項目を入力します。
    

      

    • 

      データ・ソース: OAM
      

      • 

    • 

      サービス名: oam.mycompany.com
      

      • 

    • 

      ユーザー名: OAM_OAM(OAMがRCU接頭辞として使用されていたと想定)
      

      • 

    • 

      パスワード: 前述のアカウント用のパスワード
      

      • 

    

    右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
    

      

    • 

      ホスト名: OAMDBHOST1
      

      • 

    • 

      インスタンス名: oamdb1
      

      • 

    • 

      ポート: 1521
      

      • 

    

    再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
    

      

    • 

      ホスト名: OAMDBHOST2
      

      • 

    • 

      インスタンス名: oamdb2
      

      • 

    • 

      ポート: 1521
      

      • 

    

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

    8. 

  8. 

    「コンポーネント・スキーマのテスト」画面で、データ・ソースの検証が試行されます。
    

    データ・ソースの検証が成功した場合、「次へ」をクリックします。
    

    失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。
    

    9. 

  9. 

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

      

    • 

      管理サーバー
      

      • 

    • 

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

      • 

    

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

    10. 

  10. 

    「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
    

    11. 

  11. 

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

      

    • 

      名前: AdminServer
      

      • 

    • 

      Listen address: OAMHOST1.mycompany.com
      

      • 

    • 

      リスニング・ポート: 7001
      

      • 

    • 

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

      • 

    • 

      SSL有効: 選択を解除
      

      • 

    

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

    12. 

  12. 

    「管理対象サーバーの構成」画面で、トポロジのOAMHOSTごとにエントリを作成します。つまり、OAMHOST1上で実行されているOAMサーバーに対して1つと、OAMHOST2上で実行されているOAMサーバーに対して1つ作成します。
    

    OAM_SERVERエントリを選択し、そのエントリを次の値に変更します。
    

      

    • 

      名前: WLS_OAM1
      

      • 

    • 

      Listen address: OAMHOST1.mycompany.com
      

      • 

    • 

      リスニング・ポート: 14100
      

      • 

    

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

      

    • 

      名前: WLS_OAM2
      

      • 

    • 

      Listen address: OAMHOST2.mycompany.com
      

      • 

    • 

      リスニング・ポート: 14100
      

      • 

    

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

    13. 

  13. 

    「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
    

    名前としてOAM_Clusterを入力します。
    

    その他すべてのフィールドはデフォルトの設定のままにします。
    

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

    14. 

  14. 

    「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。
    

      

    • 

      右のウィンドウでクラスタ名OAM_Clusterをクリックします。
      

      • 

    • 

      管理対象サーバーWLS_OAM1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。
      

      • 

    • 

      管理対象サーバーWLS_OAM2に対しても同様に繰り返します。
      

      • 

    

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

    15. 

  15. 

    「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を指定します。
    

      

    • 

      名前: ホスト名です。ベスト・プラクティスは、DNS名(OAMHOST1)を使用することです。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAMHOST1.mycompany.com)
      

      • 

    • 

      ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
      

      • 

    

    OAMHOST2に対しても次のように手順を繰り返します。
    

      

    • 

      名前: ホスト名です。ベスト・プラクティスは、DNS名(OAMHOST2)を使用することです。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAMHOST2.mycompany.com)
      

      • 

    • 

      ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
      

      • 

    

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

    16. 

  16. 

    「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。
    

      

    • 

      右のウィンドウでマシンOAMHOST1をクリックします。
      

      • 

    • 

      左のウィンドウで管理対象サーバーWLS_OAM1をクリックします。
      

      • 

    • 

      矢印をクリックし、その管理対象サーバーをホストOAMHOST1に割り当てます。
      

      • 

    • 

      右のウィンドウでマシンOAMHOST2をクリックします。
      

      • 

    • 

      左のウィンドウで管理対象サーバーWLS_OAM2をクリックします。
      

      • 

    • 

      矢印をクリックし、その管理対象サーバーをホストOAMHOST2に割り当てます。
      

      • 

    

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

    17. 

  17. 

    「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。
    

    18. 














注意:


構成を変更するためにconfig.shスクリプトを2回実行することはできないため、構成に追加の変更を行う場合は、Fusion Middleware ControlのMBeansブラウザの使用などの別のツールを使用する必要があります。




















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


ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、第9.1.3.3項「ドメイン用のデータベース・セキュリティ・ストアの構成」を参照してください。








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


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


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


    

  1. 

    OAMHOST1で、次のディレクトリに移動します。
    

    MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

    

    例:
    

    cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

    2. 

  2. 

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

    username=adminUser
password=adminUserPassword

    

    


    

    


    


    注意:
    

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

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

    
    

    

    

    

    3. 

  3. 

    管理サーバーが実行されている場合は停止します。
    

    WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
    

    4. 

  4. 

    MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OAMHOST1の管理サーバーを起動します。
    

    5. 

  5. 

    Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
    

      

    • 

      WebLogic Server管理コンソール:
      

      http://oamhost1.mycompany.com:7001/console

      • 

    • 

      Oracle Enterprise Manager Fusion Middleware Control:
      

      http://oamhost1.mycompany.com:7001/em

      • 

    

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

    6. 









9.2.3.7 OAMHOST1の起動


この項では、OAMHOST1の起動手順について説明します。





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


コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:


OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh







9.2.3.7.2 ノード・マネージャの起動


次のコマンドを発行してノード・マネージャを起動します。


OAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh







9.2.3.7.3 OAMHOST1上のAccess Managerの起動


OAMHOST1上のAccess Managerを起動する手順は、次のとおりです。


    

  1. 

    次のURLを使用して、WebLogic管理コンソールにログインします。
    

    http://oamhost1.mycompany.com:7001/console

    2. 

  2. 

    WebLogic管理者のユーザー名とパスワードを指定します。
    

    3. 

  3. 

    「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
    

    4. 

  4. 

    「制御」タブをクリックします。
    

    5. 

  5. 

    サーバーWLS_OAM1をクリックします。
    

    6. 

  6. 

    「起動」をクリックします。
    

    7. 

  7. 

    「OK」をクリックし、サーバーを起動することを確認します。
    

    8. 











9.2.3.8 OAMHOST1の検証


実装を検証するには、次のURLにあるOracle Access Managementコンソールに接続します。


http://OAMHOST1.mycompany.com:7001/oamconsole



OAM管理コンソールのログイン・ページが開き、WebLogic administratorアカウントを使用してログインできる場合、実装は有効です。








9.2.3.9 OAMHOST2でのOAMの構成


OAMHOST1で構成を完了したら、それをOAMHOST2に伝播できます。これを実行するには、OAMHOST1でpackスクリプトを使用してドメインをパックし、OAMHOST2でunpackスクリプトを使用してドメインを解凍します。


スクリプトは両方とも、MW_HOME/oracle_common/common/binディレクトリにあります。


OAMHOST1で、次のように入力します。


pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true



これにより、/tmpディレクトリにidm_domain.jarというファイルが作成されます。このファイルをOAMHOST2にコピーします。


OAMHOST2で、次のように入力します。


unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar







9.2.3.10 OAMHOST2の起動


この項では、OAMHOST2を起動する手順について説明します。





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


コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:


OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh







9.2.3.10.2 ノード・マネージャの起動


次のコマンドを発行してノード・マネージャを起動します。


OAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh







9.2.3.10.3 OAMHOST2上のAccess Managerの起動


OAMHOST2上のAccess Managerを起動する手順は、次のとおりです。


    

  1. 

    次のURLを使用して、WebLogic管理コンソールにログインします。
    

    http://oamhost2.mycompany.com:7001/console

    2. 

  2. 

    WebLogic管理者のユーザー名とパスワードを指定します。
    

    3. 

  3. 

    「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
    

    4. 

  4. 

    「制御」タブをクリックします。
    

    5. 

  5. 

    サーバーWLS_OAM2をクリックします。
    

    6. 

  6. 

    「起動」をクリックします。
    

    7. 

  7. 

    「OK」をクリックし、サーバーを起動することを確認します。
    

    8. 











9.2.3.11 OAMHOST2の検証


次のURLを使用してOAMサーバーに接続することによって実装を検証します。


http://OAMHOST2.mycompany.com:14100/oam



OAMログイン・ページが表示される場合、実装は有効です。この時点では、アクションが失敗したことを示すエラーがページに表示されることに注意してください。これは、ログイン・リクエストとしてではなくページに直接アクセスしたためであり、正常な動作です。








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


この項では、Oracle HTTP Serverと連携するためのAccess Managerの構成手順について説明します。





9.2.3.12.1 Oracle HTTP Server構成の更新


WEBHOST1およびWEBHOST2で、次のディレクトリにoam.confというファイルを作成します。


ORACLE_INSTANCE/config/OHS/ohs1/moduleconf



次の行を指定してファイルを作成します。


NameVirtualHost *:7777
<VirtualHost *:7777>
 
    ServerName sso.mycompany.com:7777
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

    <Location /oam>
        SetHandler weblogic-handler
        Debug ON
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        oamhost1.mycompany.com:14100,oamhost2.mycompany.com:14100
        WebLogicCluster
    </Location>

    <Location /oamfed>
        SetHandler weblogic-handler
        Debug ON
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WebLogicCluster 
        oamhost1.mycompany.com:14100,oamhost2.mycompany.com:14100
    </Location>

</VirtualHost>







9.2.3.12.2 Oracle HTTP Serverの再起動


WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。


WEBHOST1>opmnctl stopall
WEBHOST1>opmnctl startall

WEBHOST2>opmnctl stopall
WEBHOST2>opmnctl startall







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


デフォルトでは、Access Managerではローカル・サーバーにあるログイン・ページにリクエストに送信します。高可用性デプロイメントでは、この設定を変更してログイン・ページ・リクエストがローカル・バランサに送信されるようにする必要があります。


Access Managerにロード・バランサを認識させる手順は、次のとおりです。


    

  1. 

    次のURLで、Oracle Access Managementコンソールにweblogicユーザーとしてログインします。
    

    http://IDMHOST1.mycompany.com/oamconsole

    2. 

  2. 

    「システム構成」タブをクリックします。
    

    3. 

  3. 

    Access Managerの設定を開きます。
    

    4. 

  4. 

    Access Managerの設定をダブルクリックします。
    

    5. 

  5. 

    次の情報を入力します。
    

      

    • 

      OAMサーバー・ホスト: sso.mycompany.com
      

      • 

    • 

      OAMサーバー・ポート: 7777
      

      • 

    • 

      OAMサーバー・プロトコル: http
      

      • 

    

    6. 

  6. 

    「適用」をクリックします。
    

    7. 

  7. 

    管理対象サーバーWLS_OAM1およびWLS_OAM2を再起動します。
    

    8. 











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


デフォルトでは、Access Managerでは、組込みLDAPサーバーにある独自コンポーネントを使用します。高可用性構成では、ディレクトリ・ストアとして外部LDAPディレクトリを使用することをお薦めします。この項では、外部LDAPストアの設定方法について説明します。













注意:


この項で説明する手順を実行する前に、環境およびLDAPストアをバックアップしておくことをお薦めします。















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


アイデンティティ・ストアを事前構成することで、ディレクトリ・タイプに関係なくバックエンド・ディレクトリのスキーマを拡張します。


Access Managerのためにディレクトリ・スキーマを拡張するには、OAMHOST1上で次のタスクを実行します。


    

  1. 

    環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
    

    IDM_HOMEをIDM_ORACLE_HOMEに設定します。
    

    ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
    

    2. 

  2. 

    次の項目を含む、プロパティ・ファイルextend.propsを作成します。
    

    IDSTORE_HOST : idstore.mycompany.com

    

    IDSTORE_PORT : 389

    

    IDSTORE_BINDDN : cn=orcladmin

    

    IDSTORE_USERNAMEATTRIBUTE: cn

    

    IDSTORE_LOGINATTRIBUTE: uid

    

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

    

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

    

    IDSTORE_SEARCHBASE: dc=mycompany,dc=com

    

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

    

    

    説明:
    

      

    • 

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

      • 

    • 

      IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
      

      • 

    • 

      IDSTORE_USERSEARCHBASEは、ユーザーを配置するアイデンティティ・ストアの場所です。
      

      • 

    • 

      IDSTORE_GROUPSEARCHBASEは、グループを配置するアイデンティティ・ストアの場所です。
      

      • 

    • 

      IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。
      

      • 

    • 

      IDSTORE_SYSTEMIDBASEは、Oracle Identity Managerリコンシリエーション・ユーザーを配置するディレクトリの場所です。
      

      • 

    • 

      IDSTORE_SYSTEMIDBASEは、メイン・ユーザー・コンテナに配置する必要のないユーザーを配置できるディレクトリにあるコンテナの場所です。このような事態はほとんどありませんが、その一例としてOracle Virtual DirectoryアダプタのバインドDNユーザーにも使用されるOracle Identity Managerリコンシリエーション・ユーザーがあげられます。
      

      • 

    

    3. 

  3. 

    idmConfigToolコマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
    

    Linuxコマンドの構文:
    

    idmConfigTool.sh -preConfigIDStore input_file=configfile
    

    Windowsコマンドの構文:
    

    idmConfigTool.bat -prepareIDStore input_file=configfile
    

    例:
    

    idmConfigTool.sh -preConfigIDStore input_file=extend.props

    

    

    このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。
    

    次に、コマンドの出力例を示します。
    

    Enter ID Store Bind DN password : 
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif
The tool has completed its operation. Details have been logged to automation.log

    

    4. 

  4. 

    ログ・ファイルを確認して、エラーや警告を修正します。
    

    5. 









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


Access Managerが必要とするユーザーをアイデンティティ・ストアに追加する手順は、次のとおりです。


    

  1. 

    環境変数MW_HOME、JAVA_HOME、IDM_HOMEおよびORACLE_HOMEを設定します。
    

      

    • 

      IDM_HOMEをIDM_ORACLE_HOMEに設定します。
      

      • 

    • 

      ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
      

      • 

    

    2. 

  2. 

    次の項目を含む、プロパティ・ファイルoam.propsを作成します。
    

    IDSTORE_HOST : idstore.mycompany.com

    

    IDSTORE_PORT : 389

    

    IDSTORE_BINDDN : cn=orcladmin

    

    IDSTORE_USERNAMEATTRIBUTE: cn

    

    IDSTORE_LOGINATTRIBUTE: uid

    

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

    

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

    

    IDSTORE_SEARCHBASE: dc=mycompany,dc=com

    

    POLICYSTORE_SHARES_IDSTORE: true

    

    OAM11G_IDSTORE_ROLE_SECURITY_ADMIN:OAMAdministrators

    

    IDSTORE_OAMSOFTWAREUSER:oamLDAP

    

    IDSTORE_OAMADMINUSER:oamadmin
IDSTORE_SYSTEMIDBASE:cn=systemids,dc=mycompany,dc=com 

    

    説明:
    

      

    • 

      IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。
      

      • 

    • 

      IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。
      

      • 

    • 

      IDSTORE_USERSEARCHBASEは、ユーザーが格納されるディレクトリの場所です。
      

      • 

    • 

      IDSTORE_GROUPSEARCHBASEは、グループが格納されるディレクトリの場所です。
      

      • 

    • 

      IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。
      

      • 

    • 

      POLICYSTORE_SHARES_IDSTOREは、ポリシー・ストアとアイデンティティ・ストアが同じディレクトリに存在する場合にはtrueを設定します。そうでない場合は、falseを設定します。
      

      • 

    • 

      IDSTORE_OAMADMINUSERは、Access Manager管理者として作成するユーザーの名前です。
      

      • 

    • 

      IDSTORE_OAMSOFTWAREUSERは、LDAPに作成されるユーザーで、Access Managerが実行中にLDAPサーバーに接続するために使用されます。
      

      • 

    

    3. 

  3. 

    idmConfigToolコマンドを使用して、アイデンティティ・ストアを作成します。このコマンドは、IAM_ORACLE_HOME/idmtools/binにあります。
    

    Linuxコマンドの構文:
    

    idmConfigTool.sh -prepareIDStore mode=OAM input_file=configfile
    

    Windowsコマンドの構文:
    

    idmConfigTool.bat -prepareIDStore mode=OAM input_file=configfile
    

    例:
    

    idmConfigTool.sh -prepareIDStore mode=OAM input_file=oam.props

    

    このコマンドを実行すると、IDストアへの接続に使用しているアカウントのパスワードを求めるプロンプトがシステムによって表示されます。
    

    次に、コマンドの出力例を示します。
    

    Enter ID Store Bind DN password : 
Apr 5, 2011 3:53:28 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

    

    

     /u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_schema_add.ldif
Apr 5, 2011 3:54:12 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_schema_index_add.ldif
Apr 5, 2011 3:55:10 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    

    

     /u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_pwd_schema_add.ldif
Apr 5, 2011 3:55:11 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oim_pwd_schema_add.ldif
*** Creation of Oblix Anonymous User ***
Apr 5, 2011 3:55:11 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING: 

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_10g_anonymous_user_template.ldif
Enter User Password for oblixanonymous: 
Confirm User Password for oblixanonymous: 
Apr 5, 2011 3:55:53 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

    

    

    /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_group_member_template.ldif
The tool has completed its operation. Details have been logged to automation.log

    

    4. 

  4. 

    ログ・ファイルを確認して、エラーや警告を修正します。
    

    5. 



idmConfigToolコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Management Suite統合概要を参照してください。








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


ユーザー・アイデンティティ・ストアを作成する手順は、次のとおりです。


    

  1. 

    次のURLのOracle Access Managementコンソールに移動します。
    

    http://adminvhn.mycompany.com:7001/oamconsole

    2. 

  2. 

    WebLogic管理ユーザーを使用してログインします。
    

    3. 

  3. 

    「システム構成」→「データソース」を選択します。
    

    4. 

  4. 

    「ユーザー・アイデンティティ・ストア」を選択して、「追加」をクリックします。次の情報を入力します。
    

      

    • 

      ストア名: LDAP_DIR
      

      • 

    • 

      ストア・タイプ: OVD
      

      • 

    • 

      説明: ディレクトリ・ストアの説明を入力します
      

      • 

    • 

      SSLの有効化: これは、SSLを使用してディレクトリと通信する場合に選択します
      

      • 

    • 

      場所: 場所を入力します(例: ovd.mycompany.com:389)
      

      • 

    • 

      バインドDN: LDAPストアを検索する権限を与えるユーザーを入力します。例: cn=orcladmin
      

      • 

    • 

      パスワード: oracleadminパスワードを入力します
      

      • 

    • 

      ユーザー名属性: たとえば、uidとします。
      

      • 

    • 

      ユーザー検索ベース: LDAPストアのユーザーの場所を入力します。例: cn=Users,dc=mycompany,dc=com
      

      • 

    • 

      グループ名属性: 例: orclguid
      

      • 

    • 

      グループ検索ベース: LDAPストアのグループの場所を入力します。例: cn=Groups,dc=mycompany,dc=com
      

      • 

    • 

      OAM管理者ロール: OAMAdministrators
      

      • 

    

    5. 

  5. 

    「適用」をクリックします。
    

    6. 

  6. 

    「接続テスト」をクリックし、LDAPサーバーへの接続を検証します。
    

    7. 









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


LDAPアイデンティティ・ストアを定義したので、プライマリ認証ストアとして設定する必要があります。これを行うには、Oracle Access Managementコンソールで次の手順を実行します。


    

  1. 

    「システム構成」タブをクリックします。
    

    2. 

  2. 

    ナビゲーション・ペインから「データ・ソース - ユーザー・アイデンティティ・ストア」を選択します。
    

    3. 

  3. 

    「LDAP_DIR」をクリックします。
    

    4. 

  4. 

    「オープン」を「アクション」メニューで選択します。
    

    5. 

  5. 

    「デフォルト・ストアとして設定」をクリックします。
    

    6. 

  6. 

    「システム・ストアとして設定」をクリックします。
    

    7. 

  7. 

    「アクセス・システム管理者」の追加[+]アイコンをクリックします。
    

    8. 

  8. 

    検索名フィールドにOAM*を入力して、「検索」をクリックします。
    

    9. 

  9. 

    検索結果から「OAMAdministrators」を選択して、「選択済の追加」をクリックします。
    

    10. 

  10. 

    「適用」をクリックします。
    

    11. 

  11. 

    「システム管理者の検証」ウィンドウで、OAM管理者のユーザー名とパスワード(例: oamadmin)を入力します。
    

    12. 

  12. 

    「検証」をクリックします。
    

    13. 

  13. 

    「接続のテスト」をクリックして、接続をテストします。
    

    14. 









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


デフォルトでは、Access Managerは、ユーザーの検証に統合LDAPストアを使用します。LDAP認証モジュールを更新して、そのモジュールが新しい外部LDAPストアに対してユーザーを認証できるようにします。


LDAP認証モジュールが外部LDAPを使用するように更新する手順は、次のとおりです。


    

  1. 

    「システム構成」タブをクリックします。
    

    2. 

  2. 

    「Access Managerの設定」→「認証モジュール」→「LDAP認証モジュール」を選択します。
    

    3. 

  3. 

    「LDAP」をクリックします。
    

    4. 

  4. 

    「オープン」を「アクション」メニューで選択します。
    

    5. 

  5. 

    「ユーザー・アイデンティティ・ストア」をLDAP_DIRに設定します。
    

    6. 

  6. 

    「適用」をクリックします。
    

    7. 

  7. 

    管理対象サーバーの管理サーバー、WLS_OAM1およびWLS_OAM2を再起動します。
    

    8. 











9.2.3.14 Access Managerの構成の検証


http://oamhost1.mycompany.com:7001/oamconsoleでOracle Access Managementコンソールにoamadminとしてログインすることで、構成を検証します。








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


高可用性環境では、Oracleでは、Oracle Coherenceを使用して構成ファイルの同期を保ちます。Oracle Coherenceは、デフォルトではポート9095を使用しますが、これはOracle Access Managementコンソールを使用して変更できます。


URL (http://admin.example.com/oamconsole)を使用して、コンソールにログインし、次の手順を実行します。


    

  1. 

    「システム構成」タブをクリックします。
    

    2. 

  2. 

    ナビゲータでサーバーを展開します。
    

    3. 

  3. 

    ポートを変更する管理対象サーバーをダブルクリックします。
    

    4. 

  4. 

    「コヒーレンス」タブをクリックします。
    

    5. 

  5. 

    「ローカル・ポート」の値を目的の値に変更します。
    

    6. 

  6. 

    「適用」をクリックします。
    

    7. 

  7. 

    管理サーバーと、更新された管理対象サーバーと同じクラスタに配置されている管理対象サーバーすべてを再起動します。
    

    8. 









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


この項では、Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいAccess Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいAccess Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。





9.2.3.16.1 Access Managerのスケール・アップ


OAMをスケール・アップする手順は、次のとおりです。


Oracle WebLogic Server管理コンソール(http://oamhost1.mycompany.com:7001/console)にログインします。


    

  1. 

    管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
    

    2. 

  2. 

    「チェンジ・センター」で、「ロックして編集」をクリックします。
    

    3. 

  3. 

    拡張するホスト上のサーバーを選択します(例: WLS_OAM1)。
    

    4. 

  4. 

    「クローンの作成」をクリックします。
    

    5. 

  5. 

    次の情報を入力します。
    

      

    • 

      サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。
      

      • 

    • 

      サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
      

      • 

    • 

      サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意である必要があります。
      

      • 

    

    6. 

  6. 

    「OK」をクリックします。
    

    7. 

  7. 

    新しく作成したサーバーWLS_OAM3をクリックします。
    

    8. 

  8. 

    SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
    

    9. 

  9. 

    「保存」をクリックします。
    

    10. 

  10. 

    新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
    

    新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
    

      

    1. 

      Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
      

      2. 

    2. 

      「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
      

      3. 

    3. 

      「サーバー」をクリックします。表の「名前」列で「WLS_OAM3」を選択します。
      

      4. 

    4. 

      「SSL」タブをクリックします。「詳細」をクリックします。
      

      5. 

    5. 

      「ホスト名の検証」を「なし」に設定します。「保存」をクリックします。
      

      6. 

    

    11. 

  11. 

    構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
    

    12. 



新しい管理対象サーバーをOAMに登録します。この時点で、Oracle Access Managementコンソールで、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。


    

  1. 

    Oracle Access Managementコンソール(http://oamhost1.mycompany.com:7001/oamconsole)にoamadminユーザーとしてログインします。
    

    2. 

  2. 

    「システム構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
    

    3. 

  3. 

    「作成」を「アクション」メニューで選択します。
    

    4. 

  4. 

    次の情報を入力します。
    

      

    • 

      サーバー名: WLS_OAM3
      

      • 

    • 

      ホスト: サーバーを実行するホスト。
      

      • 

    • 

      ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート
      

      • 

    • 

      OAMプロキシ・ポート: OAMプロキシを実行するポート。これは当該ホストについて一意のポートです。
      

      • 

    • 

      プロキシ・サーバーID: AccessServerConfigProxy
      

      • 

    • 

      モード: Open
      

      • 

    

    5. 

  5. 

    「コヒーレンス」タブをクリックします。
    

    ホストで一意な値に「ローカル・ポート」を設定します。
    

    「適用」をクリックします。
    

    6. 

  6. 

    「適用」をクリックします。
    

    7. 



これでアクセス・サーバーを起動できます。このアクセス・サーバーを使用するには、その存在をWebgateに通知する必要があります。この手順は次のとおりです。


    

  1. 

    Oracle Access Managementコンソール(http://oamhost1.mycompany.com:7001/oamconsole)にoamadminユーザーとしてログインします。
    

    2. 

  2. 

    「システム構成」タブをクリックします。
    

    3. 

  3. 

    エージェント→OAMエージェント→10gエージェント」(10g WebGatesの場合)、またはエージェント→OAMエージェント→11gエージェント(11g WebGatesの場合)を開きます。
    

    4. 

  4. 

    変更するWebGateをダブルクリックします。
    

    5. 

  5. 

    「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。
    

    6. 

  6. 

    サーバー名をリストから選択します。
    

    7. 

  7. 

    「適用」をクリックします。
    

    8. 









9.2.3.16.2 Access Managerのスケール・アウト


スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。


    

  1. 

    第9.2.3.3項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。
    

    2. 

  2. 

    新しいホストにIdentity Managementコンポーネントをインストールします。第9.2.3.4項「Access Manager Application Tierのインストールと構成」を参照してください。
    

    3. 

  3. 

    Oracle WebLogic Server管理コンソール(http://oamhost1.mycompany.com:7001/oamconsole)にログインします。
    

    4. 

  4. 

    管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
    

    5. 

  5. 

    「チェンジ・センター」で、「ロックして編集」をクリックします。
    

    6. 

  6. 

    拡張するホスト上のサーバーを選択します(例: WLS_OAM1)。
    

    7. 

  7. 

    「クローンの作成」をクリックします。
    

    8. 

  8. 

    次の情報を入力します。
    

      

    • 

      サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。
      

      • 

    • 

      サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
      

      • 

    • 

      サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
      

      • 

    

    9. 

  9. 

    「OK」をクリックします。
    

    10. 

  10. 

    新規作成したサーバーである「WLS_OAM3」をクリックします。
    

    11. 

  11. 

    SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
    

    12. 

  12. 

    「保存」をクリックします。
    

    13. 

  13. 

    新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
    

    新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
    

      

    1. 

      Oracle Enterprise Manager Fusion Middleware Controlで、「Oracle WebLogic Server管理コンソール」を選択します。
      

      2. 

    2. 

      「環境」ノードを「ドメイン構造」ペインで開きます。
      

      3. 

    3. 

      「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
      

      4. 

    4. 

      表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。
      

      5. 

    5. 

      「SSL」タブをクリックします。「詳細」をクリックします。
      

      6. 

    6. 

      「ホスト名の検証」を「なし」に設定します。
      

      7. 

    7. 

      「保存」をクリックします。
      

      8. 

    

    14. 

  14. 

    構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
    

    15. 

  15. 

    次のコマンドを使用してOAMHOST1上のドメインをパックします。
    

    pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true

    

    pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
    

    16. 

  16. 

    次のコマンドを使用して新しいホスト上でドメインを解凍します。
    

    unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications

    

    unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
    

    17. 

  17. 

    コンソールから管理対象サーバーを起動する前に、OAMHOST3上にノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binにあるsetNMProps.shスクリプトを実行することによって行います。次のように入力します。
    

    MW_HOME/oracle_common/common/bin/setNMProps.sh

    18. 



新しい管理対象サーバーをOAMに登録します。この時点で、Oracle Access Managementコンソールで、新しい管理対象サーバーをOAMサーバーとして構成する必要があります。


    

  1. 

    Oracle Access Managementコンソール(http://oamhost1.mycompany.com:7001/oamconsole)にoamadminユーザーとしてログインします。
    

    2. 

  2. 

    「システム構成」タブをクリックします。「サーバー・インスタンス」をクリックします。
    

    3. 

  3. 

    「作成」を「アクション」メニューで選択します。
    

    4. 

  4. 

    次の情報を入力します。
    

      

    • 

      サーバー名: WLS_OAM3
      

      • 

    • 

      ホスト: サーバーを実行するホスト、OAMHOST3。
      

      • 

    • 

      ポート: 管理対象サーバーが作成されたときに割り当てられたリスニング・ポート。
      

      • 

    • 

      OAMプロキシ・ポート: OAMプロキシを実行するポート。これは当該ホストについて一意のポートです。
      

      • 

    • 

      プロキシ・サーバーID: AccessServerConfigProxy
      

      • 

    • 

      モード: Open
      

      • 

    

    5. 

  5. 

    「適用」をクリックします。
    

    6. 



Access Serverを起動します。このサーバーを使用するには、その存在をWebgateに通知する必要があります。


    

  1. 

    Oracle Access Managementコンソール(http://oamhost1.mycompany.com:7001/oamconsole)にoamadminユーザーとしてログインします。
    

    2. 

  2. 

    「システム構成」タブをクリックします。
    

    3. 

  3. 

    「エージェント」→「OAMエージェント」→「10gエージェント」を展開します。
    

    4. 

  4. 

    変更するWebGateをダブルクリックします。
    

    5. 

  5. 

    「追加」+アイコンをクリックして、新しいサーバーをプライマリまたはセカンダリ・サーバー・リストに追加します。
    

    6. 

  6. 

    サーバー名をリストから選択します。
    

    7. 

  7. 

    「適用」をクリックします。
    

    8. 



Web層を更新します。これで、新しい管理対象サーバーが作成されて起動され、Web層はリクエストをその管理対象サーバーに転送するようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。


このためには、各Web層のOAM.confファイルを更新します。このファイルは、ORACLE_INSTANCE/config/OHS/component name/moduleconfディレクトリにあります。


新しいサーバーをこのファイル内のWebLogicClusterディレクティブに追加します。次に変更前の例を示します。


<Location /OAM_admin>
    SetHandler weblogic-handler
    WebLogicCluster
 OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200
</Location>



前述の行を次のように変更します。


<Location /OAM_admin>
    SetHandler weblogic-handler
    WebLogicCluster
 OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200,OAMhsot3.mycompany.com:14300
</Location>













9.3 Oracle Adaptive Access Managerの高可用性


この項では、Oracle Adaptive Access Managerの概要およびOracle Adaptive Access Managerの高可用性環境の設計およびデプロイ方法について説明します。


Oracle Adaptive Access Managerは、プラットフォームのプレゼンテーション層、ビジネス・ロジック層、およびデータ層を分けた、J2EEベースの複数層デプロイメント・アーキテクチャに構築されています。層がこのように分離されているため、Oracle Adaptive Access Managerは、お客様のパフォーマンス要件に合せてすばやくスケールできます。このアーキテクチャでは、Java、XML、およびオブジェクト・テクノロジを組み合せた、最も柔軟なサポートされているクロス・プラットフォームJ2EEサービスを利用できます。Oracle Adaptive Access Managerは、このアーキテクチャによって、スケーラブルでフォルト・トレラントなソリューションとなっています。


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






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


図9-5は、Oracle Adaptive Access Managerの単一インスタンスのアーキテクチャを示しています。




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

図9-5の説明が続きます
 「図9-5 Oracle Adaptive Access Managerの単一インスタンス・アーキテクチャ」の説明
 



図9-5に示すOracle Adaptive Access Managerの単一インスタンス・アーキテクチャでは、エンド・ユーザーは、カスタマWebアプリケーションにアクセスし、それがSOAPを使用してOAAM Serverアプリケーションおよびそのポリシーと通信します。かわりに、OAAMプロキシを設定して、エンド・ユーザーがそのマシンと通信し、それがHTTP(S)を使用してOAAM_Serverアプリケーションと通信することもできます。認可されたエンド・ユーザーは、カスタマWebアプリケーションにアクセスできます。OAAM_ADMINコンポーネントは、OAAM_SERVERアプリケーションの管理と構成のために使用されます。OAAM_Serverアプリケーションの管理と構成を担当する管理者は、Webブラウザを使用してOAAM_ADMINアプリケーションにアクセスします。Oracle RACデータベースにはポリシーと構成情報が格納されます。





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


Oracle Adaptive Access Managerは、次の2つのコンポーネントで構成されています。


    

  • 

    OAAM_ADMIN: このコンポーネントは、OAAM_SERVERアプリケーションの管理と構成のために使用されます。このコンポーネントは、Oracle JAVA ADF FrameworkのIdentity Managementシェルを使用して開発されており、J2EEコンテナにWebアプリケーションとしてデプロイされます。これは、EARファイルとしてパッケージされています。
    

    • 

  • 

    OAAM_SERVER: このコンポーネントは、1つのWebアプリケーション内にOAAM AdminサブコンポーネントとOAAM Serverサブコンポーネントが含まれています。OAAM_SERVERコンポーネントはEARファイルとしてパッケージ化されており、Javaクラスに加えてサーブレットとJSPで構成されています。OAAM_SERVERのサブコンポーネントについては、次にレイヤー別に説明します。
    

      

    • 

      プレゼンテーション・レイヤー: 通常、JSP、サーブレットなどのサービスを提供するWebアプリケーション。プレゼンテーション・レイヤーは、厳密認証機能を提供します。これはビジネス・レイヤーによって提供されるインタフェース(SOAPまたはJavaネイティブ)を使用してそのサービスにアクセスします。
      

      • 

    • 

      ビジネス・ロジック・レイヤー: リスク分析エンジンを実装するコア・アプリケーション・ロジックが含まれています。このレイヤーは、プレゼンテーション・レイヤーのためのJavaおよびSOAPインタフェースを提供します。Javaインタフェースを使用する場合、ビジネス・ロジック・レイヤーとプレゼンテーション・レイヤーを1つのWebアプリケーションの一部とすることができます。SOAPインタフェースの場合は、これらのレイヤーは異なるアプリケーションとしてデプロイされます。
      

      • 

    • 

      データ・アクセス・レイヤー: サポートされているリレーショナル・データベースに接続するためのデータ・アクセス・コンポーネントが含まれています。Oracle Adaptive Access Managerは、リレーショナル・データベースにJavaオブジェクトを格納するための強力で柔軟なフレームワークを提供するOracle TopLinkを使用します。
      

      • 

    

    • 



次に示すコンポーネントも、Oracle Adaptive Access Manager 11gデプロイメントで使用できます。


    

  • 

    Fusion Middleware ControlおよびEnterprise Manager Grid Control: Oracle Adaptive Access Managerは、Enterprise Manager Grid Controlと統合し、パフォーマンス・メトリックとデプロイメント・トポロジを表示します。Oracle Adaptive Access Managerは、DMSおよびDiscovery Mbeanを使用してEnterprise Managerと統合します。Enterprise Managerは、コンポーネント・トレースの向上と、監査の構成のためにも使用されます。
    

    Enterprise Managerは、ドメイン内の各管理対象サーバーのログ・ファイルの表示するため、およびトレースをデバッグ・レベル、トレース・レベル、および情報レベルに高めるためにも使用できます。
    

    • 

  • 

    データ・リポジトリ: Oracle Adaptive Access Managerは、RDBMSデータベースをそのデータ・ストアとして使用します。Oracle Adaptive Access Managerがサポートし、機能するデータベース・トポロジは、次のとおりです。
    

      

    • 

      Oracle Real Application Cluster
      

      • 

    • 

      Oracle Data Guard
      

      • 

    • 

      レプリケーション・ストリーム
      

      • 

    • 

      データベース・パーティション化
      

      • 

    

    Oracle Adaptive Access Managerは、RCUを使用してデータベースにそのスキーマを作成します。
    

    • 






9.3.1.1.1 Oracle Adaptive Access Managerの状態情報


OAAM_Serverコンポーネントには、OAAM ServerサブコンポーネントとOAAM Adminサブコンポーネントが含まれています。


    

  • 

    OAAM Serverは、HTTPセッションに状態を格納するステートフル・アプリケーションです。
    

    • 

  • 

    OAAM Adminは、データベースにそのセッション情報を格納するステートフル・アプリケーションです。
    

    • 



OAAM_Adminコンポーネントは、ADFおよびアイデンティティ管理UIシェルベース・アプリケーションです。それは、ステートレス・アプリケーションであり、そのアプリケーションの状態は、ADFフレームワークによって保持されます。








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


Oracle Adaptive Access Manager管理コンソールを使用して次のランタイム・タスクを実行できます。


    

  • 

    カスタマ・ケア・アプリケーション・タスク
    

    • 

  • 

    ポリシー、グループ、およびプロパティを含むシステム構成タスク
    

    • 

  • 

    セッション・データ情報の表示
    

    • 

  • 

    システム統計ダッシュボードの表示
    

    • 



たとえば、次の管理フローを実行できます。


    

  1. 

    最近のユーザー問合せ:
    

      

    1. 

      最近のログインとセッションの詳細を表示します。
      

      2. 

    2. 

      問合せを実行します。
      

      3. 

    3. 

      「セッション詳細」をクリックします。
      

      4. 

    4. 

      ログアウトします。
      

      5. 

    

    2. 

  2. 

    手動によるCSRとエージェント・エースの作成:
    

      

    1. 

      カスタマ・ケアをリセットするには、ログインします。
      

      2. 

    2. 

      ケースを作成します。
      

      3. 

    3. 

      カスタマをリセットします。
      

      4. 

    4. 

      ログアウトします。
      

      5. 

    

    3. 



Oracle Adaptive Access Manager Serverを使用してランタイム処理も実行できます。








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


Oracle Adaptive Access Manager Serverでは、次のランタイム処理が実行されます。


    

  1. 

    Oracle Adaptive Access Managerが、デプロイされ、カスタマのアプリケーションと統合されています。
    

    2. 

  2. 

    ユーザーがカスタマのアプリケーションにアクセスし、ユーザー資格証明を入力します。
    

    3. 

  3. 

    OAAMで構成されたシステムとルールに基づき、次のように様々なログイン・フローがあります。
    

    ユーザー登録: 登録フロー
    

      

    1. 

      フローR1: (新規ユーザーとして)ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録をスキップしてログアウトします。
      

      2. 

    2. 

      フローR2: ログインし、パスワードを入力し、登録をスキップしてログアウトします。
      

      3. 

    3. 

      フローR3: ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行してログアウトします。
      

      4. 

    4. 

      フローR4: ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行して無効なアンサーを入力し、検証してログアウトします。
      

      5. 

    5. 

      フローR5: (新規デバイスに新規ユーザーとして)ログインし、パスワードを入力してデバイスをパーソナライズし、質問登録を続行してログアウトします。
      

      6. 

    

    ログイン・フロー:
    

      

    1. 

      フローL1: ログインし、誤ったパスワードを入力します(「ログイン」画面)。
      

      2. 

    2. 

      フローL2: ログインし、正しいパスワードを入力し、チャレンジオンが表示される場合は正しい答えを入力し、ログインします。
      

      3. 

    3. 

      フローL3: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、正しい答えを入力し、ログインします。
      

      4. 

    4. 

      フローL4: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、誤った答えを入力し、チャレンジオンが再表示され、正しい答えを入力し、ログインします。
      

      5. 

    5. 

      フローL5: ログインし、正しいパスワードを入力し、チャレンジオンが表示され、誤った答えを入力し、チャレンジオンが再表示され、誤った答えを入力し、ログインがブロックされます。
      

      6. 

    6. 

      フローL6: ログインし、正しいパスワードを入力し、ログインがブロックされます(「ログイン」画面)。
      

      7. 

    7. 

      フローL7: ログインし、正しいパスワードを入力し、ログインします。
      

      8. 

    8. 

      フローLNU1: (新規ユーザーとしてログイン)ログインし、正しいパスワードを入力し、ログインします。
      

      9. 

    9. 

      フローLND1: (既存のユーザー)新しいデバイスでログインし、正しいパスワードを入力し、ログインします。
      

      10. 

    10. 

      フローLNUD1: (新規ユーザー)新しいデバイスでログインし、正しいパスワードを入力し、ログインします。
      

      11. 

    

    セッション内トランザクション・フロー: ログインし、パスワードを入力し、トランザクションを作成し、トランザクションを更新し、ログアウトします。
    

    4. 

  4. 

    OAAMは、次のデータ要素を追跡し、登録します。
    

      

    1. 

      ユーザー・ログイン
      

      2. 

    2. 

      ユーザー名
      

      3. 

    3. 

      デバイス(Cookie、ブラウザ・ヘッダー、提供されたフラッシュ・データ)
      

      4. 

    4. 

      IPアドレス
      

      5. 

    5. 

      トランザクション・データ
      

      6. 

    

    5. 

  5. 

    OAAMは、ログイン動作に基づいて適切なポリシーをトリガーします。
    

    6. 



Oracle Adaptive Access Manager Serverと管理コンソールは、J2EEアプリケーションとして、WebLogic Serverのユーザー・インタフェースおよびコマンドライン・ツールを使用して起動できます。


Oracle Adaptive Access Manager Serverは、障害の検出のためにロード・バランサが使用できるヘルス・チェック・リクエスト(HTTPを介したpingリクエスト)をサポートしています。


Oracle Adaptive Access Managerは、サーバー・サイド・メトリック用(DMSを使用)にインスツルメント処理されており、この情報は管理コンソールに公開されます。DMSメトリック収集が有効化されている場合、エージェントおよびサーバー・コンポーネント・メトリックの監視は、コンポーネントの監視のかわりとして使用できます。さらに、Oracle Adaptive Access Managerは、きめ細かいリアルタイム・アクティビティ・トレースをサポートしており、それもコンポーネントの監視のかわりとして使用できます。








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


Oracle Adaptive Access Managerは、その構成情報をデータベースに格納します。これらの構成プロパティを変更するには、Oracle Adaptive Access Manager管理コンソールを使用します。


Oracle Adaptive Access Managerは、構成情報をファイル・システムや展開したEARファイルに格納することはありません。








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


Oracle Adaptive Access Managerは、デプロイメント・ステージングのnostageモードをサポートします。つまり、すべてのデプロイメント・ファイルはローカルです。








9.3.1.1.6 Oracle Adaptive Access Managerの外部依存性


Oracle Adaptive Access Managerは、RDBMSデータベースに外部依存し、それに構成情報を格納します。


Oracle Adaptive Access Managerは、Oracle RACデータベースのためにWebLogic Serverマルチ・データ・ソースを使用します。


Oracle Adaptive Access Managerは、標準Oracle TopLinkオブジェクト・キャッシュ・メカニズムを使用します。


Oracle Adaptive Access Managerは、標準セッション・オブジェクト・シリアライズを使用して、オブジェクトの永続状態を保持します。


Oracle Adaptive Access Managerは、どのようなホスト名、IPアドレス、またはポートにも依存しません。コンテナ固有のポートまたはホスト名で機能します。








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


Oracle Adaptive Access Managerは、WebLogic Server上にデプロイされるJ2EEアプリケーションです。すべてのログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。


WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log











9.3.2 Oracle Adaptive Access Managerの高可用性の概要


この項では、Oracle Adaptive Access Managerを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。





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


図9-6は、Oracle Adaptive Access Managerの高可用性アーキテクチャを示しています。




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

図9-6の説明が続きます
 「図9-6 Oracle Adaptive Access Managerの高可用性アーキテクチャ」の説明
 



図9-6では、受信リクエストは、ハードウェア・ロード・バランサによって受信されてから、Web層内のWEBHOST1またはWEBHOST2にルーティングされます。これらのホストにはOracle HTTP Serverがインストールされています。次に、Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohs.confが使用されてOAAMHOST1およびOAAMHOST2上のWebLogic管理対象サーバーにリクエストが転送されます。


OAAMHOST1とOAAMHOST2には、Oracle Adaptive Access Manager ServerアプリケーションとOracle Adaptive Access Manager Adminアプリケーションをホストする管理対象サーバーが含まれています。これらの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ的に動作できるように、クラスタにおいて構成されます。


WebLogic管理サーバーは、OAAMHOST1上で実行され、WebLogic管理コンソールとOracle Enterprise Manager Fusion Middleware Controlを含んでいます。管理サーバーは、OAAMHOST2上でアクティブ/パッシブ・モードで実行するように構成できます。つまり、OAAMHOST1が使用不可になった場合に、管理サーバーをOAAMHOST2上で手動で起動できます。


ディレクトリ層で、仮想IP ovd.mycompany.comは、Oracle Virtual DirectoryリクエストをOVDHOST1とOVDHOST2にルーティングするように設定されます。OVDHOST1とOVDHOST2は、アクティブ/アクティブのOracle Virtual Directoryクラスタを構成します。仮想IP oid.mycompany.comは、Oracle Internet DirectoryリクエストをOIDHOST1とOIDHOST2にルーティングするように設定されます。OIDHOST1とOIDHOST2は、アクティブ/アクティブのOracle Internet Directoryクラスタを構成します。


Oracle RACデータベースは、データ層における高可用性を提供します。


図9-6は、OAAMの高可用性構成アーキテクチャを示しています。図では、ロード・バランサによって、WEBHOST1およびWEBHOST2上の2つのOracle HTTP Serverインスタンスを介してOAAMHOST1およびOAAMHOST2にリクエストがルーティングされます。OAAM管理サーバー・インスタンスおよびOAAM管理対象サーバー・インスタンスは、OAAMHOST1およびOAAMHOST2にインストールされ、これらのインストールは、OAAM Serverクラスタ(OAAM_Cluster)およびOAAM Adminクラスタ(OAAM_Admin_Cluster)として構成されます。OAAM ServerクラスタはOAAM Serverデータ・ソースを使用し、OAAM AdminクラスタはOAAM Adminデータ・ソースを使用して、Oracle RACデータベースと通信します。


1つのWebLogic ServerドメインでサポートされるOracle Adaptive Access Manager ServerクラスタとOracle Adaptive Access Manager Administrationクラスタはそれぞれ1つです。さらに、Oracle Adaptive Access Manager関連のクラスタは、複数のWebLogic Serverドメインにわたることはできません。


単一インスタンスのOracle Adaptive Access Managerデプロイメントは、次の高可用性要件を満たします。


    

  • 

    ロード処理
    

    • 

  • 

    外部接続管理と監視
    

    • 

  • 

    リカバリ
    

    • 

  • 

    フォルト包含
    

    • 

  • 

    フォルト診断
    

    • 

  • 

    Oracle Adaptive Access Manager AdminまたはServerのオフライン
    

    • 



複数インスタンスのOracle Adaptive Access Managerデプロイメントは、次の追加の高可用性要件を満たします。


    

  • 

    冗長性
    

    • 

  • 

    クライアント接続のフェイルオーバー/継続性
    

    • 

  • 

    クライアントのロード・バランシング
    

    • 

  • 

    状態管理
    

    • 



インバウンドHTTP接続の場合は、外部ロード・バランシング・ルーターの使用をお薦めします。


Webセッションは、Oracle Adaptive Access Manager管理コンソールおよびサーバーへの永続TCP接続を開きます。これには、TCP接続の早すぎる終了を回避するために、ロード・バランシング・ルーターとファイアウォール接続タイムアウトを十分大きい値にする必要があります。





9.3.2.1.1 クラスタの起動と停止


各Oracle Adaptive Access Manager管理コンソールおよびサーバー・インスタンスは、他のインスタンスのピアです。すべての初期化は、サーバーがリクエストを受信できるようになる前に行われることと、組込みのスロットル機能のために、サージ状態はOracle Adaptive Access Manager 11gR1アクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく正常に処理されます。


クラスタが停止した場合、新しいリクエストは拒否され、既存のリクエストはOracle Adaptive Access Manager管理コンソールおよびサーバー・アプリケーションが停止する前に完了できます。強制シャットダウンが行われた場合、Oracle Adaptive Access Manager 11gR1は、その強制シャットダウンによって破損または無効になったデータをリカバリします。


Oracle Adaptive Access Managerコンポーネントは、Pure J2EEアプリケーションであり、それ自体に起動および停止の機能はありません。かわりに、それらは、コンテナ固有の起動および停止機能に依存します。


Oracle Adaptive Access Managerコンポーネントは、WebLogic Server管理対象サーバー・ノードにデプロイされます。ノード・マネージャを使用してコンポーネントを再起動します。








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


Oracle Adaptive Access Managerは、構成全体をデータベースに格納するため、構成変更のすべてのクラスタ・メンバーへの伝播は透過的です。すべてのOracle Adaptive Access Managerコンポーネントは、変更イベントを内部レイヤーから通知されて取得します。変更の原子性を確保するために、Oracle Adaptive Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。


Oracle Adaptive Access Managerの構成は、クラスタ内のすべてのインスタンスに適用されます。


Oracle Adaptive Access Manager管理コンソールおよびサーバー・インスタンスの追加および削除は、クラスタ内の他のOracle Adaptive Access Managerインスタンスに対して透過的です。


Oracle Adaptive Access Managerクラスタには、任意の数のインスタンスを含めることができます。1つのクラスタ当たりのインスタンス数に制限はありません。


オンライン・アプリケーション・デプロイメントによって問題が発生することはありません。










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


次の機能が、Oracle Adaptive Access Managerの高可用性構成を障害から保護します。


    

  • 

    クラスタのセッションの状態は、メモリー内に保持され、それは、すべてのセッションの状態情報についてレプリケーションとフェイルオーバーを提供します。
    

    • 

  • 

    Oracle Adaptive Access Managerサーバーは、ハート・ビート・チェック(HTTPを介したpingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視し、アプリケーションが実行されていない場合は再起動することができます。Oracle Adaptive Access Managerサーバーを再起動しても、他の実行中のコンポーネントやクラスタ・メンバーには影響ありません。
    

    • 

  • 

    WebLogic Serverノードで障害が発生した場合、外部接続のフェイルオーバーは、構成、再試行のタイムアウトおよび再試行回数に基づいて行われます。
    

    • 

  • 

    ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出した場合、後続のクライアント接続は、アクティブ・インスタンスにルーティングされ、それはその後の処理のためにそのセッション状態を取得します。
    

    • 

  • 

    Oracle Adaptive Access Managerセッションが、Oracle RACデータベース・ノードの障害に直接影響を与えることはありません。それは、WebLogic Serverがそのデータベース接続の状態を保持しているためです。
    

    • 











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


この項では、Oracle Adaptive Access Managerで最大限の高可用性を得るためのデプロイメントを設定する高度な手順について説明します。このデプロイメントには、2つのOracle HTTP Serverが含まれており、それらは、リクエストを2つのOAAMサーバーに配布します。これらのOAAMサーバーは、Oracle Real Application Clusters(Oracle RAC)データベースと対話します。1つのコンポーネントで障害が発生しても、残りのコンポーネントは引き続き機能します。


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






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


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









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


作成するスキーマは、インストールおよび構成する製品により異なります。インストールする製品と互換性のあるバージョンのリポジトリ作成ユーティリティ(RCU)を使用します。RCUを実行するには、Oracle Fusion Middlewareインストレーション計画ガイドおよびOracle Fusion Middlewareリポジトリ作成ユーティリティ･ユーザーズ･ガイドを参照してください。








9.3.3.3 Oracle WebLogic Serverのインストール


Oracle WebLogic Serverをインストールする前に、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』で指定されているように、ご使用のマシンのシステム、パッチ、カーネルの要件、およびその他の要件が満たされていることを確認します。


Oracle WebLogic ServerをOAAMHOST1およびOAAMHOST2にインストールするには、インストーラを起動後、次の手順を実行します。


    

  1. 

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

    2. 

  2. 

    「ミドルウェア・ホーム・ディレクトリの選択」画面で、「新しいミドルウェア・ホームを作成する」を選択します。
    

    「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
    

    ORACLE_BASE/product/fmw
    

    


    

    


    


    注意:
    

    ORACLE_BASEは、Oracle製品のインストール先であるベース・ディレクトリです。推奨値は/u01/app/oracleです。
    
    		

    
    

    

    

    

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

    3. 

  3. 

    セキュリティ・アップデートが通知されるようにするために、「セキュリティ更新のための登録」画面で連絡先情報を入力します。
    

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

    4. 

  4. 

    「インストール・タイプの選択」画面で、「カスタム」を選択します。
    

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

    5. 

  5. 

    「製品とコンポーネントの選択」画面で、「Oracle JRockit SDK」のみを選択し、「次へ」をクリックします。
    

    6. 

  6. 

    「製品インストール・ディレクトリの選択」画面で、ディレクトリORACLE_BASE/product/fmw/wlserver_10.3を受け入れます。
    

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

    7. 

  7. 

    「インストールの概要」画面で「次へ」をクリックします。
    

    8. 

  8. 

    「インストール完了」画面で、「Quickstartの実行」の選択を解除します。
    

    「完了」をクリックします。
    

    9. 









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


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


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


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


OAAMHOST1> runInstaller



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


    

  1. 

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

    2. 

  2. 

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

    3. 

  3. 

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

      

    • 

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

      /u01/app/oracle/product/fmw

      • 

    • 

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

        

      • 

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

        • 

      • 

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

        • 

      

      • 

    

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

    4. 

  4. 

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

    5. 

  5. 

    「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
    

    6. 

  6. 

    「ドメイン・ソースの選択」画面で、次を選択します。
    

    「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。
    

    次の製品を選択します。
    

      

    • 

      Oracle Enterprise Manager
      

      • 

    • 

      Oracle JRF(デフォルトで選択)
      

      • 

    • 

      Oracle Adaptive Access Manager - サーバー
      

      • 

    • 

      Oracle Adaptive Access Manager管理サーバー
      

      • 

    

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

    7. 

  7. 

    「ドメイン名と場所の指定」画面で、次を入力します。
    

      

    • 

      ドメイン名: IDM_Domain
      

      • 

    • 

      ドメイン・ディレクトリ: デフォルトを受け入れます。
      

      • 

    • 

      アプリケーション・ディレクトリ: デフォルトを受け入れます。
      

      • 

    

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

    8. 

  8. 

    「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
    

    9. 

  9. 

    「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
    

      

    • 

      WebLogicドメインの起動モード: 「本番モード」を選択します。
      

      • 

    • 

      JDKの選択: 「JROCKIT SDK1.6.0_<バージョン>」を選択します。
      

      • 

    

    10. 

  10. 

    「JDBCコンポーネント・スキーマの構成」画面で、すべてのデータ・ソースを選択し、「次のパネルで選択したデータ・ソースをRACマルチ・データ・ソースとして構成します。」を選択します。
    

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

    11. 

  11. 

    「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、最初のデータ・ソースであるOAAM Admin Serverを選択し、次の項目を入力します。
    

      

    • 

      データ・ソース: OAAM Admin Server
      

      • 

    • 

      サービス名: oaam.mycompany.com
      

      • 

    • 

      ユーザー名: OAAM_OAAM(OAAMがRCU接頭辞として使用されていたと想定)
      

      • 

    • 

      パスワード: 前述のアカウント用のパスワード
      

      • 

    

    右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
    

      

    • 

      ホスト名: OAAMDBHOST1
      

      • 

    • 

      インスタンス名: oaamdb1
      

      • 

    • 

      ポート: 1521
      

      • 

    

    再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
    

      

    • 

      ホスト名: OAAMDBHOST2
      

      • 

    • 

      インスタンス名: oaamdb2
      

      • 

    • 

      ポート: 1521
      

      • 

    

    このデータ・ソースの選択を解除します。次のデータ・ソースであるOAAM Admin MDSスキーマを選択し、次の情報を入力します。
    

      

    • 

      データ・ソース: OAAM Admin MDSスキーマ
      

      • 

    • 

      サービス名: oaam.mycompany.com
      

      • 

    • 

      ユーザー名: OAAM_MDS(OAAMがRCU接頭辞として使用されていたと想定)
      

      • 

    • 

      パスワード: OAAM_MDSアカウント用パスワードです。
      

      • 

    

    右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
    

      

    • 

      ホスト名: OAAMDBHOST1
      

      • 

    • 

      インスタンス名: oaamdb1
      

      • 

    • 

      ポート: 1521
      

      • 

    

    再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
    

      

    • 

      ホスト名: OAAMDBHOST2
      

      • 

    • 

      インスタンス名: oaamdb2
      

      • 

    • 

      ポート: 1521
      

      • 

    

    このデータ・ソースの選択を解除します。次のデータ・ソースであるOAAM Serverを選択し、次の情報を入力します。
    

      

    • 

      データ・ソース: OAAM Server
      

      • 

    • 

      サービス名: oaam.mycompany.com
      

      • 

    • 

      ユーザー名: OAAM_OAAM(OAAMがRCU接頭辞として使用されていたと想定)
      

      • 

    • 

      パスワード: OAAM_OAAMアカウント用パスワードです。
      

      • 

    

    右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
    

      

    • 

      ホスト名: OAAMDBHOST1
      

      • 

    • 

      インスタンス名: oaamdb1
      

      • 

    • 

      ポート: 1521
      

      • 

    

    再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
    

      

    • 

      ホスト名: OAAMDBHOST2
      

      • 

    • 

      インスタンス名: oaamdb2
      

      • 

    • 

      ポート: 1521
      

      • 

    

    このデータ・ソースの選択を解除します。次のデータ・ソースであるOWSM MDSスキーマを選択し、次の情報を入力します。
    

      

    • 

      データ・ソース: OWSM MDSスキーマ
      

      • 

    • 

      サービス名: oaam.mycompany.com
      

      • 

    • 

      ユーザー名: OAAM_MDS(OAAMがRCU接頭辞として使用されていたと想定)
      

      • 

    • 

      パスワード: OAAM_MDSアカウント用パスワードです。
      

      • 

    

    右上のボックスで、「追加」をクリックしてOracle RACホストを追加します。次の情報を入力します。
    

      

    • 

      ホスト名: INFRADBHOST1
      

      • 

    • 

      インスタンス名: oaamdb1
      

      • 

    • 

      ポート: 1521
      

      • 

    

    再度「追加」をクリックして2つ目のデータベース・ホストを追加し、次の情報を入力します。
    

      

    • 

      ホスト名: INFRADBHOST2
      

      • 

    • 

      インスタンス名: oaamdb2
      

      • 

    • 

      ポート: 1521
      

      • 

    

    このデータ・ソースの選択を解除します。
    

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

    12. 

  12. 

    「コンポーネント・スキーマのテスト」画面で、データ・ソースの検証が試行されます。
    

    データ・ソースの検証が成功した場合、「次へ」をクリックします。
    

    失敗した場合は、「前へ」をクリックし、問題を修正して、やり直します。
    

    13. 

  13. 

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

      

    • 

      管理サーバー
      

      • 

    • 

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

      • 

    

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

    14. 

  14. 

    「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
    

    15. 

  15. 

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

      

    • 

      名前: AdminServer
      

      • 

    • 

      Listen address: 管理サーバーの仮想ホスト名を入力します(例: OAAMHOST1.mycompany.com)。
      

      • 

    • 

      リスニング・ポート: 7001
      

      • 

    • 

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

      • 

    • 

      SSL有効: 選択を解除
      

      • 

    

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

    16. 

  16. 

    「管理対象サーバーの構成」画面で、トポロジのOAAMHOSTごとに2つのエントリを作成します。つまり、OAAM Serverに対して1つと、OAAM Admin Serverに対して1つ作成します。
    

    OAAM_SERVERエントリを選択し、そのエントリを次の値に変更します。
    

      

    • 

      名前: WLS_OAAM1
      

      • 

    • 

      Listen address: OAAMHOST1.mycompany.com
      

      • 

    • 

      リスニング・ポート: 14300
      

      • 

    • 

      SSLリスニング・ポート: 14301
      

      • 

    • 

      SSL有効: 選択
      

      • 

    

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

      

    • 

      名前: WLS_OAAM2
      

      • 

    • 

      Listen address: OAAMHOST2.mycompany.com
      

      • 

    • 

      リスニング・ポート: 14300
      

      • 

    • 

      SSLリスニング・ポート: 14301
      

      • 

    • 

      SSL有効: 選択
      

      • 

    

    OAAM_ADMIN_SERVERエントリを選択し、そのエントリを次の値に変更します。
    

      

    • 

      Name: WLS_OAAM_ADMIN1
      

      • 

    • 

      Listen address: OAAMHOST1.mycompany.com
      

      • 

    • 

      リスニング・ポート: 14200
      

      • 

    • 

      SSLリスニング・ポート: 14201
      

      • 

    • 

      SSL有効: 選択
      

      • 

    

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

      

    • 

      Name: WLS_OAAM_ADMIN2
      

      • 

    • 

      Listen address: OAAMHOST2.mycompany.com
      

      • 

    • 

      リスニング・ポート: 14200
      

      • 

    • 

      SSLリスニング・ポート: 14201
      

      • 

    • 

      SSL有効: 選択
      

      • 

    

    その他すべてのフィールドはデフォルトの設定のままにします。
    

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

    17. 

  17. 

    「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
    

    名前としてOAAM_Clusterを入力します。
    

    「追加」をクリックして2番目のクラスタを作成します。
    

    名前としてOAAM_Admin_Clusterを入力します。
    

    その他すべてのフィールドはデフォルトの設定のままにします。
    

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

    18. 

  18. 

    「サーバーのクラスタへの割当」画面で、次のように管理対象サーバーをクラスタに関連付けます。
    

      

    • 

      右のウィンドウでクラスタ名OAAM_Clusterをクリックします。
      

      • 

    • 

      管理対象サーバーWLS_OAAM1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。
      

      • 

    • 

      管理対象サーバーWLS_OAAM2に対しても同様に繰り返します。
      

      • 

    

    続いて、次のように操作します。
    

      

    • 

      右のウィンドウでクラスタ名OAAM_Admin_Clusterをクリックします。
      

      • 

    • 

      管理対象サーバーWLS_OAAM_ADMIN1をクリックし、矢印をクリックしてそれをクラスタに割り当てます。
      

      • 

    • 

      管理対象サーバーWLS_OAAM_ADMIN2に対しても同様に繰り返します。
      

      • 

    

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

    19. 

  19. 

    「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。ホストでUNIXベースのオペレーティング・システムを使用する場合は、「Unix」タブをクリックします。それ以外の場合は、「マシン」タブをクリックします。次の情報を指定します。
    

      

    • 

      名前: ホスト名です。ベスト・プラクティスは、DNS名(OAAMHOST1)を使用することです。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: マシンのDNS名(OAAMHOST1.mycompany.com)
      

      • 

    • 

      ノード・マネージャ・ポート: ノード・マネージャが使用するポート。
      

      • 

    

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

    20. 

  20. 

    「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを指定します。
    

    OAAMHOST1について、次のように操作します。
    

      

    • 

      右のウィンドウでマシンOAAMHOST1をクリックします。
      

      • 

    • 

      左のウィンドウで管理対象サーバーWLS_OAAM1をクリックします。
      

      • 

    • 

      矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。
      

      • 

    • 

      左のウィンドウで管理対象サーバーWLS_OAAM_ADMIN1をクリックします。
      

      • 

    • 

      矢印をクリックし、その管理対象サーバーをホストOAAMHOST1に割り当てます。
      

      • 

    

    OAAMHOST2について、次のように操作します。
    

      

    • 

      右のウィンドウでマシンOAAMHOST2をクリックします。
      

      • 

    • 

      左のウィンドウで管理対象サーバーWLS_OAAM2をクリックします。
      

      • 

    • 

      矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。
      

      • 

    • 

      左のウィンドウで管理対象サーバーWLS_OAAM_ADMIN2をクリックします。
      

      • 

    • 

      矢印をクリックし、その管理対象サーバーをホストOAAMHOST2に割り当てます。
      

      • 

    

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

    21. 

  21. 

    「構成のサマリー」画面で、「作成」をクリックし、作成プロセスを開始します。
    

    22. 









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


ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、第9.1.3.3項「ドメイン用のデータベース・セキュリティ・ストアの構成」を参照してください。








>9.3.3.6 OAAMHOST1での管理サーバー用boot.propertiesの作成


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


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


    

  1. 

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

    2. 

  2. 

    OAAMHOST1で、次のディレクトリに移動します。
    

    MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

    

    例:
    

    cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

    3. 

  3. 

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

    username=adminUser
password=adminUserPassword

    

    


    

    


    


    注意:
    

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

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

    
    

    

    

    

    4. 

  4. 

    管理サーバーが実行されている場合は停止します。
    

    WebLogicサーバーの起動と停止の詳細は、『Oracle Fusion Middleware管理者ガイド』の「Oracle Fusion Middlewareの起動と停止」を参照してください。
    

    5. 

  5. 

    MW_HOME/user_projects/domains/domainName/binディレクトリにあるstartWebLogic.shスクリプトを使用して、OAAMHOST1上の管理サーバーを起動します。
    

    6. 

  6. 

    Webブラウザを開いて次のページにアクセスし、変更が正常に行われたことを確認します。
    

      

    • 

      WebLogic Server管理コンソール:
      

      http://oaamhost1.mycompany.com:7001/console

      • 

    • 

      Oracle Enterprise Manager Fusion Middleware Control:
      

      http://oaamhost1.mycompany.com:7001/em

      • 

    

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

    7. 









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


OAAMコンソールへのアクセスに使用する管理ユーザーを作成します。そのためには、次の手順を実行してください。


    

  1. 

    次のURLを使用して、WebLogic管理コンソールにログインします。
    

    http://oaamhost1.mycompany.com:7001/console

    2. 

  2. 

    「ドメイン構造」メニューで、「セキュリティ・レルム」→「myrealm」を選択します。
    

    3. 

  3. 

    「ユーザーとグループ」タブをクリックします。
    

    4. 

  4. 

    「ユーザー」サブタブをクリックします。
    

    5. 

  5. 

    新規をクリックします。
    

    6. 

  6. 

    次の値を入力します。
    

      

    • 

      名前: ユーザーの名前。例: oaam_admin
      

      • 

    • 

      プロバイダ: デフォルト認証システム
      

      • 

    • 

      パスワード/確認: ユーザーのパスワード
      

      • 

    

    「OK」をクリックします。
    

    7. 

  7. 

    ユーザーを作成したら、そのユーザー名をクリックします。
    

    8. 

  8. 

    「グループ」サブタブをクリックします。
    

    9. 

  9. 

    ユーザーを次のグループに割り当てます。
    

      

    • 

      OAAMCSRGroup
      

      • 

    • 

      OAAMCSRManagerGroup
      

      • 

    • 

      OAAMInvestigatorGroup
      

      • 

    • 

      OAAMInvestigationManagerGroup
      

      • 

    • 

      OAAMRuleAdministratorGroup
      

      • 

    • 

      OAAMEnvAdminGroup
      

      • 

    • 

      OAAMSOAPServicesGroup
      

      • 

    

    「保存」をクリックします。
    

    10. 









9.3.3.8 OAAMHOST1の起動


この項では、OAAMHOST1の起動手順について説明します。





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


コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:


OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh







9.3.3.8.2 ノード・マネージャの起動


次のコマンドを発行してノード・マネージャを起動します。


OAAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh







9.3.3.8.3 OAAMHOST1でのOracle Adaptive Access Managerの起動


OAAMHOST1上のOracle Adaptive Access Managerを起動する手順は、次のとおりです。


    

  1. 

    次のURLを使用して、WebLogic管理コンソールにログインします。
    

    http://oaamhost1.mycompany.com:7001/console

    2. 

  2. 

    WebLogic管理者のユーザー名とパスワードを指定します。
    

    3. 

  3. 

    「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
    

    4. 

  4. 

    「制御」タブをクリックします。
    

    5. 

  5. 

    サーバーWLS_OAAM1およびWLS_OAAM_ADMIN1をクリックします。
    

    6. 

  6. 

    「起動」をクリックします。
    

    7. 

  7. 

    「OK」をクリックし、サーバーを起動することを確認します。
    

    8. 











9.3.3.9 OAAMHOST1の検証


次のURLにあるOAAM管理サーバーに接続することによって実装を検証します。


http://OAAMHOST1.mycompany.com:14200/oaam_admin



OAAM管理コンソールのログイン・ページが表示され、第9.3.3.7項「Oracle Adaptive Access Manager管理ユーザーの作成」で作成したoaamadminアカウントを使用してログインできる場合、実装は有効です。


次の場所にあるOAAMサーバーに接続することによって実装を検証します:


http://OAAMHOST1.mycompany.com:14300/oaam_server



OAAMサーバーのログイン・ページが表示されると、実装は有効です。








9.3.3.10 OAAMHOST2でのOracle Adaptive Access Managerの構成


OAAMHOST1で構成を完了したら、それをOAAMHOST2に伝播できます。これを実行するには、OAAMHOST1でpackスクリプトを使用してドメインをパックし、OAAMHOST2でunpackスクリプトを使用してドメインを解凍します。


スクリプトは両方とも、MW_HOME/oracle_common/common/binディレクトリにあります。


OAAMHOST1で、次のように入力します。


pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar -template_name="OAAM Domain" -managed=true



これにより、/tmpディレクトリにidm_domain.jarというファイルが作成されます。このファイルをOAAMHOST2にコピーします。


OAAMHOST2で、次のように入力します。


unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar







9.3.3.11 OAAMHOST2の起動


OAAMHOST2を起動します。


この項では、OAAMHOST2の起動手順について説明します。





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


コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。これは、MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行することによって行います。例:


OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh







9.3.3.11.2 ノード・マネージャの起動


次のコマンドを発行してノード・マネージャを起動します。


OAAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh







9.3.3.11.3 OAAMHOST2でのOracle Adaptive Access Managerの起動


OAAMHOST2上のOracle Adaptive Access Managerを起動する手順は、次のとおりです。


    

  1. 

    次のURLを使用して、WebLogic管理コンソールにログインします。
    

    http://oaamhost2.mycompany.com:7001/console

    2. 

  2. 

    WebLogic管理者のユーザー名とパスワードを指定します。
    

    3. 

  3. 

    「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
    

    4. 

  4. 

    「制御」タブをクリックします。
    

    5. 

  5. 

    サーバーWLS_OAAM2およびWLS_OAAM_ADMIN2をクリックします。
    

    6. 

  6. 

    「起動」をクリックします。
    

    7. 

  7. 

    「OK」をクリックし、サーバーを起動することを確認します。
    

    8. 











9.3.3.12 OAAMHOST2の検証


次のURLにあるOAAM管理サーバーに接続することによって実装を検証します。


http://OAAMHOST2.mycompany.com:14200/oaam_admin



OAAM管理コンソールのログイン・ページが表示され、第9.3.3.7項「Oracle Adaptive Access Manager管理ユーザーの作成」で作成したoaamadminアカウントを使用してログインできる場合、実装は有効です。


次の場所にあるOAAMサーバーに接続することによって実装を検証します:


http://OAAMHOST2.mycompany.com:14300/oaam_server



OAAMサーバーのログイン・ページが表示されると、実装は有効です。








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


この項では、Oracle HTTP Serverと連携するためのOracle Adaptive Access Managerの構成手順について説明します。





9.3.3.13.1 Oracle HTTP Server構成の更新


WEBHOST1およびWEBHOST2で、次のディレクトリにoaam.confというファイルを作成します。


ORACLE_INSTANCE/config/OHS/ohs1/moduleconf



次の行を指定してファイルを作成します。


NameVirtualHost *:7777
<VirtualHost *:7777>
 
    ServerName oaam.mycompany.com:7777
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
 
    <Location /oaam_server>
       SetHandler weblogic-handler
       WebLogicCluster oaamhost1.mycompany.com:14300,oaamhost2.mycompany.com:14300
    </Location>
 
    <Location /oaam_admin>
       SetHandler weblogic-handler
       WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200
       WebLogicPort 7001
    </Location>
 
</VirtualHost>







9.3.3.13.2 Oracle HTTP Serverの再起動


WEBHOST1およびWEBHOST2でOracle HTTP Serverを再起動します。


WEBHOST1>opmnctl stopall
WEBHOST1>opmnctl startall

WEBHOST2>opmnctl stopall
WEBHOST2>opmnctl startall







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


Oracle HTTP Serverは、WebLogicのプロキシとして機能するため、デフォルトでは、特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。


そのためには、次のWebLogic管理コンソールにログインします。


http://oaamhost1.mycompany.com:7001/console



次の手順を実行します。


    

  1. 

    ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。
    

    2. 

  2. 

    「チェンジ・センター」ウィンドウで「ロックして編集」をクリックし、編集可能にします。
    

    3. 

  3. 

    クラスタ名(oaam_cluster)をクリックします。
    

    4. 

  4. 

    「一般」タブで、「拡張プロパティ」セクションのボックスを選択して、WebLogicプラグインを「有効」に設定します。
    

    5. 

  5. 

    「保存」をクリックします。
    

    6. 

  6. 

    「HTTP」を選択して、次の値を入力します。
    

      

    • 

      フロントエンド・ホスト: oaam.mycompany.com
      

      • 

    • 

      フロントエンドHTTPポート: 7777
      

      • 

    • 

      フロントエンドHTTPSポート: SSL通信を使用している場合は、ロード・バランサ上のSSLポートまたはOracle HTTP Server SSLポートに設定します。
      

      • 

    

    これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート443または80に送られます。
    

    7. 

  7. 

    「保存」をクリックします。
    

    8. 

  8. 

    ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。
    

    9. 

  9. 

    クラスタ名(oaam_admin_cluster)をクリックします。
    

    10. 

  10. 

    「一般」タブで、「拡張プロパティ」セクションのボックスを選択して、WebLogicプラグインを「有効」に設定します。
    

    11. 

  11. 

    「保存」をクリックします。
    

    12. 

  12. 

    「HTTP」を選択して、次の値を入力します。
    

      

    • 

      フロントエンド・ホスト: oaam.mycompany.com
      

      • 

    • 

      フロントエンドHTTPポート: 7777
      

      • 

    • 

      フロントエンドHTTPSポート: SSL通信を使用している場合は、ロード・バランサ上のSSLポートまたはOracle HTTP Server SSLポートに設定します。
      

      • 

    

    13. 

  13. 

    「保存」をクリックします。
    

    14. 

  14. 

    「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックし、変更を保存します。
    

    15. 

  15. 

    管理対象サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1、およびWLS_OAAM_ADMIN2を次のようにして再起動します。
    

      

    1. 

      次のURLを使用して、WebLogic管理コンソールにログインします。
      

      http://oaamhost1.mycompany.com:7001/console

      2. 

    2. 

      WebLogic管理者のユーザー名とパスワードを指定します。
      

      3. 

    3. 

      「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
      

      4. 

    4. 

      「制御」タブをクリックします。
      

      5. 

    5. 

      サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2をクリックします。
      

      6. 

    6. 

      「停止 - ただちに強制停止」を選択します。
      

      7. 

    7. 

      「はい」をクリックし、サーバーを停止することを確認します。
      

      8. 

    8. 

      「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
      

      9. 

    9. 

      「制御」タブをクリックします。
      

      10. 

    10. 

      サーバーWLS_OAAM1、WLS_OAAM2、WLS_OAAM_ADMIN1およびWLS_OAAM_ADMIN2をクリックします。
      

      11. 

    11. 

      「起動」をクリックします。
      

      12. 

    12. 

      「はい」をクリックし、サーバーを起動することを確認します。
      

      13. 

    

    16. 

  16. 

    管理サーバーを再起動します。
    

    17. 











9.3.3.14 Oracle Adaptive Access Managerの構成の検証


Oracle Adaptive Access Manager管理コンソール(http://oaam.mycompany.com:7777/oaam_admin)に、作成したoaamadminアカウントを使用してログインします。


Oracle Adaptive Access Managerサーバー(http://oaam.mycompany.com:7777/oaam_server)に、作成したoaamadminアカウントおよびパスワード・テストを使用してログインします。








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


この項では、Oracle Adaptive Access Managerの高可用性トポロジをスケール・アップおよびスケール・アウトする方法について説明します。すでに1つ以上のサーバー・インスタンスが実行されているノードに、新しいOracle Adaptive Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アップ操作を実行します。新しいノードに、新しいOracle Adaptive Access Manager管理対象サーバー・インスタンスを追加するには、スケール・アウト操作を実行します。





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


OAAMをスケール・アップするには、OAAMサーバーとOAAM管理サーバーの両方について同じ手順を実行します。


Oracle WebLogic Serverコンソール(http://oaamhost1.mycompany.com:7001/console)にログインします。次のように実行します。


    

  1. 

    Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
    

    2. 

  2. 

    「ロックして編集」を「チェンジ・センター」メニューでクリックします。
    

    3. 

  3. 

    拡張するホスト上の既存サーバーを選択します(例: WLS_OAAM1やWLS_OAAM_ADMIN1)。
    

    4. 

  4. 

    「クローンの作成」をクリックします。
    

    5. 

  5. 

    次の情報を入力します。
    

      

    • 

      サーバー名: サーバーの新しい名前です(例: WLS_OAAM3)。
      

      • 

    • 

      サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
      

      • 

    • 

      サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
      

      • 

    

    6. 

  6. 

    「OK」をクリックします。
    

    7. 

  7. 

    新規作成サーバーの「WLS_OAAM3」をクリックします。
    

    8. 

  8. 

    SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
    

    9. 

  9. 

    「保存」をクリックします。
    

    10. 

  10. 

    新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAAMHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。
    

    新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
    

      

    1. 

      Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
      

      2. 

    2. 

      「環境」ノードを「ドメイン構造」ペインで開きます。
      

      3. 

    3. 

      「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
      

      4. 

    4. 

      表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。
      

      5. 

    5. 

      「SSL」タブをクリックします。
      

      6. 

    6. 

      「詳細」をクリックします。
      

      7. 

    7. 

      「ホスト名の検証」を「なし」に設定します。
      

      8. 

    8. 

      「保存」をクリックします。
      

      9. 

    

    11. 

  11. 

    構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
    

    12. 









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


スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。次の手順を実行します。


    

  1. 

    第9.3.3.3項「Oracle WebLogic Serverのインストール」の手順に従い、新しいホストにOracle WebLogic Serverをインストールします。
    

    2. 

  2. 

    新しいホストにOracle Fusion Middleware Identity Managementコンポーネントをインストールします。第9.3.3.4項「Oracle Adaptive Access Manager Application Tierのインストールと構成」を参照してください。
    

    3. 

  3. 

    WebLogicコンソール(http://oaamhost1.mycompany.com:7001/console)にログインします。
    

    4. 

  4. 

    管理コンソールの「ドメイン構造」ペインで、「環境」ノードを開いて、「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。
    

    5. 

  5. 

    「ロックして編集」を「チェンジ・センター」メニューでクリックします。
    

    6. 

  6. 

    拡張するホスト上の既存サーバーを選択します(例: WLS_OAAM1やWLS_OAAM_ADMIN1)。
    

    7. 

  7. 

    「クローンの作成」をクリックします。
    

    8. 

  8. 

    次の情報を入力します。
    

      

    • 

      サーバー名: サーバーの新しい名前です(例: WLS_OAAM3)。
      

      • 

    • 

      サーバー・リスニング・アドレス: 管理対象サーバーが実行されるホストの名前。
      

      • 

    • 

      サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。
      

      • 

    

    9. 

  9. 

    「OK」をクリックします。
    

    10. 

  10. 

    新規作成サーバーの「WLS_OAAM3」をクリックします。
    

    11. 

  11. 

    SSLリスニング・ポートを設定します。これは、管理対象サーバーが実行されるホスト上で一意である必要があります。
    

    12. 

  12. 

    「保存」をクリックします。
    

    13. 

  13. 

    新しい管理対象サーバーのホスト名の検証を無効化します。WLS_OAAM3管理対象サーバーを起動して検証するには、ホスト名の検証を無効化しておく必要があります。OAAMHOSTnのノード・マネージャとOracle WebLogic管理サーバーとの間における通信用のサーバー証明書を構成した後で、これを再び有効にできます。
    

    新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されたため、これらの手順は不要です。ホスト名の検証を無効化するには、次の手順を実行します。
    

      

    1. 

      Oracle Fusion Middleware Enterprise Managerコンソールで、「Oracle WebLogic Server管理コンソール」を選択します。
      

      2. 

    2. 

      「環境」ノードを「ドメイン構造」ペインで開きます。
      

      3. 

    3. 

      「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
      

      4. 

    4. 

      表の「名前」列で「WLS_OAAM3」を選択します。サーバーの「設定」ページが表示されます。
      

      5. 

    5. 

      「SSL」タブをクリックします。
      

      6. 

    6. 

      「詳細」をクリックします。
      

      7. 

    7. 

      「ホスト名の検証」を「なし」に設定します。
      

      8. 

    8. 

      「保存」をクリックします。
      

      9. 

    

    14. 

  14. 

    構成のアクティブ化を「チェンジ・センター」メニューでクリックします。
    

    15. 

  15. 

    次のコマンドを使用してOAAMHOST1上のドメインをパックします。
    

    pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAAM Domain" -managed=true

    

    pack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
    

    16. 

  16. 

    次のコマンドを使用して新しいホスト上でドメインを解凍します。
    

    unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications

    

    unpack.shスクリプトは、MW_HOME/oracle_common/common/binにあります。
    

    17. 

  17. 

    コンソールから管理対象サーバーを起動する前に、スクリプトsetNMProps.shを実行してOAAMHOST2上にノード・マネージャのプロパティ・ファイルを作成しておく必要があります。setNMProps.shスクリプトは、MW_HOME/oracle_common/common/binにあります。次のように入力します。
    

    OAAMHOST2> $MW_HOME/oracle_common/common/bin/setNMProps.sh

    18. 

  18. 

    新しいホストでノード・マネージャと新しい管理対象サーバーを起動します。
    

    19. 

  19. 

    これで、新しい管理対象サーバーが作成されて起動され、Web層はリクエストをその管理対象サーバーに転送するようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。
    

    このためには、各Web層のoaam.confファイルを更新します。このファイルは、ORACLE_INSTANCE/config/OHS/component_name/moduleconfディレクトリにあります。
    

    新しいサーバーをこのファイル内のWebLogicClusterディレクティブに追加します。次に例を示します。
    

    <Location /oaam_admin>
    SetHandler weblogic-handler
    WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200
</Location>

    

    前述の行を次のように変更します。
    

    <Location /oaam_admin>
    SetHandler weblogic-handler
    WebLogicCluster
oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200,oaamhost3.mycompany.com:14300
</Location>

    20. 















9.4 Oracle Access Management Security Token Serviceの高可用性


この項では、Oracle Access Management Security Token Serviceの高可用性について説明します。


Security Token Serviceは、共有Webサービス(JAX-WS)であり、様々なIdentityドメインとインフラストラクチャ層との間での信頼を仲介する機能が統合された標準ベースのメカニズムを提供します。Security Token Serviceは、Webサービス・コンシューマ(WSC)とWebサービス・プロバイダ(WSP)との間での信頼を仲介し、プロバイダとコンシューマに対してセキュリティ・トークンのライフサイクル管理サービスを提供します。Security Token Serviceでは、標準化されたインタフェースのセットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。


Security Token Serviceの高可用性デプロイメントは、Oracle Access Management Access Managerに依存します。Access Managerアプリケーションには、Oracle Security Token Serviceのサーバー・ランタイムが含まれています。Security Token Serviceの高可用性デプロイメントは、Access Managerがなければ成り立ちません。Access ManagerとSecurity Token Serviceは、どちらもOAM J2EEアプリケーションEARファイルに同梱されていて、WebLogicドメイン内の同じ管理対象サーバーにまとめてインストールされ、デプロイされます。さらに、Security Token Serviceは、Oracle Access Managementコンソールに統合されます。


Security Token Serviceの管理と構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の次のいずれかの項目をを参照してください。



パッチの適用については、Oracle Access Managerの管理の第11.1.1.3.0項から第11.1.1.6.0項を参照してください。


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






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


次の図は、高可用性アーキテクチャのSecurity Token Serviceを示しています。




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

図9-7の説明が続きます
 「図9-7 Security Token Serviceの高可用性アーキテクチャ」の説明
 



この図は、Access ManagerとSecurity Token Serviceコンポーネントの2ノード・デプロイメントを示しています。この項では、Security Token Serviceの高可用性デプロイメントについて詳しく説明します。これの一部としてデプロイされるAccess Managerの全体的な高可用性アーキテクチャについては、第9.2.2.1項「Access Managerの高可用性アーキテクチャ」を参照してください。


Security Token Serviceは、WS-Trustプロトコルのサポートを実装するサーバー側コンポーネントです。


ロード・バランサはトークン・リクエストを受信すると、そのリクエストをSecurity Token Service(STS)にルーティングします。


RACデータベースは、Access ManagerによってCoherenceバックエンド・ストアとして使用されるデータベースと同じです。


Oracle Access Managementコンソールは、Security Token Serviceデプロイメントを管理するためのサービスを提供するJ2EEアプリケーションです。OAMデプロイメントの一部として、管理コンソールをWeblogic管理サーバーにデプロイする必要があります。


Security Token Serviceの場合、各WebLogic Serverドメインで1つのSecurity Token Serviceクラスタがサポートされます。OAMとSecurity Token Serviceのクラスタは、WebLogic Serverドメイン間にまたがることはできません。


Security Token Serviceは、主にOASIS WS-Trustプロトコルを基盤とします。ただし、Security Token Serviceは、SOAPメッセージに含まれるその他のWS-*プロトコルの処理を、JAX-WSスタックに委任します。


HTTP/SOAPのインバウンド接続には、外部ロード・バランサを使用することをお薦めします。LDAPに対するアウトバウンド外部接続は、接続フェイルオーバーのサポートとともにロード・バランシングされます。





9.4.1.1クライアントとクライアント接続


WS-Trustプロトコルを実装するWebサービス・クライアントは、トークンの発行および検証のために、Security Token Serviceと対話します。STSサーバーと対話するように設計されたクライアント(OWSMクライアントなど)は、リライイング・パーティへのWebサービス・コールの一環として、Security Token Serviceを呼び出すことができます。


このクライアント接続は、次のように処理されます。


    

  1. 

    Webサービス・クライアントは、httpまたはhttpsによってSOAPメッセージを送信します。
    

    WSSプロトコルによって、メッセージを保護します。ペイロードには、実行する操作、発行または検証するトークンの種類、およびトークンの特性についての追加情報を示すWS-Trustリクエスト(RST)が格納されます。
    

    2. 

  2. 

    サーバーはリクエストを処理して、そのリクエストをサーバーが受信したチャネルと同じチャネルでレスポンスを送信します。
    

    WSSプロトコルによって、メッセージを保護します。処理が成功したときには、ペイロードにWS-Trustレスポンス(RSTRC)が格納されます。エラーが発生したときには、SOAP障害が格納されます。
    

    3. 









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


Security Token Serviceアクセス・サーバーの各インスタンスは、他のインスタンスのピアになりますがインスタンス間の通信はありません。サーバーがリクエストを受信できるようになる前に、すべての初期化が組込のスロット機能と同時に行われるため、WebLogic ServerはSecurity Token Serviceアクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく急増する条件を適切に処理します。


クラスタが停止すると、Security Token Serviceは新しいリクエストを拒否し、アクセス・サーバーのアプリケーションが停止する前に既存のリクエストを完了できるようにします。強制停止が行われた場合、Security Token Serviceはその強制停止によって破損または無効になったデータをリカバリできます。


構成の変更は、Coherence分散オブジェクト・キャッシュを利用する分散メカニズムに基づいて、すべてのクラスタ・メンバー伝播されます。Coherenceレイヤーは、すべてのSecurity Token Serviceコンポーネントに変更イベントを通知します。その後、このコンポーネントはそれらの変更を取り込みます。Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。













注意:


アクセス・サーバーのインスタンスの追加または削除は、クラスタ内の他のSecurity Token Serviceインスタンスに対して透過的になります。特定のSecurity Token Serviceサーバーの削除が、ロードに影響しないことを確認してください。




















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


この項では、Security Token Serviceコンポーネントの特性と、次の項目について説明します。






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


起動時に、Access ManagerとSecurity Token Service Serverは、バックエンド・リポジトリへの接続を初期化します。このリポジトリにアクセスできない場合、Access ManagerとSecurity Token Serviceサーバーは、指数関数的に増加するタイムアウトを使用してリポジトリへの接続を再試行します(このタイムアウトは上限を構成できます)。


Access ManagerとSecurity Token Service Serverは、バックエンドの接続が停止したときには、ローカルにキャッシュしたデータに基づいてサービスの持続性を提供します。サービスは、キャッシュの有効性が失われるか、バックエンドの接続が回復するまで持続されます。








9.4.2.2 ランタイム・プロセス


次の図は、Security Token Serviceのランタイム・プロセスを示しています。




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

図9-8の説明が続きます
 「図9-8 Security Token Serviceのランタイム・プロセス」の説明
 



Security Token Serviceのランタイム・プロセスは、次の説明のように動作します。


    

  1. 

    Webサービス・コンシューマ(WSC)は、WSPが要求するセキュリティ・トークンのタイプについてのWeb Services-Trust(WS-Trust)Request Security Token(RST)メッセージを送信します。クライアントの認証は、トランスポート・レイヤーの認証を使用するか、WSSトークンをRSTメッセージにバインドすることで行われます。
    

    2. 

  2. 

    Security Token Service(STS)はRSTメッセージを検証し、リクエストを認証してから、要求された操作の権限を付与します。
    

    3. 

  3. 

    RSTメッセージによって指定されたメタデータに応じて、適切なセキュリティ・トークンが生成されます。ポリシー主導型の交換ユースケースでは、STSが適切なトークン生成ポリシーを検索し、該当するセキュリティ・トークンを生成します。
    

    4. 

  4. 

    STSは、生成されたセキュリティ・トークンを格納するRSTメッセージを生成し、このメッセージをレスポンスとしてWSCに送信します。
    

    5. 














注意:


WSPによるセキュリティ・トークンの検証は、トークンのタイプに応じて異なります。STSが信頼の仲介者としてのみ機能する場合は、Kerberosなどの基幹セキュリティ・インフラストラクチャに対する検証が実行されます。















9.4.2.2.1 Security Token Serviceの起動と停止


アクセス・サーバー(Security Token Serviceのデプロイ先)と管理コンソールは、どちらもJ2EEアプリケーションであるため、アプリケーション・サーバーが提供するユーザー・インタフェースやコマンドライン・ツールから起動できます。








9.4.2.2.2 J2EEのコンポーネントとサブコンポーネント


J2EEのコンポーネントとサブコンポーネントには、次のものがあります。


    

  • 

    STS: イベント・ベースのデザイン・パターンであり、Security Token Service 11g-PS1の中核部分を実装します。WARアプリケーションとしてAccess Manager EARファイルにパッケージ化されています。WSプロバイダ・サーブレットとJavaクラスが含まれています。STS Webアプリケーションは、/stsルート・パスにバインドされます。
    

    • 

  • 

    管理コンソール: ADF/IDMシェルに基づくスタンドアロン・コンソールであり、.EARファイルとしてパッケージ化されています。
    

    • 

  • 

    JMX Mbeans: アクセス・サーバー・パッケージにパッケージ化されています。コンフィグMbeanは、スタンドアロンのJARファイルとしてパッケージ化されています。
    

    • 

  • 

    WSLTコマンド: Access Manager/Security Token Serviceパッケージに含まれているJavaクラスで構成されています。
    

    • 

  • 

    OWSMエージェント: WSSプロトコルのサポートを提供するWebサービスのインターセプタです。JRFに含まれます。
    

    • 

  • 

    ORAProvider: JRF Webサービス・プロバイダです。
    

    • 









9.4.2.2.3 セッションの状態情報


Security Token Serviceは、ステートレスのJ2EEアプリケーションですが、ユーザー名トークン用のNonceキャッシュがあり、Security Token Serviceはリプレイ攻撃を防止するために、Nonceが存在する場合は、提示されたユーザー名トークンを記録します。










9.4.2.3 構成アーティファクト


Access ManagerとSecurity Token Serviceは一組になるように構築され、構成やロギングなどのプロセスに同一のモジュールを使用します。Security Token Serviceの構成アーティファクトには、次のファイルが含まれます。


    

  • 

    DOMAIN_HOME/config/fmwconfig/oam-config.xml — インスタンス固有の情報を格納する構成ファイルです。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/oam-policy.xml — OES Micro SMが使用されていない場合にのみ存在します。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml — ロギング構成です。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/cwallet.sso — アイデンティティ・ストア、データベースおよびその他のエンティティへの接続に使用するパスワードを格納します。これは、エンド・ユーザー用のパスワードではありません。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/.oamkeystore — Access Manager/Security Token Serviceが所有する鍵と証明書を格納するキーストアです。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/amtruststore —  X509証明書の検証に使用されるトラスト・アンカーを格納するキーストアです。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/amcrl.jar — 証明書失効に使用するCRLを格納するzipファイルです。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/default-keystore.jks — OWSMエージェントが使用する鍵と証明書を格納するOWSMキーストアです。また、WSS操作のためのX.509証明書の検証に使用されるトラステッド・アンカーも格納されます。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/.cohstore.jks - Coherence SSL通信で使用されるトラスト・ストアです。
    

    • 









9.4.2.4 外部依存性


Security Token Serviceは、次の項目に対して外部依存性があります。


    

  • 

    LDAPベースのアイデンティティ・ストア
    

      

    • 

      ユーザー・アイデンティティ・リポジトリ
      

      • 

    • 

      ユーザー/ロールAPIによって抽象化されるLDAPアクセス
      

      


      

      


      


      注意:
      

      Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。
      
      		

      
      

      

      

      

      • 

    

    • 

  • 

    OCSPレスポンダ・サービス
    

      

    • 

      リアルタイムX.509認証検証
      

      • 

    

    • 

  • 

    RDBMSポリシー・ストア/Coherenceストア
    

      

    • 

      ポリシー(認証および認可)リポジトリ
      

      • 

    • 

      OAMポリシー・エンジンによって抽象化されるRDBMSアクセス
      

      • 

    • 

      OPSSセキュリティ・ストア
      

      • 

    

    • 











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


Security Token Serviceの高可用性は、Access Managerの一部として構成されます。Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。詳細は、第9.2.3項「Access Managerの高可用性の構成手順」を参照してください。








9.4.4 Security Token Serviceの高可用性の検証


個別のSecurity Token Serviceサーバー上のSecurity Token Serviceのエンドポイントが稼働状態であり実行中であることを検証できます。これを実行するには、Security Token ServiceのエンドポイントのWSDLドキュメント(http(s)://[hostname:port]/sts/[ENDPOINT]/WSDL)に直接アクセスします。


[ENDPOINT]の部分は、既存の公開エンドポイントに置換してください。








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


この項では、高可用性環境におけるSecurity Token Serviceのフェイルオーバーの特性について説明します。


Access Manager Access Serverは、ハートビート・チェック(HTTPによるPingリクエスト)をサポートしています。さらに、管理対象サーバー上のWebLogicノード・マネージャは、アプリケーションを監視して、そのアプリケーションを必要に応じて再起動できます。


WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。


ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出すると、後続のクライアント接続はアクティブなインスタンスにルーティングされます。このインスタンスは、セッション状態をCoherence分散オブジェクト・キャッシュから取得して処理を継続します。


フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。


別のサービスから例外を受信した場合、Access Managerは、外部接続リクエストを再試行します。再試行の回数は構成可能であり、no retriesのオプションもあります。


詳細は次のトピックを参照してください。






9.4.5.1 障害検出と再起動


Access Manager Access ServerとSecurity Token Service Access Serverは、HTTPでPingリクエストを送信する方式によるハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャでは、アプリケーションを監視して、イベントが実行されていない場合にはアプリケーションを再起動できます。Access Manager Access Serverを再起動しても、その他のクラスタ・コンポーネントまたはメンバーに影響はありません。








9.4.5.2 ノード障害


外部接続のフェイルオーバーは、構成、再試行のタイムアウトおよび再試行の回数に基づいて行われます。ロード・バランサまたはプロキシ・サーバーはノード障害を検出すると、後続のクライアント接続をアクティブなインスタンスにルーティングし、このインスタンスが、Coherence DOCからセッション状態を取得して処理を継続します。










9.4.6 Security Token Serviceの有効化および無効化


Security Token Serviceは、デフォルトで有効化されています。Security Token Serviceを無効化するには、Oracle Access Managementコンソールを使用します。『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の使用可能なサービスの有効化または無効化に関する説明を参照してください。








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


Security Token Serviceのログは、管理対象サーバーのログ・ファイルに記録されます。ただし、logging.xmlを編集すると、Security Token Service情報を、<DomainHome>/config/fmwconfig/servers/<servername>/sts/log/フォルダの個別のログ・ファイル(diagnostic.log)に記録できます。


Security Token Serviceをトラブルシューティングするために、Security Token Serviceのログ・ファイルを作成する手順は、次のとおりです。


    

  1. 

    ファイルDomainHome/config/fmwconfig/servers/servername/logging.xmlを開きます。
    

    2. 

  2. 

    次を、適切なセクションに追加します。
    

    <log_handler name='sts-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
      <property name='path' value='sts/log'/>
      <property name='maxFileSize' value='10485760'/>
      <property name='maxLogSize' value='104857600'/>
    </log_handler>
 
<logger name='oracle.security.fed' level='TRACE:32'>
      <handler name='sts-handler'/>
    </logger>

    3. 









9.4.8 ログ・ファイルの場所


すべてのログ・メッセージは、アプリケーションがデプロイされたWebLogic Serverのサーバー・ログ・ファイルに記録されます。サーバー・ログのデフォルトの場所は次のとおりです。


WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log







9.4.9 その他の考慮事項


Security Token Serviceサーバーは、リプレイ攻撃などの偽のリクエストを検出できますが、リプレイ攻撃は、リクエストからトークン・データを不正入手しようとして、同じトークンで別のリクエストを送信した場合に発生することがあります。この場合には、サーバーは2番目の偽のリクエストを検出します。2番目に発行された<Env: Body>に同一のトークンを持つリクエストは、Security Token Serviceサーバーに送られます。このサーバーは、UNTトークン・キャッシュを確認して、リプレイ攻撃を示すリクエストを拒否します。










9.5 Oracle Access Management Identity Federationの高可用性


この項では、Oracle Access Management Identity Federation 11gR2の高可用性について説明します。Identity Federationの詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のAccess Manager 11gR2との統合に関する項を参照してください。


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






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


Identity Federationサービスは、複数ドメインのアイデンティティ・ネットワークのOracle Access Management Access Managerに対してシングル・サインオン機能を提供します。もっとも広範なフェデレーション標準のセットがサポートされ、これにより、ソリューション・セットでその他のOracle Identity Management製品が実装されているかどうかに関係なく、異種環境とビジネス結合に属するユーザーのフェデレーションが可能になります。


Identity Federation 11gリリース2のみで、サービス・プロバイダ(SP)機能がサポートされます。アイデンティティ・プロバイダ(IDP)サポートでは、Identity Federation 11gリリース1を使用してください。


Identity Federationは、SPとして機能することで、帯域外の複数のセキュリティ・ドメイン間でユーザー同期をせずに、ユーザー認証をIDPにオフロードする間もリソース管理を可能にします。IDPで認証されると、SPは、ローカル・アクセス・ポリシーに応じて、そのSPのアプリケーションに対するユーザーのアクセスを許可または拒否できます。


ユーザーがそのIDPに対するアカウントを持っていない場合、フェデレーションは終了し、そのユーザーのドメイン間でのシングル・サインオンは自動的に無効化されます。


Identity Federationの主要な機能には、次のサポートが含まれます。


    

  • 

    SAML 1.x、SAML 2.0などの複数の主要なフェデレーション・プロトコル
    

    • 

  • 

    プロトコルを超えたシングル・サインオンおよびサインアウト
    

    • 

  • 

    X.509証明書検証
    

    • 

  • 

    Access Managerとのネイティブ統合
    

    • 

  • 

    Access ManagerによりサポートされるすべてのLDAPディレクトリとの統合
    

    • 





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

図9-9の説明が続きます。
 「図9-9 Identity Federationアーキテクチャ」の説明
 



Identity FederationのAccess Managerとの統合方法の詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のAccess Manager 11gR2との統合に関する項を参照してください。





9.5.1.1 Identity Federationコンポーネントの特性


Identity Federationは、クロス・ドメイン・シングル・サインオンにSP機能を提供するOracle Access Managementコンポーネントです。Oracle Access Managementによるリモートアイデンティティ・プロバイダ・パートナへのユーザー認証の委任が可能になります。SAML 1.x、SAML 2.0などの広範なフェデレーション標準のセットをサポートします。






9.5.1.1.1 ランタイム・プロセス


Identity Federationは、WebLogic Server上にデプロイされるAccess Manager J2EEアプリケーションの一部です。


Identity FederationはAccess Server内で動作するため、ランタイム・プロセスはAccess Managerと同じです。詳細は、第9.2.1.1.3項「Access Managerプロセスのライフサイクル」を参照してください。








9.5.1.1.2 プロセスのライフサイクル


Identity FederationのプロセスのライフサイクルはAccess Managerと同じです。詳細は、第9.2.1.1.3項「Access Managerプロセスのライフサイクル」を参照してください。








9.5.1.1.3 リクエスト・フロー


Identity Federationのリクエスト・フローの詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のアーキテクチャに関する項を参照してください。








9.5.1.1.4 構成アーティファクト


Identity Federationの構成アーティファクトには、次のファイルが含まれます。


    

  • 

    DOMAIN_HOME/config/fmwconfig/oam-config.xml — インスタンス固有の情報を格納する構成ファイルです。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/oam-policy.xml — OES Micro SMが使用されていない場合にのみ存在します。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml — ロギング構成です。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/cwallet.sso — アイデンティティ・ストア、データベースおよびその他のエンティティへの接続に使用するパスワードを格納します。これは、エンド・ユーザー用のパスワードではありません。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/.oamkeystore — OAM/Identity Federationが所有する鍵と証明書を格納するキーストアです。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/amtruststore —  X509証明書の検証に使用されるトラスト・アンカーを格納するキーストアです。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/amcrl.jar — 証明書失効に使用するCRLを格納するzipファイルです。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/default-keystore.jks — OWSMエージェントが使用する鍵と証明書を格納するOWSMキーストアです。また、WSS操作のためのX.509証明書の検証に使用されるトラステッド・アンカーも格納されます。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/servers/servername/dms_config.xml — イベント構成ファイルです。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/component_events.xml — 監査定義です。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml — 管理コンソールの権限です。
    

    • 

  • 

    DOMAIN_HOME/config/fmwconfig/cacerts.jks — 認証局証明書を格納するキーストアです。
    

    • 









9.5.1.1.5 外部依存性


Identity Federationサーバーの機能に必要な外部コンポーネントは次のとおりです。


    

  • 

    WebLogic Server
    

      

    • 

      管理サーバー
      

      • 

    • 

      管理対象サーバー
      

      • 

    

    • 

  • 

    LDAPベースのアイデンティティ・ストア
    

      

    • 

      ユーザー・アイデンティティ・リポジトリ
      

      • 

    • 

      ユーザー/ロールAPIによって抽象化されるLDAPアクセス
      

      


      

      


      


      注意:
      

      Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。
      
      		

      
      

      

      

      

      • 

    

    • 

  • 

    OCSPレスポンダ・サービス
    

      

    • 

      リアルタイムX.509認証検証
      

      • 

    

    • 

  • 

    RDBMSポリシー・ストア/Coherenceストア
    

      

    • 

      ポリシー(認証および認可)リポジトリ
      

      • 

    • 

      Access Managerポリシー・エンジンによって抽象化されるRDBMSアクセス
      

      • 

    

    • 

  • 

    Oracle Entitlements Server (OAM経由)
    

    • 

  • 

    フェデレーション・データ・キャッシュ
    

      

    • 

      セッションおよびランタイム情報用。このために、メモリー・ストアまたはRDBMSストアを使用するようにIdentity Federationを構成できます。ただし、高可用性環境では、RDBMSストアを使用する必要があります。
      

      • 

    

    • 




データ・リポジトリ


フェデレーションに関連するセッション情報、ユーザーがサイン・インしたパートナおよびプロトコル・データはセッションおよびキャッシュに格納されます。このデータのために、メモリー・ストアまたはRDBMSストアを使用するようにIdentity Federationを構成できます。高可用性環境では、RDBMSストアを使用する必要があります。








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


WebLogic Serverのログ・ファイルのデフォルトの場所は次のとおりです。


WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log



ログ・ファイルを表示するには、Oracle Enterprise Manager Fusion Middleware Controlを使用します。












9.5.2 Identity Federationの高可用性の概要


この項では、Identity Federationを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。


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






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


図9-10は、Identity Federationのアクティブ/アクティブ構成での高可用性アーキテクチャを示しています。




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

図9-10の説明が続きます
 「図9-10 高可用性アーキテクチャのIdentity Federation」の説明
 



図9-10では、ハードウェアのロード・バランサが着信認証リクエストを受信し、それらをWeb層のWebサーバーにルーティングしています。これらのホストにはOracle HTTP Serverがインストールされています。Oracle HTTP Serverによって、WebLogicプラグインmod_wl_ohs.confが使用されてWebLogic管理対象サーバーにリクエストが転送されます。


ロード・バランシング・ルーターは、HTTPトラフィックに対してのみセッション・スティックネスを使用する必要があります。


Oracle Access Serverアプリケーションをホストする2つの管理対象サーバーは、アクセス・サーバーがアクティブ/アクティブ・モードで動作できるように、クラスタで構成されます。


アクセスされるリソースがフェデレーション・スキームによって保護される場合、OAMはフェデレーション・エンジンを使用してユーザーを認証します。


フェデレーション・エンジンによって使用されるLDAPディレクトリは、クラスタ内にデプロイされます。


Oracle RACデータベースは、データ層における高可用性を提供します。


WebLogic管理サーバーは、管理対象サーバーの1つと同じホスト上で実行され、WebLogic管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Access Managementコンソールをデプロイします。2つ目の管理対象サーバーが動作するホスト・マシン上で、管理サーバーをアクティブ/パッシブ・モードで実行するように構成できます。この構成では、最初の管理サーバーが使用できなくなった場合に、2番目のホスト上の管理サーバーを手動で起動できます。





9.5.2.1.1 クラスタの起動と停止


Identity Federationクラスタは、OAMクラスタと同じ方法で起動および停止します。詳細は、第9.2.2.1.1項「クラスタの起動と停止」を参照してください。








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


1つのクラスタ・メンバーによって加えられた構成変更は、その構成が共有データベースに格納されているため、すべてのメンバーに自動的に伝播されます。詳細は、第9.2.2.1.2項「クラスタワイドの構成変更」を参照してください。










9.5.2.2 Identity Federationの前提条件


Identity FederationはOAMの一部のため、前提条件はOAMと同じです。詳細は、第9.2.3.1項「Access Managerの構成のための前提条件」を参照してください。













注意:


Identity Federationを高可用性デプロイメントで使用する場合は、クラスタ・ノードのシステム・クロックを同期する必要があります。




















9.5.3 Identity Federationの高可用性の構成


OAMサーバー上で動作する機能として、Identity Federationの高可用性をOAMの高可用性の一部として構成します。OAMの高可用性を構成するには、第9.2.3項「Access Managerの高可用性の構成手順」を参照してください。Identity Federationの高可用性の構成時には、次の特別な考慮事項に注意してください。






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


OAMとIdentity Federation構成のホスト名とポートには、ロード・バランサのホストとポートを設定することをお薦めします。このように設定しない場合、シングル・サインオンおよびログアウト操作でエラーが発生します。また、別のホスト上にリストアされた後に、対応するエージェントの構成を更新する必要がないように、OAM構成で仮想化されたホスト名を使用することをお薦めします。








9.5.3.2 プロバイダID値の変更


ProviderIdは、SPを一意に識別する文字列です。クラスタ内のすべてのサーバーのProviderIdは同一である必要があります。インストール時のProviderIdのデフォルトは、http://host:port/oam/fed/です。必要に応じて、インストール後にこの値を変更または設定しますが、運用時には変更しないでください。








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


セッション・データが格納されているRACデータベースへの接続を調整できます。


アーティファクト・プロファイルを使用する場合は、WLSTを使用してSOAP接続の詳細を調整します。


設定可能なIdentity Federationパラメータは次のとおりです。




発信SOAP接続


チューニング可能な発信SOAP接続のパラメータは次のとおりです。


    

  • 

    最大合計接続数
    

    • 

  • 

    ホスト当たりの最大接続数
    

    • 




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


表9-5は、RDBMS一時ストアの非同期設定を示します。




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








設定値
説明








rdbmsasynchronousmanagerinterval




非同期のスレッド・マネージャに対する実行間隔








rdbmsasynchronousmanagersleep




非同期のスレッド・マネージャのスリープ間隔で、実行が発生したかどうかを確認します。








rdbmsasynchronousqueuesize




同じタイプのRDBMS操作(セッションの作成、アーティファクトの作成)が含まれるキューのサイズ








rdbmsasynchronousqueuesleep




キューがいっぱいの場合に、コール元スレッドがキューに操作の追加をリトライできるまでのスリープ時間








rdbmsasynchronousqueueretries




キューがいっぱいの場合に、キューに操作の追加を試みる際のリトライ数








rdbmsasynchronousthreadcore




RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでのデフォルトのスレッド数








rdbmsasynchronousthreadkeepalive




RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでの外部スレッドの最大保持時間








rdbmsasynchronousthreadmax




RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールでの最大スレッド数








rdbmsasynchronousthreadpolicy




RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールのスレッド・ポリシー








rdbmsasynchronousthreadqueuesize




RDBMS非同期操作に対するRDBMSスレッドのエグゼキュータ・モジュールのスレッドのキュー・サイズ












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


表9-6は、RDBMS非同期モジュールとともに使用されるRDBMSアーティファクトのメモリー・キャッシュ設定を示します。




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








設定値
説明








artifactrdbmscachetimeout




メモリー・キャッシュでの存続時間








artifactrdbmsretries




失敗を返すまでのRDBMSでのエントリ検出の最大リトライ数








artifactrdbmssleep




操作の参照をリトライする間のスリープ時間












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


表9-7は、RDBMSのメモリー・キャッシュ設定(アーティファクト設定を除く)を示します(表9-6を参照)。




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








設定値
説明








transientrdbmscachesize




キャッシュ・サイズ








transientrdbmscachetimeout




無効になるか、オブジェクトの検索時にRDBMSの参照操作が強制されるまでのキャッシュ・オブジェクトの存続時間












RDBMSクリーン・アップ・スレッドの間隔


RDBMSクリーンアップのスレッド間隔の設定はrdbmscleanupintervalで、これは、Identity Federationデータベース表から期限切れのエントリを削除するスレッドのスリープ間隔を示します。










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


この項では、高可用性環境にデプロイされたIdentity Federationインスタンスのフェイルオーバー操作の実行手順と、予想される動作について説明します。


Identity Federationインスタンスのフェイルオーバーのテストを実行し、Identity Federationのステータスを確認するには、次の手順に従います。


    

  1. 

    管理サーバーのコンソールにログインします。「ホーム」→「セキュリティ・レルムのサマリー」→「myrealm」→「ユーザーとグループ」→「レルム・ロール」→「グローバル・ロールの編集」の順に移動します。グループOAMAdminstratorsを追加します。
    

    2. 

  2. 

    OAM管理コンソールにログインします。「システム構成」→「共通設定」→「使用可能なサービス」の順に移動して、Identity Federationを有効化します。
    

    3. 

  3. 

    IDPインスタンス(Oracle Identity Federation 11gリリース1インスタンス)とSPとして機能するこのIdentity Federation 11gリリース2インスタンス間に、Identity Federationを設定します。
    

    4. 

  4. 

    OAM 11gR2と統合し、OIFSchemeでリソースを保護します。『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のAccess Manager 11gR2との統合に関する項の手順に従います。
    

    5. 

  5. 

    2つの管理対象サーバーのうちの1つを停止し、保護されたリソースへのアクセスを試みます。
    

    6. 

  6. 

    IDPログイン・ページが表示されたら、前述の手順で停止した管理対象サーバーを再起動して、動作中の管理対象サーバーを停止し、操作の完了を試みます。
    

    7. 









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


Identity Federationに関する問題をトラブルシューティングするには、次のヒントを使用します。


    

  • 

    Identity Federationのメッセージは、次のような管理対象サーバーのログ・ファイルに記録されます。
    

    WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

    • 

  • 

    Identity Federationサーバー構成のホスト名とポートには、ロード・バランサのホストとポートが設定されていることを確認します(このように設定しない場合、シングル・サインオン操作でエラーが発生します)。
    

    • 

  • 

    IDPとSPを実行する各コンピュータのシステム・クロックの時間が異なると、シングル・サインオンの際にエラーが発生します。これを修正するには、同じ時間になるようにシステム・クロックの時間を設定するか、Oracle Enterprise Manager Fusion Middleware Controlの「サーバー・プロパティ」ページを使用してサーバー・ドリフトを調整します。
    

    • 

  • 

    ProviderIdはIDP/SPを一意に識別する文字列であり、クラスタ内のすべてのサーバーで同一である必要があります。インストール時のProviderId文字列のデフォルトは、http://host:port/oam/fedです。ProviderIdを変更する必要がある場合は、運用時ではなく、インストール後に変更してください。
    

    • 











9.6 Oracle Entitlements Serverの高可用性


この項では、Oracle Entitlements Serverの概要およびOracle Entitlements Serverコンポーネントの高可用性環境の設定方法について説明します。


Oracle Entitlements Serverはきめ細やかな認可製品で、これにより組織はリソースへのアクセスと使用を制御するポリシーを定義して管理することで、そのリソースを保護することができます。ポリシーでは、誰が、どのリソースに、いつ、どのように行うことができるかを指定することによって、アクセス権限を定義します。ポリシーでは、ソフトウェア・コンポーネントやビジネス・オブジェクトを含む、すべてのタイプのリソースを制御できます。



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






9.6.1 Oracle Entitlements Serverの高可用性の概要


この項では、Oracle Entitlements Serverを2ノードのクラスタ構成による高可用性で使用する場合の概要について説明します。


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






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


この項では、Oracle Entitlements Serverコンポーネントの次のような高可用性アーキテクチャのシナリオについて説明します。


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






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


図9-11は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたOracle Entitlements Serverの管理サーバーを示しています。




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

図9-11の説明が続きます
 「図9-11 Oracle Entitlements Serverの管理サーバーの高可用性アーキテクチャ」の説明
 



OESHOST1には、次のインストールがあります。


    

  • 

    Oracle Entitlements ServerインスタンスはWLS_OES1管理対象サーバーにインストールされており、APMインスタンスはWLS_OES1管理対象サーバーにインストールされています。
    

    • 

  • 

    Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソースまたはGridLinkデータ･ソース内に構成されています。
    

    • 

  • 

    WebLogic Serverの管理サーバーがインストールされています。通常の運用時は、これがアクティブ管理サーバーになります。
    

    • 



OESHOST2には、次のインストールがあります。


    

  • 

    Oracle Entitlements ServerインスタンスはWLS_OES2管理対象サーバーにインストールされており、APMインスタンスはWLS_OES2管理対象サーバーにインストールされています。
    

    • 

  • 

    Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
    

    • 

  • 

    OESHOST1およびOESHOST2上のWLS_OES1およびWLS_OES2管理対象サーバーのインスタンスは、OES_CLUSTERクラスタとして構成されています。
    

    • 

  • 

    WebLogic Serverの管理サーバーがインストールされています。通常の運用時は、これがパッシブ管理サーバーになります。OESHOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
    

    • 



2つのOracle Entitlements Serverの管理サーバーが登録サーバーとバックアップ登録サーバーとして機能するように、Oracle Entitlements Serverのセキュリティ・モジュールを制御プッシュ・モードで構成できます。登録サーバーが停止した場合、Oracle Entitlements Serverのセキュリティ・モジュールをバックアップ・サーバーに切り替えることができ、Oracle Entitlements Serverの管理サーバーから分散ポリシーを取得できます。フェイルオーバー・シナリオおよび動作の詳細は、第9.6.1.4項「フェイルオーバーに関する考慮事項」を参照してください。








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


セキュリティ・モジュールが埋め込まれ、異なるポリシー情報ポイント(PIP)間でフェイルオーバーするよう構成できるように、セキュリティ・モジュールをデプロイできます。PIPはデータ・リポジトリであり、認可の決定用にポリシーを評価するときに使用するために取得できる情報のソースです。PIPの詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのポリシー情報ポイントに関する説明を参照してください。


デプロイメント・オプションについては次の項目を参照してください。




複数のLDAP/JDBC URLを使用するOracle Entitlements Server PIP


図9-12は、高可用性デプロイメントでの埋込みセキュリティ・モジュール・インスタンスを示しています。LDAPおよびDBベースのPIPの両方を使用して、外部リソース間でフェイルオーバーするために、外部リソースの複数のエンドポイントを構成できます。DBベースのPIPでは、マルチソースのデータ・ソースも構成できます。




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

図9-12の説明が続きます
 「図9-12 セキュリティ・モジュール/ポリシー情報ポイントの高可用性」の説明
 



図9-12は、セキュリティ・モジュール(PDP)がLDAP 1またはDatabase 1をプライマリPIPとして使用するOracle Entitlements Serverのデプロイメントを示しています。フェイルオーバー時には、セキュリティ・モジュールはLDAP2およびDatabase 2にフェイルオーバーされます。



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


Oracle Entitlements Serverの高可用性デプロイメントのもう1つのオプションでは、セキュリティ・モジュール(PDP)はロード・バランサとともにRACデータベースまたはLDAPサーバーを使用します。フェイルオーバー時には、図9-13に示すとおり、セキュリティ・モジュールはRACにフェイルオーバーされます。




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

図9-13の説明が続きます
 「図9-13 RACおよびロード・バランサを使用するOracle Entitlements Server PIP」の説明
 








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


Oracle Entitlements Serverでは、クライアントが認可サービスをリモートで起動できるプロキシ・モードがサポートされます。Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのセキュリティ・モジュールのプロキシ・モードの使用を参照してください。セキュリティ・モジュールのプロキシ・モードでのデプロイには、次の3つのデプロイメント・オプションがあります。




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


図9-14は、WebLogic Server上のWebサービスのセキュリティ・モジュールを示します。




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

図9-14の説明が続きます
 「図9-14 WebLogic Serverデプロイメント上のWebサービスのセキュリティ・モジュール」の説明
 




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


図9-15は、スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメントを示します。




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

図9-15の説明が続きます
 「図9-15 スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメント」の説明
 




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


図9-16は、RMIのセキュリティ・モジュールのデプロイメントを示します。




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

図9-16の説明が続きます
 「図9-16 RMIのセキュリティ・モジュールのデプロイメント」の説明
 








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


Webサービスに対するプロキシ・モードでのセキュリティ・モジュールおよび制御プル・モードでのRMIセキュリティ・モジュールをデプロイするためのオプションは、次のとおりです。




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


図9-17は、WebLogic Server上のWebサービスのセキュリティ・モジュールを示します。




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

図9-17の説明が続きます
 「図9-17 WebLogic Server上のWebサービスのセキュリティ・モジュール」の説明
 




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


図9-18は、スタンドアロンのWebサービスのセキュリティ・モジュールのデプロイメントを示します。




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

図9-18の説明が続きます
 「図9-18 スタンドアロンのWebサービスのセキュリティ・モジュール」の説明
 




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


図9-19は、RMIのセキュリティ・モジュールのデプロイメントを示します。




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

図9-19の説明が続きます
 「図9-19 RMIのセキュリティ・モジュール」の説明
 



Webサービスのセキュリティ・モジュールのプロキシ・クライアントおよびRMIのセキュリティ・モジュールのプロキシ・クライアントの構成の詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのPDPプロキシに関する説明を参照してください。








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


OES WebLogic Serverの高可用性には、次の2つのデプロイメント・オプションがあります。




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


次の図は、制御プッシュ・モードのOracle Entitlements Server WebLogic Serverのセキュリティ・モジュールを示します。




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

図9-20の説明が続きます
 「図9-20 Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュール、制御プッシュ・モード」の説明
 




Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの高可用性、制御プル・モードまたは非制御モード


次の図は、制御プル・モードまたは非制御モードのWebLogic Serverのセキュリティ・モジュールを使用したOracle Entitlements Server を示します。




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

図9-21の説明が続きます
 「図9-21 Oracle Entitlements Server WebLogic Serverのセキュリティ・モジュールの制御プル・モード/非制御モード」の説明
 










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


セキュリティ・モジュールが制御プルまたは非制御分散のOPSSセキュリティ・ストアからポリシーを読み取る場合、アプリケーションによるデータベースへのアクセスでは、Oracleが推奨する高可用性方法を使用してください。








9.6.1.3 ロード・バランシング


すべての高可用性のシナリオで、ロード・バランサをデプロイできます。


    

  • 

    ユーザー対APM通信に対するAuthorization Policy Manager (APM)の前面。ポリシー・ストアに永続化されないデータの損失を防ぐためにスティッキーな接続をお薦めします。
    

    • 

  • 

    クライアント対セキュリティ・モジュール通信に対するWebサービスのセキュリティ・モジュールの前面。キャッシュを最大限に使用するためにスティッキーな接続をお薦めします。
    

    • 














注意:


Oracle Entitlements Serverには、ロード・バランサに対するタイムアウト要件はありません。


















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


この項では、Oracle Entitlements Serverのフェイルオーバーに関する考慮事項について説明します。




表9-8 Oracle Entitlements Serverのフェイルオーバーのシナリオと動作








フェイルオーバーのシナリオ
フェイルオーバーの動作








OESポリシー・ストアの障害




マルチソースのデータ・ソースが使用されている場合、制御プルおよび非制御モードのAPMおよびセキュリティ・モジュールは、作業インスタンスに切り替わります。ポリシー・ストアのインスタンスが失われた場合も、トランザクションは処理されます。


    

  • 

    APMはユーザーにエラーを返し、そのユーザーはリクエストを繰り返すことができます。
    

    • 

  • 

    セキュリティ・モジュールは、トランザクションをリトライします。セキュリティ･モジュールは、読取り操作のみを使用します。セキュリティ･モジュールが制御プル・モードの場合、ローカルに維持されているポリシー・ストアのコピーを使用します。
    

    • 









OES管理サーバーの障害




    

  • 

    ユーザー対APM通信。ロード・バランサが存在する場合、ユーザーは別のAPMインスタンスにリダイレクトされます。ユーザー・セッションの保存されていないデータはすべて失われますが、ユーザーには、維持されているポリシー・データへの完全なアクセス権があります。
    

    • 

  • 

    セキュリティ・モジュール対APM通信。制御プッシュ配布では、セキュリティ・モジュールは起動時にOES Adminに登録され、プライマリ・インスタンスが停止している場合はバックアップ・インスタンスに対してリクエストをリトライします。リトライは、作業インスタンスが検出されるまで継続されます。OES Adminへの接続を試みる間、セキュリティ・モジュールは、ローカルに維持されているポリシー・ストアのコピーを使用します。
    

    • 









Webサービスのセキュリティ・モジュールまたはRMIのセキュリティ・モジュールの障害




セキュリティ・モジュールのプロキシは、構成されているリトライ数に達するまでリクエストをリトライします。








DBまたはLDAP属性ソースの障害




セキュリティ・モジュール(OESクライアント)は、構成されているリトライ数に達するまでデータの読取りを継続します。
















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


この項では、Oracle Entitlements Serverのアクティブ/アクティブ・クラスタにおける様々な障害からの保護について説明します。






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


Oracle Entitlements Serverのフェイルオーバーは透過的ではありません。WebLogic Serverインスタンスのフェイルオーバー時は、Oracle Entitlements Serverを使用して接続を再確立する必要があります。








9.6.1.5.2 ノード障害


ノード障害は、WebLogic Serverのクラッシュと同じ方法で処理されます。








9.6.1.5.3 データベース障害


Oracle Entitlements Serverは、システムの初期設定時に構成したマルチ・データ・ソースの使用によって、データベースの障害から保護されます。マルチ・データ・ソースによって、Oracle RACデータベース・インスタンスで障害が発生した場合に、使用可能なデータベース・インスタンスとの接続が再確立されることが保証されるようになります。マルチ・データ・ソースを使用すると、Oracle RACデータベース内の複数のインスタンスへの接続を構成できます。










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


高可用性アーキテクチャでは、Oracle Entitlements ServerをOracle WebLogicクラスタにデプロイしますが、このクラスタには、その一部として少なくとも2つのサーバーが存在します。


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


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


    

  • 

    WebLogic Server管理コンソール
    

    • 

  • 

    Oracle Enterprise Manager Fusion Middleware Control
    

    • 

  • 

    Oracle WebLogic Scripting Tool(WLST)
    

    • 









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


高可用性環境では、すべてのOracle Entitlements Serverインスタンスが同じ構成リポジトリを共有するため、Oracle Entitlements Serverの1つのインスタンスの構成を変更するとその他すべてのインスタンスの構成も変更されます。ほぼすべてのOracle Entitlements Serverデプロイメントで、クラスタ構成が使用されます。唯一の例外はOracle Entitlements Serverの管理サーバーで、通常、これはクラスタ化されません。








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


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


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










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


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


Oracle Entitlements Server管理サーバーの高可用性デプロイメントは、一般的なOracleアプリケーションと同じです。


Oracle Entitlements Serverの管理サーバー・ユーザー・インタフェースにアクセスするユーザーに対して高可用性を設定するには、WebLogicクラスタを使用します。


管理サーバー・ユーザー・インタフェースに対して高可用性データベースを設定するには、マルチ・ソース・データベース、Oracle RACおよびその他の一般的な要素を使用します。


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






9.6.2.1 Oracle Entitlements Serverの構成の前提条件


Oracle Entitlements Serverの高可用性を構成する前に、次の手順を完了します。


    

  1. 

    リポジトリ作成ユーティリティを使用して、Oracle Entitlements ServerスキーマをOracle RACデータベースに作成します。スキーマの作成の詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Entitlements Serverのインストールと構成ロードマップに関する説明を参照してください。
    

    2. 

  2. 

    OESHOST1およびOESHOST2にWebLogic Serverをインストールします。詳細は、第9.1.3.1.2項「Oracle WebLogic Serverのインストール」を参照してください。
    

    3. 

  3. 

    OESHOST1およびOESHOST2にOracle Entitlements Serverの管理ソフトウェアをインストールします。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Entitlements Server管理サーバーのインストールに関する説明を参照してください。
    

    4. 

  4. 

    Oracle Entitlements Serverクライアントをインストールします。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Entitlementsクライアントのインストールに関する説明を参照してください。
    

    5. 









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


OESHOST1でOES管理サーバー用WebLogicドメインを構成するには、次の手順を実行します。


    

  1. 

    <MW_HOME>/oracle_common/common/bin/config.shスクリプトを実行します(Windowsの場合はconfig.cmd)。Oracle Fusion Middleware構成ウィザードの「ようこそ」画面が表示されます。
    

    2. 

  2. 

    「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。「拡張ソースの選択」画面が表示されます。
    

    3. 

  3. 

    「拡張ソースの選択」画面で、「管理対象サーバー[iam]のOracle Entitlements Server」を選択します。構成ウィザードによって、「Oracle JRF」、「Oracle Platform Security Service」および「Basic WebLogic Server Domain」が自動的に選択されます。
    

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

    4. 

  4. 

    「ドメイン名と場所の指定」画面で、作成しているドメインのドメイン名と場所を入力します。「次へ」をクリックします。「管理者ユーザー名およびパスワードの構成」画面が表示されます。
    

    5. 

  5. 

    管理者のユーザー名とパスワードを構成します。デフォルトのユーザー名はweblogicです。「次へ」をクリックします。
    

    6. 

  6. 

    「サーバーの起動モードおよびJDKの構成」画面で、WebLogicドメインの起動モードとJDKを選択します。
    

    7. 

  7. 

    「JDBCコンポーネント・スキーマの構成」画面で、すべてのスキーマのJDBCプロパティを構成し、「次へ」をクリックします。
    

    8. 

  8. 

    「JDBCコンポーネント・スキーマのテスト」画面で、「すべて選択」をクリックして「接続のテスト」をクリックします。「次」をクリックします。
    

    データ・ソースの検証が成功した場合、「次へ」をクリックします。
    

    データ・ソースの検証に失敗した場合は、「前へ」をクリックして問題を修正し、もう一度実行します。
    

    9. 

  9. 

    「オプションの構成を選択」画面で、「管理対象サーバー、クラスタ、およびマシン」を選択します。「次へ」をクリックします。
    

    10. 

  10. 

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

      

    • 

      名前: AdminServer
      

      • 

    • 

      リスニング・アドレス: All Local Addresses
      

      • 

    • 

      リスニング・ポート: 7001
      

      • 

    • 

      SSLリスニング・ポート: 7002
      

      • 

    • 

      SSL有効を選択
      

      • 

    

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

    11. 

  11. 

    「管理対象サーバーの構成」画面では、この画面を初めて表示したときに、oes_server1という管理対象サーバーが自動的に作成されます。oes_server1の名前を変更し、このエントリに対する属性を更新できます。
    

    例:
    

      

    • 

      名前: oes_server1
      

      • 

    • 

      リスニング・アドレス: OESHOST1.mycompany.com
      

      • 

    • 

      リスニング・ポート: 14600
      

      • 

    • 

      SSLポート: 14601
      

      • 

    

    2つ目のOES_SERVERでは、「追加」をクリックして、次の値を入力します。
    

      

    • 

      名前: oes_server2
      

      • 

    • 

      リスニング・アドレス: OESHOST2.mycompany.com
      

      • 

    • 

      リスニング・ポート: 14600
      

      • 

    • 

      SSLポート: 14601
      

      • 

    • 

      SSL有効を選択
      

      • 

    

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

    12. 

  12. 

    「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
    

    名前oes_clusterを入力します。「クラスタのメッセージング・モード」に「ユニキャスト」を選択し、「クラスタ・アドレス」をoes_server1:portのリスニング・アドレスまたはDNS名,oes_server2:portmanaged server1:portのリスニング・アドレスまたはDNS名,managed server2: portの形式で入力します。
    

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

    13. 

  13. 

    「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。
    

    右のウィンドウで、クラスタ名「oes_cluster」をクリックします。
    

    管理対象サーバー「oes_server1」をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
    

    管理サーバーoes_server2について、前述の手順を繰り返します。
    

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

    14. 

  14. 

    「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
    

    ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。Windowsでは「マシン」タブをクリックし、次に「追加」をクリックして、次のマシンを追加します。
    

    管理サーバー・ホストの場合:
    

      

    • 

      名前: ホストの名前。ここでは、DNS名を使用することをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
      

      • 

    

    その他すべての値はデフォルト設定のままにします。
    

    OESHOST1およびOESHOST2について前述の手順を繰り返し、次の値を入力します。その他すべての値はデフォルト設定のままにします。
    

      

    • 

      名前: ホスト名です。DNS名を使用することをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
      

      • 

    

    Unixオペレーティング・システムでは、「マシン」タブの下にあるデフォルト・ローカル・マシンのエントリを削除します。
    

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

    15. 

  15. 

    「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
    

    右側のウィンドウでマシンをクリックします。
    

    左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。
    

    矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。
    

    すべての管理対象サーバーを適切なマシンに割り当てるまで、この手順を繰り返します。
    

    次のように、サーバーをマシンに割り当てます。
    

      

    • 

      ADMINHOST: 管理サーバー
      

      • 

    • 

      OESHOST1: oes_server1
      

      • 

    • 

      OESHOST2: oes_server2
      

      • 

    

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

    16. 

  16. 

    「構成のサマリー」画面で、「作成」をクリックします。
    

    17. 

  17. 

    OPSSセキュリティ・ストア構成の最初のRACデータベース・インスタンスが動作していることを確認します。
    

    18. 

  18. 

    OPSSセキュリティ・ストアを構成します。『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOES管理サーバーのセキュリティ・ストアの構成に関する説明を参照してください。
    

    19. 









9.6.2.3 構成後および検証


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






9.6.2.3.1 ノード・マネージャの起動


管理ホスト(OESHOST1など)でノード・マネージャを起動するには、次の手順を実行します。


    

  1. 

    MW_HOME/wlserver_10.3/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行します。
    

    2. 

  2. 

    setNMProps.shスクリプトを実行して、StartScriptEnabledプロパティをtrueに設定します。
    

    cd MW_HOME/oracle_common/common/bin
    

    3. 

  3. 

    ノード・マネージャ・プロセスを強制終了してノード・マネージャを停止するか、Windowsでサービスを停止します。
    

    4. 

  4. 

    ノード・マネージャを起動します。
    

    5. 









9.6.2.3.2 WebLogic管理サーバーの検証


次の手順を実行して、管理サーバーが適切に構成されていることを確認します。


    

  1. 

    新しいドメインで./startWeblogic.shを使用して、WebLogic管理サーバーを起動します。
    

    2. 

  2. 

    ブラウザで、次のようなOracle WebLogic Server管理コンソールのURLを入力します。
    

    http://<OESHOST1>:7001/console
    

    3. 

  3. 

    WebLogic管理者(たとえば、weblogic)としてログインします。
    

    4. 









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


packおよびunpackコマンドを使用し、管理サーバーが使用するドメイン・ディレクトリをOESHOST1の管理対象サーバーが使用するドメイン・ディレクトリから分離します。


OESHOST1で独立ドメイン・ディレクトリを作成する手順は次のとおりです。


    

  1. 

    次のようにpackコマンドを実行し、テンプレート・パックを作成します。
    

    cd MW_HOME/oracle_common/common/bin
    

    ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=domaintemplate.jar -template_name=domain_template
    

    2. 

  2. 

    次のようにunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
    

    cd MW_HOME/oracle_common/common/bin
    

    ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=domaintemplate.jar
    

    3. 






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


リモート・ホストの管理対象サーバー(OESHOST2など)を起動する前に、リモート・ホストでunpackを実行します。


    

  1. 

    第9.6.2.3.3項「管理サーバーと同じノードでの管理対象サーバー用独立ドメイン・ディレクトリの作成」で作成したファイルdomaintemplate.jarをOESHOST2にコピーします。
    

    2. 

  2. 

    次のコマンドを使用して、OESHOST2のホストでunpackを実行します。
    

    cd MW_HOME/oracle_common/common/bin
    

    ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=domaintemplate.jar
    

    3. 











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


リモート・ホストでノード・マネージャを起動するには、次の手順を実行します。


    

  1. 

    OESHOST2でノード・マネージャを起動して、MW_HOME/wlserver_10.3/server/binディレクトリにあるstartNodemanager.shスクリプトを使用してnodemanager.propertiesファイルを作成します。
    

    2. 

  2. 

    setNMProps.shスクリプトを実行して、StartScriptEnabledプロパティをtrueに設定します。
    

    cd MW_HOME/oracle_common/common/bin
    

    ./setNMProps.sh
    

    3. 

  3. 

    ノード・マネージャを停止および起動します。
    

    4. 









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


    

  1. 

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

    2. 

  2. 

    ブラウザで、次のようなOracle WebLogic Server管理コンソールのURLを入力します。
    

    http://<OESHOST1>:7001/console
    

    3. 

  3. 

    WebLogic管理者(たとえば、weblogic)としてログインします。
    

    4. 

  4. 

    WebLogic Serverの管理コンソールからoes_server1およびoes_server2管理対象サーバーを起動します。
    

    


    

    


    


    注意:
    

    また、ドメイン・ディレクトリのサブフォルダbinでstartManagedWebLogic.shスクリプトを使用しても、管理対象サーバーを起動できます。例:
    

    ./startManagedWebLogic.sh oes_server1 http://localhost:7001
    
    		

    
    

    

    

    

    5. 

  5. 

    URL(http://<OESHOST1>:14600/apm)でAPMコンソールを開いて、OESHOST1のOES管理サーバー・インスタンスを検証します。
    

    WebLogicユーザー名およびパスワードを使用してログインします。
    

    6. 

  6. 

    http://<OESHOST2>:14600/apmをWebブラウザで指定してAPMコンソールを開き、OESHOST2のOES管理サーバー・インスタンスを検証します。
    

    7. 











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


制御プッシュ・モードのOracle Entitlements Serverのセキュリティ・モジュールを高可用性で構成するには、OESセキュリティ・モジュールの構成ユーザー・インタフェースを使用して高可用性パラメータを設定します。


    

  1. 

    適切なセキュリティ・モジュール・インスタンスのディレクトリのbinディレクトリに変更して、コマンドラインから次のスクリプトを実行します。
    

    cd $OES_CLIENT_HOME/oes_sm_instances/SM_Name/bin
    

    2. 

  2. 

    Linuxではoessmconfig.sh、Windowsではoessmconfig.batを実行して、SMConfig UIを開始します。
    

    SMConfig UIの使用の詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのSMConfig UIの開始に関する説明を参照してください。
    

    3. 

  3. 

    jps-config.xmlファイルに次のパラメータを設定します。
    

      

    • 

      oracle.security.jps.runtime.pd.client.backupRegistrationServerURL
      

      • 

    • 

      oracle.security.jps.runtime.pd.client.registrationRetryInterval
      

      次の例は、RegistrationServerURLに障害が発生した場合にバックアップとして使用されるbackupRegistrationServerURLを示します。
      

      <property name="oracle.security.jps.runtime.pd.client.backupRegistrationServerURL" value="https://slc00bqz:14601/pd-server"/>

      

      

      詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのJavaセキュリティ・モジュールの構成に関する説明を参照してください。
      

      • 

    

    4. 









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


プロキシ・モードのセキュリティ・モジュールをPDPを使用して高可用性に構成するには、次の手順を実行します。


    

  1. 

    プロキシ・モードのセキュリティ・モジュールを構成するには、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのセキュリティ・モジュールのプロキシ・モードの使用を参照してください。
    

    2. 

  2. 

    PDPアドレス(例: oracle.security.jps.pdp.proxy.PDPAddress)に、カンマ区切りの値を追加することで変更します。
    

    例:
    

    oracle.security.jps.pdp.proxy.PDPAddress=http://ws1:9410,http://ws2:9410
    

    詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのPDPプロキシ・クライアントの構成に関する説明を参照してください。
    

    3. 









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


ポリシー情報ポイントの高可用性を構成するには、次の手順を実行します。


    

  1. 

    適切なセキュリティ・モジュール・インスタンスのディレクトリのbinディレクトリに変更して、コマンドラインから次のスクリプトを実行します。
    

    cd $OES_CLIENT_HOME/oes_sm_instances/SM_Name/bin
    

    2. 

  2. 

    Linuxではoessmconfig.sh、Windowsではoessmconfig.batを実行して、SMConfig UIを開始します。
    

    詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのSMConfig UIの開始に関する説明を参照してください。
    

    3. 

  3. 

    ポリシー情報ポイントの高可用性用に次の属性リトリーバ・パラメータを設定します。詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドの属性リトリーバの構成に関する説明を参照してください。
    

    4. 














注意:


ldap.urlまたはjdbc.url属性リトリーバ・パラメータには、複数の値を設定できます。値はカンマで区切り、最初の値は1次値として処理されます。詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドのLDAPリポジトリの属性リトリーバ・パラメータの構成に関する説明を参照してください。


















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


WebLogicのOracle Entitlements Server Webサービスのセキュリティ・モジュールを、WebLogicクラスタを使用して高可用性に構成できます。


WebLogicのOracle Entitlements Server Webサービスのセキュリティ・モジュールを構成するには、次の手順を実行します。



OESHOST1で、次の手順を行います。


    

  1. 

    OESCLIENT_HOME/oessm/bin/config.shを実行して、Webサービスのセキュリティ・モジュールとWebLogic Serverドメインを作成します。
    

    例:
    

    ./config.sh -smType ws -onWLS -smConfigId <ws_name> -serverLocation <wls_home> -pdServer <oes_admin_server> -pdPort <oes_admin_ssl_port> 

    

    2. 

  2. 

    「ようこそ」画面で「WebLogicドメインの作成」を選択し、「次へ」をクリックします。
    

    3. 

  3. 

    「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。リストから「WebLogic上の管理対象サーバー用のOracle Entitlements Server Webサービスのセキュリティ・モジュール」を選択します。
    

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

    4. 

  4. 

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

      

    • 

      ドメイン名: <domain name>
      

      • 

    • 

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

      • 

    

    5. 

  5. 

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

      

    • 

      名前: weblogic
      

      • 

    • 

      ユーザー・パスワード: WebLogicユーザーのパスワード
      

      • 

    • 

      ユーザー・パスワードの確認: WebLogicユーザーのパスワード
      

      • 

    • 

      説明: WebLogicユーザーの説明
      

      • 

    

    6. 

  6. 

    「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JDK」を選択します。
    

    7. 

  7. 

    「オプションの構成を選択」画面で、「AdminServer」および「管理対象サーバー」を選択します。「次へ」をクリックします。
    

    8. 

  8. 

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

      

    • 

      名前: AdminServer
      

      • 

    • 

      リスニング・アドレス: All Local Addresses
      

      • 

    • 

      リスニング・ポート: 7001
      

      • 

    • 

      SSLリスニング・ポート: 7002
      

      • 

    

    SSL有効を選択して「次へ」をクリックします。
    

    9. 

  9. 

    「管理対象サーバーの構成」画面で、デフォルトの管理対象サーバーwsonwls_server1が作成されます。wsonwls_server1の詳細を変更し、2つ目の管理対象サーバーを追加します。
    

    wsonwls_server1では、次の値を入力します。
    

      

    • 

      名前: wsonwls_server1
      

      • 

    • 

      リスニング・アドレス: WSSMHOST1
      

      • 

    • 

      リスニング・ポート: 14610
      

      • 

    • 

      SSLリスニング・ポート: 14611
      

      • 

    

    2つ目の管理対象サーバーでは、「追加」をクリックして、次の値を入力します。
    

      

    • 

      名前: wsonwls_server2
      

      • 

    • 

      リスニング・アドレス: WSSMHOST2
      

      • 

    • 

      リスニング・ポート: 14610
      

      • 

    • 

      SSLリスニング・ポート: 14611
      

      • 

    

    10. 

  10. 

    「クラスタの構成」画面で、「追加」をクリックしてwssm_clusterを入力します。「クラスタのメッセージング・モード」に「unicast」を選択し、クラスタ・アドレスをmanaged_ server1:port,managed_server2: portのように入力します。
    

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

    11. 

  11. 

    「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。
    

      

    • 

      右のウィンドウで、クラスタ「wssm_cluster」をクリックします。
      

      • 

    • 

      管理対象サーバー「wsonwls_server1」をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
      

      管理サーバーwsonwls_server2について、前述の手順を繰り返します。
      

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

      • 

    

    12. 

  12. 

    「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
    

    ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。Windowsでは「マシン」タブをクリックし、次に「追加」をクリックして、次のマシンを追加します。
    

    管理サーバー・ホストの場合:
    

      

    • 

      名前: ホストの名前。ここでは、DNS名を使用することをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
      

      • 

    

    その他すべての値はデフォルト設定のままにします。
    

    WSSMHOST1およびWSSMOESHOST2について前述の手順を繰り返し、次の値を入力します。その他すべての値はデフォルト設定のままにします。
    

      

    • 

      名前: ホスト名です。DNS名を使用することをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
      

      • 

    

    Unixオペレーティング・システムでは、「マシン」タブの下にあるデフォルト・ローカル・マシンのエントリを削除します。
    

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

    13. 

  13. 

    「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを次の手順で割り当てます。
    

    右側のウィンドウでマシンをクリックします。
    

    左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。
    

    矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。
    

    すべての管理対象サーバーを適切なマシンに割り当てるまで、この手順を繰り返します。
    

    次のように、サーバーをマシンに割り当てます。
    

      

    • 

      ADMINHOST: 管理サーバー
      

      • 

    • 

      WSSMHOST1: wsonwls_server1
      

      • 

    • 

      WSSMHOST2: wsonwls_server2
      

      • 

    

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

    14. 

  14. 

    「構成のサマリー」画面で、「作成」をクリックします。
    

    15. 

  15. 

    新しいドメインで./startWeblogic.shを使用して、WebLogic管理サーバーを起動します。
    

    16. 

  16. 

    管理対象サーバーを起動します。作成したドメイン・ディレクトリのサブフォルダbinに切り替え、./startManagedWebLogic.sh 管理対象サーバー名  http://wlsadminserver host:wls_adminserver_portを入力します。
    

    例:
    

    ./startManagedWeblogic.sh wsonwls_server1 http://localhost:7001
    

    17. 




OESHOST2で、次の手順を行います。


packおよびunpackコマンドを使用し、OES WebサービスSMが使用するドメイン・ディレクトリをOESHOST1の管理対象サーバーが使用するドメイン・ディレクトリから分離します。


ドメイン･ディレクトリの分離の手順は、第9.6.2.8項「Oracle Entitlements Server WebLogicセキュリティ・モジュールの高可用性の構成」を参照してください。








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


Oracle Entitlements Server WebLogicセキュリティ・モジュールを、WebLogicクラスタを使用して高可用性に構成できます。


Oracle Entitlements Server WebLogicセキュリティ・モジュールを構成するには、次の手順を実行します。



OESHOST1で、次の手順を行います。


    

  1. 

    OESCLIENT_HOME/oessm/bin/config.shを実行して、WebLogicセキュリティ・モジュールとWebLogic Serverドメインを作成します。
    

    例:
    

    ./config.sh -smType wls -smConfigId <wls_name> -serverLocation <wls_home> -pdServer <oes_admin_server> -pdPort <oes_admin_ssl_port> 

    

    2. 

  2. 

    「ようこそ」画面で「WebLogicドメインの作成」を選択し、「次へ」をクリックします。
    

    3. 

  3. 

    「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。リストから「WebLogic上の管理対象サーバー用のOracle Entitlements Server WebLogicのセキュリティ・モジュール」を選択します。
    

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

    4. 

  4. 

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

      

    • 

      ドメイン名: <domain name>
      

      • 

    • 

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

      • 

    

    5. 

  5. 

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

      

    • 

      名前: weblogic
      

      • 

    • 

      ユーザー・パスワード: WebLogicユーザーのパスワード
      

      • 

    • 

      ユーザー・パスワードの確認: WebLogicユーザーのパスワード
      

      • 

    • 

      説明: WebLogicユーザーの説明
      

      • 

    

    6. 

  6. 

    「サーバーの起動モードおよびJDKの構成」画面で、「本番モード」および「JDK」を選択します。
    

    7. 

  7. 

    「オプションの構成を選択」画面で、「AdminServer」および「管理対象サーバー」を選択します。「次へ」をクリックします。
    

    8. 

  8. 

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

      

    • 

      名前: AdminServer
      

      • 

    • 

      リスニング・アドレス: All Local Addresses
      

      • 

    • 

      リスニング・ポート: 7001
      

      • 

    • 

      SSLリスニング・ポート: 7002
      

      • 

    

    SSL有効を選択して「次へ」をクリックします。
    

    9. 

  9. 

    「管理対象サーバーの構成」画面で、デフォルトの管理対象サーバーwlssm_server1が作成されます。デフォルトの管理対象サーバーの詳細を変更し、2つ目の管理対象サーバーを追加します。
    

    デフォルトの管理対象サーバーでは、次の値を入力します。
    

      

    • 

      名前: wlssm_server1
      

      • 

    • 

      リスニング・アドレス: WLSSMHOST1
      

      • 

    • 

      リスニング・ポート: 14610
      

      • 

    • 

      SSLリスニング・ポート: 14611
      

      • 

    

    2つ目の管理対象サーバーでは、「追加」をクリックして、次の値を入力します。
    

      

    • 

      名前: wlssm_server2
      

      • 

    • 

      リスニング・アドレス: WLSSMHOST2
      

      • 

    • 

      リスニング・ポート: 14610
      

      • 

    • 

      SSLリスニング・ポート: 14611
      

      • 

    

    10. 

  10. 

    「クラスタの構成」画面で、「追加」をクリックしてwlssm_clusterを入力します。「クラスタのメッセージング・モード」に「unicast」を選択し、クラスタ・アドレスをmanaged_ server1:port,managed_server2: portのように入力します。
    

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

    11. 

  11. 

    「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。
    

      

    • 

      右のウィンドウで、クラスタ「wlssm_cluster」をクリックします。
      

      • 

    • 

      管理対象サーバー「wlssm_server1」をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
      

      管理サーバーwlssm_server2について、前述の手順を繰り返します。
      

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

      • 

    

    12. 

  12. 

    「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
    

    ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。Windowsでは「マシン」タブをクリックし、次に「追加」をクリックして、次のマシンを追加します。
    

    管理サーバー・ホストの場合:
    

      

    • 

      名前: ホストの名前。ここでは、DNS名を使用することをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
      

      • 

    

    その他すべての値はデフォルト設定のままにします。
    

    WLSSHOST1およびWLSSMOESHOST2について前述の手順を繰り返し、次の値を入力します。その他すべての値はデフォルト設定のままにします。
    

      

    • 

      名前: ホスト名です。DNS名を使用することをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: マシンのIPアドレスは、マシンのDNS名と同じにすることをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・ポート: ノード・マネージャが使用するポートを入力します。
      

      • 

    

    Unixオペレーティング・システムでは、「マシン」タブの下にあるデフォルト・ローカル・マシンのエントリを削除します。
    

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

    13. 

  13. 

    「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
    

    右側のウィンドウでマシンをクリックします。
    

    左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。
    

    矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。
    

    すべての管理対象サーバーを適切なマシンに割り当てるまで、この手順を繰り返します。
    

    次のように、サーバーをマシンに割り当てます。
    

      

    • 

      ADMINHOST: 管理サーバー
      

      • 

    • 

      WLSSMHOST1: wlssm_server1
      

      • 

    • 

      W:SSMHOST2: wlssm_server2
      

      • 

    

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

    14. 

  14. 

    「構成のサマリー」画面で、「作成」をクリックします。
    

    15. 

  15. 

    新しいドメインで./startWeblogic.shを使用して、WebLogic管理サーバーを起動します。
    

    16. 

  16. 

    管理対象サーバーを起動します。作成したドメイン・ディレクトリのサブフォルダbinに切り替え、./startManagedWebLogic.sh 管理対象サーバー名  http://wlsadminserver host:wls_adminserver_portを入力します。
    

    例:
    

    ./startManagedWeblogic.sh wlssm_server1 http://localhost:7001
    

    17. 



packおよびunpackコマンドを使用し、WebLogic Serverセキュリティ・モジュールが使用するドメイン・ディレクトリをOESHOST1の管理対象サーバーが使用するドメイン・ディレクトリから分離します。


OESHOST1で独立ドメイン・ディレクトリを作成する手順は次のとおりです。


    

  1. 

    次のようにpackコマンドを実行し、テンプレート・パックを作成します。
    

    cd MW_HOME/oracle_common/common/bin
    

    ./pack.sh -managed=true -domain=domain_path -template==domaintemplate.jar -template_name=domain_template
    

    2. 

  2. 

    次のようにunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
    

    cd MW_HOME/oracle_common/common/bin
    

    ./unpack.sh -domain=new_domain_path -template=domaintemplate.jar
    

    たとえば管理対象サーバー(OESHOST2など)を起動する前に、リモート・ホストでunpackを実行します。
    

    3. 

  3. 

    手順1のファイルdomaintemplate.jarをOESHOST2にコピーします。
    

    4. 

  4. 

    次のコマンドを使用して、OESHOST2のホストでunpackを実行します。
    

    cd MW_HOME/oracle_common/common/bin
    

    ./unpack.sh -domain=domain_path -template==domaintemplate.jar
    

    5. 

  5. 

    管理対象サーバーの起動後、作成したドメイン･ディレクトリのサブフォルダbinに切り替えます。./startManagedWebLogic.sh 管理対象サーバー名 http://wlsadminserver host:wls_adminserver_portを入力します。
    

    例:
    

    ./startManagedWeblogic.sh wlssm_server2 http://localhost:7001
    

    6. 









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


ポリシー・ストアへの接続は、制御プル・モードおよび非制御モードのOracle Entitlements Serverセキュリティ・モジュールで使用されます。SMConfig UIの制限によって、セキュリティ・モジュール・インスタンスの作成時にJDBCプロパティを構成する必要があります。


RACデータ・ソースをWebLogic Serverセキュリティ・モジュールまたはWebLogic Server上のWebサービスのセキュリティ・モジュールで使用するには、セキュリティ・モジュール・インスタンスの作成後に、次の手順を実行します。


    

  1. 

    セキュリティ・モジュールがデプロイされているドメインのWebLogic管理コンソールにログインします。Oracle Entitlements Serverの管理サーバーと同じデータベース情報を使用して、RACデータ・ソースを構成します。
    

    2. 

  2. 

    SMConfig UIで、セキュリティ・モジュール構成を編集します。
    

      

    • 

      OES_CLIENT_HOME/oes_sm_instances/SM_Name/binを実行します。
      

      • 

    • 

      Linuxではoessmconfig.sh、Windowsではoessmconfig.batを実行します。
      

      • 

    • 

      「JNDI名によるデータベース構成」を選択して、* データソースJNDI名フィールドにRACデータ・ソースJNDI名を入力します。「保存して閉じる」をクリックします。
      

      • 

    

    3. 









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


この項では、Oracle Web Tierと連携するためのOracle Entitlements Serverの構成方法について、次の項目について説明します。






9.6.2.10.1 前提条件


次のタスクが実行済であることを確認します。


    

  1. 

    Oracle Web TierをWEBHOST1とWEBHOST2にインストールしました。
    

    WEBHOST1およびWEBHOST2にOracle HTTP Serverをインストールする手順は、第8.5.3.5.1項「Web Tier用のOracle HTTP Serverのインストール」を参照してください。
    

    2. 

  2. 

    Oracle Entitlements Serverを、OESHOST1およびOESHOST2上にインストールし、構成しました。
    

    3. 

  3. 

    ロード・バランサをWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(sso.mycompany.com)で構成しました。
    

    4. 

  4. 

    ロード・バランサをWEBHOST1およびWEBHOST2上のWebサーバーを指す仮想ホスト名(oesinternal.mycompany.com)で構成しました。
    

    5. 









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


    

  1. 

    WEBHOST1とWEBHOST2上の各Webサーバーで、oes.confと呼ばれるファイルをORACLE_INSTANCE/config/OHS/component/moduleconfディレクトリに作成します。このファイルには次の情報が記載されている必要があります。
    

    NameVirtualHost *:7777 
<VirtualHost *:7777> 
ServerName http://sso.mycompany.com:7777 
RewriteEngine On 
RewriteOptions inherit 
UseCanonicalName On 

# OES admin console 
 <Location /apm>
SetHandler weblogic-handler 
WebLogicCluster oeshost1.mycompany.com:14600,
oeshost2.mycompany.com:14600 
</Location> 

    2. 

  2. 

    このファイルをWEBHOST1とWEBHOST2の両方に保存します。
    

    3. 

  3. 

    第8.7項「コンポーネントの起動と停止」の説明に従い、WEBHOST1およびWEBHOST2上のOracle HTTP Serverインスタンスを停止してから起動します。
    

    4. 









9.6.2.10.3 Oracle HTTP Serverの構成の検証


Oracle HTTP Serverが適切に構成されていることを検証する手順は次のとおりです。


    

  1. 

    Webブラウザで、Oracle Identity Managerコンソール用の次のURLを入力します。
    

    http://sso.mycompany.com:7777/apm
    

    2. 

  2. 

    APMのログイン・ページで、weblogicユーザーの資格証明を使用してログインします。
    

    3. 















9.7 Oracle Access Management Mobile and Socialの高可用性


この項では、Oracle Access Management Mobile and Socialの高可用性フレームワークについて説明します。内容は次のとおりです。






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


Oracle Access Management Mobile and Social (Mobile and Social)は、既存のIdentity Managementインフラストラクチャをモバイルおよびソーシャル・ネットワークに接続する軽量のセキュリティおよびアイデンティティ・ソリューションです。Mobile and Socialを使用することで、制御されたビューを外側の世界に安全に公開できます。Mobile and Socialでは、ソーシャル・メディアのユーザー・アイデンティティを管理されたエンタープライズ内のエンタープライズ・アプリケーションおよびポータルで使用するためのメカニズムが提供されています。Mobile and Socialは、OAMおよびIGFを含む既存のIDM製品と統合されます。Mobile and Socialの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle Access Management Mobile and Socialに関する説明を参照してください。


図9-22は、Mobile and Socialコンポーネントのアーキテクチャを示しています。




図9-22 Mobile and Socialコンポーネント・アーキテクチャ

OIC非高可用性アーキテクチャ
 「図9-22 Mobile and Socialコンポーネント・アーキテクチャ」の説明
 



Oracle Access Management Mobile and Socialサービスは、保護されているリソースへのアクセスを必要とするユーザーと、リソースを保護するバックエンドのアクセス管理サービスおよびアイデンティティ管理サービスの間の橋渡しの役割を果たします。Mobile and Socialでは簡易クライアント・ライブラリが提供され、開発者はこれを使用することで、機能豊富な認証、認可およびアイデンティティ機能を登録済アプリケーションに簡単に追加することができます。バックエンドのMobile and Socialサーバーのプラガブルなアーキテクチャにより、システム管理者は、ユーザーがインストールしたソフトウェアをアップデートしなくても、アイデンティティ管理サービスおよびアクセス管理サービスを追加、変更および削除することができます。





9.7.1.1 セッションの状態情報


モバイル・サービス・コンポーネントでは、セッション情報は記録されません。インターネット・アイデンティティ・サービスでは、短期間のトークンがメモリーに保持され、期限が切れると破棄されます。








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


Mobile and Socialは、Access Suite J2EEアプリケーション内のコンポーネントです。Mobile and SocialはAccess Suiteの一部としてデプロイおよび構成されるため、インストール、構成、サーバー・インスタンスはAccess Suiteと関連付けられます。


モバイル・サービスおよびインターネット・アイデンティティ・サービスの一部として、Mobile and Socialでは、クライアントで起動するHTTPインタフェースを提供しています。Mobile and Socialは、リクエストを処理してレスポンスを返しますが、クライアントはこれを使用して追加のリクエストを行う場合があります。Mobile and Socialはステートレスであり、クライアントから個別に送信されたすべてのリクエストを処理できます。Mobile and Socialでは、OAMなどの製品や、ソーシャル・ネットワーク認証およびディレクトリ・サーバーを使用したユーザー・プロファイル・サービスを使用した、モバイル・デバイスの登録サービスおよびユーザー認証サービスが提供されます。


Mobile and Socialは、Access Suiteサーバーの起動の一部として起動されます。MBeanサーバーは、Mobile and Socialの構成をロードします。








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


管理コンソールまたはWLSTコマンドを使用して、構成ファイルを編集します。表9-9に、Mobile and Socialの構成ファイルとその場所を示します。




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








ファイル
場所








Idaas.xml




<DOMAIN_HOME>/config/fmwconfig








oic_rp.xml




<DOMAIN_HOME>/config/fmwconfig
















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


A Mobile and Socialインストールでは、次のコンポーネントがoam-server.earの一部としてデプロイされます。


    

  • 

    oic_rest.war
    

    • 

  • 

    oic_rp.war
    

    • 



表9-10に、Mobile and Socialサービスのデプロイメントの場所を示します。




表9-10 Mobile and Social製品のデプロイメントの場所








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








管理サーバー




管理サーバーのユーザー・インタフェースは、OAM Adminの.ear (oam-admin.ear)の一部としてデプロイされます。








管理対象サーバー、RESTおよびインターネット・アイデンティティ・サービスのランタイム




OAMサーバーの.earファイル(oam-server.ear)の一部としてデプロイされます。


















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


Mobile and Socialサービスは、モバイル・サービスとインターネット・アイデンティティ・サービスの2つのサブコンポーネントで構成されます。モバイル・サービスでは、認証、ユーザー・プロファイルおよび認可サービス用にRepresentational State Transfer (REST)インタフェースが提供されます。インターネット・アイデンティティ・サービスでは、ソーシャル・ネットワーク認証との統合が提供されます。


Mobile and Socialの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のモバイル・サービスの概要に関する説明を参照してください。








9.7.3 Mobile and Socialの高可用性の概要


この項では、Mobile and Socialの高可用性アーキテクチャおよびその要素について説明します。内容は次のとおりです。






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


図9-23は、アクティブ/アクティブ構成で高可用性アーキテクチャにデプロイされたMobile and Socialを示しています。




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

図9-23の説明が続きます
 「図9-23 Mobile and Socialの高可用性アーキテクチャ」の説明
 



図9-23は、複数インスタンスのデプロイメントをサポートする標準的なクライアント・サーバー・アーキテクチャを示しています。ほとんどの場合、リクエストはステートレスで、永続性は必要ありません。Mobile and Socialサービスは、OAM/OIDなどの他の製品に依存しており、それらに独自の高可用性機能がある場合があります。状態が保持される場合(インターネット・アイデンティティ認証リクエスト)、高可用性はスティッキーなロード・バランシングを介して実現されます。


セッションのデータベース永続性やランタイム・データがないため、リクエストはどのサーバーにも送信されることができます。ロード・バランサは、Round Robinなどのポリシー・セットに基づいて、リクエストをMobile and Socialサービス1または2に返します。


アプリケーションでインターネット・アイデンティティ・サービスが起動されると、リクエストを処理するために、Google、Facebookまたはインターネット・アイデンティティ・プロバイダに制御が移ります。アイデンティティ・プロバイダからレスポンスが返されるときは、そのリクエストを開始した同じサーバーにレスポンスが返される必要があります。複数のMobile and Socialノード・デプロイメントがあり、アクセスがロード・バランサを介して行われる場合は、Mobile and Socialへのリクエストは、ロード・バランサのスティッキー・セッション機能を使用して同じサーバーに固定される必要があります。IDPへのリクエストを開始したMobile and SocialがIDPレスポンスを受信した後に、Mobile and Socialは、そのリクエストに対してさらに処理を行うことができます。


Mobile and Socialアプリケーションは、クラスタ内のすべてのメンバーにデプロイされます。クラスタでのデプロイ成功時に、Mobile and Socialアプリケーションは他のクラスタ・メンバーに通知はしません。








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


この項では、ノード障害からの保護を提供するMobile and Socialアーキテクチャの要素について説明します。


ノード・フェイルオーバーが発生した場合、Mobile and Socialは、WebLogic Serverの標準のフェイルオーバー手順に従うことに注意してください。クライアントから受信したリクエストをMobile and Socialで完了する前にノード障害が発生した場合、クライアントは、HTTP接続タイムアウトを介してエラーを受信します。


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






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


Mobile and Socialコンポーネントは、WebLogic Server 10.3にデプロイされる標準のJ2EEアプリケーションで、ロード・バランシング向けの標準に準拠しています。次のことに注意してください。


    

  • 

    Mobile and Social/RPのリクエストではスティッキーなセッション・ルーティングを使用する必要がありますが、外部ロード・バンランサはサポートされています。
    

    • 

  • 

    コンポーネント間のロード・バランシングはありません。
    

    • 

  • 

    永続接続がないため、タイムアウト要件はありません。
    

    • 









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


Mobile and Socialの高可用性アーキテクチャは、フェイルオーバー要件についてはWebLogic Serverの標準のクラスタ・サポートに依存します。このアーキテクチャでは、セッション状態はレプリケートされません。








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


Mobile and Socialインスタンスの起動時に、動作中のシステムの状態には影響しません。Mobile and Socialインスタンスは、WebLogic Serverのクラスタ化のシナリオに参加する場合を除いて、他の動作中のコンポーネントやクラスタ・メンバーには影響しません。





9.7.3.2.4 障害検出と再起動


障害検出およびコンポーネントの再起動に、Java EEコンポーネントのノード・マネージャおよびシステム・コンポーネントのOPMNを使用します。














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


Mobile and Socialは、Oracle Access Managerと同一の管理対象サーバーの一部です。


Mobile and Socialは個別に、あるいはOAM、STSおよびIdentity Federationなどの別のコンポーネントとともにデプロイできます。


次のMobile and Social構成の前提条件に注意してください。


    

  • 

    無効になっている場合は、Mobile and Socialを有効化する必要があります。Oracle Access Managementコンソールにログインし、「システム構成」タブを選択して、「使用可能なサービス」を開き、Mobile and Socialのステータスに緑色のチェックが表示されていることを確認します。
    

    • 

  • 

    ORACLE_INSTANCE/config/OHS/ohs1/moduleconfのoam.confファイルに次のマッピングを追加することによって、oic_restおよびoic_rpにOHSを構成する必要があります。
    

     <Location /oic_rest>
   SetHandler weblogic-handler
   WebLogicCluster 
   oamhost1.mycompany.com:14100,oamhost2.mycompany.com:14100 
 </Location>

 <Location /oic_rp>
   SetHandler weblogic-handler
   WebLogicCluster 
   oamhost1.mycompany.com:14100,oamhost2.mycompany.com:14100 
 </Location>

    • 











9.8 Oracle Privileged Account Managerの高可用性


Oracle Privileged Account Managerは、他のどのOracle Identity Managementコンポーネントにも管理されない特権アカウントを管理します。機密データにアクセスできる場合、機密データへのアクセス権限を付与できる場合または機密データへのアクセスとアクセス権限の付与の両方ができる場合に、アカウントは特権とみなされます。


Oracle Privileged Account Managerの詳細とその機能については、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のOracle Privileged Account Managerの理解に関する説明を参照してください。


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






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


Oracle Privileged Account Manager (OPAM)は、サーバーおよびWebアプリケーションとして動作するユーザー・インタフェース・コンポーネントで構成されます。OPAMサーバーは、WebLogic管理対象サーバー内で実行されます。OPAMユーザー・インタフェースはOracle Identity Navigator (OIN)の一部で、WebLogic管理サーバー内で実行されます。


OPAMデプロイメントのデフォルトの最も簡単な構成では、WebLogicドメイン内の単一のOPAM管理対象サーバーの実行が必要です。OPAMは、独自のスキーマを使用してターゲットのパスワード、アカウント、その他のアイテムを格納します。デフォルトのOPSSセキュリティ・ストアの設定では、記憶域にXMLが使用されます。本番マシンでは、OPSSセキュリティ・ストアのバックエンドとしてLDAPまたはDatabaseの使用が推奨されますが、デフォルト構成を動作させるには、XMLストアで十分です。


次の図は、Oracle Privileged Account Managerのアーキテクチャとトポロジを示しています。




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

図9-24の説明が続きます
 「図9-24 Oracle Privileged Account Managerコンポーネント・アーキテクチャ」の説明
 



このアーキテクチャでは、次の点に注意してください。


    

  • 

    Oracle Privileged Account Managerのコア・ロジックはすべてOracle Privileged Account Managerサーバーに存在します。この機能は、Representational State Transfer (RESTまたはRESTful)サービスを介して公開されますが、データはJavaScript Object Notation (JSON)でエンコードされます。
    

    


    

    


    


    注意:
    

    Oracle Privileged Account Managerでは、Oracle Identity NavigatorのWebベースのユーザー・インタフェースおよびOracle Privileged Account Managerコマンドライン・ツールが提供されます。どちらのインタフェースも基本的に、Oracle Privileged Account Managerサーバーのクライアントです。
    

    ただし、サードパーティはオープンなRESTfulサービスを利用することで、カスタム・アプリケーションなどの独自のクライアントに書き込むことができます。詳細は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のOracle Privileged Account ManagerのRESTfulインタフェースの使用に関する説明を参照してください。
    
    		

    
    

    

    

    

    • 

  • 

    Oracle Privileged Account Managerの認証は、WebLogicのJava Authentication & Authorization Service (JAAS)サポートに依存します。WebLogicでのJAASサポートの詳細は、Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの理解のWebLogicセキュリティ・サービス・アーキテクチャに関する説明を参照してください。
    

    • 

  • 

    Oracle Privileged Account Manager関連のコンポーネントとの、およびコンポーネント間のすべての通信(Oracle Privileged Account ManagerのWebベースのユーザー・インタフェース、コマンドライン・インタフェースおよびサーバーを含む)は、すべてSSL経由で行われます。
    

    • 

  • 

    Oracle Privileged Account Managerは、Oracle Privileged Account Managerのデプロイ先であるWebLogicドメインで構成されているIDストアおよびポリシー・ストアに依存し、それらを透過的に使用します。
    

    詳細は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のDeployed in Oracle Fusion MiddlewareでのOracle Privileged Account Managerのデプロイに関する説明を参照してください。
    

    • 

  • 

    Oracle Privileged Account ManagerのWebベースのユーザー・インタフェースは、Oracle Application Development Framework (ADF)を利用して、表示されます。
    

    • 

  • 

    Oracle Privileged Account Managerは、Identity Connector Framework (ICF)コネクタを使用してターゲットに接続します。詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のIdentity Connector Frameworkの理解に関する説明を参照してください。
    

    • 



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






9.8.1.1 ランタイム・プロセス


OPAMサーバーは、WebLogic管理対象サーバーを実行するサーバー・コンポーネントです。OPAMユーザー・インタフェースは、WebLogic管理サーバーで実行されるコンポーネントです。OPAMサーバーは、OPAM GUIおよびコマンドライン・クライアントを含むクライアントとの通信に、RESTプロトコルを使用します。OPAMサーバーは、OPSSセキュリティ・ストアをデータ・ストアとして使用します。OPAMサーバーは、複数のサーバーがあるWebLogicクラスタにデプロイでき、WebLogicコンソールを使用して処理を管理します。








9.8.1.2 プロセスのライフサイクル


OPAMサーバーは、WebLogic ServerにデプロイされるJ2EEアプリケーションです。


起動時に、OPAM Lifecycle Listenerは、キーストアがそのドメインに存在するかどうかを確認します。


    

  • 

    キーストアが存在しない場合は、OPAM Lifecycle Listenerは、ランダムに生成されたキーストアのパスワードを使用してキーストアを作成し、ドメイン名を別名としたキーストア・エントリを作成し、そのキーストア・パスワードを使用してCSFを更新します。
    

    • 

  • 

    キーストアが存在する場合は、CSFからキーストア・パスワードを取得して、ドメイン名を別名とするエントリが存在するかどうかを確認します。
    

    • 



キーストアおよび目的のキーストアのCSFエントリが存在する場合は操作を行わないため、OPAMの高可用性環境はプロセスのライフサイクルに影響しません。


OPAMはサーブレット・モデルを使用し、クライアントは、RESTベースのHTTPS URLを使用して処理されます。


コンポーネントのライフサイクルは、その他の実行中のインスタンスに影響しません。


CSFの詳細は、『Oracle Fusion Middleware Oracle Privileged Account Manager管理者ガイド』のOracle Privileged Account Manager管理対象CSF資格証明に関する説明を参照してください。








9.8.1.3 セッションの状態


OPAMサーバーは、RESTベースの通信を使用して、クライアントとの通信ではHTTPS URLを使用します。セッションの状態情報は保存されません。各通信で操作を完了すると、セッションは保持されません。








9.8.1.4 外部依存性


OPAMサーバーの依存性の内容は次のとおりです。


    

  • 

    ICFコネクタ、ターゲット・システムとの通信用
    

    • 

  • 

    外部IDストア、認証用(WebLogicで構成可能)
    

    • 



OPAMユーザー・インタフェースおよびOPAMコマンドライン・ツールはOPAMサーバーに依存します。HTTPS URLを使用するRESTであるクライアント接続は短期です。








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


OPAMを管理対象サーバーにデプロイした場合、Oracle Identity Navigatorは管理サーバーにデプロイされます。Oracle JRFは、管理サーバーと管理対象サーバーの両方にデプロイされます。表9-11は、OPAM製品アーティファクトのデプロイ先を示します。




表9-11 OPAMデプロイメント・アーティファクト








場所
製品アーティファクト








管理サーバー




Oracle Identity Navigator .ear file、Oracle JRF








管理対象サーバー




OPAMサーバー.ear file、Oracle JRF
















9.8.1.6 ログ・ファイルの場所


WebLogic Serverのログおよび監査ログは、DOMAIN_HOMEに保存されます。


監査ログがWebLogicに構成されている場合は、監査データベースに保存されます。










9.8.2 Oracle Privileged Account Managerの高可用性の概要


クラスタ・レベルで、Connectorディレクトリ、時間制限などのOPAMプロパティを変更できます。


すべてのサーバーは、構成が保持されている共通ドメインのOPAMデータ・ストアに接続します。したがって、すべてのサーバーは共有データを取得します。








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


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




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

図9-25の説明が続きます
 「図9-25 高可用性アーキテクチャのOracle Privileged Account Manager」の説明
 



図9-25に示す構成では、Oracle Privileged Account Managerの各サーバーは、同じドメインの一部であり、同じOPSSセキュリティ・ストアを使用します。複数のサーバーがOPSSセキュリティ・ストアと対話するため、データベースをOPSSバックエンドとして使用することをお薦めします。


このクラスタ構成では、クラスタ内の別のサーバーから同じデータを使用できます。各管理対象サーバーには独自のポート構成があります。図9-25の構成には、ロード・バランサが含まれています。


OPAMHOST1には、次のインストールがあります。


    

  • 

    WLS_OPAM1管理対象サーバーのOracle Privileged Account Managerインスタンス。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
    

    • 

  • 

    WebLogic Serverの管理サーバー。通常の運用時は、これがアクティブ管理サーバーになります。
    

    • 



OPAMHOST2には、次のインストールがあります。


    

  • 

    WLS_OPAM2管理対象サーバーのOracle Privileged Account Manager。Oracle RACデータベースは、インスタンスをOracle RACノードの障害から保護するためにJDBCマルチ・データ・ソース内に構成されています。
    

    WLS_OPAM2管理対象サーバーにあるインスタンスと、WLS_OPAM1管理対象サーバーにあるインスタンスは、CLUSTER_OPAMクラスタとして構成されています。
    

    • 

  • 

    WebLogic Serverの管理サーバー。通常の運用時は、これがパッシブ管理サーバーになります。HOST1の管理サーバーが使用できなくなった場合は、この管理サーバーをアクティブにします。
    

    • 






9.8.3.1 クラスタの起動と停止


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


高可用性環境では、WebLogicノード・マネージャはWebLogic Serverを監視するように構成されます。障害発生時には、ノード・マネージャによってWebLogic Serverが再起動されます。


高可用性環境では、状態情報と構成情報は、クラスタ内のすべてのメンバーが共有するデータベースに格納されます。










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


高可用性構成でのOracle Privileged Account Managerのノード障害には、次の特性があります。


    

  • 

    ノード障害はクライアントに影響しません。
    

    • 

  • 

    サーバーに障害が発生した場合、実行中のRESTベースの操作は停止しますが、フェイルオーバーされません。クライアントは使用可能なサーバーに接続して、リクエストをリトライまたは継続できます。デプロイメントにロード・バランスが含まれている場合は、リクエストは使用可能なサーバーに送信されます。
    

    • 









9.8.5 Oracle Privileged Account Managerの高可用性の構成


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






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


新しいWebLogicドメインにOracle Identity NavigatorとともにOracle Privileged Account Managerを構成し、その後Oracle Identity Navigatorの検出機能を実行する場合、この項の構成を実行してください。この機能は、Oracle Identity Manager、Oracle Access Management、Oracle Adaptive Access ManagerおよびOracle Privileged Account Managerの製品コンソールへのリンクを移入します。これにより、個々の製品コンソールURLを覚えていなくても、Oracle Identity Navigatorインタフェースからこれらの製品コンソールにアクセスできます。








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


この項の構成を実行することで、Oracle Privileged Account ManagerおよびOracle Identity Navigatorアプリケーションが新しいWebLogic管理サーバーにデプロイされます。








9.8.5.3 依存性


この項の構成は、次のものに依存しています。


    

  • 

    Oracle WebLogic Server
    

    • 

  • 

    Oracle Identity and Access Management 11gソフトウェアのインストール
    

    • 



詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Management (11.1.2.0.0)のインストールと構成に関する説明を参照してください。








9.8.5.4 高可用性の構成手順


この項の手順は次のとおりです。






9.8.5.4.1 OPAMHOST1でのOracle Identity Managementの構成


Oracle Privileged Account ManagerおよびOracle Identity Navigatorの高可用性を最大化するように構成するには、次の手順を実行します。


    

  1. 

    Oracle WebLogic Serverをインストールし、Middlewareホームを作成します。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のWebLogic ServerおよびMiddlewareホームの要件に関する説明を参照してください。
    

    2. 

  2. 

    Oracle Identity and Access Management 11gソフトウェアをインストールします。詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Identity and Access Management (11.1.2.0.0)のインストールに関する説明を参照してください。
    

    3. 

  3. 

    <IAM_Home>/common/bin/config.shスクリプトを実行します(Windowsでは<IAM_Home>\common\bin\config.cmd)。Oracle Fusion Middleware構成ウィザードの「ようこそ」画面が表示されます。
    

    


    

    


    


    注意:
    

    ここでは例として、IAM_Homeが使用されます。このスクリプトは、Oracle Identity Manager、Access Manager、Oracle Adaptive Access Manager、Oracle Entitlements Server、Oracle Privileged Account Manager、Mobile and SocialおよびOracle Identity Navigatorが含まれているOracle Identity and Access Managementホーム・ディレクトリから実行する必要があります。
    
    		

    
    

    

    

    

    4. 

  4. 

    「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。「ドメイン・ソースの選択」画面が表示されます。
    

    5. 

  5. 

    「ドメイン・ソースの選択」画面で、「次の製品をサポートするために、自動的に構成されたドメインを生成する」オプションが選択されていることを確認します。「Oracle Privileged Account Manager - 11.1.2.0.0 [IAM_Home]」を選択します。
    

    


    

    


    


    注意:
    

    「Oracle Privileged Account Manager - 11.1.2.0.0 [IAM_Home]」オプションを選択すると、「Oracle Identity Navigator」、「Oracle JRF」および「Oracle Platform Security Services」オプションもデフォルトで選択されます。
    
    		

    
    

    

    

    

    「次へ」をクリックします。「ドメイン名と場所の指定」画面が表示されます。
    

    6. 

  6. 

    ドメイン名IDM_Domainを入力します。「ドメインの場所」および「アプリケーション・ディレクトリ」は、デフォルトのままにします。「次へ」をクリックします。「管理者ユーザー名およびパスワードの構成」画面が表示されます。
    

    7. 

  7. 

    管理者のユーザー名とパスワードを構成します。デフォルトのユーザー名はweblogicです。「次へ」をクリックします。
    

    8. 

  8. 

    Oracle Fusion Middleware構成ウィザードの「サーバーの起動モードおよびJDKの構成」画面で、JRockit SDK 1.6.0_<version>と「本番モード」を選択します。
    

    9. 

  9. 

    「JDBCコンポーネント・スキーマの構成」画面で、OPAMスキーマおよびOPSSスキーマのデータベース・スキーマの詳細を入力します。
    

    (オプション)コンポーネント・スキーマのRAC構成に関するオプションを選択します。
    

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

    10. 

  10. 

    「コンポーネント・スキーマのテスト」画面で、構成ウィザードによりデータ・ソースの検証が試行されます。すべてのスキーマに対するテストが正常に完了したことを確認します。
    

    データ・ソースの検証が成功した場合、「次へ」をクリックします。
    

    データ・ソースの検証に失敗した場合は、「前へ」をクリックして問題を修正し、もう一度実行します。
    

    11. 

  11. 

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

      

    • 

      管理サーバー
      

      • 

    • 

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

      • 

    • 

      デプロイメントとサービス
      

      • 

    

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

    12. 

  12. 

    「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
    

    13. 

  13. 

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

      

    • 

      名前: AdminServer
      

      • 

    • 

      Listen address: OPAMHOST1.mycompany.com
      

      • 

    • 

      リスニング・ポート: 7001
      

      次のパラメータは設定または変更しないでください。
      

      • 

    • 

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

      • 

    • 

      SSL有効または無効
      

      • 

    

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

    14. 

  14. 

    「管理対象サーバーの構成」画面で、トポロジのOPAMHOSTごとにエントリを作成しますが、つまり、OPAMHOST1上で実行されている OPAMサーバーに対して1つと、OPAMHOST2上で実行されているOPAMサーバーに対して1つ作成します。
    

    OPAM_SERVERエントリを選択し、そのエントリを次の値に変更します。
    

      

    • 

      名前: opamserver1
      

      • 

    • 

      リスニング・アドレス: OPAMHOST1.mycompany.com
      

      • 

    • 

      リスニング・ポート: 18101
      

      • 

    • 

      SSLポート: 18102
      

      • 

    

    2つ目のOPAM_SERVERでは、「追加」をクリックして、次の値を入力します。
    

      

    • 

      名前: opam_server2
      

      • 

    • 

      リスニング・アドレス: OPAMHOST2.mycompany.com
      

      • 

    • 

      リスニング・ポート: 18101
      

      • 

    • 

      SSLポート: 18102
      

      • 

    

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

    15. 

  15. 

    「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。
    

    OPAM_Clusterなどのクラスタの名前を入力します。その他すべてのフィールドはデフォルト設定のままにします。
    

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

    16. 

  16. 

    「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。
    

    右のウィンドウで、クラスタ名「OPAM_Cluster」をクリックします。
    

    管理対象サーバー「opam_server1」をクリックしてから、矢印をクリックして、その管理対象サーバーをクラスタに割り当てます。
    

    管理サーバーopam_server2について、前述の手順を繰り返します。
    

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

    17. 

  17. 

    「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。
    

    ホストでUnixオペレーティング・システムを使用する場合は、「Unix」タブを、それ以外の場合は、「マシン」をクリックします。
    

    次の情報を指定します。
    

      

    • 

      名前: ホスト名です。ここでは、DNS名を使用することをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: ここにマシンのDNS名を入力します。
      

      • 

    • 

      ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。
      

      • 

    

    OPAMHOST2について前述の手順を繰り返し、次の値を入力します。
    

      

    • 

      名前: ホスト名です。DNS名OPAMHOST2を使用することをお薦めします。
      

      • 

    • 

      ノード・マネージャ・リスニング・アドレス: マシンのDNS名OPAMHOST.mycompany.comを入力します。
      

      • 

    • 

      ノード・マネージャ・ポート: ノード・マネージャが使用するポートを入力します。
      

      • 

    

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

    18. 

  18. 

    「サーバーのマシンへの割当」画面で、作成したマシン上で実行する管理対象サーバーを割り当てます。次の手順を実行します。
    

    右側のウィンドウでマシンをクリックします。
    

    左側のウィンドウで、そのマシン上で実行する管理対象サーバーをクリックします。
    

    矢印をクリックし、その管理対象サーバーをそのマシンに割り当てます。
    

    すべての管理対象サーバーが適切なマシンに割り当てられるまで、この手順を繰り返します。
    

    例:
    

      

    • 

      ホスト1: 管理サーバー、OPAMHOST1およびopam_server1
      

      • 

    • 

      ホスト2: OPAMHOST2およびopam_server2
      

      • 

    

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

    19. 

  19. 

    「構成のサマリー」画面で、「作成」をクリックします。
    

    20. 






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


ドメインの構成後、管理サーバーを起動する前に、データベース・セキュリティ・ストアを構成する必要があります。詳細は、第9.1.3.3項「ドメイン用のデータベース・セキュリティ・ストアの構成」を参照してください。








9.8.5.4.3 OPAMHOST1での管理サーバーの起動


管理サーバーを起動するには、次の手順を実行します。


    

  1. 

    DOMAIN_HOME/binディレクトリに移動します。startWeblogic.shを実行します。
    

    2. 

  2. 

    プロンプトで、WebLogic管理者のユーザー名とパスワードを入力します。
    

    


    

    


    


    注意:
    

    次の手順は、管理サーバーを最初に起動したときのみに実行します。
    
    		

    
    

    

    

    

    3. 

  3. 

    管理サーバーが起動したら、ORACLE_HOME/opam/binディレクトリに移動します。opam-config.shを実行します。
    

    


    

    


    


    注意:
    

    このスクリプトを実行する前に、ORACLE_HOME、JAVA_HOMEおよびANT_HOME環境変数が設定されている必要があります。ANT_HOMEでは、<middleware_home>/modules/org.apache.ant_1.7.1などのAntおよびJARバイナリ・ファイルが含まれている場所をポイントしている必要があります。
    
    		

    
    

    

    

    

    4. 

  4. 

    プロンプトで、WebLogicのユーザー名、パスワード、URL、ドメイン名およびMiddlewareホームを入力します。
    

    5. 

  5. 

    opam-config.shまたはopam-config.batが正常に実行されたら、管理サーバーを再起動します。
    

    6. 











9.8.5.4.4 OPAMHOST1の起動


この項では、OPAMHOST1の起動手順について説明します。


    

  1. 

    コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。MW_HOME/oracle_common/common/binディレクトリにあるsetNMProps.shスクリプトを実行します。
    

    MW_HOME/oracle_common/common/bin/setNMProps.sh
    

    2. 

  2. 

    コマンドMW_HOME/wlserver_10.3/server/bin/startNodeManager.shを使用して、ノード・マネージャを起動します。
    

    3. 






9.8.5.4.5 OPAMHOST1でのOracle Privileged Account Managerの起動


OPAMHOST1上のOracle Privileged Account Managerを起動する手順は、次のとおりです。


    

  1. 

    次のURLを使用して、WebLogic管理コンソールにログインします。
    

    http://opamhost1.mycompany.com:7001/console

    2. 

  2. 

    WebLogic管理者のユーザー名とパスワードを入力します。
    

    3. 

  3. 

    「ドメイン構造」メニューで「環境」→「サーバー」を選択します。
    

    4. 

  4. 

    「制御」タブをクリックします。
    

    5. 

  5. 

    サーバー「opam_server1」をクリックします。
    

    6. 

  6. 

    「起動」をクリックします。
    

    7. 

  7. 

    「OK」をクリックします。
    

    8. 











9.8.5.4.6 OPAMHOST2でのOPAMの構成


OPAMHOST1で構成を完了したら、それをOPAMHOST2に伝播できます。これを実行するには、OPAMHOST1でpackスクリプトを使用してドメインをパックし、OPAMHOST2でunpackスクリプトを使用してドメインを解凍します。


どちらのスクリプトも、MW_HOME/oracle_common/common/binディレクトリにあります。


    

  1. 

    MW_HOMEおよびORACLE_HOMEディレクトリ構造がOPAMHOST1ディレクトリ構造と同じであることを確認します。
    

    2. 

  2. 

    OPAMHOST1で次のように入力して、/tmpディレクトリにファイルidm_domain.jarを作成します。
    

    pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain

    

     -template=/tmp/idm_domain.jar -template_name="OPAM Domain" -managed=true

    

    3. 

  3. 

    idm_domain.jarをOPAMHOST2にコピーするには、次のように入力します。
    

    unpack.sh -domain=MW_HOME/user_projects/domains/IDM_Domain 
-template=/tmp/idm_domain.jar

Copy jps-wls-trustprovider.jar from MW_HOME/oracle_common/modules/oracle.jps_11.1.1 to WLS_SERVER_HOME/server/lib/mbeantypes

    4. 









9.8.5.4.7 OPAMHOST2の起動


この項では、OPAMHOST2の起動手順について説明します。


    

  1. 

    コンソールから管理対象サーバーを起動する前に、ノード・マネージャのプロパティ・ファイルを作成しておく必要があります。ディレクトリMW_HOME/oracle_common/common/binにあるスクリプトsetNMProps.shを実行します。
    

    2. 

  2. 

    コマンドMW_HOME/wlserver_10.3/server/bin/startNodeManager.shを使用して、ノード・マネージャを起動します。
    

    3. 

  3. 

    OPAMHOST2でOracle Privileged Account Managerを起動します。第9.8.5.4.5項「OPAMHOST1でのOracle Privileged Account Managerの起動」を参照して、HOST1とserver1をHOST2とserver2に置き換えます。
    

    4. 











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


Oracle HTTP Server (OHS)を使用してOPAMサーバーをロード・バランシングできます。OPAMサーバーでは通信にSSLを使用するため、OHSロード・バランサでSSLオプションを構成する必要があります。次の手順を実行します。


    

  1. 

    OPAMの管理対象サーバーおよび管理サーバーと通信できるように、OHSからのアウトバウンドSSL接続を有効化します。これを行うには、『Oracle Fusion Middleware管理者ガイド』のOracle HTTP Serverからのアウトバウンド・リクエストでのSSLの有効化に関する説明を参照してください。
    

    2. 

  2. 

    OPAMの管理対象サーバーおよび管理サーバーへのSSL接続を有効化します。『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic ServerへのインバンドSSLに関する説明を参照してください。
    

    3. 













9.9 Oracle Identity Navigatorの高可用性


Oracle Identity Management Navigatorは、Oracle Identity Management製品のスタート地点として機能するよう設計されている管理ポータルです。これは、個々の製品コンソールに代わるものではありません。1つのサイトからOracle Identity Managementの各コンソールにアクセスできるようにするためのものです。Oracle Identity Management Navigatorの詳細は、Oracle Fusion Middleware Oracle Identity Navigator管理者ガイドを参照してください。


Oracle Identity Navigatorは、WebLogic管理サーバーJVMにデプロイされるため、高可用性アクティブ/アクティブ・デプロイメントでは使用されません。


高可用性アクティブ/パッシブ・コールド・フェイルオーバー・クラスタでOracle Identity Navigatorを使用するには、第12.2.3.5項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」のアクティブ/パッシブ・コールド・フェイルオーバー・クラスタでのWebLogic Serverの設定手順に従います。








9.10Oracle Unified Directoryの高可用性


Oracle Unified Directoryは、大規模なデプロイメントへの対応、優れたパフォーマンスの提供および高い拡張性を実現するために設計された、Oracleの包括的な次世代ディレクトリ・サービスです。Oracle Unified Directoryは、簡単にデプロイ、管理および監視できるような設計にもなっています。Oracle Unified Directoryの詳細は、Oracle Fusion Middleware Oracle Unified Directory管理者ガイドを参照してください。


Oracle Unified Directoryの高可用性デプロイメントの詳細は、Oracle Fusion Middleware Oracle Unified Directory管理者ガイドのOracle Unified Directoryの高可用性デプロイメントの理解に関する項を参照してください。









脚注の説明文

脚注 1: 使用されるエージェントはデプロイメント固有であり、デプロイメントによって(異なる機能を持つ)様々なタイプのエージェントを使用できます。
 脚注 2: Access Managerは、組込み資格証明コレクタだけでなく、外部資格証明コレクタもサポートできます。
 脚注 3: 資格証明収集は、非ユーザー名およびパスワード認証スキームでは異なります。
 脚注 4: WebGateのみが、バック・チャネル通信をサポートします。
 脚注 5: エージェントは、Webリソースへのリクエストの転送を許可する前に、セッション・リフレッシュなどのいくつかのハウスキーピング・タスクを実行することがあります。






















 
前
 前 		
次
 次		











 
目次へ移動
 目次