test

Sun Directory Services 3.1 管理ガイド

第 3 章 ディレクトリサービスの計画

この章では、構成要素の構成を始める前に、ディレクトリサービス全般について決めておかなければならないことを説明します。

考慮すべき項目には、次のものがあります。

情報の種類

ディレクトリに格納する情報の種類を定義する必要があります。スキーマには、この情報を格納するのに必要なオブジェクトクラスと属性が含まれていなければなりません。デフォルトのスキーマでは十分でない場合は、「スキーマの変更」に、必要なオブジェクトクラスと属性を作成する方法が説明されています。

デフォルトのスキーマには、次のようなリソースの情報を格納できます。

デフォルトのスキーマでディレクトリに作成できるすべてのオブジェクトのリストについては、「オブジェクトクラスのリファレンス」を参照してください。

ディレクトリエントリに記述するリソースの特性に合ったオブジェクトクラスを探す場合には、次の点に注意してください。

たとえば、XYZ Corporation 独自のオンラインディレクトリに、次の情報が社員ごとに入っているとします。

デフォルトスキーマの場合、社員ごとにこれらすべての属性を格納できるオブジェクトクラスは inetOrgPerson です。このオブジェクトクラスには、電子メールアドレスを格納するための任意のメール属性があります。このオブジェクトクラスは、organizationalPerson と Person オブジェクトクラスから属性を継承します。これらのオブジェクトクラスには、社員の氏名、電話番号、役職を格納するために必要な属性が備わっています。

名前付きコンテキストの作成

ディレクトリに格納する情報の種類を定義したら、情報をどのような名前付きコンテキストに分割するかを決める必要があります。分割する基準としては、次のものが考えられます。

情報を名前付きコンテキストに分割する基準は、情報の場所とは無関係に定義できます。名前付きコンテキストのどの部分でもネットワークの任意のサーバーに複製できるからです。

ただし、リソースのマスターエントリはディレクトリに 1 つだけでなければなりません。複数あると、1 つの情報リポジトリを持つという大きな利点が失われます。

例: XYZ Corporation の名前付きコンテキスト

XYZ Corporation は、米国のボストンに本社がある国際的な薬品会社です。ボストンとロンドンに 1 箇所ずつ製造拠点があります。また、ニューヨークとパリに研究グループがあり、それぞれにはマーケティングと営業部門も置かれています。香港にも営業オフィスがあります。米国関係はボストン、ヨーロッパとその他の地域はロンドンでそれぞれ人事部門を管理しています。

図 3-1 は、XYZ Corporation の機能的な構造を示しています。

図 3-1 XYZ Corporation の機能構造

Graphic

図 3-2 は、XYZ Corporation の地理的な構造を示しています。

図 3-2 XYZ Corporation の地理的な構造

Graphic

XYZ Corporation の主要な機能がいろいろな場所にあるため、組織的なディレクトリ情報ツリー構造も機能的な ディレクトリ情報ツリー構造もこの会社のディレクトリ構造の要件を完全には満たしません。さらに、XYZ Corporation は、NIS ネーミングサービスを使って、メールユーザーとネットワークリソースに関する情報を集中的に管理しています。この情報は会社の運営にとって不可欠であるため、ネットワーク管理チームは、組織や地理的な区分とは無関係にこの情報を集中的に管理したいと思っています。しかし、重要性が比較的低く、頻繁に更新される可能性のある情報については、場所ごとに保守を行なってもよいと思っています。たとえば、ネットワークアクセスサーバーを経由してネットワークにリモートアクセスすることを許可されたユーザーの情報がこれにあたります。

その結果、ディレクトリ情報ツリー構造は図 3-3 のようになります。

図 3-3 XYZ Corporation のディレクトリ情報ツリー構造

Graphic

