eDirectory設計規則
ネットワークの設計と実装で最も重要な作業は、eDirectoryツリーの設計です。ツリーの設計には、次の作業が含まれます。
オブジェクト名などの標準名を規定すると、ユーザと管理者の両方が、ネットワークをより直感的に理解できるようになります。書き出された標準では、管理者による、電話番号や住所などの他のプロパティ値の設定方法も指定できます。
ディレクトリの検索とブラウズでは、名前やプロパティ値の整合性が重要になります。
カントリオブジェクトは、2文字の標準ISOカントリコードに従って命名します。
NetWare(R) 2またはNetWare 3からバインダリサービス経由でオブジェクトにアクセスする場合は、次の制限が適用されます。
重要: バインダリエミュレーションは、Linux*またはSolaris*プラットフォームではサポートされていません。
複数の言語で稼動しているワークステーションがある場合は、必要に応じて、オブジェクト名に使用する文字を、すべてのワークステーションで表示できる文字のみに制限します。たとえば、ワークステーションを日本語環境で使用している場合には、ヨーロッパの言語で表示できない文字を名前に使用しないよう制限します。
重要: Tree名は必ず英語で指定するようにします。
次は、最もよく使用される一部のプロパティに関する標準ドキュメントの例です。使用しないプロパティについては、標準を規定する必要はありません。標準ドキュメントは、オブジェクトの作成または修正を担当するすべての管理者に配布します。
表 13. 標準ドキュメントの例
ツリーの上位層を変更するとツリーの残りの部分すべてに影響するため、ツリーの上位層は慎重に設計します。WANリンクがある場合は、特に注意する必要があります。ツリーの最上部は、後からの変更がなるべく必要でないように設計します。
eDirectoryツリーの作成時には、次のeDirectory設計規則に従います。
「図 1」は、eDirectory設計規則を示しています。
図 1
eDirectory設計規則
ツリーの上位層の作成方法については、『ConsoleOneユーザガイド』の「オブジェクトの作成と操作」を参照してください。
ピラミッド型のeDirectoryでは、管理や、大きなグループに対する変更、および論理パーティションの作成をより容易に実行できます。
ピラミッド型以外の設計として、フラットツリー型があります。この場合、すべてのオブジェクトがツリーの最上部に置かれます。eDirectoryをフラットツリー型に設計することも可能ですが、管理やパーティション化がより難しくなります。
ほとんどの組織では、ツリーを1つにするのが最適です。デフォルトでは、ツリーは1つだけ作成されます。ツリーが1つだけだと、ネットワーク内のユーザの識別を統一でき、セキュリティ管理もより容易になります。また、1箇所で集中管理できます。
業務では単一のツリーの使用を推奨しますが、追加のツリーのテストや開発を否定するわけではありません。
組織によっては、法的または政治的な問題、あるいは社内の事情から、複数のツリーが必要になる場合もあります。たとえば、自立した7つの組織から構成される組織では、7つのツリーが必要になることも考えられます。組織で複数のツリーが必要な場合は、DirXMLを使用して管理を容易化することを検討してください。DirXMLの詳細については、『DirXML管理ガイド』を参照してください。
ツリーには、他のツリー名と重複しない、固有の名前を付けます。「EDL-TREE」のように、短くてわかりやすい名前を指定します。
同じネットワーク内に同じ名前のツリーが存在すると、次のような問題が発生する場合があります。
ツリー名は、DSMERGEユーティリティで変更できますが、変更は十分に注意して行ってください。ツリー名の変更はネットワーク全体に影響します。ツリー名を変更した場合は、新しいツリー名でクライアントを再設定する必要があります。
通常、1つのeDirectoryツリーには、1つの組織オブジェクトを作成します。デフォルトでは、組織オブジェクトが1つ作成され、それに会社名に基づいた名前が付けられます。これにより、会社全体に適用される変更をツリー内の1個所から設定できます。
たとえば、ZENworksTMを使用して、組織オブジェクトの下に、ワークステーションインポートポリシーオブジェクトを作成できます。このポリシーは、eDirectory内にワークステーションオブジェクトを作成するときの命名方法を定義するもので、組織全体に影響します。
組織コンテナには、次のオブジェクトが作成されます。
eDirectoryが実行されているWindows*NT*サーバのみを含むネットワークには、ボリュームオブジェクトはありません。
次のようなケースでは、組織オブジェクトを複数作成することが必要になる場合があります。
第1レベルの部門設計は、eDirectoryの効率性とパーティション化に影響するため重要です。
LANまたはWANを使用して複数のビルや場所などにまたがって構成されているネットワークでは、所在地に基づいて第1レベルの部門オブジェクトを設計します。これにより、1つのパーティション内のすべてのオブジェクトが1箇所に維持されるように、eDirectoryを分割できます。また、各場所でのセキュリティの設定や管理者の割り当ても容易になります。
ツリーの下位層は、ネットワークリソースの編成に基づいて設計します。eDirectoryツリーの下位層の設計は同じ場所に存在するオブジェクトにのみ影響するため、下位層は上位層よりも自由に設計できます。
ツリーの下位層の作成方法については、『ConsoleOneユーザガイド』の「オブジェクトの作成と操作」を参照してください。
作成する下位層のコンテナオブジェクトの数は、ツリー内のオブジェクトの総数、空きディスク容量、およびディスクの入出力速度制限によって決まります。eDirectoryは、1つのeDirectoryツリー内に10億以上のオブジェクトを格納できることがテストで確認されているため、実際の制約項目は、空きディスク容量とディスクの入出力速度、およびパフォーマンスを維持するためのRAMです。大規模なツリーの場合は、レプリカの同期処理の影響を考慮します。
eDirectory内の一般的なオブジェクトのサイズは3〜5KBです。この数値に基づいて、現在保持している、または新たに作成するすべてのオブジェクトの保管に必要な空きディスク容量をすばやく計算できます。オブジェクトのサイズは、データに付属する属性の数や、データの内容に対応して大きくなります。画像やサウンド、または生物統計学などのBLOB(2進ラージオブジェクト)データを格納するオブジェクトの場合、そのサイズは増加します。
パーティションのサイズが大きくなるほど、レプリケーションのサイクルは遅くなります。ZENworksやDNS/DHCPサービスなど、eDirectoryの使用を必要とする製品を使用する場合、これらの製品によって作成されたeDirectoryオブジェクトにより、格納先のコンテナのサイズが影響を受けます。場合によっては、DNS/DHCPなど、管理目的のみで使用するオブジェクトは固有のパーティションに格納することを検討します。パーティションを別にすれば、レプリカの同期処理の速度の低下によってユーザのアクセスが支障をきたすことを避けることができます。また、パーティションとレプリカの管理も容易になります。
必要な場合は、eDirectoryデータベースまたはDIB(ディレクトリ情報ベース)セットのサイズを簡単に判別できます。
通常、同じ必要性からアクセスされるeDirectoryオブジェクトをまとめて格納するコンテナを作成します。それにより、1つのトラスティ割り当てまたはログインスクリプトで多くのユーザにサービスを提供できます。特にログインスクリプトをより効率的にすることを目的としてコンテナを作成できるほか、1つのコンテナに2つの部署を割り当てることによって、ログインスクリプトの管理をより容易にすることもできます。
ネットワーク内のトラフィックを制限するため、ユーザは各自が必要とするリソースの近くに配置するようにします。たとえば、同じ部署で働く社員は、通常、隣り合った位置で作業します。それらの社員は同じファイルシステムにアクセスし、同じプリンタを使用して印刷します。
一般的なワークグループ境界の例外については、容易に対処できます。たとえば、2つのワークグループが共通のプリンタを使用するような場合は、一方のワークグループのプリンタに対して別名オブジェクトを作成します。グループオブジェクトを作成することによって、1つのワークグループ内だけでなく、複数のワークグループに存在する一部のユーザオブジェクトをまとめて管理できます。また、固有のログインスクリプト要件を持つ、一部のユーザ用のプロファイルオブジェクトも作成できます。
