RSS
 |
|
by Tom Zeller
Designing Novell Directory Services
NDS System Design Trade Offs | |||
| Design Parameter to Optimize | Pros | Cons | |
|---|---|---|---|
| Minimize WAN Bandwidth Use | network operations happy | Reduces login performance | |
| Fault Tolerance | Provides a robust system | Creates additional network traffic from replication; consumes server CPU | |
| User Login Performance | Keeps users happy | Creates additional network traffic from replication; consumes server CPU | |
| Centralization User Management | Provides efficient management and reporting | Lacks flexibility for departmental support providers | |
| Bindery Services | May be required | If requires additional partition/replica, creates additional network traffic from replication; consumes server CPU | |
|
Layout of the Organization Units
In designing the form of the NDS tree, you may agonize over how to structure it-around the company's organizational chart or around the organization's geography. Until you have used NDS extensively, however, you'll find it difficult to guess which plan would be most beneficial. Truth is that with a little extra work, you can save yourself from agony and use one or more forms. Decide on a primary structure based on one dimension, and then use aliases to create a virtual view based on one or more other dimensions. If you have slower WAN links, the underlying structure should almost certainly be based on the network topology. For example, the organization units (OUs) at the top of your tree could be named "Geographical-View" and "Organizational-View." The geographical view might contain OUs for each city. Under Chicago one might see OUs for Accounting, Marketing and Sales. Users, groups and servers would be found in OUs under these city OUs. In the organizational view, one would see OUs for Accounting, Marketing, and Sales, with each of those units having OUs for San Francisco, New York, and Chicago. These OUs would be aliases, pointing to the corresponding OUs found under the geographical view. For instance, the container .chicago.sales.organizational-view would be an alias pointing to the container .sales.chicago.geographical-view. Creating alternate views through the use of alias objects might be feasible only for the first few layers of your NDS tree. Nevertheless, doing so makes jumping the first design hurdle easier.
Another basic design constraint is the depth and width of the tree. Although you could have a tree with only one level and 1,000 containers, such a design wouldn't take advantage of the hierarchical nature of NDS. Similarly, a tree that is 20 levels deep but never more than a few containers wide would probably not function as well technically as a tree with more normal dimensions. Another concern in the initial tree design is the limits to the size of the containers. Novell repeatedly tells designers to limit the number of objects in a container to fewer than 1,000. This limitation has caused many long and anguished discussions leading to the creation of ugly schemes for arbitrarily dividing natural groups of objects. In fact, this limitation appears to be unnecessary, as our environment has had 25,000 user objects in a single container for several years without a problem (see "Reaping the Fruits of a Large NDS Tree" ).
Print This Page
 E-mail this URL |
|||
