4.4. 仮想ディレクトリー情報ツリービュー
Directory Server は、仮想ディレクトリー情報ツリービュー あるいは 仮想 DIT ビュー と呼ばれる、ディレクトリー情報の階層ナビゲーションと組織の概念をサポートします。
注記
ビューが返すエントリーが同じバックエンドに存在しなければならないないという点で、仮想ビューは、複数のバックエンドと完全に互換性があるわけではありません。検索は 1 つのバックエンドに限定されます。
4.4.1. 仮想 DIT ビューについて
ディレクトリーの名前空間を設定するには 2 つの方法があります。
- 階層構造のディレクトリー情報ツリー。
- フラットなディレクトリー情報ツリー。
階層構造の DIT は、ディレクトリーのナビゲーションに便利ですが、変更するのは面倒で時間がかかります。階層構造の DIT への大規模な組織変更は、通常、かなりのサービスの中断を伴うため、費用と時間のかかる作業になります。通常、営業時間外やトラフィックの少ない時間帯に変更を行うことでしか、このデメリットを最小限に抑えることはできません。
フラットな DIT は、ほとんど変更を必要としませんが、ディレクトリーサービス内でエントリーをナビゲーションしたり、管理するための便利な方法を提供しません。また、フラットな DIT は、自然な階層構造のグルーピングを持たないことにより管理が複雑になるため、多くの管理上の課題があります。
図4.14 フラットな DIT と組織ベースの DIT の例
階層構造の DIT を使用する場合、デプロイメントは階層のサブジェクトドメインを決定する必要があります。選択肢は 1 つしかなく、自然な傾向は、組織の階層を選択することです。
組織のこのビューは多くの場合に適しますが、1 つのビューしかないことが、ディレクトリーのナビゲーションや管理に対する大きな制約となります。例えば、経理部門の人に属するエントリーを探すには、組織の階層が適しています。しかし、この表示では、Mountain View, California のような地理的な場所にいる人に属するエントリーを探すのにはあまり役に立ちません。2 番目のクエリーも 1 番目のクエリーと同様に有効ですが、エントリーに含まれる属性の知識と追加の検索ツールが必要になります。このような場合、DIT を使用してナビゲーションを行うことは適切ではありません。
同様に、DIT が管理機能の要件に合致していれば、ディレクトリーの管理は非常に容易になります。また、DIT の設定は、レプリケーションやマイグレーションへの考慮など、他の要因にも影響されます。これらにより DIT がこれらのアプリケーションの機能ユーティリティーを持ちますが、他のケースでは実用性がほとんどないということもあります。
明らかに、階層はナビゲーションと管理のための便利なメカニズムです。しかし、既存の DIT に変更を加える際の負担を回避するために、デプロイメントではフラットな DIT のメリットにより階層をすべて廃止する選択も可能です。
もし、ディレクトリーが、対象となるエントリーを移動させることなくエントリーにマッピングされる階層を任意の数作成する方法を提供する場合は、デプロイメントにとって有用になるでしょう。Directory Server の 仮想 DIT ビュー 機能は、ディレクトリーのデプロイメントに使用する DIT の種類を決定する際の迷いを解消します。
仮想 DIT ビュー では、エントリーが特定の場所に物理的に存在していなくても、それらのエントリーを階層的にナビゲートすることができます。仮想 DIT ビューは、エントリーの情報を使用してビュー階層に置きます。クライアントアプリケーションでは、仮想 DIT ビューは通常のコンテナー階層として表示されます。ある意味、仮想 DIT ビューは、エントリーがフラットな名前空間にあるか、独自の別の階層にあるかに関わらず、DIT 階層をそれらのエントリーのセットに重ね合わせます。
通常の DIT 階層と同じように、仮想 DIT ビュー階層を作成します。同じエントリー（組織単位エントリーなど）を作成しますが、追加のオブジェクトクラス(nsview)およびビューを記述するフィルター属性(
nsviewfilter)を作成します。追加属性の追加後、ビューフィルターにマッチするエントリーが即座にビューを反映させます。対象となるエントリーは、ビューの中に存在している ように見える だけで、実際の場所は変わりません。仮想 DIT ビューは、サブツリーまたは 1 レベルの検索が、想定された結果で返されることで、通常の DIT と同様に動作します。
エントリーの追加および修正については、『Red Hat Directory Server Administration Guide』の Creating Directory Entries を参照してください。
図4.15 ビューを使用した DIT の組み合わせ
図4.15「ビューを使用した DIT の組み合わせ」の DIT は、図4.14「フラットな DIT と組織ベースの DIT の例」で示した 2 つの DIT がビューを使用して組み合わされたときの様子を示しています。ビューでは本来、エントリーがビュー階層の複数の場所に表示されることを許可するため、この機能を使用して ou=Sales エントリーを拡張し、営業エントリーを場所別または製品別に表示できるようになりました。
仮想 DIT ビュー階層のセットが与えられた場合、ディレクトリーユーザーは、必要なエントリーにナビゲートするのに最も適したビューを使用することができます。たとえば、対象のエントリーが Mountain View に住んでいる人であれば、場所ベースの情報を利用したナビゲーションにより始まるビューが最適です。組織的な質問であれば、組織ビューの方が適しているでしょう。この 2 つのビューは、同時に Directory Server に存在し、同じエントリーに対して操作を行いますが、それぞれのビューはディレクトリー構造のバージョンを表示する際の目的が異なります。
図4.15「ビューを使用した DIT の組み合わせ」のビュー対応ディレクトリーのエントリーは、階層内の最上位ビューの親のすぐ下にあるフラットな名前空間に含まれています。これは必須ではありません。エントリーはそれ専用の階層に存在することができます。エントリーの配置に関してビューが持つ唯一の懸念は、ビュー階層の親の子孫でなければならないということです。
図4.16 仮想 DIT ビュー階層を含む DIT
- サブツリー ou=People には、実際の エントリー A および エントリー B エントリーが含まれています。
- サブツリー ou=Location Views は、ビュー階層です。
- リーフノード ou=Sunnyvale および ou=Mountain View には、ビューを記述する属性
nsviewfilterが含まれています。実際のエントリーを含まないため、これらはリーフノードです。ただし、クライアントアプリケーションがこれらのビューを検索すると、ou=Mountain View の下で ou=Sunnyvale および Entry B の下にエントリー A が見つかります。この仮想検索領域は、すべての上位ビューのnsviewfilter属性によって記述されます。ビューからの検索では、仮想検索空間からのエントリーと実際の検索空間からのエントリーの両方が返されます。これにより、ビュー階層を従来の DIT として機能させたり、従来の DIT をビュー階層に変更したりすることができます。
4.4.2. 仮想 DIT ビュー活用のメリット
仮想 DIT ビューを利用することで、導入の意思決定が容易になります。その理由は以下のとおりです。
- 仮想 DIT ビューは、従来の階層構造が提供するのと同様のナビゲーションと管理のサポートを提供するため、ビューではエントリーにフラットな名前空間を使用することができます。また、DIT に変更があった場合でも、エントリーを移動する必要はなく、仮想 DIT ビュー階層のみが変更されます。これらの階層は実際のエントリーを含まないため、シンプルで素早く変更することができます。
- 導入計画中の見落としは、仮想 DIT ビューを使用することで、壊滅的ではなくなります。最初の段階で階層が正しく開発されていなくても、サービスに支障をきたすことなく、簡単かつ迅速に変更することができます。
- ビュー階層を数分で完全に修正し、その結果を即座に実現できるため、ディレクトリーのメンテナンスコストを大幅に削減できます。仮想 DIT 階層の変更は瞬時に実現されます。組織変更があっても、新しい仮想 DIT ビューを迅速に作成することができます。新しい仮想 DIT ビューは古いビューと同時に存在できるので、エントリー自体およびそれらを使用するアプリケーション向けに、より段階的な変更が可能です。ディレクトリーの組織の変更は、1 か 0 かの操作ではないため、一定期間サービスを中断せずに実行できます。
- ナビゲーションと管理に複数の仮想 DIT ビューを使用すると、ディレクトリーサービスをより柔軟に利用することができます。仮想 DIT ビューで提供される機能により、組織は古いメソッドと新しいメソッドの両方を使用して、DIT の特定のポイントにエントリーを配置する必要なしにディレクトリーデータを編成できます。
- 仮想 DIT ビュー階層は、共通的に必要とされる情報の取得を容易にするために、レディーメイドのクエリーとして作成できます。
- ビューは、作業の柔軟性を高め、ディレクトリーユーザーが通常は知る必要のない属性名や値を使用して複雑な検索フィルターを作成する必要性を軽減します。ディレクトリー情報を表示およびクエリーする手段が複数ある柔軟性により、エンドユーザーとアプリケーションは階層ナビゲーションを通じて必要とされるものを直感的に把握できます。
4.4.3. 仮想 DIT ビューの例
以下の LDIF エントリーは、場所に基づいた仮想 DIT ビュー階層を示しています。dc=example,dc=com の下に存在し、ビューの説明に適合するエントリーは、すべて場所別に整理されたこのビューに表示されます。
dn: ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Location Views description: views categorized by location dn: ou=Sunnyvale,ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Sunnyvale nsViewFilter: (l=Sunnyvale) description: views categorized by location dn: ou=Santa Clara,ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Santa Clara nsViewFilter: (l=Santa Clara) description: views categorized by location dn: ou=Cupertino,ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Cupertino nsViewFilter: (l=Cupertino) description: views categorized by location
ou=Location Views,dc=example,dc=com に基づくサブツリー検索は、フィルター (l=Sunnyvale)、または (l=Cupertino) に一致する dc = example,dc=com の下のすべてのエントリーを返します。反対に、1 レベルの検索では、子ビューエントリー以外のエントリーは返されません。これは、すべての該当するエントリーが 3 つの子孫ビューにあるためです。
ou=Location Views,dc=example,dc=com ビューエントリー自体にはフィルターが含まれていません。この機能は、ビューに含まれるエントリーをさらに制限する必要なしに、階層組織を容易にします。すべてのビューがフィルターを省略できます。例示したフィルターは非常にシンプルですが、使用するフィルターは必要に応じて複雑にすることができます。
ビューに含まれるエントリーのタイプを制限することが望ましい場合があります。たとえば、この階層をユーザーエントリーのみに限定するには、ou=Location Views,dc=example,dc=com にフィルター値 (objectclass=organizationalperson) を指定して
nsfilter 属性を追加します。
フィルターを含む各ビューは、すべての子孫のビューのコンテンツを制限し、フィルターが含まれる子孫のビューも先祖の内容を制限します。たとえば、上記の新しいフィルターと共に最上位ビュー ou=Location Views を最初に作成すると、organization オブジェクトクラスを持つすべてのエントリーを含むビューが作成されます。さらにエントリーを制限する子孫のビューが追加されると、子孫のビューに表示されているエントリーは、先祖のビューから削除されます。これは、仮想 DIT ビューが従来の DIT の動作を模倣する方法を示しています。
仮想 DIT ビューは従来の DIT の動作を模倣しますが、ビューは従来の DIT ができなかったことを実行できます。エントリーを複数の場所に表示できます。たとえば、エントリー B を Mountain View と Sunnyvale の両方に関連付けるには( 図4.16「仮想 DIT ビュー階層を含む DIT」を参照)、location 属性に Sunnyvale の値を追加すると、エントリーが両方のビューに表示されます。
4.4.4. 表示およびその他のディレクトリー機能
Directory Server では、サービスクラス と ロール は、どちらもビューをサポートしています。「ディレクトリーエントリーのグループ化」 を参照してください。ビュー階層の下にサービスクラスまたはロールを追加する場合、ビューに論理的および実際的の両方に含まれるエントリーはスコープ内にあると見なされます。つまり、仮想 DIT ビューを使用してロールおよびサービスクラスを適用できますが、フラット名前空間のクエリーであっても、そのアプリケーションの効果を確認できます。
この機能の使用方法は、『Red Hat Directory Server Administration Guide』 の Advanced Entry Management を参照してください。
ビューを使用するには、アクセス制御に若干異なるアプローチが必要です。現在、ビューでは ACL への明示的なサポートがないため、ビューの親でロールベースの ACL を作成し、ロールをビュー階層の適切な部分に追加します。これにより、階層の組織プロパティーを利用できます。
検索のベースがビューであり、検索範囲がベースではない場合、検索はビューベースの検索になります。それ以外の場合は、従来の検索です。
たとえば、dc=example,dc=com のベースで検索を実行しても、仮想探索空間からのエントリーが返されません。実際、virtual-search-space の検索は実行されません。ビューの処理は、検索ベースが ou=Location Views の場合にのみ発生します。これにより、ビューは、検索により、両方の場所からのエントリーが表示されないようにします。(従来の DIT の場合、両方の場所からのエントリーが返されます。)
4.4.5. パフォーマンスに対する仮想ビューの影響
ビューベースの階層のパフォーマンスは、階層自体の構造と DIT のエントリー数に依存します。一般的には、ディレクトリーサービスで仮想 DIT ビューが有効になっている場合、パフォーマンスに関して若干の変化が発生する可能性があります (従来の DIT での同等の検索に対して数パーセントポイント以内)。検索でビューを呼び出さない場合は、パフォーマンスへの影響はありません。導入の前に、予想される検索パターンおよび負荷に対して仮想 DIT ビューをテストします。
また、ビューを組織内の汎用のナビゲーションツールとして使用する場合は、ビューフィルターで使用される属性をインデックス化することが推奨されます。さらに、ビューで使用されるサブフィルターが設定済みの仮想リストビューインデックスと一致する場合、そのインデックスがビューの評価で使用されます。
特にビュー用に、ディレクトリーの他の部分をチューニングする必要はありません。
4.4.6. 既存のアプリケーションとの互換性
仮想 DIT ビューは、従来の DIT を高いレベルで模擬するように設計されています。ビューの存在は、ほとんどのアプリケーションに対して透過的にする必要があります。ビューを使用していることを示すものがあってはいけません。いくつかの特殊なケースを除き、Directory Server インスタンスでビューが使用されていることを、ディレクトリーユーザーが知る必要はありません。ビューは従来の DIT のように表示され、動作します。
特定のタイプのアプリケーションでは、ビュー対応ディレクトリーサービスを使用すると問題が発生する可能性があります。以下に例を示します。
- ターゲットエントリーの DN を使用して DIT をナビゲートするアプリケーション。このタイプのアプリケーションは、エントリーが見つかったビュー階層ではなく、エントリーが物理的に存在する階層をナビゲートしていることを把握します。その理由は、ビューは、ビューの階層に合わせてエントリーの DN を変更することで、エントリーの本当の位置を隠そうとはしないからです。これは意図的なものです。エントリーの真の位置が偽装されていると、多くのアプリケーションが機能しなくなります。例えば、一意のエントリーを識別するために DN に依存するアプリケーションなどです。このように DN を分解して上方向にナビゲートするのは、クライアントアプリケーションとしては珍しい手法ですが、それにもかかわらず、これを行うクライアントは意図した通りに機能しない可能性があります。
numSubordinates操作属性を使用して、ノードの下に存在するエントリーの数を決定するアプリケーション。ビュー内のノードについては、現在、仮想検索空間を無視して、実際の検索空間に存在するエントリーのみをカウントしています。そのため、アプリケーションでは検索を使用してビューを評価できない場合があります。
