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は、レプリケーション・フローを示しています。
各クローンはマスターから変更内容をプルします。事前構成された時間間隔の経過後に、レプリケーション・スレッドがクローンで動作し、マスター環境で実行されているレプリケーション・サービス(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 データ・レプリケーションの有効化
-
マスター・データ・センターで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.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ユーティリティを使用します。
このコマンドを実行すると、次のような結果になります。
-
変更内容をプルするクローンに関する詳細が格納されているマスターのレプリケーション承諾ストアにエントリが挿入されます。
-
変更内容をプルするマスターに関する詳細が格納されているクローンのレプリケーション承諾ストアにエントリが挿入されます。ポーリング間隔などのレプリケーション構成値も設定されます。
レプリケーション承諾を作成するには、次のようにします。
19.4.3 レプリケーション承諾の変更
この例では、pollIntervalの値が60秒に変更されます。
サービスは、変更を行う前に、レプリケーション承諾のステータスであるJSONオブジェクトを使用して応答します。更新済の構成を確認するには、レプリケーション承諾ステータスを再度フェッチする必要があります。
19.4.4 レプリケーション承諾の削除
先にレプリケーション承諾を無効にしてから、それをクローンおよびマスター・データ・センターから削除します。
-
次のようにクローンでレプリケーション承諾を無効にします。
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は、これらのカスタム・ルールの適用方法を示しています。
-
クローン管理および管理対象サーバーを再起動します。
この変換ルールにより、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.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="}}}'