ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11gリリース2 (11.1.2.2) for All Platforms
B69533-09
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

7 マルチデータ・センターの使用

Oracle Access Management Access Managerでは、複数のデータ・センターに渡ってそのデータの同一のコピーを提供することにより、ディレクトリ・サービス・データの配布が可能です。複数のデータ・センターが拡張可能なデプロイメント・モデルを提供することで、数百万人ものユーザーのアクセス管理要件をサポートします。マルチデータ・センターのトポロジは、水平方向に拡大縮小します。つまり、複数ノードをクラスタ化することによって1つのデータ・センター内に収めたり、複数のデータ・センターにわたって構成することもできます。このモデルによって、ロード・バランシングが実現するとともに、データ・センターの1つが停止した場合のフェイルオーバーも可能になります。

この章の内容は次のとおりです。

7.1 マルチデータ・センターの概要

Access Manager 11gを使用する大規模な組織は一般的に、そのアプリケーションをマルチデータ・センターにデプロイして、負荷を分散し、データ・リカバリに対応します。マルチデータ・センターをデプロイすると、データ・センター間にシングル・サインオン(SSO)が構成されるので、ユーザー・セッションの詳細情報を透過的に転送できるようになります。データ・センターのスコープに含まれるものとしては、保護されたアプリケーション、Webゲート・エージェント、Access Managerサーバーおよびその他のインフラストラクチャ・エンティティ(アイデンティティ・ストアやデータベースなど)があります。(Access Manager 11gでは、アプリケーションが2つ以上のデータ・センターに分散されるというシナリオもサポートされます。)

Access Managerでサポートされるマルチデータ・センター・アプローチは、マスター/クローン型のデプロイメントであり、最初のデータ・センターがマスターとして指定され、クローンのデータ・センターがマスターをミラーリングします。マスター・データ・センターのクローニングには本番へのテスト(T2P)ツールが使用され、1つ以上の子データ・センターが作成されます。T2Pの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。(T2Pユーティリティは、データ・センターで使用されるAccess Managerドメインのレプリケートにも使用されます。)図7-1に、マルチデータ・センターのシステム・アーキテクチャを示します。

図7-1 マルチデータ・センターのシステム・アーキテクチャ

図7-1の説明が続きます
「図7-1 マルチデータ・センターのシステム・アーキテクチャ」の説明

データ・センターには、アプリケーション、データ・ストア、ロード・バランサなどが含まれます。各データ・センターに、Access Managerのフル・インストールが含まれます。WebLogic Serverドメインが複数データ・センターにまたがることはありません。グローバル・ロード・バランサは、HTTPトラフィックを地理的に最も近いデータ・センターにルーティングするように構成されます。(Oracle Accessプロトコルのトラフィックの管理には、ロード・バランサは使用されません。)さらに、ユーザー対データ・センターのアフィニティも保持されますが、セッション・アダプションによって、そのユーザーのセッションがすでに別のデータ・センターに存在することを示す有効な認証Cookie (OAM_ID)の提示に基づいてユーザー・セッションを作成することもできます。(セッション・アダプションは、ユーザーの再認証を伴うことも、そうでないこともあります。)

すべてのアプリケーションは、それぞれのデータ・センターでAccess Managerクラスタに対して構成されるWebゲート・エージェントによって保護されます。どのWebゲートにも、プライマリ・サーバー1つと1つ以上のセカンダリ・サーバーがあります。各データ・センターのWebゲート・エージェントには、プライマリ・リストに同じデータ・センターからのAccess Managerサーバー・ノードがあり、セカンダリ・リストに他のデータ・センターからのノードがあります。次の条件に該当するときは、ユーザー・リクエストを別のデータ・センターにルーティングすることも可能です。

  • データ・センターがダウンした。

  • 負荷が一時的に増大し、トラフィックの再分散が発生した。

  • 特定のアプリケーションが1つのデータ・センターのみにデプロイされている。

  • 負荷分散は1つのデータ・センター内で行うが、フェイルオーバーはデータ・センター間で行うようにWebゲートが構成されている。

次の各項で、マルチデータ・センターの仕組みとサポートされるトポロジについて詳しく説明します。

7.1.1 マルチデータ・センター・ソリューションの提供

次の各項で、マルチデータ・センター・ソリューションがどのように実装されるかを説明します。

7.1.1.1 マルチデータ・センターのためのCookie拡張

次の各項では、マルチデータ・センターによって拡張および使用されるSSO Cookieについて説明します。

7.1.1.1.1 OAM_ID Cookie

OAM_ID Cookieは、Access ManagerのためのSSO Cookieであり、全データ・センターにわたってMDC動作を有効にするのに必要な属性を保持します。同じSSOセッションでユーザーからの後続のリクエストが、マルチデータ・センター・トポロジ内の別のデータ・センターにルーティングされる場合は、構成済のセッション・アダプション・ポリシーによりセッションの採用がトリガーされます。セッション・アダプションとは、そのトポロジ内の別のデータ・センターにユーザーのセッションが存在することを示す有効な認証Cookie (OAM_ID)の提示に基づいて、データ・センターがそのユーザーのローカル・セッションを作成する動作のことです。(これは、そのユーザーの再認証を伴うことも、そうでないこともあります。)ユーザー・セッションがデータ・センターで作成されると、OAM_ID Cookieにそのデータ・センターのclusterid、sessionidおよびlatest_visited_clusteridが付加され、更新されます。

マルチデータ・センターのデプロイメントにおいて、OAM_IDはホスト・スコープのCookieとなります。そのドメイン・パラメータは、データ・センター全体でシングルトンな仮想ホスト名であるlogin.oracle.comに設定され、ロード・バランサ・レベルのユーザー・トラフィック・ルーティング・ルール(地理的アフィニティなど)に基づいて、グローバル・ロード・バランサによってAccess Managerデータ・センター内のAccess Managerサーバーにマップされます。OAM_ID Cookieには、Access Managerサーバー以外のアプリケーションからはアクセスできません。

7.1.1.1.2 OAMAuthn/ObSSO WebゲートCookie

OAMAuthnは11gのWebゲートCookieで、ObSSOは10gのWebゲートCookieです。認証と認可に成功すると、保護されたリソースへのアクセス権がユーザーに付与されます。その時点で、ブラウザは、サービスを行うデータ・センターのclusterid:sessionidを持つ有効なWebゲートCookieを取得します。認証に続く認可が複数のデータ・センターにわたっている場合は、ユーザー・リクエストを認可するデータ・センターが、WebゲートCookieからそのセッションの作成元であるclusteridを取得することで、セッション・アダプションをトリガーします。セッション・アダプションの後に、新しいセッションが現在のデータ・センター内に作成され、セッションの詳細が同期されます。


注意:

WebゲートCookieを認可時に更新することはできないため、新規作成されたsessionidを将来の認可参照用に永続化することはできません。この場合は、リモートのsessionidとローカルのsessionidがセッション索引付けを通してリンクされます。データ・センターに対するそれ以降の認可コールのときに、新しいセッションが作成されるのは次の場合です。

  • MDCが有効化されている。

  • WebゲートCookie内のsessionidに一致するセッションがローカルのデータ・センター内に存在しない。

  • WebゲートCookie内のsessionidに一致するセッション索引を持つセッションが存在しない。

  • 有効なセッションが(MDCセッション同期ポリシーに基づく)リモートのデータ・センターに存在する。

これらの場合は、新しいセッションが、WebゲートCookie内のsessionidを参照するセッション索引とともに、ローカルのデータ・センター内で作成されます。

7.1.1.1.3 OAM_GITO (Global Inactivity Time Out) Cookie

OAM_GITOは、認可レスポンスとして設定されるドメインCookieです。認証プロセスのセッション詳細がOAM_ID Cookieに記録されます。認可が別のデータ・センターにホップする場合は、認可リクエストを処理するデータ・センター内で新しいセッションを作成し、新しいセッションのセッション索引を受信sessionidとして設定することにより、セッション・アダプションが発生します。それ以降の認証リクエストでは、OAM_ID Cookie内のclusterid:sessionidマッピングのみが認識されているため、認可のためにセッションが別のデータ・センターにホップしても、そのことは認証リクエストの際に認識されません。このギャップに対処するために、OAM_GITO Cookie(複数のWebゲート・エージェントを対象とするタイムアウト追跡にも利用されます)が導入されています。

認可時に、OAM_GITO CookieがドメインCookieとして設定されます。それ以降の認証リクエストに対しては、OAM_GITO Cookieの内容が読み取られて、最新のセッション情報および非アクティブ/アイドル・タイムアウトの値が特定されます。OAM_GITO Cookieに格納されているのは、次のデータです。

  • データ・センター識別子

  • セッション識別子

  • ユーザー識別子

  • 最終アクセス時間

  • トークン作成時間


注意:

OAM_GITO Cookieでは、すべてのWebゲートおよびAccess Managerサーバーが共通ドメイン階層を共有することが必要です。たとえば、サーバー・ドメインが.us.example.comの場合は、すべてのWebゲートが(少なくとも) .example.comを共通ドメイン階層として持つ必要があります。これでOAM_GITO Cookieを.example.comドメインで設定できるようになります。

7.1.1.2 認可時のセッション・アダプション

マルチデータ・センターのセッション・アダプションは、認可フローの中でサポートされます。認証に成功した後、OAMAuthn Cookieには、認証が行われたデータ・センターのクラスタID詳細が付加されます。認可時に、リクエストが別のデータ・センターにルーティングされる場合、ランタイムは、これがマルチデータ・センターのシナリオに該当するかどうかを判断し、有効なリモート・セッションを検索します。見つかった場合は、マルチデータ・センターのセッション・アダプション・プロセスがセッション・アダプション・ポリシーによりトリガーされ、認可リクエストを処理するデータ・センター内で新しいセッションが作成されます。


注意:

認可時のOAMAuthn Cookieの更新はサポートされていないため、新規作成されたセッションのセッション索引は、受信セッションIDのものに設定されます。

7.1.1.3 セッション索引付け

データ・センターに対する認可コール時に、ローカルのデータ・センターで、新しいセッションが、OAMAuth/ObSSO Cookie内のセッション識別子を参照するセッション索引とともに作成されます。これが発生するのは、次の条件のときです。

  • OAMAuth/ObSSO Cookie内のセッションIDに一致するセッションがローカルのデータ・センターに存在しない。

  • MDCが有効化されている。

  • OAMAuth/ObSSO Cookie内のセッションIDに一致するセッション索引を持つセッションが存在しない。

  • 有効なセッションがMDCセッション同期ポリシーに基づくリモートのデータ・センターに存在する。

7.1.2 サポートされるマルチデータ・センターのトポロジ

Access Managerでは、次に示すマルチデータ・センターのトポロジがサポートされます。

  • アクティブ/アクティブ・トポロジ。この場合、マスターとクローンのデータ・センターが正確なレプリカであり、同時にアクティブとなります。これらは、地理的位置などの定義済の基準に基づいて、様々なユーザーのセットに対応します。ロード・バランサによってトラフィックが適切なデータ・センターにルーティングされます。第7.1.2.1項「アクティブ/アクティブ・モード」を参照してください。


    注意:

    エージェント・フェイルオーバーのあるアクティブ/アクティブ・トポロジでは、エージェントのAccess Managerサーバーが一方のデータ・センターではプライマリとして構成され、他方のデータ・センターではセカンダリとして構成され、これによってフェイルオーバーのシナリオが支援されます。

  • アクティブ・スタンバイ/パッシブ・トポロジ。この場合、プライマリのデータ・センターが稼働可能であり、クローンのデータ・センターはそうではありませんが、プライマリのデータ・センターが停止したときに合理的な時間内に稼働を開始できます。第7.1.2.2項「アクティブ・スタンバイ/パッシブ・モード」を参照してください。

  • アクティブ/ホット・スタンバイ。この場合、データ・センターの1つがホット・スタンバイ・モードです。このとき、そのデータ・センターは他のデータ・センターが停止しないかぎり、積極的に使用されることはありません。第7.1.2.3項「アクティブ/ホット・スタンバイ」を参照してください。

7.1.2.1 アクティブ/アクティブ・モード

図7-2に、通常稼働時にアクティブ/アクティブ・モードに設定されているマルチデータ・センターを示します。ニューヨークのデータ・センターがマスターとして指定され、ポリシーおよび構成の変更はすべてこのデータ・センターのみで行われます。ロンドンのデータ・センターはクローンとして指定されており、T2Pのツールとユーティリティを使用して定期的にデータをニューヨークのデータ・センターと同期させます。地理的に異なる場所(米国およびヨーロッパ)のユーザーを、(アクセスされるアプリケーションの近さではなく)データ・センターへの地理的な近さに基づいて、適切なデータ・センター(ニューヨークまたはヨーロッパ)にルーティングするようにグローバル・ロード・バランサが構成されています。たとえば、米国にいるユーザー1からのリクエストはすべてニューヨークのデータ・センター(NYDC)にルーティングされ、ヨーロッパにいるユーザー2からのリクエストはすべてロンドンのデータ・センター(LDC)にルーティングされます。


注意:

この図のAccess Managerクラスタは互いに独立しており、同一のOracle WebLogicドメインに属してはいません。WebLogicドメインが複数のデータ・センターにまたがることはお薦めしません。

図7-2 アクティブ/アクティブ・デプロイメント・モード

図7-2の説明が続きます
「図7-2 アクティブ/アクティブ・デプロイメント・モード」の説明

この例では、仮にNYDCがリクエストで過負荷になった場合、グローバル・ロード・バランサはユーザー1のリクエストを、LDCにあるクローンのAccess Managerクラスタにルーティングするようになります。(ユーザーのOAM ID Cookieから)有効なセッションがマスター・クラスタ内にあると判断できるので、クローンのAccess Managerクラスタでは、認証も再認証も行わずに新しいセッションが作成されます。さらに、クローンのAccess ManagerクラスタがOracle Accessプロトコル(OAP)を使用してマスターのAccess Managerに対してセッションの詳細のバックエンド・リクエストを行うように、セッション・アダプション・ポリシーを構成することもできます。リモート・セッション(NYDCのセッション)を無効にして、ユーザーが一度に1つのデータ・センターのみでセッションを持つようにセッション・アダプション・ポリシーを構成することもできます。

図7-3は、マスター・クラスタが過負荷のとき、または停止したときにユーザーがどのように再ルーティングされるかを示しています。マスターのAccess Managerクラスタが完全に停止した場合は、クローンのAccess Managerクラスタがユーザー1のセッション詳細の取得を試行しますが、完全にアクセス不可能であるため、ユーザー1は強制的に再認証されることになり、新しいセッションがクローンのAccess Managerクラスタ内で確立されます。この場合は、前のセッションで保存されていた情報はすべて失われます。

図7-3 アクティブ/アクティブ・モードのフェイルオーバー

図7-3の説明が続きます
「図7-3 アクティブ/アクティブ・モードのフェイルオーバー」の説明

7.1.2.2 アクティブ・スタンバイ/パッシブ・モード

アクティブ/パッシブ・モードでは、データ・センターの1つがパッシブであり、プライマリのデータ・センターに障害が発生したときに合理的な時間内で稼働を開始させることができます。

7.1.2.3 アクティブ/ホット・スタンバイ

アクティブ/ホット・スタンバイ・モードでは、データ・センターの1つがホット・スタンバイ・モードです。これは、他のデータ・センターが停止しないかぎり、積極的にユーザーへの対応を行うことはありません。

7.1.3 マルチデータ・センターに対するAccess Managerのセキュリティ・モードの理解

MDCは、Oracle Accessプロトコル(OAP)チャネルを使用してデータ・センター間セッション管理操作とバック・チャネル通信を行います。MDCパートナ・プロファイルのセキュリティ・モードは、Access Managerサーバーに対して定義されているセキュリティ・モードと一致している必要があります(OPEN、SIMPLEまたはCERT)。


注意:

MDCパートナ・プロファイルは、各データ・センターが公開するものであり、他のデータ・センターがそのデータ・センターとの通信に使用します。MDCパートナの登録は、2段階のプロセスです。1つのMDCに3つのデータ・センターがあるとします。DC1で、10gまたは11g Webゲートを作成することによってMDCパートナ・プロファイルを公開します(DC1_MDC_Partner)。次に、DC1_MDC_PartnerをDC2およびDC3で、addPartnerForMultiDataCentreを使用して登録します。詳細は、第7.9.3項「addPartnerForMultiDataCentre」を参照してください。

7.1.3.1 OPENセキュリティ・モード

これは、Access Managerデプロイメントのデフォルトのモードです。構成は必要ありません。次に示すのは、WLSTのaddPartnerForMultiDataCentreコマンドで使用するためのサンプルの入力プロパティ・ファイルです。

remoteDataCentreClusterId=
 <CLUSTER ID OF REMOTE DC FOR WHICH THE AGENT IS BEING ADDED>
oamMdcAgentId=
 <AGENT ID OF THE REGISTERED PARTNER IN datacenter ABOVE>
PrimaryHostPort=<fully-qualified-host-name:OAM-port>
 for example:PrimaryHostPort=adc.example.com:5575
SecondaryHostPort=<fully-qualified-host-name:OAM-port>
 for example:SecondaryHostPort=adc.example.com:5577
AccessClientPasswd=<ACCESS CLIENT PASSWORD OF oamMdcAgentId IN datacenter>
oamMdcSecurityMode=OPEN
agentVersion=<WEBGATE AGENT VERSION 10g or 11g>
#NA ----> Not Applicable
trustStorePath=NA
keyStorePath=NA
globalPassPhrase=NA
keystorePassword=NA

7.1.3.2 SIMPLEセキュリティ・モード

Access ManagerサーバーをSIMPLEモードで設定するには、付録Cの「Access Managerの簡易モード通信の構成」の手順に従います。要約すると、各メンバー・データ・センターにMDCパートナ・プロファイルをSIMPLEモードで作成し、このプロファイルを他のデータ・センターのそれぞれに追加します。次に示すのは、WLSTのaddPartnerForMultiDataCentreコマンドで使用するためのサンプルの入力プロパティ・ファイルです。

remoteDataCentreClusterId=
 <CLUSTER ID OF REMOTE DC FOR WHICH THE AGENT IS BEING ADDED>
oamMdcAgentId=<AGENT ID OF THE REGISTERED PARTNER IN datacenter ABOVE>
PrimaryHostPort=<fully-qualified-host-name:OAM-port>
 for example:PrimaryHostPort=adc.example.com:5575
SecondaryHostPort=<fully-qualified-host-name:OAM-port>
 for example:SecondaryHostPort=adc.example.com:5577
AccessClientPasswd=<ACCESS CLIENT PASSWORD OF oamMdcAgentId IN datacenter>
oamMdcSecurityMode=SIMPLE
agentVersion=<WEBGATE AGENT VERSION 10g or 11g>
 
#Copy the oamclient-truststore.jks & oamclient-keystore.jks from 
#<DOMAIN_HOME>/output/webgate-ssl/ from 'datacenter with cluster ID #remoteDataCentreClusterId' above into the local DC say /scratch/MDCArtifacts/ and 
#refer them in the below parameters
 
trustStorePath=</scratch/MDCArtifacts/oamclient-truststore.jks>
keyStorePath=</scratch/MDCArtifacts/oamclient-keystore.jks>
 
#Use the online WLST command displaySimpleModeGlobalPassphrase() to list 
#the global passphrase in SIMPLE mode. Admins can also update this in the UI
#@ System Configuration-->Access Manager-->Access Manager Settings-->
#Access Protocol-->Simple Mode Configuration-->Global Passphrase. 
#globalPassPhrase & keystorePassword are the same for SIMPLE mode
 
globalPassPhrase=<passphrase resulted in using the above steps>
keystorePassword=<same as globalPassPhrase>

7.1.3.3 CERTセキュリティ・モード

Access ManagerサーバーをCERTモードで設定するには、付録Cの「Access Manager用の証明書モード通信の構成」の手順に従います。要約すると、各メンバー・データ・センターにMDCパートナをCERTモードで作成し、次の手順を使用してMDCパートナで使用されるキーストアclientTrustStore.jksおよびclientKeyStore.jksを生成します。

  1. 次のopensslコマンドをLinuxコマンド・プロンプトから実行してaaa_key.pemおよびaaa_req.pemを生成します。

    openssl req -new -keyout aaa_key.pem -out aaa_req.pem -utf8

    certreqコマンドを使用して証明書とチェーンを生成します。

  2. 次の手順を使用してaaa_cert.pemを作成します。

    1. aaa_req.pemをテキスト・エディタで開いて内容をコピーします。

      末尾のスペースは除外して選択します。

    2. コピーしたテキストをSigncsrに貼り付けます。

      「-----BEGIN CERTIFICATE REQUEST-----および-----END CERTIFICATE REQUEST-----」も含めます。

    3. 出力をテキスト・エディタにコピーし、aaa_cert.pemとして保存します。

  3. 次の手順を使用してaaa_chainを作成します。

    1. certreqを開きます。

    2. chain.pemをクリックし、内容をコピーしてテキスト・エディタに貼り付け、aaa_chain.pemとして保存します。

      先頭と末尾のスペースは除外して選択します。

  4. 次のコマンドを使用して秘密鍵(aaa_key.pem)を暗号化します。

    openssl rsa -in aaa_key.pem -passin pass: -out aaa_key.pem -passout pass:Welcome1 -des

    このコマンドで使用されるパスワードは、アクセス・クライアント・パスワードまたはエージェント・キー・パスワードとしてMDCパートナの登録時に定義される必要があります。

  5. aaa_key.pem、aaa_cert.pemおよびaaa_chain.pemを一時的な場所にコピーします。

    たとえば、/tmp/clientCertArtifacts/です。

  6. 次のコマンドのいずれかを使用してaaa_cert.pemおよびaaa_key.pemをDER形式に変換します。

    -openssl x509 -in /tmp/clientCertArtifatcs/aaa_cert.pem -inform PEM -out 
 /tmp/clientCertArtifatcs/aaa_cert.der -outform DER;

    -openssl pkcs8 -topk8 -nocrypt -in /tmp/clientCertArtifatcs/aaa_key.pem 
 -inform PEM -out /tmp/clientCertArtifatcs/aaa_key.der -outform DER;

  7. 次の手順を使用して、aaa_key.derおよびaaa_cert.derをclientKeyStore.jksにインポートし、aaa_chain.pemをclientTrustStore.jksにインポートします。

    -cd $IDM_HOME/oam/server/tools/importcert/;

