マルチデータ・センターのデータの同期

19 マルチデータ・センターのデータの同期

Access Managerのデータを複数データ・センター間で同期させるようにマルチデータ・センター・インフラストラクチャを構成できます。これは、自動ポリシー同期レプリケーション・サービスを使用して実行できますが、データを手動でレプリケートすることもできます。

次の各トピックでは、データ・センター間の同期方法およびデータのレプリケート方法について説明します。

19.1 マルチデータ・センター同期の理解

Access Managerのデータを複数データ・センター(MDC)間で同期させるようにマルチデータ・センター(MDC)インフラストラクチャを構成できます。

ポリシー、システム構成およびパートナ・メタデータはすべてAPSと同期されます。

ノート:

マスター(サプライヤとも呼ばれる)からクローン(コンシューマとも呼ばれる)を作成するには、MDC Admin REST APIが使用されます。MDCインフラストラクチャがでデプロイされると、変更をマスターからクローンに自動的に同期するようにAPSを有効にできます。

「マルチデータ・センターを設定する前に」を参照してください。

(レプリケーション・サービスとも呼ばれる) APSは、REST APIのセットです。バイナリはAccess Managerアプリケーションの一部としてインストールされ、AdminServerにデプロイされます。これはデフォルトで有効になっています。サービスを有効化した後、プル・モデルのレプリケーション承諾をクローン・データ・センターとマスターとの間に作成します。レプリケーション承諾が有効であるかぎり、クローンはマスターからの変更をポーリングします。反対に、有効なレプリケーション承諾があるかぎり、マスターはクローンのリクエストに応答します。クローンは変更をローカルに適用します。

ノート:

APSは必須ではなく、このリリースより前に使用されていたWLSTコマンドの手順を使用して、管理者がインポートおよびエクスポートをベースとするレプリケーションを開始することも引き続き可能です。

レプリケーション・サービスの設定時に、次の処理が行われることがあります。

レプリケーション承諾が確立されます。あるデータ・センターがレプリケーション・クローンとして登録され、別のデータ・センターがそのマスターとして地理的に別個の場所に登録されます。変更は、マスター・データ・センターからプルされ、クローン・データ・センターに適用されます。
データ・センター間でレプリケートできないデータ・センター固有の構成が定義されます。
Access Managerの構成変更は各データ・センターで追跡されるため、どのデータ・センターでも現在のレプリケーション状態を問い合せることができます。
変更ログが生成されます。これは、類似の設定が別のデータ・センターで稼働している場合に適用できます。
必要に応じてマスター・データ・センターからのプルをトリガーできます。たとえば、自動レプリケーションに失敗した場合です。
マスター/クローン・モデルでのAccess Manager構成アーティファクトがレプリケートされます。

ノート:

APSでは、IDSプロファイル、OAMキーストアおよびOracle Platform Security Servicesアーティファクト(jps-config.xmlの変更、資格証明ストア構成など)を同期しません。

この節では、以下のトピックについて説明します。

19.1.1 レプリケーションの動作

レプリケーションは、マスター/クローン・トポロジにおいて行われます。このトポロジでは、複数のクローンが単一のマスターから変更内容をプルします。管理者によって1つのデータ・センターがマスターとして定義され、その他の1つ以上のデータ・センターがクローンとなります。

管理者がマスターに変更を行うと、それがクローンにレプリケートされます。マスターからクローンへのレプリケーションのみがサポートされ、クローンに対する変更内容が逆にマスターにレプリケートされることはありません。

ノート:

マルチマスター・レプリケーションはサポートされません。

レプリケーションに参加するマスター・データ・センター(レプリケーションを開始するデータ・センター)とクローン・データ・センター(変更を受け取るデータ・センター)のAccess Managerデータ・ストアに、レプリケーション承諾が格納されている必要があります。表19-1では、レプリケーションをデプロイできる状態について説明します。

表19-1 レプリケーションの状態

