ヘッダーをスキップ
Oracle Access Managerデプロイメント・ガイド
10g（10.1.4.3）
B55479-01
  目次
目次		 索引
索引
戻る
戻る		 次へ
次へ		  

4 フェイルオーバーとロード・バランシング

フェイルオーバーとロード・バランシングは、Oracle Access Managerの可用性とパフォーマンスのためにきわめて重要です。ロード・バランシングでは、複数のサーバー間でリクエスト処理が分散されます。フェイルオーバーでは、最初のリクエスト送信先サーバーが使用不可の場合や処理に時間がかかる場合に、別のサーバーにリクエストがリダイレクトされます。

この章では次の内容について説明します。

Oracle Access Managerによるロード・バランシング

Oracle Access Managerは、ロード・バランシングを使用して複数の物理サーバーにサーバー・リクエストを分散させることにより、パフォーマンスを最大化します。次に示すコンポーネント間のロード・バランシングを構成します。

Oracle Access ManagerのWebコンポーネントとサーバー間の次に示すロード・バランシング:

Oracle Access Managerサーバーとディレクトリ・サーバー間の次に示すロード・バランシング:

LDAPデータのロード・バランシング

Oracle Access Managerは、マルチマスターのLDAP環境をサポートします。フェイルオーバーとロード・バランシングは、ユーザー・データとポリシー・データについてサポートされます。ただし、構成データはフェイルオーバーとロード・バランシングの対象外です。構成データには、システム構成、属性定義、属性アクセス制御、ワークフロー定義およびワークフロー・インスタンス・データが含まれます。

LDAPによるユーザー・データとグループ・データの書込みに対するロード・バランシングを構成する前に、LDAPレプリケーションによって望ましくない動作が発生する可能性があることに注意してください。あるインスタンスに対する更新が別のインスタンスに反映されるまで、時間がかかる場合があります。LDAPレプリケーションではトランザクションの整合性が保証されていないため、この制約はすべてのLDAPディレクトリ・サービスに継承されます。

ユーザー・データやグループ・データの読取り操作や書込み操作の負荷を分散する場合、データのクラスタリングやセグメント化が有効です。これは、DITの個別のブランチに個別のユーザー群が存在する場合に特に有効です。たとえば、あるサーバーがパートナのデータをou=partnersブランチの下に格納し、別のサーバーがサプライヤのデータをou=suppliersブランチの下に格納している場合などです。このような場合には、読取り操作や書込み操作に対してそれぞれ別のプライマリLDAPサーバー上に各データ・セットを保持することができます。また、可用性を向上させる目的で、各サーバー・クラスタは相互に他のLDAPサーバーにフェイルオーバーできます。これにより、LDAPマルチマスター間で読取り操作と書込み操作の負荷が分散されます。

Oracle Internet Directoryなどの一部のLDAPサーバーは、本来の意味での読取り操作と書込み操作のロード・バランシング機能を備えています。この方式で構成されたマルチマスターのLDAPサーバー上で更新が発生した場合、こうしたサーバーでは即時可用性が保証されます。このタイプのサーバーを使用すると、Oracle Access Managerを構成して、ユーザー・データおよびグループ・データの読取り操作や書込み操作のロード・バランシングを実現できます。

Oracle Access Managerの場合、ユーザー・ディレクトリおよびグループ・ディレクトリに対しても、Oracle Access Managerメタデータを含む構成ブランチに対しても、ラウンド・ロビンの書込み操作はサポートされていません。様々なアクセス・サーバーが設定されたラウンド・ロビン構成でWebGateおよびアクセスゲートが検出されると、たとえ各アクセス・サーバーがそれぞれ異なる単一の構成データのインスタンスを指していて、そのインスタンスが別々のマルチマスター・ディレクトリにホストされている場合でも、データの破損が起こる可能性があります。これは、ポリシー管理がオンになっていて、アイデンティティ・サーバー上（または両方）で自動キャッシュ・フラッシュが有効な場合に特に重要です。キャッシュが更新されるたびに、ポリシー・マネージャの構成データ内で少なくとも1つの書込み操作がトリガーされます。

Webコンポーネントのロード・バランシングの構成

Oracle Access Managerは、Webコンポーネント（WebPassおよびWebGate）から関連するサーバー（アイデンティティ・サーバーおよびアクセス・サーバー）に対するリクエストのロード・バランシングにおいて、単純なラウンド・ロビンと重み付けラウンド・ロビンの両方をサポートします。Oracle Access Managerサーバーに対するWebコンポーネント・リクエストのロード・バランシングは、Webコンポーネントの観点から見た場合、次の2つのキー・フィールドを使用して構成します。

この項では、ご使用の環境に応じて複数の手順を説明します。

単純なラウンド・ロビンのロード・バランシングの構成

Webコンポーネント・リクエストに対して単純なラウンド・ロビンによるロード・バランシングを構成するということは、1つのWebコンポーネントにより、関連する各プライマリOracle Access Managerサーバーに対して1つの接続がリストされている順に開かれ、各サーバーに均等にリクエストが分配されるということです。

たとえば、図4-1に示すように、1つのWebPassと2つのプライマリ・アイデンティティ・サーバーがあるとします。この場合、WebPassにより、リストされている順に各アイデンティティ・サーバーへの接続が開かれます。WebPassは、request1をアイデンティティ・サーバーP1に、request2をアイデンティティ・サーバーP2に、request3をアイデンティティ・サーバーP1に、というように送信します。

図4-1 Webコンポーネント・リクエストの単純なラウンド・ロビンのロード・バランシング

Webコンポーネント・リクエストの単純なラウンド・ロビンのロード・バランシング
「図4-1 Webコンポーネント・リクエストの単純なラウンド・ロビンのロード・バランシング」の説明

次に示す手順に従って、単純なラウンド・ロビンのロード・バランシングを構成できます。この場合の最大接続数は、特定の時間に1つ以上のプライマリ・アイデンティティ・サーバーまたはアクセス・サーバーに対して確立する活動状態の接続の合計数です。Webコンポーネントがプライマリ・サーバーのいずれかに対して接続を確立できない場合、セカンダリ・サーバーに対する接続の確立が実行されます。最初の接続数は、プライマリおよびセカンダリの両方のOracle Access Managerサーバーに適用されます。

単純なラウンド・ロビンのロード・バランシングを構成する手順

  1. リクエストのロード・バランシングを行うWebコンポーネント構成にアクセスします。

    次に例を示します。

    • アイデンティティ・システム・コンソールから、「システム構成」→「Webパス」を選択します。

    • アクセス・システム・コンソールから、「アクセス・システム構成」→「アクセスゲート構成」を選択します。

    Webコンポーネントの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』および『Oracle Access Managerアクセス管理ガイド』を参照してください。

  2. このWebPassまたはWebGate用に開く「最大接続数」を入力します。

  3. 関連する各Oracle Access Managerサーバーの「最初の接続数」は、デフォルト値の1のままにしてください。

重み付けラウンド・ロビンのロード・バランシングの構成

使用する複数のOracle Access Managerサーバー間でパフォーマンスにばらつきがある場合、重み付けラウンド・ロビンによるWebコンポーネント・リクエストのロード・バランシングを構成できます。重みを付けたロード・バランシングを構成する場合の主な違いは、各サーバーに対して確立する最初の接続数を調整することです。

図4-2に例を示します。図4-2に示すように、2つのプライマリ・アイデンティティ・サーバーがあるとします。ただし、アイデンティティ・サーバーP1にはさらに多くの負荷を割り当てることができます。そこで、アイデンティティ・サーバーP1に対して2つの接続を開き、アイデンティティ・サーバーP2に対して1つの接続を開くようWebPassを構成します。この場合、WebPassの最大接続数は3になり、request1をアイデンティティ・サーバーP1に、request2をアイデンティティ・サーバーP2に、request3をアイデンティティ・サーバーP1に、というように送信します。


注意:

アクセスゲートとアクセス・サーバー・クラスタを関連付けた場合、Oracle Access Managerにより、アクセスゲートとクラスタ内のすべてのアクセス・サーバーの間の接続数が、クラスタに指定された最大接続数に基づいて自動的に構成されます。ロード・バランシングは動的に構成され、Oracle Access Managerはクラスタ内で最も負荷の軽いアクセス・サーバーに対してアクセスゲートからリクエストをルーティングするように指示を出します。

図4-2 2つのサーバーを使用してフェイルオーバーを使用しない、重み付けロード・バランシングのレイアウト

重み付けロード・バランシングのレイアウト
「図4-2 2つのサーバーを使用してフェイルオーバーを使用しない、重み付けロード・バランシングのレイアウト」の説明

ここでも、指定する最大接続数は、特定の時間に1つ以上のプライマリ・アイデンティティ・サーバーに対して確立する活動状態の接続の合計数です。WebPassがプライマリ・サーバーのいずれかに対して接続を確立できない場合、別のプライマリ・サーバーに対する接続の確立が実行されます。

最初の接続数もまた、プライマリ・サーバーとセカンダリ・サーバーの両方に適用されます。アクセスゲートとアクセス・サーバー・クラスタを関連付けた場合、Oracle Access Managerにより、アクセスゲートとクラスタ内のすべてのアクセス・サーバーの間の接続数が、クラスタに指定された最大接続数に基づいて自動的に構成されます。ロード・バランシングは動的に構成され、Oracle Access Managerはクラスタ内で最も負荷の軽いアクセス・サーバーに対してアクセスゲートからリクエストをルーティングするように指示を出します。

Webコンポーネント・リクエストの重み付けラウンド・ロビンのロード・バランシングを構成する手順

  1. ロード・バランシングを構成するWebコンポーネントにアクセスします。

    次に例を示します。

    • アイデンティティ・システム・コンソールから、「システム構成」→「Webパス」を選択します。

    • アクセス・システム・コンソールから、「アクセス・システム構成」→「アクセスゲート構成」を選択します。

  2. 該当のWebPass用に開く「最大接続数」を入力します。

  3. 関連するOracle Access Managerサーバーのそれぞれに対して、サーバーの性能を考慮した「最初の接続数」を入力します。

Oracle Access Managerとディレクトリ・サーバー間のロード・バランシングの構成

2つ以上のディレクトリ・サーバーに対して、単純なラウンド・ロビンによるOracle Access Managerサーバー・リクエストのロード・バランシングを実行できます。


注意:

多くの機能が前のリクエストから引き継がれたデータに依存しているため、Oracle Access Managerでは、通常の場合構成データのロード・バランシングはサポートされていません。ロード・バランシングを行う環境では、このデータはレプリケートされたサーバーでまだ有効になっていない可能性があります。

ディレクトリ・サーバーのロード・バランシングの構成手順は、コンポーネントのタイプ（アイデンティティ・サーバー、アクセス・サーバー、ポリシー・マネージャ）と、ユーザー・データと構成データのいずれに対してロード・バランシングを構成するかによって異なります。データ・ストアのタイプおよび操作の概要は、表4-1を参照してください。


注意:

Oracle Access Managerは、Oracle Access ManagerコンポーネントとのLDAP通信用のハードウェアのロード・バランサをサポートします。この章で説明しているルールと制約は、Oracle Access Managerの内部ロード・バランシング機能およびハードウェアのロード・バランサに適用されます。詳細は、My Oracle Support（以前はMetaLink）のWebサイト（http://metalink.oracle.com）のNote 793152.1を参照してください。

Oracle Access Managerの以前のバージョンでは、ディレクトリ接続情報はXML構成ファイルによってのみ管理されていました。Oracle Access Managerの最近のバージョンでは、アイデンティティ・システム・コンソールおよびアクセス・システム・コンソールの「ディレクトリ・プロファイル」ページを使用するインタフェースからこうした情報を管理する機能が用意されています。ただし、構成データとポリシー・データの一部は、依然としてXMLファイルによって管理されています。そのため、ロード・バランシングの構成は複数の方法を組み合せて行います。


注意:

アイデンティティ・サーバーは、ポリシー・ディレクトリの参照整合性を適用する際に、ポリシー・ツリー用に構成されたプロファイルに依存します。このプロファイルは、ポリシー・マネージャの設定時に、アイデンティティ・サーバー・コンポーネントのポリシー・ディレクトリ用に作成されます。ユーザーがアイデンティティ・システムからDNを変更すると、アイデンティティ・サーバーはこのプロファイルを使用してポリシー・ディレクトリ内のDN参照をすべて更新します。

表4-1 ディレクトリ・サーバーのロード・バランシングの構成

コンポーネント データ・ストア 操作

アイデンティティ・サーバー

ユーザー

READ: 「ディレクトリ・プロファイル」で構成。「ユーザー・データのロード・バランシングの構成」を参照してください。

WRITE: サポートされていません。

構成

READ: サポートされていません。

WRITE: サポートされていません。

アクセス・サーバー

ユーザー

READ: 「ディレクトリ・プロファイル」で構成。

WRITE: サポートされていません。注意: 書込み操作は、パスワード・ポリシーが有効な場合のみアクセス・サーバーに適用されます。

構成

READ: configureAAAServerコマンドライン・ツールで構成。「構成データおよびポリシー・データのロード・バランシングの構成」を参照してください。

WRITE: なし。

ポリシー

READ: configureAAAServerコマンドライン・ツールで構成。

WRITE: なし。

注意: 該当のアクセス・サーバーに対してアクセス管理サービスが有効である場合、ポリシー情報を含むデータ・ストアに対して、アクセス・サーバーからのリクエストのロード・バランシングを実行することはできません。

ポリシー・マネージャ

ユーザー

READ: 「ディレクトリ・プロファイル」で構成。

この項では次の手順を説明します。

ユーザー・データのロード・バランシングの構成

デフォルトでは、Oracle Access Managerにより、インストールされているコンポーネントごとにディレクトリ・プロファイルが作成されます。ユーザー・データを含むディレクトリ・サーバーに対するOracle Access Managerリクエストのロード・バランシングを構成するには、「ディレクトリ・プロファイル」ページを使用します。ディレクトリ・プロファイルの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

