1. Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの理解
  3. マルチデータ・センター・デプロイメントについて

4 マルチデータ・センター・デプロイメントについて

この章では、マルチデータ・センター・アクティブ-パッシブまたはアクティブ-パッシブ障害保護、およびマルチデータ・センター・アクティブ-アクティブまたはアクティブ-アクティブ障害保護について説明します。

従来の障害保護システムは、マルチデータ・センター・アクティブ-パッシブまたはアクティブ-パッシブ障害保護と呼ばれ、発生する可能性があるフェイルオーバー・シナリオを回避するため、あるサイトが実行中に別のサイトをスタンバイさせるモデルを使用します。これらの障害保護システムは通常、運用および管理コストの増加を招きますが、リソースの連続使用とスループット向上(つまり、スタンバイ・マシンのアイドル状態回避)のニーズは年々増加しています。

容量の使用と負荷分散がITシステムの設計に占める割合が多くなってきているので、使用可能なすべてのリソースを可能なかぎり使用する障害保護ソリューションが採用されるようになります。これらの障害保護システムは、マルチデータ・センター・アクティブ-アクティブまたはアクティブ-アクティブ障害保護と呼ばれます。

Oracle Identity and Access Managementのマルチデータ・センター・デプロイメントは、次のトピックで説明します。

親トピック: エンタープライズ・デプロイメントの理解

Oracle Identity and Access Managementマルチデータ・センター・デプロイメントについて

Oracle Identity and Access Managementは複数の製品から構成され、それぞれの製品には異なる可用性の要件があります。

  • Oracle Access Management (OAM)は、資格証明の収集と他のシステム・リソースへのアクセスの付与に使用されます。

  • Oracle Identity Governance (OIG)は、新しいアカウントを作成し、これらのアカウントにアクセス権を付与できます。

多くの組織で両方の製品を使用し、統合して完全なソリューションにします。しかし、アクティブ-アクティブ・デプロイメントを達成するためのアプローチは、それぞれのケースで異なります。11gリリース2 (11.1.2.2.0)以降のOAMにはマルチデータ・センター・ソリューションがありますが、これはスタンドアロン・ソリューションであり、OIGと統合できます。2つの異なるソリューションの利点を最大限にするために、製品間の統合は慎重に扱う必要があります。

親トピック: マルチデータ・センター・デプロイメントについて

OAMとOIGのマルチデータ・センター・デプロイメントのアプローチについて

Oracle Access Management (OAM)とOracle Identity Governance (OIG)という2つの製品グループは、異なる方法で扱う必要があります。

  • OAMは2つの独立したデータベースと固有のOAMレプリケーション技術を使用して、これらのデータベースの同期を維持します。

  • OIGには専用マルチデータ・センター(MDC)ソリューションがないので、従来の障害回復ソリューションと類似のソリューションを使用する必要があります。つまり、このソリューションでは単一のデータベースが使用され、障害回復サイトにレプリケートされます。データベースへの書込みはすべて、アクティブなサイトに転送されます。

OIGデータベース層で障害が発生すると、データベースが回復を牽引するため、マルチデータ・センター・デプロイメント・アクティブ-アクティブもマルチデータ・センター・デプロイメント・アクティブ-パッシブも、同じようなリカバリ時間の目標(RTO)とリカバリ・ポイントの目標(RPO)を示します。どちらの場合も、データベースは一方のサイトでのみアクティブであり、他方のサイトではパッシブです。

マルチデータ・センター・アクティブ-アクティブ・デプロイメント・システムの唯一のメリットは、適切なデータ・ソース構成ならミドル層からのデータベース接続フェイルオーバーを自動化でき、RTOを削減できるということです(リカバリ時間が減少するのは、ミドル層の再起動が不要であるためです)。

障害がOAMデータベース層で発生しても、残ったデータベースがリクエストの処理を続行するので、システム上で認識できる影響は発生しません。OAMマルチデータ・センター・デプロイメントを構成するときに、フェイルオーバーを処理する方法をシステムに指示します。次のオプションがあります。

  • 何事もなかったかのように続行します。サイト2はサイト1から認証を受け入れます。

  • サイト2でセッションを強制的に再認証します。