状態	説明
アクティブ	(管理サーバーおよび管理対象サーバーを含む)Access Managerドメインが、アクセス・リクエストを処理するように設定されています。アクティブ状態のとき、Access Managerサーバーは追加のMDC機能なしでWebアクセス管理機能を提供します。
ブートストラップ	この状態は、MDCトポロジの最初のデータ・センターなど一部のデータ・センターではオプションです。データ・センターがこの中間状態になるのは、そのデータ・センターが既存のMDCトポロジに追加されるときです。新しいDCはマスターと通信し、同じ状態になるように自身をブートストラップします。ブートストラップの中で、サーバー・キー、ポリシー・アーティファクト、パートナおよびシステム構成が同期されます。ブートストラップが完了した後は、DCの状態はレプリケーション準備完了となります。
レプリケーション準備完了	この状態のときは、MDCが有効化されており、DCはトポロジの一部となっており、レプリケーション・サービスが有効化されています。有効化された後は、レプリケーション承諾を介してクローンをマスターに登録できます。確立後は、クローンDCがマスターに問い合せて変更ログのプルを開始できます。

図19-1は、レプリケーション・フローを示しています。

図19-1 レプリケーション・フロー

「図19-1 レプリケーション・フロー」の説明

各クローンはマスターから変更内容をプルします。事前構成された時間間隔の経過後に、レプリケーション・スレッドがクローンで動作し、マスター環境で実行されているレプリケーション・サービス(RESTエンドポイント)から変更内容をフェッチします。

クローニングされた環境ごとに、マスターは最後に同期された日時を示す変更シーケンス番号を記録します。また、マスターは、クローンによってプルされた変更内容(作成/更新/削除)のリストを、特定の変更シーケンス番号を使用して変更ログに記録します。また、構成メタデータの更新時に、クローンは変換ルールに応じて環境固有のパラメータ値を変更することもできます。

「変換ルールのカスタマイズ」を参照してください。

19.1.2 レプリケーション承諾の理解

(ジャーナルとして定義された)構成変更が、マスター・ノードからクローン・ノードにレプリケートされます。ジャーナルを受け取ると、各ノードは自身の構成をジャーナルに合せて更新し、同期された状態を維持します。ただし、ノードが変更ジャーナルを受け取るには、レプリケーション承諾を確立する必要があります。

新しいデータ・センターが既存のMDCトポロジに追加されると、そのデータ・センターは既存のデータ・センターと同期するように自身をブートストラップする必要があります。このブートストラップ操作によって、既存のMDCトポロジに対する最新のAccess Managerポリシー、システム構成、パートナ・メタデータおよびサーバー・キーが取得されます。ブートストラップ操作後に、新しいデータ・センターは最新の変更シーケンス番号をトポロジのマスターから取得し、レプリケーション時にこの番号を使用して現在の状態を特定できます。

ノート:

自動ブートストラップは理想的なシナリオですが、最初に診断MDC REST APIを実行してマスターとクローンのデータ・センターを確実に同じ状態にできます。データ・センターが同じ状態にない場合、MDC ADMIN REST APIを実行する必要があります。

レプリケーション承諾を確立するには、クローン・データ・センターがマスターの変更ログ・シーケンス番号を認識している必要があります。データ・センターがトポロジに追加されたのが0日目で、レプリケーション承諾が作成されたのが1日目の場合は、再度ブートストラップが必要になります。このことを回避してフローの単純さを維持するには、レプリケーション承諾の作成時にブートストラップと実際のレプリケーション承諾作成を行います。

「マルチデータ・センターでのマスターおよびクローンの設定」を参照してください。

19.1.3 マルチデータ・センターでの手動によるデータの同期について

MDCトポロジのデータも手動で同期できます。手動オプションでは、WLSTエクスポートおよびインポート・コールを使用して、データ・センター間でデータを移行します。WLSTを使用して、パートナ・プロファイルおよびポリシーの両方をエクスポートおよびインポートする必要があります。

『Oracle Fusion Middleware WebLogic Scripting Tool Identity and Access Managementコマンド・リファレンス』の「Access Manager WLSTコマンド」を参照

19.2 データ・レプリケーションの有効化

マスターおよびクローン・データ・センターでのデータ・レプリケーションは、デフォルトで有効になっています。フラグ-Doracle.oam.EnableMDCReplicationをtrueに設定することは、必須ではありません。

