| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
Access Managerのデータを複数データ・センター(MDC)間で同期させるようにマルチデータ・センター(MDC)インフラストラクチャを構成できます。自動ポリシー同期(APS)という11gで導入されたレプリケーション・メカニズムにより、データ同期プロセスに管理者や手動の干渉が不要になりました。
ポリシー、システム構成およびパートナ・メタデータはすべてAPSと同期されます。
ノート:
マスター(サプライヤとも呼ばれる)からクローン(コンシューマとも呼ばれる)を作成するには、T2Pツールが必要です。MDCインフラストラクチャがでデプロイされると、変更をマスターからクローンに自動的に同期するようにAPSを有効にできます。
「マルチデータ・センターを設定する前に」を参照してください。
(レプリケーション・サービスとも呼ばれる) APSは、REST APIのセットです。バイナリはAccess Managerアプリケーションの一部としてインストールされ、AdminServerにデプロイされます。デフォルトでは無効化されていますが、oracle.oam.EnableMDCReplicationプロパティをtrueに設定すると有効化できます。サービスを有効化した後、プル・モデルのレプリケーション承諾をクローン・データ・センターとマスターとの間に作成します。レプリケーション承諾が有効であるかぎり、クローンはマスターからの変更をポーリングします。反対に、有効なレプリケーション承諾があるかぎり、マスターはクローンのリクエストに応答します。クローンは変更をローカルに適用します。
ノート:
APSは必須ではなく、このリリースより前に使用されていたT2PツールおよびWLSTコマンドの手順を使用して、管理者がインポートおよびエクスポートをベースとするレプリケーションを開始することも引き続き可能です。
レプリケーション・サービスの設定時に、次の処理が行われることがあります。
レプリケーション承諾の確立。データ・センターの1つがレプリケーション・クローンとして登録され、地理的に離れた別のデータ・センターがそのマスターとして登録されます。変更内容はプルされてクローンに適用されます。
データ・センター間でレプリケートできない、データ・センター固有の構成の定義。
各データ・センターでのAccess Manager構成変更のトラッキングと、任意のデータ・センターでの現在のレプリケーション状態の問合せ。
変更ログの生成。このログは、類似の設定が別のデータ・センターで稼働している場合に適用できます。
マスター・データ・センターからのプルのトリガー(必要な場合。たとえば、自動レプリケーションに失敗した場合など)。
マスター/クローン・モデルでのAccess Manager構成アーティファクトのレプリケーション。
ノート:
APSでは、IDSプロファイル、OAMキーストアおよびOracle Platform Security Servicesアーティファクト(jps-config.xmlの変更、資格証明ストア構成など)を同期しません。
次の各項では、さらに詳細を説明します。
レプリケーションは、マスター/クローン・トポロジにおいて行われます。このトポロジでは、複数のクローンが単一のマスターから変更内容をプルします。管理者によって1つのデータ・センターがマスターとして定義され、その他の1つ以上のデータ・センターがクローンとなります。
管理者がマスターに変更を行うと、それがクローンにレプリケートされます。マスターからクローンへのレプリケーションのみがサポートされ、クローンに対する変更内容が逆にマスターにレプリケートされることはありません。
ノート:
マルチマスター・レプリケーションはサポートされません。
レプリケーションに参加するマスター・データ・センター(レプリケーションを開始するデータ・センター)とクローン・データ・センター(変更を受け取るデータ・センター)のAccess Managerデータ・ストアに、レプリケーション承諾が格納されている必要があります。表19-1では、レプリケーションをデプロイできる状態について説明します。
表19-1 レプリケーションの状態
| 状態 | 定義 |
|---|---|
アクティブ |
(管理サーバーおよび管理対象サーバーを含む)Access Managerドメインが、アクセス・リクエストを処理するように設定されています。アクティブ状態のとき、Access Managerサーバーは追加のMDC機能なしでWebアクセス管理機能を提供します。 |
ブートストラップ |
この状態は、MDCトポロジの最初のデータ・センターなど一部のデータ・センターではオプションです。データ・センターがこの中間状態になるのは、そのデータ・センターが既存のMDCトポロジに追加されるときです。新しいDCはマスターと通信し、同じ状態になるように自身をブートストラップします。ブートストラップの中で、サーバー・キー、ポリシー・アーティファクト、パートナおよびシステム構成が同期されます。ブートストラップが完了した後は、DCの状態はレプリケーション準備完了となります。 |
レプリケーション準備完了 |
この状態のときは、MDCが有効化されており、DCはトポロジの一部となっており、レプリケーション・サービスが有効化されています。有効化された後は、レプリケーション承諾を介してクローンをマスターに登録できます。確立後は、クローンDCがマスターに問い合せて変更ログのプルを開始できます。 |
図19-1は、レプリケーション・フローを示しています。
各クローンはマスターから変更内容をプルします。事前構成された時間間隔の経過後に、レプリケーション・スレッドがクローンで動作し、マスター環境で実行されているレプリケーション・サービス(RESTエンドポイント)から変更内容をフェッチします。
クローニングされた環境ごとに、マスターは最後に同期された日時を示す変更シーケンス番号を記録します。また、マスターは、クローンによってプルされた変更内容(作成/更新/削除)のリストを、特定の変更シーケンス番号を使用して変更ログに記録します。また、構成メタデータの更新時に、クローンは変換ルールに応じて環境固有のパラメータ値を変更することもできます。
「変換ルールのカスタマイズ」を参照してください。
新しいデータ・センターが既存のMDCトポロジに追加されると、そのデータ・センターは既存のデータ・センターと同期するように自身をブートストラップする必要があります。このブートストラップ操作によって、既存のMDCトポロジに対する最新のAccess Managerポリシー、システム構成、パートナ・メタデータおよびサーバー・キーが取得されます。ブートストラップ操作後に、新しいデータ・センターは最新の変更シーケンス番号をトポロジのマスターから取得し、レプリケーション時にこの番号を使用して現在の状態を特定できます。
ノート:
自動ブートストラップは理想的なシナリオですが、最初にT2Pツールを実行してマスターとクローンとを確実に同じ状態にできます。
レプリケーション承諾を確立するには、クローン・データ・センターがマスターの変更ログ・シーケンス番号を認識している必要があります。データ・センターがトポロジに追加されたのが0日目で、レプリケーション承諾が作成されたのが1日目の場合は、再度ブートストラップが必要になります。このことを回避してフローの単純さを維持するには、レプリケーション承諾の作成時にブートストラップと実際のレプリケーション承諾作成を行います。レプリケーション承諾を作成するステップは、次を参照してください。
「マルチデータ・センターの設定」を参照してください。
