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.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.
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.
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 - NDS Master Replica, Read/Write, NDS Read-Only Replica and NDS Sparse Write Replica.
- 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 PseudoServer Browse functionality (eDirectory 8.6 or greater).EDirectory Synchronization Tips we have learned. Monitoring Edirectory Synchronization
More Information #There might be more information for this subject on one of the following:
- Asynchronous Outbound Synchronization
- Change Cache
- EDirectory Performance Tuning
- EDirectory Synchronization
- EDirectory Synchronization Tips
- Event number
- LOST ENTRY
- NDS External References
- NDS Sparse Read Replica
- Netware Core Protocol
- Partition Root Entry
- Priority Synchronization
- Replica List
- Replica number
- Schema Sync
- 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