次のように、マスターおよびクローン・データ・センターのレプリケーションRESTエンドポイントを検証します。

マスター・データ・センターでRESTエンドポイントが有効になっていることを確認します。
```
curl -u weblogic:password 'https://supplier.example.com:7002/oam/services/rest/_replication/hello
```
クローン・データ・センターでRESTエンドポイントが有効になっていることを確認します。
```
curl -u weblogic:password 'https://supplier.example.com:7002/oam/services/rest/_replication/hello
```
すべてのクローン・データ・センターでこの検証プロセスを繰り返します。

19.3 マスターおよびクローン・メタデータの同期

MDC間でのメタデータの同期のプロセスでは、まずAccess Manager UDMメタデータを同期し、次にレプリケーション承諾を作成します。

「レプリケーション承諾の理解」を参照してください。

次の各トピックでは、マスターおよびクローン・メタデータの同期方法について説明します。

19.3.1 UDMメタデータの同期

レプリケーション承諾を作成するには、UDMメタデータを同期する必要があります。

マスターに格納されているAccess Manager UDMメタデータをすべてのクローンと同期するには、次のようにします。

マスター・データ・センターでexportAccessStore WLSTコマンドを実行して、UDMメタデータを含むZIPファイルを作成します。
```
exportAccessStore(toFile="/master/location/dc1metadata.zip", 
   namePath="/")
```
dc1metadata.zipをクローンDCの場所にコピーします。
クローン・データ・センターでimportAccessStore WLSTコマンドを実行して、UDMメタデータをインポートします。
```
importAccessStore(fromFile="/clone/location/dc1metadata.zip", 
   namePath="/")
```
すべてのクローンDCで、同じ手順を繰り返します。

19.4 レプリケーション承諾のREST APIの使用

Access Managerが提供するREST APIを使用してレプリケーション承諾を管理します。

この節では、以下のトピックについて説明します。

19.4.1 レプリケーション承諾の詳細の問合せ

RESTリクエストをマスターのエンドポイントで実行して、マスターとクローンのデータ・センター間のレプリケーション承諾の詳細(ポーリング間隔を含む)を問い合せます。

レプリケーション承諾識別子が不明な場合、次のコマンドを実行してすべてのレプリケーション承諾識別子をリストします(それ以外の場合、このステップをスキップします)。

curl -k -u weblogic:password 'https://supplier.example.com:7002/oam/services/rest/_replication/agreements'
 
Sample output 1:
{"featureEnabled":"true","identifiers":"201411211137273612","ok":"true"}
Sample output 2:
{"featureEnabled":"true","identifiers":["201411211137273612","201411211137273900"],"ok":"true"}

次のように、クローン・データ・センターのレプリケーション承諾の詳細(ポーリング間隔を含む)を問い合せます。

curl -k -u weblogic:password 'https://supplier.example.com:7002/oam/services/rest/_replication/201409231329353668?type=consumer'

Sample output:
{"enabled":"true","identifier":"201409231329353668","ok":"true",
  "pollInterval":"60","startingSequenceNumber":"110","state":"READY"}

次のように、マスター・データ・センターのレプリケーション承諾の詳細(ポーリング間隔を含む)を問い合せます。
```
curl -u weblogic:password 'https://supplier.example.com:7002/oam/services/rest/_replication/201409231329353668'
Sample output:
{"enabled":"true","identifier":"201409231329353668","lastSequenceNumber":"110","ok":"true","pollInterval":"3600","startingSequenceNumber":"110","state":"ACTIVE"}
```
ノート:
マスター・データ・センターのレプリケーション承諾のポーリング間隔は、実際のレプリケーションに影響を与えません。

19.4.2 レプリケーション承諾の作成

レプリケーション承諾の作成は、クローン・データ・センターがマスター・データ・センターから変更をプルできるようにする1回かぎりの操作です。

レプリケーション承諾は、任意のRESTクライアントを使用して作成できます。この手順では、標準のCurlユーティリティを使用します。

このコマンドを実行すると、次のような結果になります。