最大アクティブ・サーバー数: 常に稼働状態にするプライマリ・ディレクトリ・サーバーの合計数です。リクエストは、これらのサーバーに均等に分配されます。

図4-3に示すような、2台のプライマリ・ディレクトリ・サーバーと1台のセカンダリ・ディレクトリ・サーバーの構成を想定します。プライマリ・ディレクトリ・サーバー間でロード・バランシングを行うため、「最大アクティブ・サーバー数」に「2」を入力します。セカンダリ・ディレクトリ・サーバーが関係するのはフェイルオーバーの場合のみであるため、この設定には影響を及ぼしません。

図4-3 Oracle Access Managerリクエストのディレクトリ・サーバーへのロード・バランシング

アクセス・リクエストおよびIDリクエストのロード・バランシング
「図4-3 Oracle Access Managerリクエストのディレクトリ・サーバーへのロード・バランシング」の説明

ユーザー・データのロード・バランシングを構成する手順

  1. 「ディレクトリ・プロファイル」ページにアクセスします。

    次に例を示します。

    • アイデンティティ・システム・コンソールから、「システム構成」→「ディレクトリ・プロファイル」を選択します。

    • アクセス・システム・コンソールから、「システム構成」→「サーバー設定の表示」→「ディレクトリ・オプション」を選択します。

  2. 「LDAPディレクトリ・サーバー・プロファイルの構成」の下で、ロード・バランシングの対象となるコンポーネントとデータのプロファイル名を選択します。

  3. ロード・バランシングに対して有効にする「最大アクティブ・サーバー数」の値を入力します。

構成データおよびポリシー・データのロード・バランシングの構成

構成データまたはポリシー・データ、およびその両方を含むディレクトリ・サーバーに対するアクセス・サーバー・リクエストのロード・バランシングを構成する場合は、configureAAAServerツールを使用します。以降の手順では、2台以上のプライマリ・ディレクトリ・サーバーが設定されていることを前提としています。


注意:

通常の場合、構成データのロード・バランシングはアイデンティティ・サーバーではサポートされていません。この手順では、アクセス・サーバーのみを対象とします。configureAAAServerは古いツールであるため、最新のネーミング規則に準拠していません。このツールで表示される最大接続数は、前述の「最大アクティブ・サーバー数」の値と同じです。

アクセス・サーバーに対する構成データおよびポリシー・データのロード・バランシングを構成する手順

  1. コマンド・プロンプトから、AccessServer_install_dir/access/oblix/tools/configureAAAServer内のconfigureAAAServerツールにアクセスします。

  2. configureAAAServerユーティリティにreconfiginstall_dirオプションを指定して実行します。

    このinstall_dirは、アクセス・サーバーがインストールされているディレクトリの名前です。

    次に例を示します。

    configureAAAServer reconfig "c:\Program Files\COREid1014\access"

  3. アクセス・サーバーのセキュリティ・モードに対応する番号を入力します。これは、ディレクトリ・サーバーに接続するアクセス・サーバーです。

    • 1）オープン

    • 2）簡易

    • 3）証明書

    ここで、構成またはポリシーのフェイルオーバー情報を指定するかどうかをたずねるメッセージが表示されます。

  4. 「はい」（Y）を選択します。

  5. データを次のどちらに格納するかを指定します。

    • 1）Oblixツリー

    • 2）ポリシー・ツリー

  6. フェイルオーバー・サーバーを追加するには、次に示すプロンプトで「1」を入力します。

    • 1）フェイルオーバー・サーバーを追加します

    • 2）フェイルオーバー・サーバーを変更します

    • 3）フェイルオーバー・サーバーを削除します

    • 4）共通パラメータを変更します

  7. 次の情報を入力します。

    • ディレクトリ・サーバー名

    • ディレクトリ・サーバーのポート

      Active Directory Forest環境のLDAPの場合、オープン・モードにポート3268を使用し、SSLモードにポート3269を使用します。これら2つのポートは、グローバル・カタログのポートです。

    • ディレクトリ・サーバーのログインDN

    • ディレクトリ・サーバーのパスワード

    • ディレクトリ・サーバーのセキュリティ・モード

      • 1）オープン

      • 2）SSL

  8. ロード・バランシングを構成しているため、優先度として「1」を入力します。

    • 1）プライマリ

    • 2）セカンダリ

  9. 共通パラメータを変更するには「4」を入力します。

  10. 「最大アクティブ・サーバー数」を指定するには、「1」を入力します。

    ツール内で表示される最大接続数は、「Oracle Access Managerとディレクトリ・サーバー間のロード・バランシングの構成」で説明した「最大アクティブ・サーバー数」の値と同じです。

  11. ロード・バランシングに使用できるプライマリ・ディレクトリ・サーバーの合計数を入力します。

  12. 終了するには「5」を入力します。

  13. 変更をコミットするには「1」を入力します。

ディレクトリ・サーバー・インスタンスの接続プーリングの調整

「最大アクティブ・サーバー数」パラメータを使用して、ディレクトリ・サーバー・インスタンス間に均等にリクエストのロード・バランシングを行うことができます。また、特定のディレクトリ・サーバー・インスタンスの「最初の接続数」と「最大接続数」を入力することにより、該当のサーバー・インスタンス内で接続プーリングを調整することもできます。このリクエストは、最小の負荷設定で接続に送信されます。

ロード・バランシングの構成と同様に、次に示す方法でディレクトリ・プールの接続を調整する必要があります。

ディレクトリ・プロファイルからディレクトリ接続プーリングを調整する手順

  1. 「ディレクトリ・プロファイル」ページから、特定のDB（ディレクトリ）インスタンスを選択します。

  2. このディレクトリ・サーバーに対して開かれる「最初の接続数」を入力します。

    デフォルト値は1です。

  3. このディレクトリ・サーバー・インスタンスに許可される「最大接続数」の値を入力します。

    ディレクトリ・サーバーへの接続が失われた場合、Oracle Access Managerは入力された最大値の範囲内で接続を開こうとします。

    最初のリクエストがディレクトリ・サーバーに送信されると、最初の接続数分の接続が開かれます。接続が失われた場合、またはサービスのスレッド数が接続より多くなった場合、（最大数の範囲内で）新しい接続が開かれます。図4-4の例を参照してください。

図4-4 ディレクトリ・サーバー・インスタンスの接続プーリングの調整

ディレクトリ・サーバー・インスタンスの接続プーリングの調整
「図4-4 ディレクトリ・サーバー・インスタンスの接続プーリングの調整」の説明

たとえば、ディレクトリ・サーバーの最初の接続数が5、最大接続数が10に設定されていると仮定します。サービスのスレッドによってディレクトリ・サーバーへのリクエストが生成されると、最初の5つの接続が作成されます。ここで、ディレクトリ・サーバーからの情報を必要とする同時アクティブ・サービス・スレッドが5つあるとします。この場合、既存の5つの接続がすべて使用されます。

同時に稼働するサービス・スレッドが増えてさらに5つ以上の接続を使用する場合、Oracle Access Managerはこのディレクトリ・サーバーに対して最大10までの接続を作成できます。接続数の上限の10に到達し、同時に稼働するサービス・スレッドが11を超えると、11番目のサービス・スレッドは10の接続のプールから最も負荷の少ない接続を取得します。この接続は、複数のサービス・スレッドで共有されます。


