How Do I Partition My NDS Tree?
Articles and Tips: article
Senior Editor
DeveloperNet University
nmclain@novell.com
01 Aug 2000
This section looks at some of the intricacies of partitioning an NDS tree, followed by six basic design principles to help simplify the design task.
Novell Directory Service (NDS) was designed to be extremely flexible so that it would lend itself to many different organization structures. This flexibility means that companies can design their NDS tree to fit their specific needs. Unfortunately, this same flexibility in design sometimes intimidates network administrator's understanding and skill set. However, partitioning the NDS tree and designing those partitions can be extremely simple if you remember why you create a partition to begin with.
The primary reason to create a partition is to localize the network information. Partition the data to keep it physically close to the users who use it most often. This means that if your network spans a WAN link, for example, you will want to place a replica on a server on the same side of the WAN link as its users. Partitioning is simple if you copy the physical layout of your network infrastructure. If you have a very small network, you don't need to partition your tree.
Let your network's physical layout (the WAN links and the network servers) guide you in partitioning your NDS tree. This is the most important design principle. If you use the network physical layout as a partition guide, you will find it easier to determine where to physically locate specific information. Figure 1 shows ALargeCompany's NDS tree.
Figure 1: ALarge Company's NDS tree organization.
ALargeCompany has divisions in Germany, the United States, and England. Figure 2 shows the physical layout that supports ALargeCompany's NDS tree.
Figure 2: The physical WAN links that ALargeCompany's NDS tree crosses.
The first partitions you should make in the tree are readily apparent. Figure 3 shows them.
Figure 3: Illustration of the first partitions you should make.
As Figure 3 shows, ALargeCompany's NDS tree is first partitioned by the company's office locations. Each partition is then placed on a server that is physically located on each office's site. This prevents each office from continually crossing the WAN link to access their information.
When we discuss replication, you will see that replicas of a partition are placed across WAN links when they are needed. But, they are usually configured so that their synchronization across the WAN link only occurs at specific times. Each of the above partitions will usually be organized into smaller parent/child partitions, with the information placed physically close to each group that frequently accesses it. However, if the office sites are small, these partitions might be enough to provide efficient synchronization operations.
Six Design Principles
The following six design principles are suggested guidelines that you can use to simplify your design task.
Don't span a WAN or other slow links with a partition. If a partition spans a WAN link, synchronization causes unnecessary NDS traffic to travel across the WAN link between the two locations. This can slow the network and it means that your NDS database won't scale well.
Keep the ROOT partition small. Usually, the [ROOT] partition includes only the [ROOT] object and the O=Organization object. Avoid including other subordinate containers in the [ROOT] partition. You want to keep your [ROOT] partitions small because as your company grows, it enables the tree to scale more easily. Sometimes, you might need to have your [ROOT] partition scan a WAN link. Small [ROOT] partitions make it possible to span WAN links. You can also more easily place the root in more strategic locations.
Partition the top layers of the tree according to your company's locations. This is to keep the network information physically close to the users who access it the most. This also prevents users from accessing the information across a WAN link, slowing their access and creating unnecessary network traffic. You don't need to partition the tree at every organizational unit container. First, partition your tree by geographic location, then partition locally, only if necessary.
Partition the bottom layers of the NDS tree only if your network has special requirements, such as a large partition, more than ten replicas of the partition, or the need to break out a subtree for administration purposes. By splitting a partition, you reduce the total number of replicas for that partition. Reducing the number of replicas means less management if you must repair the partition. If you must repair a partition, you might need to repair every server holding a replica or subordinate reference. Sometimes department or site managers want to manage their own partitions. If this is the case, you can partition their subtree so that they can manage it.
Keep a smaller number of partitions at the top of the tree and, if necessary, increase the number of partitions toward the bottom of the tree. Novell recommends that you design your NDS tree in a pyramid shape. If you do so, you can easily design your partitions so that they follow the tree design. Designing the partitions to follow your tree's pyramid design distributes the subordinate reference replicas.
Create a partition only if you can store it on a local server. If you have small remote offices that don't have servers at their local site, they must access all network services (including NDS) across WAN links. So if you have a small office at a remote site without its own server, don't make that office's container a separate partition.
Remember, if you design your NDS tree as a pyramid, with fewer objects on top and more objects towards the bottom, and follow these partition guidelines, you ensure that the NDS information always remains close to your users.
* 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.