変更内容をプルするクローンに関する詳細が格納されているマスターのレプリケーション承諾ストアにエントリが挿入されます。
変更内容をプルするマスターに関する詳細が格納されているクローンのレプリケーション承諾ストアにエントリが挿入されます。ポーリング間隔などのレプリケーション構成値も設定されます。

レプリケーション承諾を作成するには、次のようにします。

マスターとクローンのDC RESTエンドポイントが稼働中であることを確認します。
マスターDCで次のコマンドを実行します。
このコマンドでは、マスターからクローンへのレプリケーション問合せに指定されているrepluserが使用されます。関連するすべてのDCのデフォルト・アイデンティティ・ストアで、repluserが使用可能であることが期待されます。
```
curl -u <repluser> -H 'Content-Type: application/json' -X POST
 'https://supplier.example.com:7002/oam/services/rest/
  _replication/setup' -d '{"name":"DC12DC2", 
 "source":"DC1","target":"DC2","documentType":"ENTITY"}'
```
コマンドの出力例を次に示します。
```
{"enabled":"true","identifier":"201409231329353668","ok":"true",
  "pollInterval":"900","startingSequenceNumber":"110","state"  :"READY"}
```
レプリケーション識別子pollIntervalおよびstartingSequence Numberの値に注意してください。この識別子は、このレプリケーション承諾に固有の参照であり、レプリケーション関連の問合せに使用されます。pollIntervalの値(秒)が経過すると、クローンはマスターに対して変更をポーリングします。(通常、ポリシーや構成が頻繁に変更されることはないため、この番号はデフォルト値の900秒程度の高い値に設定してかまいません。)startingSequenceNumberの値より前のすべてのレコードは使用不可になります。この例では、110の値より前のレコードはすべて使用不可です。暗黙的に、レプリケーション承諾の作成前にブートストラップが行われているため、クローンはシーケンス番号110から変更内容のプルを開始できます。クローンのローカル・レプリケーション表にもエントリが作成されており、ここに最後のシーケンス番号が記録されます。図19-2は、開始シーケンス・プロセスを示しています。

図19-2 示されている開始シーケンス

「図19-2 示されている開始シーケンス」の説明

レプリケーション承諾作成コマンドは、既存のレプリケーション承諾の詳細を返します(該当する場合)。この場合、okの値がfalseになります。
```
{"enabled":"true","identifier":"201409231329353668","ok":"false",
  "pollInterval":"900","startingSequenceNumber":"110",
  "state":"READY"}
```
ノート:

レプリケーションに特定のユーザーを使用する必要がある場合、そのユーザーの資格証明を"BASIC base64(user:password)"という形式でコマンドに指定できます。たとえば、次のコマンドでは、"BASIC base64(weblogic:welcome1)"を"BASIC d2VibG9naWM6d2VsY29tZTE="として指定しています。
```
curl -u <repluser> -H 'Content-Type: application/json' -X POST 
  'https://supplier.example.com:7002/oam/services/rest/
  _replication/setup' -d 
  '{"source":"DC1","target":"DC2","documentType":"ENTITY","config":
  {"entry":{"key":"authorization","value":"BASIC 
  d2VibG9naWM6d2VsY29tZTE="}}}''
```
レプリケーションREST APIでは、Basic認可がサポートされています。
マスターおよびクローンのAdminServerを再起動します。

レプリケーション承諾が作成され、AdminServerが再起動されると、クローンは変更のポーリングを開始します。「ポーリング間隔の変更」を参照してください。

19.4.3 レプリケーション承諾の変更

レプリケーション承諾識別子を使用して、レプリケーション承諾構成を変更できます。レプリケーション承諾のプロパティ(有効化ステータス、ポーリング間隔など)を更新するには、マスターのエンドポイントでRESTリクエストを実行します。replicaTypeパラメータの値で指定されたとおりに、マスターまたはクローンのレプリケーション承諾が更新されます。クローンは変更をポーリングし、その変更を適用し、pollIntervalとして指定された時間が経過するまで待機します。

この例では、pollIntervalの値が60秒に変更されます。

サービスは、変更を行う前に、レプリケーション承諾のステータスであるJSONオブジェクトを使用して応答します。更新済の構成を確認するには、レプリケーション承諾ステータスを再度フェッチする必要があります。

次のコマンドを使用して既存のレプリケーション承諾を問い合せ、次のステップで使用する必要があるレプリケーション識別子replIdを取得します。
```
curl -k -u weblogic:password 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/agreements'
```
ノート:
複数のレプリケーション承諾が存在する場合、対応するクローン・データ・センターを問い合せてレプリケーション承諾を変更する必要のある識別子を選択します。

次のコマンドを実行して、クローン・マシンでレプリケーション承諾の現在のステータスを取得します。

curl -k -u weblogic:password 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/201409040157218184?type=consumer'

JSONレスポンスは次のようになります。

{“enabled":"true","identifier":"201409040157218184","ok":"true","pollInterval":"900","startingSequenceNumber":"101","state":"READY"}

次のコマンドを実行して、クローン・マシンでpollIntervalの値を変更します。

curl -k -u weblogic:password 'Content-Type: application/json' -X PUT 
'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/201409040157218184' -d '{“pollInterval":"60","replicaType":"CONSUMER"}'

JSONレスポンスは次のようになります。

{“enabled":"true","identifier":"201409040157218184","ok":"true","pollInterval":"60","startingSequenceNumber":"101","state":"READY"}

クローン・マシンでAdminServerを再起動します。

次のコマンドを実行して、レプリケーション承諾の現在のステータスを取得します。

これにより、変更が行われたことが検証されます。JSONレスポンスのpollIntervalの値は、この手順の最初のステップで返される値と異なるので注意してください。

curl -k -u weblogic:password 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/201409040157218184?type=consumer'

JSONレスポンスは次のようになります。

{“enabled":"true","identifier":"201409040157218184?,"ok":"true","pollInterval":"60","startingSequenceNumber":"101","state":"READY"}

表19-2 レプリケーション承諾プロパティの変更

プロパティ	変更コマンド
BatchSize	クローンによるgetChanges問合せの結果として、マスターによって返される変更レコード(ジャーナル)の数。フェッチの一部として複数のバッチですべての変更がプルされるため、理想としては、デフォルトのバッチ・サイズの32で十分です。ただし、大きいバッチ・サイズが設定で必要な場合は、次のコマンドを実行します。 curl -k -u weblogic:password -H 'Content-Type: application/json' -X PUT 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/<replid>' -d '{"batchSize":"100","replicaType":"SUPPLIER"}'
ユーザー・コンテキスト	まれな例ですが、レプリケーション・ポーリングのユーザー・コンテキストの変更が必要になる場合があります。 curl -k -u weblogic:password -H 'Content-Type: application/json' -X PUT 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/201409231329353668' -d '{"replicaType":"CONSUMER", "config":{"entry":{"key":"authorization","value":" BASIC cG9sbHVzZXI6c2VjcmV0"}}}' 'cG9sbHVzZXI6c2VjcmV0'は、polluser資格証明のベース64のエンコード値です。ここでは、コマンドの実行に使用されるrepluserではなく、任意のユーザー資格証明を使用できます。

プロパティ

変更コマンド

BatchSize

クローンによるgetChanges問合せの結果として、マスターによって返される変更レコード(ジャーナル)の数。フェッチの一部として複数のバッチですべての変更がプルされるため、理想としては、デフォルトのバッチ・サイズの32で十分です。ただし、大きいバッチ・サイズが設定で必要な場合は、次のコマンドを実行します。

curl -k -u weblogic:password -H 'Content-Type: application/json' -X PUT 
 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/<replid>' 
 -d '{"batchSize":"100","replicaType":"SUPPLIER"}'

ユーザー・コンテキスト

まれな例ですが、レプリケーション・ポーリングのユーザー・コンテキストの変更が必要になる場合があります。

curl -k -u weblogic:password -H 'Content-Type: application/json' -X PUT 
 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/201409231329353668' 
 -d '{"replicaType":"CONSUMER",
"config":{"entry":{"key":"authorization","value":" 
 BASIC cG9sbHVzZXI6c2VjcmV0"}}}'

'cG9sbHVzZXI6c2VjcmV0'は、polluser資格証明のベース64のエンコード値です。ここでは、コマンドの実行に使用されるrepluserではなく、任意のユーザー資格証明を使用できます。

19.4.4 レプリケーション承諾の削除

レプリケーション承諾を削除するには、REST APIをマスター・データ・センターのエンドポイントで実行します。レプリケーション承諾が現在アクティブで使用されている場合は、マスターおよびクローンが無効化されないかぎり、そのレプリケーション承諾の削除はできません。

先にレプリケーション承諾を無効にしてから、それをクローンおよびマスター・データ・センターから削除します。

次のようにクローンでレプリケーション承諾を無効にします。

curl -u <repluser> -H 'Content-Type: application/json' -X PUT
  'https://supplier.example.com:7002/oam/services/rest/_replication/201409231
  329353668' -d '{"enabled":"false","replicaType":"CONSUMER"}''

次のようにマスターでレプリケーション承諾を無効にします。

curl -u <repluser> -H 'Content-Type: application/json' -X PUT
  'https://supplier.example.com:7002/oam/services/rest/_replication/201409231
  329353668' -d '{"enabled":"false","replicaType":"SUPPLIER"}''

次のようにレプリケーション承諾を削除します。

curl -u weblogic:welcome1 -H 'Content-Type: application/json' -X DELETE
  'https://supplier.example.com:7002/oam/services/rest/_replication/201409231
  329353668'

19.5 変換ルールのカスタマイズ

変換ルールはAPSによって使用され、必要に応じてルールを変更できます。

次の例に示した変換ルールは、Access Managerによって提供されるデフォルト・ルールです。これらのOOTBルールをオーバーライドするようにクローンを構成できます。この項では、これらのルールの一部を変更する方法と、これらのカスタム・ルールを認識するようにAccess Managerを構成する方法について説明します。

ファイル(transformationRules.txtなど)にカスタム変換ルールを指定します。次のように指定されたデフォルトのOOTB変換ルールをコピーして、必要に応じてルールを変更することをお薦めします。

<?xml version="1.0" encoding="UTF-8"?>
<mdc-transform-rule>
<changes-to-include entity-path="/policy"/>
<changes-to-include entity-path="/oauth"/>
<changes-to-include entity-path="/IDM"/>
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Agent/WebGate/Instance" />
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules"/>
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/oamproxy"/>
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/Sme/SessionConfigurations"/>
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile">
<ignore attribute-match="/OAMSERVER/serverprotocol"/>
<ignore attribute-match="/OAMSERVER/serverhost"/>
<ignore attribute-match="/OAMSERVER/serverport"/>
<ignore attribute-match="/OAMSERVER/serversslterminated"/>
<ignore attribute-match="/HostAlias/oamserverHttps/serverprotocol"/>
<ignore attribute-match="/HostAlias/oamserverHttps/serverhost"/>
<ignore attribute-match="/HostAlias/oamserverHttps/serverport"/>
</changes-to-include>
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER">
<ignore attribute-match="/serverprotocol"/>
<ignore attribute-match="/serverhost"/>
<ignore attribute-match="/serverport"/>
<ignore attribute-match="/serversslterminated"/>
</changes-to-include>
<changes-to-include entity-path="/config/NGAMConfiguration/DataCenterConfiguration/Cluster">
<ignore attribute-match="/DataCenterType"/>
<ignore attribute-match="/ClusterId"/>
<ignore attribute-match="/WriteEnabledFlag"/>
</changes-to-include>
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Descriptors/OAMSEntityDescriptor" />
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Federation/IdentityProvider" />
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Federation/ServiceProvider" />
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/STS/fedattributeprofiles" />
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/STS/fedpartnerprofiles" />
<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/STS/fedserverconfig" />
</mdc-transform-rule>

ルール・ドキュメントには、システム構成アーティファクトのXPathをクローンにレプリケートすることが記述されます。XPathのエントリのレプリケーション中になんらかの変換を行う必要がある場合、それをそのクローンの置換ルールとして提供できます。クローンにレプリケートする新しいXPathを追加するには、前出のXMLドキュメントをテンプレートとして使用して、新しい変換XMLファイルを作成します。必要に応じて、XPathを追加および削除します。たとえば、次のXPathを<mdc-transformation-rule>ノードの子として追加し、そのファイルをクローンのファイル・システムに保存すると、「使用可能なサービス」が変更されます。

次の環境変数を、$MW_HOME/user_projects/domains/OAMDomain/binにあるsetDomainEnv.sh (LinuxまたはUNIX)またはsetDomainEnv.cmd (Windows)ファイルのEXTRA_JAVA_PROPERTIESに追加します。
```
-Doracle.oam.MDCRuleFile=/scratch/transformationRules.txt
```
各クローンは異なる変換ルールを使用できます。図19-3は、これらのカスタム・ルールの適用方法を示しています。

図19-3 カスタム変換ルールの適用

「図19-3 カスタム変換ルールの適用」の説明
クローン管理および管理対象サーバーを再起動します。

この変換ルールにより、Webゲート・エージェントの定義は変更されません。次の情報では、PrimaryServerList属性とlogoutRedirectUrl属性に関してこれらの変更を修正する方法について説明します。

次の例の変換ルールを使用して、クローン環境からのAccess Managerサーバー・ホストでPrimaryServerListおよびlogoutRedirectUrl属性を更新できます。この変更は、oam-config.xmlファイル内で確認できます。このファイル内のPrimaryServerList属性の値は、${DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER/serverhost}と等しい値に置き換わります(たとえば、oam1-lon.example.com)。このルールには、プライマリ・リスト内のすべてのサーバーが更新されるという制限があります。


<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Agent/WebGate/Instance">
  <replace attribute-match="/*/PrimaryServerList/*/host" value-match="(.*)">
   <replace-with n="1">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER/serverhost}</replace-with>
  </replace>
  <replace attribute-match="/*/UserDefinedParameters/logoutRedirectUrl" 
   value-match="(.*)<a target="_blank" href="://">://</a>(.*):(.*)/oam/server/logout">
  <replace-with n="1">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER/serverprotocol}</replace-with>
  <replace-with n="2">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER/serverhost}</replace-with>
  <replace-with n="3">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER/serverport}</replace-with>
  </replace>
  <replace attribute-match="/*/logoutRedirectUrl" 
   value-match="(.*)<a target="_blank" href="://">://</a>(.*):(.*)/oam/server/logout">
  <replace-with n="1">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER/serverprotocol}</replace-with>
  <replace-with n="2">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER/serverhost}</replace-with>
  <replace-with n="3">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER/serverport}</replace-with>
 </replace>