この ディレクトリ情報ツリー構造では、会社は、10 の名前付きコンテキストに対応する 6 つの組織単位 (ou) と 4 つの場所 (l) に分割されています。表 3-1 に、各名前付きコンテキストの相対識別名と識別名を格納するサーバーを示します。表 3-2 には、他のサーバーに複製される名前付きコンテキストのマスターサーバーを示します。

サーバーにおける情報の配置

作成する名前付きコンテキストをネットワークのどのサーバーに格納するかを決める必要があります。考慮すべき制約には次のものがあります。

ネットワークによる制約やユーザーのニーズを考慮して、情報をどこに格納するかを決めます。この際、情報がサーバー間で重複してもかまいません。この重複は、複製方針を設定する際に解決されます。

たとえば、XYZ Corporation には、香港を除き、それぞれの場所にディレクトリサーバーがあるものとします。表 3-1 は、各サーバーの名前付きコンテキストを示しています。

表 3-1 XYZ Corporation における名前付きコンテキストの場所

サーバー 

名前付きコンテキスト 

boston 

ou=XYZ, c=US 

ou=People, ou=XYZ, c=US 

ou=Services, ou=XYZ, c=US 

ou=HR, ou=XYZ, c=US 

newyork 

l=New-York, ou=XYZ, c=US 

ou=US-RD, ou=XYZ, c=US 

ou=Eur-RD, ou=XYZ, c=US 

ou=Sales-Mktg, ou=XYZ, c=US 

london 

l=London, ou=XYZ, c=US 

ou=People, ou=XYZ, c=US 

ou=Services, ou=XYZ, c=US 

ou=HR, ou=XYZ, c=US 

paris 

l=Paris, ou=XYZ, c=US 

ou=Eur-RD, ou=XYZ, c=US 

ou=US-RD, ou=XYZ, c=US 

ou=Sales-Mktg, ou=XYZ, c=US 

複製方針の設定

複製方針を設定する際には、同じ情報を置く場所の数を明らかにし、マスターコピーを持つ場所を決め、最も効率的なサーバー間の複製プロセスを定義します。

単純複製と階層式複製

同じ情報を持つ場所が 2 つある場合は、1 つのマスターと 1 つのスレーブからなる単純複製です。同じ情報を持つ場所が 3 つ以上ある場合は、1 つのマスターと複数のスレーブからなる単純複製か、階層式複製を使用できます。

階層式複製では、情報の複製がいくつかのレベルで起こります。つまり、スレーブサーバーの複製コピーがさらに別のスレーブに複製されます。多くの場所で情報を複製する場合には、階層式複製を使うと、複製の負荷が最初のレベルのスレーブサーバーに分散されるため、マスターサーバーから出されるネットワークトラフィックが少なくなるという利点があります。

複製方式

Sun Directory Services の複製は、LDAP プロトコルに基づいて行われます。ただし、Sun Directory Services のサーバーで NIS サービスが使用できるようになっていると、このサーバーと従来の NIS サーバーの間で NIS 複製を行うことができます。

Sun Directory Services の NIS 複製機能を使うと、従来の NIS ネーミングサービスから、統合されたネーミングおよびディレクトリサービスに容易に移行できます。

LDAP 複製には、NIS 複製に比べ次の利点があります。

したがって、NIS サーバーとして使用しているいくつかのサーバーに Sun Directory Services 製品をインストールする場合は、NIS 複製の代わりに LDAP 複製を使用してください。詳細は、「NIS サービスの構成」を参照してください。

マスターサーバーとスレーブサーバーの間で変更を伝播するための複製モードには、次の 2 つがあります。

注意 - 注意 -

同じ環境に LDAP v2 サーバーと LDAP v3 サーバーがある場合には、LDAP v3 サーバーから LDAP v2 サーバーに複製を行なったときに、LDAP v3 固有の情報が失われることがあります。たとえば、複製する情報が属性内の言語タグを使用する場合には、すべての複製ターゲットで LDAP v3 がサポートされていなければなりません。Sun Directory Services 1.0 から Sun Directory Services 3.1 への移行の詳細は、『Sun Directory Services 3.1 ご使用にあたって』を参照してください。

