eDirectoryツリーの設計

ネットワークの設計と実装で最も重要な作業は、eDirectoryツリーの設計です。ツリーの設計には、次の作業が含まれます。


命名標準ドキュメントを作成する

オブジェクト名などの標準名を規定すると、ユーザと管理者の両方が、ネットワークをより直感的に理解できるようになります。書き出された標準では、管理者による、電話番号や住所などの他のプロパティ値の設定方法も指定できます。

ディレクトリの検索とブラウズでは、名前やプロパティ値の整合性が重要になります。

また、標準的な名前を使用することで、Novell Nsure Identity Managerでは、eDirectoryとその他のアプリケーションの間でデータを容易に移動することもできます。Novell Nsure Identity Managerの詳細については、『DirXML 管理ガイド』を参照してください。


命名規則


オブジェクト
  • コンテナ内では、重複する名前を使用することはできません。たとえば、同じコンテナ内でDebra JonesとDaniel Jonesの両方に「DJONES」という名前を付けることはできません。
  • 特殊文字を使用できます。ただし、プラス記号(+)、等号(=)、およびピリオド(.)を使用する場合は、直前に円記号(\)を入力する必要があります。サーバオブジェクトと国オブジェクトのほか、バインダリサービスおよび多言語環境には、追加の命名規則が適用されます。
  • 大文字と小文字、およびアンダースコアとスペースは、入力時にはそのまま表示されますが、実際には区別されません。たとえば、「Manager_Profile」と「MANAGER PROFILE」は同一と見なされます。
  • 名前をコマンドラインやログインスクリプトに入力するときにスペースを使用する場合は、名前全体を引用符で囲む必要があります。

サーバオブジェクト
  • 新しいサーバをインストールすると、サーバオブジェクトが自動的に作成されます。
  • 既存のNetWare(R)やNTサーバ、および他のツリーのeDirectoryサーバに対して、追加のサーバオブジェクトを作成できますが、それらはすべてバインダリオブジェクトとして扱われます。
  • サーバオブジェクトを作成するとき、その名前は物理サーバ名と一致していなければなりません。また、サーバ名には次の規定があります。
    • ネットワーク全体で固有である
    • 2〜47文字の長さである
    • A〜Zまでの文字、0〜9までの数字、ハイフン(-)、ピリオド(.)、およびアンダースコア(_)のみを含む
    • 最初の文字にピリオドを使用しない
  • 一度付けたサーバオブジェクト名は、iManagerで変更することはできません。サーバで名前を変更すると、新しい名前が自動的にiManagerに表示されます。

国オブジェクト

国オブジェクトは、2文字の標準ISOカントリコードに従って命名します。

詳細については、ISO 3166 Code Listsを参照してください。


バインダリオブジェクト

NetWare 2またはNetWare 3からバインダリサービス経由でオブジェクトにアクセスする場合は、次の制限が適用されます。

  • 名前に使用されているスペースは、アンダースコアに置き換えられる。
  • 名前は47文字で切り捨てられる。
  • 次の文字は使用できない。スラッシュ(/)、円記号(\)、コロン(:)、コンマ(,)、アスタリスク(*)、および疑問符(?)。

重要:  バインダリエミュレーションは、Linux、Solaris、AIX、HP-UXプラットフォームではサポートされていません。


多言語環境の注意事項

複数の言語で稼動しているワークステーションがある場合は、必要に応じて、オブジェクト名に使用する文字を、すべてのワークステーションで表示できる文字のみに制限します。たとえば、ワークステーションを日本語環境で使用している場合には、ヨーロッパの言語で表示できない文字を名前に使用しないよう制限します。

HP-UXは英語のみをサポートします。

重要:  Tree名は必ず英語で指定するようにします。


標準ドキュメントの例

次は、最もよく使用される一部のプロパティに関する標準ドキュメントの例です。使用しないプロパティについては、標準を規定する必要はありません。標準ドキュメントは、オブジェクトの作成または修正を担当するすべての管理者に配布します。

オブジェクトクラス | プロパティ [標準] 理由

ユーザ | ログイン名

ファーストネームのイニシャル、ミドルネームのイニシャル(ある場合)、姓の組み合わせ(すべて小文字)。最大8文字です。各共通名はすべて、社内全体で固有のものにします。

msmith、bjohnson

eDirectoryでは会社全体で固有の名前を使用する必要はありませんが、固有にすると、同じコンテキスト(またはバインダリコンテキスト)内での不整合を避けることができます。

ユーザ | 姓

姓(通常の大文字/小文字表記)。

Smith

メールラベルの生成に使用されます。

電話番号およびFax番号

ハイフンで区切られた番号。

米国:123-456-7890
その他: 44-344-123456