</changes-to-include>

次の例の変換ルールを使用して、PrimaryServerList内のサーバーを別のクローン・サーバーで更新できます。


<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Agent/WebGate/Instance">
    <replace attribute-match="/*/PrimaryServerList/0/host" value-match="(.*)">
        <replace-with n="1">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Instance/oam_server1/host}</replace-with>
    </replace>
    <replace attribute-match="/*/PrimaryServerList/1/host" value-match="(.*)">
        <replace-with n="1">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Instance/oam_server2/host}</replace-with>
    </replace>
</changes-to-include>

ノート:

oam_server1やoam_server2などのOAM管理対象サーバーを、デプロイメント中に指定した名前で更新する必要があります。

WebゲートとAccess Managerサーバーの間にはロード・バランサを使用することをお薦めします。この場合、複数のデータ・センターにわたってPrimaryServerListを更新する必要はなく、この変換ルールをXMLから削除できます。

次の例では、変換ルールを変更して、(Webゲート・エージェントではなく) WebgateAgent1およびWebgateAgent2エージェントについてのみPrimaryServerListを更新する方法を示します。


<changes-to-include entity-path="/config/NGAMConfiguration/DeployedComponent/Agent/WebGate/Instance">
    <replace attribute-match="/WebgateAgent1/PrimaryServerList/*/host" value-match="(.*)">
        <replace-with n="1">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER/serverhost}</replace-with>
    </replace>
    <replace attribute-match="/WebgateAgent2/PrimaryServerList/*/host" value-match="(.*)">
        <replace-with n="1">${/config/NGAMConfiguration/DeployedComponent/Server/NGAMServer/Profile/OAMServerProfile/OAMSERVER/serverhost}</replace-with>
    </replace>
