| 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 |
|
前 |
次 |
この章では、Directory Serverのアーキテクチャの概要を説明します。この章の内容は、次のとおりです。
Directory Serverの役割は、規格に準拠したLDAPアプリケーションおよびDSMLアプリケーションに、ディレクトリのデータを渡すことです。Directory Serverは、データ・セットが大容量になっても検索時間が短くなるように、カスタマイズされた二分木のデータベースにデータを格納します。
ディレクトリは、オブジェクト指向データベースです。ディレクトリは、エントリと呼ばれるデータ・オブジェクトを、DITと呼ばれるディレクトリ情報ツリーに編成します。各エントリは、uid=bjensen,ou=people,dc=example,dc=comなどの識別名で識別されます。識別名によって、ディレクトリ情報ツリーでのエントリの場所が識別されます。たとえば、uid=bjensen,ou=people,dc=example,dc=comは、ツリーのdc=example,dc=com部分のou=peopleブランチ上にあるBarbara Jensenのユーザー・エントリです。
各ディレクトリには属性があります。人に関するエントリの場合、それらの属性は、名前、電話番号、電子メール・アドレスなどを反映している場合があります。属性には、少なくとも1つのタイプ名があり、これはその属性の名前です。たとえば、人エントリは、属性surname (短い名前snで呼ぶことも可能)を持つことができます。属性は、1つ以上の値を持つこともできます。たとえば、Barbara JensenがQuentin Cubbinsと結婚し、Quentinの苗字を使用する場合、彼女のエントリは、sn: Jensenおよびsn: Cubbinsを持つことができます。
ディレクトリは、その属性の値に基づいてエントリを検索する際に高速になるように設計されています。たとえば、「dc=example,dc=com以下にある苗字がJensenのすべてのエントリを検索する」と問い合わせることができます。この高速参照機能は、頻繁に読み取る必要のある情報を格納するアプリケーションに対して、ディレクトリをよく適した状態にします。したがって、ディレクトリは、電話や電子メールの情報に適したデータ・ストアです。さらに、ディレクトリは、認証の資格証明、アイデンティティ情報およびアプリケーションの構成データの処理にも適しています。
また、Directory Serverは、ディレクトリ内の情報が変更される際の高い更新率に対応するように設計されています。今日、多くのディレクトリ・デプロイメントのサイズは、更新を適切に処理することは参照を処理するのと同じぐらい重要であることを意味します。
Directory Serverでは、多数のディレクトリ関連の標準およびRFCがサポートされています。Directory Serverでは、高可用性のためのネットワークを介した高速データ・レプリケーションが可能です。Directory Serverでは、サーバーを再起動することなく包括的に構成できます。さらに、Directory Serverでは、ディレクトリ・データへのアクセスに対する広範囲にわたる制御が可能です。
Directory Serverの機能のリストは非常に長いため、簡単な紹介では説明できません。『Oracle Directory Server Enterprise Edition評価ガイド』に詳細なリストが含まれています。このリファレンスのこの部のその他の章は、多くの機能の詳細な理解に役立ちます。
この項では、Directory Serverの主要概念について、Directory Serverをインストールおよび管理する必要のある担当者の視点から簡潔に説明します。この項の内容は次のとおりです。
Directory Serverソフトウェアのインストールごとに、複数のサーバー・インスタンスを作成できます。ソフトウェアをインストールしたファイル・システム上にサーバー・インスタンスを作成できますが、ソフトウェアとインスタンスを併置するために必要なものはありません。
インストールするDirectory Serverソフトウェアには、実際のサーバーを作成、実行および管理するために必要な実行可能ファイル、テンプレート・データおよびサンプル・ファイルが含まれています。ソフトウェアは実際のサーバーとは分離されているため、サーバー・データを変更することなく、ソフトウェアにパッチまたはサービス・パックを適用できます。そのため、各サーバー・インスタンスにパッチを適用する必要はありませんが、そのかわり、ソフトウェア・インストールにのみ必要です。
Directory Serverインスタンスは、ディレクトリ・クライアント・アプリケーションにサービスを提供するために必要な構成データおよびディレクトリ・データを保持します。本番システムでは、サーバーのユーザー・アイデンティティを慎重に制御しますが、通常システム上では、Directory Serverインスタンスをユーザーとして作成および実行できます。その後、ディレクトリ・データは、インスタンスを作成したユーザーに属します。
第1章「Directory Server Enterprise Editionのファイル参照」では、「Directory Server Enterprise Editionのソフトウェア・レイアウト」が「Directory Serverインスタンスのデフォルト・レイアウト」から明確に分離されていることを確認します。特に、ドキュメントでは、ソフトウェア・インストールを参照するときはinstall-pathですが、サーバー・インスタンスを参照するときはinstance-pathと記載されていることに注意してください。
Directory Serverは、構成したポート番号上でLDAPおよびDSMLクライアント・アプリケーション・トラフィックをリスニングします。Directory Serverは、サーバーの起動直後にLDAP接続をリスニングします。DSMLサービスを構成した場合は、Directory ServerはHTTPを介したDSML接続のみをリスニングします。
デフォルトでDirectory Serverは、インスタンスがrootによって作成された場合はポート389上のLDAP接続をリスニングし、インスタンスがroot以外によって作成された場合は、1389をリスニングします。デフォルトでDirectory Serverは、インスタンスがrootによって作成された場合はポート636上のSSLを介したLDAP接続をリスニングし、インスタンスがroot以外によって作成された場合は、1636をリスニングします。DSML/HTTPポート番号はデフォルトでは定義されていません。かわりに、DSMLサービスを有効化するときに、ポート番号を指定します。
クライアント・アプリケーションがDirectory Serverを使用できるようにするには、静的IPアドレスを使用してホスト上にインスタンスを作成します。ホスト名も通常、DNSで参照されます。クライアント・アプリケーションがディレクトリにアクセスするには、少なくとも2つの情報が必要です。
Directory Serverが実行されるシステムのホスト名、または少なくともIPアドレス。
Directory Serverがクライアント接続をリスニングするポート番号。
LDAPクライアントおよびサーバーは、通常、リクエストごとに新しい接続を開きません。LDAPモデルでは、クライアントはその他の操作を実行する前に、認証のためにサーバーに接続します。この接続および認証プロセスは、バインディングと呼ばれます。クライアント・アプリケーションは資格証明を使用してバインドできますが、匿名でバインドすることもできます。Directory Serverでは、状況に応じて、既知および匿名のクライアントの両方にアクセスを構成できます。クライアント・アプリケーションは接続を開いたままにもできますが、再度バインドして、認証アイデンティティを変更します。この技術によって、新しい接続を作成するためのコストを削減できます。
バインドが実行され、クライアントが認証されると、クライアントは次の操作をリクエストできます。
新しいディレクトリ・エントリを追加します。
属性値が指定された値と同じかどうかを確認します。
ディレクトリ・エントリを削除します。
ディレクトリ・エントリの1つ以上の属性を変更します。
ディレクトリ・エントリの識別名を変更します。
この操作は、ディレクトリ・エントリをディレクトリ情報ツリーの1つの部分から別の部分に移動するために行います。たとえば、uid=bjensen,ou=employees,dc=example,dc=comからuid=bjensen,ou=people,dc=example,dc=comに移動できます。
ou=people,dc=example,dc=comなどの親エントリを移動する場合は、Directory Serverはその親エントリのすべての子エントリも移動する必要があるため、操作に非常に時間がかかる場合があります。
ディレクトリ・エントリの相対識別名を変更します。
相対識別名は、ディレクトリ情報ツリーと同じレベルで、他のエントリからディレクトリ・エントリを識別するために使用される属性値です。
この操作は、ディレクトリ・エントリの名前を変更するために行います。たとえば、uid=bjensen,ou=employees,dc=example,dc=comからuid=bcubbins,ou=people,dc=example,dc=comに名前を変更できます。
この操作は、modDNの特別なケースです。通常、modRDN操作は比較的高速です(ただし、リーフ・エントリのみの変更に関係する場合)。
フィルタと一致する属性値を持つディレクトリ情報ツリーの指定した点以下にあるすべてのディレクトリ・エントリを検索します。
検索フィルタには、1つ以上の属性の特性を指定できます。たとえば、苗字がJensenのエントリを検索するには、LDAPフィルタ(sn=Jensen)を使用します。苗字がJensenでユーザーIDが文字Bで始まるエントリを検索するには、LDAPフィルタ(&(sn=Jensen)(uid=b*))を使用します。
操作の実行が終了したら、クライアントをバインド解除できます。バインド解除後、クライアントとサーバーによって接続が切断されます。クライアント・アプリケーションは、時間がかかり過ぎている検索などの操作も中止できます。
Directory Serverは、多くのクライアント接続を同時に処理できます。接続を処理するために、Directory Serverは、空いているファイル記述子を消費し、多数のスレッドを管理します。サーバー構成を使用して、Directory Serverで使用可能なシステム・リソースを制限できます。詳細は、『Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』の第6章「システム特性のチューニングとハードウェアのサイズ指定」を参照してください。
Directory Serverは、サーバー・インスタンスの構成データをファイルに格納しますが、構成データにはLDAPを介してアクセスすることもできます。
instance-path以下に格納されるファイルは次のとおりです。Directory Serverは、LDAPスキーマ(どのディレクトリ・エントリを含むことができるかを定義)をinstance-path/config/schema/に格納します。スキーマに関する参照情報は、Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスを、スキーマの管理手順は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第11章「Directory Serverのスキーマ」を参照してください。Directory Serverは、その他の構成情報をdse.ldifファイルであるinstance-path/config/dse.ldifに格納します。このファイルは手動で更新しないでください。
LDAPを介して、スキーマ情報はcn=schemaで利用できます。その他の構成情報はcn=configで利用できます。実際は、cn=configディレクトリ以下のデータは通常更新しません。かわりに、WebベースのDirectory Service Control Centerまたはdsconfコマンドを使用します。Directory Service Control Centerおよびdsconfコマンドはどちらも、LDAPを介してDirectory Serverを変更します。さらに、これらを使用することで、LDAP変更操作を使用した複雑な構成の調整の多くを行わずに済みます。
ほとんどすべてのDirectory Server製品のドキュメントは、Directory Serverの構成に焦点を当てています。『Oracle Directory Server Enterprise Edition管理者ガイド』では、コマンドライン構成ツールを使用した多様なタスクを完了するための詳細な方法が記載されています。Directory Service Control Centerのオンライン・ヘルプは、Directory Service Control Centerのインタフェースで直感的な理解が難しいような場合に、正しい手順に戻るのに役立ちます。
Directory Serverは、ディレクトリ・データを保存するために多数のバイナリツリー・データベースを管理します。デフォルトでは、データベース・ファイルはinstance-path/db/以下に格納されます。通常、これらのファイルは変更または移動しません。
instance-path/db/ディレクトリの内容を確認すると、データベース・ログ・ファイルが見つかります。また、サーバーが管理する各データベースにはサブディレクトリもあります。たとえば、instance-path/db/example/には、dc=example,dc=comにあるディレクトリ・エントリ用のデータが保存されています。このファイルを確認すると、苗字属性値のexample_sn.db3などの多数のデータベース索引があることがわかります。example_id2entry.db3ファイルには、ディレクトリ・エントリ情報が含まれていることもわかります。必要に応じて、これらのファイルの情報を暗号化するようにDirectory Serverを構成できます。
クライアント・アプリケーションの観点から、Directory Serverは、ディレクトリ情報ツリーに配置されたディレクトリ・エントリとして格納されたディレクトリ・データを表示します。Directory Serverは、エントリをすばやく取得するために、属性値索引を使用します。Directory Serverが保持する索引を構成できます。
ディレクトリ・データのバックアップ手順については、『Oracle Directory Server Enterprise Edition管理者ガイド』の第8章「Directory Serverのバックアップとリストア」を参照してください。索引の構成手順については、『Oracle Directory Server Enterprise Edition管理者ガイド』の第12章「Directory Serverの索引作成」を参照してください。ディレクトリ・データのバックアップおよび索引の構成は、Directory Service Control Centerを使用して行うこともできます。
ディレクトリ情報ツリー(DIT)は、クライアント・アプリケーションがデータを参照できるようにディレクトリ・データを構成する方法を提供します。
適切に構成されたDITは、次を提供します。
簡略化されたディレクトリ・データの保持
レプリケーション・ポリシーおよびアクセス制御の作成での柔軟性
ディレクトリを使用するアプリケーションに対するサポート
ユーザーに対する簡略化されたディレクトリ・ナビゲーション
DIT構成は、階層化LDAPモデルに従います。たとえばDITは、データをグループごと、人ごとまたは地理的な場所ごとに編成します。また、複数のサーバー全体でのデータのパーティション化の方法についても定義します。
DIT設計は、レプリケーション構成およびデータを分散するためのDirectory Proxy Serverの使用方法にも影響を与えます。DITの一部をレプリケートまたは分散する場合は、設計時に、Directory Proxy Serverのレプリケーションおよび要件を検討します。さらに、設計時に、ブランチ・ポイントでのアクセス制御が必要かどうかについても決定します。
DITは、サフィックス、サブサフィックスおよび結合されたサフィックスを単位として定義されます。サフィックスは、コンテンツ全体が管理タスクの単位として処理されるブランチまたはサブツリーです。索引作成はサフィックス全体に定義され、サフィックス全体は単一操作で初期化できます。また、サフィックスは通常、レプリケーションの単位です。同じ方法でアクセスおよび管理する必要のあるデータは、同じサフィックスにある必要があります。サフィックスはディレクトリ・ツリーのルートに配置でき、ここはルート・サフィックスと呼ばれます。
データはサフィックス・レベルでのみパーティション化できるため、複数のサーバー間にデータを分散するには、適切なディレクトリ・ツリー構造が必要です。
次の図に、2つのルート・サフィックスを持つディレクトリを示します。それぞれのサフィックスは、異なる企業のエンティティを表します。
サフィックスは、別のサフィックスのブランチである場合があり、その場合、これはサブサフィックスと呼ばれます。親サフィックスには、管理操作用にサブサフィックスの内容は含まれません。サブサフィックスは、その親とは独立して管理されます。LDAP操作によって、サフィックスに関する情報が含まれないため、ディレクトリ・クライアントは、エントリがルート・サフィックスの一部なのかサブサフィックスの一部なのかを認識しません。
次の図に、大規模な企業エンティティの1つのサフィックスと複数のサブサフィックスを持つディレクトリを示します。
サフィックスは、サーバー内の個々のデータベースに対応します。ただし、データベースおよびそのファイルは、サーバーによって内部的に管理され、データベース用語は使用されません。
カスケード・チェーンの特別な場合では、結合されたサフィックスはリモート・サーバー上などの別の結合されたサフィックスを参照する場合があります。各サーバーが操作を転送し、最終的にクライアントのリクエストを処理するサーバーに結果が戻されます。
Directory Serverでは、必要な数のサーバー・インスタンス間でディレクトリ・データをレプリケートできます。Directory Serverのレプリケーションは、1つのサーバーから別のサーバーへ更新操作をリプレイするLDAP拡張操作として動作します。Directory Serverのレプリケーションのプロトコルは、ネットワーク間ですばやく動作するために最適化されています。また、このプロトコルは、2つの異なるサーバー・インスタンスで同じデータが同時に変更された場合の競合を解消するために最適化されています。
Directory Serverのレプリケーションの単位はサフィックスです。2つのサーバー間のレプリケーション承諾は、dc=example,dc=comなどのディレクトリ情報ツリーのベース・エントリの下にあるすべてのディレクトリ・エントリを処理します。レプリケーションのための各承諾は、ポイント間で設定されます。一方では、ポイント間の承諾は、ネットワークがパーティション化されているときにレプリケーションが単一点障害にならないようにします。他方で、ポイント間の承諾は、レプリカの数が増えると管理が複雑になります。幸いにも、Directory Service Control Centerでは、その複雑性の多くが処理されます。Directory Service Control Centerでは、共通ディレクトリ・サービスを提供するレプリカのグループを管理できます。
タイミング、優先度およびレプリケートするデータを構成できます。また、更新と参照の両方を受け入れるために、一部のサーバー(マスターと呼ばれる)も構成できます。参照のみを受け入れるためのその他のサーバー(コンシューマと呼ばれる)を構成できます。さらに、更新が発生したときに追従する必要のあるクライアント・アプリケーションに対して、LDAPを介して更新情報を公開できます。レプリケーションの詳細は、第7章「Directory Serverのレプリケーション」を参照してください。レプリケーションの構成手順については、『Oracle Directory Server Enterprise Edition管理者ガイド』の第10章「Directory Serverのレプリケーション」を参照してください。
Directory Serverでは、ディレクトリ・エントリに配置されたaci属性を使用して機能するアクセス制御メカニズムが提供されます。ACIは、アクセス制御命令を表します。
ACIは、ユーザーのバインド・アイデンティティに基づいて評価されます。したがってACIは、ディレクトリにバインド可能なすべてのユーザーに対して評価できます。また、ACIは、バインド資格証明を提供していない匿名ユーザーに対しても適用できます。バインド・アイデンティティについてのルールでは、どのユーザーかだけでなく、ユーザーの接続元システム、1日のうちの接続時間帯または使用する認証方式も指定できます。
有効範囲内のエントリに適用するためにACIを構成します。有効範囲内に存在できるエントリには、ACIを保持するエントリで始まるディレクトリ情報ツリーのブランチ上にあるエントリが含まれます。Directory Serverでは、多数の異なる基準に従って適用されるACIを構成できます。また、Directory Serverでは、アクセスを許可するためだけでなく、アクセスを拒否するためにもACIを構成できます。
ACIは、許可および拒否する操作を指定できます。たとえば、通常は多数のユーザーによる情報の読取りを許可しますが、ごくわずかのユーザーに対してのみディレクトリ・データの更新および追加を許可します。
Directory Serverのアクセス制御の詳細は、「Directory Serverのアクセス制御の提供方法」を参照してください。アクセス制御の構成手順については、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」を参照してください。
