Universal Guidelines for NDS Tree Design
Articles and Tips: article
Senior Research Engineer
Novell Systems Research
01 Apr 1996
These guidelines apply to every NDS tree, large or small. If you're designing a tree for a single server with several users, these guidelines will help you weed out many unnecessary factors in the design of the tree. If you're designing a tree for a larger system with multiple NetWare servers, a campus or metropolitan area organization, a regional organization, or even a multinational organization, these guidelines will help you lay the groundwork for a flexible, scalable, and reliable NDS configuration.
RELATED APPNOTES Apr 96 "Ten Proven Techniques to Increase NDS Performance and Reliability" Apr 96 "Enabling Request-IPX-Checksums to Eliminate NDS Packet Corruption Problems"
- Introduction
- General Tree Design Principles
- Universal Tree Guidelines
- If You Are Designing a Small Tree
- Conclusion
Introduction
NetWare Directory Services (NDS) provides comprehensive directory services for the smallest to the very largest of networks. The benefits of NDS go far beyond the initial benefits of a single login for your users and centralized administration.
If designed correctly, an NDS tree can act as a form of intelligence that coordinates the distribution and access of all the network's resources. Therefore, the design of this intelligent tree will have a great impact on the return on your network investment.
When designing an NDS tree, you go through three general design phases:
The initial broad-brush design
Partitioning and replication to improve availability of the tree and fault tolerance.
"Decorating" the tree with applications, directory maps, profiles, roles, groups, and access privileges.
This AppNote provides guidelines for the first phase of the design process--the initial broad-brush design.
|
Note: This AppNote assumes you are familiar with NDS conceptsand terminology. For background information see: |
Introduction to NetWare Directory Services manual
Novell's Guide to NetWare 4.1 Networks, Hughes and Thomas,Novell Press, 1996
"What's New in NetWare 4.1," Novell Application Notes, January 1995
"Management Procedures for Directory Services," Novell Application Notes, March 1994
NetWare 4.0 Special Edition, Novell Application Notes, April 1993
This AppNote supersedes "Planning an NDS Tree" in the January 1995 Novell Application Notes.
General Tree Design Principles
During the design of your organization's tree, it's important that you keep three general principles in mind. These principles will assist you in making decisions about how to organize your network resources, as well as the users who will be using the tree, to form an intelligent "road map" of your network.
The tree is primarily an organization of your physical network resources.
The NDS tree should provide a natural organization of your physical network resources. The tree should mirror your network and the physical locales of servers and printers, buildings, central and regional offices, and remote sites. Using the geographic locations of your network resources will ease access and administration performed by people who normally, and naturally, navigate geographic road maps to find things in the real world.
Design the tree with flexibility in mind.
The NDS tree structure isn't set in concrete. Design the tree with flexibility in mind so you can easily incorporate unforeseen moves and changes, as well as future growth. The guidelines in this AppNote provide specific direction on where flexibility should be designed into the tree and where the tree needs to remain fairly static. If you abide by these guidelines, your resulting tree will be flexible--with the added advantage of increased performance and reliability.
A standard naming convention can help you produce a self-documenting system.
With the right naming conventions, an NDS tree structure can provide an intuitive road map to areas of an organization that are otherwise unfamiliar to the navigator. The most useful standard names include enough information about a container or network resource to make it useable by users who are unfamiliar with the object's location or configuration.
For instance, a server name might include information about the site, intra-site location, type, and instance. Using this convention, the first of many application servers located at a corporate headquarters, in building E, could be named CORP-E-APPSERVER1. Mouse-driven GUI interfaces make the use of longer object names feasible by relieving the user from having to type in the name.
We recommend against the use of ambiguous naming schemes, such as using cartoon character names for network resources. These types of names may be convenient for some users, but they make administration and use difficult for the new or unfamiliar user. Standard naming conventions are even more important for large trees that are managed by more than one administrator.
|
For more information on developing standard naming conventions for your tree, see "Implementing Naming Standards for NetWare Directory Services" in the February 1994 Novell Application Notes |
Universal Tree Guidelines
The guidelines given in this AppNote apply to every NDS tree, large or small. If you're designing a tree for a single server with several users, these guidelines will help you weed out many unnecessary factors in the design of the tree (see the sidebar, "If You're Designing a Small Tree"). If you're designing a tree for a larger system with multiple NetWare servers, for a campus or metropolitan area organization, for a regional organization, or even for a multi-national organization, these guidelines will help you lay the groundwork for a flexible, scalable, and reliable NDS configuration.
The universal NDS tree guidelines are:
Design the top of the tree to mirror your WAN infrastructure.
Design the top of the tree around geographic boundaries.
Shape the structure of the top of the tree in theform of a pyramid.
Don't worry about the needs of remote and mobile users while designing the top of the tree.
Design the bottom of the tree to mirror sites, divisions, departments,and workgroups.
Design your user login scripts and access rights before you organizethe containers in the bottom of the tree.
Place your network's physical resources close to their users.
Use containers as logical groups.
As you read through this AppNote, keep in mind that these are not to be interpreted as hard-and-fast rules for every situation. They are presented as guidelines that can be modified to meet the unique needs of individual installations.
Design the top of the tree to mirror your WAN infrastructure.
If your network includes WAN links (or any link with a speed of 2Mbps or slower), design the top of the tree to mirror that infra-structure before designing any other part of the tree (see Figure 1).
Figure 1: The top of the tree mirrors the WAN.
Following this guideline isolates your WAN infrastructure to the top of the tree and prepares the tree for efficient partitioning. This process will minimize the impact of your WAN links on the tree's performance and reliability, whether the links are slow, unreliable, or both.
This design allows the top of the tree to remain fairly static because links to other sites, whether across town or around the world, rarely change. Keeping the top of the tree static also engenders stability by isolating the majority of moves and changes to lower levels in the tree (see Figure 2).
Figure 2: The top of the tree remains static, while you build flexibility into the bottom of the tree. static, while you build flexibility into the bottom of the tree.">
Suppose your company has four sites, located in Los Angeles, Salt Lake City, Dallas, and Atlanta, and these sites are connected by WAN links. In the example tree shown in Figure 3, the entire top of the tree represents the WAN infrastructure.
Figure 3: The tree top for an organization with four remote sites connected by WAN links. remote sites connected by WAN links.">
Don't make the mistake of relying on your company organizational chart when you design the top of the tree. Using an organizational chart often forces you to mirror your WAN links down toward the bottom of the tree. This often happens when divisions or departments span or share multiple remote sites.
In the tree shown in Figure 4, the design is based on the organizational divisions at the top (Manufacturing, Engineering, Administration, and so on), with OUs for each site branching off from there. This design is not as efficient as one that mirrors the WAN links at the top-most layer.
Figure 4: A less efficient tree design based on an organizational chart at the top and WAN links at the bottom. based on an organizational chart at the top and WAN links at the bottom.">
Once you have designed the top of the tree based on your WAN infrastructure, you can use your organizational chart to help with the placement of lower level OUs and users around their physical network resources.
In almost all cases, a tree should contain only one Organization (O) object. If you think you have an organization that requires two or more O objects, use the following criteria to make a decision:
If the organizations each have completely separate physical network infrastructures, multiple O objects may make sense.
If the organizations share a single infrastructure, then use asingle O container.
Design the top of the tree around geographic boundaries.
If your network infrastructure doesn't include a WAN, use Organizational Unit (OU) containers to organize your physical network resources by location. This organization can be by department in a building, or by building in a campus or metropolitan area network.
Figure 5: An efficient tree designed around geographic boundaries. boundaries.">
By using location as the determining factor for placement of OUs, you are laying the foundation for efficient partitioning of the tree. Later in the tree design process, partitioning around geographic boundaries will have a positive influence on the performance of day-to-day activities such as user logins. This design also helps the tree's administrators by increasing the speed and efficiency of object changes and major partition operations.
Shape the structure of the top of the tree in the form of a pyramid.
An NDS tree begins with one root and flows downward as more of the organization and its physical network resources are added. Following your implementation of guidelines 1 and 2, above, use additional OUs to shape the top of the tree so that it is sparse at the top and fuller at the bottom, like a pyramid (Figure 6). This is called a "balanced" tree.
Note: The term "balanced" refers to the pyramid shape of the topof the tree and does not imply that the entire tree shouldnecessarily be of equal depth and width throughout.
Figure 6: A tree is balanced when the top of the tree is shaped in the form of a pyramid. shaped in pyramid form.">
Once the top of the tree is designed in the form of a pyramid, the bottom of the tree becomes a free-flowing hierarchy of objects that conform to the physical network resources and access rights of the organization.
A tree that is either too flat or too narrow produces inefficiencies that have to be overcome by NDS processes. These inefficiencies can lead to poor performance as well as a less user-friendly environment for users and administrators.
In some trees, numerous WAN links lead to a flat tree such as the one shown in Figure 7.
Figure 7: A tree can be unbalanced if the top of the tree is too flat. tree is too flat.">
Whether the flatness is due to WAN links or to some other organizational anomaly, these trees can be balanced by adding another level of OUs, called "placeholders," above the level of excessive peer OUs (see Figure 8). These placeholder OUs can be named after sites, departments, or whatever nomenclature naturally suits the needs of both users and administrators.
Figure 8: "Placeholder" OUs can be used to balance a flat tree and increase the tree's ease of use and administration. used to balance a flat tree and increase the tree's ease of use and administration.">
Narrow trees can be balanced by redistributing users and resources among multiple OUs. You can either replace large OUs with multiple OUs, or you can add a layer of OUs directly below a large OU and redistribute its users and resources.
Don't worry about the needs of remote and mobile users while designing the top of the tree.
Formal strategies for accommodating remote and mobile users are better left to the final stages of tree design and implementation. Since these strategies require no modifications to the top of the tree, premature consideration of their needs only complicates the initial design.
Design the bottom of the tree to mirror sites, divisions, departments, and workgroups.
The bottom of the tree is where you put the remaining hierarchy of OUs and the bulk of the leaf objects. This is the place where you organize your physical network resources, such as servers and printers, around the users that use them. This is the flexible part of the tree that will see the majority of adds, moves, and changes. Using this approach isolates the majority of administrative changes to the bottom of the tree, allowing synchronization across the tree to occur with little or no effect on the top, or foundation, of the tree.
If you choose to administer the tree centrally and use this design, you benefit by having the majority of object moves and changes, as well as partition operations, occurring at lower levels of the tree and not requiring any change at the top of the tree. You gain stability, efficiency, and improved performance.
Using this principle is also appropriate if you choose to administer the top of the tree centrally but distribute the administration of the bottom of the tree to local container administrators. Even if administration is completely decentralized, you gain both increased stability and flexibility as benefits of confining the majority of operations to the bottom of the tree.
Design your user login scripts and access rights before you organize the containers in the bottom of the tree.
You can design your login scripts and access rights earlier or later in the design process. But if you formulate your most common login scripts and access rights early on, your efforts will produce a more natural organization of containers that you might not have created otherwise.
For this reason, we recommend that you design your login scripts for the majority of your users before completing the design of the bottom of the tree. Your work will save many hours of reorgani-zation and simplify day-to-day operations for administrators and users alike. You also have the advantage of being prepared with standardized login script and access rights strategies that will help remote administrators promote a unified approach to network access and tree management.
Also, become familiar with the NetWare Application Manager (NAM) that comes with Novell's NetWare Client 32 software for clients running DOS/Windows 3.1 and Windows 95. Using NAM, you can use Application objects to store pointers to the actual location of network applications. Users no longer need to have drive mappings established through login scripts. Each Application object can also store login script-like subroutines that map additional drives and capture printers when a user launches the application. This technology may allow you to eliminate your need for login scripts and reduce login times.
Place your network's physical resources close to their users.
Typically, resources such as servers, printers, and queues should be placed in the same container with the users who use them. This approach simplifies your administration of login scripts and access rights. It also engenders the use of containers as logical groups (see guideline 8) and reduces your reliance on formal Group objects. Carefully consider the needs of the users who will share each resource and place the resource in the container that limits their requirement to search for the resource.
Some resources may have to be placed higher in the tree if they are shared by users in multiple OUs. However, this should be the exception rather than the rule.
Avoid creating special containers for similar types of resources-- such as a container for servers or a container for printers. This intentional separation of users from the resources they most frequently access can dramatically increase the users' requirement to traverse the tree to find the resource. Locating their most frequently used resources in the same container improves performance, ease of use, and administration.
The exception to this guideline to avoid special containers is large environments in which many users commonly access devices located throughout the organization. A university is a good example of this type of organization. Placing a group of workgroup printers in a container with a standardized name (such as OU=PRINTERS) in each geographic location may help rather than hinder the accessibility of those resources.
Use containers as logical groups.
If you organize the OUs in the bottom of the tree based on login scripts and access rights as described above, you can take advantage of a significant performance enhancement in NDS. Your containers will naturally perform many of the same functions as a formal Group but with better performance. We call containers that are used in this way "logical" groups, or container groups.
Group objects should only be used when containers fail to contain the appropriate users. Due to the breadth of Group relationships and the algorithms necessary to resolve those relationships, Group rights assignments don't perform as well as rights administered via containers (logical groups).
Due to this overhead, global Groups--Group objects placed at or near the root of the tree and contain general membership-- should never be used without understanding the performance implications.
Use of the "IFMEMBEROF" login script variable may be kept to a minimum if containers can be used effectively in the place of groups. If you do use Groups and the "IFMEMBEROF" login script variable, try to limit each Group's membership to a single partition. This minimizes the overhead incurred by Group operations during user login.
Another way to reduce your reliance on formal Groups is with user profiles. Individual users can inherit multiple profiles and accomplish many of the same objective as with formal Groups.
If You Are Designing a Small Tree
(Many of the guidelines in this AppNote do not apply to very small trees. By definition, a small tree is one that is confined to a LAN (Does not include WAN links), includes less than five or six servers, and has fewer than 500 objects (users, servers, NetWare volumes, printers, print servers, and so on).
If your tree fits these criteria, we recommend that you take the following approach to tree design:
Place all of the tree's objects in the Organiztion (O) container.
There is no need to use Organizational Unit (OU) containers unless they help you organize your objects for ease of use and administration.
Don't partition the tree.
Your use of partitioning to distribute parts of the tree across a small LAN is uneccesary because the sole [ROOT] partition is local and immediately available.
Accept the time synchronization default configuration.
This default designates a Single Reference time server, with the rest of your servers configured as Secondary time servers. This is the simplest configuration and requires no further action on your part once you select the default setting during installation.
If you are installing a single-server configuration, remember that NetWare builds fault tolerance into an NDS tree only as additional servers are installed. (The second and third servers automatically store replicas of the [ROOT] partition.) If you have only one server, you will have only one copy of the tree (the [ROOT] partition), with no onine replicas. Therefore, you should perform frequent tape backups, or use third-party utilities to regularly back up your tree to ensure adequate fault tolerance.
Conclusion
These guidelines have application in every NDS tree. If you are designing a new tree, these guidelines will help you focus your initial broad-brush design on important design fundamentals. If you manage an existing tree that doesn't conform to these guidelines, this AppNote can help you gently modify your tree over time to improve the tree's performance, as well as its ease of use and ease of administration.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.