-unzip importcert.zip;

-java -cp importcert.jar 
 oracle.security.am.common.tools.importcerts.CertificateImport -keystore 
 /tmp/clientCertArtifatcs/clientKeyStore.jks -privatekeyfile 
 /tmp/clientCertArtifatcs/aaa_key.der -signedcertfile 
 /tmp/clientCertArtifatcs/aaa_cert.der -storetype jks -genkeystore yes

-keytool -importcert -file /tmp/clientCertArtifatcs/aaa_chain.pem -trustcacerts 
 -keystore /tmp/clientCertArtifatcs/clientTrustStore.jks -storetype JKS

    指示に従ってキーストアのパスワードを入力します。パスワードは、WLSTのaddPartnerForMultiDataCentreコマンドの入力プロパティ・ファイルでも定義されている必要があります。

  8. Webゲートの証明書作成時に行わなかった場合は、前の手順で使用したのと同じ、Oracle提供のimportcert.jarを使用して、aaa_key.derおよびaaa_cert.der形式の証明書を.oamkeystoreにインポートします。

    -java -cp importcert.jar 
 oracle.security.am.common.tools.importcerts.CertificateImport 
 -keystore /scratch/Oracle/Middleware/domains/
 base_domain/config/fmwconfig/.oamkeystore -privatekeyfile 
 /tmp/clientCertArtifacts/aaa_key.der -signedcertfile 
 /tmp/clientCertArtifacts/aaa_cert.der -alias mycertmode1 -storetype JCEKS

    aliasは、Access ManagerでCERTモード設定時に定義された別名です。

次に示すのは、WLSTのaddPartnerForMultiDataCentreコマンドで使用するためのサンプルの入力プロパティ・ファイルです。

remoteDataCentreClusterId=
 <CLUSTER ID OF REMOTE DC FOR WHICH THE AGENT IS BEING ADDED>
oamMdcAgentId=<AGENT ID OF THE REGISTERED PARTNER IN datacenter ABOVE>
PrimaryHostPort=<fully-qualified-host-name:OAM-port> 
 for example:PrimaryHostPort=adc.example.com:5575
SecondaryHostPort=<fully-qualified-host-name:OAM-port>
 for example:SecondaryHostPort=adc.example.com:5577
AccessClientPasswd=<ACCESS CLIENT PASSWORD OF oamMdcAgentId IN datacenter>
oamMdcSecurityMode=CERT
agentVersion=<WEBGATE AGENT VERSION 10g or 11g>
 
trustStorePath=</tmp/clientCertArtifatcs/clientTrustStore.jks >
keyStorePath=</tmp/clientCertArtifatcs/clientKeyStore.jks >
 
globalPassPhrase=NA
 
#use keystore password used for generating keystore in the previous step
keystorePassword=<keystore password given while generating keystore>

7.2 マルチデータ・センター・デプロイメントの理解

マルチデータ・センター・デプロイメントでは、各データ・センターにAccess Managerのフル・インストールが含まれます。WebLogic Serverドメインが複数のデータ・センターにまたがることはありません。グローバル・ロード・バランサによってユーザーからデータ・センターへのアフィニティが維持されますが、ユーザー・リクエストが別のデータ・センターにルーティングされることもあります。

  • データ・センターが停止したとき。

  • 負荷が一時的に増大し、トラフィックの再分散が発生したとき。

  • 各データ・センターが他のミラーではないとき。たとえば、アプリケーションの中には1つのデータ・センターにしかデプロイできないものがあります。

  • Webゲートが、データ・センター内でロード・バランシングを行い、複数データ・センターにまたがるフェイルオーバーを行うように構成されている。

図7-4に、基本的なマルチデータ・センター・デプロイメントを示します。

図7-4 マルチデータ・センター・デプロイメント

図7-4の説明が続きます
「図7-4 マルチデータ・センター・デプロイメント」の説明

次の各項で、様々なデプロイメント・シナリオを説明します。


注意:

バックチャネル通信に使用されるOAP接続では、ロード・バランシングやフェイルオーバーはサポートされないので、ロード・バランサを使用する必要があります。

7.2.1 セッション・アダプション: 再認証、セッション無効化、セッション・データ取得なし

次のシナリオは、セッション・アダプション・ポリシーが、再認証、リモート・セッション無効化およびリモート・セッション・データ取得のどれも行わないように構成されている場合のフローを示しています。ユーザーにはDC1とのアフィニティがあることを前提としています。

  1. ユーザーがDC1によって認証されます。

    認証に成功すると、OAM_ID Cookieは、DC1を参照する一意のデータ・センター識別子が付加され、ユーザーはDC1内のAccess Managerで保護されたアプリケーションにアクセスできるようになります。

  2. DC2内にデプロイされたアプリケーションにアクセスすると、ユーザーはグローバル・ロード・バランサによってDC2にルーティングされます。

  3. DC2内のAccess Managerに対して、DC1で発行された付加情報付きOAM_ID Cookieが提示されます。

    検証に成功すると、DC2のAccess ManagerはこのユーザーがリモートのDC1からルーティングされたことを認識します。

  4. DC2のAccess Managerはセッション・アダプション・ポリシーを調べます。

    このセッション・アダプション・ポリシーは、再認証、リモート・セッション無効化およびリモート・セッション・データ取得を行わないように構成されています。

  5. DC2のAccess Managerは、DC1のOAM_ID Cookieで提示された情報(存続期間、ユーザー)を使用してローカル・ユーザー・セッションを作成し、静的セッション情報($userレスポンス)を再初期化します。

  6. DC2のAccess Managerは、OAM_ID Cookieを自身のデータ・センター識別子で更新します。

    データ・センター・チェーンもOAM_ID Cookieに記録されます。

  7. 次に、ユーザーはDC1内のAccess Managerで保護されているアプリケーションにアクセスし、グローバル・ロード・バランサによって再びDC1にルーティングされます。

  8. DC1のAccess Managerに対して、DC1が発行してDC2で更新されたOAM_ID Cookieが提示されます。

    検証に成功すると、DC1のAccess ManagerはこのユーザーのセッションがDC1とDC2の両方にあることを認識します。

  9. DC1のAccess Managerは、OAM_ID Cookieで参照されているセッションの特定を試みます。

    • 見つかった場合は、DC1のセッションが更新されます。

    • 見つからない場合、DC1のAccess Managerは、再認証、リモート・セッション無効化およびリモート・セッション・データ取得なしで構成されているセッション・アダプション・ポリシーを調べます。

  10. DC1のAccess Managerは、自身のデータ・センター識別子でOAM_ID Cookieを更新し、データ・センター・チェーンをDC2と同様に記録します。

7.2.2 セッション・アダプション: 再認証なし、セッション無効化およびセッション・データ取得あり

次のシナリオは、セッション・アダプション・ポリシーが、再認証を行わないがリモート・セッション無効化およびリモート・セッション・データ取得を行うように構成されている場合のフローを示します。ユーザーにはDC1とのアフィニティがあることを前提としています。

  1. ユーザーがDC1によって認証されます。

    認証に成功すると、OAM_ID Cookieに、DC1を参照する一意のデータ・センター識別子が付加されます。

  2. DC2内にデプロイされたアプリケーションにアクセスすると、ユーザーはグローバル・ロード・バランサによってDC2にルーティングされます。

  3. DC2内のAccess Managerに対して、DC1で発行された付加情報付きOAM_ID Cookieが提示されます。

    検証に成功すると、DC2のAccess ManagerはこのユーザーがリモートのDC1からルーティングされたことを認識します。

  4. DC2のAccess Managerはセッション・アダプション・ポリシーを調べます。

    このセッション・アダプション・ポリシーは、再認証は行わないが、リモート・セッション無効化およびリモート・セッション・データ取得を行うように構成されています。

  5. DC2のAccess Managerは、DC1のAccess Managerへのバックチャネル(OAP)コール(セッション識別子が含まれる)を行い、セッション・データを取得します。

    DC1のセッションは、データ取得の後に終了となります。セッション参照が正しくないことが原因でこの手順が失敗した場合は、ローカル・セッションが作成されます(第7.2.1項「セッション・アダプション: 再認証、セッション無効化、セッション・データ取得なし」を参照)。

  6. DC2のAccess Managerは、OAM_ID Cookieで提示された情報(存続期間、ユーザー)を使用してローカル・ユーザー・セッションを作成し、静的セッション情報($userレスポンス)を再初期化します。

  7. DC2のAccess Managerは、OAM_ID Cookieを自身のデータ・センター識別子で書き換えます。

  8. 次に、ユーザーはDC1のAccess Managerで保護されているアプリケーションにアクセスし、グローバル・ロード・バランサによってDC1にルーティングされます。

  9. DC1のAccess Managerに対して、DC2で発行されたOAM_ID Cookieが提示されます。

    検証に成功すると、DC1のAccess ManagerはこのユーザーのセッションがDC2にあることを認識します。

  10. DC1のAccess Managerは、DC2のAccess Managerへのバックチャネル(OAP)コール(セッション識別子が含まれる)を行い、セッション・データを取得します。

    セッションが見つかった場合は、取得したデータを使用してセッションが作成されます。見つからない場合は、DC1のOAMサーバーによって新しいセッションが作成されます。DC2のセッションは、データ取得の後に終了となります。

7.2.3 セッション・アダプション: 再認証およびセッション無効化なし、オンデマンドのセッション・データ取得あり

マルチデータ・センターでは、非ローカル・セッションが終了されず、ローカル・セッションがリモートDCから取得されたセッション・データを使用して作成されることを除き、再認証なしのセッション・アダプションをサポートします。OAM_ID Cookieが更新され、現在どのデータ・センターにアクセスしているかを示す属性が含まれることに注意してください。

7.2.4 異なるデータ・センターで処理される認証および認可リクエスト

