1. Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの理解
  3. IAM Exalogicエンタープライズ・デプロイメントについて

4 IAM Exalogicエンタープライズ・デプロイメントについて

この章では、ExalogicハードウェアでのOracle Identity and Access Managementデプロイメント・トポロジについて概説します。これらのトポロジは、「エンタープライズ・デプロイメントの理解」で説明した概念の具体的な参照用実装です。

このドキュメントでは、読者がExalogicを理解していることを前提にしています。Exalogicの機能の詳細が必要な場合は、使用するExalogicのリリースの『Exalogicエンタープライズ・デプロイメント・ガイド』を参照してください。

トピック:

親トピック: エンタープライズ・デプロイメントの理解

Oracle IAMをExalogicにインストールする理由

Oracle Exalogicは、Oracleの高可用性および高パフォーマンスの統合ハードウェア・アプライアンスです。Oracle Fusion MiddlewareコンポーネントをOracle Exalogicにデプロイすると、優れたネットワーキング機能を利用できるため、アプリケーションのスループットが向上します。さらに、WebLogic Serverは、Oracle Exalogic上でより高速に実行するための最適化をいくつか備えています。これらの最適化によって、デプロイされたアプリケーションのスループットをさらに増加できます。

Oracle IAMをExalogicにデプロイすると、最大の可用性とパフォーマンスを提供する高可用性インフラストラクチャが実現します。

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて

Exalogicでのプライマリおよび独自構築のエンタープライズ・デプロイメント・トポロジの理解

このガイドでは、仮想ExalogicまたはOracle CloudマシンにおいてOracle Identity and Access Managementをデプロイするプライマリ・デプロイメント・トポロジを中心に説明しています。

次のセカンダリ・トポロジについて、このドキュメントで図解および説明します。

  • 物理ExalogicにおけるOracle Identity Management

  • 外部Web層を含むExalogicにおけるOracle Identity Management

仮想Exalogicと物理Exalogicの対比:

物理Exalogicデプロイメントは、Exalogicラックのそのままの処理パワーを使用します。製品はコンピュート・ノードに直接デプロイされます。Oracle仮想Exalogicは基礎となる同じハードウェアを使用しますが、Oracle Elastic CloudまたはOracle Cloud Machineインフラストラクチャは、小規模な仮想サーバーを作成できる仮想レイヤーを提供するために使用されます。

仮想サーバーはプラットフォーム・デプロイメントに類似のホスト・セットを提供するために使用されます。物理的にExalogicをデプロイメントすればより強力な計算能力を活用できますが、コンピュート・ノードを最大限使用しないと、そのパワーの一部は無駄になる可能性があります。仮想デプロイメントにより分離性と管理性が高まりますが、同じタイプの仮想サーバー2つが基礎となる同じコンピュート・ノードで実行されないようにする必要があるため、設計がさらに複雑になります。

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて

プライマリOracle Identity and Access Management Exalogicエンタープライズ・トポロジのダイアグラム

この項では、Oracle Identity and Access Management Exalogicトポロジのダイアグラムを示します。

トピック:

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて

物理ExalogicでのOracle Identity and Access Managementのダイアグラム

図名は、Oracle Identity and Access Managementの統合トポロジを示しています。

図4-1 Exalogic物理デプロイメント・トポロジ

Exalogic物理デプロイメント・トポロジ

親トピック: プライマリOracle Identity and Access Management Exalogicエンタープライズ・トポロジのダイアグラム

仮想ExalogicでのOracle Identity and Access Managementのダイアグラム

図名は、Oracle Identity and Access Managementの分散トポロジを示しています。

図4-2 Exalogic仮想デプロイメント・トポロジのダイアグラム

Exalogic仮想デプロイメント・トポロジのダイアグラム

親トピック: プライマリOracle Identity and Access Management Exalogicエンタープライズ・トポロジのダイアグラム

外部Web層を含むOracle Identity and Access Managementのダイアグラム

図名は、外部Web層を含むOracle Identity and Access Managementの統合トポロジを示しています。

図4-3 外部OHSを含むExalogicトポロジ

外部OHSを含むExalogicトポロジ

親トピック: プライマリOracle Identity and Access Management Exalogicエンタープライズ・トポロジのダイアグラム

プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて

この項では、プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて説明します。

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

親トピック: プライマリOracle Identity and Access Management Exalogicエンタープライズ・トポロジのダイアグラム

製品の分離について

Oracle Identity and Access Managementデプロイメントは、複数のコンポーネントで構成されています。次のコンポーネントが含まれます。

  • Webサーバー

  • WebLogicアプリケーション・サーバー

  • LDAP - LDAPコールを行う目的で内部サーバーがアクセスする仮想IPアドレスを管理します。

    LDAP仮想IPアドレスでリクエストを受信し、IPoIBネットワークを使用して、実行中のLDAPインスタンスにそのリクエストを渡します。

  • データベース

アクセス・ドメインとガバナンス・ドメインについて

図4-1、図4-2および図4-3は、各コンポーネント間の分離を示しています。さらに、WebLogicコンポーネントは、IAMAccessDomainおよびIAMGovernanceDomainの2つのWebLogicドメインに分割されています。製品は次のように配置されています。

  • IAMAccessDomainには、Oracle Access Manager、Oracle Mobile Security Suiteが含まれます。

  • IAMGovernanceDomainには、Oracle Identity Manager、Oracle Business Intelligenceが含まれます。

このように分割されているのは、各コンポーネントで要求される操作要件および可用性要件が異なるためです。通常、IAMAccessDomain内のコンポーネントの可用性要件は、IAMGovernanceDomain内のコンポーネントより高くなります。これらのコンポーネントを分離することによって、可用性要件を別々に管理できます。アクセス・コンポーネントとは関係なくガバナンス・コンポーネントにパッチを適用でき、アクセス・コンポーネントに影響を与えずにガバナンス・インスタンスを停止できます。

この分離は、多くの場合Web層およびアプリケーション層のコンポーネントとは別の時点にリリースされるディレクトリ層にも拡張できます。ディレクトリの分離によって、ドメインの分割と同様の利点(独立したアップグレードやパッチ適用など)を得られます。

この分離による更なる利点は、トポロジをモジュラ形式で構築できることです。ディレクトリから開始してアクセス・コンポーネントに拡張し、後でガバナンス・コンポーネントに拡張すると、これらを接続しないかぎり、デプロイされているソフトウェア、または既存のコンポーネントの構成に影響を与えません。

ディレクトリ層の理解