注意:

最初の接続数や最大接続数に対する標準的な最適値は存在しません。ディレクトリ構成やハードウェアなどの特定の変数に対しても、標準的な最適値は存在しません。ただし、所定のOracle Access Managerサーバーのスレッド数を超える数の接続数を設定しないでください。

configureAAAServerツールを使用してディレクトリ接続プーリングを調整する手順

  1. 「アクセス・サーバーに対する構成データおよびポリシー・データのロード・バランシングを構成する手順」を参照してください。

  2. メッセージが表示されたら、「共通パラメータを変更します」オプションを指定します。

Oracle Access Managerによるフェイルオーバー

Oracle Access Managerはフェイルオーバーを使用することにより、中断することなくサービスを提供します。フェイルオーバーには、リクエストの元の宛先に障害が発生した場合に、リクエストを別のサーバーにリダイレクトする機能が用意されています。

フェイルオーバーを実現するには、プライマリ・サーバーとセカンダリ・サーバーを構成し、フェイルオーバー・プロセス用に特定のパラメータを指定します。フェイルオーバーは、次の組合せで構成できます。

プライマリ・サーバーとセカンダリ・サーバー

Oracle Access Managerコンポーネントは、最初にプライマリ・サーバーへの接続を試みます。

プライマリ・サーバーが使用できない場合、セカンダリ・サーバーへの接続を試みます。Oracle Access Managerは引き続きプライマリ・サーバーへの接続を試み、接続が再度確立されると、セカンダリ・サーバーへの接続をドロップします。任意のサーバーを、プライマリ・サーバーまたはセカンダリ・サーバーとして構成できます。たとえば、処理能力の低いサーバーや地理的に離れた場所にあるサーバーをセカンダリ・サーバーとして指定できます。

Oracle Access Managerとディレクトリ・サーバー間のフェイルオーバー

活動状態のプライマリ・ディレクトリ・サーバーの数が「フェイルオーバーしきい値」フィールドの値を下回った場合に、Oracle Access Managerサーバーのフェイルオーバーが発生します。Oracle Access Managerコンポーネントからディレクトリ・サーバーへのフェイルオーバーの構成手順は、コンポーネントのタイプ（アイデンティティ・サーバー、アクセス・サーバー、ポリシー・マネージャ）と、ユーザー・データと構成データのいずれに対してフェイルオーバーを構成するかによって異なります。


注意:

アイデンティティ・サーバーは、ポリシー・ディレクトリの参照整合性を適用する際に、ポリシー・ツリー用に構成されたプロファイルに依存します。このプロファイルは、ポリシー・マネージャの設定時に、アイデンティティ・サーバー・コンポーネントのポリシー・ディレクトリ用に作成されます。ユーザーがアイデンティティ・システムからDNを変更すると、アイデンティティ・サーバーはこのプロファイルを使用してポリシー・ディレクトリ内のDN参照をすべて更新します。

表4-2 サポートされるディレクトリ・サーバーのフェイルオーバー構成

コンポーネント データ・ストア 操作

アイデンティティ・サーバー

ユーザー

READ/WRITE: ディレクトリ・プロファイルで構成

構成

READ/WRITE: ディレクトリ・プロファイルとXML構成ファイルで構成

アクセス・サーバー

ユーザー

READ/WRITE: ディレクトリ・プロファイルで構成WRITEは、パスワード・ポリシーが有効な場合にのみ適用可能

構成

READ: configureAAAServerコマンドライン・ツールで構成

ポリシー

READ: configureAAAServerコマンドライン・ツールで構成

ポリシー・マネージャ

ユーザー

READ: ディレクトリ・プロファイルで構成

構成

ポリシー

READ: XML構成ファイル


注意:

アイデンティティ・サーバーは、ポリシー・ディレクトリの参照整合性を適用する際に、ポリシー・ツリー用に構成されたプロファイルに依存します。このプロファイルは、ポリシー・マネージャの設定時に、アイデンティティ・サーバー・コンポーネントのポリシー・ディレクトリ用に作成されます。ユーザーがアイデンティティ・システムからDNを変更すると、アイデンティティ・サーバーはこのプロファイルを使用してポリシー・ディレクトリ内のDN参照をすべて更新します。

Webコンポーネントのフェイルオーバーの構成

フェイルオーバーを構成すると、WebPassまたはWebGateによって接続状態を確認できます。また、1台以上のプライマリ・サーバーが停止した場合に、セカンダリのOracle Access Managerサーバーへのフェイルオーバーを実行することもできます。Webコンポーネントの観点からフェイルオーバーを構成します。図4-5の例を参照してください。

図4-5 WebGateとアクセス・サーバー間の基本的なフェイルオーバーのシナリオ

WebGateとアクセス・サーバー間のフェイルオーバー
「図4-5 WebGateとアクセス・サーバー間の基本的なフェイルオーバーのシナリオ」の説明

フェイルオーバーしきい値: フェイルオーバーを構成する際に重要になるのは、Webコンポーネント構成の「フェイルオーバーしきい値」フィールドです。このフィールドは、活動状態のプライマリ接続の必要最小値を指定します。活動状態の接続数がフェイルオーバーしきい値を下回ると、Webコンポーネントはリストされている順にセカンダリ・サーバーへの接続の確立を試みます。デフォルト値は最大接続数です。

スリープ時間の間隔: デフォルト値は60秒です。この時間の経過後、WebPassまたはWebGateにより、有効な接続数が構成済の最大接続数と等しいかどうかが確認されます。有効な接続数が最大接続数に等しくない（フェイルオーバーしきい値を下回る）場合、Webコンポーネントはセカンダリ・サーバーへの接続をセカンダリ・サーバーが構成された順に確立しようとします。次に、Webコンポーネントは、指定された間隔でプライマリ・サーバーへの接続の確立を試みます。接続が確立されると、処理中のリクエストの終了後に、セカンダリ・サーバーへの接続がドロップされます。

タイムアウトしきい値: 応答のないOracle Access Managerサーバーを到達不能と判断して別のサーバーへの接続を試みるまでに、Webコンポーネントが待機する時間の長さ（秒数）を指定します。この値を指定しなかった場合は、タイムアウトは発生しません。その場合、Webコンポーネントは永久にOracle Access Managerサーバーからのレスポンスを待機します。タイムアウトを設定しないと、セッションがハングするか、TCPのタイムアウトがデフォルト値となる可能性があります。次に例を示します。

図4-6の場合、WebGateは2つのプライマリ・アクセス・サーバー（アクセス・サーバーP1およびアクセス・サーバーP2）と通信しています。

図4-6 WebGateとそれに関連するアクセス・サーバー間のフェイルオーバーのシナリオ

WebGateとそれに関連するアクセス・サーバー間のフェイルオーバー
「図4-6 WebGateとそれに関連するアクセス・サーバー間のフェイルオーバーのシナリオ」の説明

Webコンポーネント・リクエストのフェイルオーバーを構成する手順

  1. フェイルオーバーを構成するWebコンポーネントのWebPassまたはWebGateにアクセスします。

    次に例を示します。

    • アイデンティティ・システム・コンソールから「システム構成」を選択し、左のナビゲーション・ペインにある「Webパス」リンクをクリックします。次にWebPassを選択して「変更」をクリックします。

    • アクセス・システム・コンソールから、「アクセス・システム構成」→「アクセスゲート構成」→「すべて」→「実行」を選択し、WebGateを選択します。

    詳細は、『Oracle Access Manager IDおよび共通管理ガイド』および『Oracle Access Managerアクセス管理ガイド』を参照してください。

  2. 「フェイルオーバーしきい値」フィールドで、WebコンポーネントからプライマリのOracle Access Managerサーバーに対する必要な活動状態の接続数を入力します。

  3. 「スリープ時間」の間隔を秒数で入力します。

  4. タイムアウトしきい値に、応答のないOracle Access Managerサーバーを到達不能と判断して別のサーバーへの接続を試みるまでに、Webコンポーネントが待機する時間の長さ（秒数）を入力します。

    • WebPass: 「アイデンティティ・サーバー・タイムアウトしきい値」に値を入力します。

    • アクセスゲート: 「アクセス・サーバー・タイムアウトしきい値」に値を入力します。

  5. 変更を保存します。

ユーザー・データ用ディレクトリのフェイルオーバーの構成

ユーザー・データを含むディレクトリ・サーバーへのOracle Access Managerリクエストのフェイルオーバーを構成するには、「ディレクトリ・プロファイル」ページを使用します。

フェイルオーバーしきい値: 活動状態のプライマリ・ディレクトリ・サーバーの必要数。プライマリ・サーバーの数がフェイルオーバーしきい値を下回る場合、Oracle Access Managerはセカンダリ・ディレクトリ・サーバーへのフェイルオーバーを実行します。

Oracle Access Managerサーバーがディレクトリ接続のいずれかに対してリクエストを送信し、LDAP SDKが接続エラーまたはサーバー停止エラーを返した場合、ディレクトリ・サーバーは使用できないものと判断されます。プライマリ・ディレクトリ・サーバーの数がフェイルオーバーしきい値を下回ると、Oracle Access Managerはリストされている順にセカンダリ・サーバーへの接続の確立を試みます。

フェイルオーバーが発生した時点で使用可能なプライマリ・サーバーがある場合、Oracle Access Managerサーバーは最初にプライマリ・サーバーへのフェイルオーバーを実行します。

スリープ時間: ウォッチャ・スレッドが起動され、接続の再確立および（接続が停止していた場合に）新しい接続の作成が実行されるまでの秒数を指定します。ウォッチャ・スレッドにより、正常な接続のプールが常に維持されます。

デフォルトでは、Oracle Access Managerにより、インストールされているコンポーネントごとにディレクトリ・プロファイルが作成されます。このページにアクセスして、ディレクトリのフェイルオーバーを構成する必要があります。ディレクトリ・プロファイルの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

ユーザー・データのディレクトリ・フェイルオーバーを構成する手順

  1. システム・コンソールに移動して、「ディレクトリ・プロファイル」ページにアクセスします。

    次に例を示します。

    • アイデンティティ・システム・コンソールから、「システム構成」→「ディレクトリ・プロファイル」を選択します。

    • アクセス・システム・コンソールから、「システム構成」→「サーバー設定」を選択します。

  2. コンポーネントの接続情報およびフェイルオーバー対象のデータを含むディレクトリ・プロファイルへのリンクを選択します。

  3. 「フェイルオーバーしきい値」を入力します。

  4. 「スリープ時間」フィールドに、ウォッチャ・スレッドが起動されて接続の再確立および（接続が停止していた場合に）新しい接続の作成が実行されるまでの秒数を指定します。

  5. 「データベース・インスタンス」を追加し、セカンダリ・サーバーとしてのステータスを指定します。

構成データおよびポリシー・データ用ディレクトリのフェイルオーバーの構成

Oracle Access Managerコンポーネントからディレクトリ・サーバーへのフェイルオーバーの構成手順は、コンポーネントのタイプ（アイデンティティ・サーバー、アクセス・サーバー、ポリシー・マネージャ）と、ユーザー・データと構成データのいずれに対してフェイルオーバーを構成するかによって異なります。ディレクトリ・サーバーに対してサポートされているフェイルオーバーの構成の詳細は、表4-2を参照してください。

タスクの概要: 構成データおよびポリシー・データ用のディレクトリ・フェイルオーバーの構成

  1. 詳細は、「構成データに対するアイデンティティ・サーバーのフェイルオーバーの構成」を参照してください。

  2. 詳細は、「構成データおよびポリシー・データに対するアクセス・サーバー・ディレクトリのフェイルオーバーの構成」を参照してください。

構成データに対するアイデンティティ・サーバーのフェイルオーバーの構成

アイデンティティ・サーバーの場合、大部分の構成データは依然としてXML構成ファイルによって管理されます。ただし、マルチ言語データおよび参照整合性データは「ディレクトリ・プロファイル」ページから管理されます。

プライマリ構成データ・ディレクトリ・サーバーが停止している場合、アイデンティティ・サーバーによって構成エントリを読み取る方法はありません。そのため、アイデンティティ・サーバーはfailover.xmlを読み取り、セカンダリ・ディレクトリ・サーバーのブートストラップ情報を取得します。例については、「サンプルFailover.xml」を参照してください。

タスクの概要: 構成データ用のアイデンティティ・サーバーのフェイルオーバーの構成

  1. 構成データ用のフェイルオーバーの構成

    詳細は、「構成データに対するアイデンティティ・サーバー・ディレクトリのフェイルオーバーを構成する手順」を参照してください。

  2. 暗号化されたパスワードを作成します。

    詳細は、「バインドDN用の暗号化されたパスワードを作成する手順」を参照してください。

  3. failover.xmlを構成します。

    詳細は、「failover.xmlを作成する手順」を参照してください。

構成データに対するアイデンティティ・サーバー・ディレクトリのフェイルオーバーを構成する手順

  1. 「ユーザー・データ用ディレクトリのフェイルオーバーの構成」で説明しているように、「ディレクトリ・プロファイル」ページから、構成のツリー・ブランチを含むディレクトリ・プロファイルのフェイルオーバーの指定を入力します。

  2. ファイルfailover.xmlを作成し、IdentityServer_install_dir/identity/oblix/config/ldapディレクトリに追加します。

バインドDN用の暗号化されたパスワードを作成する手順

  1. obencryptツールを次の場所に配置します。

    AccessServer_install_dir/access/oblix/tools/ldap_tools/

  2. obencrypt passwordを実行します。

  3. 「failover.xmlを作成する手順」で説明しているように、暗号化されたパスワードをコピーしてフェイルオーバー・ファイルに貼り付けます。

failover.xmlを作成する手順

  1. 既存のsample_failover.xmlテンプレートをコピーして次のディレクトリに貼り付けます。

    IdentityServer_install_dir/identity/oblix/config/ldap

  2. テキスト・エディタでこのコピーを開き、「サンプルFailover.xml」を参考にして、セカンダリ・サーバーのフェイルオーバー情報を追加します。

  3. 暗号化されたパスワード情報をコピーして、フェイルオーバー・ファイルに貼り付けます。

  4. コピーのファイル名をfailover.xmlに変更します。

  5. 適用可能なアイデンティティ・サーバーごとに必要な作業を繰り返します。

サンプルFailover.xml

?xml version="1.0" encoding="ISO-8859-1"?>
<CompoundList xmlns="http://www.oblix.com" ListName="failover.xml">
<!-- # すべてのアクティブldapサーバーに許可された最大接続数 -- これは最大アクティブ・サーバー数と同じです。>
<SimpleList>
<NameValPair ParamName="maxConnections" Value="1"></NameValPair>
</SimpleList>
<!-- # セカンダリldapサーバーに切替えるか、再起動したプライマリldapサーバーに再接続するまでの秒数 -->
<SimpleList>
<NameValPair ParamName="sleepFor" Value="60"></NameValPair>
</SimpleList>
<!-- # ldapサーバーへの接続が期限切れになるまでの時間 -->
<SimpleList>
<NameValPair ParamName="maxSessionTime" Value="0"></NameValPair>
</SimpleList>
<!-- # セカンダリ・サーバーへのフェイルオーバーが発生するアクティブなプライマリldapサーバーの最小数 -->
<SimpleList>
NameValPair ParamName="failoverThreshold" Value="1"></NameValPair>
</SimpleList>
<!-- # すべてのセカンダリldapサーバーのリストをここに指定します -->
<ValList xmlns="http://www.oblix.com" ListName="secondary_server_list">
<ValListMember Value="sec_ldap_server"></ValListMember>
</ValList>
<!-- # 各セカンダリldapサーバーの詳細をここに指定します -->
<ValNameList xmlns="http://www.oblix.com" ListName="sec_ldap_server">
<NameValPair ParamName="ldapSecurityMode" Value="Open"></NameValPair>
<NameValPair ParamName="ldapServerName" Value="instructor.oblix.com"></NameValPair>
<NameValPair ParamName="ldapServerPort" Value="9002"></NameValPair>
<NameValPair ParamName="ldapRootDN" Value="cn=Directory Manager"></NameValPair>
<NameValPair ParamName="ldapRootPasswd" Value="000A0259585F5C564C"></NameValPair>
<NameValPair ParamName="ldapSizeLimit" Value="0"></NameValPair>
<NameValPair ParamName="ldapTimeLimit" Value="0"></NameValPair>
</ValNameList>
</CompoundList>

構成データおよびポリシー・データに対するアクセス・サーバー・ディレクトリのフェイルオーバーの構成

次の手順は、アクセス・サーバーから、構成データやポリシー・データを含む1つ以上のディレクトリ・サーバーへのフェイルオーバーを構成する方法を示しています。


関連資料:

『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』の、Oracleデータおよびポリシー・データに対するアクセス・サーバー・ディレクトリのフェイルオーバーの構成に関する項、およびポリシー・マネージャのフェイルオーバーの構成に関する項。

構成データおよびポリシー・データに対するアクセス・サーバーのフェイルオーバーを構成する手順

  1. 「ディレクトリ・プロファイル」ページから、ツリーのoblixブランチを含むディレクトリ・プロファイルのフェイルオーバーを入力します。

    通常の手順については、「ユーザー・データ用ディレクトリのフェイルオーバーの構成」を参照してください。

  2. 適用可能な場合、ポリシー・データを含むディレクトリ・サーバーに対して前述の手順を繰り返します。

    アクセス・サーバーの場合、大部分の構成データは依然として構成ファイルによって管理されます。ただし、マルチ言語データおよび参照整合性データは「ディレクトリ・プロファイル」ページから管理されます。

  3. 次の説明のとおり、configureAAAServerツールを使用してフェイルオーバー情報を追加します。

configureAAAServerツールを使用してフェイルオーバー・ディレクトリ・サーバーを追加する手順

  1. コマンドラインから、configureAAAserverツールが格納されているフォルダに移動します。

    たとえば、デフォルトの場所は次のとおりです。

    AccessServer_install_dir\access\oblix\tools\configureAAAServer

    このAccessServer_install_dirは、アクセス・サーバーが存在するディレクトリです。

  2. 次の引数を指定して、configureAAAServerを実行します。

    configureAAAServer reconfig AccessServer_install_dir

    次に例を示します。

    configureAAAServer reconfig "c:\Program Files\COREid1014\access"

  3. ディレクトリ・サーバーに接続するアクセス・サーバー用のアクセス・サーバー・セキュリティ・モードに対応する番号を入力します。

    • 1）オープン

    • 2）簡易

    • 3）証明書

    ここで、構成またはポリシーのフェイルオーバー情報を指定するかどうかをたずねるメッセージが表示されます。

  4. 「はい」（Y）を選択します。

  5. データを次のどちらに格納するかを指定します。

    • 1）Oblixツリー

    • 2）ポリシー・ツリー

  6. フェイルオーバー・サーバーを追加するには、次に示すプロンプトで「1」を入力します。

    • 1）フェイルオーバー・サーバーを追加します

    • 2）フェイルオーバー・サーバーを変更します

    • 3）フェイルオーバー・サーバーを削除します

    • 4）共通パラメータを変更します

    • 5）終了します

  7. 次の情報を入力します。

    • ディレクトリ・サーバー名

    • ディレクトリ・サーバーのポート

      Active Directory Forest環境のLDAPの場合、オープン・モードにポート3268を使用し、SSLモードにポート3269を使用します。これら2つのポートは、グローバル・カタログのポートです。

    • ディレクトリ・サーバーのログインDN

    • ディレクトリ・サーバーのパスワード

    • ディレクトリ・サーバーのセキュリティ・モード

      • 1）オープン

      • 2）SSL

    • 優先度（優先度には「2」を入力します。）

      • 1）プライマリ

      • 2）セカンダリ

  8. 終了するには「5」を入力します。

    変更をコミットするかどうかを確認するメッセージが表示されます。

  9. 変更をコミットするには「Y」を選択します。

configureAAAServerにより、AccessServer_install_dir/access/oblix/config/ldapに次のXMLファイルが自動的に作成されます。

  • AppDBfailover.xml

  • ConfigDBfailover.xml

  • WebResrcDBfailoverxml

ポリシー・マネージャのフェイルオーバーを構成する手順

  1. アクセス・サーバー構成ディレクトリからポリシー・マネージャ・インストール・ディレクトリへ、WebResrcDBfailover.xmlファイルをコピーします。

  2. アクセス・サーバー構成ディレクトリからポリシー・マネージャ・インストール・ディレクトリへ、AppDBfailover.xmlファイルをコピーします。

  3. アクセス・サーバー構成ディレクトリからポリシー・マネージャ・インストール・ディレクトリへ、ConfigDBfailover.xmlファイルをコピーします。

ディレクトリ・サーバーの可用性に基づくフェイルオーバーの構成

