This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
EDirectory Synchronization
EDirectory Synchronization

Version management

Difference between version and

At line 1 added 126 lines
!!! Overview[1][2]
[{$pagename}] is the propagation of the [eDirectory] [data] from one [replica] to another to have [data] Consistency] of each [replica] of the [partition].
[{$pagename}] 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 [{$pagename}] for those of interests or those who might be new to the idea.
!! [{$pagename}]
Changes are recorded in the [Change Cache]. The [Change Cache] stores a list of objects that need to be [synchronized|Synchronization] 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]
[{$pagename}] 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 [{$pagename}]
[{$pagename}] 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
[{$pagename}] for outbound synchronization specify the number of [synchronization] [NDS Threads] using Agent Configuration under Agent [Synchronization]. The supported values are 1 to 16.
!! [{$pagename}] Method
[eDirectory], by default, automatically chooses the method based on the number of [replicas] and [replication] partners. The following are the [{$pagename}] 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 [{$pagename}] method.
%%information
[EDirectory 9.0.0.0 (40002.79)] or later, [Skulker] will immediately start [{$pagename}] __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 [{$pagename}] is already in progress.
%%
!! [{$pagename}]
[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 [{$pagename}] Occur
There are several methods to determine when [{$pagename}] 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|Edirectory Replicas] - [NDS Master Replica], [Read/Write|Edirectory Read Write Replica|NDS Read-Write Replica], [NDS Read-Only Replica] and [NDS Sparse Write Replica].
* [Replica Ring or list|Replica 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].
!! [Partition Root Entry]
The [Partition Root Entry] holds several [AttributeTypes] which are required for [{$pagename}]
!! [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 [replica]s 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|NDS Obituaries] 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|Schema Sync]
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]
[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]
[{$applicationname}] provide some [EDirectory Synchronization Tips] we have learned.
!! [Monitoring Edirectory Synchronization]
Some information on [Monitoring Edirectory Synchronization]
!! Category
%%category [eDirectory]%%
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [http://support.novell.com/techcenter/articles/anp20021101.html|http://support.novell.com/techcenter/articles/anp20021101.html|target='_blank'] - based on 2011-06-17
* [#2] - [eDirectory Background Processes Notes|http://www.jamesgosling.com/eDirectory%20Background%20Processes%20Notes.html|target='_blank'] - based on 2011-06-17
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop