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

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

トピック

マルチデータ・センターの構成時に使用する変数
この項には、マルチデータ・センターの構成時に使用する変数がリストされています。
マルチデータ・センター・デプロイメントの構成のロードマップ
この項のロードマップには、マルチデータ・センター・デプロイメントを構成するためのステップの概要が含まれています。
マルチデータ・センター・デプロイメント用のリソースの取得
マルチデータ・センター・エンタープライズ・デプロイメント用のリソースを取得する必要があります。
マルチデータ・センター・デプロイメント用のロード・バランサの準備
サイト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ドキュメントに従って使用します。

表20-1 マルチデータ・センター・エンタープライズ・デプロイメントの構成のロードマップ

タスク	サブタスク	説明
サイト1でサブタスクを完了し、サイト1を構成します。各サブタスクについては、「説明」列に記載されている各項の「サイト1」の手順に従ってください。	必要なリソースを取得します。	「マルチデータ・センター・デプロイメント用のリソースの取得」を参照してください。
該当なし	ロード・バランサを準備します。	「マルチデータ・センター・デプロイメント用のロード・バランサの準備」を参照してください。
該当なし	ファイル・システムの準備	「マルチデータ・センター・デプロイメント用のファイル・システムの準備」を参照してください。
該当なし	ホスト・コンピュータを準備します。	「マルチデータ・センター・エンタープライズ・デプロイメント用のホスト・コンピュータの準備」を参照してください。
該当なし	データベースを準備します。	「マルチデータ・センター・エンタープライズ・デプロイメント用のホスト・コンピュータの準備」を参照してください。
該当なし	Oracle LDAPを構成します。	「マルチデータ・センター・デプロイメント用のOracle LDAPの構成」を参照してください。
該当なし	Oracle HTTP ServerまたはOracle Traffic Directorを構成します。	「マルチデータ・センター・デプロイメント用の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またはOracle Traffic Directorを構成します。	「マルチデータ・センター・デプロイメント用の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で起動できるように、IGD_ASERVER_HOMEがサイト2にミラーリングされます。

サーバー全体の移行のためにファイル・システムを使用している場合、サイト2へのミラーリングが必要になります。

サイト2

マルチデータ・センター・エンタープライズ・デプロイメントのサイト2のファイル・システム構成では、次のパラメータが異なります。

両方のサイトのソフトウェア・バージョンをまったく同一にする必要がなくなるよう、オプションでバイナリをサイト1にミラーリングできます。この場合、この章で説明するように、少なくとも2つのバージョンのバイナリを使用することが重要です。

IAD_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

LDAPは、サイト2でサイト1の拡張として構成されます。このため、次のようにして、サイト2でLDAPを構成する必要があります。

Oracle Unified Directory (OUD)の場合は、次のタスクを完了します。

親トピック: マルチデータ・センターの構成

マルチデータ・センター・デプロイメント用のWeb層の構成

マルチデータ・センター・エンタープライズ・デプロイメント用のWeb層を構成する必要があります。

(「エンタープライズ・デプロイメント用のOracle HTTP Serverの構成」の説明に従って) Oracle HTTP Serverを構成するか、(「エンタープライズ・デプロイメント用のOracle Traffic Directorの構成」の説明に従って) Oracle Traffic Directorを構成しますが、次の追加の考慮事項があります。

サイト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

ノート:

両方のサイトで同じWeb層タイプOHSまたはOracle Traffic Directoryを使用することを推奨しますが、必須ではありません。

サイト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)のようになります

ノート:

両方のサイトで同じWeb層タイプOHSまたはOracle Traffic Directoryを使用することを推奨しますが、必須ではありません。

親トピック: マルチデータ・センターの構成

マルチデータ・センター・デプロイメント用の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ゲート・エージェントを更新する必要があります。

親トピック: マルチデータ・センターの構成

ロード・バランサ用の追加のサーバー・インスタンスの作成

マルチデータ・センター・エンタープライズ・デプロイメントでは、ロード・バランサのエントリ・ポイント用に追加のサーバー・インスタンスを作成する必要があります。

追加のサーバー・インスタンスを作成するには、次のステップを実行します。

EDGで作成したoamadminユーザーとして、次のURLを使用してOAMコンソールにログインします。
```
http://iadadmin.example.com/oamconsole
```
「構成」タブをクリックします。
「サーバー・インスタンス」をクリックします。
「OAMサーバーの検索」ページで、「検索」をクリックします。
すでに定義されているサーバー・インスタンスが表示されます。
「作成」をクリックします
サーバー名にoamLBRを入力します
ロード・バランサ仮想ホスト名を入力します。たとえば: oam.example.com
ロード・バランサ仮想ホストでリスニングするように構成したポートを入力します。たとえば: 5575
既存のサーバー・エントリで使用していたプロキシ・サーバーIDを入力します。たとえば: AccessServerConfigProxy
使用しているOAMセキュリティ・モデルを選択します。たとえば: 簡易
「適用」をクリックします。

親トピック: マルチデータ・センター・デプロイメント用のOracle Access Managementの構成

ロード・バランサを使用するためのWebゲート・エージェントの更新

マルチデータ・センター・エンタープライズ・デプロイメントでは、ロード・バランサのエントリ・ポイント用にWebゲート・エージェントを更新する必要があります。

Webゲート・エージェントを更新するには、次の手順を実行します。

エージェント名をクリックします。
「プライマリ・サーバー」ボックスで「追加」ボタンをクリックして新しいエージェントを作成し、アクセス・サーバーとして「oamLBR」を選択します。
「プライマリ・サーバー・リスト」内の他の各エントリを削除します。
「適用」をクリックします
各エージェントに対してこれらのステップを繰り返します。

