| Oracle® Exalogic Elastic Cloud Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51446-03 |
|
 前 |
 次 |
| Oracle® Exalogic Elastic Cloud Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51446-03 |
|
前 |
次 |
この章では、このガイドに記載されているエンタープライズ・デプロイメント参照トポロジについて説明し、デプロイメントの計画を支援します。
この章には次のトピックが含まれます:
この項では、ExalogicでのOracle Identity Managementのデプロイメントの計画に役立つ情報を提供します。
デプロイメントの計画の際、この章に記載されている特定の参照トポロジを実装する詳細な手順がこのガイドに示されていることに留意してください。
このトポロジは、次のようなExalogicプラットフォームの主な特徴を利用しています。
Exalogic内Infiniband (IPoIB)ネットワーク・ファブリックの高い帯域幅とパフォーマンス
Oracle Traffic Directorのソフトウェア・ロード・バランシング機能
この特定のトポロジで、Oracle Traffic Directorは、Webリスナーと内部通信用のクライアント側ロード・バランサの両方として使用されます。
この構成では、Traffic Directorインスタンスとアイデンティティ管理の計算ノード間のすべての内部通信に、ExalogicのデフォルトのIPoIBネットワークを利用できます。
Traffic Directorインスタンスと外部ユーザー間の外部トラフィックのみ、Exalogic Ethernet over IB (EoIB)ネットワーク上で転送されます。
このガイドで説明されているトポロジに加え、Exalogicでは代替のOracle Identity Managerトポロジを検討できます。
このガイドでは、これらの代替トポロジの実装の具体的な手順は示していませんが、ExalogicでのOracle Identity Managerデプロイメント用に環境を準備する際には、次の点を検討してください。
第2.1.1項で説明したとおり、このガイドのトポロジでは、Oracle Traffic Directorを、Webサーバーと内部ロード・バランサの両方として使用します。この構成では、2つの計算ノードをOracle Traffic Directorインスタンスのホスト専用にする必要があります。
2つの計算ノードをOracle Traffic Director専用にできない場合、または専用のOracle HTTP Server Web層を使用する場合は、Exalogicマシン外にある外部Web層にOracle HTTP Serverをデプロイすることが可能です。
外部のOracle HTTP Server Web層を使用した一般的なExalogicのOracle Identity Managerトポロジの図は、付録C「Oracle HTTP Serverを使用するエンタープライズ・トポロジ」を参照してください。
このガイドの参照トポロジでは、外部Real Application Clusters (RAC)データベースを製品スキーマおよびセキュリティ・ストアのリポジトリとして使用する方法についての情報を提供します。
トポロジは、RACデータベースが専用サーバーでホストされることを前提としています。これらのサーバーは、Oracle Exadataデータベース・マシンから独立することも、その一部とすることもできます。
Oracle Exadataマシンを使用する場合、これをInfinibandファブリックを介してExalogicマシンに接続する必要があります。詳細は、Oracle Exalogic Elastic Cloudマルチラック・ケーブル・ガイドのExalogicとExadataマシンの接続に関する項を参照してください。
エンタープライズ・デプロイメント成功の鍵となるのは計画と準備です。この章のインストールおよび構成の手引きでは、実行する必要のあるタスクに関する章を示します。
この章を、ExalogicプラットフォームでのOracle Identity Managementエンタープライズ・デプロイメントの計画に役立ててください。
ホスト名、IPアドレス、およびこのデプロイメントに必要なマシンやリソースの調達や特定を行う際の重要なその他の情報を把握するには、付録A「アイデンティティ管理トポロジのワークシート」も役立ちます。
図2-1は、Exalogicにおける、Oracle Identity Management用の標準的な参照トポロジの図を示します。
この特定のトポロジで、Web層はOracle Traffic Directorインスタンスで構成され、Exalogicマシンは10Gbイーサネット接続でリモートのOracle RACデータベースと接続されています。
トポロジの要素の詳細な説明は、第2.3項「トポロジ・コンポーネントの理解」を参照してください。
図2-1 Oracle Traffic DirectorおよびOracle RACデータベースとともにデプロイされたExalogic上のOracle Identity Management
トポロジは3つの層で構成されます。これらについて、次の項で説明します。
Exalogicマシンを最初に設定すると、デフォルト・ネットワークではIP over Infiniband (IPoIB)を実行します。このガイドで説明しているトポロジの様々な目的のため、IPoIBネットワークに加えて、Ethernet over Infiniband (EoIB)ネットワークのアクセスを構成する必要があります。詳細は、『Oracle Exalogic Elastic Cloudマシン・オーナーズ・ガイド』でEthernet Over InfiniBandの構成に関する項を参照してください。
Exalogicデプロイメントでは、次のように2つの異なるタイプのネットワークが使用されます。
IPoIBは、Exalogicマシン・ラック内のコンポーネントの内部通信用に使用されます。このネットワークは、Exalogicマシン・ラック自体の外部では表示されません。
EoIBは、Exalogicマシン・ラックの外部のコンポーネントと通信するために、Exalogicマシン・ラック内部のコンポーネントに使用されます。
次の4種類の通信が、ExalogicにおけるOracle Identity and Access Managementエンタープライズ・デプロイメントで構成されている必要があります。
Oracle Traffic Directorホストでは、IPアドレスは、ロード・バランサからアクセスできるEoIBアドレスにする必要があります。Oracle Traffic DirectorのIPアドレスは、DMZネットワークからアクセスできるアドレスのみです。
アプリケーション層ではIDMHOSTマシンのIPアドレスは、Oracle RACデータベースのSCANとVIPアドレスにアクセスできるEoIBアドレスにする必要があります。さらに、IDMサーバーではIPoIBアドレスを内部呼出し用とExalogicラック内部におけるRMI相互作用のメイン・リスニング・アドレスとして使用します。
Oracle Traffic Directorホストとアプリケーション層との間における通信とルーティングは、IPoIBでのみ行う必要があります。
複数のアプリケーション層コンポーネント間における通信の場合、たとえば、内部JMS宛先のルーティングは、IPoIBで行う必要があります。内部利用専用で公開されるフロント・エンド・アドレスでは、Oracle Traffic DirectorホストにおいてIPoIBの仮想IPを使用します。
また、RMI/JMS/T3呼出しとHTTP呼出しで外部的にIDMサーバーにアクセスできます。リモート・デプロイメント、外部JMSのプロデューサとコンシューマ、およびExalogicラック(EoIB)外部で利用可能なIDMサーバーのリスニング・アドレスを使用する他の操作でこれらが行われます。
IPoIBおよびEoIBのネットワーク構成の詳細は、第3章「エンタープライズ・デプロイメント用のネットワークの構成」を参照してください。
Exalogicデプロイメントでは、ハードウェア・ロード・バランサはExalogicマシン・ラックの外部に位置します。これの機能は、IAMデプロイメントの外部リクエストを受信し、各Webホストに渡すことです。これらのWebホストは、Oracle HTTP ServerまたはOracle Traffic Directorサーバーのいずれかになります。
ロード・バランサは、HTTPおよびHTTPSリクエストを受信するために構成されます。ロード・バランサでHTTPSリクエストを受信する場合、SSLはロード・バランサで復号化され、HTTPプロトコルを使用してWebサーバーに渡されます。これは、ロード・バランサでSSLの終了と呼ばれます。
ハードウェア・ロード・バランサからWeb層(この場合、WEBHOST1とWEBHOST2)への通信は、完全にEoIB経由です。
ロード・バランサは、アプリケーション・リクエストと管理リクエストの両方をWebサーバーにルーティングするために使用されます。管理リクエストは、組織のイントラネット内で発生します。アプリケーション・リクエストは、イントラネットまたはインターネットを介して受信できます。
Exalogicでは、Oracle Traffic Director機能を利用できます。
特に、Oracle Traffic Directorのアーキテクチャにより、小さな待機時間で大量のアプリケーション・トラフィックを処理することが可能となります。これは、Oracle Exalogic Elastic Cloudでの使用に向けて最適化されます。WebLogic Serverとは、ExalogicのInfiniBandファブリック(IPoIB)を経由して、バック・エンドで通信します。
このトポロジでのOracle Traffic Directorインスタンスの役割は次の2つです。
ハードウェア・ロード・バランサからのHTTPリクエスト(EoIBネットワーク経由)を受信し、これらのリクエストを(IPoIBネットワーク経由で)アプリケーション層の計算ノードにルーティングします。
アプリケーション層コンポーネントからのリクエスト(IPoIBネットワーク経由)を他のアプリケーション層コンポーネントにルーティングします(Oracle Access ManagerからのリクエストをOracle Unified Directoryディレクトリ・サービスにルーティングするなど)。
内部のIPoIBネットワークのみを介してルーティングされる内部アプリケーションからアプリケーションへのリクエストは、トポロジ・ダイアグラム(図2-1)のVIP1で示されている仮想IPアドレスを介してルーティングされます。
Oracle Traffic Directorインスタンスはフェイルオーバー・グループの一部として構成されます。この構成で、Oracle Traffic Directorは仮想ルーター冗長プロトコル(VRRP)の実装を使用してフェイルオーバー機能を提供します。Oracle Traffic Directorインスタンスに障害が発生すると、そこで有効化されているIPアドレスは、VRRPを経由してまだ稼働しているインスタンスに移行されます。
リクエストは、Oracle Traffic Directorサーバーからアプリケーション層で実行中のOracle WebLogic Serverにルーティングされます。
WebゲートはOracle Accessプロトコル(OAP)を使用してOracle Access Managerと通信し、ユーザー認証などの処理を実行します。
Oracle Traffic Directorは次のアクションを実行します。
特定のロード・バランシング方法に基づいて、アプリケーション層のクライアントからサーバーに受信するリクエストを分散します。
特定のルールに基づいてリクエストをルーティングします。
頻繁にアクセスされるデータをキャッシュします。
トラフィックを優先度付けし、サービスの品質を制御します。
Oracle Traffic Directorは、HTTPまたはLDAPリクエストのルーティングに使用できます。
内部ロード・バランシングに使用されます(常に必須)。
Webサーバーとして機能します。
DMZは、インフラストラクチャのコンポーネントへのアクセスを、実際にそれを必要としているもののみに限定する手段です。このガイドの例では、パブリックDMZがあります。これは、外部の世界がシステムへのアクセスを取得する場所です。このゾーンには、ロード・バランサやWeb層など、外部ネットワークがアクセスする必要のあるコンポーネントのみを配置します。外部ネットワークのユーザーがこのゾーンの下にあるサーバーやサービスへのアクセスを試みると、ファイアウォールによってこれが阻止されます。パブリック・ゾーンは、このゾーンのサーバーがプライベート・ゾーンのアプリケーション・サーバーと相互作用できるように構成します。
パブリック・ゾーン: 外部ネットワークがシステムへのアクセス権を獲得する場所です。このゾーンには、ロード・バランサやWeb層など、外部ネットワークがアクセスする必要のあるコンポーネントのみを配置します。外部ネットワークのユーザーがこのゾーンの下にあるサーバーやサービスへのアクセスを試みると、ファイアウォールによってこれが阻止されます。
パブリック・ゾーンは、このゾーンのサーバーがプライベート・ゾーンのアプリケーション・サーバーと相互作用できるように構成します。
イントラネット・ゾーン: データベースなどのコア・サービスを含むサーバーを配置する場所です。これらのサービスは、最も機密性の高いデータが含まれるため、組織によって非常に厳しく制御されます。
このアプローチを使用することにより、情報へのアクセスを、その情報を必要とするコンポーネントのみに限定します。このアプローチは、組織の外からユーザーが入ってくる場合に役立ちます。エクストラネットのかわりに、信頼されるソースからすべての通信が送られるイントラネットを設定する場合、パブリックDMZなしにする決断を合理的に行うことができます。
アプリケーション層は、Java EEアプリケーションがデプロイされる層です。この層にデプロイできるJava EEコンポーネントの例としては、Oracle Identity Manager、Oracle Directory Services Manager、Oracle Enterprise Manager Fusion Middleware Controlなどの製品があります。この層のアプリケーションは、Oracle WebLogic ServerおよびOracle Fusion Middlewareの高可用性サポートの利点を享受できます。
アプリケーション層において、IDMHOST1およびIDMHOST2には次のコンポーネントが含まれています。これらは、Oracle WebLogic Serverドメインの管理対象サーバーにインストールされています。
インフラストラクチャの操作コンポーネント。このコンポーネントは、Oracle Access Management Access Manager (OAM)です。これはOracle WebLogic Server内で実行されるJ2EEアプリケーションです。
ユーザー・プロビジョニングに使用されるOracle Identity Managerを含む、アイデンティティ管理の管理コンポーネント。
Oracle SOA Suite (SOA)。これはプロセス・ワークフローでリクエスト承認を管理するため、Oracle Identity Managementで必要となります。
IDMHOST1はOracle WebLogic管理サーバーをホストします。管理サーバーは、Oracle WebLogicコンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Access Management ConsoleおよびOUDのOracle Directory Services Manager (ODSM)をホストします。
Oracle WebLogic Server管理サーバーはシングルトン・プロセスです。つまり、1つのドメイン内で同時に実行できる管理サーバーは1つのみです。管理サーバーを実行しているホストに障害が発生した場合には、別のホストで手動で管理サーバーを起動できます。
Oracle Fusion Middlewareコンポーネントへのアクセスを制御するには、Oracle Entitlement Serverの埋込みバージョンが使用されます。
Oracle Entitlements Serverは、データベース内に格納される中央のポリシー・ストアを使用します。
Access Managerは、OPSSポリシー・ストアを使用してポリシー情報を格納します。
Oracle WebLogic Serverコンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Access Managementコンソールは、常に管理サーバーのリスニング・アドレスにバインドされます。
管理対象サーバーWLS_OAM1およびWLS_OAM2は、クラスタおよびクラスタにデプロイされているAccess Managerアプリケーションにデプロイされます。
管理対象サーバーWLS_OIM1およびWLS_OIM2は、クラスタおよびクラスタにデプロイされているAccess Managerアプリケーションにデプロイされます。
管理対象サーバーWLS_SOA1およびWLS_SOA2は、クラスタおよびクラスタにデプロイされているAccess Managerアプリケーションにデプロイされます。
Oracle Traffic Directorは、アクティブ/パッシブ・モードで高可用性を実現するように構成できます。仮想ホスト/IPアドレスは、単一OTDインスタンスで起動します。ハートビートは各OTDインスタンス間に存在します。このハートビートを使用して、セカンダリOTDインスタンスは、プライマリOTDインスタンスに障害が発生した場合に仮想ホスト/IPアドレスを有効にします。
OAMサーバー、Oracle Identity ManagerおよびSOAは、アクティブ/アクティブ・デプロイメントです。これらのサーバーは実行時にデータ層と通信します。
Oracle Traffic DirectorはHTTPおよびLDAPのリクエストをすべてのWebLogic管理対象サーバーまたはOUDインスタンスに送り、最大限の可用性を保証します。
WebLogic管理サーバーおよびOracle Enterprise Managerデプロイメントはアクティブ/パッシブです(他のコンポーネントはアクティブ/アクティブ)。ドメインごとに1つの管理サーバーがあります。
WebLogic管理サーバーは、アクティブ/パッシブ構成でデプロイされるシングルトン・コンポーネントです。プライマリに障害が発生したり、IDMHOST1上の管理サーバーが起動しない場合、セカンダリ・ホストの管理サーバーを起動できます。WebLogic管理対象サーバーに障害が発生すると、そのホストで実行されているノード・マネージャはその再起動を試みます。
アイデンティティ情報はLDAP準拠ディレクトリに格納されます。このトポロジで、OracleはネイティブでOracle Unified Directoryをサポートしています。
次の項では、Exalogicでのアイデンティティ管理エンタープライズ・トポロジのハードウェア要件について説明します。
Oracle Fusion Middlewareエンタープライズ・デプロイメントでは、リクエストをWeb層にルーティングするため、ハードウェア・ロード・バランサが必要です。このトポロジのロード・バランサで必要な最低限の機能セットについては、第3.9.1項「ロード・バランサの要件」を参照してください。
Exalogicマシンは、仮想または物理マシン、ストレージ・アプライアンスのほか、必要なInfiniBandおよびイーサネット・ネットワーキング・コンポーネントから構成されます。各マシンに含まれるコンポーネントの数は、ハードウェア構成によって異なります。
Exalogicマシンで使用可能なハードウェア・オプションの詳細は、『Oracle Exalogic Elastic Cloudマシン・オーナーズ・ガイド』のExalogicのハードウェア構成に関する項を参照してください。
このガイドで説明しているトポロジでは、Exalogicマシン1/8ラックを使用できます。詳細は、第2.2項「ExalogicでのOracle Identity Managementデプロイメント・トポロジの理解」を参照してください。
Exalogicマシンは、次のように割り当てることができます。
2つのマシンをアプリケーション層に割り当てます。これらをIDMHOST1およびIDMHOST2と呼びます。
Oracle Traffic Directorトポロジを使用している場合は、さらに2つのマシンをOracle Traffic Directorインスタンスに割り当てます。これらをWEBHOST1およびWEBHOST2と呼びます。
標準のOracle RACデータベースの計算ノードを割り当てることもできますが、このガイドでは、データベースはリモートのホスト・セットでホストされることを想定しています。
この項では、Oracle Identity Managementエンタープライズ・デプロイメントで必要なソフトウェアについて説明します。
この項の内容は、次のとおりです。
表2-1に、このガイドの手順を開始する前に取得する必要のあるOracleソフトウェアを示します。
表2-1 使用するソフトウェア・バージョン
| 短縮名 | 製品 | バージョン |
|---|---|---|
|
OTD |
Oracle Traffic Director |
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.0.0 |
|
SOA |
Oracle SOA Suite |
11.1.1.6.0 |
|
Webゲート |
Webゲート11g |
11.1.2.0.0 |
|
RCU |
リポジトリ作成アシスタント |
11.1.2.0.0 |
|
OUD |
Oracle Unified Directory |
11.1.2.0.0 |
Oracle Fusion Middlewareソフトウェアのダウンロードの詳細は、http://docs.oracle.com/cd/E23104_01/download_readme.htmにあるこのリリースのOracle Fusion Middleware 11g リリース1のダウンロード、インストールおよび構成のReadmeを参照してください。
適用するパッチのリストは、ご使用のプラットフォームおよびオペレーティング・システムのOracle Fusion Middlewareリリース・ノートを参照してください。ソフトウェアが期待どおりに動作するよう、必ずパッチを適用してください。
パッチはhttp://support.oracle.comからダウンロードできます。各パッチのデプロイ手順は、それぞれのパッチ・アーカイブに含まれているREADME.htmlファイルを参照してください。
Oracle Identity Managementエンタープライズ・デプロイメントを開始する前に、図2-2「Oracle Identity Managementエンタープライズ・デプロイメント・プロセスのフロー・チャート」を確認してください。このフローチャートは、このガイドに記載されているエンタープライズ・デプロイメントを実行するための大まかなプロセスを示しています。表2-2では、フロー・チャートの手順について説明し、各手順についての項または章を示しています。
このセクションの内容は次のとおりです。
図2-2「Oracle Identity Managementエンタープライズ・デプロイメント・プロセスのフロー・チャート」に、Oracle Identity Managementエンタープライズ・デプロイメント・プロセスのフロー・チャートを示します。このチャートを確認し、既存の環境に基づいて実行する必要のある手順をよく理解してください。
表2-2に、図2-2で示したOracle Identity Managementのエンタープライズ・デプロイメント・プロセスのフロー・チャートの各手順を説明します。また、プロセス内の各手順の詳細を説明している章や項も示します。
表2-2 Oracle Identity Managementエンタープライズ・デプロイメント・プロセスの手順
| 手順 | 説明 | 詳細情報 |
|---|---|---|
|
エンタープライズ・デプロイメント・トポロジの確認 |
推奨されるトポロジを確認し、組織やアプリケーションに最も適したトポロジを計画します。 |
|
|
エンタープライズ・デプロイメント用のネットワークの準備 |
エンタープライズ・デプロイメント用のネットワークを準備するには、仮想サーバー名、IP、仮想IPなどの概念を理解し、仮想ホスト名を定義することによりロード・バランサを構成します。 |
第3章「エンタープライズ・デプロイメント用のネットワークの構成」 |
|
エンタープライズ・デプロイメント用のファイル・ストレージ・アプライアンスの準備 |
エンタープライズ・デプロイメント用のファイル・システムを準備するには、ディレクトリおよびディレクトリ環境変数についての用語を確認し、共有記憶域を構成します。 |
|
|
エンタープライズ・デプロイメント用の計算ノードの準備 |
エンタープライズ・デプロイメント用のサーバーを準備するには、ご使用のサーバーがハードウェアおよびソフトウェアの要件を満たしていることを確認し、Unicodeサポートおよび仮想IPアドレスを有効にして、共有記憶域をマウントし、ユーザーとグループを構成して、必要に応じてソフトウェアをマルチホーム・システムにインストールします。 |
第5章「エンタープライズ・デプロイメント用の計算ノードの構成」 |
|
エンタープライズ・デプロイメント用のOracle RACデータベースの準備 |
エンタープライズ・デプロイメント用のOracle RACデータベースを準備するには、データベース要件を確認し、Oracle RACでデータベース・サービスを作成してメタデータ・リポジトリをロードし、トランザクション・リカバリ権限のアイデンティティ管理スキーマを構成して、データベースをバックアップします。 |
第6章「エンタープライズ・デプロイメント用のデータベースの構成」 |
|
Oracle Unified Directoryのインストールおよび構成 |
Oracle Unified Directoryをインストールおよび構成します。これは推奨されるトポロジでアイデンティティ・ストアとして使用されます。 Oracle Unified Directory構成アシスタントを使用して、2つのOracle Unified Directoryインスタンスを構成します。 |
第8章「Oracle Unified Directoryのインストールおよび構成」 |
|
初期WebLogic Serverドメインの作成 |
構成ウィザードを実行し、初期WebLogic Serverドメインを作成します。 |
|
|
Exalogic計算ノードでのOracle Traffic Directorのインストールおよび構成 |
Oracle Traffic Directorをインストールおよび構成します。 |
第7章「エンタープライズ・デプロイメント用のOracle Traffic Directorのインストールおよび構成」 |
|
Oracle Access Management用のドメインの拡張 |
再度構成ウィザードを実行し、Oracle Access Managementを含むようにドメインを拡張します。 |
第11章「Oracle Access Managementを含めるためのドメイン拡張」 |
|
Oracle Identity Manager用のドメインの拡張 |
再度構成ウィザードを実行し、Oracle Identity Managerを含むようにドメインを拡張します。 |
第12章「Oracle Identity Managerを含めるためのドメイン拡張の概要」 |
|
管理コンソール用のSSOの構成 |
アイデンティティ管理エンタープライズ・デプロイメントでの管理コンソール用のシングル・サインオン(SSO)を構成します。 |
第15章「エンタープライズ・デプロイメントでの管理コンソールに対するシングル・サインオンの構成」 |
|
ノード・マネージャの構成 |
ホスト名の検証を有効にし、ノード・マネージャを起動して、カスタム・キーストアを使用するようにWebLogic Serverを構成することによって、ノード・マネージャを設定します。 |
第13章「エンタープライズ・デプロイメントのノード・マネージャの設定」 |
|
サーバー移行の構成 |
WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2の管理対象サーバーのサーバー移行を構成します。WLS_OIM1およびWLS_SOA1の管理対象サーバーは、障害が発生した場合、IDMHOST2で再起動するように構成します。WLS_OIM2およびWLS_SOA2の管理対象サーバーは、障害が発生した場合、IDMHOST1で再起動するように構成します。 |
第14章「エンタープライズ・デプロイメントのサーバー移行の構成」 |