OAMソリューションがアクティブ-アクティブの場合、OIGソリューションは通常はアクティブ-パッシブです。

OAM MDCソリューションと従来のストレッチ・クラスタ・アクティブ-パッシブ・ソリューションを使用するOIGを使用すれば、OAMとOIGを別々に処理できます。アクティブなデータガードを使用して2番目のサイトにレプリケートされる単一のアクティブなデータベースと、両方のサイトにまたがるストレッチWeblogicクラスタを使用すれば、同じように処理できます。単一のソリューションは保守と管理が容易ですが、アクティブ-アクティブが必要な場合、2つのサイトは近接している必要があります。アクティブ-パッシブを実行するOIGと組み合せたOAM MDCアプローチを使用する場合は、2つのサイトが遠くに離れていても問題ありません。

ただし、たとえ分散OAMアクティブ-アクティブ・ソリューションでも、OAMポリシーの変更はプライマリ・インスタンスとして指定された1つのインスタンスに行う必要があります。

OIGまたはOAMにストレッチ・クラスタ・デプロイメントを使用している場合、これらのサイトを同時に使用できるか、アクティブ-パッシブで使用できるかは、ネットワークの速度で決定されます。2つのサイト間のネットワーク・レイテンシが高いほど、パフォーマンスが低下します。ストレッチ・クラスタ・デプロイメントでは、5ミリ秒を超過するネットワーク・レイテンシは通常は許容範囲外とみなされます。この数値は指標の1つであり、他にトランザクション量など多くの要素が最小値に影響します。ストレッチ・クラスタをアクティブ-アクティブ・デプロイメントで使用している場合、適切な負荷テストを実施して、指定のトポロジに対して許容できるパフォーマンスを確保してください。

親トピック: Oracle Identity and Access Managementマルチデータ・センター・デプロイメントについて

OAMとOIGのマルチデータ・センター・デプロイメントについて

単一データセンター設計に適用される共通のパフォーマンス・パラダイムの他に、Oracle Identity and Access Managementマルチデータ・センター・アクティブ-アクティブ・システムは、サイト間のトラフィックを最小化して、システムのスループットに対するレイテンシの影響を低減する必要があります。標準的なOracle Identity and Access Managementシステムでは、データベース・アクセス(デハイドレーション、メタデータ・アクセス、およびシステムに関与するカスタム・サービスが実行する可能性があるその他のデータベース読取り/書込み操作)の他に、様々な層の間の通信が主に次のプロトコル経由で発生する可能性があります。

  • ロード・バランサ(LBR)またはOracle Web Server (Oracle HTTP Server)から受信するHTTP呼出しとHTTPコールバック

  • OAMとOIMの間で受信するHTTP呼出し

  • Oracle WebLogic Server間のJava Naming and Directory Interface (JNDI)/Remote Method Invocation (RMI)とJava Message Service (JMS)の呼出し

  • WebサーバーとOAM間のOracle Access Protocol (OAP)リクエスト

パフォーマンス向上のためには、前述のプロトコルすべてを可能なかぎり1つの単一サイトに制限する必要があります。つまり、SiteNのサーバーはSiteNのOracle Web Serverからの呼出しのみを受信するのが理想的です。これらのサーバーはJMS、RMIおよびJNDIの呼出しをSiteNのサーバーのみに行い、SiteXのサーバーで生成されたコールバックのみを取得します。さらに、サーバーは自分のサイトにローカルな記憶域デバイスを使用して、競合を解消します(サイト間のNFS書込みのレイテンシが原因で深刻なパフォーマンス低下が発生する可能性があります)。コンポーネントがSiteNで使用可能である場合のみ、リクエストが代替サイトに送信されます。

