Alan Frayer, CNE, CNI, CIW CI, Net+, MCP

Vote for us at the sites below:

Q. What is the significance of subordinate references in an NDS tree, and how do I determine where they exist?

A. Please consider the following NDS tree sample and replica table during this discussion:

Server [Root] EMA LA EU FCHI001 M     R/W FCHI002 R/W M     FCHI003 R/W   R/W   FBUA001   R/W M R/W FLON001   R/W R/W M

When we partition the NDS tree, we distribute pieces of the NDS database to various servers, making it easy to keep the portion of the tree most used by a set of users close to those users, without keeping copies of the entire database everywhere. Each piece of the tree we call a replica, and each partition will have at least one replica (called the master replica), stored on a server on the network. Additional replicas, if needed or desired, are called read/write replicas, and are also placed on various servers on the network. Multiple replicas of a partition are a good idea for fault-tolerance, allowing continued network operation and ease of repair, should a single replica fail. Replicas do not need to be stored on servers within their partition, although we commonly have at least one replica local to the users who need it.

A parent/child relationship exists between partitions, to allow users to locate NDS objects in partitions other than their own, a process called tree walking. A parent partition is one that exists directly above another partition in the NDS tree. A child partition, then, is a partition that exists directly below another partition. A partition can be the child of another partition, and have children of its own.

In this example, we can see that we have parent/child relationships between the [Root] and EMA partitions, the EMA and LA partitions, and the EMA and EU partitions. By applying master replicas local to their partitions, we insure each partition can be reached by their principal users, and two read/write replicas of the partitions are placed elsewhere for fault tolerance.

We are not limited to placing one replica on one server. A fast, powerful server can hold many replicas, but it is common for servers to hold two or three replicas. This is the case in our example; server FCHI001 holds the master replica of the [Root] partition and a read/write replica of the EU partition, for instance. When a server stores a replica of both a parent and child, requests for objects in the child partition by a user in the parent partition are easily authenticated by the one server, which knows the entire structure of both partitions.

When a server holds a replica of a parent, but not of the child, the server needs to replace the child with something that will know enough of the structure to tell where the replicas exist, so it can refer requests to the right servers. This something is called a subordinate reference, and it only exists on servers where a replica of a parent partition exists, but a replica of the child partition does not. Subordinate references cause additional network traffic by forwarding requests they can't handle themselves to servers that can.

To determine which servers hold subordinate references, you need a logical diagram of the NDS tree with partitions defined and a replica table, which describes the placement of replicas on the network. A replica table lists the names of the partitions across the top, and the names of the various file servers down the side. Novell recommends each partition have at least three replicas (one master and two read/writes); by looking down each column, one can verify this requirement is met.

Once the replicas are placed, one should read across the columns, looking for servers that hold replicas of parent partitions without their children. In the example, FCHI001 has a master of [Root], which is the parent of EMA, however FCHI001 does not hold a replica of EMA. As a result, FCHI001 will hold a subordinate reference to EMA. LA is a child of EMA, but is not one of [Root] (LA is not directly below [Root]). Since FCHI001 does not hold a replica of EMA, it doesn't need one of LA, and no subordinate reference is created. If we placed a replica of EMA on FCHI001 to remove the subordinate reference, we would create one to LA.

On larger networks, the replica table can get rather large, but since excessive subordinate references cause excessive traffic, we need to know how to build and read replica tables to decide on the proper placement of replicas to reduce subordinate references.

[Home] [PDA Applications] [Contract CNI] [Q & A] [Calc. Sub. Ref.] [Host-Host] [Mappings] [NDS vs Bindery] [Merging Trees] [Configuration] [NetWare Tips] [Bookstore] [PC Life] [Links] [Novell News] [Shopping Mall]