この特集のトップページへ

Directory first step 6... ディレクトリサービス製品
sankaku.gif ディレクトリ構造

 ディレクトリ構造は,ディレクトリサービスの使い勝手を決めるうえでも重要なポイントとなる。組織の統廃合が頻繁な今日のビジネス環境では,ディレクトリ構造の統廃合も頻繁となるからである。

 NDSやNetscape Directory Serverは,1つのrootから枝分かれした,X.500準拠の論理階層ディレクトリ構造を採用している。つまり,ディレクトリツリーは,組織(O),組織ユニット(OU),一般名(CN)で構成された論理的な階層で構築される。複数のディレクトリをマージし,さらに大きな1つのディレクトリツリーを構築することも可能である。一般的には,たとえば会社などの事業組織ごとに1つの論理階層ディレクトリが構築される。この場合,事業組織が大きくなれば,ディレクトリの管理スパンも大きくなるので,管理負担が増える可能性もある。もちろん,それより小さな組織や機能でディレクトリ構造を構築することも可能である。しかしいずれにせよ,組織全体を反映するディレクトリ構造は避けるべきであろう。そうしないと,組織の併合や分離のたびにディレクトリ構造を変えなければならず,管理負担が増してしまう。NDSやNetscape Directory Serverにおけるディレクトリ構造の特徴として,ネットワークの物理構造とディレクトリの論理構造が独立している点が挙げられる。このため,Active Directoryの場合と異なり,DNSネームスペースと無関係に組織ユニット(OU)を設定することができる。

Fig.16 NDSのディレクトリ構造
fig16.gif

 これに対してActive Directoryは,「ドメイン」を単位とするツリー構造をとる。ドメインを単位としたディレクトリ構造を集めることで,「ドメインツリー」と呼ばれる,より大きなディレクトリ構造を作成することもできる。さらに,ディレクトリツリー同士を結合させ,「フォレスト」と呼ばれる,さらに大きなディレクトリ構造を形成することも可能である。従来Windows NTで採用されていたNTドメインは,それぞれ対等でフラットなディレクトリ構造を採用していたが,Active Directoryのドメインは上下関係のある階層構造を形成できるようになっている。この点で,1つの大きなディレクトリ構造を採用しているNDSやNetscape Directory Serverと比較すると,Active Directoryはディレクトリを段階的に構築する場合にも柔軟に対応できるし,管理負担も少なくなる可能性がある。

Fig.17 Active Directoryのディレクトリ構造
fig17.gif

 しかし,Active Directoryのドメインは,NTドメインの概念を一部引きずっていることにも注意しなければならない。Windows NTで採用されていたNTドメインは,もともとOS/2のLAN Managerの時代に登場したものであり,複数のファイルサーバーが備えるユーザー管理情報を一元管理するために提供されていた。NTドメインでは,ドメインコントローラがユーザーを集中管理し,残りのサーバーはドメインコントローラの管理情報を参照するだけだったので,歴史的にいくつかの問題点が指摘されてきた(『徹底レビュー!! Windows 2000 Server』の「Active Directoryの概要」を参照)。Windows 2000のActive Directoryは,NTドメインで指摘されていたいくつかの問題点を解決するために設計されたディレクトリサービスである。

 ここでは詳しく言及しないが,たしかに,Active Directoryを導入することで,NTドメインで指摘されてきた問題点の多くは改善される。だが,Active Directoryの場合には,階層構造をとり得る「ドメイン」と,ドメインの内部で階層構造を形成する「組織単位(OU)」という2つの階層構造でディレクトリ全体を構成することになるため,環境を構築または運用するうえでは注意を要する。特に,Active Directory環境を構築または運用するうえで柔軟性を欠く一因となりかねないのは,「ネットワークの物理構造(というより,DNSのドメインやサブドメインの構造)を完全に無視してディレクトリを構築できない」という点である。Active Directoryのディレクトリツリー構造は,DNSネームスペースそのものである(ディレクトリツリーの構造=DNSネームスペース)。このため,Active Directoryでは,DNSネームスペースによってディレクトリツリーの構造が制限され,ディレクトリを自由に構成するという柔軟性にやや欠ける場面があり得る。

 たとえば,最近のようにビジネス環境にスピードと変化が求められている状況では,企業の組織構造も短期間でめまぐるしく変化する。この場合,もし組織構造に対応したドメインを作成してディレクトリを構築してしまったとすると,組織構造が変更されるたびにDNSネームスペースまで改変しなければならなくなる。だが,現実問題として,そのような運用は難しい。むしろ,インターネットなどの外部ネットワークと接続されている場合には,組織構造が変更されたからといって,いったん決定されたDNSネームスペースを改変することは,あまりないはずである。実務上は,電子メールアドレスなどの問題もあって,組織が変更されても旧組織のドメイン名やサブドメイン名をそのまま使用し続けることも多い。この点,Active Directoryでは厳格な設計を求められる分だけ,従来の実務的な視点から見ると,やや使いづらく感じるかもしれない。

 この問題を回避する最善策は,組織構造に基づいてドメインを分割しないように心がけることである。つまり,組織構造のように変更頻度の高いオブジェクトは,ドメインの境界にするのではなく,ドメインの内部にある組織単位の境界にする。いい換えれば,Active Directoryにおけるディレクトリ構築においては,「上位レベルのディレクトリツリー」をActive Directoryのドメインツリーに,「下位レベルのディレクトリツリー」を各ドメイン内の組織単位に,それぞれ対応させることで,論理的なディレクトリ境界を物理的にも分割するのである。また,低速なWAN回線を経由するなど,物理的なネットワーク構造の制限からドメインを分割したいときでも,ドメインを分割するのではなく,できるだけサイトで分割する。

 Active DirectoryにせよNDSにせよ,ディレクトリ構造の設計においては,

  1. 組織構造をそのままディレクトリ構造に対応させるのは極力避ける(地域や機能,役割などで構成する),
  2. 上位レベルのディレクトリツリーにはなるべく変動の少ない静的なオブジェクトを格納する,
  3. ディレクトリの分岐はできるだけ少なくする(できるだけ単純にする),
ことが重要である。Active Directoryの場合には,さらに,
  1. 外部向けDNSと内部向けDNS(Active Directory対応DNS)で分離する,
  2. できるだけシングルドメインにする(マルチドメインにするとしても,ドメインには「上位レベルのディレクトリツリー」を対応させる),
ことがポイントになるだろう。

prevpg.gif Directory first step(後編) 7/14 nextpg.gif