トポロジの一部である別のOracle Identity and Access Managementサーバー間で発生する可能性のある追加タイプの呼出しがあります。これらの呼出しは次のとおりです。

  • Oracle Coherence通知: Oracle Coherence通知は、どのサイトで処理されるものであっても、すべてのSOAリクエストに一貫性のあるcompoSiteおよびメタデータ・イメージを提供するために、システム内のすべてのサーバーに到達する必要があります。

  • HTTPセッション・レプリケーション: サーバー間でのセッションの透過的なフェイルオーバーを可能にするため、一部のOracle Identity and Access Managementコンポーネントではセッション・レプリケーションに依存する可能性があるステートフルなWebアプリケーションが使用されます。使用パターンとユーザー数によっては、かなりの量のレプリケーション・データが生成される可能性があります。業務上のケースごとにレプリケーションとフェイルオーバーの要件を分析する必要がありますが、レプリケーションのトラフィックはサイト間で可能なかぎり削減するのが理想的です

  • LDAP、ポリシーまたはアイデンティティ・ストアのアクセス: ポリシーおよびアイデンティティ・ストアへのアクセスは、認可および認証の目的でOracle WebLogic ServerインフラストラクチャとOracle Identity and Access Managementコンポーネントによって実行されます。双方のサイトのユーザーにシームレスにアクセスできるようにするには、共通のポリシーまたはアイデンティティ・ストア・ビューを使用する必要があります。各サイトに独立したアイデンティティおよびポリシー・ストアがあり、定期的に同期して、一方のサイトからもう一方のサイトへの呼出しが最小限になることが理想的です。

親トピック: Oracle Identity and Access Managementマルチデータ・センター・デプロイメントについて

Oracle Identity and Access Managementマルチデータ・センター・デプロイメントの管理

Oracle Identity and Access Managementマルチデータ・センター・デプロイメントの設計とデプロイメントの重要事項は、ソリューションが原因で発生する管理オーバーヘッドです。

リクエストに一貫性のある応答をするには、どのサイトがリクエストを処理しているかにかかわらず、関係するサイトで、システムの機能動作が同じになるような構成を使用する必要があります。Oracle Identity and Access Managementの構成とメタデータはOracleデータベースで保持されます。このため、一意のアクティブ・データベースを含むマルチデータ・センター・アクティブ-アクティブ・デプロイメントでは、コンポジットおよびメタデータのレベルで一貫性のある動作が保証されます(関与するアーティファクトに単一の真のソースがあります)。

ただし、Oracle WebLogic Server構成は、Oracle WebLogic Server Infrastructureによって、同じドメインの複数のノードにわたり同期を維持します。この構成の大半は通常、管理サーバーのドメイン・ディレクトリにあります。この構成は同じドメインでOracle WebLogic Serverを格納する他のノードに自動的に伝播されます。このため、マルチデータ・センター・アクティブ-アクティブ・デプロイメント・システムの管理オーバーヘッドは、構成変更を絶えずレプリケートする必要があるアクティブ-パッシブのアプローチに比べ、非常に小さくなります。

Oracle Fusion Middlewareバイナリはすべてのサイトで同一であることが必要なため、同じ場所に置き、同じパッチを適用するようにします。これは独立したインストールやディスク・ミラーリングで実現できます。ディスク・ミラーリングを使用している場合は、必ず2つの異なるバージョンを使用可能にし、破損したパッチの影響を受けるのがデプロイメントの半分(1つのサイト)のみになるようにし、バイナリの破損が障害回復サイトにレプリケートされないようにしてください。たとえば:

  • FMWバイナリ・セット1 – SiteAHost1、SiteAHost3、SiteAHost5

  • FMWバイナリ・セット2 – SiteAHost2、SiteAHost4、SiteAHost6

FMWバイナリ・セット1と2はサイト2にレプリケートされ、次の場所にマウントされます。

  • FMWバイナリ・セット1 (コピー) – SiteBHost1、SiteBHost3、SiteBHost5

  • FMWバイナリ・セット2 (コピー) – SiteBHost2、SiteBHost4、SiteBHost6

親トピック: マルチデータ・センター・デプロイメントについて

マルチデータ・センター・デプロイメントの要件について

Oracle Identity and Access Managementマルチデータ・センター・デプロイメントを設定するための要件は次のとおりです。

  • トポロジ

  • エントリ・ポイント

  • データベース

  • ディレクトリ層

これらの要件は次の項で説明します。

親トピック: マルチデータ・センター・デプロイメントについて

マルチデータ・センター・デプロイメントのトポロジについて

Oracle Identity and Access Managementアクティブ-アクティブ・マルチデータ・センター・デプロイメントのトポロジ・モデルを確認します。

記載されている分析と推奨事項は、この項で説明しているトポロジに基づきます。各サイトでは、わずかな変更が行われたバージョンのOracle Identity and Access Managementエンタープライズ・デプロイメント・トポロジをローカルで使用しています。詳細は、次の項を参照してください。

Oracle Identity and Access Managementマルチデータ・センター・トポロジ

Oracle Identity and Access Managementアクティブ-アクティブ・マルチデータ・センター・デプロイメントのトポロジでは次のようになります。

  • 2つの別々のサイト(今後、このドキュメントではサイト1、サイト2と記述)があり、1つの一意なアクセス・ポイントからアクセスされます。

    • グローバル・ロード・バランサ。トラフィックを各サイトに転送します(各ベンダーは異なるルーティング・アルゴリズムを提供します)。

    • ローカル・ロード・バランサ。各サイトのローカルなアクセス・ポイントであり、リクエストを複数のOracle HTTP Server (OHS)に分散します。次に、Identity and Access Managementコンポーネントをホスティングする特定のOracle WebLogic Serverにリクエストを割り当てます。

  • 各Oracle Access Management (OAM)実装は読取り/書込みの対象であるローカル・データベースにアクセスし、データベースはOAMレプリケーションを使用して同期を維持します。

  • Oracle Identity Governance (OIG)実装は1つの一意なデータベースを共有し、データベースは両方のサイト(どちらもアクティブな場合)のサーバーによって同時にアクセスされます。

  • 各サイトに複数のLightweight Direct Access Protocol (LDAP)サーバーがあり、これらのサーバーはOracle Unified Directory (OUD)レプリケーションを使用して同期を維持します。

  • サイト1には両方のサイトにまたがるOIGデプロイメント全体の管理サーバーがあります。

  • サイト1とサイト2にはローカルOAMデプロイメントの独立した管理サーバーがあります。

親トピック: マルチデータ・センター・デプロイメントの要件について

マルチデータ・センター・デプロイメントのエントリ・ポイントについて

このガイドの「エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備」で説明したとおり、Access and Identityには異なるエントリ・ポイントが存在するようになります。2つの異なるエントリ・ポイントがある理由は、各エントリ・ポイントを別々に構成できることです。たとえば:

  • login.example.comは、すべてのアクティブなOracle Access Managementサイト間にリクエストを地理的に分散するよう構成されます。

  • prov.example.comは、アクティブ-パッシブ・デプロイメントのアクティブなサイトのみにトラフィックを送信するように構成されます。

親トピック: マルチデータ・センター・デプロイメントの要件について

マルチデータ・センター・デプロイメントのデータベースについて

変更はサイト間で異なる方法で伝播するので(Oracle Access Management (OAM)とOracle Identity Governance (OIG)の両方でストレッチ・クラスタ設計を使用する場合を除く)、Oracle Identity and Access Management Suiteをサポートするには、2つの異なるデータベースが必要です。

OAMデータの同期化は、固有のOAM技術を使用して実行されます。この技術では、データをプライマリ・サイトから効果的にアップロードして、セカンダリ・サイトに転送し、SQLコマンドを使用してそのサイトのデータベースに適用します。プライマリ・サイトとセカンダリ・サイトのデータベースは独立しており、どちらも読取りと書込みが可能です。

同期性の要件、および異なるOIGコンポーネントで使用されるデータ型によって、マルチデータ・センター・デプロイメントのOIGデータベースに対して可能なアプローチが限定されます。このドキュメントでは、OIGで使用するOracle Fusion Middlewareデータベースが、Data Guardを使用してサイト1のアクティブなデータベースをサイト2のパッシブなデータベースと同期化する場合のソリューションにのみ対応しています。他のアプローチが有効な可能性もありますが、オラクル社によるテストおよび動作保証が行われていないため、このドキュメントでは説明しません。

