| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
前 |
次 |
サービス・クラス(CoS)メカニズムにより属性をエントリ間で共有できるようになります。CoSの値は、リクエストが出されたときに動的に計算されます。CoSの詳細は次の項を参照してください。
facsimileTelephoneNumber属性に対してすべてが同じ値を持つ数千のエントリが含まれているディレクトリを想定してみます。従来は、FAX番号を変更するには各エントリを個別に更新するので、管理者にとっては時間のかかる作業でした。CoSを使用すると、FAX番号は1つの場所に保管され、各エントリが返されるときにfacsimileTelephoneNumber属性が自動的にそれぞれのエントリに生成されます。
クライアント・アプリケーションに対して、CoS属性は他の属性と全く同じ方法で生成されます。ただし、ディレクトリの管理者にとって、今度は管理するFAX番号が1つだけです。また、ディレクトリに格納される値の数も少なくなるので、データベースが使用するディスク容量も少なくなります。さらに、CoSメカニズムではエントリが生成済の値を上書きしたり、同じ属性について複数の値を生成できます。
|
注意: CoS仮想属性は索引付けされていないため、LDAP検索フィルタで参照するとパフォーマンスに影響する場合があります。 |
生成されるCoS属性は複数値であることが可能です。指定子は複数のテンプレート・エントリを指定するか、または、同じ属性に対して複数のCoS定義が存在できます。または、すべてのテンプレートからただ1つの値が作成されるように、テンプレートの優先度を指定できます。
ロールおよびクラッシックCoSを一緒に使用してロール・ベースの属性を指定できます。これらの属性は、関連付けられたCoSテンプレートを持つ特定のロールをエントリが所有しているため、そのエントリに表示されます。たとえば、ロール・ベースの属性を使用して、ロールごとにサーバーの検索制限を設定できます。
CoS機能は再帰的に使用でき、ユーザーはCoSによって生成された他の属性に依存するCoSを使用して、属性を生成できます。複雑なCoSスキームは情報へのクライアントのアクセスを簡素化し、反復する属性の管理を容易にしますが、これらによって管理の複雑さが増し、サーバーのパフォーマンスが低下します。極端に複雑なCoSスキームは避けてください。たとえば、多くの間接的なCoSスキームはクラシックCoSまたはポインタCoSとして再定義できます。
また、必要以上頻繁にCoS定義を変更することも、避ける必要があります。サーバーはCoS情報をキャッシュするため、CoS定義への変更はただちに有効にはなりません。キャッシングにより、生成済属性への読取りアクセスは速くなりますが、CoS情報への変更が発生すると、サーバーはキャッシュを再構成する必要があります。このタスクは多少時間がかかる場合があり、通常はほぼ数秒程度です。キャッシュの再構成時に、書込み操作で新しく変更された情報ではなく、依然として古いキャッシュ済情報にアクセスする場合がありますが、これは、あまり頻繁にCoS定義を変更した場合、旧データへアクセスする可能性が高くなることを意味します。
CoSメカニズムは、CoS定義エントリおよびCoSテンプレート・エントリの、2つのタイプのエントリに依存しています。この項ではCoS定義エントリおよびCoSテンプレート・エントリについて説明します。
CoS定義エントリは、CoSのタイプと、生成されるCoS属性の名前を識別します。ロール定義エントリと同様、CoS定義エントリはLDAPsubentryオブジェクト・クラスから継承されます。同じCoS属性に対して複数の定義が存在する場合があり、その結果、複数値になることがあります。
CoS定義エントリはcosSuperDefinitionオブジェクト・クラスのインスタンスです。CoS定義エントリはCoSのタイプを指定するために、次のいずれかのオブジェクト・クラスからも継承されます。
cosPointerDefinition
cosIndirectDefinition
cosClassicDefinition
CoS定義エントリには、ターゲット・エントリの仮想CoS属性、テンプレートDNおよび指定子属性を命名するための、それぞれのCoSタイプに固有の属性が含まれています。デフォルトで、CoSメカニズムはCoS属性と同じ名前を持つ既存の属性の値を上書きしません。ただし、CoS定義エントリの構文でこの動作を制御できます。
スキーマ・チェックが有効になっている場合、CoS属性はその属性を許可するすべてのターゲット・エントリに生成されます。スキーマ・チェックが無効になっている場合、CoS属性はすべてのターゲット・エントリに生成されまます。
定義エントリの場所はCoSの範囲を決定しますが、これは、CoS定義エントリの親の下にあるサブツリー全体です。定義エントリの親のブランチのすべてのエントリは、CoS定義に対してターゲット・エントリと呼ばれます。
次の図は、ou=peopleサブツリーのルートにあるCoS定義エントリを示しています。CoSの範囲はルートの下の2つのサブツリーのみです。CoSはこのルートを超えて拡張されませんし、DITの他のサブツリーにも拡張されません。
CoSテンプレート・エントリにはCoS属性のために生成された値が含まれています。CoSの範囲内のすべてのエントリはここで定義された値を使用します。それぞれが異なる値を持つ複数のテンプレートである場合もありますが、その場合は、生成される属性が複数値になることがあります。CoSメカニズムは、定義エントリおよびターゲット・エントリの両方の内容に基づき、これらの値の1つを選択します。
CoSテンプレート・エントリは、cosTemplateオブジェクト・クラスのインスタンスです。CoSテンプレート・エントリにはCoSメカニズムにより生成された属性の値が1つまたは複数含まれています。特定のCoSのテンプレート・エントリは、そのCoS定義と同じレベルのディレクトリ・ツリーに格納されます。
管理を容易にするために、可能な場合は定義エントリとテンプレート・エントリを同じ場所に配置する必要があります。また、それらには、提供する機能を連想させるような名前を付ける必要があります。たとえば、「cn=classicCosGenEmployeeType,ou=People,dc=example,dc=com」のような定義エントリのDNは、「cn=ClassicCos1,ou=People,dc=example,dc=com」よりも説明的です。オブジェクト・クラスおよび各CoSタイプに関連付けられる属性の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のサービス・クラスに関する説明を参照してください。
次のタイプのCoSではテンプレートを選択する方法、ひいては生成される値が異なります。
ポインタCoSは最も単純なタイプのCoSです。ポインタCoS定義エントリは、cosTemplateオブジェクト・クラスの特定のテンプレート・エントリのDNを提供します。すべてのターゲット・エントリには、このテンプレートにより定義された同じCoS属性値があります。
次の図は、dc=example,dc=comの下に格納されたすべてのエントリで共通の郵便番号を定義するポインタCoSを示しています。CoS定義エントリ、CoSテンプレート・エントリおよびターゲット・エントリが示されています。
テンプレート・エントリは、CoS定義エントリ内のDN (cn=exampleUS,cn=data)で識別されます。dc=example,dc=comでpostalCode属性が問合せられるたびに、Directory Serverはテンプレート・エントリcn=exampleUS,cn=dataで使用できる値を返します。したがって、郵便番号はエントリuid=wholiday,ou=people,dc=example,dc=comにより表示されますが、そこには格納されません。
各エントリの既存の実在属性ではなく、数十万または数百万のエントリに対して複数の共有属性がCoSにより生成されるシナリオでは、CoSによりストレージ領域の大幅な節約とパフォーマンスの大幅な向上が提供されます。
間接CoSではディレクトリ内の任意のエントリをテンプレートにすることができ、CoSの値を指定できます。間接CoS定義エントリは、間接指定子と呼ばれる属性を識別し、ターゲット・エントリのその値は、そのエントリに使用されるテンプレートを決定します。ターゲット・エントリの間接指定子属性にはDNが含まれている必要があります。間接CoSでは各ターゲット・エントリで異なるテンプレートを使用でき、そのため、CoS属性に対して異なる値を持つ場合があります。
たとえば、departmentNumber属性を生成する間接CoSは指定子として従業員のマネージャを使用する場合があります。ターゲット・エントリを検索するときに、CoSメカニズムはテンプレートとしてmanager属性のDN値を使用します。次に、同じ値をマネージャの部門番号として使用することにより、従業員のdepartmentNumber属性を生成します。
|
注意: テンプレートはディレクトリ・ツリー内の任意の場所にある任意のエントリが可能なので、間接CoSに対するアクセス制御の実装はきわめて複雑になる場合があります。パフォーマンスが重要となるデプロイメントにおいては、そのリソース集中的な性質上、間接CoSの使い過ぎも避ける必要があります。 多くの場合、間接CoSにより可能になるのと同様の結果は、クラシックCoSによりターゲット・エントリの場所を制限するか、またはより柔軟性の低いポインタCoSメカニズムを使用することにより、達成できます。 |
次の図は、そのターゲット・エントリのmanager属性を使用してテンプレート・エントリを識別する間接CoSを示しています。このようにして、CoSメカニズムはすべての従業員のdepartmentNumber属性を、その従業員たちのマネージャと同じになるように生成でき、それにより、属性が常に最新であることを確保します。
間接CoS定義エントリは指定子属性に名前を付けますが、この例ではmanager属性となっています。William HolidayのエントリはこのCoSのターゲット・エントリの1つで、そのmanager属性にはuid=cfuentes,ou=people,dc=example,dc=comというDNが含まれています。したがって、Carla Fuentesのエントリがテンプレートで、これによって、318842というdepartmentNumber属性が指定されます。
クラシックCoSはポインタおよび間接CoSの動作を結合します。クラシックCoS定義エントリはテンプレートのベースDNおよび指定子属性を識別します。その後、ターゲット・エントリの指定子属性の値を使用して、次のようにテンプレート・エントリのDNが構成されます。
cn=specifierValue, baseDN
CoSの値が含まれたテンプレートは、ターゲット・エントリの指定子属性のRDN (相対識別名)値およびテンプレートのベースDNの組合せにより決定されます。
クラシックCoSテンプレートは、任意の間接CoSテンプレートに関連するパフォーマンス問題を回避するための、cosTemplateオブジェクト・クラスのエントリです。
クラシックCoSのメカニズムは定義エントリで指定されたベースDNおよびターゲット・エントリの指定子属性からテンプレートのDNを決定します。指定子属性の値はテンプレートDNのcn値としてとられます。このため、クラシックCoSのテンプレートDNは次の構造を持つ必要があります。
cn=specifierValue,baseDN
次の図は郵便番号属性の値を生成するクラシックCoS定義を示します。
この例で、cosSpecifier属性はemployeeType属性の名前を付けます。cosSpecifier属性およびテンプレートDNの組合せにより、テンプレート・エントリがcn=sales,cn=exampleUS,cn=dataであると識別されます。次に、テンプレート・エントリはターゲット・エントリにpostalCode属性の値を指定します。
サービス・クラス(CoS)により属性をエントリ間で共有できます。ロール・メカニズム同様、CoSはエントリが検索されるときにエントリに仮想属性を生成します。CoSはメンバーシップを定義しませんが、一貫性および空き領域に対する考慮から、関連エントリによるデータ共有を許可します。CoSの値は、値がリクエストされたときに動的に計算されます。
次の各項では、パフォーマンスの低下を避けつつ、意図するとおりにCoS機能を使用できる方法を検証します。
|
注意: CoSの生成は常にパフォーマンスに影響します。実際に必要な以上に多くの属性を検索するクライアント・アプリケーションは、この問題をさらに複合的にすることがあります。 クライアント・アプリケーションの記述方法に影響力がある場合、クライアント・アプリケーションは実際に必要な属性値のみを検索するほうがパフォーマンスが非常によいということを、開発者に再認識してもらいます。 |
CoSは、サブツリー内の多数のエントリに同じ属性値を表示する必要がある場合に、比較的低いコストで大きな利点を提供します。
たとえば、ou=Peopleの下のすべてのユーザー・エントリにcompanyName属性が含まれている、MyCompany, Inc.のディレクトリを考えてみます。各請負業者はcompanyName属性に対して実際の値を持ちますが、正規社員はすべて、CoSにより生成される1つの値MyCompany, Inc.をcompanyName属性に対して持ちます。次の図は、この例でポインタCoSを使用した場合を示しています。CoSは、請負業者の従業員用に格納されている、CoSにより生成されたのではないcompanyNameの実際の値を上書きすることなく、すべての正社員のcompanyName値を生成します。会社名は、companyNameが許可された属性になっているエントリに対してのみ生成されます。
多数のエントリが同じ値を共有する場合には、ポインタCoSが特に活躍します。正社員のcompanyNameの保守が容易になることで、属性値を生成するための追加の処理コストが相殺されます。深いディレクトリ情報ツリー(DIT)は、一般的な特徴を共有するエントリをまとめる傾向があります。深いDITでポインタCoSを使用すると、ツリーの適当な分岐にCoS定義を配置することによって、一般的な属性値を生成できます。
CoSはまた、ディレクトリ・データが自然な関係を持っている場合も、データ管理の大きな利点を提供します。
すべての従業員にマネージャがいる企業ディレクトリを考えてみます。すべての従業員はメール・ストップとFAX番号を、最も近い管理アシスタントと共有しています。図12-6は、間接CoSを使用して、マネージャのエントリから部門番号を取得する様子を示しています。図12-7では、管理アシスタントのエントリからメール・ストップとFAX番号が取得されます。
この実装では、マネージャのエントリにdepartmentNumberの実際の値が含まれ、その値は生成されたすべての値に優先します。Directory Serverは、CoSで生成された属性値からは属性値を生成しません。そのため、図12-6の例では、部門番号の属性値をマネージャのエントリ上でのみ管理する必要があります。同様に、図12-7に示されている例では、メール・ストップとFAX番号の属性を管理アシスタントのエントリ上でのみ管理する必要があります。
単一のCoS定義エントリを使用して、このような関係をディレクトリ内の様々なエントリに利用できます。
別の自然な関係に、サービス・レベルがあります。顧客にスタンダード、シルバー、ゴールドおよびプラチナのパッケージを提供しているインターネット・サービス・プロバイダを考えてみます。顧客のディスク割当て、メールボックスの数、前払いのサポート・レベルに対する権限などは、購入したサービス・レベルによって異なります。次の図は、クラシックCoSスキーマによってこの機能が可能になる様子を示しています。
1つのCoS定義が複数のCoSテンプレート・エントリに関連付けられる場合があります。
Directory Serverは、1つのクラシックCoS定義エントリが複数のCoS定義テンプレート・エントリに関連付けられている場合はCoSを最適化します。Directory Serverは、多数のCoS定義が適用される可能性がある場合はCoSを最適化しません。かわりに、Directory Serverは各CoS定義をチェックして、この定義が適用されるかどうかを判定します。この動作によって、数千のCoS定義が存在する場合はパフォーマンスの問題が発生します。
この状況は、図12-8で示した例に変更がある場合に発生する可能性があります。各顧客のサービスレベルの委任管理を顧客に提供している、インターネット・サービス・プロバイダを考えてみます。各顧客から、スタンダード、シルバー、ゴールドおよびプラチナのサービス・レベルの定義エントリが提供されます。顧客数が1000に増えると、1000個のクラシックCoS定義が作成されることになります。どの定義が適用されるを判定するために1000個のCoS定義のリストがチェックされるため、Directory Serverのパフォーマンスが影響を受ける可能性があります。この種の状況でCoSを使用する必要がある場合は、間接CoSを検討してください。間接CoSでは、顧客のエントリによって、その顧客のサービスクラス割当てを定義するエントリが特定されます。
1つまたは2つのターゲットエントリごとに別のCoSスキーマを選択することの限界に近づき始めたら、実際の値を更新することをお薦めします。CoSで生成されていない実際の値が読み取られるため、より高いパフォーマンスが実現します。
属性値を提供するために、それぞれが競合するCoSスキーマを作成することが可能です。たとえば、CoS定義エントリに複数値のcosSpecifierがあるとします。そのような場合、各テンプレート・エントリに対してテンプレートの優先度を指定し、属性値を提供するテンプレートを決定することができます。テンプレートの優先度はcosPriority属性を使用して設定します。この属性は、特定のテンプレートのグローバル優先度を数値で表します。優先度ゼロは、考えられる最高の優先度です。
cosPriority属性が含まれていないテンプレートは、考えられる最低の優先度であるとみなされます。属性値を供給するテンプレートとして2つ以上のテンプレートが検討され、それらが同じ優先度を持っているか、またはいずれも優先度を持たないテンプレートである場合、値は任意に選択されます。Directory Serverは、テンプレートを強制的に任意で選択する場合に、メッセージを記録するように構成できます。
CoSの機能は複雑なメカニズムであり、パフォーマンスおよびセキュリティ上の理由から次の制限を受けます。
サブツリーの制限
CoS定義はcn=configまたはcn=schemaサブツリーには作成できません。
索引付けされていない検索
属性がCoSにより生成された属性であると宣言されている場合にサフィックスで検索を実行すると、索引付けされていない検索になります。これはパフォーマンスに大きな影響を及ぼす場合があります。同じ属性がCoS属性では「ない」と宣言されているサフィックスでは、検索が索引付けされます。
属性タイプの制限
次の属性は、同じ名前の実際の属性とは異なる振舞いを持つため、CoSにより生成されることはありません。
userPassword - CoSにより生成されるパスワード値は、Directory Serverへのバインドに使用できません。
aci - Directory Serverは、CoSにより定義される仮想ACIの内容に基づいてアクセス制御を適用しません。
objectclass - Directory Serverは、CoSにより定義された仮想オブジェクト・クラスの値に対してスキーマ・チェックを実行しません。
nsRoleDN - CoSで生成されたnsRoleDN値は、ロールを生成するためにサーバーで使用されません。
テンプレートはローカル
テンプレート・エントリのDNは、それがCoS定義のものでも、またはターゲット・エントリの指定子のものでも、ディレクトリのローカル・エントリを参照する必要があります。テンプレートおよびそれに含まれる値は、ディレクトリ・チェーニングまたはリフェラルによって取得することはできません。
CoS仮想値は実際の値と結合できません。
CoS属性の値が、エントリの実際の値とテンプレートの仮想値を組み合せたものになることはありません。CoSが実際の属性値を上書きする場合は、すべての実際の値をテンプレートの値に置き換えます。ただし、CoSのメカニズムによって、複数のCoS定義エントリの仮想値を結合することができます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のCoSの制限に関する説明を参照してください。
フィルタされたロールのフィルタ文字列は、CoS仮想値の値に基づくことはできません。ただし、CoS定義の指定子属性が、ロール定義により生成されたnsRole属性を参照する場合があります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のロールベースの属性の作成に関する説明を参照してください。
サーバーは通常の、保管された属性へのアクセスを制御するのとまったく同じ方法で、CoSにより生成された属性へのアクセスを制御します。ただし、CoSにより生成された属性の値に応じたアクセス制御ルールは、「CoSの制限」で説明した条件に従います。
CoSキャッシュは、パフォーマンスを改善するために、すべてのCoSデータをメモリーに保持する内部構造です。このキャッシュは、CoS定義およびテンプレート・エントリを更新中の場合でも、仮想属性の計算に使用されるCoSデータを取得するために最適化されます。したがって、定義エントリおよびテンプレート・エントリが追加または変更された場合は、それらが考慮されるまでに若干の遅延が生じる場合があります。この遅延はCoS定義の数と複雑さ、および現在のサーバーの負荷によって異なりますが、通常は2、3秒です。極端に複雑なCoS構成を設計する前に、この遅延を検討してください。
