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