親トピック: マルチデータ・センター・デプロイメント用のOracle Access Managementの構成

マルチデータ・センター・デプロイメント用の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の構成時に、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 Governanceの構成

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 Governanceの構成

Oracle Identity Managerの構成のためのOracle Identity Managerデータ・ソースの変更

Oracle Identity Manager (OIM)の構成のために構成後の変更を実行する際に、Oracle Identity Managerデータ・ソースを変更する必要があります。OIMデータ・ソースを変更するには、次の手順を実行します。

WebLogicコンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン」ツリーで、「サービス」、「データ・ソース」の順に展開します。
「JDBCデータ・ソースのサマリー」ページで、データ・ソースの名前をクリックします。たとえば、ApplicationDBをクリックします。
「接続プール」タブをクリックします。
URLを更新して、前述のデータベース接続の例を反映させます。
「保存」をクリックします。
「モニタリング」タブ、「テスト」サブタブの順にクリックして、データ・ソースを検証します。
サーバーの1つを選択し、「データ・ソースのテスト」をクリックします。
続行する前に、テストが成功したことを確認します。
「ONS」タブをクリックします。
「ONSノード」フィールドに、各ホスト/ポートをカンマで区切ってスタンバイ・データベースを追加します。たとえば、primaryDB-scan:6200,standbyDB-scan:6200のようにします。
「保存」をクリックします。
データ・ソースごとに、手順を繰り返します。
「変更のアクティブ化」をクリックします。

親トピック: Oracle Identity Managerの構成後の変更

Oracle Identity Managerの構成のためのOracle Identity Managerジョブ・スケジューラの無効化

Oracle Identity Managerを構成するために、サイト2のOracle Identity Managerジョブ・スケジューラを無効にする必要があります。

OIMジョブ・スケジューラは、データベースを大量に使用します。サイト間のトラフィックを最小限に保つために、データベースがプライマリではないサイトのジョブ・スケジューラを無効にする必要があります。このステップは、サイト2のOIM管理対象サーバーを停止する予定である場合には必要ありません。

サーバー起動引数に次のパラメータを追加することにより、ジョブ・スケジューラが無効になります。

-Dscheduler.disabled=true

ジョブ・スケジューラを無効化する方法の詳細は、「Oracle Identity Managerの構成のためにジョブ・スケジューラを無効化するためのパラメータの追加」を参照してください

Oracle Identity Managerの構成のためにジョブ・スケジューラを無効化するためのパラメータの追加

親トピック: マルチデータ・センター・デプロイメント用のOracle Identity Governanceの構成

Oracle Identity Managerの構成のためにジョブ・スケジューラを無効化するためのパラメータの追加

パラメータDisabling thを追加してジョブ・スケジューラを無効にするには、次の手順を実行します。

WebLogic管理コンソールにログインします。
左ペインで、「環境」→「サーバー」をクリックします。
左タブで、「ロックして編集」をクリックします。
右ペインで、「構成」→「サーバーの起動」タブをクリックします。
「引数」テキスト・ボックスで、Dscheduler.disabled=true,を追加して保存します。
左ペインで、「変更のアクティブ化」をクリックします。
データベースを切り替えると、このパラメータはこれらのサーバーから削除され、現在のスタンバイ・サイトのサーバー定義に追加されます。

親トピック: Oracle Identity Managerの構成のためのOracle Identity Managerジョブ・スケジューラの無効化

TAPエンドポイントの更新

この項では、TAPエンドポイントを更新するための手順を説明します。

Oracle Identity Governanceの構成を開始する前にOAM MDCを構成した場合は、このステップは必要ありません。既存のOAMをマルチデータ・センターに変換している場合は、新しいOAMエントリ・ポイントを反映させるために、OIMのTAPエンドポイントを更新する必要があります。

ユーザーweblogic_idmを使用して、Oracle Enterprise ManagerのIdentityAccessDomainにログインします。
```
http://iadadmin.example.com/em
```
「weblogic_domain」、「システムMBeanブラウザ」の順にクリックします。
検索ボックスに、oamWLSTと入力して、「検索」をクリックします。mbeanが表示されます。
「操作」タブを選択します。
displayTAPURLをクリックし、戻り値をノートにとります。後述の例を確認してください。
```
https://login.example.com:443/oam/server/dap/cred_submit
```
ユーザーweblogic_idmを使用して、Oracle Enterprise ManagerのIdentityGovernanceDomainにログインします。
```
http://igdadmin.example.com/em
```
「weblogic_domain」、「システムMBeanブラウザ」の順にクリックします。
検索ボックスに、SSOIntegrationMXBeanと入力して、「検索」をクリックします。mbeanが表示されます。
TapEndpointUrl属性の値をoamWLST Beanから取得した値に設定します。
「適用」をクリックします。

親トピック: マルチデータ・センターの構成

マルチデータ・センターの有効化

マルチデータ・センター・デプロイメントの構築後にマルチデータ・センターを有効にする必要があります。

次のステップを実行して、マルチデータ・センターを有効化できます。前述のステップについては、次の項を参照してください。

親トピック: マルチデータ・センターの構成

マスター・データ・センターの設定

マスター・データ・センターを設定するには、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コマンドの値を示します。

表20-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コマンドの値を示します。

表20-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コマンドの値を示します。

表20-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コマンドは、次のとおりです。

サイト1の場合:

curl -u oamadmin:password 'http://iadadmin1.example.com/oam/services/rest/_replication/hello'

サイト2の場合:

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コマンドは、次のとおりです。

サイト1の場合:

curl -k -u oamadmin:password 'http://iadadmin1.example.com/oam/services/rest/mdc/dc/configuration

サイト2の場合:

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.us.oracle.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>)。

親トピック: レプリケーション承諾の作成