この構成では、OIGがデプロイされる両方のサイトで、同じデータベース(およびそのデータベース内部の同じスキーマ)にアクセスし、データベースはData Guard構成で設定されるものとします。Data Guardは、データベースの総合的なデータ保護ソリューションを提供します。本番サイトとは地理的に異なる場所のスタンバイ・サイト1で構成されます。スタンバイ・データベースは通常はパッシブ・モードであり、本番サイト(データベース・アクティビティの視点から本番と呼ばれます)が使用できない場合に起動されます。

各サイトに構成されるOracleデータベースは、Oracle Real Application Cluster (RAC)にあります。Oracle RACを使用すると、Oracle Databaseを同じデータ・センターにあるサーバーのクラスタ全体で実行可能になり、アプリケーションを変更せずにフォルト・トレランス、パフォーマンスおよびスケーラビリティを確保できます。

データベース・トランザクションが一方のサイトから他方のサイトにスムーズに変換されるようにするため、ロールベース・データベース・サービスがプライマリ・データベース・サイトとセカンダリ・データベース・サイトの両方に作成されます。ロールベース・サービスを使用できるのは、データベースがプライマリ・ロールで実行されている場合、つまりデータベースが読取り/書込み用にオープンしている場合のみです。スタンバイ・データベースがプライマリ・データベースになると、サービスは自動的にそちら側で有効化されます。

WebLogicデータ・ソースがこのロールベース・サービスを使用するように構成し、データ・ソースに両方のサイトを認識させることで、プライマリ・データベースがサイト間で移動するときにWebLogicの再構成が不要になります

親トピック: マルチデータ・センター・デプロイメントの要件について

マルチデータ・センター・デプロイメントのディレクトリ層について

Oracle Identity Governance (OIG)のマルチデータ・センター・デプロイメントはOracle Unified Directory (OUD)を使用してテストされています。

OUDは疎結合されたデプロイメントです。データはOUDインスタンス間でOUDレプリケーションを使用してレプリケートされます。2番目のサイトはその原則が拡張されたもので、リモートOUDインスタンスがOUDレプリケーション構成の一部になります。

親トピック: マルチデータ・センター・デプロイメントの要件について

マルチデータ・センター・デプロイメントのロード・バランサについて

グローバル・ロード・バランサ(GLBR)とは、サイトおよびサイト外の場所のすべてのユーザーからアドレスとしてアクセスできるように構成されたロード・バランサです。このデバイスは、接続先のサイトにかかわらず、任意のクライアントからアクセス可能なDNS名にマップされた仮想サーバーを提供します。GLBRは設定された基準とルールをベースにして、トラフィックをどちらか一方のサイトに転送します。たとえば、クライアントのIPを基準のベースにできます。これらの基準とルールを使用して、GLBRが初回リクエスト時と次のリクエスト時にユーザーを同じサイトにマップできる永続性プロファイルを作成してください。GLBRは、すべてのローカル・ロード・バランサのアドレスから構成されるプールを保持します。サイトのいずれかで障害が発生すると、ユーザーはまだ機能しているアクティブなサイトに自動的にリダイレクトされます。

各サイトでローカル・ロード・バランサ(LBR)はGLBRからリクエストを受信し、リクエストを適切なHTTPサーバーに転送します。どちらの場合も、アフィニティを保持し、クライアントが適切に転送されるようにするため、LBRはクッキーのアクティブ・インサートのような永続メソッドを使用して構成されます。不要なルーティングと高コストな再ハイドレーションをなくすため、GLBRも構成されますが、コールバックを生成したサーバーに対してローカルなLBRにのみコールバックをルーティングするという特定のルールが適用されます。これは、Oracle Identity and Access Managementサービスの内部コンシューマにとっても有用です。

