Planning an NDS Tree
Articles and Tips: article
Manager, Software Engineering
NPD Engineering
TIM PETRU
Software Engineering
NPD Engineering
NANCY CROSSEN
Engineering Documentation Team Lead
NDS Development Team
01 Jan 1995
This AppNote contains specific suggestions for solving common problems when you design NDS trees. When you design a tree, you should not only consider the organizational characteristics of the environment, but also the LAN/WAN topology and any special environmental requirements. One of the most influential considerations is whether the tree is to be used in a single or multiple campus environment. If your environment is a single campus, you can design the NDS tree with or without considering the physical network layout. If your environment is a multiple campus, you can design the tree so that the upper layers efficiently use the WAN.
- Introduction
- Overview
- Designing the Upper Levels
- Designing the Lower Levels
- Incorporating Special Needs Into the Tree Design
- Adapting the Tree
- Sample Trees
- Conclusion
Introduction
Before reading this document, you should understand the following NetWare Directory Services (NDS) concepts: objects, containers, external references, subordinate references, partitions, replicas, synchronization, name context, alias, and the NDS hierarchy. For more information on the previous topics, please see the NetWare 4 Introduction to NDS and Users Guide.
Note: This article uses the word environment to represent an NDS tree environment. This environment includes any logically connected group that must have resources within the same NetWare 4 network. These groups could include entire companies, divisions, departments, and workgroups. Name resolution is the process used to find an object in the tree. Tree Walking is the process that name resolution uses to locate an object not stored locally. External reference is a placeholder on a server where the real object does not exist; the external reference is used to provide the following: file rights where needed, a hierarchy for the tree, and cache attributes of the objects. Subordinate reference is a partition used to provide connectivity in the tree for name resolution
One of the current trends in designing NDS trees is to design the tree around any special needs found in the tree's environment. However, after evaluating many tree designs currently being used in commercial production, we found that, regardless of their environment, all good NDS trees share common architectures. We analyzed these architectures and found the underlying solutions to common problems present in many environments.
This AppNote contains specific suggestions for solving these common problems when you design NDS trees. It also presents the issues you should consider when you design your tree. These considerations should enable you to design your tree so that it uses NDS's distributed nature to an advantage. This AppNote also provides several examples of good tree design that are taken from actual corporate environments.
We do not attempt to provide hard and fast rules in this AppNote. Instead, we explain the factors you should consider and how they influence the tree design. If you understand the reasons behind a tree design, you will be able to design a tree for any environment, not just specific environments that match the examples.
Overview
When you design an NDS tree, you should not only consider the organizational characteristics of the environment, but also the LAN/WAN topology and any special environmental requirements. For example, environments that have only seven servers and four WAN segments are best suited by a "large tree configuration" (multiple campus configuration) rather than the "small tree" configuration (single campus configuration) usually recommended.
We have found that NDS trees are more efficient if they are designed for the general environment and then that design is adapted to meet any special environmental requirements. NDS trees that are designed to meet specific environmental needs tend to become less efficient over time as the environment's special needs diminish and change.
Tree Environments: Single and Multiple Campus
Generally, tree environments can be categorized into two types: single campus and multiple campus LAN/WAN.
Single campus refers to any environment that has the entire network connected either by LAN medium or fast enough WAN links that data transmission is not an issue, such as FDDI. This network can be entirely housed in one building, in many buildings that are in close proximity or connected across fast WAN links.
Multiple campus networks make up any other environment where data transmission must be considered an issue either in speed or in volume.
Steps for Designing Good NDS Trees
To ensure a manageable and efficient tree, you should follow these general steps:
Select a unique tree name.
Design the upper levels of the tree.
Design the lower levels of the tree.
Incorporate any special needs into the tree design.
Adapt the entire tree for efficient tree walking.
Adapt the tree so that you can merge it in the future.
The factors involved in these processes are described in the following section.
Selecting a Unique Tree Name
Every tree name must be unique on the network; this allows multiple trees to exist on the same network. The tree name allows clients to connect to a server within the correct NDS tree. This name is representative of the environment for which the tree is designed; frequently, it is the corporation's name, or a name representative of the environment.
Designing the Upper Levels
The very top of the tree is the root. In versions prior to NetWare 4.10 this was named [Root]; in NetWare 4.10 it is the tree name. (However, in many utility operations the root is still referred to as [Root].)
The level below [Root] is usually either a country or an organization name. If the users must access data in other directory spaces (for example, on a common carrier internet, information superhighway, or other X.500 name spaces), the container below [Root] should be named with a country name. (The figures in this article show the country name by "C=" .)
The country name enables the users to use, exchange, and manipulate data, and to authenticate to other name spaces with X.500 fully distinguished names. The benefits of exchanging data with other name spaces outweigh the overhead of the added hierarchy level for the country object.
If the NDS tree environment spans country borders, then the country name could be the name of the country where the corporate headquarters reside. The corporate name is usually the next level of the tree, or the top level in the absence of the country name. (This level is indicated by an "O=" on the figures.) This should be a name that is well known throughout the environment so that tree client operations are easier. The organization name should be registered with the Internet or should be ANSI-standard to enable future X.500 multiple tree and multiple name space operations. An environment can also incorporate multiple organization names to more fully describe the tree. In such cases, each organization name should be registered.
Figure 1: The level below [Root] is either a country or an organization name.
The organization name (as well as all container names) should be as short as possible and still maintain meaning. Shorter names are easier for the user to key in at a keyboard when they must scan, browse, or use the utilities and Email. Remember that the user uses these names for almost all operations in the Directory. Make them concise, clear, and intuitive.
You can use the next layers in this portion of the tree to reflect the LAN/WAN topology. This is particularly useful in environments that have limited bandwidth such the multiple campus environment.
Because the single campus environment has few bandwidth concerns, a tree in this environment need not reflect the LAN/WAN topology. A tree for a single campus need only define the [Root] and locality (if desired) and the organization levels. You can then start designing the lower tree levels.
Reflecting the LAN/WAN Topology
The next level of containers should be a level of organizational units (indicated by "OU=" on the figures). These containers should represent the physical network structure of the environment. They should include corporate divisions, departments, buildings, or geographical locations that are separated by a WAN, rather than a LAN.
This tree design allows you to efficiently use NDS's data replication and to partition the database along WAN structures, thereby significantly reducing the network traffic.
If you desire, you can also allow tree management at each corporate location, thus decentralizing the tree administration. This allows the administrator to autonomously manage containers and also manage just the relevant portions of the tree.
The upper levels of the tree are the levels that are most affected by the LAN/WAN topology. Therefore, WAN's are the most dependent upon the data transmission and tree connectivity of these upper tree levels. Efficient NDS tree designs reflect a close match between the network infrastructure and the upper levels of the tree. As Figures 2 and 3 show, Organizational Units can reflect a corporation's physical locations.
Figure 2: Organizational Units for a single organization.
Figure 3: Organizational Units for multiple organizations.
A tree design that reflects the corporation's physical locations not only reduces network traffic, but is also intuitive for the users. Most individuals think of themselves as working in a location, city, or building of a company. In the example illustrated above, users would think of themselves as working for Novell either in Provo, San Jose, or Europe. Thus, the user is able to easily remember the upper levels of the NDS tree. This tree design also keeps each location's data in that portion of the tree. Because the tree design reflects the corporation's physical locations, replicated information from Europe flows around the servers in Europe, but does not need to traverse the WAN to another major site, dramatically reducing the WAN traffic.
Note: NDS and its utilities currently support the Organization and Organizational Unit containers. NDS also supports the Locality container, although the utilities do not yet fully support this. This Locality container is beneficial to those environments that specify containers by geographical cities. NDS trees for state and local governments would most likely use the locality containers.
Designing the Lower Levels
You should organize the remaining levels of the tree according to the functional divisions of the environment. This includes divisions, departments, workgroups, services and other functions. Use these levels to accurately name the service, user, or other resource in the environment. Use the environment's organization or work flow charts to develop the hierarchy and names of these tree levels. These levels should have a container for every user, service, server and all other leaf objects.
You should now determine the hierarchal placement of central groups, services such as Email, and public file servers. Placing these common services correctly decreases the amount of traffic on the wire and allows users to easily find the service. Use aliases for these common services when appropriate to allow users easier access to them. Designing for environment wide aliases assists in the total design of the tree.
You must also now adapt the tree design so that it can be easily backed up. Backing-up NDS is a logical operation that could traverse the servers in order to functionally backup NDS data. Thus, the correct replica placement reduces network traffic during a backup. Be aware, however, that placing replicas in order to reduce network traffic during the backup process, creates more traffic during synchronization.
You must also determine tree depth at this point. Maintaining the appropriate depth makes data access and tree management easier.
Generally, a depth of between 4 and 8 levels is adequate for any NDS tree. As the environment complexity increases, either in numbers of objects or in the number of locations under separate management, the tree depth also usually increases.
After determining the depth of the tree in the lower levels, you must determine the layout of these layers. While, the layout of the upper levels is usually easily determined and customarily only allows a few choices in the tree design, the layout of the lower levels can require many choices because of the many organizational and workflow combinations that could occur at this level.
Consider the following in structuring the tree at this level:
An organizational chart, relying on division and department names to provide the logical structure for container names.
Workflow through the company; this allows you to group individuals and services along task lines rather than department lines.
The management structure that is incorporated for each group of users, including login script use, container roles, directory maps, etc.
Service-oriented groups so that users of similar services are grouped together across department or other boundaries.
Any combination of the above.
The upper levels of the tree generally have the same type of structure; however, the lower levels are usually quite similar in structure but dissimilar in depth and naming. Therefore, you should design the lower levels of the tree specifically to name the leaf objects. Each leaf object should have a name that truly represents that object.
In addition, the name should have the minimum number of containers that provides a fully distinguished and identifiable name. Also, be aware that if you attempt to create a tree with nonessential containers just to maintain identical subtrees, you will unnecessarily complicate the tree.
Leaf object naming is a critical portion of lower level tree design, but manageability of those objects is also a key issue. Container groupings should follow the common rights within the environment. An efficient design decreases the time required to install NetWare 4 because it places resources, services and the appropriate users in close proximity within the tree.
This means that you can grant most rights to a container, rather than to individual objects, and have those rights flow through the tree to the users that will need them. Thus, a single right could be given to a container that might affect 50, 500, 5000 or more users and minimize the time that you spend administrating the NDS tree and also reduce network traffic.
Figure 4: The lower level Organizational Units.
Incorporating Special Needs Into the Tree Design
You might have to address many special needs. Therefore, keep in mind that you should design the tree as specified above and then adapt the design to meet any special needs, rather than designing specifically for those special needs. Your tree design might have to take into consideration the following:
Bindery services
Applying rights to groups
Globally shared resources
Mobile users
Distributed searches
Bindery Services
Enabling bindery services on all, or most, servers in order to support bindery-only aware applications increases network traffic due to the replication traffic exchanged between the partition replicas. To solve this you could:
Partition the tree in a lower level so that fewer servers hold the replica of any partition,
Move the bindery-only aware applications to certain servers and then place the replicas only on those servers
Upgrade old applications or purchase new Directory-aware applications.
Applying Rights to Groups
"Management by exception" reduces administration on a NetWare 4 network. This principle stresses that you grant rights to containers and let users receive those rights through inheritance. If you place servers, printers, and services in the container where the appropriate users reside, you reduce administration even more. Management by exception is particularly useful when resources and/or users span containers.
If global groups span the environment, then common containers that hold those groups are beneficial. Keep in mind that when a user authenticates to the network, NDS calculates the security equivalence, and that security equivalence includes the security rights inherited from the groups. If those groups are only a network hop or two away from the user, the time required to calculate the security equivalence decreases. Also keep in mind that if a user is a member of a group that can access resources where that user's object does not exist, NDS creates external references to the user's object.
Globally Shared Resources
Some environments have many globally shared resources. When you design a tree, you should take into account resources that are server- or location- centric and that are accessed by users in many portions of the tree. A payroll database is a good example of this. A payroll database is a resource that probably exists on a server that holds the replica for the Human Resource department, yet many people within the company access the data.
As the users authenticate to the server that holds the shared resource (the payroll database, in this example), NDS creates external references of the user objects on that server. You can resolve this situation by determining which users or subtrees must access the shared resource and then modifying the tree design to accommodate users in several partitions rather than in the entire tree.
Profiles and container scripts are other examples of shared resources. When a user authenticates to the network, NDS executes that user's profiles and scripts. If any of those are not kept locally, the login process must retrieve those profiles and scripts across the LAN or WAN. You can solve this by keeping the profiles and scripts either on the user's server or relatively close to the user across fast LAN or WAN links. This decreases the user's authentication time.
A global system that is external to NDS and that is not NDS-aware is another shared resource. Examples of these global systems that some users must access are E-mail and Legacy systems. In this case, users authenticate to the resource and then execute some procedures. You can design the tree in various way to provide access to these solutions. However, keep in mind that you must enable all appropriate users to access the service. To accomplish this, you could use either directory map objects, aliases, or a procedure that informs the user of the mechanism for accessing the resource.
Mobile Users
If the network has a significant number of mobile users, you should adapt the tree design to accommodate those users. You could consider one of the following solutions:
Build identical directory map objects in the Directory so that a user can easily map a drive from any point in the Directory to a local server and access any required resources. (If you decide to use this solution, the network must have some servers withan identical file system structure.)
Place an alias for the mobile user close to the root of the tree. This assists the user during the authentication process by not requiring that the user remember the full distinguished name.
Place the NDS partitions so that they assist the mobile user in finding NDS data. Placing the replicas within 1 or 2 hops from any site reduces the number of hops the mobile user must make in order to authenticate or walk the tree.
Distributed Searches
You might need to consider designing the tree so that it makes it easier and faster for applications to search for objects. Email, calendars, notebooks, and phone directories are some examples of applications that search the database. Each of these applications rely upon an address book, which in this case is the NDS database.
As the database is distributed across WANs, the response time for a search lengthens. You can choose one of several solutions to this problem:
Alter the tree design or use an external method for name lookup.
Place a significant portion of the tree on the servers that hold an instance of the root partition. (This assists users searching for an object when that search must access the root partition. However, it does not assist in searches that do not access the root partition.)
Build a branch of the tree to contain aliases to the real objects. This could be either a single container or a hierarchial subtree just off of the root that would contain an alias for every object that the application might need. For example, if the application were Email, the alias subtree would have an alias for every user in the tree. You can also replicate this alias partition on several servers because aliases are extremely small objects that require little or no updates. Keep in mind that this solution requires that every time administrators create a user, they also create an alias to that user.
Synchronize the NDS data to another database for index retrieval. For example, if the application were Email, the NDS data would be synchronized to the Email address book. In this case, whenever the administrator creates a user in the NDS database, the synchronization process creates the user in the address book as well.
Adapting the Tree
Consider adapting the tree for efficient tree walking, minimization of subordinate references, or merging.
Efficient Tree Walking
Every user must walk the tree to locate objects. Tree-walking occurs at authentication time and when the user or application is searching or browsing the tree.
Tree-walking requires NDS to move either up or down the tree and step through the containers. If the tree is flat, then NDS need only move up to the root of the tree and back down to the necessary partition for nearly all requests. If the tree has more depth, the tree-walking process uses the root partition less. The sections with the sample trees illustrates this more clearly.
Minimize Subordinate References
Having fewer subordinate references reduces the number of replicas you need to update when you make partition changes, decreasing the chance that synchronization will not occur because servers or communication links are unavailable. The best way to reduce the number of subordinate references is to reduce the number of file servers containing a copy of the [Root] partition.
Workgroup boundaries generally determine the number of partitions required in any tree. You should partition your tree according to how network resources are used and where they are located in the directory tree. Be careful not to create unnecessary partitions.
Design your tree like a triangle with a small number of partitions at the top of the tree and more partitions as you move toward the bottom. Such a design will create fewer subordinate references than a top-heavy tree that has more partitions at the top than at the bottom.
Efficient Merging
When you design a tree, you should also keep in mind that it will probably be merged with another tree sometime in the future. Smaller trees are easier to merge. Keep in mind that the merge tree operation merges two trees at the root.
To enable your tree to merge easily you should keep in mind the considerations illustrated in Figure 5.
Figure 5 illustrates two trees - Novell and Xprod. Once these two trees are merged at the root, you can restructure the tree by using the move subtree operation; any objects located in the Xprod container must be moved manually.
If you have designed the tree so that the containers are left essentially empty after the trees are merged, only the NYC container must be moved and the operation is complete.
Precautions
Keep in mind the following precautions when you design your tree:
Do not place too many instances of the root partition in the tree. This creates more subreferences in the tree.
Do not "over partition." Partitions that are too small create administration problems.
Do not design a flat tree. Flat trees result in increased administration. Flat trees also cause more subreferences.
Use moderation in all that you do.
Figure 5: This shows the merging of two trees.
Sample Trees
This section includes sample trees taken from real corporations. These trees illustrate the above principles in real-life examples. The names of the companies and containers have been changed.
Single Site Campus
As noted earlier, a single site campus can be housed in one building, in many buildings that are in close proximity, or connected across fast WAN links.
Environment Description
A single campus site that has a physical layout consisting of 320 servers in 2 buildings
All servers are connected by high-speed links and Ethernet.
The corporation has 6000 employees.
This is a very common NDS tree.
Figure 6 illustrates a fairly efficient tree.
Figure 6: This shows a single site campus tree.
Tree Design Goals
Minimize the user's response time
Minimize the administration time involved in moving users for internal transfers
Provide central partition management
Allow the department administrators to manage the objects
Provide fault tolerance for the user authentication
Tree Design
Design this tree around the departments or workgroups.
This tree does not require that the environment's physical topology be reflected, so do not implement that level
Mask off partitioning rights at the lower containers, but allow the department administrators to manage all object changes.
Provide at least 3 instances of each partition to enable users to authenticate and use the network regardless of server outages.
Locate the Root partition on 2-4 servers in each building.
Advantages
This design keeps the containers/partitions as large as possible without causing too much replication traffic.
Personnel can change tasks and yet not change their context in the tree.
Tree context must only change when a user moves within the company.
Searching is enhanced because the entire treeis based on the organization of the environment. Tree-walking is fairly efficient due to the tree organization. Users typically stay within a department for their resources, and a department is contained within a partition or two. If the tree-walking process moves out of the partition, it will involve the root partition,but this will be across a fast link and should cause little problem.
The tree contains very few subordinate references of the root.
Expectations
The tree has some areas that are reaching 6 levels deep. This is not bad, but does mean that users must be educated on the concept of the context.
The design may not scale easily to a large multiple campus environment, because the tree has no physical locality associated with it. This will not be an issue if all divisions are located in just one site. Then as the environment grows, the tree does not have to be redesigned in order to scale.
Moving users between departments is not easy to administer. Any reorganization in any department will change the structure of the tree.
Resource sharing between departments is difficult to implement.
Optimization
Repartitioning some areas of the tree could assist in the efficiency of the tree. For example, the Sales and MFG partitions could be repartitioned. However, if bandwidth usage becomes a concern, scaling back could be difficult, especially if the departments span locations.
A divisional level could be added under the organization level to give the upper levels of the tree more hierarchy because the tree is fairly flat at the top, but hierarchial at the lower levels. More hierarchy would eliminate many instances of subordinate references.
Multiple Site Campus #1
Figure 7 shows a multiple site campus physical layout.
Figure 7: This is a multiple site campus physical layout.
Environment Description
120 servers in 5 main locations
All servers are connected by T1
Between 3 and 12 regional sites are connected to each major site by links that range in speed from 19.2 to 56Kb.
Each of these sites has at least 1 server.
The corporation has 4500 employees.
Figure 8: Multiple site campus logical layout.
Tree Design Goals
Minimize network WAN traffic
Allow administrators at each major site to manage their subtree
Provide fault tolerance for the single server regional sites
Provide fault tolerance between major sites
Tree Design
Create partitions based on major and regional sites of the network topology
Place a container for each regional site that connects to the major site under the major site containers
Place a replica of the region's partition at each site within the region
Place the regional replica at the major site as well
Place the replicas for the major sites at the other major locations in order to assist mobile users
Place the Root partition at each of the major sites.
Advantages
Partitions are moderate in size.
Replication is kept to a segment of the regional (slower) WAN.
Replication traffic is kept to a minimum across the high speed links.
Searching is based on knowing the general regional location of the user or service.
An administrator in each major site can managethat site as well as all the regional sites that physically connect to that site.
Fault tolerance is provided by replicas that are stored in the regional sites as well as at the major sites.
Resource sharing by location is easily implemented.
The Root partition has fewer subordinate references because of the tree depth.
Expectations
Placing replicas across the major site mesh causes replication traffic to increase.
It is difficult to restrict major site administrators from having all rights to the regional sites and yet allow them to have all rights for the major site.
Regional partitions carry data for many sites and, thus, are replicated in each site. This creates higher traffic on the regional WAN. If a division spans cities, the replication traffic across the WAN increases as replicas are stored in each city.
The number of replicas of a partition equates to the number of locations in the region.
Partition operations require that all instances of that partition be reachable, and if many sites hold that partition, the odds of a server or link being down are increased.
The tree-walking process must use the servers that contain the root partition when it moves from one partition to another.
The tree is difficult to separate by the divisions.
Optimization
Determine how the company really operates: Is a department found in multiple cities? Multiple divisions don't span cities well in this design.
Multiple Site Campus #2
Figure 9 illustrates a variation on the tree.
Figure 9: A second possible multiple site campus tree.
Tree Design
Create partitions based on the structure of the environment and the regional sites of the network topology.
Replicate partitions for each division/department across the major sites.
Place a replica of the region's partition at each site within the region
Place a replica of the regional partition at the major site.
Place the replicas for the major sites in the other major locations so that they assist mobile users.
Place a replica of the Root partition at each of the major sites.
Advantages
Partitions are moderate in size.
Replication is kept to a segment of the regional (slower) WAN.
Administration is more efficient, if it is performed by a central administrator.
Fault tolerance is provided by the replicas stored at the regional sites and at the major sites.
The Root partition has fewer subordinate references because of the tree depth.
This design depicts a methodology for regionalizing a tree.
This design allows for divisional as well as regional layouts.
This design will allow users to effectively work across cities but within their division.
Expectations
Placing replicas across the major site mesh causes replication traffic to increase across the high speed links because of the common replicas kept on multiple sites.
Searching for an object within a division/department container is easier, but locating objects within a regional site is harder because the user is unsure whether to search in a division container or a regional container. This causes confusion.
Decentralized administration is more difficult to manage because the partitions span multiple major sites.
Regional partitions contain data for many sites and, thus, are replicated at each site (increasing traffic on regional WAN).
The number of replicas of a partition equals the number of locations in the region.
Partition operations require that all instances of that partition be reachable, and if many sites hold that partition, the odds of a server or link being down are increased.
The tree-walking process must use the servers containing the root partition when it moves from one partition to another.
Optimization
If bandwidth is an issue, this may not be an optimum design. However, if the bandwidth can support the heavier replication traffic, this is a good design.
Use more generic naming if city hubs could change. (This could create long term stability.)
Place the headquarters containers another level deeper in the tree (see Figure 10). This facilitates easier searching and partitioning for those containers.
Figure 10: A third possible multiple site campus tree.
Branch Office Tree: Single Star #1
Figure 11 illustrates the physical layout for a single star branch office tree.
Figure 11: Physical layout for single star branch office.
Environment Description
The physical layout consists of 190 remote sites coupled by 56Kb lines to a central site.
Each of the remote branch sites connect directly to the central site.
This environment has 218 servers, 1 server in each branch, and 28 servers in the corporate headquarters.
The branch offices have between 5 and 25 users each.
The corporation has 4300 employees.
A tree design for this environment must take into account some unique network traffic complexities.
Figure 12: Possible tree for single star branch office.
Tree Design Goals
Minimize network WAN traffic
Provide central management for partitioning
Allow the branch offices to manage the objects
Provide fault tolerance for the single server branch sites
Tree Design
Create each branch office container as a partition root with a larger partition for the corporate headquarters
Place a replica of the site partition at each branch office
Place 2 instances of the site partition at the central site
Use several servers with each server holding between 50 and 75 replicas. This requires a minimum of 8 servers in the central site.
Replicate the Root partition only at the central site.
Advantages
Partitions are small. Every leaf container is a partition root.
Synchronization traffic travels from the branch sites to the central site.
A central MIS could manage the partitioning ofthe tree with rights to the root of the tree.
The rights of each administrator in the branch offices could be also be restricted so that the branch sites cannot partition, but they can still manipulate all the objects.
The remote replicas can be managed at the remote site and the modifications synchronized to the central site.
Two instances of each partition are located in the central site, providing fault tolerance.
Expectations
Partitions are small. This requires more administration to manage the partition placement.
The design doesn't support large partitions, except at the central site.
This is a very flat tree. Because of its flat nature, every server that holds a copy of the root partition will contain subordinate references to the branch office replicas. Therefore, the instances of the root partition must be kept to a minimum.
This design is not scalable. As the number of branch offices grows, the number of subreferences increases.
This design will be difficult to evolve into a more hierarchial tree. Therefore, the design will not support much growth for individual branch offices, and they must remain fairly small. Bandwidth for the remote branches is limited.
The design makes it hard to centrally manage individual objects.
The central site must be accessible for all tree synchronization operations.
Maintaining servers at the central site is time consuming because of the number of replicas stored on each server.
Resource sharing is not easy to administer. However, a user in Dallas would probably not be using a printer in Atlanta.
Walking the tree requires that all operations outside of the current partition must connect to a root partition server.
Locating users or services in the tree could be more difficult because these operations require that the user know what city the user or service is in before beginning the search.
Optimization
Create an alias for all objects at a high level in the tree to aid in searching.
Set the scope of the search to begin at the root of the tree. This assists in locating objects, but requires searching the entire tree.
Place instances of the root partition only at the central site. Placing remote replicas of the root partition only degrades NDS performance because it causes more subordinate references and more synchronization traffic as a result of the increased number of servers that must communicate. It also adds very little benefit for the user.
Keep only a reasonable number of replicas on each central site server. (The central server must synchronize data with every server that holds the same replicas as the central server.)
Logically and physically separate the central site partitions in order to enhance the performance of the central site replication and the authentication process for the users.
Create separate partitions and place those on different servers than the central site servers. Replicating remotebranch partitions enables better usage and disaster recovery forthe central site. By separating branch replication from central site replication, you are moving towards dedicated NDS servers. This increases performance on a large star network.
Place a second server at each remote site. If the branch server serves as the router to the central site and is inaccessible, the branch users are unable to authenticate. A second server placed at each remote site significantly increases fault tolerance because one server holds the replica, while the second server handles the routing. Therefore, when the NDS server is inaccessible, the user can still retrieve authentication data from the central site.
Branch Office Tree: Single Star #2
Figure 13 illustrates a branch office tree.
Figure 13: A second possible single star branch office.
Tree Design Goals
Minimize administration
Provide central management for partitioning and objects
Provide fault tolerance for the single server branch sites
Tree Design
Create partitions based on functionality.
Place containers at the lower levels for every site that has the same function.
Place an instance of every partition that involves that location at each site.
Place 0, 1, or 2 replicas of each partition at the central site.
Replicate the Root partition only at the central site.
Advantages
The partitions are built around functionality and are easier to manage from a department basis.
Tree walking is easier for a single department.
Searching is easier because the user can find an object based on the functionality of the environment.
A central or departmental MIS can manage the entire tree. Management would most likely be performed on the central site replicas and then synchronized with outlying replicas.
Security and rights administration is easier due to the functional nature of the tree. Resource sharing within a department and across servers is easier.
The partition replicas in many sites offer fault tolerance.
The tree is deeper and, thus, contains fewer subordinate references on the root partition.
Expectations
Disallowing the branch sites to perform partitioning and still allow them to manipulate all the objects is difficult because of the partition structure.
Tree structure makes branch administration more difficult.
Partitions contain data for many sites and, thus, are replicated in each site. This results in higher WAN traffic because if every site is in every functional container, then every site holds a complete copy of the tree; in other words, all partitions would exist on all remote sites. This means that the number of partition replicas is too large to be manageable.
Partition operations require that all instances of that partition, including subordinate references, be reachable; if many sites hold that partition, the odds of a server or link being down are increased.
Administrative overhead is higher for both the central site and the branch offices.
Resource sharing on the same server, but within different departments is more difficult.
Tree walking between departments is still bound to the servers holding the root partition
Optimization
In addition to the items mentioned for the tree in Figure 2, you should also consider the following:
Due to mismatching between the network topology and the tree structure, you should avoid this tree.
Partitioning becomes crucial to the effectiveness of the tree.
If the divisions are localized (for example, if Accounting is located in one or two sites), this tree could be workable; otherwise, the NDS data is replicated in too many sites.
Branch Office Tree: Segmented Star
Changing the physical topology to a multiple segmented star offers some different tree designs for the environment. Figure 14 shows the physical layout.
Figure 14: Physical layout for multiple segmented star.
Each of the remote branch sites now connect directly to a regional site.
A fairly efficient tree is shown in Figure 15.
Figure 15: Logical layout for multiple segmented star.
Tree Design Goals
Minimize network WAN traffic
Provide central partition management
Allow the regional offices to manage the objects
Provide fault tolerance for the single server branch sites
Tree Design
Create partitions based on regional sites of the network topology.
Place a container under these containers for each site that connects to the regional site.
Place a replica of the region's partition at each site within a region.
Control these partitions for size, because as the WAN traffic increases, another regional hub for the network is added. The design of the tree is, thus, able to take advantage of the change.
Place only branch partitions at regional sites.
Replicate the Root partition at the central site as well as at each regional site.
Advantages
Partitions are moderate in size.
Replication is kept to a segment of the WAN.
The Root partition holds fewer subordinate references because the tree is deeper.
Searching is easier because the user can find an object based on the general regional location of the user or service.
A central MIS could manage the entire tree or a regional administrator could manage the regional portion of the tree.
Management can be performed on the remote replicas and then synchronized in to the central site.
Fault tolerance is provided by the multiple instances of each partition in the regional sites.
Expectations
Disallowing the branch sites to perform partitioning operations while still allowing them to perform all object manipulations is difficult to implement because of the partition structure.
Partitions contain data for many sites and, thus, are replicated in each site. This creates higher network traffic on the regional WAN.
The number of replicas of a partition is equal to the number of locations in the region.
The design is limited in scaleability and will be difficult to evolve into to a more hierarchial tree.
The design does not allow the individual branch offices to grow much. They must remain fairly small. Adding many more branches or increasing the size of a branch causes the partition to grow.
Bandwidth for the remote branches is the limiting factor because all the branches are in one partition.
This design makes it difficult to use centrally manage individual objects.
The central site must be accessible for all synchronization operations.
The tree-walking process must use the servers that contain the root partition when the process moves from one partition to another.
Partition operations require that all instances of a partition be reachable. If many sites hold that partition, the odds of a server or link being down are increased.
Sharing of resources between sites is difficult to administer.
Optimization
Create an alias for all objects at a high level in the tree to aid in searching.
Set the scope of the search to begin at the root of the tree. This assists in locating objects, but requires searching the entire tree.
Place instances of the root partition only at the central site. Placing remote replicas of the root partition only degrades NDS performance because it causes more subordinate references and more synchronization traffic as a result of the increased number of servers that must communicate. It also adds very little benefit for the user.
Keep the replica on the regional server to areasonable size. If you must, you could split the regional partition, but because of the nature of this tree design, you would have to split the tree to the lowest leaf containers.
Logically and physically separate the central site partitions from the regional site partitions in order to enhance the performance of the central site replication and the authentication process for the users. Remember that the regional servers must synchronize data with every server that holds the same replicas as the central server.
Create separate partitions and place those partitions on different servers than the central site servers. This replicates regional and branch partitions and enables better usage and disaster recovery for the central site.
Place a second server at each remote site to significantly increase fault tolerance for the user. If the branch server serves as the router to the regional site and is inaccessible, the branch users are unable to authenticate; they have no fault tolerance. A second server at each remote site enables one server to hold the replica, while the other server handles the routing. This way, when the NDS server is inaccessible, the user can still retrieve authentication data from the regional or another branch site.
Services Tree
A services tree is built around the services within the environment. This type of tree is independent of the network topology because the partitions are generally small and could exist on most types of connectivity. A tree for this environment produces some logical complexities for network administration (see Figure 16).
Figure 16: A services tree.
Tree Design Goals
Provide ease of management for containers
Provide central management for partitioning
Provide for more restricted rights for management
Tree Design
Each functional container has 5 services containers: bindery, servers, applications, users and printing
Place all services and applications in the applications container, all users in the users container, etc.
Advantages
Provides ease of management for specific groups within the environment. For example, when the bindery is no longer needed, that container and all of the contents can be deleted.
Administration can be divided easily.
An administrator could have rights to manage all of the printers and for security reasons, not have any rights to any servers.
Searching is easier because of the functional layout of the tree.
Expectations
A single user could have multiple user names: one could be in the user container, and a second if needed, could be in the bindery container. This can create confusion, as well as a management problem, because the administrator must remember to add both usernames when creating a user. The administrator must also remember to make any modifications to both user names.
Management of the services within the network is a manual operation because the Directory hierarchy is defeated. In order for users to access servers, printers, print queues,and other applications, the administrator must either grant the users explicit rights or grant rights to the user container for those services.
The bindery path must be set to all containers that the users must access. This might include print and applications, as well as the bindery container.
This design does not work well for multiple campus networks because of the increased number of locations.
This design is not scalable; it will not grow with the company because it has no locality.
This design uses the Directory to perform functions that should be performed by the applications.
This design physically separates the NDS class types that separate object types in a search. This degrades the searching capability and performance of this tree.
Security must be administered manually and is dictated by an inflexible design.
This design dictates how new services are added.
The tree is difficult to partition and replication could place large partitions across WAN links, greatly increasing WAN traffic.
Optimization
Only use this design in a single site campus network topology because it use high bandwidth in other network topologies.
Locate every high level container in a single site to maximize the usefulness of the tree.
Change the partition boundaries to lower containers. This could assist in lowering the bandwidth usage in a multiple campus or star environment.
Conclusion
When you design NDS trees, you must consider a number of issues. One of the most influential considerations, however, is whether the tree is to be used in a single or multiple campus environment. If your environment is a single campus, you can design the NDS tree with or without considering the physical network layout. In a single campus environment, you can either base the tree design of the upper levels on locality, or omit the locality containers. However, eliminating the locality means that the tree is more difficult to evolve with the environment if it experiences much growth.
If your environment is a multiple campus (a star environment), you can design the NDS tree so that the upper layers efficiently use the WAN. This makes the tree replication more efficient, although walking the tree could be more cumbersome.
Checklist
When you design the tree, you should keep in mind the answers to the following questions:
How does the tree design handle reorganizations?
How does the tree design handle types of partitions?
How does the tree design handle traffic on the wire?
How does the tree design map to the physical topology?
Will the physical topology change in the future?
How will the tree be administered?
How will the tree design handle the administration model for the tree?
Do different areas of the environment have different models of administration?
How useable is the design for the users?
How does the design deal with special needs for the users?
How effectively does the tree handle default administration?
How effectively does the tree handle default rights?
How does the tree design handle disaster recovery?
Are there any implications of running DSREPAIR on any servers?
Does the tree design plan for the advantages or disadvantages of partitioning?
Is there sharing of work in the environment?
Does the tree promote the sharing of resources between divisions, departments?
The answers to these questions should help you adapt your tree design so that it fits into the special needs of your environment.
* 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.