jspωiki
EDirectory Synchronization

Overview[1][2] #

EDirectory Synchronization is the propagation of the directory information from one replica to another so the information in each partition is consistent with each other.

The EDirectory Synchronization is limited to the entries within the Replica List.

The idea of synchronizing data among "n" number of servers is quite a daunting and complex task and even more daunting in a full-multi-master environment.

Perhaps that is why only a few LDAP Server Implementations provide such a service.

Our attempt in this discussion is to try to put some definitions and concepts around EDirectory Synchronization for those of interests or those who might be new to the idea.

EDirectory Synchronization#

Changes are recorded in the Change Cache. The Change Cache stores a list of objects that need to be synchronized or purged so that the information can be communicated to other replicas.

The Partition Root Entry receives a current Replica List when it is created. When changes are made to objects within a partition, those changes are sent to the Replica List of the Partition Root Entry.

Servers can communicate to multiple servers simultaneously. By default, the receiving servers can only synchronization at a time.

Synchronization is scheduled to execute 2 minutes after the database successfully initializes, then rescheduled upon completion to execute every Heartbeat Synchronization (Default is 60 minutes). The Heartbeat Synchronization occurs even if no changes have been made recently.

Object Synchronization [1]#

Novell's eDirectory has a very slick and efficient Synchronization engine that takes care of the following features:
  • Convergence, which is the act of making an object consistent among all instances of that object.
  • hierarchy, which is a graded series of objects in which each element may contain other objects.
  • Replication Styles, offered are Single Instance, Master-Slave, Multi-Master, and Hybrids.
  • Replication Methods, None, Copy and Replace, Change Log, State Based and Hybrids.
Note: Of the above features, eDirectory uses Multi-Master/Slave Hybrid and State-Based the most.

When Does EDirectory Synchronization Occur #

There are several methods to determine when EDirectory Synchronization will occur.

In addition, eDirectory utilizes the following features in the synchronization process:

Partition Root Entry#

The Partition Root Entry holds several AttributeTypes which are required for EDirectory Synchronization

Local Received Up To (LRUT) #

eDirectory uses LRUTs to keep track of what changes have been received from other replicas in the network. LRUTs are also used to inform inbounding replicas of the current synchronization state and to advertise the local state when the agent is ready to do an outbound synchronization.

Once the changes are ready for outbound synchronization, the following occurs:

  • Read the last TimeStamp issued on the local replica localReceivedUpTo from the partition record
  • Update the row in the Local Received Up To corresponding to the local Replica List number
  • Update the transitiveVector value corresponding to the local agent ("server")
  • The updated data is then sent out to all of the other servers.

External Reference Synchronization #

An NDS External References is a name that needs to be tracked by the local Directory Information Base (DIB) in the External Reference Partition.

Normally External References are maintained by a Reference Check Process, such as the Backlinker or Distributed Reference Links processor.

NDS Obituaries Synchronization #

In eDirectory, an Obituary is used to ensure referential integrity during operations, such as delete, move, rename, and the like. The most common types of Obituaries are two fold:
  • Primary, which can be Dead, Restored, Moved, Inhibit Move or New Relative Distinguished Name (RDN)
  • Secondary, which can be Back Link or Used By

Schema Synchronization #

The eDirectory schema resides on all agents (servers) in the network within the Schema Partition. The Schema Sync process ensures that all severs which hold the ROOT partition have the same schema.

Limber Process #

Limber is the process that performs Agent Configuration Synchronization. Limber (also referred to as Connectivity Check) may trigger other processes to refresh their configuration (i.e. LDAP, etc.) Limber is scheduled to run every 4 hours by default, which is configurable in NDS iMonitor. It will also run when requested or when a change is noticed that needs to be synchronized.

This process maintains data such as the Network Address, Index Definitions, the NCP Server's RDN and location in the tree, the Tree Name, and Permanent Configuration Parameters. You can tell if you are having this type of problem in your network by using NDS iMonitor, the Agent Process Status and Pseudo Server Browse functionality (eDirectory 8.6 or greater).

EDirectory Background Processes #

There are other EDirectory Background Processes

EDirectory Synchronization Tips#

We provide some EDirectory Synchronization Tips we have learned.

Monitoring Edirectory Synchronization#

Some information on Monitoring Edirectory Synchronization

More Information #

There might be more information for this subject on one of the following: