18 マルチデータ・センターの構成
マルチデータ・センター(MDC)は、負荷を分散する場合と、障害時リカバリに対応する場合に役立ちます。この章では、エンタープライズ・デプロイメントにマルチデータ・センターを構成するのに役立つ手順を詳細に説明します。
トピック
- マルチデータ・センターの構成時に使用する変数
この項には、マルチデータ・センターの構成時に使用する変数がリストされています。 - マルチデータ・センター・デプロイメントの構成のロードマップ
この項のロードマップには、マルチデータ・センター・デプロイメントを構成するためのステップの概要が含まれています。 - マルチデータ・センター・デプロイメント用のリソースの取得
マルチデータ・センター・エンタープライズ・デプロイメント用のリソースを取得する必要があります。 - マルチデータ・センター・デプロイメント用のロード・バランサの準備
サイト1およびサイト2で、マルチデータ・センター・エンタープライズ・デプロイメント用のローカル・ロード・バランサ構成を構成する必要があります。 - マルチデータ・センター・デプロイメント用のファイル・システムの準備
マルチデータ・センター・エンタープライズ・デプロイメント用のファイル・システムを構成する必要があります。 - マルチデータ・センター・エンタープライズ・デプロイメント用のホスト・コンピュータの準備
- マルチデータ・センター・デプロイメント用のデータベースの準備
マルチデータ・センター・エンタープライズ・デプロイメント用のデータベースを構成する必要があります。 - マルチデータ・センター・デプロイメント用のOracle LDAPの構成
マルチデータ・センター・エンタープライズ・デプロイメント用にOracle LDAPを構成する必要があります。 - マルチデータ・センター・デプロイメント用のWeb層の構成
マルチデータ・センター・エンタープライズ・デプロイメント用のWeb層を構成する必要があります。 - マルチデータ・センター・デプロイメント用のOracle Access Managementインフラストラクチャの作成
- マルチデータ・センター・デプロイメント用のOracle Access Managementの構成
マルチデータ・センター・エンタープライズ・デプロイメント用にOracle Access Managementを構成する必要があります。 - マルチデータ・センター・デプロイメント用のOracle Identity Governanceインフラストラクチャの作成
- マルチデータ・センター・デプロイメント用のOracle Identity Governanceの構成
マルチデータ・センター・エンタープライズ・デプロイメント用にOracle Identity Governanceを構成する必要があります。 - TAPエンドポイントの更新
この項では、TAPエンドポイントを更新するための手順を説明します。 - マルチデータ・センターの有効化
マルチデータ・センター・デプロイメントの構築後にマルチデータ・センターを有効にする必要があります。
上位トピック: 「エンタープライズ・ドメインの構成」
マルチデータ・センターの構成時に使用する変数
この項には、マルチデータ・センターの構成時に使用する変数がリストされています。
-
IAD_ORACLE_HOME
-
IGD_ASERVER_HOME
-
IAD_ASERVER_HOME
親トピック: マルチデータ・センターの構成
マルチデータ・センター・デプロイメントの構成のロードマップ
この項のロードマップには、マルチデータ・センター・デプロイメントを構成するためのステップの概要が含まれています。
この項で説明するマルチデータ・センター・エンタープライズ・デプロイメントの構成ステップでは、サイト1とサイト2の両方にバイナリのコピーがあると想定しています。これらのバイナリは、同じパッチ・レベル・バージョンにする必要があります。これを実現する方法として、次のものがあります。
-
サイト1およびサイト2への製品の手動インストール
-
サイト1からサイト2へのリモート・ミラー
-
T2Pをコピーして貼り付ける方法
バイナリの作成については、この章では説明しません。手動インストールのステップは、このガイドの前の章で説明しています。リモート・ミラーリングは、ストレージ・ハードウェアに提供されているメカニズムを使用して実行できます。T2Pは、次のOracle T2Pドキュメントに従って使用します。
表18-1 マルチデータ・センター・エンタープライズ・デプロイメントの構成のロードマップ
タスク | サブタスク | 説明 |
---|---|---|
サイト1でサブタスクを完了し、サイト1を構成します。 各サブタスクについては、「説明」列に記載されている各項の「サイト1」の手順に従ってください。 |
必要なリソースを取得します。 | 「マルチデータ・センター・デプロイメント用のリソースの取得」を参照してください。 |
該当なし |
ロード・バランサを準備します。 | 「マルチデータ・センター・デプロイメント用のロード・バランサの準備」を参照してください。 |
該当なし |
ファイル・システムの準備 | 「マルチデータ・センター・デプロイメント用のファイル・システムの準備」を参照してください。 |
該当なし |
ホスト・コンピュータを準備します。 | 「マルチデータ・センター・エンタープライズ・デプロイメント用のホスト・コンピュータの準備」を参照してください。 |
該当なし |
データベースを準備します。 | 「マルチデータ・センター・エンタープライズ・デプロイメント用のホスト・コンピュータの準備」を参照してください。 |
該当なし |
Oracle LDAPを構成します。 | 「マルチデータ・センター・デプロイメント用のOracle LDAPの構成」を参照してください。 |
該当なし |
Oracle HTTP Serverの構成 | 「マルチデータ・センター・デプロイメント用のWeb層の構成」を参照してください。 |
該当なし |
Oracle Access Managementのインフラストラクチャを作成します。 | 「マルチデータ・センター・デプロイメント用のOracle Access Managementインフラストラクチャの作成」を参照してください。 |
該当なし |
Oracle Access Managementの構成 | 「マルチデータ・センター・デプロイメント用のOracle Access Managementの構成」を参照してください。 |
該当なし |
Oracle Identity Governanceのインフラストラクチャを作成します。 | 「マルチデータ・センター・デプロイメント用のOracle Identity Governanceインフラストラクチャの作成」を参照してください。 |
該当なし |
Oracle Identity Governanceの構成 | 「マルチデータ・センター・デプロイメント用のOracle Identity Governanceの構成」を参照してください。 |
サイト2でサブタスクを完了し、サイト2を構成します。 各サブタスクについては、「説明」列に記載されている各項の「サイト2」の手順に従ってください。 |
必要なリソースを取得します。 | 「マルチデータ・センター・デプロイメント用のリソースの取得」を参照してください。 |
該当なし |
ロード・バランサを準備します。 | 「マルチデータ・センター・デプロイメント用のロード・バランサの準備」を参照してください。 |
該当なし |
ファイル・システムの準備 | 「マルチデータ・センター・デプロイメント用のファイル・システムの準備」を参照してください。 |
該当なし |
ホスト・コンピュータを準備します。 | 「マルチデータ・センター・エンタープライズ・デプロイメント用のホスト・コンピュータの準備」を参照してください。 |
該当なし |
データベースを準備します。 | 「マルチデータ・センター・エンタープライズ・デプロイメント用のホスト・コンピュータの準備」を参照してください。 |
該当なし |
既存のOracle LDAPディレクトリをサイト2に拡張します。 | 「マルチデータ・センター・デプロイメント用のOracle LDAPの構成」を参照してください。 |
該当なし |
Oracle HTTP Serverの構成 | 「マルチデータ・センター・デプロイメント用のWeb層の構成」を参照してください。 |
該当なし |
Oracle Access Managementのインフラストラクチャを作成します。 | 「マルチデータ・センター・デプロイメント用のOracle Access Managementインフラストラクチャの作成」を参照してください。 |
該当なし |
Oracle Access Managementの構成 | 「マルチデータ・センター・デプロイメント用のOracle Access Managementの構成」を参照してください。 |
該当なし |
Oracle Identity Governanceのインフラストラクチャを作成します。 | 「マルチデータ・センター・デプロイメント用のOracle Identity Governanceインフラストラクチャの作成」を参照してください。 |
該当なし |
サイト2を含むようにOracle Identity Governanceインストールを拡張します。 | 「マルチデータ・センター・デプロイメント用のOracle Identity Governanceの構成」を参照してください。 |
サイト1とサイト2の間でのOracle Policy Replicationを有効化します。 |
該当なし |
「マルチデータ・センターの有効化」を参照してください。 |
親トピック: マルチデータ・センターの構成
マルチデータ・センター・デプロイメント用のリソースの取得
マルチデータ・センター・エンタープライズ・デプロイメント用のリソースを取得する必要があります。
マルチデータ・センター・エンタープライズ・デプロイメント用のリソースを取得する手順は、「エンタープライズ・デプロイメント用のリソースの取得」で説明されている手順と同じですが、次の追加の考慮事項があります。
サイト1
仮想IPアドレスの割当て時に、次のことを確認する必要があります。
-
サイト1のOracle Access Managementドメイン用に、仮想IPアドレスが1つ必要です。
-
Oracle Identity Managerドメインに使用する仮想IPアドレスは、サイト1が使用不可能になったらサイト2に移動可能であることが必要です。これにより、必要に応じて管理サーバーをサイト2で起動できるようになります。
サイト2
仮想IPアドレスの割当て時に、次のことを確認する必要があります。
-
サイト2のOracle Access Managementドメイン用に、仮想IPアドレスが1つ必要です。
-
Oracle Identity Managerドメインに使用する仮想IPアドレスは、サイト2が使用可能になったらサイト1から移動可能であることが必要です。これにより、必要に応じて管理サーバーをサイト1で起動できるようになります。
親トピック: マルチデータ・センターの構成
マルチデータ・センター・デプロイメントのロード・バランサの準備
サイト1およびサイト2で、マルチデータ・センター・エンタープライズ・デプロイメント用のローカル・ロード・バランサ構成を構成する必要があります。
マルチデータ・センター・エンタープライズ・デプロイメント用のロード・バランサを準備する手順は、「エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備」で説明されている手順と同じですが、次の追加の考慮事項があります。
サイト1
マルチデータ・センター・エンタープライズ・デプロイメントのサイト1のローカル・ロード・バランサ構成では、次のパラメータが異なります。
-
サイト内に構成されているロード・バランサ仮想サーバーでは、メイン・エントリ・ポイント(
idstore.example.com
、igdinternal.example.com
、prov.example.com
およびlogin.example.com
)は使用されず、ローカル・バリアントが使用されます。これらのエントリの名前は、ロード・バランサ構成以外では使用されません(たとえば、login1.example.com
およびprov2.example.com
などの名前になります)
-
Iadamin.example.com
は、デプロイメントに対して一意になります(iadadmin1.example.com
など)。
-
oam1.example.com
という名前の新しいロード・バランサ・エントリ・ポイントが定義され、これにはサイト1のOracle Access Management (OAM)管理対象サーバーが含まれます。
-
oam.example.com
という名前のグローバル・ロード・バランサ仮想ホストが作成され、これはローカル・ロード・バランサ仮想ホストoam1.example.com
にリクエストを渡します。
-
メイン・アプリケーション・エントリ・ポイント(
idstore.example.com
、login.example.com
、prov.example.com
およびigdinternal.example.com
)が、グローバル・ロード・バランサの一部として構成されます。次に、これらのエントリ・ポイントは、ローカル・ロード・バランサ仮想ホストにリクエストを渡します。たとえば、prov.example.com
はリクエストをprov1.example.com
に転送します。
サイト2
マルチデータ・センター・エンタープライズ・デプロイメントのサイト2のローカル・ロード・バランサ構成では、次のパラメータが異なります。
-
サイト内に構成されているロード・バランサ仮想サーバーでは、メイン・エントリ・ポイント(
prov.example.com
およびlogin.example.com
)は使用されず、ローカル・バリアントが使用されます。これらのエントリの名前は、ロード・バランサ構成以外では使用されません(たとえば、login2.example.com
およびprov2.example.com
などの名前になります)
-
Iadamin.example.com
は、デプロイメントに対して一意になります(iadadmin2.example.com
など)。
-
oam2.example.com
という名前の新しいロード・バランサ・エントリ・ポイントが定義され、これにはサイト2のOracle Access Management (OAM)管理対象サーバーが含まれます。
-
ローカル・ロード・バランサ仮想ホスト
oam2.example.com
がoam.example.com
のグローバル・ロード・バランサ定義に追加されます。サイト1で発生した呼出しがoam1.example.com
に送信され、サイト2で発生した呼出しがoam2.example.com
に送信されるように、地理ルールが設定されます。呼出しのターゲットが使用不可である場合は、それらの呼出しを使用可能ないずれかのサイトに転送できます。
-
ローカル・ロード・バランサ仮想ホスト
idstore2.example.com
、igdinternal2.example.com
、prov2.example.com
およびlogin2.example.com
が対応するグローバル・ロード・バランサ定義に追加され、次のことを確認するために地理ルールが設定されます。-
特定のサイトから発生した内部トラフィックが、そのサイトが使用可能な場合には、そのサイトに戻るように送信されること。サイトが使用可能でない場合、内部トラフィックは別のサイトに転送されます。
-
パブリック・トラフィックが、地理的な場所が最も近いローカル・ロード・バランサに送信されること。
-
親トピック: マルチデータ・センターの構成
マルチデータ・センター・デプロイメント用のファイル・システムの準備
マルチデータ・センター・エンタープライズ・デプロイメント用のファイル・システムを構成する必要があります。
マルチデータ・センター・エンタープライズ・デプロイメント用のファイル・システムを準備する手順は、「エンタープライズ・デプロイメント用のファイル・システムの準備」で説明されている手順と同じですが、次の追加の考慮事項があります。
サイト1
マルチデータ・センター・エンタープライズ・デプロイメントのサイト1のファイル・システム構成では、次のパラメータが異なります。
-
両方のサイトのソフトウェア・バージョンをまったく同一にする必要がなくなるよう、オプションでバイナリをサイト2にミラーリングできます。この場合、この章で説明するように、少なくとも2つのバージョンのバイナリを使用することが重要です。
-
IAD_ASERVER_HOMEがサイト1に対してローカルに構成されます。
-
必要に応じてガバナンス管理サーバーをサイト2で起動できるように、IAD_ASERVER_HOMEがサイト2にミラーリングされます。
-
サーバー全体の移行のためにファイル・システムを使用している場合、サイト2へのミラーリングが必要になります。
サイト2
マルチデータ・センター・エンタープライズ・デプロイメントのサイト2のファイル・システム構成では、次のパラメータが異なります。
-
両方のサイトのソフトウェア・バージョンをまったく同一にする必要がなくなるよう、オプションでバイナリをサイト1にミラーリングできます。この場合、この章で説明するように、少なくとも2つのバージョンのバイナリを使用することが重要です。
-
IGD_ASERVER_HOMEがサイト2に対してローカルに構成されます。
-
必要に応じてガバナンス管理サーバーをサイト2で起動できるように、IGD_ASERVER_HOMEがサイト1にミラーリングされます。
-
サーバー全体の移行にファイル・システムを使用している場合は、サイト1へのミラーリングが必要になります。
親トピック: マルチデータ・センターの構成
マルチデータ・センター・エンタープライズ・デプロイメント用のホスト・コンピュータの準備
マルチデータ・センター・エンタープライズ・デプロイメント用のホスト・コンピュータを準備する手順は、「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で説明されている手順と同じです。
親トピック: マルチデータ・センターの構成
マルチデータ・センター・デプロイメント用のデータベースの準備
マルチデータ・センター・エンタープライズ・デプロイメント用のデータベースを構成する必要があります。
マルチデータ・センター・エンタープライズ・デプロイメント用のデータベースを準備する手順は、「エンタープライズ・デプロイメント用のデータベースの準備」で説明されている手順と同じですが、次の追加の考慮事項があります。
サイト1
サイト1に対してマルチデータ・センター・エンタープライズ・デプロイメント用のデータベースを設定する際は、次の点に注意してください。
-
サイト1のOracle Access Management (OAM)用に専用のデータベースが使用されます。
-
サイト1のOracle Identity Governance (OIG)用に専用のデータベースが使用されます。
-
OIGにはロールベースのデータベース・サービスを使用する必要があります。
サイト2
サイト2に対してマルチデータ・センター・エンタープライズ・デプロイメント用のデータベースを設定する際は、次の点に注意してください。
-
サイト2のOracle Access Management (OAM)用に専用のデータベースが使用されます。
-
Data Guardを使用して、Oracle Identity Governance (OIG)データベースがサイト2にレプリケートされます
-
OIGにはロールベースのデータベース・サービスを使用する必要があり、サイト1とサイト2の両方にロールベースのデータベース・サービスが構成されている必要があります。
親トピック: マルチデータ・センターの構成
マルチデータ・センター・デプロイメント用のOracle LDAPの構成
マルチデータ・センター・エンタープライズ・デプロイメント用にOracle LDAPを構成する必要があります。
次の各項では、サイト1およびサイト2のマルチデータ・センター・エンタープライズ・デプロイメント用のOracle LDAP構成について説明します。
サイト1
「エンタープライズ・デプロイメント用のOracle LDAPの構成」の説明に従って、サイト1でLDAPを構成します。
サイト2
-
Oracle Unified Directory (OUD)の場合は、次のタスクを完了します。
親トピック: マルチデータ・センターの構成
マルチデータ・センター・デプロイメント用のWeb層の構成
マルチデータ・センター・エンタープライズ・デプロイメント用のWeb層を構成する必要があります。
(エンタープライズ・デプロイメント用のOracle HTTP Serverの構成の説明に従って) Oracle HTTP Serverを構成しますが、次の追加の考慮事項があります:
サイト1
サイト1に対してマルチデータ・センター・エンタープライズ・デプロイメント用のWeb層を構成する際は、次の点に注意してください。
-
仮想ホスト(Oracle HTTP ServerまたはOracle Internet Directory)を作成する際には、ローカル・バリアントではなくメイン・エントリ・ポイント(
prov.example.com
、login.example.com
およびigdinternal.example.com
)を使用します。
-
iadadmin.example.com
エントリ・ポイントには、Iadadmin1.example.com
を使用する必要があります。サイト1のOracle Access Management (OAM)ドメインの管理には、常にIadadmin1.example.com
が使用されます。
-
オプションで、仮想ホスト定義に、サイト2のWeblogicクラスタ・メンバーを含めます。サイト1の管理対象サーバーが停止しても、サイト1のWeb層が機能していれば、サイト1はリクエストをサイト2の管理対象サーバーに転送できます。このユース・ケースに問題はありませんが、多くの場合、トラフィックがサイト間をバウンスするのを防ぐため、管理対象サーバーにリクエストを転送するのは好ましくありません。サイト間でトラフィックをバウンスさせない場合は、Oracle HTTP ServerのディレクティブDynamicServerList OFFを追加する必要があります。
# OIM Self Service
<Location/Identity>
SetHandler webLogic-handler
WebLogicCluster PMHOST1.example.com:14000, OIMHOST2.example.com:14000
DynamicServerList OFF
</Location
サイト2
サイト2に対してマルチデータ・センター・エンタープライズ・デプロイメント用のWeb層を構成する際は、次の点に注意してください。
-
仮想ホスト(Oracle HTTP ServerまたはOracle Internet Directory)を作成する際には、ローカル・バリアントではなくメイン・エントリ・ポイント(
prov.example.com
、login.example.com
およびigdinternal.example.com
)を使用します。
-
iadadmin.example.com
エントリ・ポイントには、Iadadmin2.example.com
を使用する必要があります。サイト2のOracle Access Management (OAM)ドメインの管理には、常にIadadmin2.example.com
が使用されます。
-
オプションで、仮想ホスト定義に、サイト2のWeblogicクラスタ・メンバーを含めます。サイト1の管理対象サーバーが停止しても、サイト1のWeb層が機能していれば、サイト1はリクエストをサイト2の管理対象サーバーに転送できます。このユース・ケースに問題はありませんが、多くの場合、トラフィックがサイト間をバウンスするのを防ぐため、管理対象サーバーにリクエストを転送するのは好ましくありません。サイト間でトラフィックをバウンスさせない場合は、Oracle HTTP ServerのディレクティブDynamicServerList OFFを追加する必要があります。
# OIM Self Service
<Location/Identity>
SetHandler webLogic-handler
WebLogicCluster OIMHOST3.example.com:14000, OIMHOST2.example.com:14000
DynamicServerList OFF
</Location
OIMと動的クラスタを使用している場合、ポート番号はサイト1のポート番号の増分になることに留意してください。たとえば、サイト1 (14000, 14001)、サイト2 (14002, 14003)のようになります。
親トピック: マルチデータ・センターの構成
マルチデータ・センター・デプロイメント用のOracle Access Managementインフラストラクチャの作成
サイト1およびサイト2に対するマルチデータ・センター・エンタープライズ・デプロイメント用のOracle Access Managementインフラストラクチャの作成は、「Oracle Access Managementのインフラストラクチャの作成」で説明されている標準EDGプロセスと同じです。
親トピック: マルチデータ・センターの構成
マルチデータ・センター・デプロイメント用のOracle Access Managementの構成
マルチデータ・センター・エンタープライズ・デプロイメント用にOracle Access Managementを構成する必要があります。
マルチデータ・センター・エンタープライズ・デプロイメント用にOracle Access Managementを構成する手順は、「Oracle Access Managementの構成」で説明されている手順と同じですが、次の追加の考慮事項があります。
サイト1
OAMの構成後、次のタスクを完了します。
-
ロード・バランサのサーバー・インスタンスを作成します
OAMの初期構成時に、各管理対象サーバーに対していくつかのOAMサーバー・インスタンスが作成されています。これらのサーバー・インスタンスは、OAM NAPコールの送信先を決定するために使用されます。マルチデータ・センター・デプロイメントでは、ロード・バランサのエントリ・ポイント
oam.example.com
用に追加のサーバー・インスタンスを作成する必要があります。サーバー・インスタンスの作成方法の詳細は、「ロード・バランサ用の追加のサーバー・インスタンスの作成」を参照してください。 -
ロード・バランサを使用するようにWebゲート・エージェントを更新します
指定されたサーバー名ではなくロード・バランサ・エントリ
oam.example.com
を使用するように、Webゲート・エージェントを更新します。Webゲート・エージェントの更新方法の詳細は、「ロード・バランサを使用するためのWebゲート・エージェントの更新」を参照してください
サイト2
サイト2に対するOAMの構成は、サイト1に対する構成で説明した手順と似ています。ロード・バランサのエントリ・ポイントを使用するためのWebゲート・エージェントの更新は、ポリシー同期によって処理されます。
- ロード・バランサ用の追加のサーバー・インスタンスの作成
マルチデータ・センター・エンタープライズ・デプロイメントでは、ロード・バランサのエントリ・ポイント用に追加のサーバー・インスタンスを作成する必要があります。 - ロード・バランサを使用するためのWebゲート・エージェントの更新
マルチデータ・センター・エンタープライズ・デプロイメントでは、ロード・バランサのエントリ・ポイント用にWebゲート・エージェントを更新する必要があります。
親トピック: マルチデータ・センターの構成
ロード・バランサ用の追加のサーバー・インスタンスの作成
マルチデータ・センター・エンタープライズ・デプロイメントでは、ロード・バランサのエントリ・ポイント用に追加のサーバー・インスタンスを作成する必要があります。
ロード・バランサを使用するためのWebゲート・エージェントの更新
マルチデータ・センター・エンタープライズ・デプロイメントでは、ロード・バランサのエントリ・ポイント用にWebゲート・エージェントを更新する必要があります。
- エージェント名をクリックします。
- 「プライマリ・サーバー」ボックスで「追加」ボタンをクリックして新しいエージェントを作成し、アクセス・サーバーとして「oamLBR」を選択します。
- 「プライマリ・サーバー・リスト」内の他の各エントリを削除します。
- 「適用」をクリックします
- 各エージェントに対してこれらのステップを繰り返します。
マルチデータ・センター・デプロイメント用のOracle Identity Governanceインフラストラクチャの作成
サイト1およびサイト2に対してマルチデータ・センター・エンタープライズ・デプロイメント用のOracle Identity Governance (OIG)インフラストラクチャを構成する手順は、「Oracle Identity Governanceのインフラストラクチャの作成」で説明されている標準EDGプロセスとほとんど同じです。ただし、いくつかの例外があり、それらについて次の項で説明します。
親トピック: マルチデータ・センターの構成
マルチデータ・センター・デプロイメント用のOracle Identity Governanceの構成
マルチデータ・センター・エンタープライズ・デプロイメント用にOracle Identity Governanceを構成する必要があります。
マルチデータ・センター・エンタープライズ・デプロイメント用のOracle Identity Governance (OIG)の構成は、「Oracle Identity Governanceの構成」で説明されている標準EDGプロセスと同じです。これに加えて、サイト1およびサイト2に対して追加のタスクを実行します。
サイト1
サイト1でOracle Identity Governanceを構成した後、サイト1で次のタスクを実行します。
サイト2
サイト2でOracle Identity Governanceを構成した後、「Oracle Identity Managerの構成のためのOracle Identity Managerジョブ・スケジューラの無効化」の説明に従って、サイト2のOIMジョブ・スケジューラを無効にします。
- Oracle Identity Manager用の構成ウィザードの変更
- Oracle Identity Managerの構成後の変更
- Oracle Identity Managerの構成のためのOracle Identity Managerジョブ・スケジューラの無効化
親トピック: マルチデータ・センターの構成
Oracle Identity Manager用の構成ウィザードの変更
Oracle Identity Managerの構成時に、2つのサイトにまたがるクラスタを作成するために、構成ウィザードで次の内容を追加で実行する必要があります。
-
Oracle Identity Manager (OIM)クラスタ構成
構成ウィザードでIAMGovernanceDomainを作成する際、OIMおよびSOAクラスタの指定時にすべてのサーバー(サイト1およびサイト2)を含める必要があります。たとえば、
OIMHOST1.example.com
:14000、OIMHOST2.example.com
:14000、OIMHOST3.example.com:14000
、OIMHOST4.example.com
:14000です動的クラスタの場合は、サイト1およびサイト2のマシンのみを含める必要があります。
既存のデプロイメントがある場合は、標準のスケール・アップ/アウト手順で追加のクラスタ・メンバーを含めることができます。
-
JMS
すべてのOIM/SOA管理対象サーバーに対してJMSストアを作成し、データベースを使用するようにJMSを構成します。
-
データ・ソース
JMSデータ・ソースの作成時に、データベース・サービス名ではなくOIMサービス名を指定する必要があります。これは、ロールベースのデータベース・サービスになります。
Oracle Identity Managerの構成後の変更
Oracle Identity Manager (OIM)の構成時に、次の構成後の変更を行う必要があります。
-
OIMデータ・ソースの更新
OIMドメインが作成されたときに、
oim.example.com
データベース・サービスを使用するいくつかのデータ・ソースが作成されています。これらのサービスはすべて、プライマリOIMデータベースを指します。シームレスなフェイルオーバーが行われるよう、データ・ソース構成にスタンバイ・データベースを追加する必要があります。プライマリ・データベースとスタンバイ・データベースの両方を含む一般的なデータベース接続は、次のようになります。jdbc:oracle:thin:@ (DESCRIPTION_LIST=(LOAD_BALANCE=OFF)(FAILOVER=ON)(DESCRIPTION=(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=iagdb-scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=oim.example.com)))(DESCRIPTION=(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=iagdbdg-scan.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=oim.example.com))))
これらのデータ・ソースを変更する必要があります。データ・ソースの変更方法の詳細は、「Oracle Identity Managerの構成のためのOracle Identity Managerデータ・ソースの変更」を参照してください
-
Java仮想マシン・プロセス・ステータス・ツール(JPS)セキュリティ・ファイルの更新
Weblogicデータ・ソースの更新に加え、IGD_ASERVER_HOME/config/fmwconfigディレクトリにあるjps-config.xmlおよびjps-config-jse.xmlファイル内のデータ・ソース情報も更新する必要があります。
ノート:
編集する前に、これらのファイルをバックアップしておく必要があります。
Oracle Identity Managerの構成のためのOracle Identity Managerジョブ・スケジューラの無効化
Oracle Identity Managerを構成するために、サイト2のOracle Identity Managerジョブ・スケジューラを無効にする必要があります。
OIMジョブ・スケジューラは、データベースを大量に使用します。サイト間のトラフィックを最小限に保つために、データベースがプライマリではないサイトのジョブ・スケジューラを無効にする必要があります。このステップは、サイト2のOIM管理対象サーバーを停止する予定である場合には必要ありません。
サーバー起動引数に次のパラメータを追加することにより、ジョブ・スケジューラが無効になります。
-Dscheduler.disabled=true
ジョブ・スケジューラを無効化する方法の詳細は、「Oracle Identity Managerの構成のためにジョブ・スケジューラを無効化するためのパラメータの追加」を参照してください
TAPエンドポイントの更新
この項では、TAPエンドポイントを更新するための手順を説明します。
Oracle Identity Governanceの構成を開始する前にOAM MDCを構成した場合は、このステップは必要ありません。既存のOAMをマルチデータ・センターに変換している場合は、新しいOAMエントリ・ポイントを反映させるために、OIMのTAPエンドポイントを更新する必要があります。
親トピック: マルチデータ・センターの構成
マルチデータ・センターの有効化
マルチデータ・センター・デプロイメントの構築後にマルチデータ・センターを有効にする必要があります。
次のステップを実行して、マルチデータ・センターを有効化できます。前述のステップについては、次の項を参照してください。
プライマリ・データ・センターの設定
プライマリ・データ・センターを設定するには、MDC ADMIN REST APIを使用してプライマリ・データ・センターを構成する必要があります。
プライマリ・データ・センターを構成するには、適切な値を使用して次のコマンドを実行します。
curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST 'http://MasterServerURL/oam/services/rest/mdc/master' -d '{"mdcTopologyType":"value", "masterMDCAgentID":"value","cloneMDCAgentID":"value", "accessClientPassword":"value","artifactPassword":"value","cloneServerURL":"value","agentKeyPassword":"value","certModeKeystorePassword":"value","masterServerURL":"value", "cloneAdminUserNamePassword":"value","trustStorePath":"value", "keyStorePath":"value", "artifactsZipLocation":"value"}'
次の表に、Curlコマンドの値を示します。
表18-2 プライマリ・データ・センターの構成
値 | 説明 |
---|---|
-u | OAM管理ユーザーのユーザー名とパスワード。たとえば: iamadmin |
MasterServerURL | プライマリとして指定しているOAMドメインのURL。たとえば: http://iadadmin1.example.com/oam/services/rest/mdc/master |
mdcTopologyType | MDC構成で使用できる2つのトポロジ・タイプ(ACTIVE_ACTIVEまたはDISASTER_RECOVERY)。この場合は、ACTIVE_ACTIVEを選択します。 |
masterMDCAgentID | プライマリ・データ・センターのMDC NAPエージェント名。たとえば、Site1と入力します |
cloneMDCAgentID | クローン・データ・センターのMDC NAPエージェント名。たとえば、Site2と入力します |
accessClientPassword | プライマリおよびクローン・データ・センターでMDC NAPエージェントが使用するために必要なパスワード |
artifactPassword | クローニング・アーティファクトの保護に使用するパスワード |
cloneServerURL | プライマリ管理サーバーのURLまたはプライマリ管理サーバーのフロント・エンドとなっているリバース・プロキシのURL。たとえば、http://iamadmin1.example.com/と入力します |
masterServerURL | プライマリ管理サーバーのURLまたはプライマリ管理サーバーのフロント・エンドとなっているリバース・プロキシのURL。たとえば、http://iamadmin1.example.com/と入力します |
cloneAdminUserNamePassword | クローン・データ・センターのIAM管理者のユーザー資格証明(プライマリ・データ・センターとクローン・データ・センターの管理者のユーザー名およびパスワードが異なる場合)。たとえば、iamadminと入力します |
trustStorePath | oamclient-truststore.jksファイルへのパス。例: IAD_ASERVER_HOME/output/webgate-ssl-SHA-256/ |
keyStorePath | oamclient-keystore.jksファイルへのパス。例: IAD_ASERVER_HOME/output/webgate-ssl-SHA-256/ |
artifactsZipLocation | クローニング・アーティファクトを格納する場所。クローニング・アーティファクトを/tmp以外の場所に格納する必要がある場合にのみ指定します。たとえばSHARED_CONFIG_DIR/mdc |
ノート:
Curlコマンドを実行する前に、artifactsZipLocationに指定した場所がすでに存在していることを確認してください。
プライマリ・データ・センターを構成するためのサンプルCurlコマンドは、次のとおりです:
curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST 'http://iadadmin1.example.com/oam/services/rest/mdc/master' -d '{"mdcTopologyType":"ACTIVE_ACTIVE", "masterMDCAgentID":"site1Agent","cloneMDCAgentID":"site2Agent", "accessClientPassword":"password","artifactPassword":"password","cloneServerURL":"http://iadadmin2.example.com","agentKeyPassword":"password","certModeKeystorePassword":"password","masterServerURL":"http://iadadmin1.example.com", "cloneAdminUserNamePassword":"password","trustStorePath":"/u01/oracle/config/domains/IAMAccessDomain/output/webgate-ssl-SHA-256", "keyStorePath":"":"/u01/oracle/config/domains/IAMAccessDomain/output/webgate-ssl-SHA-256", "artifactsZipLocation":"/u01/oracle/config/mdc"}'
このコマンドを実行すると、OAMコンソールにsite1Agentおよびsite2Agentという名前の2つの新しいエージェントが作成されます。「ロード・バランサを使用するためのWebゲート・エージェントの更新」の項に記載されているステップに従って、これらのエージェントがOAMのロード・バランサ・エントリを参照していることを確認します。
親トピック: マルチデータ・センターの有効化
クローン・データ・センターの設定
クローン・データ・センターを設定するには、次のようにMDC ADMIN REST APIを使用して、マルチデータ・センター(MDC)環境用のクローン・データ・センターを構成する必要があります。
クローン・データ・センターを構成するには、適切な値を使用して次のコマンドを実行します。
curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST 'http://CloneServerURL/oam/services/rest/mdc/clone' -d '{"masterServerURL":"value","artifactPassword":"value","masterAdminUserNamePassword":"value", "artifactsZipLocation":"value", "masterArtifactsZipLocation":"value"}'
次の表に、Curlコマンドの値を示します。
表18-3 クローン・データ・センターのプロパティ
値 | 説明 |
---|---|
-u | OAM管理ユーザーのユーザー名とパスワード。たとえば: iamadmin |
CloneServerURL | クローンとして指定しているOAMドメインのURL。たとえば: http://iadadmin2.example.com/oam/services/rest/mdc/clone |
masterServerURL | プライマリ管理サーバーのURLまたはプライマリ管理サーバーのフロント・エンドとなっているリバース・プロキシのURL。たとえば、http://iamadmin.example.com/と入力します |
artifactPassword | クローニング・アーティファクトを保護する、プライマリ・データ・センターの設定時に使用されたものと同じパスワード |
masterAdminUserNamePassword | プライマリ・データ・センターのIAM管理者のユーザー資格証明 |
artifactsZipLocation | クローニング・アーティファクトを格納する場所。クローニング・アーティファクトを/tmp以外の場所に格納する必要がある場合にのみ指定します。たとえばSHARED_CONFIG_DIR/mdc |
ノート:
Curlコマンドを実行する前に、artifactsZipLocationに指定した場所がクローン管理サーバー・マシンにすでに存在していることを確認してください。
クローン・データ・センターを構成するためのサンプルCurlコマンドは、次のとおりです。
curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST 'http://iadadmin2.example.com/oam/services/rest/mdc/clone/configuration'
マルチデータ・センター・デプロイメントでは、「プライマリ・データ・センターの設定」の項で説明しているように、プライマリ・サイトとして指定されている1つのサイトのみがポリシーの作成に責任を持ちます。クローン・サイトへの誤った書込みを防ぐために、クローン・サイトを読取り専用モードにする必要があります。
クローン・サイトをクローン・サイトで読取り専用モードにするには、次の手順を実行します。
IAD_ORACLE_HOME/oracle_common/common/bin/wlst.sh
connect('weblogic','password','t3://iadadmminvhn2.example.com:7001')
domainRuntime()
setMultiDataCenterWrite(WriteEnabledFlag="true")
exit()
クローン・データ・センターを設定した後、サイト1およびサイト2に対してドメインを再起動して構成を検証する必要があります。
詳細は、次のトピックを参照してください。
ドメインの再起動
クローン・データ・センターを設定した後、サイト1およびサイト2に対してドメインを再起動する必要があります。
サイト1およびサイト2のドメインを再起動するには、次の手順を実行します。
-
サイト1の管理サーバーと管理対象サーバーを停止します。
-
サイト2の管理サーバーと管理対象サーバーを停止します。
-
サイト1の管理サーバーと管理対象サーバーを起動します。
-
サイト2の管理サーバーと管理対象サーバーを起動します。
親トピック: クローン・データ・センターの設定
クローン・データ・センターの構成の検証
クローン・データ・センターを設定した後、サイト1およびサイト2に対してクローン・データ・センターの構成を検証する必要があります。
構成を検証するには、次のコマンドを実行します。
curl -k -u oamadmin:XXXX 'http://SiteURL/oam/services/rest/mdc/configuration'
サイト1に対するコマンドは、次のとおりです。
curl -k -u oamadmin:password “http://iadadmin1.example.com/oam/services/rest/mdc/configuration”
サイト1に対するコマンドは、次のとおりです。
curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST “http://iadadmin2.example.com/oam/services/rest/mdc/configuration”
親トピック: クローン・データ・センターの設定
レプリケーションの有効化
構成をマルチデータ・センター・モードにした後、データ同期を設定する必要があります。この設定により、プライマリ・サイトに追加されたすべての情報が確実にクローン・サイトに伝播されるようになります。
設定は、次のような2段階のプロセスです。
-
プライマリ・サイトからクローン・サイトへのバルク・データ・アンロードを実行するには
-
後続の変更を自動的に伝播するためのレプリケーション承諾の作成
詳細は、次のトピックを参照してください。
プライマリ・サイトからクローン・サイトへのバルク・データ・アンロードの実行
プライマリ・サイトからクローン・サイトへのバルク・データ・アンロードを実行するには、クローンをプライマリ・サイトのデータでリフレッシュする必要がありますが、これはプライマリからアクセス・ストアをエクスポートしてクローンにインポートすることで実行できます。
プライマリ・サイトのデータでクローンをリフレッシュするには、プライマリ・ノードで次のコマンドを発行します:
IAD_ORACLE_HOME/oracle_common/common/bin/wlst.sh
connect('weblogic','password','t3://iadadmin1vhn.example.com:7001')
exportAccessStore(toFile=”filelocation/oamaccess.zip",namePath="/")
exit()
ノート:
実行するコマンドに対して、ファイルの場所が存在している必要があります。
生成されたファイルをクローン管理サーバー・ホストにコピーします。
プライマリ・サイトのデータでクローンをリフレッシュするには、クローン・ノードで次のコマンドを発行します:
IAD_ORACLE_HOME/oracle_common/common/bin/wlst.sh
connect('weblogic','password','t3://iadadmin1vhn.example.com:7001')
importAccessStore(toFile=”filelocation/oamaccess.zip",namePath="/")
exit()
親トピック: レプリケーションの有効化
レプリケーション承諾の作成
このプロセスの最終ステップは、プライマリ・サイトとクローン・サイト間にレプリケーション承諾を設定することです。ただし、レプリケーション承諾を作成する前に、次に示すプロセスを実行することをお薦めします。これらのプロセスについては、次の各項で説明します。
プライマリ・サイトとクローン・サイト間にレプリケーション承諾を設定するには、次のコマンドを実行します:
curl -k -u oamadmin:password -H 'Content-Type: application/json' -X POST 'http://masterSiteURL/oam/services/rest/_replication/setup' -d '{"name":”agreementName”,"source":”masterClusterName”,"target":”cloneClusterName”,"documentType":"ENTITY","config": {"entry":{"key":"authorization","value":”Basic encodedUser” }}}'
次の表に、Curlコマンドの値を示します。
表18-4 Curlコマンドの値
値 | 説明 |
---|---|
-u | OAM管理ユーザーのユーザー名とパスワード。たとえば: iamadmin |
masterSiteURL | プライマリとして指定しているOAMドメインのURL (たとえば: http://iadadmin1.example.com/ oam/services/rest/_replication/setup) |
agreementName | 承諾の任意の名前。たとえば: Site1toSite2 |
masterClusterName | 「MDCクラスタ名の取得」で取得したプライマリ・サイト・クラスタの名前 |
clonerClusterName | 「MDCクラスタ名の取得」で取得したクラスタ・サイト・クラスタの名前 |
encodedUser | 「iammadminユーザーのエンコーディング」で取得したエンコードされたiamadminユーザー文字列 |
レプリケーション承諾を作成するためのサンプルCurlコマンドは、次のとおりです
curl -k -u iamadmin:password -H 'Content-Type: application/json' -X POST 'http://iadadmin1.example.com/oam/services/rest/_replication/setup' -d '{"name":"Site1toSite2","source":"0c04b-OAMHOST1.u","target":"0c04b-OAMHOST2.u","documentType":"ENTITY","config": {"entry":{"key":"authorization","value":"Basic aWFtYWRtaW46UGFzc3dvcmQxr" }}}'
レプリケーションが成功すると、次のような出力が生成されます。
{"enabled":true,"identifier":"201709071449437364","lastSequenceNumber":878,"ok":true,"pollInterval":900,"startingSequenceNumber":878,"state":"READY"}
ノート:
POLLINTERVALは900秒(15分)です。このため、プライマリDCに対して行われた変更がクローンDCに伝播されるまで15分かかります。ポーリング間隔が長すぎる場合は、クローンDCでポーリング間隔を変更できます。
クローンDCでポーリング間隔を変更するには、次の手順を実行します。
-
次のコマンドを使用して既存のレプリケーション承諾に問合せを送信し、レプリケーション識別子(replId)を取得します。
curl -k -u oamadmin:password 'http://iadadmin1.example.com/oam/services/rest/_replication/agreements'
複数の承諾が存在する場合は、対応するクローン・データ・センターで同じコマンドを実行して、APSを無効にする必要のある識別子を選択します。
-
クローンDCでポーリング間隔を変更するには、次のコマンドを実行します。
curl -u weblogic:password -H 'Content-Type: application/json' -X PUT 'http://iamadmin1.example.com/oam/services/rest/_replication/replicationAgreement' -d '{"pollInterval":PollInterval,"replicaType":"CONSUMER"}'
説明-
replicationAgreementはステップ1で取得した値です
-
Pollintervalは新しいポーリング間隔(秒単位)です
-
レプリケーション・エンド・ポイントの検証
レプリケーション承諾を作成する前に、レプリケーションを容易にするRESTエンドポイントが、プライマリ・サイトとクローン・サイトの両方で機能していることを確認することをお薦めします。これらのエンド・ポイントが機能していないと、レプリケーション承諾を作成できなくなります。
レプリケーション・エンド・ポイントを検証するには、次のコマンドを発行する必要があります。
curl -u oamadmin:password 'http://SiteURL/oam/services/rest/_replication/hello'
レプリケーション・エンド・ポイントを検証するためのサンプルCurlコマンドは、次のとおりです。
curl -u oamadmin:password 'http://iadadmin1.example.com/oam/services/rest/_replication/hello'
curl -u oamadmin:password 'http:// iadadmin2.example.com /oam/services/rest/_replication/hello'
親トピック: レプリケーション承諾の作成
マルチデータ・センター・クラスタ名の取得
マルチデータ・センター・デプロイメントにおける各サイトには一意のクラスタ名があり、これはレプリケーション承諾の作成時に必要となります。
各サイトのクラスタ名を特定するには、次のコマンドを使用して既存の構成を問い合せます。
curl -k -u oamadmin:password 'http://siteURL/oam/services/rest/mdc/dc/configuration
マルチデータ・センター・クラスタ名を取得するためのサンプルCurlコマンドは、次のとおりです。
curl -k -u oamadmin:password 'http://iadadmin1.example.com/oam/services/rest/mdc/dc/configuration
curl -k -u oamadmin:password 'http://iadadmin2.example.com/oam/services/rest/mdc/dc/configuration
{"ok":true,"status":"Success","clusterName":"0c04b-OAMHOST1.u" ,"primaryServers":["OAMHOST1.example.com:5575","OAMHOST2.example.com:5575","oamLBR.example.com:5575"],"restEndPoint":"http://IADADMINVHN1.example.com:7001","oamServerModes":{"wls_oam2":"simple","oamLBR":"simple","wls_oam1":"simple"}}
クラスタ名をノートにとります。
親トピック: レプリケーション承諾の作成
oamadminユーザーのエンコーディング
レプリケーション承諾の設定時には、LDAPディレクトリにあるoamadmin
アカウントを使用する必要があります。
レプリケーション承諾の設定は、次のCurlコマンドを使用して行います。Curlコマンドの一部として、oamadminユーザーおよびパスワードを指定する必要があります。このパスワードはbase64を使用してエンコードされている必要があります。Web上には、http://www.motobit.com/util/base64-decoder-encoder.aspなど、パスワードをエンコードできるユーティリティが多数あります
ノート:
値をエンコードする際には、ユーザー名とパスワードの両方をエンコードする必要があります。たとえば、前述のユーティリティを使用する場合は、エンコードする値がusername:passwordの形式であることが必要です(例: oamadmin:<password>)。親トピック: レプリケーション承諾の作成