自動ダイヤルソフトウェアで使用されます。

複数のクラス | 地域

2文字の地域コード(大文字)、ハイフン、メール配達地点の組み合わせ。

BA-C23

社内のメール配達で使用されます。

組織 | 名前

すべてのツリーに与える会社名。

YourCo

独立したツリーがある場合、標準の組織名を使用することで、将来ツリーのマージができます。

部門 | 名前(地域に基づく)

2または3文字の地域コードで、すべて大文字。

ATL、CHI、CUP、LA、BAT、BOS、DAL

短く、標準的な名前を使用することで、効率的に検索できます。

部門 | 名前(部署に基づく)

部署名または略語。

Sales、Eng

短く、標準的な名前を使用することで、どの部署で使用しているコンテナか見分けやすくなります。

グループ | 名前

識別名。

Project Managers

ユーティリティによってはすべて表示できない場合があるため、極端に長い名前は避けます。

ディレクトリマップ | 名前

ディレクトリマップが示すディレクトリの内容。

DOSAPPS

短く、標準的な名前を使用することで、どの部署で使用しているコンテナか見分けやすくなります。

プロファイル | 名前

プロファイルの目的。

MobileUser

短く、標準的な名前を使用することで、どの部署で使用しているコンテナか見分けやすくなります。

サーバ | 名前

SERV、ハイフン、部署、ハイフン、固有番号の組み合わせ。

SERV-Eng-1

eDirectoryでは、ツリー内で固有のサーバ名を使用する必要があります。


Treeの上位層を設計する

ツリーの上位層を変更するとツリーの残りの部分すべてに影響するため、ツリーの上位層は慎重に設計します。WANリンクがある場合は、特に注意する必要があります。ツリーの最上部は、後からの変更がなるべく必要でないように設計します。

eDirectoryツリーの作成時には、次のeDirectory設計規則に従います。

図 21は、eDirectory設計規則を示しています。

図 21
eDirectory設計規則

ツリーの上位層を作成するには、オブジェクトを作成するおよびオブジェクトのプロパティを変更するを参照してください。


ピラミッド型の設計の使用

ピラミッド型のeDirectoryでは、管理や、大きなグループに対する変更、および論理パーティションの作成をより容易に実行できます。

ピラミッド型以外の設計として、フラットツリー型があります。この場合、すべてのオブジェクトがツリーの最上部に置かれます。eDirectoryをフラットツリー型に設計することも可能ですが、管理やパーティション化がより難しくなります。


固有の名前を持つ単一のeDirectoryツリーの使用

ほとんどの組織では、ツリーを1つにするのが最適です。デフォルトでは、ツリーは1つだけ作成されます。ツリーが1つだけだと、ネットワーク内のユーザの識別を統一でき、セキュリティ管理もより容易になります。また、1箇所で集中管理できます。

業務では単一のツリーの使用を推奨しますが、追加のツリーのテストや開発を否定するわけではありません。

組織によっては、法的または政治的な問題、あるいは社内の事情から、複数のツリーが必要になる場合もあります。たとえば、自立した7つの組織から構成される組織では、7つのツリーが必要になることも考えられます。組織で複数のツリーが必要な場合は、Novell Nsure Identity Managerを使用して管理を容易化することを検討してください。Novell Nsure Identity Managerの詳細については、『DirXML 管理ガイド』を参照してください。

注:  HP-UXはNovell Nsure Identity Managerをサポートしていません。

ツリーには、他のツリー名と重複しない、固有の名前を付けます。「EDL-TREE」のように、短くてわかりやすい名前を指定します。

同じネットワーク内に同じ名前のツリーが存在すると、次のような問題が発生する場合があります。

  • 更新内容が、対象のツリーとは別のツリーに適用される
  • リソースが消失する
  • 権利が消失する
  • データが破損する

ツリー名は、DSMergeユーティリティで変更できますが、変更は十分に注意して行ってください。ツリー名の変更はネットワーク全体に影響します。ツリー名を変更した場合は、新しいツリー名でクライアントを再設定する必要があります。


単一の組織オブジェクトの作成

通常、1つのeDirectoryツリーには、1つの組織オブジェクトを作成します。デフォルトでは、組織オブジェクトが1つ作成され、それに会社名に基づいた名前が付けられます。これにより、会社全体に適用される変更をツリー内の1個所から設定できます。

たとえば、ZENworks(R)を使用して、組織オブジェクトの下に、ワークステーションインポートポリシーオブジェクトを作成できます。このポリシーは、eDirectory内にワークステーションオブジェクトを作成するときの命名方法を定義するもので、組織全体に影響します。

組織コンテナには、次のオブジェクトが作成されます。

  • 管理者
  • サーバ
  • ボリューム

    eDirectoryが実行されているWindows、Linux、Solaris、AIX、またはHP-UXサーバのみを含むネットワークには、ボリュームオブジェクトはありません。