例: XYZ Corporation における複製

表 3-1 では、XYZ Corporation の一部の名前付きコンテキストがいくつかのサーバーに置かれていることがわかります。これは、情報を地域に限定することでアクセスを速くし、接続コストを減らすためです。

1 つのサーバーにマスターコピーを持ち、その他のサーバーには複製を持ちます。

表 3-2 は、XYZ Corporation ディレクトリサービスの各名前付きコンテキストがどのように複製されるかを示しています。

表 3-2 XYZ Corporation の複製方針

名前付きコンテキスト 

マスターサーバー 

スレーブサーバー 

ou=People, ou=XYZ, c=US 

boston 

london 

ou=Services, ou=XYZ, c=US 

boston 

london 

ou=HR, ou=XYZ, c=US 

boston 

london 

l=Boston, ou=XYZ, c=US 

boston 

 

l=New-York, ou=XYZ, c=US 

newyork 

 

ou=US-RD, ou=XYZ, c=US 

newyork 

paris 

ou=Sales-Mktg, ou=XYZ, c=US 

newyork 

paris 

l=London, ou=XYZ, c=US 

london 

 

l=Paris, ou=XYZ, c=US 

paris 

 

ou=Eur-RD, ou=XYZ, c=US 

paris 

newyork 

マスターサーバーとスレーブサーバーの間で変更を複製するための複製方式は LDAP です。

照会

照会システムでは、エントリがそのサーバーにないと、ディレクトリサーバーは、照会をクライアントに戻し、別のディレクトリサーバーに照会するよう要求します。ほとんどの LDAP クライアントライブラリは、照会に従ってユーザーの元の要求を自動的に出し直します。

Sun Directory Services に照会を定義する方法には次の 2 つがあります。

デフォルト照会はディレクトリサーバーごとに構成時に設定するパラメータで、別の「ディレクトリサーバー」へのポインタです。通常、照会先のサーバーは、検索の範囲を広げるために、現在のサーバーよりも高いディレクトリ情報ツリーのノードを持ちます。

照会エントリは、ディレクトリ情報ツリーのどのレベルにでも作成できます。このエントリでは、別の「データ格納」にあるディレクトリ情報ツリーのサブツリーを指します。照会エントリの値は URL です。

注 -

LDAP v3 サーバーから LDAP v2 サーバーへの照会は作成しないでください。最初の要求が LDAP v3 サーバーに出された場合、ほとんどのライブラリは、LDAP v2 サーバーへの照会に対応できません。

データ格納には最高 100 万エントリまで格納できますが、この制約を解決する方法として照会エントリが使用できます。その場合、ルートエントリのすぐ下に照会エントリを持つデータ格納を作成できます。これらのエントリは、同じサーバーまたは異なるサーバーの別のデータ格納に格納されている広域ディレクトリ情報ツリーのサブツリーを指します。

この仕組みを図 3-4 に示します。

図 3-4 100 万エントリを持つディレクトリ内の照会

Graphic

newyork、london、paris の各サーバーは、boston サーバーにあるデータ格納 o=XYZ, c=US へのデフォルト照会を持っています。boston サーバーには、次の 3 つの照会エントリがあります。

照会エントリには、次の属性を指定します。

たとえば、l=New-York, ou=XYZ, c=US という照会エントリには、次のように指定します。 

DN: l=New-York, ou=xyz,c=US
objectClass: referral
ref: ldap://newyork/ou=New-York,ou=XYZ,c=US
l: New-York

l=New-York, ou=XYZ, c=US ツリーの検索が失敗した場合、LDAP プロトコルはデフォルト照会に従って ou=XYZ, c=US ツリーを検索します。ou=XYZ, c=US ツリーの検索が始まると、LDAP プロトコルは、照会エントリに指定された URL に従って参照先のすべてのデータ格納を検索します。