Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
![]() 前 |
![]() 次 |
Directory Proxy Serverでは、データ・ビューの定義を使用した配布が可能です。データ・ビューは、そのデータ・ビューのエントリのベースDNを決定するビュー・ベースによって定義されます。Directory Proxy Serverが提供する配布アルゴリズムに基づいて、エントリを様々なデータ・ビュー間で分割する方法を指定できます。
この章の内容は、次のとおりです。
LDAPデータ・ビューにより、クライアントのリクエストに対してLDAPサーバーのデータが公開され、そのレクエストに対応するソース・プールが指定されます。LDAPデータ・ビューを定義することで、次のタスクを実行できます。
データベース全体を1つのビューで公開する
データベース内の異なるサブツリーに対して異なるビューを提供する
異なるデータベースの統合ビューを提供する
その他のタイプのデータ・ビューがありますが、配布できるのは、LDAPデータ・ビューのみです。他のタイプのデータ・ビューの詳細は、第18章「Directory Proxy Serverの仮想化」を参照してください。
単純なLDAPデータ・ビューは、主にデータ・ビューのベースDNによって定義されます。単純なデータ・ビューでは、サブツリーのすべてのエントリがデータ・ビューで囲まれます。データ・ビューは、上位データ・ビューおよび下位データ・ビューの階層構造で存在します。下位データ・ビューは、ベースDNが上位データ・ビューのベースDNに対して劣っているデータ・ビューです。下位データ・ビューのエントリは、上位データ・ビューから除外されます。
データ・ビューの機能の詳細は、次の項を参照してください。
下位データ・ビューが作成されると、Directory Proxy Serverは上位データ・ビューから下位データ・ビューを自動的に除外します。リクエストが下位データ・ビューをターゲットにしている場合、リクエストは上位データ・ビューではなく、下位データ・ビューに送信されます。
デフォルトでは、Directory Proxy Serverは、上位データ・ビューのexcluded-subtrees
パラメータを自動的に構成して、下位データ・ビューを除外します。自動構成を無効化する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のexcluded-subtreeおよびalternate-search-base-dnプロパティを手動で構成する方法に関する説明を参照してください。
サブツリーcn=config
、cn=monitor
およびcn=proxy manager
は、デフォルトですべてのデータ・ビューから除外されます。
代替検索ベースが下位データ・ビューで指定された場合、上位データ・ビューをターゲットとする検索操作も下位データ・ビューで実行されます。
デフォルトでは、Directory Proxy Serverは、下位データ・ビューのalternateSearchBase
パラメータを自動的に構成します。自動構成を無効化する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のexcluded-subtreeおよびalternate-search-base-dnプロパティを手動で構成する方法に関する説明を参照してください。
ディレクトリの各エントリは、DNおよび、属性と属性値のセットにより識別されます。クライアント側で定義されたDNおよび属性は、多くの場合、サーバー側で定義されたDNおよび属性にはマップされません。
データ・ビューは、DNおよび属性の名前をサーバー側と一致する値に変更するよう定義できます。クライアントが要求を行うと、DNと属性の名前がサーバー側と一致するように変更されます。結果がクライアントに返されると、DNと属性はクライアント側と一致するよう元に戻されます。
次の図は、Directory Proxy Serverによって属性名がどのように変更されるかを示しています。
図17-1で、電子メール・クライアントでは、姓を属性surname
によって指定する必要がありますが、LDAPサーバーでは、姓は属性sn
によって定義されます。属性名を変更すると属性名のみが影響を受け、属性の値は変更されません。ただし、属性名を変更すると、その名前を持つすべてのエントリの名前が変更されます。
属性名の変更を構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の属性名の変更を構成する方法に関する説明を参照してください。
次の図は、Directory Proxy ServerによってDN名がどのように変更されるかを示しています。
図17-2で、クライアントにはdc=example, dc=com
データベースが含まれています。LDAPサーバーには、dc=example, dc=org
データベースが含まれています。Directory Proxy Serverは、DNの名前を変更します。
DNが元々のDN名の変更によって変更されているDITの一部である場合、それらのDNを含む属性名も変更する必要があります。図17-2で、group
属性には、グループ・メンバーのDNのリストが含まれています。dc=example, dc=com
の名前をdc=example, dc=org
に変更すると、グループ属性のDNの名前も変更する必要があります。
DN名の変更を構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDN名の変更を構成する方法に関する説明を参照してください。
配布アルゴリズムは、同じベースDNを持つデータ・ビュー間に操作を配布します。配布アルゴリズムのタイプは、distribution-algorithm
パラメータによって定義されます。
操作の配布方法を決定するために、配布アルゴリズムは、データ・ビューのベースDNの直下の属性の値を考慮します。たとえば、ou=people,dc=example,dc=com
のベースDNを持つデータ・ビューを考慮します。検索操作にベースDN uid=23,ou=people,dc=example,dc=com
が含まれている場合、uid
がデータ・ビューのベースDNの直下にあるため、配布アルゴリズムはuid
をルーティング属性とみなします。次に、アルゴリズムは、値23
と一致するよう試みて、操作のルーティング方法を決定します。
ただし、検索操作にベースDN uid=23,ou=managers,ou=people,dc=example,dc=com
が含まれている場合、ou
がデータ・ビューのベースDNの直下にあるため、配布アルゴリズムはou
をルーティング属性とみなします。ou
は、検索問合せで指定されているuid
と一致しないため、配布アルゴリズムは検索を正しく配布できません。この場合、配布を正しく動作させるには、データ・ビューのベースDNをou=managers,ou=people,dc=example,dc=com
にする必要があります。
そのため、データ・ビューのベースDNが配布アルゴリズムに対して適切かどうかを確認する必要があります。
次の配布アルゴリズムは、Directory Proxy Serverによって提供されます。
リクエストは、リクエストのパラメータと1つ以上のパターンの間の一致に基づいてデータ・ビューに配布されます。パターンは次のパラメータによって定義されます。
pattern-matching-base-dn-regular-expression
pattern-matching-base-object-search-filter
pattern-matching-dn-regular-expression
pattern-matching-one-level-search-filter
pattern-matching-subtree-search-filter
パターン一致アルゴリズムがサポートしている構文は、JavaのPatternクラス(http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html (http://download.oracle.com/javase/1.4.2/docs/api/java/util/regex/Pattern.html
)の説明を参照)で指定されます。この構文は、通常のregex
構文と同じではありません。
リクエストは、リクエストのRDNの数値に応じて、データ・ビューに配布されます。数値は、データ・ビューのベースDNの下の最初のRDNの値から取得されます。数値のバウンドは、次のパラメータで定義されます。
numeric-attrs
numeric-default-data-view
numeric-lower-bound
numeric-upper-bound
リクエストは、リクエストのRDNの辞書編集上の値に応じて、データ・ビューに配布されます。辞書編集上のバウンドは、データ・ビューのベースDNの下の最初のRDNの値から取得されます。辞書編集上のバウンドは、次のパラメータで定義されます。
lexicographic-attrs
lexicographic-lower-bound
lexicographic-upper-bound
リクエストは、レプリケーションのデータ・ビューのロールに応じて、データ・ビューに配布されます。このアルゴリズムは、書込み操作をデータソース・プールのすべてのデータソースに配布し、読取り操作を1つのデータソースに配布します。レプリケーション・ロールは、replication-role
パラメータによって定義されます。データ・ビューは、マスター・ロールまたはコンシューマ・ロールを持つことができます。
また、カスタム配布アルゴリズムをサポートするようにDirectory Proxy Serverを構成することもできます。カスタム配布アルゴリズムの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のカスタム配布アルゴリズムの構成方法に関する説明を参照してください。
配布アルゴリズムの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の階層および配布アルゴリズムを持つデータ・ビューに関する説明を参照してください。配布アルゴリズムで使用されるパラメータの詳細は、distribution-algorithmを参照してください。
Directory Proxy Serverで提供される配布アルゴリズムは、特定のリクエストのシナリオでは、一部制限があります。
次のリストは、リクエストで配布アルゴリズムが使用されない状況をまとめたものです。このリストの例は、ルーティング属性がuid
で、データ・ビューのビュー・ベースがdc=example,dc=com
であることを前提としています。
検索ベースがビュー・ベースで終わり、範囲がbase
である場合、リクエストは、常に最初のデータ・ビューに配布されます。次に例を示します。
$ ldapsearch -b "ou=people,dc=example,dc=com" -s base "uid=116352"
検索ベースがビュー・ベースで終わり、範囲が1つのレベルまたはサブツリーである場合、リクエストは、常に最初のデータ・ビューに配布されます。次に例を示します。
$ ldapsearch -b "ou=people,dc=example,dc=com" -s sub "uid=116352"
検索ベースがビュー・ベースで終わり、ルーティング属性で始まるが、検索フィルタにルーティング属性が含まれていない場合、リクエストはすべてのデータ・ビューに配布されます。次に例を示します。
$ ldapsearch -b "uid=116352",ou=people,dc=example,dc=com" -s base "objectclass=*"
この例では、RDN値がデータ・ビュー基準に一致する場合、リクエストは正しく配布されます。
検索ベースがビュー・ベースで終わり、ルーティング属性を含んでいるが、検索フィルタにルーティング属性が含まれていない場合、リクエストはすべてのデータ・ビューに配布されます。次に例を示します。
$ ldapsearch -b "cn=myAccount,uid=116352,ou=people,dc=example,dc=com" -s base "objectclass=*"
この例では、RDN値がデータ・ビュー基準に一致する場合、リクエストは正しく配布されます。
この項では、LDAPデータ・ビューのユースケースについて説明します。すべての例は、接続ハンドラのすべてのクライアント接続をDirectory Proxy Serverで処理できることを前提としています。
様々なデプロイメントでのデータ・ビューの例は、次の項を参照してください。
この項では、リクエストのターゲットDNに関係なく、すべてのリクエストをデータソース・プールにルーティングするデータ・ビューについて説明します。このデータ・ビューは、ルート・データ・ビューと呼ばれます。ルート・データ・ビューはDirectory Proxy Serverのインスタンスの作成時にデフォルトで作成されます。
この項の例には、同じサブツリーのセットを含む複数のデータソースが含まれています。データソースはデータと等価であり、ロード・バランシングのために1つのデータソース・プールにプールされます。データ・ビューは、" "で表されるrootDSEのベースDNを使用して構成されます。図17-3は、デプロイメントの例を示しています。
図17-3 ターゲットDNに関係なく、すべてのリクエストをデータソース・プールにルーティングするデプロイメントの例
データ・ビューのベースDNはrootDSEであるため、データ・ビューは、すべての使用可能なリクエストのベースDNを囲みます。すべてのリクエストは、ターゲットDNまたはデータソースにそのリクエストのエントリが含まれているかどうかに関係なく、データソース・プールに転送されます。
Directory Proxy Serverがデータソースに存在しないターゲットを持つリクエストを受け取った場合、リクエストはデータソース・プールに転送されます。リクエストに応答するデータソースはエラーを返します。
図17-3のデータ・ビューの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリクエストのターゲットDNに関係なくすべてのリクエストをルーティングするデータ・ビューに関する説明を参照してください。
この項では、サブツリー・リストをターゲットとするリクエストをデータと等価なデータソース・セットにルーティングするデータ・ビューについて説明します。
この項の例には、それぞれが同じサブツリーのセットを含む複数のデータソースが含まれています。データソースはデータと等価であり、ロード・バランシングのために1つのデータソース・プールにプールされます。データ・ビューは、サブツリーごとに、そのサブツリーをクライアント・リクエストに公開するように構成されます。図17-3は、デプロイメントの例を示しています。
図17-4 データと等価な複数のデータソースにサブツリー・リストが格納されている場合にリクエストをルーティングするデプロイメント例
ターゲットDNがデータ・ビューのベースDNに対して下位である場合にのみ、リクエストはデータ・ビューに公開されます。リクエストがデータ・ビューに公開されると、リクエストは、データ・ビューによって指定されているデータソース・プールに転送されます。
リクエストのターゲットDNがいずれのデータ・ビューのベースDNに対しても下位でない場合、Directory Proxy Serverはエラーを返します。
図17-4で、dc=example1,dc=com
またはdc=example2,dc=com
をターゲットとするリクエストは、データソース・プールに転送されます。Directory Proxy Serverは、dc=example1,dc=com
もdc=example2,dc=com
もターゲットとしないリクエストにエラーを返します。
この項のデータ・ビューの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のデータと等価な複数のデータソースにサブツリー・リストが格納されている場合にリクエストをルーティングするデータ・ビューに関する説明を参照してください。
この項では、Directory Proxy Serverが、複数のデータソースのデータの異なるサブツリーに単一のアクセス・ポイントを提供する方法について説明します。この項の例では、各サブツリーをクライアント・リクエストに公開するための、サブツリーのデータ・ビューが含まれます。データソース・プールは、データと等価なデータソースのセットごとに構成されます。図17-5は、デプロイメントの例を示しています。
図17-5 異なるサブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデプロイメント例
Directory Proxy Serverは、リクエストがターゲットとしているDNがデータ・ビューのベースDNに対して下位である場合、そのリクエストをデータ・ビューに公開します。リクエストがデータ・ビューに公開されると、リクエストは、データ・ビューによって指定されているデータソース・プールに転送されます。
リクエストに、データ・ビューのベースDNに対して下位でないターゲットDNがある場合、Directory Proxy Serverはエラーを返します。
図17-5で、dc=example1,dc=com
をターゲットとするクライアント・リクエストは、データソース・プール1に転送され、データソース1またはデータソース1'によって処理されます。dc=example2,dc=com
をターゲットとするクライアント・リクエストは、データソース・プール2に転送され、データソース2またはデータソース2'によって処理されます。Directory Proxy Serverは、dc=example1,dc=com
もdc=example2,dc=com
もターゲットとしないクライアント・リクエストにエラーを返します。
データ・ビューを構成して単一のアクセス・ポイントを複数のデータソースに格納されている異なるサブツリーに提供する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の異なるサブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデータ・ビューに関する説明を参照してください。
この項では、Directory Proxy Serverが、複数のデータソースに格納されているサブツリーの様々な部分に単一のアクセス・ポイントを提供する方法について説明します。サブツリーの様々な部分のリクエストをルーティングするために、Directory Proxy Serverは配布アルゴリズムを使用します。この項の例では、Directory Proxy Serverは、数値の配布アルゴリズムを使用します。配布アルゴリズムの詳細は、「異なるデータ・ビューへのサブツリーのエントリの配布」を参照してください。
この項の例には、同じベースDNを持つ2つのデータ・ビューが含まれています。数値配布アルゴリズムを使用して、エントリを異なるデータ・ビューに分割します。データソース・プールは、データと等価なデータソースのセットごとに構成されます。図17-6は、デプロイメントの例を示しています。
図17-6 サブツリーの様々な部分が異なるデータソースに格納されている場合にリクエストをルーティングするデプロイメントの例
Directory Proxy Serverは、次の条件を満たすデータ・ビューにリクエストを公開します。
リクエストがターゲットとするDNがデータ・ビューのベースDNに対して下位である
リクエストのパラメータが、データ・ビューの配布アルゴリズムで指定されているパターンに一致する
リクエストがデータ・ビューに公開されると、リクエストは、データ・ビューによって指定されているデータソース・プールに転送されます。
リクエストがいずれのデータ・ビューの条件にも一致しない場合、Directory Proxy Serverは、エラーを返します。
データ・ビューを構成して単一のアクセス・ポイントを複数のデータソースのサブツリーの様々な部分に提供する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のサブツリーの様々な部分が異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデータ・ビューに関する説明を参照してください。
この項では、上位サブツリーと下位サブツリーが異なるデータソースに格納される場合に、Directory Proxy Serverが単一のアクセス・ポイントを提供する方法について説明します。
Directory Proxy Serverでは、デフォルトでexcluded-subtrees
とalternate-search-base-dn
プロパティが自動的に設定されます。ただし、excluded-subtrees
とalternate-search-base-dn
プロパティの自動管理は無効化できます。excluded-subtrees
およびalternate-search-base-dn
プロパティを手動で構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のexcluded-subtreeおよびalternate-search-base-dnプロパティを手動で構成する方法に関する説明を参照してください。
図17-7の例には、3つのデータ・ビューが含まれています。dataview-1
のベースDNは、dataview-2
およびdataview-3
のベースDNよりも上位です。
dataview-1
のexcluded-subtrees
プロパティは、dataview-1
からdataview-2
およびdataview-3
を除外します。dataview-2
およびdataview-3
のalternate-search-base-dn
プロパティには、dataview-1
をターゲットとする検索操作にdataview-2
およびdataview-3
が含まれます。図17-7は、デプロイメントの例を示しています。
図17-7 上位サブツリーと下位サブツリーが異なるデータソースに格納されている場合にリクエストをルーティングするデプロイメント例
Directory Proxy Serverは、次の条件を満たすデータ・ビューにリクエストを公開します。
リクエストがターゲットとするDNがデータ・ビューのベースDNに対して下位である
リクエストがターゲットとするDNは、excluded-subtrees
パラメータによってデータ・ビューから除外されない
リクエストがデータ・ビューに公開されると、リクエストは、データ・ビューによって指定されているデータソース・プールに転送されます。
リクエストがいずれのデータ・ビューの条件にも一致しない場合、リクエストはデータ・ビューに公開できず、Directory Proxy Serverはエラーを返します。
図17-7で、dc=example,dc=com
をターゲットとするが、ou=computer, dc=example, dc=com
またはou=people, dc=example, dc=com
をターゲットとしないクライアント・リクエストは、データソース・プール1に転送されます。このようなリクエストは、データソース1またはデータソース1'によって処理されます。ou=computer, dc=example, dc=com
またはou=people, dc=example, dc=com
をターゲットとするクライアント・リクエストは、それぞれデータソース・プール2およびデータソース3に転送されます。Directory Proxy Serverは、dc=example,dc=com
をターゲットとしないクライアント・リクエストにエラーを返します。
サブツリー検索が上位データ・ビューをターゲットとすると、検索範囲は下位データ・ビューになります。この例で、3つのすべてのデータ・ビューが、dc=example,dc=com
をターゲットとする検索操作の候補となります。一部の特定のケースでは、検索範囲がこのように拡大しないほうが便利な場合があります。この検索範囲の拡大を防ぐには、下位データ・ビューをその親データ・ビューから切断する必要があります。デフォルトでは、Directory Proxy Serverは、connect-to-parent
パラメータをtrueに設定して、自動的に下位データ・ビューをそれらの各親に接続します。データ・ビューをその親から切断する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の階層および配布アルゴリズムを持つデータ・ビューに関する説明を参照してください。
データ・ビューを構成して単一のアクセス・ポイントを複数のデータソースのサブツリーの様々な部分に提供する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の上位サブツリーおよび下位サブツリーが異なるデータソースに格納されている場合に単一のアクセス・ポイントを提供するデータ・ビューに関する説明を参照してください。
同じトポロジに様々なデータ・ビューを使用して、サブツリーの部分を公開したり非表示にしたりできます。図17-8は、図17-7で示されている階層を図17-6で示されている配布アルゴリズムを組み合せたデータ・ビューの例です。
図17-8の例には、4つのデータ・ビューが含まれています。データ・ビュー1のベースDNは、他のデータ・ビューのベースDNより優先されます。データ・ビュー3とデータ・ビュー4は、同じベースDNを持っているが、数値の配布アルゴリズムは、エントリを異なるデータ・ビューに分割します。図17-8は、デプロイメントの例を示しています。
dataview-1
のexcluded-subtrees
プロパティは、dataview-1
から他のデータ・ビューを除外します。dataview-2
、dataview-3
およびdataview-4
のalternate-search-base-dn
プロパティには、dataview-1
をターゲットとする検索操作にこれらのデータ・ビューが含まれます。
Directory Proxy Serverは、次の条件を満たすデータ・ビューにリクエストを公開します。
リクエストがターゲットとするDNがデータ・ビューのベースDNに対して下位である
リクエストがターゲットとするDNは、excluded-subtrees
パラメータによってデータ・ビューから除外されない
リクエストのパラメータが、配布アルゴリズムで指定されているパターンに一致する
リクエストがデータ・ビューに公開されると、リクエストは、データ・ビューによって指定されているデータソース・プールに転送されます。
リクエストがいずれのデータ・ビューの条件にも一致しない場合、Directory Proxy Serverは、エラーを返します。
複雑なデータ・ビューの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の階層および配布アルゴリズムを持つデータ・ビューに関する説明を参照してください。