ディレクトリ層は、LDAP対応ディレクトリがインストールされている2つの物理ホスト・コンピュータで構成されています。通常、これはOracle Unified Directory (OUD)です。

多くの場合、ディレクトリ層はデータ層に結合されています。

このリリースのエンタープライズ・デプロイメント・ガイドでは、3つの異なるLDAPディレクトリをサポートしています。これらのディレクトリを最初に作成するか、または組織内の既存のディレクトリを使用できます。サポートされるディレクトリはOracle Unified Directory (OUD)です。

選択するディレクトリは組織によって異なります。

Web層の理解

Oracle 12cでは、Oracle Traffic Director (OTD)をコロケート・モードまたはスタンドアロン・モードで使用できます。

スタンドアロン・モードではフェイルオーバー・グループの使用がサポートされず、グラフィカル・インタフェースによる管理が限定されます。このため、コロケート・モードを使用してOTDをデプロイすることをお薦めします。コロケート・モードを使用する場合、OTD管理コンポーネントはWebLogic管理サーバーに配置されます。これらのコンポーネントは、既存のWebLogicドメインに配置できます。

OTDインスタンスがリクエストを複数のドメインにそのままルーティングする場合、Oracle Identity and Access Managementでは、Oracle Traffic Director専用ドメインを使用することをお薦めします。これにより、リクエストのルーティング先のドメインと無関係にOracle Traffic Directorを管理できます。

各ゾーンがファイアウォールで分離されたプラットフォーム・デプロイメントでは、管理サーバーをアプリケーション・ゾーンに配置することをお薦めします。ゾーンの分離がないOracle Exalogicデプロイメントでは、管理サーバーはOTDインスタンスと共存できます。

外部Web層を使用しており、外部Web層がOTDを実行している場合、OTD管理サーバーをWeb層DMZの外側に配置することをお薦めします。

Exalogicデプロイメントとプラットフォーム・デプロイメントの違い

ExalogicにOracle Identity and Access Managementをデプロイすると、ほとんどのコンポーネント(すべてではありません)はExalogicアプライアンス内にインストールされます。「標準的なエンタープライズ・デプロイメントについて」で説明したように、標準的なエンタープライズ・デプロイメントは様々な層に分散されます。ハードウェアのコンポーネントはExalogicアプライアンスに組み込まれているため、使用可能な層の数が減少します。

ExalogicアプライアンスがExadataアプライアンスにリンクされている場合、アプリケーション層またはディレクトリ層は必要ありません。ExalogicがExadataにリンクされている場合、データベース層はExadataに移動されます。

プラットフォーム・デプロイメントとExalogicデプロイメントの2番目の主な違いは、ExalogicデプロイメントではOracle HTTP serverのかわりにOracle Traffic Directorを使用していることです。Exalogicデプロイメントにおいて、Oracle Traffic Directorは複数の役割を実行します。Exalogicアプライアンス外に公開されないための内部トラフィックのロード・バランサ、およびWebサーバーとして機能します。

外部Web層を使用する場合、Oracle Traffic DirectorのWebサービス特性を使用する必要はありません。

Oracle ExalogicにOracle Fusion Middlewareをデプロイすると、多くの組込みWebLogic最適化にアクセスできます。これによって、Fusion Middlewareデプロイメントでいくつかの組込みExalogicテクノロジを使用でき、パフォーマンスが向上します。

親トピック: プライマリOracle Identity and Access Management Exalogicエンタープライズ・トポロジのダイアグラム

Oracle Identity and Access ManagementおよびExalogicのネットワーキング

Exalogicの中心となる利点は、高速かつ柔軟なネットワークです。Oracle IAMをExalogicにデプロイするときは、Oracle Exalogicのネットワーキングの使用方法を検討する必要があります。

Exalogicアプライアンス内には3タイプのネットワークがあります。

  • IPoIB - これは、Exalogicアプライアンスの内部コンポーネントを接続する内部Infinibandネットワークです。このネットワークは高速ですが、外部には接続できません。このネットワークの利点は、このネットワークを使用すると外部に対してネットワーク・トラフィックをプライベートにできることです。このネットワークを使用する際の短所は、外部コンポーネントがExalogicアプライアンス内のアプリケーション・コンポーネントにアクセスする必要があることです。

  • EoIB - このネットワークもExalogic Infinibandネットワークを使用しますが、このネットワークは標準的な社内ネットワークにアクセスできます。これによって、外部コンポーネントがExalogic内のコンポーネントと直接通信できます。このネットワークは常に、ハードウェア・ロード・バランサとOracle Traffic Director間の通信に使用されます。

  • eth0 - これは、ビルトイン・イーサネット・ネットワークを介してExalogicコンポーネントに接続するのに使用される管理ネットワークです。このネットワークは管理操作でのみ使用し、本番デプロイメントでは使用できません。Exalogicコンポーネントにログインして構成する場合に使用するのはこのネットワークです。

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

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて

Exalogicネットワークを選択する際の考慮事項

IAM内の一部のコンポーネントは、デフォルトで単一ネットワークでのみ通信します。たとえば、WebLogic管理対象サーバーや、Oracle Traffic Directorなどのコンポーネントは、内部ネットワークで通信します。これは、Oracle Traffic DirectorがExalogicアプライアンスに入ると、Oracle Traffic Directorがトラフィックの優先ロード・バランサになるためです。

使用するExalogicネットワークを選択する際は、次のことを考慮してください。

  • マルチデータ・センター・デプロイメントを作成する予定の場合は、EoIBネットワークを使用するようにコンポーネントを構成してください。

  • 外部Web層の使用を計画しているかどうか。その場合は、デフォルトで、EoIBネットワーク上で機能するようにコンポーネントを構成できます。

  • すべてのトラフィックがOracle Traffic Directorを経由し、トラフィックが到達するとすべてのトラフィックがExalogicアプライアンス内に維持される場合は、IPoIBネットワークを使用するようにコンポーネントを構成します。

  • すべてのLDAPトラフィックがExalogicアプライアンス内から発生する場合は、IPoIBネットワークを使用するようにLDAPサーバーを構成します。

  • データベースがExadataアプライアンス内に配置され、Exalogicアプライアンスに直接接続されている場合は、IPoIBネットワークを使用します。そうでない場合は、EoIBネットワークを使用する必要があります。

ノート:

Oracle Access Manager管理対象サーバーは、OAMプロキシ・ポートを使用して両方のネットワークで通信するように構成できます。