認証リクエストの処理はニューヨークのデータ・センター(NYDC)で行われるが、ユーザー・アフィニティが理由で認可リクエストはロンドンのデータ・センター(LDC)に提示されるシナリオについて考えます。リモート・セッション終了が有効化されている場合は、マルチデータ・センターをシームレスに操作するためにOAM_ID Cookie、OamAuthn/ObSSO認可CookieおよびGITO Cookieの組合せが必要になります。このフロー(およびその後の図7-5)で、これを示します。ユーザーとNYDCとの間にアフィニティがあることを前提とします。

  1. APP1にアクセスすると、ユーザーはNYDCによる認証を受けます。

    認証に成功すると、OAM_ID Cookieに、NYDCを参照する一意のデータ・センター識別子が付加されます。これに続く認可コールは、アクセスされるリソースのプライマリ・サーバー、つまりNYDCによって処理されます。認可が行われると、NYDCの識別子(クラスタID)を保持する認可Cookieが生成され、ユーザーにはAPP1へのアクセス権が付与されます。

  2. ユーザーは、LDCにあるAPP2へのアクセスを試みます。

  3. APP2のWebゲートは、有効なセッションがLDCの中で見つからないため、認証を開始します。

    ユーザー・アフィニティが理由で、認証リクエストはNYDCにルーティングされ、ここでシームレスに認証が行われます。OamAuthn Cookieの内容が生成されて、APP2のWebゲートとの間で共有されます。

  4. APP2のWebゲートは、これに続く認可リクエストを、APP2のプライマリ・サーバーであるLDCに、生成済の認可Cookieとともに転送します。

    認可時に、LDCはこれがマルチデータ・センターのシナリオであり、有効なセッションがNYDCに存在すると判断します。この場合の認可は、構成済のセッション・アダプション・ポリシーによりリモート・セッションを同期させることによって行われます。

  5. 認可時にLDCで新しいセッションが作成され、受け取ったセッションIDが新しいセッションの索引として設定されます。

    これ以降の認可コールは、索引によるセッション検索でLDC内の有効なセッションが返されるかぎり、受け入れられます。認可のたびに、GITO CookieがクラスタID、セッションIDおよびアクセス日時で更新されます。GITO Cookieは認可レスポンスとして毎回書き換えられます。

    同じユーザーからのそれ以降の認証リクエストをNYDCが受け取った場合は、OAM_ID CookieとGITO Cookieの情報を使用して、どのデータ・センターにそのユーザーの最新のセッションがあるかが特定されます。構成済のセッション・アダプション・ポリシーに基づいて、マルチデータ・センターのフローがシームレスにトリガーされます。

図7-5 異なるデータ・センターで処理されるリクエスト

図7-5の説明が続きます
「図7-5 異なるデータ・センターで処理されるリクエスト」の説明

7.2.5 ログアウトとセッション無効化

マルチデータ・センターのシナリオでは、ログアウトによって確実にすべてのデータ・センターのすべてのサーバー側セッションとすべての認証Cookieが消去されます。セッション無効化の場合は、バックチャネルを介してセッション・アーティファクトを終了させても、Webゲートで保持されているセッションCookieおよび状態情報が削除されることはありません。ただし、サーバー・セッションがないため認可に失敗し、その結果として再認証が行われます。セッション無効化を行わない場合は、ログアウトによって、現在のSSOセッションに属するすべてのサーバー側セッションがすべてのデータ・センターから消去されます。このフロー(およびその後の図7-6)で、ログアウトを示します。ユーザーとNYDCとの間にアフィニティがあることを前提とします。

  1. NYDCとのアフィニティを持つユーザーが、NYDCでの認証成功後にAPP1へのアクセス権を獲得します。

  2. ユーザーは、APP2へのアクセスを試みます。

    この時点で、ユーザー・セッションがSSOの一部としてNYDCおよびLDCに存在します(第2.4.5項を参照)。

  3. ユーザーは、APP1からログアウトします。

    アフィニティが理由で、このログアウト・リクエストはNYDCに到達します。

  4. NYDCのサーバーは、ユーザーのSSOセッションを終了させ、すべてのSSOパートナからログアウトします。

  5. NYDCのサーバーはOAPセッション終了リクエストを、SSOセッションに関連付けられているすべての関連データ・センターに送信します。これには、LDCも含まれます。

    この結果として、SSOに関連付けられているすべてのユーザー・セッションがすべてのデータ・センターから消去されます。

図7-6 ログアウトとセッション無効化

図7-6については周囲のテキストで説明しています。

7.3 マルチデータ・センターのデプロイの前提事項

マルチデータ・センターをデプロイするには、次の前提事項が満たされている必要があります。

  • 単一のロード・バランサがすべてのデータ・センター・クラスタのフロント・エンドとなる必要があります。このロード・バランサは、ユーザー・セッション内のすべてのリクエストを一貫して同じバックエンド・サーバーに送信する必要があり(永続性、固定性)、トラフィックを地理的にルーティングする必要があります(地理的アフィニティ)。

  • Access Managerおよびエージェントがデプロイされているマシンのクロックが同期している必要があります。MDCではないAccess Managerクラスタでは、Webゲート・エージェントのクロックがAccess Managerサーバーと同期している必要があります。この要件は、MDCにも適用されます。クロックが同期していない場合は、トークン検証の一貫性がなくなり、結果として、トークン失効までの期間、有効期間、タイムアウトなどに関する動作が期待どおりではなくなります。

  • マルチデータ・センター・トポロジ内のアイデンティティ・ストアの名前は同一であることが必要です。

  • 最初のデータ・センターがマスターとして指定され、その他のデータ・センターのためにクローニングされます(T2Pのツールを使用)。

  • 構成およびポリシーに関するすべての変更は、T2Pツールの一部として提供されているWLSTのコマンドを使用して、マスターからクローンに伝播されます。

  • データ・センターはそれぞれ異なるWebLogicドメインで、インストール・トポロジは同一です。

  • これらのデータ・センター間にファイアウォールがある場合は、OAPチャネル経由でのデータ・センター間通信を許可する必要があります。

  • パートナ(Webゲートまたはエージェント)は、単一のデータ・センターに固定されています。パートナ登録は個々のデータ・センターで行われます。

7.4 マルチデータ・センターのデプロイ

アクティブ/アクティブ・トポロジでは、マスターとクローンのデータ・センターは互いの正確なレプリカです(アプリケーション、データ・ストアなど)。これらは同時にアクティブであり、定義済の基準(たとえば地理的位置)に基づいて、それぞれ異なるユーザー・セットに対応します。ロード・バランサによってトラフィックが適切なデータ・センターにルーティングされます。同一のAccess Managerクラスタが両方のロケールにデプロイされ、ニューヨークがマスター、ロンドンがクローンとして指定されます。


注意:

エージェント・フェイルオーバーのあるアクティブ/アクティブ・トポロジでは、エージェントのAccess Managerサーバーが一方のデータ・センターではプライマリとして構成され、他方のデータ・センターではセカンダリとして構成され、これによってフェイルオーバーのシナリオが支援されます。

図7-7に、アクティブ/アクティブ・モードでのマルチデータ・センター・デプロイメントのトポロジを示します。ニューヨークのデータ・センターがマスターとして指定され、ポリシーおよび構成の変更はすべてこのデータ・センターのみで行われます。ロンドンのデータ・センターはクローンとして指定されており、T2Pのツールとユーティリティを使用して定期的にデータをニューヨークのデータ・センターと同期させます。地理的に異なる場所(米国およびヨーロッパ)のユーザーを、(アクセスされるアプリケーションの近さではなく)データ・センターへの地理的な近さに基づいて、適切なデータ・センター(ニューヨークまたはヨーロッパ)にルーティングするようにグローバル・ロード・バランサが構成されています。たとえば、米国にいるユーザー1からのリクエストはすべてニューヨークのデータ・センター(NYDC)にルーティングされ、ヨーロッパにいるユーザー2からのリクエストはすべてロンドンのデータ・センター(LDC)にルーティングされます。

図7-7 アクティブ/アクティブ・トポロジ

図7-7の説明が続きます
「図7-7 アクティブ/アクティブ・トポロジ」の説明

グローバル・ロード・バランサはセッションの固定性を維持するように構成されているので、ユーザーが特定のデータ・センターに割り当てられた後は、そのユーザーからのリクエストはすべて同じデータ・センターにルーティングされます。この例では、ユーザー1は常にニューヨークのデータ・センターにルーティングされ、ユーザー2はロンドンのデータ・センターにルーティングされます。

各データ・センターでのユーザー・リクエストは、アクセスされるアプリケーションに応じて異なるWebゲートによって捕捉されます。各Webゲートには、プライマリ・サーバーとして構成された同じデータ・センター内のAccess Managerクラスタの様々なノードがあります。この場合、Webゲートはローカル・データ・センターのロード・バランシングとフェイルオーバーを行います。


注意:

管理者は、負荷の特性に応じて様々な順序で柔軟に各Webゲートのプライマリ・サーバーを構成できます。各データ・センターでモニタリング・スクリプトを実行すると、Access Managerコンポーネント(Webゲートやサーバー)が応答しなくなったことが検出されるので、管理者はロード・バランサを再構成してユーザー・トラフィックを別のデータ・センターに転送できます。

負荷を全世界に分散するために、任意の数のクローン・データ・センターを構成できます。唯一の条件は、T2Pを使用してすべてのクローン・データ・センターが単一のマスターと同期されていることです。次の図7-8には、5つのデータ・センターにまたがるアクティブ/アクティブのマルチデータ・センター・デプロイメントを示します。

図7-8 複数のデータ・センターにまたがるアクティブ/アクティブ・トポロジ

図7-8の説明が続きます
「図7-8 複数のデータ・センターにまたがるアクティブ/アクティブ・トポロジ」の説明

7.5 Access Managementコンポーネント間のロード・バランシング

前述のトポロジは、エンド・ユーザーのHTTPトラフィックを様々なデータ・センターにルーティングするグローバルおよびローカルのロード・バランサを示しています。さらに、顧客は、ロード・バランサをAccess Managerのコンポーネント間にデプロイし、仮想ホスト名を使用してAccess Managerコンポーネントの構成を単純化することもできます。たとえば、NYDCの各Webゲートでプライマリ・サーバーをssonode1.ny.acme.com、ssonode2.ny.acme.comなどと構成するかわりに、すべてが同じ仮想ホスト名(たとえばsso.ny.acme.com)を指し、ロード・バランサがDNSを解決してクラスタ内の各ノードに転送することもできます。ただし、Access Managerコンポーネント間にロード・バランサを導入するときは、次の制約事項に注意してください。

  • OAP接続は永続的であり、アイドル状態になっている場合でも、構成可能な期間の間はそれらの接続をオープンしておく必要があります。

  • ロード・バランサが接続を終了する前に、接続をリサイクルするようにWebゲートを構成する必要があります。ただし、ロード・バランサがTCPリセットをWebゲートとサーバーの両方に送信でき、確実に接続がクリーンアップされる場合は除きます。

  • ロード・バランサは、OAP接続を各WebゲートのアクティブなAccess Managerサーバー間で均等に分散する(OAP接続を接続元IPに従って分散する)必要があります。このようにしない場合は、負荷の偏りが発生する可能性があります。

図7-9に、ローカルのロード・バランサ(LBR 3およびLBR 4)が各データ・センターのクラスタのフロント・エンドとなっているデプロイメント・トポロジのバリエーションを示します。Oracle HTTP Server (OHS)をこれらのロード・バランサとして使用できます。OAPトラフィックはデータ・センター内のWebゲートとAccess Managerクラスタとの間を流れますが、ロード・バランサがDNSルーティングを実行することによって、仮想ホスト名が使用できるようになります。

図7-9 Access Managerコンポーネントのロード・バランシング

図7-9の説明が続きます
「図7-9 Access Managerコンポーネントのロード・バランシング」の説明

