|
| |
| Sun Java™ System Directory Server 5 2004Q2 配備計画ガイド | |
第 5 章
分散、連鎖、およびリフェラル第 4 章「ディレクトリ情報ツリー」 では、Directory Server がエントリを格納する方法について説明します。Directory Server は膨大な数のエントリを格納できるので、エントリを複数のサーバーに分散して配置しなければならない場合があります。ディレクトリのトポロジは、ディレクトリツリーをどのように複数の物理的な Directory Server に分割するか、およびこれらのサーバーをどのように相互にリンクするかを示します。
この章では、データの分散、連鎖、およびリフェラルを使用してディレクトリデータをより効率的に管理する方法を説明します。この章は、次の節から構成されています。
トポロジの概要分散ディレクトリは、複数の物理的な Directory Server に分散されているディレクトリツリーにあるディレクトリです。ディレクトリをこのように分割することで、次のことが可能になります。
ディレクトリが複数のサーバーに分割されている場合、各サーバーはディレクトリツリーの一部分だけを処理します。分散されたディレクトリの動作は、DNS ネームスペースの各部分を特定の DNS サーバーに割り当てるドメインネームサービス (DNS) に似ています。同様に、ディレクトリのネームスペースを複数のサーバーに分散し、クライアント側からは単一のディレクトリツリーとして管理させることができます。
Directory Server には、異なるデータベースに格納されているディレクトリデータをリンクするために、リフェラルと連鎖のメカニズムも用意されています。サフィックスは、レプリケーション、バックアップ、データの復元などの作業の基本単位です。この章では、サフィックス、リフェラル、連鎖について、およびディレクトリのパフォーマンスの向上のためにインデックスを設計する方法について説明します。
データの分散データを分散すると、すべてのディレクトリのエントリを社内の各サーバー上に格納することなく、ディレクトリを複数のサーバーインスタンスにわたって拡張できます。サーバーインスタンスは、パフォーマンス要件を満たすために複数のマシンに格納することができます。そのため、分散型ディレクトリは、1 つのサーバーで保持できる数よりはるかに多くのエントリを保持できます。
また、分散されていることがユーザーやクライアントアプリケーションからは見えないようにディレクトリを設定することもできます。ディレクトリクライアントに関する限り、単一のディレクトリがそのディレクトリへのクエリに応答します。
次に、データ分散のしくみについて詳しく説明します。
複数のデータベースの使用
Directory Server はデータを LDBM データベースに格納します。LDBM データベースはディスクベースの高パフォーマンスデータベースです。各データベースは、割り当てられたすべてのデータを含む大きなファイルのセットから構成されます。ディレクトリツリーの異なる部分を別々のデータベースに格納できます。たとえば、図 5-1 のような 3 つのサブサフィックスを含むディレクトリツリーがあるとします。
図 5-1 3 つのサブサフィックスを持つディレクトリツリー
ツリーにある 3 つのサブサフィックスのデータを、図 5-2 のように 3 つの異なるデータベースに格納できます。
図 5-2 3 つの異なるデータベースに格納された 3 つのサブサフィックス
ディレクトリツリーを多数のデータベースに分割すると、それらのデータベースを複数のサーバーに分散できます。通常は、パフォーマンスの向上のために複数のマシンにインストールされた複数のデータベースに分散します。上の図で示した 3 つのデータベースは、図 5-3 に示すように 2 つのサーバー上に格納できます。
図 5-3 2 つのサーバー A、B に格納された Example.com の 3 つのデータベース
データベースを複数のサーバーに分散すると、各サーバーが処理しなければならない作業量を削減できます。このようにして、1 つのサーバーで保持できる数よりもはるかに多いエントリに対応するようにディレクトリを拡張できます。また、Directory Server ではデータベースをダイナミックに追加できるので、ディレクトリ全体をオフラインにしなくても、必要に応じて新しいデータベースを追加できます。
サフィックスについて
各データベースには Directory Server のサフィックスにあるデータが格納されます。サフィックスとサブサフィックスの両方を作成して、ディレクトリツリーの内容を編成できます。サフィックスはツリーのルートにあるエントリです。これは、ディレクトリツリー全体のルートか、または大きなツリーの一部である可能性があります。
サブサフィックスは、サフィックスの下にある分岐です。サブサフィックスは、ディレクトリデータの分散を表します。
たとえば、Example.com のディレクトリツリーは図 5-4 のようになります。
図 5-4 Example.com のディレクトリツリー
図 5-5 に示すように、Example.com がディレクトリツリーを 5 つの異なるデータベースに分割するとします。
図 5-5 5 つのデータベースに分割された Example.com 社のディレクトリツリー
o=NetscapeRoot と dc=Example,dc=com はどちらもサフィックスです。それ以外の ou=testing,dc=Example,dc=com、ou=development,dc=Example,dc=com、ou=partners,ou=development,dc=Example,dc=com は、dc=Example,dc=com サフィックスのサブサフィックスです。サフィックス dc=Example,dc=com には、元のディレクトリツリーの分岐である ou=marketing のデータが含まれます。
この分割により、サフィックスとサブサフィックスは図 5-6 のようにエントリを格納します。
図 5-6 Example.com 社のサフィックスと関連エントリ
ディレクトリには複数のサフィックスを持たせることができます。たとえば、ExampleISP.com という ISP が複数の Web サイトをホスティングし、1 つが独自の Web サイトである ExampleISP.com、もう 1 つが HostedExample.com という別の Web サイトであると仮定します。ISP は、すべてを格納する 1 つのサフィックスを作成するか、同社がホスティングする部分と ExampleISP.com 社の社内データのために 2 つの異なるサフィックスを作成するかを選択できます。
すべてのデータを 1 つのサフィックスに格納するソリューションでは、ディレクトリ情報ツリーは図 5-7 のようになります。
図 5-7 1 つのサフィックスを持つ ExampleISP.com 社のディレクトリツリー
ISP が、1 つはその独自の命名コンテキストに対応し、もう 1 つはそれがホスティングする組織に対応する 2 つのサフィックスを作成した場合、ディレクトリ情報ツリーは次のようになります。
図 5-8 2 つのサフィックスを持つ ExampleISP.com 社のディレクトリツリー
ホスティングされる各組織のエントリ (o=Example と o=HostedExample) は o=ISP サフィックスのサブサフィックスで、ou=people と ou=groups はホスティングされる各組織のサブサフィックスとして分岐します。
リフェラルと連鎖データが複数のサフィックスに分散されている場合は、分散したデータ間の関係を定義する必要があります。これは、別々のサフィックスに保持されているディレクトリ情報へのポインタを使用して行います。Directory Server には、分散されたデータを単一のディレクトリツリーとしてリンクするために、リフェラルと連鎖というメカニズムが用意されています。
次に、2 つのメカニズムをより詳細に比較します。
リフェラルの使用方法
リフェラルはサーバーが返す情報であり、操作要求を完了するために接続する必要があるサーバーをクライアントアプリケーションに指示します。Directory Server は、次の 3 種類のリフェラルをサポートしています。
すべてのリフェラルは、LDAP URL (Uniform Resource Locator) の形式で返されます。次に、LDAP リフェラルの構造と、Directory Server がサポートする 3 つのタイプのリフェラルについて説明します。
LDAP リフェラルの構造
LDAP リフェラルには LDAP URL 形式の情報が含まれます。LDAP URL には、次の情報が含まれます。
たとえば、クライアントアプリケーションが Jensen という姓を持つエントリを dc=Example,dc=com 内で検索するとします。リフェラルは、次の LDAP URL をクライアントアプリケーションに返します。
ldap://europe.Example.com:389/ou=people,l=europe,dc=Example,dc=com
リフェラルは、LDAP ポート 389 のホスト europe.Example.com に接続し、ou=people,l=europe,dc=Example,dc=com にルート設定された検索要求を送信するように、クライアントアプリケーションに指示します。
リフェラルがどのように処理されるかは、LDAP クライアントアプリケーションによって決まります。一部のクライアントアプリケーションは、参照先サーバーに対して自動的に操作を再実行します。別のクライアントアプリケーションは、ユーザーにリフェラル情報を返します。コマンド行ユーティリティなど、Directory Server が提供するほとんどの LDAP クライアントアプリケーションは、自動的にリフェラルを実行します。参照先サーバーへのアクセスには、最初のサーバー要求で指定したバインド証明情報が使用されます。
ほとんどのクライアントアプリケーションは、リフェラルの制限数、あるいはホップ数だけリフェラルを実行します。実行するリフェラル数を制限すると、クライアントアプリケーションがディレクトリ検索要求を完了しようとして費やす時間を短縮でき、また循環リフェラルパターンが原因で発生する処理停止を防ぐのにも役に立ちます。
デフォルトリフェラル
Directory Server は、要求されたディレクトリオブジェクトの DN とローカルサーバーでサポートされているディレクトリサフィックスを比較して、デフォルトリフェラルを返すかどうかを決めます。DN とサポートされているサフィックスが一致しない場合、Directory Server はデフォルトリフェラルを返します。
たとえば、ディレクトリクライアントが次のディレクトリエントリを要求したとします。
uid=bjensen,ou=people,dc=Example,dc=com
ところが、サーバーは dc=europe,dc=Example,dc=com サフィックスの下に格納されているエントリしか管理していません。このような場合、ディレクトリは、dc=Example,dc=com サフィックスに格納されているエントリを取得するために接続する必要があるサーバーを示すリフェラルをクライアントに返します。デフォルトリフェラルを受け取ったクライアントは適切なサーバーに接続して、元の要求を再送信します。
デフォルトリフェラルは、ディレクトリの分散に関する情報をより多く保持している Directory Server を指すように設定します。サーバーのデフォルトリフェラルは、dse.ldif 設定ファイルに格納されている nsslapd-referral 属性で設定します。
デフォルトリフェラルの設定については、『Directory Server 管理ガイド』の第 2 章にある「デフォルトリフェラルの設定」を参照してください。
サフィックスリフェラル
サフィックスを完全に無効にすることなくサフィックスへのアクセスを制限するには、アクセス権を変更して、読み取り専用アクセスを許可することもできます。この場合、書き込み操作に対しては、別のサーバーへのサフィックスリフェラルを定義する必要があります。また、読み取りアクセスと書き込みアクセスの両方を拒否し、サフィックスへのすべての操作に対するリフェラルを定義することもできます。さらに、サフィックスリフェラルを使用して、クライアントアプリケーションが一時的に別のサーバーを使用するように設定することもできます。たとえば、サフィックスにリフェラルを追加しておくことにより、サフィックスの内容のバックアップ中に、クライアントが別のサーバーを使用するように設定できます。
米国内に 2 つの主要サイトがあり、1 つはニューヨーク、もう 1 つはロサンゼルスに基盤を置いていると仮定します。クライアントアプリケーションは、ニューヨークのサイトを次のように照会します。
uid=bjensen,ou=people,dc=US,dc=Example,dc=com
サフィックスリフェラルを dc=NewYork,dc=US,dc=Example,dc=com と設定することで、dc=NewYork サブツリーを含むサフィックスによって要求が処理されるようになります。
サフィックスリフェラルは、そのサフィックスのマッピングツリーエントリに含まれる nsslapd-state および nsslapd-referral 属性によって設定されます。nsslapd-referral 属性は、サフィックスが返す LDAP URL を指定します。nsslapd-state 属性は、次の 4 つの値のいずれかをとることができます。
- nsslapd-state: backend: すべての操作はこのサフィックスによって処理される
- nsslapd-state: disabled: このサフィックスは処理には利用できず、クライアントからの要求に応答してエラーを返す
- nsslapd-state: referral: このサフィックスに対するすべての要求に対してリフェラルが返される
- nsslapd-state: referral on update: すべての操作に対してこのサフィックスが使用され、更新要求に対してはリフェラルが返される。referral on update 状態は、レプリケーションが設定された場合に、コンシューマが更新要求を処理しないように内部的に使用される。ただし、ロードバランスとパフォーマンスのために、特定のサフィックスでの読み取り操作へのアクセスの制限にも、この状態を使用できる
サフィックスリフェラルの設定については、『Directory Server 管理ガイド』の第 3 章にある「アクセス権とリフェラルの設定」を参照してください。
スマートリフェラル
また、Directory Server は、ディレクトリのエントリまたはディレクトリツリーを特定の LDAP URL に関連付けることができる、「スマートリフェラル」もサポートしています。ディレクトリのエントリを特定の LDAP URL に関連付けると、次のいずれかに要求を転送できます。
デフォルトリフェラルとは異なり、スマートリフェラルはディレクトリ自体に格納されます。
たとえば、Example.com の米国支社のディレクトリに、ou=people,dc=Example,dc=com というディレクトリ分岐点があるとします。
ou=people エントリ自体にスマートリフェラルを指定することで、この分岐への要求をすべて Example.com のヨーロッパ支社の ou=people 分岐に転送できます。このスマートリフェラルは、次のようになります。
ldap://europe.Example.com:389/ou=people,dc=Example,dc=com
米国支店のディレクトリにある people 分岐への要求はすべて、ヨーロッパのディレクトリに転送されます。図 5-9 は、このようなスマートリフェラルを示しています。
図 5-9 米国のディレクトリからヨーロッパのディレクトリへのスマートリフェラル
同じメカニズムを使用して、異なるネームスペースを使っている別のサーバーにクエリを転送できます。たとえば、Example.com のイタリア支社の従業員がヨーロッパのディレクトリに米国の Example.com 社員の電話番号を要求したとします。ディレクトリは次のリフェラルを返します。
ldap://europe.Example.com:389/ou=US employees,dc=Example,dc=com
同じサーバー上に複数のサフィックスを設定している場合は、あるネームスペースから同じマシン上の別のネームスペースにクエリを転送できます。ローカルマシン上の o=Example,c=us に対するすべてのクエリを dc=Example,dc=com に転送する場合は、o=Example,c=us エントリに次のスマートリフェラルを設定します。
ldap:///dc=Example,dc=com
図 5-10 を参照してください。
図 5-10 スマートリフェラルのトラフィック
1 つのネームスペースからのクエリを同一マシン上の別のネームスペースに転送するため、通常は URL に指定される host:port の情報ペアを指定する必要はありません。URL にこの情報ペアが指定されていないため、同じ Directory Server を指す URL には 3 つのスラッシュが含まれます。
LDAP URL の詳細については、『Directory Server Administration Reference』の「LDAP URL」を参照してください。Directory Server のエントリにスマート URL を含める方法については、『Directory Server 管理ガイド』の第 2 章にある「スマートリフェラルの作成」を参照してください。
スマートリフェラルを設計する際のヒント
スマートリフェラルを使用するときは、次の点を考慮してください。
複雑に交錯したリフェラルは、ディレクトリの管理を難しくします。また、スマートリフェラルを使いすぎると、循環リフェラルパターンを引き起こしてしまう場合もあります。この場合、リフェラルがある LDAP URL を指し、その LDAP URL が別の LDAP URL を指すといったことが、連鎖のどこかで最後に元のサーバーに戻ってしまうまで続くという状況になります。図 5-11 は、循環リフェラルのパターンを示しています。
図 5-11 スマートリフェラルの使いすぎによる循環リフェラルのパターン
連鎖の使用方法
連鎖は要求を別のサーバーに中継する手法の 1 つです。この手法は連鎖サフィックスを介して実行されます。「データの分散」で説明しているように、連鎖サフィックスにはデータは含まれません。連鎖サフィックスは、クライアントアプリケーションの要求をデータがあるリモートサーバーに転送します。
連鎖時に、サーバーは格納されていないデータに対する要求をクライアントアプリケーションから受け取ります。サーバーは連鎖サフィックスを使用して、クライアントアプリケーションの代わりに他のサーバーにアクセスし、結果をクライアントアプリケーションに返します。図 5-12 は、この処理を示しています。
図 5-12 連鎖による処理
各連鎖サフィックスは、データを保持しているリモートサーバーに関連付けられています。障害が発生したときに連鎖サフィックスが使用する、データのレプリカが入った代替リモートサーバーを設定することもできます。連鎖サフィックスの設定については、『Directory Server 管理ガイド』の第 3 章にある「連鎖サフィックスの作成」を参照してください。
連鎖サフィックスには次の機能があります。
連鎖サフィックスは、クライアントアプリケーションに代わって該当する認証情報をリモートサーバーに提示します。アクセス制御を評価する必要がない場合は、リモートサーバーに対するユーザー代行機能を無効にすることができます。アクセス制御と連鎖サフィックスの関係については、『Directory Server 管理ガイド』の第 3 章にある「連鎖サフィックスのアクセス制御」を参照してください。
リフェラルと連鎖の選択
分割されたディレクトリ部分をリンクする場合、どちらの手法にも利点と欠点があります。ディレクトリの要件に応じて、どちらか一方、あるいは両方を組み合わせて使用します。
リフェラルと連鎖の大きな違いは、分散された情報の検索方法を認識するための情報が置かれている場所です。連鎖システムでは、この情報がサーバー内に実装されます。リフェラルを使用するシステムでは、この情報はクライアントアプリケーション内に実装されます。
連鎖では、クライアント側の処理は簡単になりますが、その分サーバー側の処理が複雑になります。連鎖対象のサーバーは、リモートサーバーと協調して結果をディレクトリクライアントに送信する必要があります。
リフェラルでは、クライアントがリフェラルを検索して検索結果を照合する必要があります。ただし、連鎖よりもリフェラルを使用した方がクライアントアプリケーションを柔軟に作成でき、開発者は分散型ディレクトリの進行状況をより適切な形でユーザーにフィードバックできます。
次に、リフェラルと連鎖の違いについて詳しく説明します。
使用方法の違い
リフェラルをサポートしないクライアントアプリケーションもあります。連鎖を使用すると、クライアントアプリケーションは 1 つのサーバーと通信するだけで、多数のサーバーに格納されているデータにアクセスすることができます。企業のネットワークがプロキシを使用している場合は、リフェラルが機能しないことがあります。たとえば、クライアントアプリケーションがファイアウォール内の 1 つのサーバーとだけ通信する権限を持っているとします。クライアントアプリケーションが別のサーバーに転送された場合、クライアントはそのサーバーに正常に接続できません。
また、リフェラルでは、クライアントを認証する必要があります。つまり、クライアントの転送先のサーバーにクライアントの証明情報が格納されている必要があります。連鎖では、クライアント認証は 1 回だけで済みます。要求の連鎖先のサーバーでクライアントを再び認証する必要はありません。
アクセス制御の評価
連鎖は、リフェラルとは異なる方法でアクセス制御を評価します。リフェラルでは、バインド DN エントリがすべての転送先サーバー上に存在しなければなりません。連鎖では、クライアントエントリがすべての転送先サーバー上に存在している必要はありません。
たとえば、クライアントが検索要求をサーバー A に送信する場合を考えてみます。図 5-13 は、リフェラルを使用した場合の動作を示しています。
図 5-13 リフェラルによって転送されるクライアントアプリケーションの検索要求
この図では、クライアントアプリケーションは次の手順を実行します。
- クライアントアプリケーションは、まずサーバー A にバインドします。
- サーバー A は、ユーザー名とパスワードを提供するクライアントのエントリを保持しているので、バインド受け入れメッセージを返します。リフェラルが機能するためには、サーバー A にクライアントエントリが存在する必要があります。
- クライアントアプリケーションがサーバー A に操作要求を送信します。
- しかし、サーバー A には要求された情報が格納されていません。サーバー A は、代わりにリフェラルをクライアントアプリケーションに返し、サーバー B へのアクセスを指示します。
- クライアントアプリケーションが、バインド要求をサーバー B に送信します。サーバーへのバインドに成功するには、サーバー B にクライアントアプリケーションのエントリが存在する必要があります。
- バインドに成功したので、クライアントアプリケーションは再び検索操作をサーバー B に送信できます。
この方法では、サーバー A からレプリケートされたクライアントエントリのコピーがサーバー B に必要です。
連鎖では、この問題は発生しません。図 5-14 は、連鎖を使用した場合の検索要求の動作を示しています。
図 5-14 連鎖を使用した検索要求
この図では、次の手順が実行されます。
- クライアントアプリケーションがサーバー A にバインドし、サーバー A はユーザー名とパスワードが正しいことを確認しようとします。
- サーバー A にはクライアントアプリケーションに対応するエントリが存在しません。その代わりに、サーバー A にはクライアントの実際のエントリがあるサーバー B への連鎖サフィックスがあります。サーバー A はバインド要求をサーバー B に送信します。
- サーバー B はサーバー A にバインド受け入れメッセージを返信します。
- サーバー A は連鎖サフィックスを使用してクライアントアプリケーションからの要求を処理します。連鎖サフィックスはサーバー B にあるリモートデータストアに接続して検索操作を処理します。
連鎖システムでは、クライアントアプリケーションに対応するエントリが、クライアントが要求するデータと同じサーバー上にある必要はありません。図 5-15 は、クライアントからの検索要求を処理するために、2 つの連鎖サフィックスを使用する方法を示しています。
図 5-15 クライアントからの検索要求を処理するために 2 つの連鎖サフィックスを使用する連鎖
図 5-15 では、次の手順が実行されます。
- クライアントアプリケーションがサーバー A にバインドし、サーバー A はユーザー名とパスワードが正しいことを確認しようとします。
- サーバー A にはクライアントアプリケーションに対応するエントリが存在しません。その代わりに、サーバー A にはクライアントの実際のエントリがあるサーバー B への連鎖サフィックスがあります。サーバー A はバインド要求をサーバー B に送信します。
- サーバー B はサーバー A にバインド受け入れメッセージを返信します。
- サーバー A は別の連鎖サフィックスを使用してクライアントアプリケーションからの要求を処理します。連鎖サフィックスはサーバー C にあるリモートデータストアに接続して検索操作を処理します。
ただし、連鎖サフィックスは、次のアクセス制御をサポートしません。