標準的なWebLogic管理対象サーバーは、異なるチャネルを使用して複数のネットワーク上でリスニングするように構成できます。

親トピック: Oracle Identity and Access ManagementおよびExalogicのネットワーキング

標準的なIAMネットワーク使用

この項では、標準的なIAMネットワーク使用について説明します。内容は次のとおりです。

親トピック: Oracle Identity and Access ManagementおよびExalogicのネットワーキング

仮想Exalogic

図4-4は、仮想Exalogic環境でのIdentity and Access Managementデプロイメントの標準的なネットワーク・マップを示しています。

図4-4 仮想Exalogicネットワーク・マップ

図4-4の説明が続きます
「図4-4 仮想Exalogicネットワーク・マップ」の説明

外部Web層を使用しない場合は、すべてのコンポーネントが内部IPoIBネットワークを使用するように構成できます。Oracle Traffic Directorは、リクエストをEoIBネットワーク上で受け取り、IPoIBネットワークを使用してWebLogicおよびLDAPに渡すように構成されます。

図4-4の要素は、表4-1に示すように定義されます。

表4-1 Exalogicの仮想IPアドレスのワークシート

このガイドにおけるホスト名の例 インタフェース IPアドレス/サブネット 実際の値 タイプ ホスト バインド 詳細

WEBHOST1

bond0

192.168.2.1/255.255.224.0

IPoIB/固定

vServer1/WEBHOST1

該当なし

内部IPoIBネットワーク経由でvServer11/WEBHOST1にアクセスします。

WEBHOST2

bond0

192.168.2.2/255.255.224.0

IPoIB/固定

vServer2/WEBHOST2

該当なし

内部IPoIBネットワーク経由でvServer2/WEBHOST2にアクセスします。

OAMHOST1

bond0

192.168.2.3/255.255.224.0

IPoIB/固定

vServer3/OAMHOST1

該当なし

内部IPoIBネットワーク経由でvServer3/OAMHOST1にアクセスします。

OAMHOST2

bond0

192.168.2.4/255.255.224.0

IPoIB/固定

vServer4/OAMHOST2

該当なし

内部IPoIBネットワーク経由でvServer4/OAMHOST2にアクセスします。

OIMHOST1

bond0

192.168.10.5/255.255.224.0

IPoIB/固定

vServer5/OIMHOST1

該当なし

内部IPoIBネットワーク経由でvServer5/OIMHOST1にアクセスします。

OIMHOST2

bond0

192.168.10.6/255.255.224.0

IPoIB/固定

vServer6/OIMHOST2

該当なし

内部IPoIBネットワーク経由でvServer6/OIMHOST2にアクセスします。

LDAPHOST1

bond0

192.168.10.7/255.255.224.0

IPoIB/固定

vServer7/LDAPHOST1

該当なし

内部IPoIBネットワーク経由でvServer7/LDAPHOST1にアクセスします。

LDAPHOST2

bond0

192.168.10.8/255.255.224.0

IPoIB/固定

vServer8/LDAPHOST2

該当なし

内部IPoIBネットワーク経由でvServer8/LDAPHOST2にアクセスします。

OTDADMINVHN

bond1:1

10.10.30.1/255.255.224.0

EoIB/浮動

vServer1/WEBHOST1

OTD管理サーバー

手動でOTD管理サーバーをWEBHOST1からWEBHOST2に移行する場合、管理サーバーに浮動Pアドレスを使用することをお薦めします。

IADADMINVHN

bond1:1

10.10.30.2/255.255.224.0

EoIB/浮動

vServer3/OAMHOST1

IAMAccessDomain管理サーバー

手動で管理サーバーをOAMHOST1からOAMHOST2に移行する場合、IAMAccessDomain管理サーバーに浮動Pアドレスを使用することをお薦めします。

IGDADMINVHN

bond1:1

10.10.30.3/255.255.224.0

EoIB/浮動

vServer5/OIMHOST1

IAMGovernanceDomain管理サーバー

手動で管理サーバーをOIMHOST2からOIMHOST1に移行する場合、IAMGovernanceDomain管理サーバーに浮動Pアドレスを使用することをお薦めします。

WEBHOST1VHN1

OTD

10.10.50.1/255.255.224.0

EoIB/浮動

vServer1/WEBHOST1

OTD - WEBHOST1

OTDで管理される浮動IPアドレス。これは、ロード・バランサが接続するIPアドレスです。これはオプションです

WEBHOST2VHN1

OTD

10.10.50.2/255.255.224.0

EoIB/浮動

vServer2/WEBHOST2

OTD - WEBHOST2

OTDで管理される浮動IPアドレス。これは、ロード・バランサが接続するIPアドレスです。

これはオプションです。

OIMHOST1VHN1

bond0:1

192.168.30.1/255.255.240.0

IPoIB/浮動

vServer5/OIMHOST1

WLS_OIM1デフォルト・チャネル

OIMHOST1で最初に有効にされていると、サーバー移行によりOIMHOST2にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST2VHN1

bond0:1

192.168.30.2/255.255.240.0

IPoIB/浮動

vServer6/OIMHOST2

WLS_OIM2デフォルト・チャネル

OIMHOST2で最初に有効にされていると、サーバー移行によりOIMHOST1にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST1VHN2

bond0:2

192.168.30.3/255.255.240.0

IPoIB/浮動

vServer5/OIMHOST1

WLS_SOA1デフォルト・チャネル

OIMHOST1で最初に有効にされていると、サーバー移行によりOIMHOST2にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST2VHN2

bond0:2

192.168.30.4/255.255.240.0

IPoIB/浮動

vServer6/OIMHOST2

WLS_SOA2デフォルト・チャネル

OIMHOST2で最初に有効にされていると、サーバー移行によりOIMHOST1にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST1VHN3

bond0:3

192.168.30.5/255.255.224.0

IPoIB/浮動

vServer5/OIMHOST1

WLS_BI1デフォルト・チャネル

OIMHOST1で最初に有効にされていると、サーバー移行によりOIMHOST2にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST2VHN3

bond 0:3

192.168.30.6/255.255.224.0

IPoIB/浮動

vServer6/OIMHOST2

WLS_BI2デフォルト・チャネル

OIMHOST2で最初に有効にされていると、サーバー移行によりOIMHOST1にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

WEBHOST1-EXT

bond1

10.10.10.1/255.255.240.0

EoIB/固定

vServer1/WEBHOST1

該当なし

外部ロード・バランサによるvServerへのアクセスを許可する固定IP

