EDirectory Synchronization

Overview[1][2] #

EDirectory Synchronization is the propagation of the eDirectory data from one replica to another to have data Consistency] of each replica of the partition.

EDirectory Synchronization is limited to the entries within the Replica List and is an EDirectory Background Processes.

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 Transaction Model [1]#

EDirectory Synchronization maintains the object transaction model, a standard for LDAP and X.500-compliant directories. Object Transaction Model means that all the previous transactions should be synchronized before synchronizing newer Transactions.

Enabling/Disabling EDirectory Synchronization#

EDirectory Synchronization can be enabled or disabled through by enabling or disabling the outbound and inbound synchronization in iMonitor.
  • Outbound synchronization is enabled by default. When you disable this option on a server, the modifications to the data on this server are not synchronized with other servers. You can specify the amount of time, in hours, for which you want the outbound synchronization disabled. The default which is also the maximum time is 24 hours. After the specified time, the modifications to the data on this server are synchronized with other servers.
  • Inbound synchronization is enabled by default. When you disable this option for a server, the modifications to the data on other servers are not synchronized with this server.

Enabling/Disabling Inline Cache#

Inline Cache can be enabled or disabled the Inline Change Cache for a server. Inline Change Cache can only be disabled when Outbound Synchronization is disabled. Enabling Outbound Synchronization also enables Inline Change Cache.

Disabling Inline Change Cache marks the Change Cache as invalid for this replica and tags it with an invalid flag in Agent Configuration > Partitions. Enabling Inline Change Cache removes the invalid change cache flag when the Change Cache is rebuilt.

Synchronization Threads#

EDirectory Synchronization for outbound synchronization specify the number of synchronization NDS Threads using Agent Configuration under Agent Synchronization. The supported values are 1 to 16.

EDirectory Synchronization Method#

eDirectory, by default, automatically chooses the method based on the number of replicas and replication partners. The following are the EDirectory Synchronization Methods:
  • By Partition - The modifications to data are synchronized simultaneously with other replicas. Several NDS Threads are used to synchronize the modifications.
  • By Server - Modifications to data are synchronized sequentially. Only one thread is used to sync the modifications.
  • By Dynamic Adjust - Based on the system resources you have allotted, eDirectory automatically chooses the EDirectory Synchronization method.

EDirectory (40002.79) or later, Skulker will immediately start EDirectory Synchronization without any delay soon after the data transaction completes successfully. This is done without affecting the performance of LDAP operations.
Immediate skulking does not impact the schedule when EDirectory Synchronization is already in progress.

EDirectory Synchronization#

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 PseudoServer Browse functionality (eDirectory 8.6 or greater).

EDirectory Synchronization Tips#

Ldapwiki 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: