ディレクトリの分散化とルーティング

このセクションでは、以下のトピックについて説明します。
cad141jp
このセクションでは、以下のトピックについて説明します。
分散化機能
分散型ディレクトリで、DSA は X.500 Directory Systems Protocol (DSP)を使用し、ネームスペースの任意の領域上のクエリを協力して解決します。
CA Directory は、以下の分散化機能を含め、X.500 Directory Systems Protocol を完全にサポートしています。
  • ルーティングまたは連鎖
    。DSA に送信されたリクエストは、別の DSA によって実行されます。ルーティングの決定は、リクエストのベース DN、およびバックボーン内の DSA のプレフィックスに基づきます。ルーティングされたリクエストは単一の DSA によって処理されます。ターゲット DSA に問い合わせることができない場合、リクエストはリフェラル エラーによって拒否されます。
  • Multi-Chaining 検索
    。サブツリー全体を含んでいる検索は、複数の DSA にわたって広げられる場合があります。Multi-Chaining が有効な場合、Multi-Chaining した検索はサブツリー全体にわたるプロセスに従います。
  • 継続リファレンスまたはリフェラル
    。分散型リクエストをサービスするバックボーン内の 1 つ以上の DSA に問い合わせることができない場合、リフェラルまたは継続リファレンスがクライアントに返され、検索の未検索領域が示されます。
分散化のしくみ
分散化された
ディレクトリでは、多くの DSA が共同で単一のネームスペースを形成します。ネームスペースの部分は異なる DSA によってサービスされます。任意の DSA に接続されたアプリケーションは、ネームスペース全体を検索できます。
クライアントの視点から見て、ディレクトリ バックボーンは単一のエンティティです。これは、すべてのリクエストがネームスペース内の適切な DSA にルーティングされるからです。
DSA は、すべてが同じコンピュータ上にあることもあれば、別々のコンピュータ上にあることもあります。
分散型ディレクトリは、複数の場所のオフィスを持つ組織にとって有用です。これは、各オフィスが自身のディレクトリをメンテナンスできる一方、クライアントにとっては単に 1 つのディレクトリとして表示されるからです。また、異なるサーバにわたってデータを共有するとき、拡張性とパフォーマンスが向上するので、大きなディレクトリにも役立ちます。
分散型ディレクトリは LDAP サーバを組み込むことができます。CA Directory は LDAP 標準に完全に準拠しています。つまり、LDAP をサポートするディレクトリを統一して、バックボーンとして使用することができます。
分散型ディレクトリの例
以下の図は、5 つの DSA がサービスする単一のネームスペースを示しています。CA Directory DSA は DSP を使用して相互に通信します。また、LDAP を使用して LDAP のみのディレクトリ サーバと通信します。
A single namespace that is served by five dsas 14.1
 
クライアントがディレクトリにクエリを送信すると、クエリはネームスペースの関連する部分に対して動作する DSA にルーティングされます。クライアントは、ディレクトリが分散化していることを知る必要はありません。
Multi-Chaining 検索のしくみ
Multi-Chaining 検索は以下の方法で機能します。
  1. DSA が検索リクエストを受信し、自ら検索する
  2. 検索は次に、(存在すれば)すぐ下の DSA にマルチキャストされる
  3. その後、下位の DSA が 1 で処理を続行する
  4. 検索がすべて完了すると、結果が照合され、クライアントに返される
検索スコープ内のどの DSA にも問い合わせることができない場合は、部分的な結果が、ディレクトリ情報ツリーの未検索領域を示す検索結果と共に含まれています。
注:
Multi-Chaining をマルチキャスティングと呼ぶことは適切でありません。マルチキャスティングは、多くの Multi-Chaining 検索を含むコンポーネントです。
ルーティングまたは連鎖のしくみ
バックボーン内の DSA がリクエストを受信すると、リクエストを処理するために別の DSA にリクエストを転送する(または
連鎖する
)必要がある場合があります。
リクエストを受信する DSA は、最短ルートを使用してドメイン内の他の DSA にそのリクエストを直接転送できます。これは、ディレクトリ バックボーン全体が同じ設定ナレッジを共有しているからです。
更新リクエストのルーティング例
以下の図は、単一のネームスペースを制御する 5 つの DSA を示しています。各 DSA はプレフィックスによって表されるネームスペースの部分を制御します。また、他の DSA との関係はドメインで表されます。
以下の図で、DSA 1 は DSA 2 および DSA 3 よりも上位です。DSA 4 および DSA 5 は DSA 3 より下位です。
This diagram illustrates how dsa is superior of dsa2 and dsa3. And dsa4 and dsa5 are subordinates of dsa3 14.1
  1. クライアントは、エントリ cn=Milio GILMORE、ou=Legal、ou=Corporate、o=DEMOCORP、c=AU の電話番号を変更するため、DSA 2 にリクエストを送信します。
  2. DSA 2 がリクエストを処理できないときは、最短ルートを使用して、DSA 5 へのリクエストをルーティング(転送)します。
  3. DSA 5 は電話番号を変更し、DSA 2 に確認レスポンスを送信します。
  4. DSA 2 がクライアントに応答を送信します。
