NDS Design and Implementation

Chapter 3: Determining a Partition and Replica Strategy

 

Objectives:

This chapter introduces guidelines for partitioning an NDS Tree and for placement of partition replicas. The objectives important to this chapter are on page 3-1:

  1. Explain NDS partitioning and replication.
  2. Determine a partition and replica strategy.
Concepts:

This chapter represents one of the two procedures that may be skipped in an NDS design project. Do not look for reasons to avoid it, since partitioning serves useful purposes: redundant copies for recovery, and breaking NDS into workable pieces. You should be aware, however, of the decision process for choosing to accept the defaults. The flow chart on page 3-2 shows the three questions that must be answered to determine if this procedure is necessary:

  • Is your network confined to a single location?
  • Will you have fewer than 15 servers that will hold replicas?
  • Will there be less than 3500 objects in your Tree?

If all three questions can be answered "yes", then you may skip this procedure, accepting the default configuration of one partition (the [Root] partition). If any question is answered with a "no", you must continue along the flow chart, create a partition plan and determine replica placement.

Explain NDS Partitioning and Replication

Three reasons are given for creating NDS partitions:

  • NDS fault tolerance. Note that the text stresses that this does not add fault tolerance to the File System. Only NDS information is stored in partition replicas.
  • Efficient access to NDS information. Partitions are efficient if they provide smaller sections of the database, close to users who need the information in those sections.
  • Access to NDS from bindery services. Placing a replica on a server allows access to objects in that replica via bindery services.

Partitioning is defined on page 3-4 as simply "dividing NDS". Partitions are defined as "logical divisions of NDS" that make it possible to divide the database among servers.

The diagrams on pages 3-5 and 3-6 illustrate several basic facts about partitions:

  • each NDS object must exist in one and only one partition
  • partitions cannot overlap
  • partitions are named for the topmost container in them, which is called the partition root
  • the boundaries or partitions are defined by containers
  • partitions have parent-child relationships, just like directories

The data within a partition is stored in a replica. Replicas come in four types (sort of):

  • Master - you can make object changes here, and this is the only copy in which you can make partition changes; there can be only one master copy of each partition at one time
  • Read/Write - you can make object changes here, but not partition changes; you can have as many of these as you want
  • Read-Only - you cannot make any changes here; change requests are forwarded to the nearest replica that can make them
  • Subordinate Reference - this is not really a replica, since it contains no NDS data. It is really a simple concept: if a server holds a replica of a parent partition, but holds no replica of that parent's child partition, the server is given a subordinate reference to the child partition. In this way, information can be found more easily. The drawback is that it causes more traffic and overhead for the servers.

A chart appears on page 3-8 that summarizes the features of each type of replica. Novell recommends that you design your strategy so that there are few subordinate references. It is also recommended that there is no need to create Read-onlyreplicas, since they also increase traffic.

For a replica to be useful, it must match the other replicas of its partition. (Remember, a replica only holds data about one partition.) Page 3-9 describes NDS as a loosely consistent database. This means that there can be changes in one replica that other replicas do not know about. This condition is undesirable and is not meant to last for long, so changes in replicas are propagated, sent from the changed replica to all other replicas in a replica list. Since no changes are ever made in a Read-only replica, it can only receive changes made elsewhere. The process of converging the replicas, bringing them into a matching state, is called synchronization. Only changes made to NDS objects are sent in synchronization, not entire objects.

Transitive synchronization was new with NetWare 5. In a NetWare 5 network, you may have replicas on servers that support IP only, servers that support IPX only, and on servers that support both IP and IPX. Replicas on a server that supports only one protocol cannot directly communicate with replicas on servers that support only the other protocol. This means that for synchronization to take place, there must be at least one server supporting both protocols, which serves as a translator. If this server holds replicas as well, this procedure actually diminishes traffic.

Page 3-11 shows a graphic representation of a replica list, also called a replica ring. Note that the graphic shows a default strategy: one partition, one Master replica, two Read/Write replicas, and three servers, each holding one of the replicas.

Determine a Partition and Replica Strategy