ハートビート・メカニズムは、すべてのプライマリ・ディレクトリ・サーバー接続をポーリングし、ディレクトリ・サービスの可用性を検証します。ディレクトリ・サービスが使用できない場合、ハートビート・メカニズムによって即座にセカンダリ・ディレクトリ・サーバー（構成されている場合）へのフェイルオーバーが開始されます。優先される接続が回復すると、フェイルバック・メカニズムにより、ただちにセカンダリ・ディレクトリ・サーバーからプライマリ・サーバーへの切替えが行われます。

globalparams.xmlのheartbeat_ldap_connection_timeout_in_millisパラメータによって、ディレクトリ・サーバーとの接続の確立の時間制限が指定されます。時間制限に到達すると、アイデンティティ・サーバーおよびアクセス・サーバーは、別のディレクトリ・サーバーとの接続の確立を開始します。このパラメータによって、アイデンティティ・サーバーおよびアクセス・サーバーは、ディレクトリ・サーバーの停止を早期検出し、ディレクトリ・サービス・リクエストとTCPタイムアウトを伴わずにフェイルオーバーを実行できます。この機能は有効に設定することをお薦めします。

各ディレクトリ・プロファイルに「スリープ時間」（秒）パラメータを設定して、ポーリング間隔を構成します。ホストに到達できない場合、このホストへのこれ以降の接続は、指定されたスリープ時間の間ブロックされます。


注意:

ネットワークが遅い状態でheartbeat_ldap_ connection_ timeout_in_millisが低い値（たとえば10ミリ秒）に設定されている場合、ディレクトリが稼働中であるにもかかわらず、ディレクトリに到達できないという誤った情報がハートビート・メカニズムによって表示される可能性があります。

アイデンティティ・システムのポーリング間隔を設定する手順

  1. アイデンティティ・システム・コンソールから、「システム構成」→「ディレクトリ・プロファイル」を選択します。

    「プロファイルの構成」ページが表示されます。

  2. このページの「LDAPディレクトリ・サーバー・プロファイルの構成」セクションで、変更するプロファイルのリンクをクリックします。

    「ディレクトリ・サーバー・プロファイルの変更」ページが表示されます。このディレクトリ・サーバー・プロファイルは、このページの「使用」リストから選択したOracle Access Managerサーバーで使用されます。

  3. 「スリープ時間（秒）」フィールドに間隔を入力します。

アクセス・システムのポーリング間隔を設定する手順

  1. アクセス・システム・コンソールから、「システム構成」を選択し、「サーバー設定」をクリックします。

  2. このページの「LDAPディレクトリ・サーバー・プロファイルの構成」セクションで、変更するプロファイルのリンクをクリックします。

    「ディレクトリ・サーバー・プロファイルの変更」ページが表示されます。このディレクトリ・サーバー・プロファイルは、このページの「使用」リストから選択したOracle Access Managerサーバーで使用されます。

  3. 「スリープ時間（秒）」フィールドに間隔を入力します。

ディレクトリとの接続の確立の時間制限を設定する手順

  1. 次のファイルを開きます。

    component_install_dir/identity/apps/common/bin/globalparams.xml

    このcomponent_install_dirは、アクセス・サーバーまたはアイデンティティ・サーバーをインストールした場所です。

  2. heartbeat_ldap_connection_timeout_in_millisパラメータの値を編集します。

    アイデンティティ・サーバーまたはアクセス・サーバーがディレクトリ・サーバーとの接続が確立されるまで待機する時間を指定します。デフォルト値は4000（4秒）です。値が-1の場合、接続の確立が実行される前にプラットフォームの接続タイムアウトの制限に達します。

ハートビート・メカニズムをオンまたはオフに設定する手順

  1. ファイルcomponent_install_dir/identity/apps/common/bin/globalparams.xmlを開きます。

    このcomponent_install_dirは、アクセス・サーバーまたはアイデンティティ・サーバーをインストールした場所です。

  2. heartbeat_enabledパラメータの値を編集します。

    このパラメータは、ハートビート・メカニズムをアクティブまたは非アクティブにします。デフォルトでは、true（オン）に設定されています。値がfalseの場合、ハートビート・メカニズムは非アクティブになります。

ディレクトリ・サーバーのレスポンス時間に基づくフェイルオーバーの構成

アイデンティティ・サーバー、アクセス・サーバーおよびポリシー・マネージャを構成して、プライマリ・ディレクトリ・サーバーからのレスポンスを、構成した時間（ミリ秒単位）だけ待機させることができます。構成した時間制限内にレスポンスがなかった場合、セカンダリ・ディレクトリ・サーバーが構成されていれば、コンポーネントがそのサーバーへのフェイルオーバーを実行します。

globalparams.xmlのLDAPOperationTimeout設定は、Oracle Access Managerコンポーネントがディレクトリ・サーバーからのレスポンスを待機する時間を制御します。

ユーザー・リクエストを処理する際、Oracle Access Managerコンポーネントは複数のLDAP問合せを発行する可能性があります。LDAPOperationTimeoutパラメータは、同じリクエストの処理に関係するその他の問合せとは別に、問合せごとに適用されます。たとえば、LDAPOperationTimeoutパラメータは、ディレクトリ・サーバーによる検索結果の単一エントリの処理に対して時間制限を設定します。検索結果セットの1つのエントリをこの時間制限内に取得できなかった場合、このコンポーネントによってセカンダリ・サーバーへのフェイルオーバーが実行されます。すべての検索結果エントリの待機時間を構成するには、Oracle Access Managerの管理コンソールを使用してディレクトリ・プロファイルの「時間制限」パラメータを構成します。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

LDAPOperationTimeoutパラメータのデフォルト値である-1を使用した場合、Oracle Access Managerコンポーネントはディレクトリ・サーバーからのレスポンスを無制限に待機します。

ここでは、次の内容について説明します。


警告:

LDAPOperationTimeoutのデフォルト値-1をそのまま使用した場合、ディレクトリ・サーバーが停止するとOracle Access Managerも停止する可能性があります。ディレクトリ・サーバーが停止しても問題がない場合は、デフォルト値-1を使用できます。

また、LDAPOperationTimeoutパラメータに設定した値が低すぎると、プライマリ・ディレクトリ・サーバーが機能している場合でもフェイルオーバーが実行される可能性があります。この値がセカンダリ・サーバーに対しても低すぎる場合は、無限ループが発生する可能性があります。詳細は次の各項を参照してください。

ディレクトリ・サーバーのレスポンス時間に基づくフェイルオーバーの構成のガイドライン

LDAPOperationTimeoutの値は、それぞれの環境に基づいて決定します。たとえば、ディレクトリ・サーバーのデータ量、ネットワーク待機時間、ディレクトリ・サーバーに対して定義される索引数、Oracle Access Managerコンポーネントとディレクトリ・サーバーの通信にSSLが使用されるかどうかなどです。

