Novell eDirectory Design and Implementation

Chapter 4: Determine a Partition and Replica Strategy

 

Objectives:

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

  1. eDirectory partitioning and replication
  2. Determine a partition and replica strategy
  3. WAN Traffic Manager Strategy
Concepts:
Explain eDirectory Partitioning and Replication

Three reasons are given for creating eDirectory partitions:

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

Partitioning is defined as simply dividing eDirectory into sections . Partitions are defined as logical divisions of eDirectory that make it possible to divide the database among servers. Note eDirectory can be stored on NetWare, Windows, or Linux servers.

The diagram on page 4-6 illustrates several basic facts about partitions:

  • each eDirectory 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 six 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 eDirectory 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.
  • Filtered Replicas - Filtered replicas contain only part of the information stored in a partition. They can be used to provide eDirectory information when only some information is needed. You can use ConsoleOne to create Filtered Read/Write replicas or Filtered Read-Only replicas.

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-only replicas, 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.) eDirectory is 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 eDirectory objects are sent in synchronization, not the 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 4-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 4-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 eDirectory 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.

Novell cautions that it is possible to design a tree that extends beyond a firewall, but it is not recommended, because eDirectory 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 eDirectory 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 4-32 offers an update about the capacitites of dDirectory 8.5, since they are different from previous versions. (Version 7 and earlier versions were referred to as NDS, Novell Directory Services.)

  • a partition may have an unlimited number of objects
  • a partition should have fewer than 500,000 objects
  • parent partitions may have up to 150 child 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.
  • Regulate the number of replicas - no more than 50 replicas of each partition, no more than 250 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. Replicas can be large, so don't copy them when the network is busy.
  • Set Up Name Resolution - place replicas of all partitions users need on a single server close to those users.

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 eDirectory). 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, eDirectory 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.

WAN Traffic Manager Strategy

WAN Traffic Manager is a Novell product to manage eDirectory synchronization traffic. It is available for NetWare and Windows servers, but not on UNIX/Linux servers.

The issue is that eDirectory traffic must sometimes cross WAN links. You can regulate this traffic based on several parameters, such as time of day, cost of traffic, type of traffic, or combinations of these factors.

Three components are listed: WTM.NLM, a ConsoleOne Snap-in, and WAN Traffic Policies. WTM.NLM is replaced by WTM.DLM when run on Windows servers.