操作制限が分散化に与える影響
DSA が分散型リクエストをサービスする間に課すことのできる操作制限には、時間制限とサイズ制限の 2 つがあります。
  • 時間制限
    。ローカル DSA がリクエストを受信すると、時間制限を適用できます(たとえば max-op-time または service time limit)。リクエストがリモート DSA に連鎖または Multi-Chaining された場合でも、ローカル DSA にはまだリクエストの参照が保持されています。たとえリクエストが現在 1 つ以上のリモート DSA によってサービスされていても、この参照は時間制限による影響を受けます。
    例:
    max-op-time が 30 秒に設定され、Democorp: <c AU><o Democorp> が UNSPSC: <c AU><o UNSPSC> のスコープでリクエストを受信すると、そのリクエストは連鎖します。Democorp が 30 秒間 UNSPSC からの応答を受信しない場合、リクエスト拒否(adminLimitExceeded)がクライアントに送信されます。また Democorp は、リクエストが続行するのを止めようとして、UNSPSC に中止リクエストを送信します。
  • サイズ制限
    : ローカル DSA が検索リクエストを受信すると、サイズ制限が結果に適用されます(たとえば max-op-size または service size limit)。リクエストが別の DSA に連鎖または Multi-Chaining された場合、ローカル DSA 制限は実施されません。サイズ制限は、検索をローカルに実行するデータ DSA によってのみ実施されます。
    例:
    すべての DSA について max-op-size が 100 に設定され、Router: <c AU> がスコープ <c AU> で全サブツリー検索を受信した場合、検索は Democorp: <c AU><o Democorp> と UNSPSC: <c AU><o UNSPSC> の両方に Multi-Chaining されます。Democorp と UNSPSCS はどちらもサイズ制限を適用し、部分的結果(adminLimitExceeded)と共にそれぞれ 100 のエントリを返します。ルータは結果(200 エントリ)を照合し、クライアントに結果(部分的結果を含む)を送信します。サイズ制限がルータによって強制されないので、ルータは結果セットの形式を整えません。ただし、DSA は連鎖リクエストを処理します。
リモート操作
各 DSA には、その DSA によって制御される DIT のベースを定義するコンテキスト プレフィックスがあります。
DSA が受信操作を受信すると、ネームスペースの自身のセクションでリクエストが発生したときにリクエストをローカルでサービスします。操作がローカルでないときは、以下の状況を除き、リモート DSA に操作を連鎖します。
  • 1 つの(ユーザ)サービス制御(
    chainingProhibited
    または
    localScope
    のいずれか)が設定されている。
  • リモート DSA は利用不可能である。
  • リモート DSA への適切な認証レベルのリンクを確立できない。
  • 操作のエリアに DSA ナレッジがない。
状況に応じて、リモート操作が以下のいずれかのオプションを返します。
  • 結果
  • リフェラル
  • サービス エラー
  • セキュリティ エラー
分散型 DSA がどのように協力してクエリを解決するかについての完全な仕様は、X.500 標準を参照してください。
下位 DSA からエントリをキャッシュする
DAP と異なり、LDAP には LIST 操作がありません。したがって、LDAP クライアントがディレクトリを参照するとき、LDAP クライアントはオブジェクト クラスのみを返す 1 レベル検索を呼び出します。
これらの 1 レベル検索は、下位 DSA が多数あるとき問題になります。1 レベル検索は、各 DSA にブロードキャストする必要があるからです(LIST は DSA の名前を返します)。
これによって発生するフラッディング効果(特に最初のレベルの DSA)を停止するために、DSA は 1 レベル検索クエリへの応答をキャッシュし、その後の同様のリクエストに利用できるようにします。
オブジェクト クラスを返す 1 レベルの検索のみがキャッシュされます。これらはディレクトリを参照するために一般的に使用される検索です。
透過的なルーティング
透過的なルーティング
により、ルータ DSA は制御スキーマを必要とせずに、LDAP リクエストおよび応答を処理できます。ルータ DSA が LDAP クライアントを LDAP サーバにリンクするように使用されている場合、またはクライアントとサーバにルータ DSA の知らないスキーマがある場合、これは役立ちます。透過的なルーティングは LDAP クライアントのみで動作します。
デフォルトでは、透過的なルーティングは
false
に設定されます。  以下の図に示すように、透過的なルーティングはルータ上に設定できます。
Transparent Routing