Oracle Access Managerコンポーネントがセカンダリ・ディレクトリ・サーバーへのフェイルオーバーを実行するまでの待機時間の見積り方法のガイドラインを次に示します。

  • たとえば、現在構成中の環境と類似した環境で、時間のかかるリクエストをOracle Access Managerコンポーネントに送信して、値を調べるためのテストを実行します。

  • 次のログ・ファイルで、LDAPMaxNoOfRetriesの値を超えました。globalparams.xmlでLDAPOperationTimeoutの構成値を確認してください。というメッセージが含まれているかチェックします。

    Component_install_dir\oblix\logs\oblog.log

    このメッセージは、警告レベルで構成されているログに表示されます。このメッセージは、機能しているディレクトリ・サーバーが結果を返す前に、リクエストがタイムアウトになったことを示しています。このメッセージが確認された場合は、LDAPOperationTimeoutパラメータの値を増やす必要があります。値が低すぎると、機能しているディレクトリ・サーバーが結果を返すのに十分な時間を与えられない無限ループが発生する可能性があります。

LDAPOperationTimeoutパラメータに低すぎる値が設定された場合の予防策として、LDAPMaxNoOfRetriesパラメータは、アイデンティティ・サーバー、アクセス・サーバーまたはポリシー・マネージャによる構成済ディレクトリ・サーバーでのLDAP操作またはLDAP問合せのリトライ回数を制限します。LDAPOperationTimeoutパラメータの場合と同様に、このパラメータはリクエストの処理に関係するその他の問合せとは別に、問合せごとに適用されます。Oracle Access Managerコンポーネントと通信するディレクトリ・サーバーの数より大きい値に設定してください。これにより、構成済ディレクトリ・サーバーごとに少なくとも1回は問合せが試行されるようになります。

LDAPOperationTimeoutパラメータおよびLDAPMaxNoOfRetriesパラメータの構成

これらのパラメータの構成の手順を次に示します。

フェイルオーバーまでのレスポンス待機時間の構成の手順

  1. 次のファイルを開きます。

    component_install_dir/apps/common/bin/globalparams.xml

  2. LDAPOperationTimeoutパラメータを次の値のいずれかに設定します。

    • ミリ秒単位の時間を示す正数。

    • -1。この値を指定すると、リクエストに費やす時間がディレクトリ・サーバーによって指定されます。

  3. LDAPMaxNoOfRetriesパラメータの値を設定します。

    デフォルトの0を使用すると、コンポーネントと通信するように構成されているプライマリ・ディレクトリ・サーバーおよびセカンダリ・ディレクトリ・サーバーの数とリトライの回数が同じになります。値-1は、リトライ回数が無限であることを示します。整数は、許可されるリトライ数を示します。

  4. コンポーネントを再起動します。

LDAPOperationTimeout値のテスト

Oracle Access Managerの一部の機能では、複数のLDAP操作が必要になります。リクエストに関係する一部のLDAP操作では、指定されたLDAPOperationTimeout値が適正で、操作が正常に実行される可能性があります。同じリクエストのその他の操作では、このLDAPOperationTimeout値が低すぎるためにディレクトリ・サーバーが使用不可とみなされ、リクエスト内の次のLDAP操作が失敗する可能性があります。その結果、一貫性のない状態が発生します。

LDAPOperationTimeoutパラメータに設定した値が低すぎると、プライマリ・ディレクトリ・サーバーが機能している場合でもフェイルオーバーが実行される可能性があります。この値がセカンダリ・サーバーに対しても低すぎる場合は、無限ループが発生する可能性があります。

より高い値をLDAPOperationTimeoutパラメータに設定しても、Oracle Access Managerのパフォーマンスは低下しません。ディレクトリ・サーバーによって結果が返されるとすぐに、Oracle Access Managerは処理を続行します。

テストでLDAPOperationTimeoutパラメータに適した値を調べるには、Oracle Access Managerで特に時間のかかる操作をテストできます。


注意:

次に示す手順の複数の箇所に、DN接頭辞セマンティク型を使用して構成された属性の処理の調査が含まれています。DN接頭辞セマンティク型は、Person構造型オブジェクト・クラスおよびGroup構造型オブジェクト・クラス、そして組織マネージャの構造型オブジェクト・クラスに必要です。DN接頭辞は、オブジェクトの相対識別名（RDN）を指定します。RDNは識別名（DN）の最も左の部分です。DN接頭辞は、ワークフローを通してオブジェクトを作成する場合に使用されます。

LDAPOperationTimeoutの最適な値を調べるためのテストの手順

  1. LDAPOperationTimeoutの値を構成します。

    詳細は、「LDAPOperationTimeoutパラメータおよびLDAPMaxNoOfRetriesパラメータの構成」を参照してください。

  2. 次のように、ユーザー・マネージャでDN接頭辞セマンティク型を使用する属性を探します。

    アイデンティティ・システム・コンソールから「ユーザー・マネージャ構成」をクリックし、「タブ」をクリックして「ユーザー・マネージャ」タブへのリンクをクリックします。次に、「属性の変更」をクリックして、DN接頭辞セマンティク型を使用して構成された属性を特定します。

  3. ユーザー・マネージャで「マイプロファイル」をクリックし、「変更」をクリックしてDN接頭辞セマンティク型を使用して構成された属性を変更します。

  4. ログ・ファイルcomponent_install_dir\oblix\logs\oblog.logに移動して、LDAPMaxNoOfRetriesの値を超えました。globalparams.xmlでLDAPOperationTimeoutの構成値を確認してください。というメッセージがファイルに表示されていないことを確認します。

    このメッセージは、警告レベルで構成されているログに表示されます。このメッセージが表示された場合は、LDAPOperationTimeoutの値を増やしてテストを再実行します。

  5. 次のように、グループ・マネージャでDN接頭辞セマンティク型を使用する属性を探します。

    アイデンティティ・システム・コンソールから「グループ・マネージャ構成」をクリックし、「タブ」をクリックして「グループ・マネージャ」タブへのリンクをクリックします。次に、「属性の変更」をクリックして、DN接頭辞セマンティク型を使用して構成された属性を特定します。

  6. グループ・マネージャで「マイグループ」をクリックし、グループを選択してから「変更」をクリックしてDN接頭辞セマンティク型を持つ属性を変更します。

  7. 手順4で示したメッセージを探し、このメッセージが表示されている場合はLDAPOperationTimeoutの値を増やしてテストを再実行します。

  8. 次のように、組織マネージャでDN接頭辞セマンティク型を使用する属性を探します。

    アイデンティティ・システム・コンソールから「Org Manager構成」をクリックし、「タブ」をクリックして「組織マネージャ」タブへのリンクをクリックします。次に、「属性の変更」をクリックして、DN接頭辞セマンティク型を使用して構成された属性を変更します。

  9. 手順4で示したメッセージを探し、このメッセージが表示されている場合はLDAPOperationTimeoutの値を増やしてテストを再実行します。

  10. 次のように、LDAPOperationTimeout値が静的グループのメンバーであるユーザーの非アクティブ化や削除を行うのに十分な値かどうかを判断します。

    ユーザー・マネージャでユーザー・プロファイルを表示し、ユーザーを削除して、手順4の説明に従ってoblog.logファイルをチェックします。

  11. 独自の環境で時間がかかっているその他の操作を特定し、それらの操作を実行します。

    操作を実行したら、手順4の説明に従ってoblog.logファイルをチェックします。

  戻る
戻る		 次へ
次へ
  目次
目次		 索引
索引