</changes-to-include>

logoutRedirectUrl属性は、すべてのWebゲート・エージェントのログアウトURLプロトコル、ホストおよびポートを、クローンからのそれぞれの値で更新します。マスター環境ですべてのWebゲート・エージェントのログアウトURLを定義するためにロード・バランサをグローバルに使用している場合、クローン環境のログアウトURLを置き換える必要はなく、変換ルールを削除できます。DCCログインとログアウトURLを定義するためにDCC認証スキームおよびグローバル・ロード・バランサを使用している場合も、クローン環境のログインおよびログアウトURLを置き換える必要はなく、変換ルールを削除できます。

19.6 自動ポリシー同期の無効化

マスターおよびクローン・データ・センターでレプリケーション承諾を無効にしてから削除します。

次のコマンドを使用して既存のレプリケーション承諾を問い合せ、レプリケーション識別子replIdを取得します。これは、ステップ2からステップ4で使用します。
```
curl -k -u weblogic:password 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/agreements'
```
ノート:
複数のレプリケーション承諾が存在する場合、対応するクローン・データ・センターを問い合せてAPSを無効にする必要のある識別子を選択します。

クローン・データ・センターでレプリケーション承諾を無効にします。

curl -u weblogic:password -H 'Content-Type: application/json' -X PUT 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/replId' -d '{"enabled":"false","replicaType":"CONSUMER"}'