WEBHOST2-EXT

bond1

10.10.10.2/255.255.240.0

EoIB/固定

vServer2/WEBHOST2

該当なし

外部ロード・バランサによるvServerへのアクセスを許可する固定IP

WEBHOST1-STOR

bond3

192.168.32.1/255.255.240.0

IPoIB/固定

vServer1/WEBHOST1

該当なし

内部ネットワークを使用してvServerによるZFSストレージ・アプライアンスへの接続を許可する固定IPアドレス。

WEBHOST2-STOR

bond3

192.168.32.2/255.255.240.0

IPoIB/固定

vServer2/WEBHOST2

該当なし

内部ネットワークを使用してvServerによるZFSストレージ・アプライアンスへの接続を許可する固定IPアドレス。

OAMHOST1-STOR

bond3

192.168.32.3/255.255.240.0

IPoIB/固定

vServer3/OAMHOST1

該当なし

内部ネットワークを使用してvServerによるZFSストレージ・アプライアンスへの接続を許可する固定IPアドレス。

OAMHOST2-STOR

bond3

192.168.32.4/255.255.240.0

IPoIB/固定

vServer4/OAMHOST2

該当なし

内部ネットワークを使用してvServerによるZFSストレージ・アプライアンスへの接続を許可する固定IPアドレス。

OIMHOST1-STOR

bond3

192.168.32.5/255.255.240.0

IPoIB/固定

vServer5/OIMHOST1

該当なし

内部ネットワークを使用してvServerによるZFSストレージ・アプライアンスへの接続を許可する固定IPアドレス。

OIMHOST2-STOR

bond3

192.168.32.6/255.255.240.0

IPoIB/固定

vServer6/OIMHOST2

該当なし

内部ネットワークを使用してvServerによるZFSストレージ・アプライアンスへの接続を許可する固定IPアドレス。

LDAPHOST1-STOR

bond3

192.168.32.7/255.255.240.0

IPoIB/固定

vServer7/LDAPHOST1

該当なし

内部ネットワークを使用してvServerによるZFSストレージ・アプライアンスへの接続を許可する固定IPアドレス。

LDAPHOST2-STOR

bond3

192.168.32.8/255.255.240.0

IPoIB/固定

vServer8/LDAPHOST2

該当なし

内部ネットワークを使用してvServerによるZFSストレージ・アプライアンスへの接続を許可する固定IPアドレス。

OAMHOST1-DATA

bond4

192.168.10.3/255.255.240.0

IPoIB/固定

vServer3/OAMHOST1

該当なし

デフォルトの内部ネットワークを使用してvServerによるExadataアプライアンスへの接続を許可する固定IPアドレス。

OAMHOST2-DATA

bond4

192.168.10.4/255.255.240.0

IPoIB/固定

vServer4/OAMHOST2

該当なし

デフォルトの内部ネットワークを使用してvServerによるExadataアプライアンスへの接続を許可する固定IPアドレス。

OIMHOST1-DATA

bond4

192.168.10.5/255.255.240.0

IPoIB/固定

vServer5/OIMHOST1

該当なし

デフォルトの内部ネットワークを使用してvServerによるExadataアプライアンスへの接続を許可する固定IPアドレス。

OIMHOST2-DATA

bond4

192.168.10.6/255.255.240.0

IPoIB/固定

vServer6/OIMHOST2

該当なし

デフォルトの内部ネットワークを使用してvServerによるExadataアプライアンスへの接続を許可する固定IPアドレス。

LDAPHOST1-DATA

bond4

192.168.10.7/255.255.240.0

IPoIB/固定

vServer7/LDAPHOST1

該当なし

デフォルトの内部ネットワークを使用してvServerによるExadataアプライアンスへの接続を許可する固定IPアドレス。

LDAPHOST2-DATA

bond4

192.168.10.8/255.255.240.0

IPoIB/固定

vServer8/LDAPHOST2

該当なし

デフォルトの内部ネットワークを使用してvServerによるExadataアプライアンスへの接続を許可する固定IPアドレス。

IGDINTERNAL

OTD

192.168.50.1/255.255.224.0

IPoIB/浮動

vServer1/WEBHOST1

該当なし

SOAのOracle Traffic Directorフェイルオーバー・グループ

IDSTORE

OTD

192.168.50.3/255.255.224.0

IPoIB/浮動

vServer2/WEBHOST2

該当なし

LDAPのOracle Traffic Directorフェイルオーバー・グループ

ノート:

表4-1に示すIPアドレスは例にすぎません。仮想ExalogicでIPアドレスが割り当てられる方法によっては、この表に示す値をそのまま使用できない可能性が高いです。

物理Exalogic

図4-5は、物理Exalogic環境でのIdentity and Access Managementデプロイメントの標準的なネットワーク・マップを示しています。

図4-5 物理Exalogicネットワーク・マップ

図4-5の説明が続きます
「図4-5 物理Exalogicネットワーク・マップ」の説明

外部Web層を使用しない場合は、すべてのコンポーネントが内部IPoIBネットワークを使用するように構成できます。Oracle Traffic Directorは、リクエストをEoIBネットワーク上で受け取り、IPoIBネットワークを使用してWebLogicおよびLDAPに渡すように構成されます。

図4-5の要素は、表4-2に示すように定義されます。

表4-2 Exalogicの物理IPアドレスのワークシート

このガイドにおけるホスト名の例 インタフェース IPアドレス/サブネット 実際の値 タイプ ホスト バインド 詳細

IAMHOST1

bond0

192.168.10.1/255.255.224.0

IPoIB/固定

ComputNode1/IAMHOST1

該当なし

内部IPoIBネットワークを使用してIAMHOST1にアクセスします。

IAMHOST2

bond0

192.168.10.2/255.255.224.0

IPoIB/固定

ComputNode2/IAMHOST2

該当なし

内部IPoIBネットワークを使用してIAMHOST2にアクセスします。

OTDADMINVHN

bond1:1

10.10.30.1/255.255.224.0

EoIB/浮動

ComputNode1/IAMHOST1

OTD管理サーバー

手動でOTD管理サーバーをIAMHOST1からIAMHOST2に移行する場合、管理サーバーに浮動Pアドレスを使用することをお薦めします。

IADADMINVHN

bond1:2

10.10.30.2/255.255.224.0

EoIB/浮動

ComputNode2/IAMHOST1

IAMAccessDomain管理サーバー

