| 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 11gを使用する大規模な組織は一般的に、そのアプリケーションをマルチデータ・センター全体にデプロイして、負荷を分散し、障害時リカバリに対応します。Access Managerをマルチデータ・センターにデプロイすると、データ・センター間のシングル・サインオン(SSO)の構成後に、ユーザー・セッションの詳細を透過的に転送できます。
データ・センターのスコープに含まれるものとしては、保護されたアプリケーション、Webゲート・エージェント、Access Managerサーバーおよびその他のインフラストラクチャ・エンティティ(アイデンティティ・ストアやデータベースなど)があります。
ノート:
Access Manager 11gでは、アプリケーションを2つ以上のデータ・センターに分散するというシナリオもサポートされます。
Access Managerでサポートされるマルチデータ・センター・アプローチは、マスター/クローン型のデプロイメントであり、最初のデータ・センターがマスターとして指定され、1つ以上のクローン・データ・センターがそれをミラーリングします。(マスター・データ・センターとクローン・データ・センターは、それぞれサプライヤ・データ・センターとコンシューマ・データ・センターと呼ぶこともできます。)マスター・データ・センターの複製には本番へのテスト(T2P)ツールが使用され、1つ以上の子データ・センターが作成されます。T2Pの詳細は、『Oracle Fusion Middlewareの管理』を参照してください。
マルチデータ・センターの設定中に、セッション・アダプション・ポリシーが構成され、マスター・データ・センターの停止時のリクエストの送信先が決定されます。設定後、マスターからクローンへのデータのレプリケーション方法が指定されます。これは、自動ポリシー同期(APS)レプリケーション・サービスを使用するか、手動によって実行できます。設定および同期プロセスの詳細は、「マルチデータ・センターの構成」および「マルチデータ・センターのデータの同期」を参照してください。
データ・センターには、アプリケーション、データ・ストア、ロード・バランサなどが含まれます。各データ・センターに、Access Managerのフル・インストールが含まれます。Access ManagerのインスタンスがインストールされているWebLogic Serverドメインが複数のデータ・センターにまたがることはありません。さらに、データ・センターは、ユーザー対データ・センターのアフィニティを保持します。図17-1に、マルチデータ・センターのシステム・アーキテクチャを示します。
ノート:
グローバル・ロード・バランサは、HTTPトラフィックを地理的に最も近いデータ・センターにルーティングするように構成されます。Oracle Accessプロトコルのトラフィックの管理には、ロード・バランサは使用されません。
すべてのアプリケーションは、それぞれのローカル・データ・センターでAccess Managerクラスタに対して構成されるWebゲート・エージェントによって保護されます。どのWebゲートにも、プライマリ・サーバー1つと1つ以上のセカンダリ・サーバーがあります。各データ・センターのWebゲート・エージェントには、プライマリ・リストに同じデータ・センターからのAccess Managerサーバー・ノードがあり、セカンダリ・リストに他のデータ・センターからのノードがあります。したがって、次の条件に該当するときは、ユーザー・リクエストを別のデータ・センターにルーティングすることも可能です。
ローカル・データ・センターが停止した。
負荷が一時的に増大し、トラフィックの再分散が発生した。
特定のアプリケーションが1つのデータ・センターのみにデプロイされている。
負荷分散は1つのデータ・センター内で行うが、フェイルオーバーはデータ・センター間で行うようにWebゲートが構成されている。
次の各項では、マルチデータ・センター・ソリューションがどのように機能するかについて説明します。
SSO Cookie (OAM_ID、OAMAuthnおよびOAM_GITO)は、マルチデータ・センターによって強化され、使用されています。
この節では、以下のトピックについて説明します。
OAM_ID Cookieは、Access ManagerのためのSSO Cookieであり、全データ・センターにわたってMDC動作を有効にするのに必要な属性を保持します。
同じSSOセッションでユーザーからの後続のリクエストが、MDCトポロジ内の別のデータ・センターにルーティングされる場合は、構成済のセッション・アダプション・ポリシーによりセッションの採用がトリガーされます。‘セッション・アダプション’とは、そのトポロジ内の別のデータ・センターにユーザーのセッションが存在することを示す有効な認証Cookie (OAM_ID)の提示に基づいて、データ・センターがそのユーザーのローカル・セッションを作成する動作のことです。(これは、そのユーザーの再認証を伴うことも、そうでないこともあります。)
データ・センター内でユーザー・セッションが作成されると、OAM_ID Cookieは次の項目を使用して付加または更新されます。
clusteridsessionidlatest_visited_clusteridMDCデプロイメントでは、OAM_IDはホスト・スコープのCookieです。そのドメイン・パラメータは、データ・センター全体でシングルトンである仮想ホスト名に設定され、ロード・バランサ・レベルのユーザー・トラフィック・ルーティング・ルール(地理的アフィニティなど)に基づいて、グローバル・ロード・バランサによってAccess Managerデータ・センター内のAccess Managerサーバーにマップされます。OAM_ID Cookieは、Access Managerサーバー以外のアプリケーションにはアクセスできません。
OAMAuthnは11gのWebゲートCookieで、ObSSOは10gのWebゲートCookieです。認証と認可に成功すると、保護されたリソースへのアクセス権がユーザーに付与されます。その時点で、ブラウザは、認証を行うデータ・センターのclusterid:sessionidを持つ有効なWebゲートCookieを取得します。
認証に続く認可が複数のデータ・センターにわたっている場合は、ユーザー・リクエストを認可するデータ・センターが、WebゲートCookieからそのセッションの作成元であるclusteridを取得することで、セッション・アダプションをトリガーします。(WebゲートCookieのホスト・スコープのため、Webゲートの各データ・センターのホスト名は同じである必要があります。)セッション・アダプションの後に、新しいセッションが現在のデータ・センター内に作成され、セッションの詳細が同期されます。
ノート:
WebゲートCookieを認可時に更新することはできないため、新規作成されたsessionidを将来の認可参照用に永続化することはできません。この場合は、リモートのsessionidとローカルのsessionidがセッション索引付けを通してリンクされます。データ・センターに対するそれ以降の認可コールのときに、新しいセッションが作成されるのは次の場合です。
MDCが有効になっている。
WebゲートCookie内のsessionidに一致するセッションがローカルのデータ・センター内に存在しない。
WebゲートCookie内のsessionidに一致するセッション索引を持つセッションが存在しない。
有効なセッションが(MDCセッション同期ポリシーに基づく)リモートのデータ・センターに存在する。
これらの場合は、新しいセッションが、WebゲートCookie内のsessionidを参照するセッション索引とともに、ローカルのデータ・センター内で作成されます。
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ドメインで設定できるようになります。
マルチデータ・センターのセッション・アダプションは、認可フローの中でサポートされます。認証に成功した後、OAMAuthn Cookieには、認証が行われたデータ・センターのクラスタID詳細が付加されます。
認可時に、リクエストが別のデータ・センターにルーティングされる場合、Access Managerランタイムは、有効なリモート・セッションであるかどうかをチェックして、これがマルチデータ・センターのシナリオに該当するかどうかを判断します。有効なリモート・セッションが特定されると、セッション・アダプション・ポリシーごとにマルチデータ・センターのセッション・アダプション・プロセスがトリガーされます。
クローンのAccess ManagerクラスタがOracle Accessプロトコル(OAP)を使用してマスターのAccess Managerクラスタに対してセッションの詳細のバックエンド・リクエストを行うように、セッション・アダプション・ポリシーを構成することもできます。前のセッションを無効にして、ユーザーが一度に1つのデータ・センターのみでセッションを持つようにセッション・アダプション・ポリシーを構成することもできます。セッション・アダプション・プロセスの後に、認可リクエストを処理するデータ・センターに新しいセッションが作成されます。
ノート:
認可時のOAMAuthn Cookieの更新はサポートされていないため、新規作成されたセッションのセッション索引は、受信セッションIDのものに設定されます。
Session IndexはOAMAuth Cookieのセッション識別子を参照します。
データ・センターへの認可コール中に、Session Indexを持つ新しいセッションが、ローカル・データ・センターに作成されます。これは、次の条件が満たされると発生します。
OAMAuth/ObSSO Cookie内のセッションIDに一致するセッションがローカルのデータ・センターに存在しない。
MDCが有効になっている。
OAMAuth/ObSSO Cookie内のセッションIDに一致するセッション索引を持つセッションが存在しない。
有効なセッションがMDCセッション同期ポリシーに基づくリモートのデータ・センターに存在する。
Access Managerは、3つのマルチデータ・センターのトポロジをサポートします: アクティブ/アクティブ・モード、アクティブ/パッシブ・モードおよびアクティブ/スタンバイ・モード。
次の各項では、これらのモードの詳細を説明します。
アクティブ/アクティブ・トポロジ。この場合、マスターとクローンのデータ・センターが正確なレプリカであり、同時にアクティブとなります。
これらは、地理的位置などの定義済の基準に基づいて、様々なユーザーのセットに対応します。ロード・バランサによってトラフィックが適切なデータ・センターにルーティングされます。図17-2に、通常稼働時にアクティブ/アクティブ・モードに設定されているマルチデータ・センターを示します。
図17-2では、ニューヨークのデータ・センターがマスターとして指定され、ポリシーおよび構成の変更はすべてこのデータ・センターのみで行われます。ロンドンのデータ・センターはクローンとして指定されており、T2Pのツールとユーティリティを使用して定期的にデータをニューヨークのデータ・センターと同期させます。地理的に異なる場所(米国およびヨーロッパ)のユーザーを、(アクセスされるアプリケーションの近さではなく)データ・センターへの地理的な近さに基づいて、適切なデータ・センター(ニューヨークまたはロンドン)にルーティングするようにグローバル・ロード・バランサが構成されています。たとえば、米国にいるユーザー1からのリクエストはすべてニューヨークのデータ・センター(NYDC)にルーティングされ、ヨーロッパにいるユーザー2からのリクエストはすべてロンドンのデータ・センター(LDC)にルーティングされます。
ノート:
図17-2のAccess Managerクラスタは互いに独立しており、同一のOracle WebLogicドメインに属してはいません。WebLogicドメインが複数のデータ・センターにまたがることはお薦めしません。
この例では、仮にNYDCがリクエストで過負荷になった場合、グローバル・ロード・バランサはユーザー1のリクエストを、LDCにあるクローンのAccess Managerクラスタにルーティングするようになります。(ユーザーのOAM_ID Cookieから)有効なセッションがマスター・クラスタ内にあると判断できるので、クローンのAccess Managerクラスタでは、認証も再認証も行わずに新しいセッションが作成されます。さらに、クローンのAccess ManagerクラスタがOracle Accessプロトコル(OAP)を使用してマスターのAccess Managerに対してセッションの詳細のバックエンド・リクエストを行うように、セッション・アダプション・ポリシーを構成することもできます。リモート・セッション(NYDCのセッション)を無効にして、ユーザーが一度に1つのデータ・センターのみでセッションを持つようにセッション・アダプション・ポリシーを構成することもできます。
図17-3は、マスター・クラスタが過負荷のとき、または停止したときにユーザーがどのように再ルーティングされるかを示しています。マスターのAccess Managerクラスタが完全に停止した場合は、クローンのAccess Managerクラスタがユーザー1のセッション詳細の取得を試行しますが、完全にアクセス不可能であるため、ユーザー1は強制的に再認証されることになり、新しいセッションがクローンのAccess Managerクラスタ内で確立されます。この場合は、前のセッションで保存されていた情報はすべて失われます。
ノート:
エージェント・フェイルオーバーのあるアクティブ/アクティブ・トポロジでは、エージェントのAccess Managerサーバーが一方のデータ・センターではプライマリとして構成され、他方のデータ・センターではセカンダリとして構成され、これによってフェイルオーバーのシナリオが支援されます。
アクティブ/アクティブ・トポロジの詳細は、「アクティブ/アクティブ・マルチデータ・センター・トポロジ・デプロイメント」を参照してください。
アクティブ/パッシブ・トポロジは、プライマリのデータ・センターが稼働可能であり、クローンのデータ・センターはそうでない場合です。このトポロジでは、プライマリのデータ・センターに障害が発生した場合に、合理的な時間内でクローンの稼働を開始させることができます。したがって、アクティブ/パッシブ・モードは、データ・センターの1つがパッシブで、サービスが開始されていません。
この場合、データ・センターはすぐに稼働可能になる必要はありませんが、プライマリのデータ・センターが停止した場合には合理的な時間内に稼働を開始させる必要があります。ポリシー・データは常に同期されますが、MDC設定を行う必要はありません。
アクティブ/ホット・スタンバイ。この場合、データ・センターの1つがホット・スタンバイ・モードです。この場合、アクティブ・データ・センターが停止していないかぎり、トラフィックはホット・スタンバイ・データ・センターにルーティングされません。
この場合、トラフィックに対応する追加のデータ・センターは毎日は必要ありませんが、1つは常に用意しておきます。アクティブ/ホット・スタンバイ・モードでのデプロイは、アクティブ/アクティブ・モードのステップに従いますが、ホット・スタンバイとして定義されているセンターにトラフィックをルーティングしません。ホット・スタンバイ・センターは引き続きデータを同期しますが、ロード・バランサまたは管理者によってトラフィックをそのセンターに転送したときにのみ使用されます。