マスター・データ・センターでレプリケーション承諾を無効にします。

curl -u weblogic:password -H 'Content-Type: application/json' -X PUT 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/replId' -d '{"enabled":"false","replicaType":"SUPPLIER"}'

マスターおよびクローン・データ・センターからレプリケーション承諾を削除します。

curl -u weblogic:password -H 'Content-Type: application/json' -X DELETE 'https://oamadmin1-dc1.poc.com:7002/oam/services/rest/_replication/replId'

19.7 レプリケーションのベスト・プラクティス

ここでは、データ・レプリケーションの設定に役立つベスト・プラクティスをいくつか示します。

次の点および各項の情報は、データ・レプリケーションを設定する場合に考慮する必要があります。

クローニングの前に、できるだけ多数のポリシー・ドメイン・アーティファクトを作成しておくことをお薦めします。これにより、増分更新中のレプリケーション・マネージャの動作が効率的になります。
OAMサーバー・インスタンス・リストはCoherenceクラスタを作成するためのWell Knownアドレス(WKA)として使用されるため、このサーバー・インスタンス・リストに他のデータ・センター・サーバーを追加しないでください。
Webゲート・プロファイルがセカンダリ・サーバー・リストのリモート・データ・センターを指せるようにするには、「その他」オプションを使用して、リモート・データ・センターのホストおよびポートの詳細をOAPに提供します。
「レプリケーション・ログの有効化」を参照してください。
「ユーザー識別子の変更」を参照してください。

19.7.1 レプリケーション・ログの有効化

レプリケーション承諾およびレプリケーション・ポーリングに関連する問題に関する詳細なログを取得するには、WLSTコマンドを実行して、ロガー'oracle.oam.replication'を有効にします。

setLogLevel(logger="oracle.oam.replication", level="TRACE:32", persist="0",
target="AdminServer")

これにより、次にAdminServerが停止されるまでの間にかぎり、ロガーが有効になります。ロガーの状態を再起動後も保持するには、persist属性を“1”.に設定します。

19.7.2 ユーザー識別子の変更

ユーザーのパスワードが後から変更された場合にレプリケーションに使用されるユーザーの認可ヘッダーを指定していない場合、レプリケーション承諾の作成時に、最新のユーザー・アイデンティティおよびパスワードでレプリケーション承諾を編集できます。

次のコマンドを実行します。

curl -u <repluser> -H 'Content-Type: application/json' -X PUT
'https://supplier.example.com:7002/oam/services/rest/_replication/201409231
329353668' -d '{"replicaType":"CONSUMER","config":{"entry":
{"key":"authorization","value":"BASIC d2VibG9naWM6d2VsY29tZTE="}}}'