手動で管理サーバーをIAMHOST1からIAMHOST2に移行する場合、IAMAccessDomain管理サーバーに浮動Pアドレスを使用することをお薦めします。

IGDADMINVHN

bond1:3

10.10.30.3/255.255.224.0

EoIB/浮動

ComputNode1/IAMHOST1

IAMGovernanceDomain管理サーバー

手動で管理サーバーをIAMHOST1からIAMHOST2に移行する場合、IAMGovernanceDomain管理サーバーに浮動Pアドレスを使用することをお薦めします。

WEBHOST1VHN

OTD

10.10.50.1/255.255.224.0

EoIB/浮動

ComputNode1/IAMHOST1

OTD - IAMHOST1

OTDで管理される浮動IPアドレス。これは、ロード・バランサが接続するIPアドレスです。

これは推奨しますがオプションです。

WEBHOST2VHN

OTD

10.10.50.2/255.255.224.0

EoIB/浮動

ComputNode2/IAMHOST2

OTD - IAMHOST2

OTDで管理される浮動IPアドレス。これは、ロード・バランサが接続するIPアドレスです。

これは推奨しますがオプションです。

OIMHOST1VHN1

bond0:1

192.168.30.1/255.255.240.0

IPoIB/浮動

ComputNode1/IAMHOST1

WLS_OIM1デフォルト・チャネル

IAMHOST1で最初に有効にされていると、サーバー移行によりIAMHOST2にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST2VHN1

bond0:1

192.168.30.2/255.255.240.0

       

IPoIB/浮動

ComputNode2/IAMHOST2

WLS_OIM2デフォルト・チャネル

IAMHOST2で最初に有効にされていると、サーバー移行によりIAMHOST1にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST1VHN2

bond0:2

192.168.30.3/255.255.240.0

IPoIB/浮動

ComputNode1/IAMHOST1

WLS_SOA1デフォルト・チャネル

IAMHOST1で最初に有効にされていると、サーバー移行によりIAMHOST2にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST2VHN2

bond0:2

192.168.30.4/255.255.240.0

IPoIB/浮動

ComputNode2/IAMHOST2

WLS_SOA2デフォルト・チャネル

IAMHOST2で最初に有効にされていると、サーバー移行によりIAMHOST1にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST1VHN3

bond 0:3

192.168.30.5/255.255.240.0

IPoIB/浮動

ComputeNode1/IAMHOST1

WLS_BI1デフォルト・チャネル

IAMHOST2で最初に有効にされていると、サーバー移行によりIAMHOST1にフェイルオーバーできます

サーバー全体の移行にのみ使用されます。

OIMHOST2VHN3

bond 0:3

192.168.30.6/255.255.240.0

IPoIB/浮動

ComputeNode2/IAMHOST2

WLS_BI1デフォルト・チャネル

IAMHOST1で最初に有効にされていると、サーバー移行によりIAMHOST2にフェイルオーバーできます

サーバー全体の移行にのみ使用されます。

IAMHOST1EXT

bond1

10.10.10.1/255.255.240.0

EoIB/固定

ComputNode1/IAMHOST1

該当なし

計算ノードが外部社内ネットワーク(EoIB)でアクセスすることが可能な固定IP

IAMHOST2EXT

bond1

10.10.10.2/255.255.240.0

EoIB/固定

ComputNode2/IAMHOST2

該当なし

計算ノードが外部社内ネットワーク(EoIB)でアクセスすることが可能な固定IP

IGDINTERNAL

OTD

192.168.50.1/255.255.224.0

IPoIB/浮動

ComputNode1/IAMHOST1

該当なし

SOAのOracle Traffic Directorフェイルオーバー・グループ

IDSTORE

OTD

192.168.50.3/255.255.224.0

IPoIB/浮動

ComputNode2/IAMHOST2

該当なし

LDAPのOracle Traffic Directorフェイルオーバー・グループ
外部Web層を含む物理Exalogic

図4-6は、外部Web層を含む物理Exalogic環境でのIdentity and Access Managementデプロイメントの標準的なネットワーク・マップを示しています。

図4-6 物理Exalogicネットワーク・マップ

図4-6の説明が続きます
「図4-6 物理Exalogicネットワーク・マップ」の説明

外部Web層を使用しない場合は、すべてのコンポーネントが内部IPoIBネットワークを使用するように構成できます。Oracle Traffic Directorは、リクエストをEoIBネットワーク上で受け取り、IPoIBネットワークを使用してWebLogicおよびLDAPに渡すように構成されます。

図4-6の要素は、表4-3に示すように定義されます。

表4-3 Exalogicの物理IPアドレスのワークシート

このガイドにおけるホスト名の例 インタフェース IPアドレス/サブネット 実際の値 タイプ ホスト バインド 詳細

IAMHOST1

bond0

192.168.10.1/255.255.224.0

IPoIB/固定

ComputNode1/IAMHOST1

該当なし

内部IPoIBネットワークを使用してIAMHOST1にアクセスします。

IAMHOST2

bond0

192.168.10.2/255.255.224.0

IPoIB/固定

ComputNode2/IAMHOST2

該当なし

内部IPoIBネットワークを使用してIAMHOST2にアクセスします。

OTDADMINVHN

bond1:1

10.10.30.1/255.255.224.0

EoIB/浮動

ComputNode1/IAMHOST1

OTD管理サーバー

手動でOTD管理サーバーをIAMHOST1からIAMHOST2に移行する場合、管理サーバーに浮動Pアドレスを使用することをお薦めします。

IADADMINVHN

bond1:2

10.10.30.2/255.255.224.0

EoIB/浮動

ComputNode2/IAMHOST1

IAMAccessDomain管理サーバー

手動で管理サーバーをIAMHOST1からIAMHOST2に移行する場合、IAMAccessDomain管理サーバーに浮動Pアドレスを使用することをお薦めします。

IGDADMINVHN

bond1:1

10.10.30.3/255.255.224.0

EoIB/浮動

ComputNode1/IAMHOST1

IAMGovernanceDomain管理サーバー

手動で管理サーバーをIAMHOST1からIAMHOST2に移行する場合、IAMGovernanceDomain管理サーバーに浮動Pアドレスを使用することをお薦めします。

OIMHOST1VHN1

bond1:3

10.10.30.4/255.255.240.0

EoIB/浮動

ComputNode1/IAMHOST1

WLS_OIM1デフォルト・チャネル

IAMHOST1で最初に有効にされていると、サーバー移行によりIAMHOST2にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST2VHN1

bond1:2

10.10.30.7/255.255.240.0

       

