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.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.
When Does EDirectory Synchronization Occur #There are several methods to determine when EDirectory Synchronization will occur.
- Attributes that are marked X-NDS_NOT_SCHED_SYNC_IMMEDIATE are added to the Change Cache as a Slow Convergent or (30 second hold time).
- Attributes that are marked NOT X-NDS_SCHED_SYNC_NEVER are added to the Change Cache which will sync whenever the next EDirectory Synchronization cycle happens but not longer than the N4u.nds.heartbeat-data interval.
- Any other Attributes will initiate "Fast" 10 seconds or less.
- Priority Synchronization will take place Now.
In addition, eDirectory utilizes the following features in the synchronization process:
- Replica Types - Master, Read/Write, Read Only and Filtered.
- Replica Ring or list - The set of eDirectory agents that hold a Edirectory Replica of a given partition and, therefore, participate in the synchronization of objects contained with that partition.
- Deltas - The time differences between copies of a given object. Effectively the change window becomes the difference between RRUT and LRUT
- Change Cache - The collection of objects with deltas for a given replica.
- Heartbeat Synchronization - Periodically, members of the Replica List will check that they are still converged.
- Transitive Synchronization - A method for providing convergence of data without requiring an eDirectory agent with changes (i.e. state based deltas) to directly contact and synchronize those changes with every other agent in the Replica List.
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.
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
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 EDirectory Synchronization Tips we have learned. Monitoring Edirectory Synchronization
More Information #There might be more information for this subject on one of the following:
- Change Cache
- EDirectory Synchronization
- NDS External References
- Partition Root Entry
- Priority Synchronization
- Replica List
- Test Page
- User-Defined Partitions
- [#1] - http://support.novell.com/techcenter/articles/anp20021101.html - based on 2011-06-17
- [#2] - eDirectory Background Processes Notes - based on 2011-06-17