| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.1) B71694-06 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11g リリース2 (11.1.2.1) B71694-06 |
|
前 |
次 |
この章では、このガイドで使用するエンタープライズ・デプロイメント参照用トポロジについて説明します。
エンタープライズ・デプロイメントを成功させるには、計画および準備が重要です。この章の最後にあるインストールと構成のロード・マップでは、実行する必要のあるタスクが記載されている章へと導きます。この章は、このガイドで使用する例を独自のデプロイメントにマップする際に役立ちます。
付録B「Identity Managementのトポロジに関するワークシート」を使用して、情報を追跡できます。
この章には、次の項目が含まれます。
Identity Managementのエンタープライズ・デプロイメントは、次の部分から構成されます。
ポリシー情報およびデプロイするアイデンティティ管理コンポーネント固有の情報を格納するための高可用性データベース。
アイデンティティ情報の作成および管理をサポートし、データベースおよびアイデンティティ・ストア内に格納されたポリシーおよびアイデンティティに基づいてリソースへのアクセスを制限するように高可用性の方法でインストールされたIdentity Managementコンポーネント。Identity Managementコンポーネントは、次の3つのカテゴリに分類できます。
Directory Services: アイデンティティ情報を格納するための1つ以上の高可用性ディレクトリ
Identity Managementプロビジョニング: Oracle Identity Manager
アクセス制御: Oracle Access Management
アイデンティティ管理コンポーネントへのアクセスに使用される高可用性Web層。これらのコンポーネントへのアクセスを制限し、企業のリソースにアクセスしようとする人やプロセスのアイデンティティを確認するために使用されます。
Webサーバー間に負荷を分散するために使用する高可用性ロード・バランサ。ロード・バランサは、SSL暗号化をオフロードしてユーザー・セッションとOracle Identity Managementの間の通信を暗号化するためにも使用できますが、個別のアイデンティティ管理コンポーネント間のSSLを有効にするためのオーバーヘッドの必要はありません。
これらのコンポーネント・パーツを同時に配置する方法は多数あります。3つのトポロジは、次の項で説明します。このガイドでは、これらのデプロイ方法を詳細に説明します。Oracleがサポートしているのはこれらのトポロジのみではありませんが、これらは最も一般的なものと考えられます。
|
注意: このガイドでは、Oracle Internet DirectoryインスタンスまたはOracle Internet Directoryドメインの作成方法は説明しません。 |
この項には次のトピックが含まれます:
トポロジは、コンポーネントのデプロイメント・マップです。Oracle Identity Managementコンポーネントをインストールして、動作するIdentity and Access Managementのソリューションを提供する方法は複数あります。トポロジは、アーキテクチャの青写真としても記述できます。このガイドでは、Oracle Identity and Access Managementの最も一般的なデプロイメント・トポロジを示します。
Oracle Identity and Access Managementをエンタープライズ・デプロイメントにデプロイする方法は多数あります。2つの最も一般的なデプロイメント・モデルは、すべてを単一のドメインに配置する方法と、運用コンポーネントと管理コンポーネントを別のドメインに分離する方法です。次の3つの図は、これら2つの異なるデプロイメント・モデルを示しています。
この項には次のトピックが含まれます:
この図は、エンタープライズ・トポロジのグラフィカル表示です。これには、ハードウェア・ロード・バランサ、ホスト・コンピュータ、ファイアウォールおよびトポロジのその他の要素を表すアイコンおよび記号が含まれています。高レベルでは、次のものを含むトポロジの主コンポーネントを示します。
Web層: 2つのサーバーがあり、それぞれがOracle HTTP ServerとOracle Webゲートをホストしています。
アプリケーション層: 2つのサーバー(IDMHOST1とIDMHOST2)があります。それぞれが、次の製品の管理対象サーバーを含んでいます。
Oracle Access Management。これは、Access Server、Federationおよび対応するJRF/OPSSプロセスをホストしています。
Oracle Identity Manager。これは、OIM Serverおよび対応するJRF/OPSSプロセスをホストしています。
SOA。これは、SOA Serverおよび対応するJRF/OPSSプロセスをホストしています。
Oracle Unified Directory。各ホストには、アイデンティティ情報用のLDAPディレクトリとして使用されるOracle Unified Directoryのインスタンスがあります。それぞれのOracle Unified Directoryインスタンスは、Oracle Unified Directoryのレプリケーションによって最新に保たれます。
IDMHOST1には、WebLogicコンソール、Enterprise Manager Fusion Middleware Control、OAMコンソール、APMコンソールおよびODSM (Oracle Unified Directory用)をホストするWebLogic管理サーバーも含まれています。IDMHOST1に障害が発生した場合、WebLogic管理サーバーはIDMHOST2上で起動できます。
データ層: これはデータベースがある場所です。データベースには、アプリケーション層の製品が必要とする顧客データおよびスキーマが含まれています。
ロード・バランサ: ロード・バランサは非武装地帯(DMZ)にあり、SSO.mycompany.com、ADMIN.mycompany.comおよびIDMINTERNAL.mycompany.comで受信したリクエストをOracle HTTPサーバーに転送します。SSO.mycompany.comの場合、リクエストはSSL暗号化されます。これはロード・バランサで終了します。ADMIN.mycompany.comおよびIDMINTERNAL.mycompany.comは、HTTPプロトコルを使用してリクエストを処理します。
また、ロード・バランサは、ロード・バランサの仮想ホストであるIDSTORE.mycompany.comを使用して、LDAPリクエストをIDMHOST1とIDMHOST2のOracle Unified Directoryインスタンス間に分散します。
ファイアウォール: これらは、Web層、アプリケーション層およびディレクトリ層を異なるゾーンに分離するために使用します。WEBHOST1とWEBHOST2はDMZに配置されています。
詳細は、図に続く各項のトポロジ層の説明を参照してください。このガイドの手順では、このトポロジ用にソフトウェアをインストールして構成する方法を説明します。
この図は図2-1と似ています。異なる点は、Oracle Access ManagementのWebLogic管理対象サーバーがIDMDomainというドメインに配置されていて、Oracle Identity Managerの管理対象サーバーおよびSOAコンポーネントがOIMDomainというドメインに配置されていることです。
また、2つ目の管理サーバーがIDMHOST1上に構成されていて、2つ目のドメインであるOIMDomainをサポートしています。
このトポロジ用にソフトウェアをインストールして構成する方法は、第16章「分割ドメイン・トポロジの作成」で説明します。
詳細は、図に続く各項のトポロジ層の説明を参照してください。
この図は図2-2と似ています。異なる点は、Oracle Unified DirectoryがOracle Internet Directoryに置き換えられていることです。Oracle Internet Directoryコンポーネントは、ディレクトリ層という名前に変更されたデータベース層に移動します。
ディレクトリ層には、2つの新規ホストOIDHOST1とOIDHOST2があります。これらのホストには、Oracle Internet Directoryインスタンスが含まれています。また、OIDDomainという別のドメインもあり、これにはWebLogic管理サーバーおよび2つのWebLogic管理対象サーバーがあり、それぞれがODSMをホストしています。
ディレクトリ層には追加のデータベースも含まれていて、これにはOracle Internet Directoryスキーマが含まれています。
詳細は、図に続く各項のトポロジ層の説明を参照してください。
シングル・ドメイン・トポロジと分割ドメイン・トポロジには、それぞれ長所と短所があります。
この項には次のトピックが含まれます:
シングル・ドメイン・トポロジの長所は次のとおりです。
大部分の実装に適しています。
各コンポーネントが単一のWebLogicドメイン内に含まれていて、設定、管理およびパッチ適用が簡単です。
分割ドメイン・モデルよりも設定が簡単です。
同じトポロジは、本番システムと本番ではないシステムに適しています。
これは、Fusion ApplicationsのIdentity Managementが使用するデプロイメント・モデルと同じです。
異なるドメインに異なるIAMコンポーネントを持つことによる複雑さがありません。
Enterprise Manager Fusion Middleware Controlは、すべてのアイデンティティ管理コンポーネントを統合した単一のビューを表示します。
シングル・デプロイメント・モデルの短所は次のとおりです。
アイデンティティ・プロビジョニングとアクセス制御が同じデプロイメントによって提供されます。
パッチを適用する必要があり、そのパッチを適用するにはドメイン全体を停止する必要がある場合、プロビジョニングとアクセス制御の両方のサービスが中断されます。
ドメイン・レベルの更新を含むパッチ・セットによって互換性の問題が引き起こされる場合があります。これは、Identity and Access Managementのみがインストールされているドメイン(つまり、Oracle Internet Directory、Oracle Virtual DirectoryまたはOracle Identity Federationがないドメイン)ではほとんど発生しません。
分割ドメイン・トポロジは、デプロイメントの各コンポーネントに対して限定的な制御を必要とする大きい組織に適しています。
分割ドメイン・トポロジの主な長所は、パッチ適用の柔軟性に関係しています。具体的には次のとおりです。
各コンポーネント(Oracle Identity ManagerおよびAccess Manager)が異なるドメインに配置されているため、目的のコンポーネントのみを更新するようにパッチを適用できます(ドメイン・レベルのものであっても同様)。
Oracle Identity Managerなどの管理コンポーネントを制御して停止する必要なくパッチ適用できます。この制御停止は、Access Managerなどの運用コンポーネントの更新では必要です。
分割デプロイメント・トポロジの短所は次のとおりです。
設定がより複雑です。
ドメイン間で動作するようにコンポーネントを構成する必要があります。
複数のソフトウェア・デプロイメントが必要なため、Middlewareホームが増えます。
汎用パッチを各ドメインにデプロイする必要があります。
ドメインの管理がより複雑です。具体的には次のとおりです。
2つの管理コンソール
Fusion Middleware Controlの2つのインスタンス
すべてのアイデンティティ管理コンポーネントの単一ビューなし
このトポロジは、本質的には分割ドメイン・トポロジと同じですが、Oracle Unified DirectoryのかわりにOracle Internet Directoryを使用します。他のコンポーネントに依存せずにOracle Internet Directoryのパッチ適用を容易にするために、Oracle Internet Directoryは個別のドメインを使用して構成されます。
このガイドでは、高可用性Oracle Internet Directoryがすでにデプロイされていることを想定していますが、その設定については説明しません。高可用性Oracle Internet Directoryの設定の詳細は、『Oracle Fusion Middleware高可用性ガイド』のOracle Internet Directoryの高可用性に関する項を参照してください。
パッチ適用の完全な制御(つまり、各アイデンティティ管理コンポーネントを個別にパッチ適用する機能)を特別に必要としないのであれば、シングル・ドメイン・トポロジの使用をお薦めします。
各トポロジは、セキュリティおよび保護を向上するために複数の層に分割されます。層は、ある層から次の層へのアクセスを制御するファイアウォールによって分離されます。その目的は、未承認のトラフィックを防止することです。たとえば、インターネットに面しているトポロジでは、インターネット領域からデータベースに直接アクセスできないことが必要です。アプリケーション領域にデプロイされているアプリケーションのみがデータベースにアクセスできる必要があります。
前述の図それぞれが次の3つの層を示しています。
Web層
アプリケーション層
データベース層
図には表示されていませんが、ディレクトリ層(データベース層に含まれることが多い)も存在できます。専用のディレクトリ層が導入される場合、LDAPディレクトリをこの層内に配置できます。これは、データベースに密接に関連しているOracle Internet Directoryを使用したデプロイメントで行われることが最も多いです。
この項には次のトピックが含まれます:
Web層はDMZパブリック・ゾーンにあります。HTTPサーバーはWeb層にデプロイされます。
大半のアイデンティティ管理コンポーネントはWeb層なしで動作できますが、大半のエンタープライズ・デプロイメントではWeb層が望ましいです。Oracle Single Sign-OnやAccess Managerなどの製品を使用して全社レベルのシングル・サインオンをサポートするには、Web層が必要です。
Oracle Enterprise Manager Fusion Middleware ControlやOracle Directory Services ManagerなどのコンポーネントはWeb層なしで動作できますが、必要に応じてWeb層を使用するように構成できます。
Web層:
WEBHOST1とWEBHOST2には、Oracle HTTP Server、Webゲート(Access Managerコンポーネント)およびmod_wl_ohsプラグイン・モジュールがインストールされています。mod_wl_ohsプラグイン・モジュールにより、アプリケーション層で実行されているWebLogic ServerにOracle HTTP Serverからリクエストをプロキシすることができます。
Oracle HTTP ServerのWebゲート(Oracle Access Managementコンポーネント)は、Oracle Accessプロトコル(OAP)を使用して、アイデンティティ管理DMZ内のIDMHOST1とIDMHOST2で実行されているAccess Managerと通信します。WebゲートとAccess Managerは、ユーザー認証などの操作の実行に使用されます。
Web層を保護するファイアウォール上では、HTTPポートは、HTTPS用の443(HTTP_SSL_PORT)とHTTP用の80(HTTP_PORT)です。ポート443は開いています。
WEBHOST1とWEBHOST2上のOracle HTTP Serverはmod_wl_ohsを使用して構成されており、IDMHOST1とIDMHOST2上にあるWebLogic ServerにデプロイされたOracle Enterprise Manager、Oracle Directory Integration PlatformおよびOracle Directory Services Manager Java EEアプリケーションのリクエストをプロキシします。
Oracle HTTPサーバーがWEBHOST上で障害が発生した場合、Oracle Process Management and Notification (OPMN)サーバーはこれを再起動しようとします。
アプリケーション層は、Java EEアプリケーションが配置される層です。Oracle Identity Manager、Oracle Directory Integration Platform、Oracle Directory Services Manager、Oracle Enterprise Manager Fusion Middleware Controlなどの製品が、この層にデプロイできる主要なJava EEコンポーネントです。この層にあるアプリケーションは、Oracle WebLogic Serverの高可用性サポートにおけるメリットを享受します。
アプリケーション層にあるアイデンティティ管理アプリケーションは、次に示すようにディレクトリ層と対話的に処理を行います。
エンタープライズ・アイデンティティ情報についてはディレクトリ層が活用されます。
場合によっては、アプリケーション・メタデータではディレクトリ層(およびデータ層のデータベースの場合もある)が活用されます。
Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Directory Services Managerは、アプリケーション層だけでなくディレクトリ層にもあるコンポーネントに対して管理機能を提供する管理ツールです。
WebLogic Serverには、Webサーバーのサポートが組み込まれています。有効にされていると、HTTPリスナーはアプリケーション層にも配置されます。ただし、図1-1に示したエンタープライズ・デプロイメントでは、お客様はApacheやOracle HTTP ServerなどのWebサーバーに依存する別のWeb層を使用しています。
アプリケーション層では、IDMHOST1とIDMHOST2には次のコンポーネントが含まれています。
インフラストラクチャの運用コンポーネント。このコンポーネントは、Oracle Access Management Access Manager (OAM)です。これは、Oracle WebLogic Server内で実行されるJ2EEアプリケーションです。
Oracle Identity ManagerおよびOracle Entitlements Server Policy Manager。これらはユーザー・プロビジョニングおよびポリシー管理に使用されます。
Oracle Identity Managerなどのアイデンティティ管理の管理コンポーネント。これはユーザー・プロビジョニングに使用されます。注意: これらのサーバーは、Oracle Identity Managerによって排他的に使用されるOracle SOAも実行します。
Oracle Identity Manager (OIM)はディレクトリ層と通信します。
さらに、次の場合もあります。
IDMHOST1はOracle WebLogic管理サーバーをホストします。管理サーバーの内部には、Oracle WebLogicコンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Access Managementコンソール、Oracle Unified Directory用のOracle Directory Services Manager (ODSM)など、ドメインの管理およびナビゲーション用のコンポーネントがあります。WebLogic管理サーバーは、シングルトン・プロセスです。つまり、一度に1つのサーバーでのみ起動できます。管理サーバーを実行しているホストで障害が発生した場合、管理サーバーを別のホストで手動で起動できます。
ドメインは、WebLogic Serverインスタンスの基本的な管理単位です。ドメインは、単一の管理サーバーを使用して管理する1つ以上のWebLogic Serverインスタンス(およびその関連リソース)から構成されています。様々なシステム管理者の責任、アプリケーション境界、またはサーバーの地理的な場所に基づいて複数のドメインを定義できます。一方で、1つのドメインを使用して、すべてのWebLogic Server管理アクティビティを集中管理できます。
アイデンティティ管理のコンテキストでは、SOA、Web Center Portalなどの顧客アプリケーションがデプロイされる可能性があるドメインとは別個のWebLogic Serverドメインに、アイデンティティ管理コンポーネントとSOAをデプロイすることをお薦めします。標準のエンタープライズ・デプロイメントでは、アイデンティティ管理コンポーネント(LDAPディレクトリ、シングル・サインオン・ソリューション、プロビジョニング・ソリューションなど)の管理は、ミドルウェア・インフラストラクチャおよびアプリケーションを管理する管理者とは異なる管理者が行います。Oracle Identity Managerは、他の製品に依存せずにパッチ適用できるように個別の専用ドメインにデプロイできます。
開発環境またはテスト環境において単一のドメインにすべてを配置することは技術的には可能です。ただし、本番環境では、別々のドメインを使用するという推奨事項により、アイデンティティ管理スタックと残りのミドルウェアおよびアプリケーションのデプロイメントの間に論理的管理境界が作成されます。
アイデンティティ情報は、LDAP対応ディレクトリに格納されます。本来、次のディレクトリがサポートされています。
Oracle Unified Directory
Oracle Internet Directory
Microsoft Active Directoryなどの別のディレクトリを使用する場合、Oracle Virtual Directoryを使用してその情報を提供するか、Oracle Directory Integration Platformを使用して、他のディレクトリのユーザーとグループを同期させることができます。
標準的なLDAPポートは、非SSLポートでは389 (LDAP_LBR_PORT)になり、SSLポートでは636 (LDAP_LBR_SSL_PORT)になります。イントラネットの電子メール・クライアントなどのクライアントによりホワイト・ページが検索される際に、LDAPサービスが使用されることがあります。ロード・バランサ上のポート389と636は、通常、個々のディレクトリ・インスタンスによって使用される権限のないポートにリダイレクトされます。LDAPリクエストは、ハードウェア・ロード・バランサを使用して、Oracle Unified Directory、Oracle Internet DirectoryまたはOracle Virtual Directoryの各ホストに分散されます。
アイデンティティ情報が複数のバックエンド・ディレクトリに分割されている複雑なディレクトリ実装では、Oracle Virtual Directoryを使用して、この実装をOracle Identity Managementとともに使用できます。
多くの組織には、既存のディレクトリ・デプロイメントがあります。既存のデプロイメントがない場合、このガイドを使用して、このロールを引き受けるようにOracle Unified Directoryを構成する方法を学習できます。既存のディレクトリがある場合、このガイドを使用して、そのディレクトリを構成してOracle Identity Managementで使用する方法を学習できます。ディレクトリがなく、Oracle Unified Directory以外のディレクトリを使用する場合、これらのディレクトリを高可用性の方法で構成する方法の詳細は、ディレクトリのドキュメントを参照してください。
アイデンティティ情報をOracle Unified Directoryに格納すると、この情報は、Berkeleyデータベースにローカルで格納されます。高可用性を確保するために、Oracle Unified Directoryレプリケーションを使用して、この情報が別のOracle Unified Directoryインスタンスにレプリケーションされます。
Oracle Unified Directoryサーバー・インスタンスは、本来、レプリケーションを使用して、埋込みデータベースの同期状態を保持します。デフォルトでは、レプリケーションは、操作結果がアプリケーションに戻った後に更新をレプリカにレプリケーションするゆるやかな一貫性モデルを使用します。したがってこのモデルでは、データをレプリカに書き込んでから、書込みの少し後に古い情報を別のレプリカから読み取ってしまう可能性があります。レプリケーション・プロセスが高速で1ミリ秒の桁で達成できるように、Oracle Unified Directoryレプリケーションで多くの作業が行われました。
レプリカ内のデータの一貫性を保証するように開発された保証レプリケーション・モデルを使用するようにOracle Unified Directoryを構成できます。保証レプリケーションの安全読取りモードを使用すると、アプリケーションは、レプリケーション・プロセスが書込み操作の結果を返す前に完了することを保証します。
保証レプリケーションを使用すると、書込み操作の応答時間に悪影響があります。これは、保証レプリケーションではリモート・レプリカとの通信の後に操作結果を返す必要があるためです。遅延時間は、使用するネットワークおよびOracle Unified Directoryをホストしているサーバーの容量によって異なります。保証レプリケーションを使用しても、読取り操作への影響はほとんどありません。
ディレクトリへの大量の書込みを定期的に実行することが予想される場合、ロード・バランサを構成して、アクティブ/パッシブ・モードでOracle Unified Directoryインスタンスにリクエストを分散することを検討してください。こうすることによって、レプリカから古いデータ読み取る機会がなくなりますが、使用しているOracle Unified Directoryホストがすべてのリクエストを処理する能力がない場合、全体のパフォーマンスが低下する可能性があります。
このガイドの目的のために、複数のサーバーにリクエストを処理させる機能の方が保証モードでのリクエストの書込みによって生じる追加のオーバーヘッドより重要であると想定されます。この目的のために、このガイドでは、保証レプリケーションを使用したOracle Unified Directoryの構成を示します。ただし、次のOracle Unified Directoryの構成は両方ともサポートされます。
保証構成のアクティブ/アクティブ
非保証構成のアクティブ/パッシブ
詳細は、Oracle Fusion Middleware Oracle Unified Directory管理者ガイドの保証レプリケーションに関する項を参照してください。
Oracle Unified Directoryは、通常、内部変更番号を使用して変更を追跡します。変更番号は、各Oracle Unified Directoryインスタンス固有で、あるOracle Unified Directoryインスタンスで障害が発生し、レプリケーションされるエントリがない場合に問題となる可能性があります。このような障害は、Oracle Identity Managerのリコンシリエーションに影響する可能性があります。
パッチ16943171によって、Oracle Identity Managerは、新しく信頼性の高いOracle Unified Directoryメカニズムを使用して変更を追跡できます。これはCookieを使用します。このメカニズムを使用すると、Oracle Unified Directoryのフェイルオーバー時に問題が発生しなくなります。パッチ16943171をインストールした後、Oracle Identity Managerは、リコンシリエーション・ジョブを自動的に作成するときにCookieモードを使用します。カスタム・リコンシリエーション・ジョブを作成することを決定する場合、Oracle Unified DirectoryのCookieモードを強制的に使用するする必要があります。
Oracle Internet Directoryをアイデンティティ・ストアとして使用している場合、これを構成してマルチマスター・レプリケーションを使用できます(『Oracle Fusion Middleware高可用性ガイド』の「最大の高可用性を実現するためのアイデンティティ管理の構成」に記載)。これによって、複数のディレクトリ・サーバーで同じネーミング・コンテキストを保持できます。これにより、問合せを処理するサーバーの数が増え、クライアントの近くにデータを持ってくるため、パフォーマンスが向上します。また、シングル・ポイント障害に関連するリスクを排除することで信頼性が向上します。
Oracle Identity Management (Oracle Internet Directoryを含む)は、Oracle Identity and Access Managementとは異なるリリース・サイクルになっています。使用中のアイデンティティ情報がOracle Internet Directoryにある場合、パッチ適用を容易にするために、Oracle Identity Managementコンポーネント(ODSMなど)を分離されたMW_HOMEおよびドメインに配置することをお薦めします。ただし、コンポーネントを同じドメインに配置することもサポートされています。Oracle Directory Services Managerを使用してディレクトリを管理しない場合、ディレクトリ・トポロジで説明されているように分離されたWebLogicドメインは必要ありません。
Oracle Unified DirectoryまたはOracle Internet Directoryを排他的に使用している場合、Oracle Virtual Directoryを使用する必要はありません。
Oracle Internet DirectoryおよびOracle Virtual Directoryは、次の理由からデータベース層に密接に関連付けられています。
Oracle Internet Directoryは、そのバックエンドとしてOracle Databaseに依存しています。
Oracle Virtual Directoryでは、他のLDAPサービスまたはデータベース(あるいはその両方)において仮想化がサポートされています。
通常アクティブ/アクティブであるディレクトリ・デプロイメントの他に、次の機能によってディレクトリの高可用性が提供されます。
Oracle Internet Directoryで障害が発生した場合、Oracle Process Management and Notification (OPMN)サーバーはこれを再起動しようとします。
Oracle Virtual Directoryで障害が発生した場合、Oracle Process Management and Notification (OPMN)サーバーはこれを再起動しようとします。
Oracle Unified Directoryで障害が発生しても、自動的には再起動されません。Oracle Unified Directoryは、ロード・バランサによって正常なインスタンスにリダイレクトするリクエストを待ちます。
Oracle Entitlement Serverの埋込みバージョンは、Oracle Fusion Middlewareコンポーネントへのアクセス制御に使用されます。
Oracle Entitlements Serverは、データベース内に格納されている集中管理されたポリシー・ストアを使用します。
Access Managerは、OPSSポリシー・ストアを使用して、ポリシー情報を格納します。
分割ドメイン構成では、OIMおよびSOAは、他のコンポーネントから分離されたドメインにインストールされます。
Oracle WebLogic Serverコンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Access Managementコンソールは、常に管理サーバーのリスニング・アドレスにバインドされます。
WebLogic管理サーバーはシングルトン・サービスです。一度に1つのノード上でのみ実行されます。障害が発生した場合は、正常なノード上で再起動されます。
管理対象サーバーWLS_OAM1およびWLS_OAM2はクラスタにデプロイされ、Access Managerアプリケーションはそのクラスタにデプロイされます。
管理対象サーバーWLS_OIM1およびWLS_OIM2はクラスタにデプロイされ、Access Managerアプリケーションはそのクラスタにデプロイされます。
管理対象サーバーWLS_SOA1およびWLS_SOA2はクラスタにデプロイされ、Access Managerアプリケーションはそのクラスタにデプロイされます。
OAM Server、Oracle Identity ManagerおよびSOAはアクティブ/アクティブ・デプロイメントです。これらのサーバーは実行時にデータ層と通信します。
WebLogic管理サーバーとOracle Enterprise Managerのデプロイメントは、アクティブ/パッシブです(他のコンポーネントはアクティブ/アクティブ)。ドメインごとに1つの管理サーバーがあります。
WebLogic管理サーバーは、アクティブ/パッシブ構成でデプロイされるシングルトン・コンポーネントです。プライマリに障害が発生したときや、IDMHOST1上の管理サーバーが起動しなかったときに、セカンダリ・ホスト上の管理サーバーを起動できます。WebLogic管理対象サーバーで障害が発生すると、このホストで動作しているノード・マネージャはこのサーバーの再起動を試行します。
このガイドでは、通常アプリケーション層に配置されているOracle Unified Directoryの使用を扱っているため、第2.1.1項「デプロイメント・トポロジ」ではディレクトリ層は示していません。ただし、Oracle Internet DirectoryまたはOracle Virtual Directoryを使用している場合、ディレクトリ層が必要になる場合があります。また、通常ディレクトリ層はファイアウォールで保護されているため、セキュリティを向上するためにOracle Unified Directoryをディレクトリ層に配置できます。ディレクトリ層より上にあるアプリケーションは、指定LDAPホスト・ポートによりLDAPサービスにアクセスします。
通常ディレクトリ層は、エンタープライズLDAPサービスをサポートするディレクトリ管理者が管理します。
11gリリース2 (11.1.2)以降、ポリシー情報はデータベースに格納されます。このデータベースは、デプロイされるアイデンティティ管理コンポーネント固有の情報の格納にも使用されます。
場合によっては、ディレクトリ層とデータ層は同じ管理者グループで管理することもあります。ただし、多くの企業ではデータベース管理者がデータ層を所有し、ディレクトリ管理者がディレクトリ層を所有しています。
ダイアグラムには示されていませんが、ディレクトリをデータベース層に配置してセキュリティを向上する必要がある場合があります。これは、情報を格納するためにデータベースにアクセスする必要があるOracle Internet Directoryを使用するデプロイメントで必要とされる可能性が最も高いです。
トポロジ・ダイアグラムで示したデプロイメントは、少数の強力なサーバーを使用し、デプロイメントを単純にします。ただし、このような強力なサーバーの使用は必須ではありません。かわりに、管理対象サーバーを多数の小さいサーバーに分散できます。
ダイアグラムで示したサーバーと同数のサーバーにデプロイすることを計画している場合、これらのサーバーは表2-1に示した最小仕様を備えている必要があります。
詳細要件またはその他のプラットフォームの要件は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。
表2-1 標準ハードウェア要件
| サーバー | プロセッサ | ディスク | メモリー | TMPディレクトリ | スワップ |
|---|---|---|---|---|---|
|
データベース・ホストIDMDBHOST |
1.5GHz以上で動作するX Pentiumが4個以上 |
nXm n=ディスク数。最小4個(1個のディスクとしてストライプ化) m=ディスクのサイズ(最小30GB) |
6-16GB |
デフォルト |
デフォルト |
|
WEBHOST |
1.5GHz以上で動作するX Pentiumが2個以上 |
10GB |
4GB |
デフォルト |
デフォルト |
|
IDMHOST |
1.5GHz以上で動作するX Pentiumが4個以上 |
20GB |
16GB |
デフォルト |
デフォルト |
これらは標準的なハードウェア要件です。層ごとに、負荷、スループット、応答時間などの要件を慎重に考慮して、実際に必要な容量を計画してください。必要なノード数、CPU、およびメモリーは、デプロイメント・プロファイルに応じて層ごとに異なる可能性があります。本番での要件は、アプリケーションおよびユーザー数によって異なる場合があります。
このガイドで説明するエンタープライズ・デプロイメント構成は、それぞれの層に2つのサーバーを使用して、フェイルオーバー機能を提供します。ただし、アプリケーションまたはユーザーの入力に対して適切な計算リソースとはみなされません。システムのワークロードが増えてパフォーマンスが低下する場合、第17.4項「エンタープライズ・デプロイメントのスケーリング」の説明に従ってWebLogicサーバーまたはディレクトリ/OHSインスタンスを追加できます。
|
注意: オペレーティング・システム・レベル、パッチ・レベル、ユーザー・アカウント、およびユーザー・グループに関して、トポロジ内のノードすべての構成を同一にすることをお薦めします。 |
この項では、Oracle Identity Managementエンタープライズ・デプロイメントで必要なソフトウェアについて説明します。
この項には次のトピックが含まれます:
表2-2「使用するソフトウェアのバージョン」に、このガイドの手順を開始する前に入手しておく必要があるOracleソフトウェアを示します。
表2-2 使用するソフトウェアのバージョン
| 短縮名 | 製品 | バージョン |
|---|---|---|
|
OHS11G |
Oracle HTTP Server |
11.1.1.6.0 |
|
JRockit |
Oracle JRockit |
jrockit-jdk1.6.0_29-R28.2.0-4.0.1以降 |
|
WLS |
Oracle WebLogic Server |
10.3.6.0 |
|
IAM |
Oracle Identity and Access Management |
11.1.2.1.0 |
|
SOA |
Oracle SOA Suite |
11.1.1.6.0 |
|
Webゲート |
WebGate 11g |
11.1.2.1.0 |
|
RCU |
リポジトリ作成アシスタント |
11.1.2.1.0 |
|
OUD |
Oracle Unified Directory |
11.1.2.1.0 |
|
IDM(オプション) |
Oracle Identity Management |
11.1.2.1.0 |
Oracle Fusion Middlewareソフトウェアのダウンロードの詳細は、このリリースのOracle Fusion Middleware 11g リリース1ダウンロード、インストール、構成のReadmeファイル(http://docs.oracle.com/cd/E23104_01/download_readme.htm)を参照してください。
OracleバイナリはOracle Fusion Middlewareホームにインストールされます。個別の製品は、Middlewareホーム内のOracleホームにインストールされます。表2-3は、このドキュメントで使用するMiddlewareホームとOracleホームのまとめです。
Oracle Identity Managementのインストールと構成は、このガイドでは説明しません。詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。
表2-3 ホームの概要
| ホーム名 | ホームの説明 | インストールする製品 |
|---|---|---|
|
|
Oracle WebLogic Serverホーム、およびオプションで1つ以上のOracleホームから構成されています。 |
|
|
|
これは、Oracle WebLogic Serverがインストールされるルート・ディレクトリです。 |
Oracle WebLogic Server |
|
|
Oracle Identity Management用のバイナリ・ファイルおよびライブラリ・ファイルを格納します。 |
Oracle Internet Directory Oracle Virtual Directory Oracle Directory Services Manager |
|
|
Oracle Identity and Access Managementに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します。 |
Oracle Access Manager Oracle Identity Management |
|
|
Oracle Unified Directoryに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します。 |
Oracle Unified Directory |
|
|
Oracle HTTP Serverに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します。
|
Oracle Webゲート |
|
|
Oracle SOA Suiteに必要なバイナリおよびライブラリ・ファイルを格納します。OIMを含むトポロジを作成する場合のみ必要で、 |
Oracle SOA Suite |
|
|
汎用Oracleホーム・ファイルを格納します。このOracleホームは、いずれかの製品をインストールすると自動的に作成され、 |
汎用コマンド |
インストール・メディアにあるOracleインストーラを使用してソフトウェアのインストールを実行します。このガイドでは、第4章「エンタープライズ・デプロイメント用の記憶域の準備」で説明されているように、ソフトウェアを異なるディレクトリにデプロイします。
実行する必要があるインストール・タスクは、次のようにまとめることができます。
Web層のホストにあるローカル記憶域にOHSをインストールします。
Web層のホストにあるローカル記憶域にOracle Webゲートをインストールします。
アプリケーション層のホストで使用できる共有記憶域にOracle WebLogic Serverをインストールします。
アプリケーション層のホストで使用できる共有記憶域にOracle Identity and Access Managementをインストールします。
Oracle Unified Directoryを使用している場合、アプリケーション層のホストで使用できる共有記憶域にOracle Unified Directoryをインストールします。
Oracle Internet DirectoryまたはOracle Virtual Directoryを使用している場合、データ層のホストにOracle Identity Managementをインストールします。これらの製品を使用する計画があるが高可用性ディレクトリがない場合、『Oracle Fusion Middleware高可用性ガイド』の説明に従って、高可用性ディレクトリを作成する必要があります。Oracle Internet DirectoryまたはOracle Virtual Directoryの他に、Oracle Internet DirectoryおよびOracle Virtual Directory用にODSMもインストールする必要があります。
分割ドメイン構成を作成している場合、Oracle Identity Managementをアプリケーション層上の2つの分離された場所にインストールし、独立したパッチ適用を容易にする必要があります。
Oracleソフトウェアのインストールの詳細手順は、このドキュメントのコンポーネントの章を参照してください。
Oracle Internet DirectoryやOracle Virtual Directoryなど、製品によっては、一部のファイルのアクセス権をrootに設定するスクリプトを実行する必要があります。
設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。
適用するパッチのリストは、使用中のプラットフォームおよびオペレーティング・システムに関するOracle Fusion Middlewareリリース・ノートを参照してください。ソフトウェアを期待どおりに動作させるには、パッチを適用する必要があります。
|
注意: 特に、次のトポロジ・ダイアグラムに示すようにOracle Unified Directoryをアクティブ/アクティブ・モードで使用している場合、パッチ16943171は重要です。このパッチを適用しないと、フェイルオーバー・イベントの際にデータの不整合が発生する可能性があります。 |
パッチはhttp://support.oracle.comからダウンロードできます。各パッチをデプロイする手順は、同封のREADME.htmlファイルにあります。
Oracle Identity Managementエンタープライズ・デプロイメントを開始する前に、図2-4「Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャート」のフロー・チャートを確認してください。このフロー・チャートは、このガイドで説明するエンタープライズ・デプロイメントを完成させるための大まかなプロセスを示しています。表2-4はこのフロー・チャート内の手順を説明するものであり、ここから各手順の項または章にジャンプできます。
この項の内容は、次のとおりです。
図2-4「Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャート」は、Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャートです。このチャートを確認し、既存の環境に基づいた実行手順を理解してください。
表2-4では、図2-4で示したOracle Identity Managementのエンタープライズ・デプロイメント処理のフロー・チャートの各手順を説明します。この表では、処理における各手順の詳細について、その参照先も示します。
表2-4 Oracle Identity Managementエンタープライズ・デプロイメント処理の手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
エンタープライズ・デプロイメント用のネットワークの準備 |
エンタープライズ・デプロイメント用のネットワークを準備するには、仮想サーバー名、IP、仮想IPなどの概念を理解し、仮想ホスト名を定義してロード・バランサを構成する必要があります。 |
第3章「エンタープライズ・デプロイメント用のネットワークの準備」 |
|
エンタープライズ・デプロイメント用の記憶域の準備 |
エンタープライズ・デプロイメント用のファイル・システムを準備するには、ディレクトリおよびディレクトリ環境変数の用語を理解し、共有記憶域を構成する必要があります。 |
|
|
エンタープライズ・デプロイメント用のサーバーの準備 |
エンタープライズ・デプロイメント用のサーバーを準備するには、サーバーがハードウェア要件およびソフトウェア要件を満たしていることを確認し、Unicodeサポートおよび仮想IPアドレスを有効にし、共有記憶域をマウントし、ユーザーおよびグループを構成し、必要に応じてソフトウェアを複数のホームを持つシステムにインストールします。 |
第5章「エンタープライズ・デプロイメント用のサーバーの準備」 |
|
エンタープライズ・デプロイメント用のデータベースの準備 |
エンタープライズ・デプロイメント用のデータベースを準備するには、データベース要件の確認、データベース・サービスの作成、Oracle RACデータベースへのメタデータ・リポジトリのロード、トランザクション・リカバリ権限用アイデンティティ管理スキーマの構成およびデータベースのバックアップを実行する必要があります。 |
第6章「エンタープライズ・デプロイメント用のデータベースの準備」 |
|
Oracle Unified Directory用のドメインの拡張 |
構成ウィザードを実行してOracle Unified Directoryを構成することによって既存のWebLogicドメインを拡張します。 |
第7章「Oracle Unified Directoryのインストールおよび構成」 |
|
ドメインの作成 |
構成ウィザードを実行して、ドメイン(OIMDomain)を作成し、OAMおよびOIMを組み込みます。 |
第8章「エンタープライズ・デプロイメント用のドメインの作成」 |
|
アイデンティティ・ストアとポリシー・ストアの準備 |
Oracle Identity Managementエンタープライズ・デプロイメントのアイデンティティ・ストアおよびポリシー・ストアを準備します。 |
|
|
Web層の構成 |
Oracle Web層をOracle WebLogicドメインに関連付け、Oracle HTTP Serverをロード・バランサとともに構成し、仮想ホスト名を構成することでOracle Web層を構成します。 |
第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」 |
|
Oracle Access Management用のドメインの拡張 |
構成ウィザードを再度実行し、Oracle Access Managementを追加するためにドメインを拡張します。 |
第11章「Oracle Access Managementを追加するためのドメインの拡張」 |
|
Oracle Identity Manager用のドメインの拡張 |
構成ウィザードを再度実行し、Oracle Identity Managerを追加するためにドメインを拡張します。 |
第12章「Oracle Identity Managerを追加するためのドメインの拡張」 |
|
ノード・マネージャの設定 |
ホスト名検証を有効化し、ノード・マネージャを起動して、カスタム・キーストアを使用するようにWebLogic Serverを構成し、ノード・マネージャを設定します。 |
第13章「エンタープライズ・デプロイメント用のノード・マネージャの設定」 |
|
サーバー移行の構成 |
WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2の各管理対象サーバーのサーバー移行を構成します。管理対象サーバーWLS_OIM1およびWLS_SOA1は、障害発生時にIDMHOST2上で再起動されるように構成されます。管理対象サーバーWLS_OIM2およびWLS_SOA2は、障害発生時にIDMHOST1上で再起動されるように構成されます。 |
第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」 |
|
エンタープライズ・デプロイメントで管理コンソールのシングル・サインオンを構成します。 |
アイデンティティ管理エンタープライズ・デプロイメントで管理コンソールのシングル・サインオン(SSO)を構成します。 |
第15章「エンタープライズ・デプロイメントにおける管理コンソールのシングル・サインオンの構成」 |