GLBRルールは次のようにまとめることができます。

  • リクエストがサイト1からのものである場合(サイト1のOracle Identity and Access Managementサーバーからのコールバック、またはサイト1のコンシューマからのエンドポイント呼出し)、GLBRはサイト1のローカル・ロード・バランサ(LBR)にルーティングします。

  • リクエストがサイト2からのものである場合(サイト2のOracle Identity and Access Managementサーバーからのコールバック、またはサイト2のコンシューマからのエンドポイント呼出し)、GLBRはサイト2のLBRにルーティングします。

  • リクエストが他のアドレスからのものである場合(クライアント呼出し)、GLBRは接続を両方のLBRにロード・バランシングします。

  • クライアント・リクエストはGLBRを使用して、リクエストを地理的に最も近いサイトに転送することもあります。

  • 追加のルーティング・ルールをGLBRで定義して、特定のクライアントを特定のサイトにルーティングすることもできます(たとえば、2つのサイトは各ケースのハードウェア・リソースが原因で応答時間が異なる可能性があります)。

ロード・バランサが「Oracle Access Management設計の特性」で示された要件を満たすかぎり、どのベンダーのロード・バランサもサポートされます。グローバル・ロード・バランサは、元のサーバーのIPに基づいて、ルールを許可するようにします(F5ネットワークの場合の例があります)。

親トピック: マルチデータ・センター・デプロイメントの要件について

トランザクション・ログと永続ストアの共有ストレージとデータベースの対比

「マルチデータ・センター・デプロイメントのトポロジについて」で示されるトポロジは、Oracle WebLogic Serverのトランザクション・ログおよびOracle WebLogic ServerのJMS永続性ストアのデータベースベース永続データ・ストアを使用してテストされました。

トランザクション・ログおよび永続ストアをデータベースに格納することにより、基礎となるデータベース・システムに固有のレプリケーションおよび高可用性の利点が提供されます。JMS、TLOG、およびOIM/SOAデータがData Guardデータベースにある場合、クロスサイトの同期が簡素化され、中間層において、NASやSANなどの共有記憶域サブシステムの必要性が低下します(管理サーバーのフェイルオーバーでは依然として必要です)。ただし、TLOGおよびJMSストアをデータベースで使用すると、システム・パフォーマンスが低下します。

Oracle Fusion Middleware 11g以降、データベース内の障害を処理するJMS JDBC永続性ストアの再試行ロジックは、単一の再試行に限定されます。2回目の試行で失敗すると、コール・スタックまで例外が伝播され、失敗したトランザクションに関連するメッセージをリカバリするにはサーバーを手動で再起動する必要があります(永続性ストアのエラーが原因で、サーバーの状態がFAILEDになります)。この障害を解決するために、関連するデータ・ソースに予約時の接続テストを使用して、関連するJMSサーバーと永続性ストアのインプレース再起動も構成することをお薦めします。インプレース再起動の詳細は、付録Bを参照してください。

親トピック: マルチデータ・センター・デプロイメントの要件について

マルチデータ・センター・デプロイメントの特性について

マルチデータ・センター・デプロイメントの特性、およびドメインを分割してIdentity and Accessのマルチサイト実装を別々に扱う方法を理解することが重要です。

  • Oracle Access Management (OAM)では、製品に組み込まれた独自のマルチサイト技術を使用できます。

  • Oracle Identity Manager (OIM)では、ネットワーク・レイテンシが高い場合にはアクティブ-パッシブ・アプローチを使用でき、ネットワーク・レイテンシが低い場合にはアクティブ-アクティブも使用できます。Governanceがアクティブ-パッシブで実行されている場合は、サイト2のOIMコンポーネントは必要になるまで停止します。

  • グローバル・ロード・バランサ(GLBR)は、トラフィックをアクティブなサイトにのみ送信するよう構成します。

  • 各OAMドメインには、管理機能用に個別のエントリポイントがあります。

  • OIM管理サーバーのフェイルオーバーは、サイト間で移動できるIGD_ASERVER_HOMEディレクトリと仮想IPアドレス(VIP)のディスクベース・レプリケーションを使用して実現できます。

  • OAM管理サーバーの障害は、標準的なEDG技術を使用してサイト内で処理されます。