Partition and Replication strategies are discussed on page 3-14. Much detail is given to each point:

  • Installing Servers
    • The first partition is created when the first server is installed in a new Tree. That server gets the Master replica of that partition by default. No other server installation creates a partition.
    • The second and third servers installed in a partition receive Read/Write replicas of that partition by default. Typically, other servers installed in a partition do not automatically receive replicas.
      1. Variation: whenever a server is installed in a partition, if three replicas of that partition do not exist, the new server will receive a replica.
      2. Variation: whenever you upgrade a NetWare 3 server to NetWare 4 or 5, it will receive a Read/Write replica of the partition containing that server's bindery context. (A bindery is a flat-file database. The NetWare 3 server that is upgraded is assigned a "bindery context", a particular container that will act like a bindery for applications that require a bindery.)
    • Other than these automatic replicas, you must create any other desired replicas manually.
  • Merging NDS trees
    • When two Trees are merged, one is considered the source, and the other is considered the target.
    • The operation flows from the server in the source Tree that holds the Master replica of the source [Root] partition, to the server in the target Tree that holds the Master replica of the [Root] partition of the target Tree.
    • The target server will hold the Master replica of the [Root] partition of the new Tree after the merge. Other servers from the target Tree that held replicas of the target [Root] partition lose them and get replicas of the new [Root] partition. This can cause Subordinate References to be created.
    • The source server gets a Read/Write replica of the new [Root] partition, and loses the copy of the old source [Root] partition. Other servers from the source Tree that held copies of the source [Root] partition lose them and get nothing.
    • For a merge to be successful, the first-level containers in the source and target Trees must have unique names
    • Users whose rights derive from the ACL of the source [Root] lose those rights. However, the merge activity requires that you log in as a user with Supervisor rights in each Tree (two user IDs are used). The user ID from the source Tree that conducts the merge will receive Supervisor rights to the new Tree.
    • Users whose rights derive from the ACL of the target [Root] keep those rights with respect to the new [Root] object
    • First-level containers in the source Tree [Root] partition become independent partition roots in the new Tree. Great, new partitions without even asking.

The book cautions that it is possible to design a Tree that extends beyond a firewall, but it is not recommended, because NDS changes will have to be made manually in the firewall software. If you must span a firewall, keep the parts outside the firewall small, and simple.

A partition structure should resemble a pyramid for the same reasons that the NDS structure should. Consider WAN links and geography as important, since you do not want synchronization traffic over slow links.

Lower layer partitions should consider workgroups and resources. Put users in the same partition who need the same resources.

Page 3-22 offers suggestions for a network using 100 MHz Pentium servers with 64 MB of RAM. Better servers can do more, less powerful servers can do less:

  • a partition should have fewer than 3,500 objects
  • a partition should have fewer than 35 child partitions per parent
  • Think of this as the Strunk and White rule: Avoid creating unnecessary partitions. A list appears on page 3-23 with the pros and cons of more small partitions. Novell typically asks test questions that ask why doing something is a good idea, and this chart supplies some justifications.

The text cautions you to follow the recommendations in this chapter for NDS version 7. It mentions that NDS version 8 has different characteristics:

  • Trees can store an unlimited number of objects (load tested to 1 billion objects)
  • Partitions can contain an unlimited number of objects (load tested to 100 million objects)
  • The number of child partitions is unrestricted (load tested to 75 partitions)

The text discusses seven goals of good replica placement:

  • Meet workgroup needs - if workgroups are mobile, this is more complex. In an example, users need access to resources in replicas that are across a WAN link. Having a replica stored on each side of the WAN link will actually decrease traffic, in this case.
  • Create fault tolerance - the minimum for fault tolerance is three replicas of each partition, and as many as ten depending on complexity of the network.
  • Manage the number of replicas - no more than ten replicas of each partition, no more than twenty replicas per server
  • Replicate the [Root] partition - it is noted as the most important partition in the Tree
  • Replicate for administration - place master replicas on servers near the network administrator who is in charge of partition changes
  • Meet bindery services needs - each server may need a Read/Write replica of the bindery context. This is an excellent reason to stop supporting bindery services.
  • Manage WAN traffic - WAN Traffic Manager is a Novell product to manage NDS synchronization traffic. Three components are listed: WTM.NLM, a NetWare Administrator Snap-in, and WAN Traffic Policies.

The heart of the chapter is summed up in the following problem. You must be able to look at a diagram of network partitions, and a table of replica placements, and then detect the errors in either one. Also, you must be able to apply the principles of this chapter to fill in missing entries in the table, either replicas that should exist or subordinate references that will automatically be created.

 
Servers
Partitions
  [Root] Comp Loc 1 Loc 2 Loc 3 Dpt 1 Dpt 2 Dpt3 Dpt 4 Dpt 5
S1     Master   Master Master        
S2 R/W   R/W              
S3 Master R/O   Master R/W     Master R/W  
S4   Master   R/W           Master
S5                 Master  
S6 R/W S/R         Master      

 

In the table above, I have left out several Subordinate References (usually abbreviated S/R). I am only showing one, for the Comp partition on Server 6. There are also several missing replicas that should be there. Review this material, and see if you can tell what is missing. (To check yourself, mouse over the cells in the table to see which ones should hold S/Rs. Cells that should hold an S/R should dynamically change on this page.)

The concepts of Tree Walking and Name Resolution are the same concepts (at least, in NDS). Every replica has a little extra information stored in it: pointers to replicas that are above and below it in the partition hierarchy. If a user needs something from a replica that is not on the server the user is connected to, NDS uses these pointers to find a server that has a replica with the needed information. Tree Walking is not an efficient thing, so placing replicas near users who need them is a recommended practice.