ネットワークの設計と実装で最も重要な作業は、eDirectoryツリーの設計です。ツリーの設計には、次の作業が含まれます。
オブジェクト名などの標準名を規定すると、ユーザと管理者の両方が、ネットワークをより直感的に理解できるようになります。書き出された標準では、管理者による、電話番号や住所などの他のプロパティ値の設定方法も指定できます。
ディレクトリの検索とブラウズでは、名前やプロパティ値の整合性が重要になります。
また、標準的な名前を使用することで、NetIQ Identity ManagerはeDirectoryとその他のアプリケーションの間でデータを容易に移動できます。Identity Managerの詳細については、『NetIQ Identity Manager Setup Guide (NetIQ Identity Managerセットアップガイド)』を参照してください。
コンテナ内で一意の名前にします。たとえば、同じコンテナ内でDebra JonesとDaniel Jonesの両方に「DJONES」という名前を付けることはできません。
特殊文字を使用することもできます。ただし、プラス記号(+)、等号(=)、およびピリオド(.)を使用する場合は、直前に円記号(\)を入力する必要があります。サーバオブジェクトとカントリオブジェクト、およびバインダリサービスと多言語環境には、追加の命名規則が適用されます。
大文字と小文字、およびアンダースコアとスペースは、入力時にはそのまま表示されますが、実際には区別されません。 たとえばManager_ProfileとMANAGER PROFILEは同一と見なされます。
名前をコマンドラインやログインスクリプトに入力するときにスペースを使用する場合は、名前全体を引用符で囲む必要があります。
新しいサーバをインストールすると、サーバオブジェクトが自動的に作成されます。
既存のWindowsサーバ、および他のツリー内のeDirectoryサーバに対して、追加のサーバオブジェクトを作成できますが、それらはすべてバインダリオブジェクトとして扱われます。
サーバオブジェクトを作成するとき、その名前は物理サーバ名と一致していなければなりません。また、サーバ名には次の規定があります。
ネットワーク全体で固有である
2~47文字の長さである
A~Zまでの文字、0~9までの数字、ハイフン(-)、ピリオド(.)、およびアンダースコア(_)のみを含む
最初の文字にピリオドを使用しない
一度付けたサーバオブジェクト名をNetIQ iManagerで変更することはできません。サーバで名前を変更すると、新しい名前が自動的にiManagerに表示されます。
複数の言語で稼動しているワークステーションがある場合は、必要に応じて、オブジェクト名に使用する文字を、すべてのワークステーションで表示できる文字のみに制限します。たとえば、ワークステーションを日本語環境で使用している場合には、ヨーロッパの言語で表示できない文字を名前に使用しないよう制限します。
重要:Tree名は必ず英語で指定するようにします。
次は、最もよく使用される一部のプロパティに関する標準ドキュメントの例です。使用しないプロパティについては、標準を規定する必要はありません。標準ドキュメントは、オブジェクトの作成または修正を担当するすべての管理者に配布します。
|
オブジェクトクラス | プロパティ |
Standard |
例 |
理由 |
|---|---|---|---|
|
ユーザ | ログイン名 |
ファーストネームのイニシャル、ミドルネームのイニシャル(ある場合)、姓の組み合わせ(すべて小文字)。最大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では、ツリー内で固有のサーバ名を使用する必要があります。 |
ツリーの上位層を変更するとツリーの残りの部分すべてに影響するため、ツリーの上位層は慎重に設計します。WANリンクがある場合は、特に注意する必要があります。ツリーの最上部は、後からの変更がなるべく必要でないように設計します。
eDirectoryツリーの作成時には、次のeDirectory設計規則に従います。
ピラミッド型の設計を使用する。
eDirectoryツリーは1つにし、固有の名前を付ける。
組織オブジェクトを1つ作成する。
物理的なネットワーク構造を表す第1レベルの部門群を作成する。
図 2-1は、eDirectory設計規則を示しています。
図 2-1 eDirectory設計規則
ツリーの上位層を作成するには、オブジェクトを作成するおよびオブジェクトのプロパティの変更を参照してください。
ピラミッド型のeDirectoryでは、管理や、大きなグループに対する変更、および論理パーティションの作成をより容易に実行できます。
ピラミッド型の代わりに使用できる設計として、フラットツリー型があります。フラットツリー型では、すべてのオブジェクトがツリーの最上部に置かれます。eDirectoryではフラットツリー型の設計もできますが、管理やパーティション化がより難しくなる可能性があります。
ほとんどの組織では、ツリーを1つにするのが最適です。デフォルトでは、ツリーは1つだけ作成されます。ツリーが1つだけだと、ネットワーク内のユーザの識別を統一でき、セキュリティ管理もより容易になります。また、1箇所で集中管理できます。
業務では単一のツリーの使用を推奨しますが、追加のツリーのテストや開発を否定するわけではありません。
組織によっては、法的または政治的な問題、あるいは社内の事情から、複数のツリーが必要になる場合もあります。たとえば、自立した7つの組織から構成される組織では、7つのツリーが必要になることも考えられます。組織で複数のツリーが必要な場合は、管理を容易にするためにNetIQ Identity Managerを使用することを検討してください。Identity Managerの詳細については、『NetIQ Identity Manager Setup Guide (NetIQ Identity Managerセットアップガイド)』を参照してください。
ツリーには、他のツリー名と重複しない、固有の名前を付けます。「EDL-TREE」のように、短くてわかりやすい名前を指定します。
同じネットワーク内に同じ名前のツリーが存在すると、次のような問題が発生する場合があります。
更新内容が、対象のツリーとは別のツリーに適用される
リソースが消失する
権利が消失する
データが破損する
DSMergeユーティリティを使用してツリー名を変更できますが、変更する際には十分に注意する必要があります。ツリー名の変更はネットワーク全体に影響します。ツリー名を変更した場合は、新しいツリー名でクライアントを再設定する必要があります。
通常、1つのeDirectoryツリーには、1つの組織オブジェクトを作成します。デフォルトでは、組織オブジェクトが1つ作成され、それに会社名に基づいた名前が付けられます。これにより、会社全体に適用される変更をツリー内の1個所から設定できます。
たとえば、ZENworks®を使用して、組織オブジェクトの中にワークステーションインポートポリシーオブジェクトを作成できます。このポリシーは、eDirectory内にワークステーションオブジェクトを作成するときの命名方法を定義するもので、組織全体に影響します。
組織コンテナには、次のオブジェクトが作成されます。
Admin
サーバ
ボリューム
eDirectoryを実行しているWindowsまたはLinuxサーバのみを含むネットワークには、ボリュームオブジェクトがありません。
次のようなケースでは、組織オブジェクトを複数作成することが必要になる場合があります。
複数の会社から構成される企業で、それぞれの会社が個別にネットワークを構成している。
社内で、独立した業務単位または組織を表す必要がある。
各部門が独立した形態をとることを規定する社内ガイドラインやポリシーがある。
第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(ディレクトリ情報ベース)セットのサイズを簡単に判別できます。
Windowsの場合は、\novell\nds\dibfilesにあるDIBセットを確認します。
Linuxの場合は、インストール時に指定したディレクトリにあるDIBセットを確認します。
通常、同じ必要性からアクセスされるeDirectoryオブジェクトをまとめて格納するコンテナを作成します。それにより、1つのトラスティ割り当てまたはログインスクリプトで多くのユーザにサービスを提供できます。特にログインスクリプトをより効率的にすることを目的としてコンテナを作成できるほか、1つのコンテナに2つの部署を割り当てることによって、ログインスクリプトの管理をより容易にすることもできます。
ネットワーク内のトラフィックを制限するため、ユーザは各自が必要とするリソースの近くに配置するようにします。たとえば、同じ部署で働く社員は、通常、隣り合った位置で作業します。それらの社員は同じファイルシステムにアクセスし、同じプリンタを使用して印刷します。
一般的なワークグループ境界の例外については、容易に対処できます。たとえば、2つのワークグループが共通のプリンタを使用するような場合は、一方のワークグループのプリンタに対して別名オブジェクトを作成します。グループオブジェクトを作成することによって、1つのワークグループ内だけでなく、複数のワークグループに存在する一部のユーザオブジェクトをまとめて管理できます。また、固有のログインスクリプト要件を持つ、一部のユーザ用のプロファイルオブジェクトも作成できます。