マルチデータ・センター・デプロイメントの特性

可用性(Web層):

Oracle HTTP Server (OHS)の構成のベースは、各サイトのサーバーの固定リストです(OHSプラグインから提供され、標準的な単一の場所のデプロイメントで使用される動的リストではありません)。この構成は、あるサイトから別のサイトへの不要なルーティングをなくすためのものですが、この構成には、Oracle WebLogic Serverの障害に対応する時間が遅くなるというデメリットがあります。

次の項では、OAM設計とOIM設計の特性を説明します。

親トピック: マルチデータ・センター・デプロイメントについて

Oracle Access Management設計の特性

Oracle Access Management (OAM)設計の特性を確認してください。

  • 可用性

    OAMマルチデータ・センター・デプロイメントでは、各サイトが独立しているので、操作に対する影響はほとんどありません。OAMマルチデータ・センター・デプロイメントでは、あるサイトがプライマリとして指定され、そのサイトでエラーが発生すると、プライマリのロールがサイト2に渡されます。この影響を受けるのはポリシーの作成のみであり、実行時間は影響を受けません。ただし、実行時間については設計で配慮してください。

    リクエストがサイト1で認可され、サイト1が使用できなくなると、すでに発生した認証を受け入れるために、ユーザーをサイト2で強制的に再認証できます。

  • 管理

    マルチデータ・センター・アクティブ-アクティブ・デプロイメントでは、各サイトが他のサイトから独立しています。OAMレプリケーション・メカニズムがOAMデータのレプリケーションを処理しますが、WebLogicまたはアプリケーションの構成は各サイトで独立して実行する必要があります。OAMでは実行時アーティファクトが使用されず(認証クッキーを除く)、プロセスが簡略化されます。ただし、独立した構成が複数あるため、管理オーバーヘッドが増加します。

  • パフォーマンス

    ロード・バランシングに関する項で説明したとおりに適切なロード・バランシングとトラフィック制限を構成すると、サイト間のOAMのパフォーマンスは、単一サイトにある同数のサーバーを含むクラスタのパフォーマンスと同等になります。

  • ロード・バランシング

    OAMデプロイメントでは、ロード・バランサ仮想ホストはガイドでの説明どおりですが、次の違いがあります。

    • login.example.com: この仮想サーバーはローカルでも、グローバル・ロード・バランサのレベルでも、場所のアフィニティを使用して構成されます。

    • iadadmin.example.com: この仮想サーバーは各サイトで一意です。つまり、iadadminsite1.example.comとiadadminsite2.example.comがあります。

    • oam.example.com: この仮想サーバーは追加のロード・バランサのエントリ・ポイントです。各サイトで解決可能であり、リクエストをOAM管理対象サーバーのOAMプロキシ・ポート、たとえば5575にルーティングします。このロード・バランサのエントリ・ポイントはグローバル・ロード・バランサ(GLBR)レベルでも構成され、場所のアフィニティがある両方のマルチデータ・センター・ドメインにあるOAM管理対象サーバーのそれぞれにリクエストを配分します。GLBRレベルで構成することの長所は、サイト1の管理対象サーバーが使用できなくなっても、Web層が使用できれば、認証が可能であるということです。このアプローチの不利な面は、サイト間トラフィックが多量に生成されることです。各データ・センターはそれ自身が高可用性(HA)なので、2つのみのホストが停止の影響を受ける可能性は低いものの、両方の管理対象サーバーが停止すると、すべてのトラフィックが2番目のサイトにリダイレクトされます。トラフィックをリダイレクトするには、login.example.comモニタリング・サービスがWebサーバーだけでなくOAMサービスの可用性もモニターするように構成する必要があります。

      ノート:

      Oracle Access Protocol (OAP)リクエストはロード・バランサによって処理されているので、OAMサーバーが使用できないことをロード・バランサが検知すると、遅延が生じる可能性があります。

親トピック: マルチデータ・センター・デプロイメントの特性について

Oracle Identity Governance設計の特性