図7-10に、デプロイメント・トポロジのもう1つのバリエーションを示します。このトポロジでは、グローバル・ロード・バランサ(GLBR2)が導入されており、ローカル・ロード・バランサ(LBR3およびLBR4)のフロント・エンドとなっています。この場合は、ホスト名の仮想化がデータ・センター内だけでなく、複数データ・センター間でも可能です。各データ・センター内のWebゲートは、ロード・バランシングはローカルで行うが、フェイルオーバーはリモートで行うように構成されます。このトポロジの主な利点の1つは、スタックの全レイヤーで高可用性が保証されることです。データ・センターのAccess Managerクラスタ全体が停止した場合でも、そのデータ・センターのWebゲートは他のデータ・センターのAccess Managerクラスタにフェイルオーバーします。

図7-10 ローカル・ロード・バランサのフロント・エンドとなるグローバル・ロード・バランサ

図7-10の説明が続きます
「図7-10 ローカル・ロード・バランサのフロント・エンドとなるグローバル・ロード・バランサ」の説明

使用中のロード・バランサによるAccess Managerサーバーのヘルス・モニタリングの詳細は、第12.7項「Access Managerサーバーのヘルス・モニタリング」を参照してください。

7.6 マルチデータ・センターの設定

MDC機能は、デフォルトでは無効になっています。Access Manager MDCをデプロイするには、最初にAccess Managerクラスタを1つ設定し、すべてのMDCグローバル構成を設定し、このクラスタをマスター・データ・センターとして指定します。この手順には、第7.9項「マルチデータ・センターのためのWLSTのコマンド」で説明するコマンドの実行も含まれています。


注意:

WebLogic Scripting Toolの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

次のドキュメントで説明しているT2Pプロセスを使用して、マスターから、必要な数のデータ・センターをクローニングします。

  • WebLogic Serverを使用しているときのT2Pの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

  • Websphere Serverを使用しているときのT2Pの詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementサードパーティ・アプリケーション・サーバー・ガイド』を参照してください。

次の手順で、詳しく説明します。

  1. プライマリのAccess Managerデータ・センターを設定し、マスターとして指定します。

    このマルチデータ・センターは、既存のAccess Managerクラスタでも、バニラ・インストールでもかまいません。Access Managerブートストラップによって一意のclusterIdがAccess Managerクラスタに割り当てられます。カスタムのclusterIdを設定するには、WLSTのsetMultiDataCentreClusterNameコマンドを使用します(第7.9.7項「setMultiDataCentreClusterName」を参照)。

    1. 基本的な構成を行います。

      これには、LDAPストアの設定や、セキュリティ・モード(SIMPLE/CERT)の構成が含まれます。

    2. WLSTのenableMultiDataCentreModeコマンドを実行し、MDCを有効にします。

      これによって、グローバル構成が適用されます。

    3. グローバル・ロード・バランサを構成します。

    4. WLSTのvalidateMDCConfig()コマンドを実行し、MDC構成を検証します。

    5. 管理サーバーを再起動します。

    6. このAccess Managerクラスタをマスター・データ・センターとして指定します。

      enableMultiDataCentreModeにより、Access Managerクラスタがデフォルトでマスターとして指定されます。DCのタイプを明示的に設定するには、WLSTのsetMultiDataCenterTypeコマンドを使用します。

    7. アプリケーションとWebゲートをデータ・センターにデプロイします。

  2. T2Pプロセスを使用して、必要な数のクラスタをマスター・データ・センターからクローニングします。


    注意:

    この手順には、R2PS1のクローニング手順が含まれています。R2PS2を使用する場合は、次のことを行います。

    • rcuを実行して、Access Managerに必要なスキーマをターゲットのデータ・センター・データベース上に作成します。

    • 手順aをスキップします。

    • -opssDataExport true引数を追加してcopyConfigコマンド(次の指定のとおり)を実行し、Access ManagerおよびOPSSのデータをエクスポートします。

      ./copyConfig.sh -javaHome $JAVA_HOME -archiveLoc 
 $T2P_HOME/oamt2pConfig.jar
 -sourceDomainLoc $WL_DOMAIN_HOME -sourceMWHomeLoc
 $MW_HOME -domainHostName name.example.com 
 -domainPortNum 7001
 -domainAdminUserName weblogic
 -domainAdminPassword $T2P_HOME/t2p_domain_pass.txt
 -silent true -ldl $T2P_HOME/oam_cln_log_config 
 -opssDataExport true -debug true;

    1. R2PS1の手順のみ: Access Manager R2PS1データ・センターのクローニングを開始する前に、OPSSのデータをソース・データベースからターゲットに移動します。この手順の実行方法は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

    2. OPSSのデータを移動した後で、次の3つのコマンド・セットを使用して、Access Managerをソースのテスト・マシンからターゲットの本番サーバーにコピーします。

      ソースのテスト・マシン上で、次のとおりに実行します。

      export JAVA_HOME=/scratch/11gR2_Refresh/jRockit;
export MW_HOME=/scratch/R2PS2RC4Refresh/Middleware;
export T2P_HOME=/scratch/R2PS2RC4Refresh/T2P;
export WL_DOMAIN_HOME=$MW_HOME/user_projects/domains/base2_domain;
 
cd $MW_HOME/oracle_common/bin/;

  Note : For the copyBinary command the Admin and 
  managed servers can be running or stopped

./copyBinary.sh -javaHome $JAVA_HOME -archiveLoc $T2P_HOME/oamt2pbin.jar 
 -sourceMWHomeLoc $MW_HOME -idw true 
 -ipl $MW_HOME/oracle_common/oraInst.loc 
 -silent true -ldl $T2P_HOME/oam_cln_log;

  Note : For the copyConfig command the Admin and managed servers
  should be up and running; see note above when running R2PS2

./copyConfig.sh -javaHome $JAVA_HOME -archiveLoc $T2P_HOME/oamt2pConfig.jar 
 -sourceDomainLoc $WL_DOMAIN_HOME -sourceMWHomeLoc 
 $MW_HOME -domainHostName name.example.com -domainPortNum 7001 
 -domainAdminUserName weblogic 
 -domainAdminPassword $T2P_HOME/t2p_domain_pass.txt 
 -silent true -ldl $T2P_HOME/oam_cln_log_config -debug true;
 
cp $MW_HOME/oracle_common/bin/pasteBinary.sh $T2P_HOME;
cp $MW_HOME/oracle_common/jlib/cloningclient.jar $T2P_HOME;
cp $MW_HOME/oracle_common/oraInst.loc $T2P_HOME;

      ターゲットの本番サーバー上で、次を実行します。

      export JAVA_HOME=/scratch/PSFE_T2P_FINAL/jRockit/jRockit;
export MW_HOME=/scratch/PSFE_T2P_FINAL/Middleware;
export T2P_HOME=/scratch/PSFE_T2P_FINAL/T2P/T2P;
export WL_DOMAIN_HOME=
 /scratch/PSFE_T2P_FINAL/Middleware/user_projects/domains/base15_domain;

      ディレクトリを作成し、ソース・マシンの$T2P_HOMEの内容をこのディレクトリにコピーします。ターゲット環境に応じた適切なコピー・コマンドを使用してください。

      mkdir -p $T2P_HOME