EoIB/浮動

ComputNode2/IAMHOST2

WLS_OIM2デフォルト・チャネル

IAMHOST2で最初に有効にされていると、サーバー移行によりIAMHOST1にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST1VHN2

bond1:4

10.10.30.5/255.255.240.0

EoIB/浮動

ComputNode1/IAMHOST1

WLS_SOA1デフォルト・チャネル

IAMHOST1で最初に有効にされていると、サーバー移行によりIAMHOST2にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST2VHN2

bond0:3

10.10.30.8/255.255.240.0

EoIB/浮動

ComputNode2/IAMHOST2

WLS_SOA2デフォルト・チャネル

ComputeNode3で最初に有効にされていると、サーバー移行によりIAMHOST1にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST1VHN3

bond1:5

10.10.30.6/255.255.224.0

EoIB/浮動

ComputNode1/IAMHOST1

WLS_BI1デフォルト・チャネル

IAMHOST1で最初に有効にされていると、サーバー移行によりIAMHOST2にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

OIMHOST2VHN3

bond1:4

10.10.30.9/255.255.224.0

EoIB/浮動

ComputNode2/IAMHOST2

WLS_BI1デフォルト・チャネル

IAMHOST2で最初に有効にされていると、サーバー移行によりIAMHOST1にフェイルオーバーできます。

サーバー全体の移行にのみ使用されます。

IAMHOST1-EXT

bond1

10.10.10.1/255.255.240.0

EoIB/固定

ComputNode1/IAMHOST1

該当なし

外部ロード・バランサによる計算ノードへのアクセスを許可する固定IP

IAMHOST2-EXT

bond1

10.10.10.2/255.255.240.0

EoIB/固定

ComputNode2/IAMHOST2

該当なし

外部ロード・バランサによる計算ノードへのアクセスを許可する固定IP

IDSTORE

OTD

192.168.50.3/255.255.224.0

IPoIB/浮動

ComputNode2/IAMHOST2

該当なし

Oracle Unified DirectoryのOracle Traffic Directorフェイルオーバー・グループ

Oracle Identity and Access Managementのロード・バランシング仮想サーバー名のサマリー

サーバー間にリクエストを均等に分散して高可用性を実現するには、ハードウェア・ロード・バランサが必要です。可用性を最大化するために、ハードウェア・ロード・バランサは冗長ハードウェアに存在する必要があります。ハードウェア・ロード・バランサは、一連の仮想サーバー名を認識するように構成されます。

すべてのトラフィックがEoIBネットワークを使用するようにExalogicアプライアンスを構成した場合、ロード・バランサはプラットフォーム・デプロイメントと同じ方法で構成できます。ただし、Exalogicでは、内部コンポーネント間のロード・バランシングにOracle Traffic Directorを使用することをお薦めします。

これらのサーバー名の用途の詳細は、「標準的なロード・バランサの仮想サーバー名のサマリー」を参照してください。

Oracle Identity and Access Managementデプロイメントのハードウェア・ロード・バランサは、次の仮想サーバー名を認識します。

  • login.example.com - この仮想サーバー名はすべての受信アクセス・トラフィックに使用されます。これは、ランタイムAccess ManagementコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。

    login.example.com:443

    外部Web層を使用する場合、この仮想ホストは外部Webサーバー間でリクエストを分散します。そうでない場合は、内部のOracle Traffic Directorサーバー間でリクエストを分散します。

  • prov.example.com - この仮想サーバー名はすべての受信ガバナンス・トラフィックに使用されます。これは、ランタイムAccess ManagementコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。

    prov.example.com:443

    外部Web層を使用する場合、この仮想ホストは外部Webサーバー間でリクエストを分散します。そうでない場合は、内部のOracle Traffic Directorサーバー間でリクエストを分散します。

    以前のリリースのエンタープライズ・デプロイメント・ガイドでは、login.example.comおよびprov.example.comは同じエントリ・ポイントでした。このリリースではこれらを分離できます。これによって、ロード・バランサからのルーティング機能が向上し、モジュラ・デプロイメントが実現して、将来のマルチ・データ・センター・デプロイメントが容易になります。必要な場合は、これら2つのエントリ・ポイントを結合して、IAMデプロイメントへの単一エントリ・ポイントにすることも可能です。

  • iadadmin.example.com - この仮想サーバー名は、アクセス・ドメイン内のアプリケーション層のコンポーネント間の内部通信専用であり、インターネットには公開されません。この仮想サーバーの主な用途は、Oracleモバイル・セキュリティ・マネージャへのリクエストの配信に使用されるOracle HTTP Serverとモバイル・セキュリティ・アクセス・サービスを通信可能にすること、または、この仮想サーバーを使用して、モバイル・セキュリティ・マネージャをホストするWebLogic管理対象サーバーにリクエストを直接送信することです。

    クライアントからこのURLへのトラフィックは、SSL対応ではありません。クライアントは次のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。

    iadadmin.example.com:80

    外部Webサーバーを使用しない場合、この仮想ホストは、ハードウェア・ロード・バランサではなくOracle Traffic Director上に構成できます。

  • igdadmin.example.com - この仮想サーバー名は、カバナンス・ドメイン内のアプリケーション層のコンポーネント間の内部通信専用であり、インターネットには公開されません。この仮想ホスト上でアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Control、Identity Managerシステム管理コンソールなどがあります。

    クライアントからこのURLへのトラフィックは、SSL対応ではありません。クライアントは次のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。

    igdadmin.example.com:80

    外部Webサーバーを使用しない場合、この仮想ホストは、ハードウェア・ロード・バランサではなくOracle Traffic Director上に構成できます。

  • igdinternal.example.com - この仮想サーバー名は、カバナンス・ドメイン内のアプリケーション層のコンポーネント間の内部通信専用であり、インターネットには公開されません。具体的には、Oracle Identity and Access Managementエンタープライズ・トポロジでは、このURLがOracle OIM SuiteとOracle SOA Suite両方の内部通信に使用されます。

    クライアントからこのURLへのトラフィックは、SSL対応ではありません。クライアントは次のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。

    igdinternal.example.com:7777

    外部Webサーバーを使用しない場合、この仮想ホストは、ハードウェア・ロード・バランサではなくOracle Traffic Director上に構成できます。

  • idstore.example.com - この仮想サーバー名はすべての受信アイデンティティ・ストア・トラフィックに使用されます。これは、LDAPディレクトリ・インスタンスへのアクセス・ポイントとして機能します。この仮想サーバーは、インターネットには公開されません。

    クライアントからこのURLへのトラフィックは、使用するLDAPディレクトリのタイプに応じて、SSL対応の場合とそうでない場合があります。通常、Oracle Unified Directoryの場合はSSL非対応です。クライアントは次のアドレスを使用してこのサービスにアクセスし、リクエストがLDAPインスタンスに転送されます。

    この仮想ホストは、ハードウェア・ロード・バランサではなくOracle Traffic Director上に構成されます。

  • oam.example.com:5575 - これはマルチ・データセンター・デプロイメントでのみ使用される追加のロード・バランサ仮想ホストです。この仮想ホストはリクエストをOAM管理対象サーバー上のOracle Access Management (OAM)プロキシ・ポートにルーティングします。たとえば、5575です。