次のようなケースでは、組織オブジェクトを複数作成することが必要になる場合があります。

  • 複数の会社から構成される企業で、それぞれの会社が個別にネットワークを構成している。
  • 社内で、独立した業務単位または組織を表す必要がある。
  • 各部門が独立した形態をとることを規定する社内ガイドラインやポリシーがある。


物理的なネットワークを表す部門を作成する

第1レベルの部門設計は、eDirectoryの効率性とパーティション化に影響するため重要です。

LANまたはWANを使用して複数のビルや場所などにまたがって構成されているネットワークでは、所在地に基づいて第1レベルの部門オブジェクトを設計します。これにより、1つのパーティション内のすべてのオブジェクトが1箇所に維持されるように、eDirectoryを分割できます。また、各場所でのセキュリティの設定や管理者の割り当ても容易になります。


ツリーの下位層を設計する

ツリーの下位層は、ネットワークリソースの編成に基づいて設計します。eDirectoryツリーの下位層の設計は同じ場所に存在するオブジェクトにのみ影響するため、下位層は上位層よりも自由に設計できます。

ツリーの下位層を作成するには、オブジェクトを作成するおよびオブジェクトのプロパティを変更するを参照してください。


コンテナ、ツリー、およびデータベースのサイズを決定する

作成する下位層のコンテナオブジェクトの数は、ツリー内のオブジェクトの総数、空きディスク容量、およびディスクの入出力速度制限によって決まります。eDirectoryは、1つのeDirectoryツリー内に10億以上のオブジェクトを格納できることがテストで確認されているため、実際の制約項目は、空きディスク容量とディスクの入出力速度、およびパフォーマンスを維持するためのRAMです。大規模なツリーの場合は、レプリカの同期処理が大きく影響することにも注意が必要です。

eDirectory内の一般的なオブジェクトのサイズは3〜5KBです。この数値に基づいて、現在保持している、または新たに作成するすべてのオブジェクトの保管に必要な空きディスク容量をすばやく計算できます。オブジェクトのサイズは、データに付属する属性の数や、データの内容に対応して大きくなります。画像やサウンド、または生物統計学などのBLOB(バイナリラージオブジェクト)データを格納するオブジェクトの場合、そのサイズは増加します。

パーティションのサイズが大きくなるほど、レプリケーションのサイクルは遅くなります。ZENworksやDNS/DHCPサービスなど、eDirectoryの使用を必要とする製品を使用する場合、これらの製品によって作成されたeDirectoryオブジェクトにより、格納先のコンテナのサイズが影響を受けます。場合によっては、DNS/DHCPなど、管理目的のみで使用するオブジェクトは固有のパーティションに格納することを検討します。パーティションを別にすれば、レプリカの同期処理の速度の低下によってユーザのアクセスが支障をきたすことを避けることができます。また、パーティションとレプリカの管理も容易になります。

必要な場合は、eDirectoryデータベースまたはDIB(ディレクトリ情報ベース)セットのサイズを簡単に判別できます。

  • NetWareの場合は、Novell Support Webサイトからtoolbox.nlmをダウンロードして、サーバ上のsys:_netwareディレクトリを表示します。
  • Windowsの場合は、\novell\nds\dibfilesにあるDIBセットを参照します。
  • Linux、Solaris、AIX、またはHP-UXの場合は、インストール時に指定したディレクトリにあるDIBセットを参照してください。


作成するコンテナを決定する

通常、同じ必要性からアクセスされるeDirectoryオブジェクトをまとめて格納するコンテナを作成します。それにより、1つのトラスティ割り当てまたはログインスクリプトで多くのユーザにサービスを提供できます。特にログインスクリプトをより効率的にすることを目的としてコンテナを作成できるほか、1つのコンテナに2つの部署を割り当てることによって、ログインスクリプトの管理をより容易にすることもできます。

ネットワーク内のトラフィックを制限するため、ユーザは各自が必要とするリソースの近くに配置するようにします。たとえば、同じ部署で働く社員は、通常、隣り合った位置で作業します。それらの社員は同じファイルシステムにアクセスし、同じプリンタを使用して印刷します。

一般的なワークグループ境界の例外については、容易に対処できます。たとえば、2つのワークグループが共通のプリンタを使用するような場合は、一方のワークグループのプリンタに対して別名オブジェクトを作成します。グループオブジェクトを作成することによって、1つのワークグループ内だけでなく、複数のワークグループに存在する一部のユーザオブジェクトをまとめて管理できます。また、固有のログインスクリプト要件を持つ、一部のユーザ用のプロファイルオブジェクトも作成できます。