cp -r /net/slc02ozn/$T2P_HOME/* $T2P_HOME 
cd $T2P_HOME
 
./pasteBinary.sh -javaHome $JAVA_HOME -al /scratch/T2P_FIX/oamt2pbin.jar 
 -tmw $MW_HOME -silent true -idw true -esp false 
 -ipl /scratch/T2P_FIX/oraInst.loc -ldl /scratch/T2P_FIX/oam_cln_log_p 
 -silent true
 
cd $MW_HOME/oracle_common/bin
 
./extractMovePlan.sh -javaHome $JAVA_HOME -al $T2P_HOME/oamt2pConfig.jar 
 -planDirLoc $T2P_HOME/moveplan/
 
cp $T2P_HOME/moveplan/moveplan.xml $T2P_HOME/moveplan/moveplan.org

      ターゲットの本番サーバー上でも、このpasteConfigコマンドを実行する前に、抽出したmoveplan.xmlを、ターゲット・マシンのホストおよびポートの詳細とデータ・ソースの詳細で更新する必要があります。moveplanの修正内容を十分に確認し、ターゲット・マシンの詳細を検証してから、次のpasteConfigコマンドを実行してください。

      ./pasteConfig.sh -javaHome $JAVA_HOME 
 -archiveLoc $T2P_HOME/oamt2pConfig.jar -targetMWHomeLoc $MW_HOME 
 -targetDomainLoc $WL_DOMAIN_HOME 
 -movePlanLoc $T2P_HOME/moveplan/moveplan.xml 
 -domainAdminPassword $T2P_HOME/t2p_domain_pass.txt 
 -ldl $T2P_HOME/oam_cln_log_paste_p -silent true

      これらの手順の後に、Access Managerクローン・クラスタが設定され、管理サーバーが起動して稼働します。必要に応じて、管理対象サーバーを起動できます。

  3. 前の手順で作成されたクローンに対して、次の構成を実行します。

    1. WLSTのsetMultiDataCentreClusterNameコマンドを使用して、一意のclusterIdをすべてのクローン・データ・センターに対して設定します。

      setMultiDataCentreClusterName(clusterName="LonCluster")

      T2PプロセスによってマスターのclusterIdがすべてのクローンにコピーされます。

    2. WLSTのaddPartnerForMultiDataCentreコマンドを使用して、すべてのメンバー・データ・センター(マスターおよびクローン)でMDCパートナを構成および登録します。


      注意:

      MDCパートナ・プロファイルは、各データ・センターが公開するものであり、他のデータ・センターがそのデータ・センターとの通信に使用します。MDCパートナの登録は、2段階のプロセスです。1つのMDCに3つのデータ・センターがあるとします。DC1で、10gまたは11g Webゲートを作成することによってMDCパートナ・プロファイルを公開します(DC1_MDC_Partner)。次に、DC1_MDC_PartnerをDC2およびDC3で、addPartnerForMultiDataCentreを使用して登録します。詳細は、第7.9.3項「addPartnerForMultiDataCentre」を参照してください。

    3. クローン・データ・センターで、バック・チャネル通信を許可するために必要なファイアウォール・ポートを開きます(オンデマンド・セッション・データ取得に必要)。

    4. アプリケーションとWebゲートをクローン・データ・センターにデプロイします。


      注意:

      ユーザーのアフィニティに基づくロード・バランシングの場合は、ロード・バランサが認証を行うターゲット・データ・センターを決定するので、特定のWebゲートが行った認証リクエストは、どのメンバー・データ・センターにも到達する可能性があります。したがって、アプリケーションがデータ・センターで選択的にデプロイされるとしても、Webゲート・プロファイルはすべてのメンバー・データ・センターに一様に存在する必要があります。このWebゲート固有データをT2Pの後に同期させるには、WLSTのexportPartners/importPartnersコマンドおよびexportPolicy/importPolicyコマンドを使用します。

  4. T2Pのコマンドを使用して、変更内容をすべてのメンバー・データ・センターに配布します。

  5. メンバー・データ・センターを書込み保護として設定します。このためには、WLSTのsetMultiDataCenterTypeコマンドおよびsetMultiDataCenterWriteコマンドを使用して、各データ・センターをクローンかつ読取り専用として指定します。

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

Access Managerのデータを複数データ・センター間で同期させるようにマルチデータ・センター・インフラストラクチャを構成できます。以前は、レプリケーションを行うにはT2Pのツールを使用してマスターとクローンを設定し、それ以降の変更はWLSTのコマンドを使用して適用していました。この11gR2リリースでは自動ポリシー同期(APS)が導入されました。これは、データ同期プロセスから管理者および手動での介入をなくす、自動化されたレプリケーション・メカニズムです。(このリリースより前に使用されていたT2PのツールおよびWLSTコマンド・プロシージャも、引き続き使用できます。)


注意:

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

APSを使用してデータ・センターを同期するときは、次のことが発生する可能性があります。

  • レプリケーション承諾の確立。データ・センターの1つがレプリケーション・クローンとして登録され、地理的に離れた別のデータ・センターがそのマスターとして登録されます。変更内容はプルされてクローンに適用されます。

  • データ・センター間でレプリケートできない、データ・センター固有の構成の定義。

  • 各データ・センターでのAccess Manager構成変更のトラッキングと、任意のデータ・センターでの現在のレプリケーション状態の問合せ。

  • 変更ログの生成。このログは、類似の設定が別のデータ・センターで稼働している場合に適用できます。

  • マスター・データ・センターからのプルのトリガー(必要な場合)。たとえば、自動レプリケーションに失敗した場合に行われます。

  • マスター/クローン・モデルでのAccess Manager構成アーティファクトのレプリケーション。

次の各項では、さらに詳細を説明します。

7.7.1 自動ポリシー同期の仕組み

自動ポリシー同期は、マスター/クローン・トポロジにおいて機能します。このトポロジでは、複数のクローンが変更内容を単一のマスターからプルします。1つのデータ・センターが管理者によってマスターとして定義され、その他の1つ以上のデータ・センターがクローンとして動作します。管理者はマスターに対して変更を行い、クローンがその変更内容をレプリケートします。マスターからクローンへのレプリケーションのみがサポートされます。クローンに対する変更内容が逆にマスターにレプリケートされることはありません。


注意:

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

APSに参加するには、サプライヤ・データ・センター(レプリケーションを開始するデータ・センター)とクローン・データ・センター(変更内容を受け取るデータ・センター)は、レプリケーション承認をAccess Managerデータ・ストアに格納する必要があります。(APSは必須ではありません。管理者が開始する、インポートおよびエクスポートをベースとするレプリケーションも引き続き使用可能です。)表7-1は、APSをデプロイできる状態をまとめたものです。

表7-1 自動ポリシー同期: レプリカの状態

状態 定義

アクティブ

Access Managerドメイン(管理サーバーおよび管理対象サーバーを含む)がアクセス・リクエストを処理するように設定されています。アクティブ状態のとき、Access Managerサーバーは追加のMDC機能なしでWebアクセス管理機能を提供します。

ブートストラップ

この状態は、MDCトポロジの最初のデータ・センターなど一部のデータ・センターではオプションです。データ・センターがこの中間状態になるのは、そのデータ・センターが既存のMDCトポロジに追加されるときです。新しいDCはマスターと通信し、同じ状態になるように自身をブートストラップします。ブートストラップの中で、サーバー・キー、ポリシー・アーティファクト、パートナおよびシステム構成が同期されます。ブートストラップが完了した後は、DCの状態はレプリケーション準備完了となります。

レプリケーション準備完了

この状態のときは、MDCが有効化されており、DCはトポロジの一部となっており、レプリケーション・サービスが有効化されています。有効化された後は、レプリケーション承諾を介してクローンをマスターに登録できます。確立後は、クローンDCがマスターに問い合せて変更ログのプルを開始できます。

図7-11に自動ポリシー同期のフローを示します。

図7-11 自動ポリシー同期フロー

図7-11については周囲のテキストで説明しています。

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

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

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


注意:

自動ブートストラップは理想的なシナリオですが、(R2PS2では)最初にT2Pツールを実行してマスター構成とクローンとを確実に同じ状態にできます。この後に、APSを有効化して同期を設定できます。詳細は、「レプリケーション・サービスの有効化」を参照してください。

レプリケーションを確立するには、クローン・データ・センターがサプライヤの変更ログ・シーケンス番号を知る必要があります。データ・センターがトポロジに追加されたのが0日目で、レプリケーション承諾が作成されたのがN日目の場合は、再度ブートストラップが必要になります。このことを回避してフローの単純さを維持するには、レプリケーション承諾の作成時にブートストラップと実際のレプリケーション承諾作成を行います。詳細は、「レプリケーション・サービスの有効化」を参照してください。

7.7.3 レプリケーション・サービスの有効化

レプリケーション・サービスは、REST APIのセットです。バイナリはAccess Managerアプリケーションの一部としてインストールされ、管理サーバーにデプロイされます。デフォルトでは無効化されていますが、oracle.oam.EnableMDCReplicationプロパティをtrueに設定すると有効化できます。サービスの有効化の後に、プル・モデルのレプリケーション承諾をクローン・データ・センターとマスターとの間に作成します。レプリケーション承諾が有効であるかぎり、クローンはマスターからの変更をポーリングします。有効なレプリケーション承諾があるかぎり、マスターはクローンのリクエストに応答します。クローンは変更内容をマスターからプルして、自身にローカルに適用します。


注意:

レプリケーションRESTサービスが使用可能であることを確認するには、次のhello RESTエンド・ポイントにアクセスします。 
curl -u <user>
'https://oam1.example.com:7002/oam/services/rest/_
 replication/hello'

次の各項で、Access Managerで提供されるREST APIの使用方法を詳しく説明します。これらは、マスター・データ・センターのエンド・ポイントで実行する必要があります。

7.7.3.1 RESTを使用したレプリケーションの設定

この項の例は、DC1がマスターでoam1.oracle.comにあることを前提としています。DC2はDC1からT2Pプロセスを使用してクローニングされたものであり、oam2.oracle.comにあります。


注意:

レプリケーションを行うには、WLST入力に使用するpartnerInfo.propertiesファイルにRESTEndpointプロパティが追加されている必要があります(下記の例を参照)。この値は、レプリケーション関連のRESTサービスを起動するためのHTTPエンドポイントです。「addPartnerForMultiDataCentre」を参照してください。 
remoteDataCentreClusterId=DC1
oamMdcAgentId=DC1Partner
PrimaryHostPort=dc1.oracle.com:5575
SecondaryHostPort=dc1.oracle.com:5576
AccessClientPasswd=secret
oamMdcSecurityMode=OPEN
trustStorePath=NA
keyStorePath=NA
globalPassPhrase=NA
keystorePassword=NA
agentVersion=11g
RESTEndpoint=https://oam1.oracle.com:443

次に示すRESTリクエストは、次のことを行います。

  • マスターのレプリケーション承諾ストア(変更内容をプルするクローンに関する詳細情報が格納されている)にエントリを挿入します。

  • クローンのレプリケーション承諾ストア(マスターに関する詳細およびポーリング間隔などの値が格納されている)にエントリを挿入します。

POST http://oam1.oracle.com/oam/services/rest/_replication/setup HTTP/1.1
Content-Type: application/json
{"name":"DC12DC2", "source":"DC1","target":"DC2","documentType":"ENTITY"}

注意:

RESTエンド・ポイントは、HTTPとHTTPSのどちらのURLでもかまいません。HTTPSをお薦めします。

このRESTリクエストへの応答で、マスターは変更ログ・リポジトリの開始シーケンス番号を指定します。この開始シーケンス番号を使用して、クローンのレプリケーション承諾をレプリケーションが発生するシーケンス番号に更新します。返された識別子は、レプリケーション関連の問合せに使用されます。

{"enabled":"true","identifier":"201312040602298762","ok":"true","pollInterval":"60","startingSequenceNumber":"10","state":"READY"}

前の例では、startingSequenceNumberの値(10)よりも前のレコードはすべて使用できません。暗黙的に、ブートストラップはレプリケーション承諾作成の前に行われており、クローンはシーケンス番号10から変更内容のプルを開始できます。クローンのローカル・レプリケーション表にもエントリが作成されており、ここに最後のシーケンス番号が記録されます。


注意:

クローンからマスターに対してレプリケーション・ポーリングが行われるときの認証には、Weblogicのユーザーおよびパスワードが使用されます。レプリケーションで別のユーザーをコールするため、有効な基本認可ヘッダーをクローンに提供できます。次に示す例では、replicationuserがユーザーでsecretがパスワードであり、"BASIC cmVwbGljYXRpb251c2VyOnNlY3JldA=="がRESTコールに使用される基本ヘッダー(ユーザーとパスワードによるbase64暗号化済)です。ユーザー詳細は、マスターとクローンの両方にシードされます。 
curl -u weblogic:welcome1 -H 'Content-Type: application/json' 
 -X POST 'http://adc1140321.example.com:7001/oam/services/rest
 /_replication/setup' -d 
 '{"source":"DC1","target":"DC2","documentType":"ENTITY",
 "config":{"entry":{"key":"authorization",
 "value":"BASIC cmVwbGljYXRpb251c2VyOnNlY3JldA=="}}}'

レプリケーション承諾は、マスター/クローン・ペアごとに行う必要があります。完了後、クローンは定期的にマスターからの変更内容のプルを開始できます。「レプリケーション承諾の理解」を参照してください。レプリケーションを有効にしたら、マスターとクローン両方のデータ・センターで、WLSTのaddPartnerForMultiDataCentreコマンドをマスターおよびクローンの各ノードに実行して、すべてをMDCパートナとして登録します。

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

RESTリクエストをマスター・データ・センターのエンドポイントで実行して、マスターとクローンの間のレプリケーション承諾の詳細を問い合せることができます。マスターの詳細を問い合せるには、次を使用します。

GET http://oam1.oracle.com/oam/services/rest/_replication/201312040602298762 HTTP/1.1
Content-Type: application/json

クローンの詳細を問い合せるには、次を使用します。

GET http://oam1.oracle.com/oam/services/rest/_replication/201312040602298762?type=clone HTTP/1.1 HTTP/1.1
Content-Type: application/json

7.7.3.3 既存のレプリケーション承諾の変更

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

PUT http://oam1.oracle.com/oam/services/rest/_replication/201312040602298762 HTTP/1.1
Content-Type: application/json
{"enabled":"false","pollInterval":"60","replicaType":"clone"}

この例では、クローンのレプリケーション承諾が無効になり、ポーリング間隔が60秒に変更されます。replicaTypeの値が定義されていない(またはSUPPLIERである)場合は、マスターのレプリケーション承諾が更新されます。

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

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

DELETE http://oam1.oracle.com/oam/services/rest/_replication/
 201312040602298762 HTTP/1.1

7.8 タイムアウトおよびセッション同期の理解

次の各項で、マルチデータ・センターにおけるセッション・タイムアウトおよび同期の扱いについて説明します。

7.8.1 最大セッション制約の遵守

資格証明コレクタ・ユーザーのアフィニティによって、ユーザー当たりの最大セッション制約が確実に遵守されます。ユーザー当たりの許容最大セッション数を検証するためのマルチデータ・センター・セッション・ストアはありません。

7.8.2 アイドル・タイムアウトのポリシーの構成

OAM_IDおよびOAM_GITOのCookieを使用してアイドル(非アクティブ)タイムアウトが計算され、適用されます。ただし、OAM_GITO Cookieを設定できるのは、Webゲート間に共通のサブドメインがある場合のみです。したがって、マルチデータ・センターのポリシーは、OAM_GITO Cookieが設定されているかどうかに基づいて構成する必要があります。表7-2は、ポリシー構成をまとめたものです。

表7-2 アイドル・タイムアウトに関するマルチデータ・センターのポリシー構成

OAM_GITO設定済 マルチデータ・センターのポリシー

はい

アイドル・タイムアウトは最新のOAM_GITO Cookieから計算されます。

SessionMustBeAnchoredToDataCenterServicingUser=<true/false>

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds>

SessionContinuationOnSyncFailure=<true/false>

MDCGitoCookieDomain=<sub domain>

いいえ

OAM_GITOが使用できないため、アイドル・タイムアウトはOAM_ID Cookieから計算されます。

SessionMustBeAnchoredToDataCenterServicingUser=false

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds>

SessionContinuationOnSyncFailure=<true/false>

#MDCGitoCookieDomain= この設定はコメント化または削除する必要があります。

7.8.3 マルチデータ・センターのセッションの失効

セッション失効の管理は、ユーザーがアフィニティを持つデータ・センターによって行われます。ユーザーと特定のデータ・センターとのアフィニティは、グローバル・トラフィック・マネージャ/ロード・バランサに基づきます。

7.8.4 セッションの同期とマルチデータ・センターのフェイルオーバー

Access Managerサーバー側セッションは、シングル・サインオン(SSO)資格証明に基づいて作成および維持されます。セッションの中で保存される属性には(これに限定されるわけではありません)、ユーザー識別子、アイデンティティ・ストア参照、サブジェクト、カスタム属性、パートナ・データ、クライアントIPアドレスおよび認証レベルがあります。SSOが許可されるのは、サーバーがユーザーのリクエストに対応する有効なセッションを特定できる場合です。

マルチデータ・センターのシナリオでは、ユーザー・リクエストがデータ・センター間をホップするときに、そのリクエストを処理するデータ・センターが、正当なセッションかどうかの検証をローカルで、およびデータ・センター間で行う必要があります。特定のリクエストに対する有効なセッションがリモートのデータ・センターに存在する場合は、MDCセッション同期ポリシーに基づいてリモート・セッションを現在のデータ・センターに移行する必要があります。(詳細は、第7.2項「マルチデータ・センター・デプロイメントの理解」を参照してください。)このセッション同期のときに、リモート・セッションからのすべてのセッション属性が、現在のリクエストを処理するデータ・センターで新規作成されたセッションに同期されます。

マルチデータ・センターでは、データ・センター間のWebゲートのフェイルオーバーもサポートされます。Webゲートが別のデータ・センターにフェイルオーバーするときは、最初のデータ・センターのサーバーが停止しているため、セッション・データの同期はできません。したがって、2つ目のデータ・センターがSessionContinuationOnSyncFailureの設定に基づいて、セッション・アダプションを続行するかどうかを決定します。trueのときは、リモートのデータ・センターへのOAP通信が失敗しても、現在のリクエストを処理するデータ・センターはCookie内の必須属性に基づいてローカルに新規セッションを作成できます。これで、同期エラーがあってもリクエストされたリソースへのシームレスなアクセスが可能になります。表7-3は、セッション同期とフェイルオーバーの代表的なシナリオをまとめたものです。

表7-3 セッション同期とフェイルオーバーのシナリオ

MDCデプロイメント MDCポリシー リモート・セッションの検証 リモートDCからのユーザーを処理するDCでのセッション同期 リモート・セッションの終了 ユーザーに対するチャレンジ

アクティブ/アクティブ

SessionMustBeAnchoredToDataCenterServicingUser=true

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds>

SessionContinuationOnSyncFailure= false

MDCGitoCookieDomain=<sub domain>

はい

はい

はい

有効なセッションがリモートDCで見つからないとき

アクティブ/アクティブ

SessionMustBeAnchoredToDataCenterServicingUser=false

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<millisecon

ds>

SessionContinuationOnSyncFailure= false

MDCGitoCookieDomain=<sub domain>

はい

はい

いいえ

有効なセッションがリモートDCで見つからないとき

アクティブ/スタンバイ

SessionMustBeAnchoredToDataCenterServicingUser=true

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<millisecon

ds>

SessionContinuationOnSyncFailure= false

MDCGitoCookieDomain=<sub domain>

検証できない(リモートDCが停止しているため)

いいえ(リモートDCが停止しているため)

終了できない(リモートDCが停止しているため)

はい

アクティブ/スタンバイ

SessionMustBeAnchoredToDataCenterServicingUser=true

SessionDataRetrievalOnDemand=true

Reauthenticate=false

SessionDataRetrievalOnDemandMax_retry_attempts=<number>

SessionDataRetrievalOnDemandMax_conn_wait_time=<milliseconds>

SessionContinuationOnSyncFailure= true

MDCGitoCookieDomain=<sub domain>

検証できない(リモートDCが停止しているため)

いいえ(リモートDCが停止しているため)

終了できない(リモートDCが停止しているため)

いいえ

有効なCookie内の詳細情報を使用してローカル・セッションを作成することにより、シームレスなアクセスを提供

7.9 マルチデータ・センターのためのWLSTコマンド

次に示すWebLogic Scripting Tool (WLST)コマンドは、マルチデータ・センター・デプロイメントに固有です。詳細は、次の各項に記載されています。

7.9.1 enableMultiDataCentreMode

マルチデータ・センター・モードの有効化に使用されるオンライン・コマンド。

7.9.1.1 説明

このコマンドは、マルチデータ・センター・モードを有効にします。MDC.propertiesファイルのフルパスおよびファイル名と等しい値を取ります。


注意:

管理コンソールでSSOトークンのバージョンを5に設定することは、サポートされていません。このようにするには、「Access Managerの設定」ページに変更を加え、WLSTのenableMultiDataCentreModeコマンドを実行して設定します。

7.9.1.2 構文

enableMultiDataCentreMode(propfile="../MDC_properties/oamMDCProperty.properties")
引数 定義
propfile 必須です。oamMDCProperty.propertiesファイルのフルパスおよびファイル名と等しい値を取ります。表7-4は、ファイルを構成するプロパティを示します。例7-1 (表の次)は、oamMDCProperty.propertiesファイルのサンプルです。

表7-4 oamMDC.propertiesのプロパティ

プロパティ 定義

SessionMustBeAnchoredToDataCenterServicingUser

True (無効化)またはFalse (無効化しない)の値を取ります。

SessionDataRetrievalOnDemand

True (他DCから取得)またはFalse (いいえ)の値を取ります。MDCを無効にせずにデータ取得をオフにできます。Falseの場合、ユーザーがDC間で移動すると、セッション・データは転送されませんが、SSOは引き続き実行されます。

Reauthenticate

True (強制的に再認証)またはFalse (強制的再認証なし)の値を取ります。

SessionDataRetrievalOnDemandMax_retry_attempts

データ取得に失敗したときの再試行回数を表すバイナリに等しい値を取ります。デフォルトは2です。

SessionDataRetrievalOnDemandMax_conn_wait_time

接続を待つ時間の合計(秒)を表すバイナリに等しい値を取ります。デフォルトは1000です。

SessionContinuationOnSyncFailure

True (無効化/取得に成功する必要がある)またはFalse (失敗を無視)の値を取ります。

MDCGitoCookieDomain

OAM_GITO Cookieをどのドメインで設定するかを指定します。共通Cookieドメイン階層を導出できないMDCデプロイメントでは、この設定をコメント化または削除する必要があります(非アクティブ・タイムアウトのシナリオの説明を参照)。

例7-1 oamMDCProperty.propertiesファイルのサンプル

SessionMustBeAnchoredToDataCenterServicingUser=true
SessionDataRetrievalOnDemand=true
Reauthenticate=true
SessionDataRetrievalOnDemandMax_retry_attempts=3
SessionDataRetrievalOnDemandMax_conn_wait_time=80
SessionContinuationOnSyncFailure=true

#MDCGitoCookieDomain=.oracle.com <This setting should be provided only if there is a common cookie subdomain across the WGs and DCs>

7.9.1.3 例

次のコマンドを実行すると、このデータ・センターが有効になります。

enableMultiDataCentreMode(propfile="../MDC_properties/oamMDCProperty.properties")

7.9.2 disableMultiDataCentreMode

マルチデータ・センター・モードの無効化に使用されるオンライン・コマンド。

7.9.2.1 説明

このコマンドは、マルチデータ・センター・モードを無効にします。

7.9.2.2 構文

disableMultiDataCentreMode()

このコマンドには引数はありません。

7.9.2.3 例

次のコマンドを実行すると、マルチデータ・センター・モードが無効になります。

disableMultiDataCentreMode()

7.9.3 addPartnerForMultiDataCentre

n個のデータ・センターを持つMDCデプロイメントでは、各データ・センターに、他の(n-1)個のデータ・センターそれぞれと通信するための登録済パートナがあります。つまり、パートナ登録の総数は(n) x (n-1)です。このオンライン・コマンドは、データ・センター間OAP通信用のパートナを追加するのに使用されます。


注意:

MDCパートナ・プロファイルは、各データ・センターが公開するものであり、他のデータ・センターがそのデータ・センターとの通信に使用します。MDCパートナの登録は、2段階のプロセスです。1つのMDCに3つのデータ・センターがあるとします。DC1で、10gまたは11g Webゲートを作成することによってMDCパートナ・プロファイルを公開します(DC1_MDC_Partner)。次に、DC1_MDC_PartnerをDC2およびDC3で、addPartnerForMultiDataCentreを使用して登録します。詳細は、第7.9.3項「addPartnerForMultiDataCentre」を参照してください。

7.9.3.1 説明

このコマンドは、パートナをデータ・センターに追加します。partnerInfo.propertiesファイルのフルパスおよび名前と等しい値を取ります。

7.9.3.2 構文

addPartnerForMultiDataCentre(propfile="../MDC_properties/partnerInfo.properties")
引数 定義
propfile 必須です。partnerInfo.propertiesファイルのパスおよび名前と等しい値を取ります。
RESTEndpoint オプション。値として、Access Manager RESTサービスにアクセスできるHTTP/HTTPS URLを取ります。

表7-5は、partnerInfo.propertiesを構成するプロパティを示します。プロパティ・ファイルのサンプルは、第7.1.3項「マルチデータ・センターに対するAccess Managerセキュリティ・モードの理解」を参照してください。

表7-5 partnerInfo.propertiesのプロパティ

プロパティ 定義

remoteDataCentreClusterId

OAP通信を確立する必要のあるリモート・データ・センターのクラスタID。

oamMdcAgentId

リモート・データ・センター内の登録済パートナ・プロファイルのパートナID。このパートナの"管理操作を許可"フラグがリモート・データ・センターで設定されている必要があります。

PrimaryHostPort

remoteDataCentreClusterIdで指定されたリモートDCに対応するプライマリAccess Managerサーバーのfully-qualified-host-name:OAM-portを値として取ります。例: PrimaryHostPort=abc.example.com:5575

SecondaryHostPort

remoteDataCentreClusterIdで指定されたリモートDCに対応するセカンダリAccess Managerサーバーのfully-qualified-host-name:OAM-portを値として取ります。例: SecondaryHostPort=abc.example.com:5577

OAM MDCメンバー・データ・センターに2つの管理対象サーバーがあり、場所はabc.example.comで、ポートがoam_server1 (5575)およびoam_server2 (5577)であるとします。OAP SDKパートナの高可用性/フェイルオーバーを実現するには、PrimaryHostPortおよびSecondaryHostPortを次のとおりに設定します。

PrimaryHostPort=abc.example.com:5575

SecondaryHostPort=abc.example.com:5577

AccessClientPasswd

リモート・データ・センターで登録済のMDCパートナのアクセス・クライアント・パスワード。

oamMdcSecurityMode

MDCセキュリティ・モードを定義します。値はOPEN/SIMPLE/CERTです。(CERTモードをお薦めします。SIMPLEでも問題ありませんが、OPENはお薦めできません。)

SIMPLEモードおよびCERTモードの場合は、次に示す値を適宜指定する必要があります。OPENモードの場合は、これらの値は適用されません。

agentVersion

有効なエージェント・バージョン11g/10g。

trustStorePath

トラストストア・ファイルへの絶対パス[SIMPE/CERT]。

keyStorePath

キーストア・ファイルへの絶対パス[SIMPLE/CERT]。

globalPassPhrase

パートナ登録時に設定されたグローバル・パスフレーズ[SIMPLE/CERT]。

keystorePassword

パートナ構成時に設定されたキーストア・パスワード[SIMPLE/CERT]。

7.9.3.3 例

次のコマンドを実行すると、このデータ・センターがマスターとして定義されます。

addPartnerForMultiDataCentre(propfile="../MDC_properties/partnerInfo.properties")

7.9.4 removePartnerForMultiDataCentre

登録済のリモート・パートナをデータ・センター構成から削除するために使用されるオンライン・コマンド。

7.9.4.1 説明

このコマンドは、登録済リモート・パートナを構成済データ・センターから削除します。有効なremoteDataCentreClusterIdと等しい値を取ります。

7.9.4.2 構文

removePartnerForMultiDataCentre=("<cluster_ID>")
引数 定義
cluster_ID 必須です。クラスタIDに等しい文字列値を取ります。

7.9.4.3 例

次のコマンドは、削除するパートナを定義します。

removePartnerForMultiDataCentre("99bf9-adc2120609")

7.9.5 setMultiDataCenterType

データ・センターのタイプ(マスターまたはクローン)の設定に使用されるオンライン・コマンド。

7.9.5.1 説明

MDCデプロイメントでは、1つのデータ・センターがマスターとして指定され、その他がクローンとして指定されます。基本的に、MDC全体でのグローバル構成およびポリシーの更新はすべてマスターに適用し、クローンには、サポートされるT2Pコマンドを使用して伝播する必要があります。このコマンドは、データ・センターのタイプを設定します。値はMasterまたはCloneです。

7.9.5.2 構文

setMultiDataCenterType(DataCenterType="<Master|Clone>")
引数 定義
DataCenterType 必須です。MasterまたはCloneの文字列値を取ります。

7.9.5.3 例

次のコマンドを実行すると、このデータ・センターがマスターとして定義されます。

setMultiDataCenterType(DataCenterType="Master")

7.9.6 setMultiDataCenterWrite

システムおよびポリシーの構成に対する変更の制御を設定するために使用されるオンライン・コマンド。

7.9.6.1 説明

システムおよびポリシーの構成に対する更新ができなくなるよう、クローン・データ・センターを書込み保護できます。値はtrueまたはfalseです。

7.9.6.2 構文

setMultiDataCenterWrite(WriteEnabledFlag="<true|false>")
引数 定義
WriteEnabledFlag 必須です。trueまたはfalseの文字列値を取ります。

7.9.6.3 例

次のコマンドを実行すると、システムおよびポリシーの構成に対する変更が可能になります。

setMultiDataCenterWrite(WriteEnabledFlag = "true")

7.9.7 setMultiDataCentreClusterName

データ・センターのクラスタ名を指定の文字列に設定するためのオンライン・コマンド。

7.9.7.1 説明

このコマンドは、マルチデータ・センターのクラスタ名を設定します。値は文字列です。

7.9.7.2 構文

setMultiDataCentreClusterName(clusterName="<string_value>")
引数 定義
clusterName 必須です。クラスタ名に等しい文字列を取ります。

7.9.7.3 例

次のコマンドを実行すると、このデータ・センターが有効になります。

setMultiDataCentreClusterName(clusterName="MyCluster")

7.9.8 validateMDCConfig

マルチデータ・センターの構成が正しいことを保証するために使用されるオンライン・コマンド。

7.9.8.1 説明

このコマンドは、マルチデータ・センターの構成の必須エントリがoam-config.xmlに存在することを検証します。MDCソリューションでは、認可時にMDCセッションを作成または更新するにはmdc_session_updateという名前の新しいAccess Managerイベントが必要です。Access Managerイベント・モデルでは、一連の構成がoam-config.xml構成ファイルに存在することが要求されます。必須の構成を静的に追加することはできないため、validateMDCConfigによってmdc_session_updateの必須のエントリを検証し、まだ存在しない構成をシードします。

7.9.8.2 構文

validateMDCConfig()

このコマンドには引数はありません。

7.9.8.3 例

次のコマンドを実行すると、MDC構成が検証されます。

validateMDCConfig()

7.10 マルチデータ・センターおよびIdentity Managerでのドメインのレプリケート

デプロイメントにおいてAccess Manager 11.1.2.1.0とOracle Identity Manager (11.1.2.1.0)が同じドメイン内で統合されている場合、本番へのテスト(T2P)をドメイン・レプリケーションに使用することはできません。Identity ManagerではT2Pがサポートされていないためです。この場合は、次の手順を使用して、Access ManagerとIdentity Managerを別のドメインにインストールします。

  1. Access Managerをインストールします。

  2. configureSecurityStore (-create)を実行します。

  3. Access Managerを起動します。

    必ず、インストゥルメント済EARによるTRACEロギングを有効にしてください。

  4. Identity Managerをインストールします。

  5. configureSecurityStore (-join)を実行します。

  6. $DOMAIN_HOME/config/fmwconfig/default-keystore.jksパスワードにある、Access ManagerおよびIdentity Managerのドメインのデフォルト・パスワードを、keytoolコマンドを使用して更新します。

  7. EMコンソールを使用して、同じパスワード値をCSFで設定します。

    1. 該当するWeblogicドメインのドメイン名に移動します。

    2. ドメイン名を右クリックして「セキュリティ」→「資格証明」に移動します。

    3. oracle.wsm.security資格証明マップを開き、keystore-csf-keyの値を編集します。

    4. パスワードおよび確認パスワードのフィールドのパスワードを更新します。

      このパスワードは、Access ManagerドメインとIdentity Managerドメインの両方でdefault-keystore.jksの新しいパスワードと同じであることが必要です。

  8. oracle.wsm.securityをキーkeystore-csf-keyにマップします。

  9. Identity Managerを起動します。

  10. Access ManagerおよびIdentity Managerを再起動します。

7.11 マルチデータ・センターに関する推奨事項

この項では、マルチデータ・センター機能に関する推奨事項を示します。

7.11.1 共通ドメインの使用

Webゲートはドメイン・スコープ指定とし、すべてのWebゲートおよびOAM Server資格証明コレクタで1つの共通ドメインを推測できるようにすることをお薦めします。これで、Webゲートが、OAM Serverとの間で共有される暗号化GITO Cookieを設定できるようになります。たとえば、Webゲートがapplications.abc.comで構成され、OAM Server資格証明コレクタがserver.abc.comで構成されている場合は、GITO Cookieの設定に使用される共通ドメインはabc.comです。共通ドメインを推測できないシナリオの場合は、GITO Cookieを設定することは意味がありません。あるデータ・センターが他のデータ・センターの最新ユーザー・セッションを認識していないこともあるためです。この結果として、そのデータ・センターは古いセッション・データに基づいてセッション・アイドル・タイムアウトを計算し、他にアクティブなセッションがどこかに存在しているとしても、ユーザーの再認証が必要になる可能性があります。


注意:

SessionContinuationOnSyncFailureプロパティが設定されているときは、同様の問題がサーバー・フェイルオーバー時に発生します。期待される動作は、OAM_ID Cookieの内容からセッションを取り出すことです。実際の非アクティブ・タイムアウト値をGITO Cookieから取り出すことが不可能であるため、再認証が発生します。

WebゲートおよびOAMサーバーの共通Cookieドメインがないときは、アイドル・タイムアウトの問題に対処するために、構成を次のとおりに変更してください。

  • MDCGitoCookieDomainプロパティを入力プロパティ・ファイルから削除した後に、WLSTのenableMultiDataCentreModeコマンドを実行します。

  • WebゲートCookieの有効期間の値を、セッション・アイドル・タイムアウト・プロパティの値よりも小さく設定します。セッション・アイドル・タイムアウトの値が30分で、WebゲートCookieの有効期間の値が15分とすると、認証を行うデータ・センターでは15分ごとにセッションがリフレッシュされます。

7.11.2 外部ロード・バランサの使用

このパッチでは、11g SDK APIを使用してセッション・データを取得しますが、このAPIでは、構成済プライマリ・サーバー・セット内でのSDKベースのロード・バランシングがサポートされていません。外部のTCPベースのロード・バランサを、高パフォーマンスが期待されているデータ・センター・ノードのNAPエンドポイントのフロント・エンドとして使用します。


注意:

プライマリとセカンダリのOAMサーバー間のフェイルオーバーは、11g SDK APIの現行リリースでサポートされています。

7.11.3 最大セッション数の遵守

一般的なマルチデータ・センターのシナリオでは、ユーザーの認証は、そのユーザーが地理的にアフィニティを持つデータ・センターに対して行われます。まれなシナリオとして、特定のユーザーのユーザー認証とセッション作成が複数のメンバー・データ・センターにわたる場合は(地理的アフィニティと負荷スパイクを回避)、マルチデータ・センター・トポロジ全体でのそのユーザーの最大セッション数は遵守されません。

7.12 T2Pによるクローニング

このドキュメントには、Access Manager R2PS1データ・センターのクローニングの手順と前提事項が含まれています。2つの手順が関与します。

  1. OPSSのデータをターゲットのデータベースに移動します。

  2. OAMをソースからターゲットにコピーします。

7.12.1 OPSSデータの移動

OPSSデータ層の移動は適用できません。可能な場合はデータ層を移動します[T2PがOAMのみに対して行われる場合は適用されません。]

OPSSデータ層を移動する手順は、http://docs.oracle.com/cd/E27559_01/core.1112/e28516/testprod.htm#autoId5の手順を参照してください。

シナリオ:

次の手順を使用して、インストール直後のOAMまたは既存のOAM設定をクローニングできます。

OPSSデータのクローンへの移動: (http://docs.oracle.com/cd/E27559_01/core.1112/e28516/testprod.htm#CHDHAFCE)

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引