親トピック: Oracle Identity and Access ManagementおよびExalogicのネットワーキング

アプリケーション層ホストの管理対象サーバーとクラスタのサマリー

アプリケーション層は、Oracle WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーをホストします。

選択したコンポーネントに応じて、Oracle Identity and Access Management用のOracle WebLogic Serverドメインは、表4-4に示すクラスタで構成されています。これらのクラスタは、アクティブ/アクティブ高可用性構成として機能します。

表4-4 管理対象サーバーとクラスタのサマリー

ドメイン クラスタ 管理対象サーバー

IAMAccessDomain

Oracle Access Manager

WLS_OAM1、WLS_OAM2

該当なし

Oracle Policy Manager

WLS_AMA1、WLS_AMA2

IAMGovernanceDomain

Oracle Identity Manager

WLS_OIM1、WLS_OIM2

該当なし

Oracle SOA Suite

WLS_SOA1、WLS_SOA2

該当なし

Oracle Web Service Manager

WLS_WSM1、WLS_WSM2

選択したコンポーネントに応じて、Oracle Identity and Access Management用のOracle WebLogic Serverドメインが、上に示すクラスタで構成されています。これらのクラスタは、アクティブ/アクティブ高可用性構成として機能します。

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて

Oracle Traffic Directorの理解

Oracle Traffic Director (OTD)は、ロード・バランサおよびWebルーターとして機能します。OTDは完全な機能を備えたWebサーバーではありませんが、Webサーバーが担う多くのタスクを実行できます。管理サーバー、インスタンスおよびファイルオーバー・グループで構成されます。

Oracle Traffic Directorのインストールおよび構成の詳細は、「エンタープライズ・デプロイメント用のOracle Traffic Directorの構成」を参照してください。

トピック:

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて

標準的なExalogicデプロイメントにおけるOracle Traffic Directorについて

Oracle Traffic Directoryを使用して、リクエストが次へロード・バランシングされます。

  • LDAP - LDAPコールを行う目的で内部サーバーがアクセスする仮想IPアドレスを管理します。

    LDAP仮想IPアドレスでリクエストを受信し、IPoIBネットワークを使用して、実行中のLDAPインスタンスにそのリクエストを渡します。

  • 内部コールバック - 内部アプリケーション・コールバックを行う目的で内部サーバーがアクセスする仮想IPアドレスを管理します。

    コールバック仮想IPアドレスでリクエストを受信し、IPoIBネットワークを使用して、適切なWeblogic管理対象サーバーにそのリクエストを渡します。

ハードウェア・ロード・バランサは、リクエストをOracle Traffic Directorに送信します。

Oracle Traffic Directorは、ロード・バランサ、および他の内部アプリケーションやLDAPへのアクセスが必要な内部アプリケーションからリクエストを受信します。Oracle Traffic Directorは、これらのリクエストを受信すると、WebLogic管理対象サーバーまたはLDAPにそのリクエストを転送します。

このガイドで説明している標準的なExalogicトポロジの詳細は、「プライマリOracle Identity and Access Management Exalogicエンタープライズ・トポロジのダイアグラム」を参照してください。

親トピック: Oracle Traffic Directorの理解

Oracle HTTP Serverを使用したデプロイメントにおけるOracle Traffic Directorについて

Oracle Traffic Directoryを使用して、リクエストが次へロード・バランシングされます。

  • LDAP - EoIBネットワークでハードウェア・ロード・バランサからHTTPリクエストを受信し、IPoIBネットワークでWebLogic管理対象サーバーにそのリクエストを転送します。

    LDAPコールを行う目的で内部サーバーがアクセスする仮想IPアドレスを管理します。

    LDAP仮想IPアドレスでリクエストを受信し、IPoIBネットワークを使用して、実行中のLDAPインスタンスにそのリクエストを渡します。

  • 内部コールバック - 内部アプリケーション・コールバックを行う目的で内部サーバーがアクセスする仮想IPアドレスを管理します。

    コールバック仮想IPアドレスでリクエストを受信し、IPoIBネットワークを使用して、適切なWeblogic管理対象サーバーにそのリクエストを渡します。

ハードウェア・ロード・バランサは、社内イーサネット・ネットワーク上のコモディティ・サーバーに配置されたOracle HTTP Server (OHS)にリクエストを送信します。次にOHSは、EoIBネットワークを使用してWebLogic Serverにリクエストを渡します。

親トピック: Oracle Traffic Directorの理解

Oracle Traffic Directorフェイルオーバー・グループについて

Oracle Traffic Directorは、IPoIBネットワーク上でLDAPおよび内部コールバックの浮動IPアドレスを管理します。フェイルオーバー・グループの作成時に、プライマリ・ノードとフェイルオーバー・ノードに使用するIPアドレスのネットマスクを指定します。障害検出にはインスタンス間のハートビートが使用されます。

フェイルオーバー・グループの作成および構成の詳細は、「仮想ホストのフェイルオーバー・グループの作成」を参照してください。

親トピック: Oracle Traffic Directorの理解

Oracle Traffic Directorとロード・バランサについて

ロード・バランサは、Oracle Traffic Directorインスタンスを指すように構成できます。ただし、ロード・バランサの障害検出はOTDフェイルオーバー・グループを使用する方法よりも時間がかかります。そのため、各Oracle Traffic Directorインスタンスに外部フェイルオーバー・グループを作成し、そのフェイルオーバー・グループを指すようにロード・バランサを設定することをお薦めします。

親トピック: Oracle Traffic Directorの理解

Oracle Traffic DirectorとIdentity and Access Managementについて

Oracle Traffic Directorには独自のWebゲートがあり、これを認証に使用します。Webゲートのインストールと構成が完了すると、Oracle Traffic Directorはコンソールのリクエストをインターセプトし、検証のためにAccess Managerに転送します。

