Understanding the Relationships BetweenNDS Partitions
Articles and Tips: article
12 Jul 2000
Last month I explained what partitions are and what role they play in Novell Directory Services (NDS). This month I will discuss how partitions are related to each other.
Organizing Your NDS Tree
By dividing your NDS tree into partitions, you can organize the tree so that it reflects your organization's logical structure. Doing so helps you place network data close to the users who will access it.
An NDS tree can be partitioned so that its partitions have subordinate partitions to reflect your organization's hierarchical structure. Figure 1 shows an example of a tree with superior and subordinate partitions (the shading indicates the partitions).
Figure 1: An example of a partitioned NDS tree.
The [Root] Partition
The most superior of all partitions is called the [Root] partition, which is created during the installation of the first NDS server in a tree (see Figure 2). The installation program creates just this one partition and places a replica (copy) of it on the first NetWare 5 server. It is up to you to create all other partitions besides [Root].
Figure 2: The [Root] partition is the top-most partition in the NDS tree.
After you have installed the first server, you add the other objects necessary to build your company's NDS tree structure. For example, you would typically create several OU (Organizational Unit) objects beneath the O (Organization) object. The [Root] partition initially holds all the objects you create. You can then create additional partitions by selecting a container (O or OU) object below the [Root] container. The object you select becomes the partition's root container, and resulting partition contains all the objects held in that container and all of its subordinate containers.
You should keep the [Root] partition small, with only the top-most O object and as few other objects as effectively possible. This will enable your tree to scale more easily as your company grows. Sometimes you might need to have your [Root] partition span a WAN link (although this is generally not recommended). Small [Root] partitions make it possible to span WAN links more effectively. You can also more easily place the root in more strategic locations.
You can't remove the [Root] partition without removing NDS from all the NetWare 5 servers. When you do this, you effectively delete the entire NDS tree.
Parent and Child Partitions
Looking at Figure 1, you can see that the Germany partition is a superior partition to the subordinate partitions Marketing, Engineering, and Finance. Engineering.Germany, while subordinate to the Germany partition, is superior to the Development and Testing partitions.
Superior and subordinate partitions are called parent and child partitions. The parent partition is always the partition closer to the Root than the child partition. The child partition is always the partition furthest from the root.
For example, the Germany partition is a parent partition. Its three subordinate partitions--Marketing, Engineering and Finance--are its child partitions. The Engineering.Marketing partition is, in turn, a parent partition with two child partitions--Development and Testing. The England partition is also a parent partition, and it has two child partitions: Human Resources and Engineering.
Child partitions that share the same parent partition are called sibling partitions. For example, Marketing.Germany, Engineering.Germany, and Finance.Germany share the same parent partition (Marketing), so they are siblings to each other.
In NDS, parent partitions keep track of their child partitions. That is, when child partitions are created, their parent partitions maintain a record of their locations. If a server doesn't hold the parent partitions and all of its children partitions, NDS creates a subordinate reference replica for the child partitions that are not on the same server as the parent. The subordinate reference replica tells NDS which server the child partition is on.
Figure 3 shows the Engineering partition from our example tree. Server 1 holds the Germany/Engineering/Development portion of the partition. Server 2 holds the Testing portion of the partition. Testing is a child of Germany/Engineering and a sibling of Development.
Figure 3: An example of different servers holding child partitions.
Because the server that holds the Engineering parent partition also holds a reference to the server that holds its child partition (Testing), users are able to traverse the NDS tree even though the tree is actually split up into several pieces. When a tree is partitioned like this, users never know they are looking across different servers.
When you are deciding how to partition your NDS tree immediately below the [Root] partition, remember that parent partitions hold subordinate references to all their children partitions. This means that if you put several partitions immediately below the [Root] partition, your [Root] partition will hold several Subordinate References--one for each of its child partitions.
If your tree looks like the tree in Figure 4, its [Root] partition will hold one subordinate reference for every replica. Having too many Subordinate References at this level can make your tree much more difficult to scale and maintain.
Rules for NDS Partitioning
To summarize what we've discussed about partitioning, here are three basic rules that govern NDS partitioning:
Partitions require a single container object at the top of the partition. This container object is called the partition root object. Each partition can have only one partition root object.
Partitions cannot overlap. No one object will ever reside in two partitions.
Partitions contain all of the information for the connected subtree. In other words, you can think of each partition as a section or subtree of the entire NDS tree.
Parent and child partitions help you logically organize the NDS tree so you can efficiently distribute network data across multiple servers. They also help maintain the tree's hierarchical organization.
* Originally published in Novell AppNotes
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.