Oracle Identity Governance (OIG)設計の特性を確認してください。

  • 可用性

    データベース接続のフェイルオーバー動作とJMSおよびRMIのフェイルオーバー動作は、標準的なエンタープライズ・デプロイメント・トポロジで行われるフェイルオーバー動作と類似しています。すべての時点で、マルチデータ・センター・アクティブ-アクティブ・デプロイメントで使用可能なすべてのサーバーの中に、1つだけ単一のCLUSTER_MASTERサーバーがあり、自動回復を実行できます。相手サイトで障害が発生した場合、次のようにインスタンスはサイト1とサイト2から同じように回復できます。

    • CLUSTER MASTERがサイト1にあり、サイト2が稼働しているときはサイト1から。

    • CLUSTER MASTERがサイト2にあり、サイト1が稼働しているときはサイト2から。

    • サイト2が停止しているときはサイト1から。

    • サイト1が停止しているときはサイト2から。

    すべてのミドル層に影響する障害がサイト1で発生した場合、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを再開するために管理サーバーの回復が必要です。

    管理サーバーから離れた場所にあるサーバーは、通常のエンタープライズ・デプロイメント・トポロジにあるサーバーより再起動に必要な時間が長くなります。その理由は、管理サーバーとのすべての通信(起動時にドメイン構成を取得するためのもの)、最初の接続プール作成、およびデータベース・アクセスがサイト間のレイテンシの影響を受けるためです。

    リカバリ・ポイントの目標(RPO)の視点からは、サイトの障害によって停止したトランザクションを使用可能なサイトで再開するために、そのサイトで障害が発生したサーバーを手動で起動できます。サイト間での自動化されたサーバー移行は、データベースがJMSおよびTLOGの永続性のために使用されている場合にのみお薦めします。それ以外の場合は、適切な永続ストアの定期的なレプリカをサイト間で設定する必要があります。(顧客のインフラストラクチャによっては)あるサイトで使用されている仮想IPを他のサイトへの移行に有効活用できる可能性も高くはありません。最初はサイト1で使用可能であったリスニング・アドレスをサイト2向けに有効化、またはその逆方向に有効化するには、通常さらに操作が必要になるからです。この操作は移行前スクリプトで自動化できますが、(単一データ・センターの範囲内で発生する)標準の自動化サーバー移行と比較すると、リカバリ時間の目標(RTO)は一般に増加します。

  • パフォーマンス

    ロード・バランシングに関する項で説明したとおりに適切なロード・バランシングとトラフィック制限を構成すると、サイト間のレイテンシが低いストレッチ・クラスタのパフォーマンスは、単一サイトにある同数のサーバーを含むクラスタのパフォーマンスと同等になります。ロード・バランシングに関する項に記述されている構成ステップは、一番共通していて通常の操作について、各サイト内部のトラフィックを抑制するためのものです。ただし、分離が確定しているわけではないので(たとえば、2つのサイト間でJMS呼出しが行われる場合にフェイルオーバー・シナリオの余地があります)、トラフィックの大半がOIGサーバーとデータベースの間で行われることが暗示されます。これはアクティブ-アクティブ・シナリオで実行するマルチデータ・センターのパフォーマンスのキーです。

    レイテンシが高いネットワークによってサイトが分離される場合、パフォーマンスの著しい低下を回避するため、OIGをアクティブ-パッシブで実行してください。

  • 管理

    マルチデータ・センター・アクティブ-アクティブ・デプロイメントでは、Oracle WebLogic Serverのインフラストラクチャが、ドメインで使用されているすべての異なるドメイン・ディレクトリに、構成の変更をコピーします。構成されたCoherenceクラスタは、コンポジットまたはメタデータが更新されるときに、クラスタのサーバーすべてを更新します。ファイル・システム間の実行時アーティファクトのレプリケーション要件を除き、マルチデータ・センター・アクティブ-アクティブ・デプロイメントは標準的なクラスタのように管理されるので、その管理オーバーヘッドは非常に低くなります。

親トピック: マルチデータ・センター・デプロイメントの特性について