Infinibandネットワークを効率的に使用するため、内部コールバックはフェイルオーバー・グループに戻ります。

親トピック: Oracle Traffic Directorの理解

WebLogicのためのExalogic最適化について

Exalogicは、WebLogic用に次の最適化を備えています。

ドメイン・レベル:

  • WebLogicドメインのチェック・ボックス

  • ネットワークIOの向上

  • セッション・レプリケーションの効率性の向上

  • 自己チューニング・スレッド・プール

クラスタ・レベル:

ネットワーク・スループットを改善するために、カスタム・ネットワーク・レプリケーション・チャネルを作成します。

Exalogic最適化の詳細および手順は、『Oracle Exalogic Elastic CloudのためのWebLogic Serverの管理』のExalogic Elastic CloudソフトウェアのWebLogic Serverドメインの最適化に関する項を参照してください。

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて

プライマリOracle Identity and Access Managementトポロジの実装のロードマップ

表4-5に、ExalogicでのプライマリIAM Suiteトポロジの実装のロードマップを示します。

表4-5 ExalogicでのプライマリIAM Suiteトポロジの実装のロードマップ

タスク 詳細の参照先

プライマリExalogicエンタープライズ・トポロジの確認。

IAM Exalogicエンタープライズ・デプロイメントについて

ハードウェアおよびソフトウェアの要件の確認、およびエンタープライズ・デプロイメント用のリソースの取得。

エンタープライズ・デプロイメント用のリソースの取得

ロード・バランサとファイアウォールの準備。

エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

記憶域の準備、およびディレクトリ構造の理解。

エンタープライズ・デプロイメント用のファイル・システムの準備

Exalogicマシンの準備。

Oracle Identity and Access Managementデプロイメント用のExalogicの準備

ホスト・コンピュータの構成。

エンタープライズ・デプロイメント用のホスト・コンピュータの準備

データベースを準備します。

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

Oracle LDAPを構成します。

エンタープライズ・デプロイメント用のOracle LDAPの構成

Oracle Access Management用のインフラストラクチャ・ドメインの作成。

Oracle Access Managementのインフラストラクチャの作成

Oracle Identity Governnance用のインフラストラクチャ・ドメインの作成。

Oracle Identity Governanceのインフラストラクチャの作成

Oracle Traffic Directorの構成。

エンタープライズ・デプロイメント用のOracle Traffic Directorの構成

Oracle Access Managementの構成。

Oracle Access Managementの構成

Oracle Identity Governance (OIG)の構成。

Oracle Identity Governanceの構成

マルチデータ・センターの設定の構成。

マルチデータ・センターの構成

サーバー移行設定の構成。

エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

シングル・サインオン(SSO)の構成。

エンタープライズ・デプロイメント用のシングル・サインオンの構成

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて

独自のOracle Identity and Access Managementトポロジの構築

このドキュメントの「プライマリOracle Identity and Access Management Exalogicエンタープライズ・トポロジのダイアグラム」では、Oracle Identity and Access Managementの2つのプライマリ・エンタープライズ・トポロジを構成するステップを説明しています。

ただし、お客様が購入するOracle Fusion Middleware製品セットやデプロイするアプリケーションのタイプによって、組織の要件が異なる場合があります。

多くの場合、代替トポロジ(追加コンポーネントを含むトポロジ、またはプライマリ・トポロジ・ダイアグラムに示したOracle Identity and Access Management製品の一部を含まないトポロジ)のインストールおよび構成が可能です。

次の項では、実装可能ないくつかの代替Oracle Identity and Access Managementトポロジについて、このガイドに示した手順に多少の変更を加えて説明します。

  • 既存のディレクトリのみを含むOAM

  • 既存のディレクトリのみを含むOIM

  • モジュラ・デプロイメントに統合されたOAM/OIM

  • 既存のディレクトリと統合されたOAM/OIM

ノート:

デプロイメントは、Oracle Adaptive Access ManagerまたはOracle Privileged Account Managerを含むように拡張できます。詳細は、MAAのWebサイトを参照してください。

ノート:

このガイドで説明している環境とは異なるカスタム環境をデプロイする場合、Oracle Identity and Access Managementを手動でデプロイします。インストールおよびデプロイメントを自動化するために用意されているライフ・サイクル管理(LCM)ツールは、すべての代替トポロジをサポートしているわけではありません。

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて

カスタム・エンタープライズ・トポロジのインストールと構成について

このガイドで説明されていないトポロジを実装する場合は、トポロジに含める製品の動作保証情報、システム要件および相互運用性要件を確認してください。

トポロジがサポートされていることを確認した後、必要なコンポーネントのインストールと構成を行うためのガイドとしてこのガイドの説明を使用するか、またはOracle Fusion Middleware 11gのインストレーション・ガイドを使用して標準インストール・トポロジをインストールおよび構成し、スモール・スタート/スケール・アウト型アプローチで環境を構成できます。

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて

サービスまたはサーバー移行によるエンタープライズ・トポロジの高可用性化について

Oracle Identity Governance製品およびコンポーネントの高可用性を実現するために、このガイドでは、参照用トポロジの一部として作成するOracle Identity ManagerおよびOracle SOA Suiteのクラスタに対してOracle WebLogic Serverのサーバー全体の移行を有効にすることをお薦めします。

静的クラスタの場合、構成ウィザードの「高可用性のオプション」画面を使用して自動サービス移行を構成できます。「自動サービス移行の有効化」オプションを選択すると、自動サービス移行に必要な移行可能ターゲットの定義が構成されます。同じ画面で「JTAトランザクション・ログ永続性」オプションと「JMSサーバー永続性」オプションを使用すると、自動的にJDBCストアとして構成することができます。OIMエンタープライズ・デプロイメントで静的クラスタを構成するときには、これらのオプションを有効にすることをお薦めします。

動的クラスタの場合、移行可能ターゲットは必要ありません。自動サービス移行の一部の機能は、動的クラスタに当初から用意されているからです。構成ウィザードの「高可用性のオプション」画面は、動的クラスタでは使用しませんが、リースと永続ストアの移行ポリシーを構成するには、追加のステップが必要です。OIMエンタープライズ・デプロイメントで動的クラスタを構成するときには、これらの事後のステップを実行することをお薦めします。

詳細は、「エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用」を参照してください。

親トピック: IAM Exalogicエンタープライズ・デプロイメントについて